1. 项目概述为什么我们需要 Agent最近和不少刚接触 AI 应用开发的朋友聊天发现一个挺普遍的现象大家一上来就兴致勃勃地讨论要搞个“智能 Agent”但细问之下很多人其实没太搞明白 Agent 和它底层的 LLM大语言模型到底有啥本质区别。这感觉就像是想造一辆能自动驾驶的汽车却把全部精力都放在了研究发动机的马力上忽略了方向盘、传感器和决策系统。结果往往是用上了最先进的“发动机”比如 GPT-4做出来的东西却像个“人工智障”只能一问一答离真正的“智能体”相去甚远。所以今天我想从一个一线开发者的角度掰开揉碎了聊聊这个话题。我们不谈那些高大上的学术定义就说说在实际项目中LLM 和 Agent 到底扮演什么角色以及那个听起来有点技术范儿的Function Calling是如何成为连接两者的关键桥梁的。无论你是想自己动手搭建一个能处理复杂任务的 AI 助手还是仅仅想理解当前 AI 应用的技术脉络这篇文章都会给你一个清晰、可操作的认知框架。简单来说你可以把LLM 看作是一个“超级大脑”它博览群书训练数据知识渊博擅长理解和生成自然语言。你问它“今天天气怎么样”它能根据训练数据里的知识编造一段合情合理的描述。但它有个致命缺陷它活在“虚拟世界”里它的“知识”截止于训练数据它无法感知实时数据比如此刻的真实天气也无法操作外部系统比如帮你订一张机票。它的回答是基于概率的“语言模仿”。而Agent智能体则是一个“完整的智能个体”。它同样拥有一个“大脑”通常是 LLM但这个大脑被赋予了“感知器官”能获取实时信息、“执行器官”能调用工具完成任务和“记忆系统”能记住对话历史和任务上下文。更重要的是它有一套“思考逻辑”Agent 框架能自主规划、决策、使用工具最终达成一个复杂目标。比如你让一个旅行 Agent “帮我规划一个周末去杭州的行程并预订高铁票和酒店”它会自己分解任务先调用天气 API 查杭州天气再调用交通 API 查高铁班次接着调用酒店预订 API 筛选酒店最后把结果整合成一份行程单给你。这个过程LLM 只是其中负责“思考规划”和“语言组织”的组件。那么LLM 这个“虚拟大脑”是如何指挥“物理世界”的工具去执行任务的呢答案就是Function Calling函数调用。这是当前构建实用 Agent 最核心、最主流的技术范式。它本质上是一种“标准化协议”让 LLM 能够以结构化的方式“表达意图”当它判断需要执行某个外部操作时不是用模糊的自然语言说“你去查一下天气”而是输出一个格式严格的 JSON 对象指明要调用哪个函数工具并传入哪些参数。外部的执行引擎收到这个 JSON就去真正执行对应的代码如调用天气 API然后把执行结果结构化的数据再塞回给 LLM由 LLM 组织成人类友好的语言输出。理解了这三者的关系你就能明白从 LLM 到 Agent 的跨越关键在于从“语言生成”到“目标驱动行动”的转变。而 Function Calling 就是实现这一转变的“关节”技术。接下来我们就深入这个“关节”看看它具体是怎么工作的以及在实践中如何用好它。2. 核心原理拆解Function Calling 如何让 LLM“动手做事”2.1 从“聊天”到“调度”思维模式的根本转变在没有 Function Calling 之前我们和 LLM 的交互基本是“聊天模式”。用户输入一个问题模型输出一段回答。即使我们通过复杂的提示工程Prompt Engineering让模型在回答中“暗示”需要某个信息比如“要回答这个问题我需要知道北京的实时气温”但这也只是一段文本。应用程序需要非常脆弱且不稳定的文本解析比如正则表达式来尝试捕捉这种意图然后手动去调用 API再把结果拼接回对话上下文。这个过程笨重、易错且很难扩展。Function Calling 引入了一种“声明式”的交互范式。我们不再要求模型“在回答里暗示”而是提前告诉模型“伙计我这里给你准备了几个工具这是它们的功能说明和用法。当你觉得需要用到时就直接告诉我你要用哪个参数是什么。” 模型输出的不再是最终答案的自然语言而是一个或多个标准的“工具调用请求”。这个转变的核心在于“将意图识别与结构化输出相结合”。LLM 擅长理解用户的自然语言意图“我想知道天气”而 Function Calling 要求它把这种意图映射到我们预先定义好的、结构化的工具调用指令上。这相当于给 LLM 的“思考过程”加了一个输出模板让它从天马行空的文本生成转变为目标明确的“调度指令”生成。2.2 技术实现剖析OpenAI 格式的 Function Calling目前业界最广泛采用的 Function Calling 标准源自 OpenAI API。我们以其为例拆解其核心组成部分。当你向 ChatGPT 或相关 API 发起一个包含工具定义的请求时流程如下1. 工具定义告诉模型你有什么你需要在请求中以 JSON Schema 的形式向模型描述你可用的工具函数。每个工具定义包括name: 函数名称如get_current_weather。description: 函数功能的自然语言描述。这部分至关重要它直接决定了模型是否能在合适的场景下想起并使用这个工具。描述应清晰、简洁说明函数做什么、适用于什么场景。parameters: 函数的参数列表同样用 JSON Schema 描述。包括参数名、类型、描述以及是否是必需的。{ type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气情况, parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京上海 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位摄氏度或华氏度 } }, required: [location] } } }2. 模型决策与结构化输出模型选择工具用户提问“北京今天热吗” 模型结合对话上下文和你提供的工具定义进行推理。它会想“用户问北京热不热这需要天气信息。我有个工具叫get_current_weather可以获取天气而且需要location参数。北京符合这个参数。” 于是模型不会生成“北京今天气温是...”而是生成一个特殊的消息响应其content字段可能为空但会包含一个tool_calls数组。{ role: assistant, content: null, tool_calls: [ { id: call_abc123, type: function, function: { name: get_current_weather, arguments: {\location\: \北京\, \unit\: \celsius\} } } ] }注意arguments是一个 JSON 字符串其结构必须完全符合之前定义的parametersSchema。3. 执行与回传应用程序干活你的应用程序收到这个响应后解析tool_calls。根据name找到本地真正的函数get_current_weather解析arguments中的参数然后执行它比如调用一个真实的天气 API。执行完毕后你需要将结果以特定格式追加到对话历史中。4. 结果整合与最终回复模型生成答案你将工具执行的结果作为一个新的消息role设为tool送回给模型。{ role: tool, content: {\temperature\: 28, \condition\: \晴朗\, \humidity\: 65}, tool_call_id: call_abc123 }模型看到这个工具执行结果后结合最初的用户问题生成最终的自然语言回复“北京今天天气晴朗气温28摄氏度比较暖和。”实操心得描述description是灵魂很多新手在定义工具时只草草写个名字和参数类型结果发现模型经常“瞎用”或“不用”。关键在于description和参数description。要用模型能理解的自然语言清晰说明工具的用途、适用场景以及每个参数的确切含义。例如location的描述写成“城市或地区名”就比“地点”要好。这本质上是你在“教”模型如何理解和使用这个工具。2.3 与其他技术路径的对比除了 Function Calling早期让 LLM 使用工具还有别的方法了解它们有助于理解 Function Calling 的优势ReActReasoning Acting模式通过精心设计的提示词要求模型以“Thought: ... Action: ... Observation: ...”的格式进行链式思考。Action 部分输出类似Search[关键字]的文本再由程序解析执行。这种方式完全依赖提示工程和模型的文本遵循能力格式不稳定解析容易出错开发体验较差。LangChain ToolsLangChain 框架封装了工具调用的通用流程其底层早期也依赖 ReAct 等模式现在也深度集成了 OpenAI 的 Function Calling。它提供了更高层次的抽象但理解其底层原理即 Function Calling对于调试和优化至关重要。Function Calling 的核心优势在于“标准化”和“结构化”。它将工具调用的意图、参数和结果都约束在明确的 JSON Schema 内极大降低了系统集成的复杂度提高了可靠性和开发效率。它已经成为当前 AI 应用开发中连接 LLM 认知世界与外部行动世界的“事实标准”。3. 从零构建一个简易天气查询 Agent理论说再多不如动手做一遍。我们用一个最简单的“天气查询 Agent”为例展示如何将 LLM这里用 OpenAI GPT与 Function Calling 结合打造一个能真正“动手”查天气的智能体。我们将使用 Python 和 OpenAI SDK但思路适用于任何语言。3.1 环境准备与工具函数定义首先确保你已安装 openai 库并配置好 API 密钥。pip install openai接下来我们定义这个 Agent 的核心——工具函数。这个函数并不直接调用真实 API为了简化而是模拟返回数据。import json import openai from typing import Optional # 设置你的 OpenAI API 密钥 openai.api_key your-api-key-here # 模拟的天气数据源 def get_current_weather(location: str, unit: str celsius) - str: 模拟获取天气的函数。 在实际应用中这里会调用如 OpenWeatherMap、和风天气等第三方 API。 Args: location: 城市名称如“北京”、“上海”。 unit: 温度单位“celsius” 或 “fahrenheit”。 Returns: 返回一个包含天气信息的 JSON 字符串。 # 模拟根据城市返回数据 weather_data { 北京: {temperature: 22, condition: 多云, humidity: 60}, 上海: {temperature: 28, condition: 晴朗, humidity: 75}, 广州: {temperature: 32, condition: 雷阵雨, humidity: 85}, } data weather_data.get(location, {temperature: 25, condition: 未知, humidity: 50}) # 模拟单位转换简陋版 if unit fahrenheit: data[temperature] data[temperature] * 9/5 32 return json.dumps(data) # 定义工具的 Schema用于告诉模型这个工具的存在和用法 tools [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气信息包括温度、天气状况和湿度。, # 清晰描述 parameters: { type: object, properties: { location: { type: string, description: 需要查询天气的城市名称必须是一个明确的城市名例如北京、纽约、伦敦。, # 参数描述具体化 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度的单位默认为摄氏度celsius。, } }, required: [location], # 指定必需参数 }, } } ]注意事项工具函数的纯文本化注意get_current_weather函数返回的是一个 JSON 字符串而不是 Python 字典。这是因为在后续步骤中我们需要将这个结果作为content字段必须是字符串传回给模型。这是一种常见的模式工具函数处理外部世界返回结构化的字符串数据通常是 JSON由模型来解读并生成自然语言。3.2 构建对话循环与工具调用逻辑核心逻辑在于一个循环维护对话历史每次将用户消息和工具定义发给模型检查模型是否要求调用工具如果是则执行工具并将结果追加到历史然后再次请求模型生成最终回答。def run_weather_agent(): 运行一个简单的天气查询 Agent。 # 初始化对话历史 messages [ {role: system, content: 你是一个友好的天气助手。请根据用户的需求使用工具查询天气并给出回答。如果用户的问题不涉及天气请礼貌告知。} ] print(天气助手已启动。输入‘退出’或‘quit’结束对话。) while True: # 1. 获取用户输入 user_input input(\n你) if user_input.lower() in [退出, quit, exit]: print(助手再见) break # 2. 将用户输入加入对话历史 messages.append({role: user, content: user_input}) # 3. 首次调用模型允许其选择工具 try: response openai.chat.completions.create( modelgpt-3.5-turbo, # 或 gpt-4 messagesmessages, toolstools, # 关键传入工具定义 tool_choiceauto, # “auto”表示由模型决定是否调用工具 ) except Exception as e: print(f调用API出错{e}) break # 4. 处理模型响应 response_message response.choices[0].message messages.append(response_message) # 将助手的响应可能包含工具调用也加入历史 # 5. 检查模型是否调用了工具 tool_calls response_message.tool_calls if tool_calls: print(f助手我需要查询天气信息...) # 可能存在多个工具调用并行这里我们循环处理 for tool_call in tool_calls: function_name tool_call.function.name function_args json.loads(tool_call.function.arguments) # 6. 执行对应的工具函数 if function_name get_current_weather: location function_args.get(location) unit function_args.get(unit, celsius) # 在实际应用中这里应该有更完善的错误处理 if not location: print(f错误未提供城市参数。) function_response json.dumps({error: Missing location parameter}) else: function_response get_current_weather(location, unit) else: function_response json.dumps({error: f未知工具{function_name}}) # 7. 将工具执行结果作为一条新消息追加到历史 messages.append({ role: tool, tool_call_id: tool_call.id, content: function_response, }) # 8. 第二次调用模型让它基于工具执行结果生成最终回答 second_response openai.chat.completions.create( modelgpt-3.5-turbo, messagesmessages, # 此时历史包含了工具执行结果 ) final_message second_response.choices[0].message messages.append(final_message) # 将最终回答也加入历史保持上下文完整 print(f助手{final_message.content}) else: # 模型没有调用工具直接输出回答 print(f助手{response_message.content})3.3 运行示例与过程解析运行上面的run_weather_agent()函数让我们看看一次完整的交互流程。天气助手已启动。输入‘退出’或‘quit’结束对话。 你上海今天天气怎么样 助手我需要查询天气信息... 助手上海今天天气晴朗气温28摄氏度湿度75%感觉会比较暖和。 你那北京呢用华氏度告诉我。 助手我需要查询天气信息... 助手北京今天的天气是多云气温大约是72华氏度对应22摄氏度湿度为60%。过程拆解用户输入“上海今天天气怎么样”模型第一次响应模型收到消息和工具定义。它分析问题识别出需要天气信息且城市是“上海”。于是它决定调用get_current_weather工具并生成一个tool_calls响应其中arguments为{location: 上海, unit: celsius}默认单位。此时它不生成最终答案。程序执行工具我们的代码解析出工具调用执行本地的get_current_weather(上海, celsius)函数得到模拟结果{temperature: 28, condition: 晴朗, humidity: 75}。回传结果程序将上述结果以role: tool的消息格式追加到对话历史。模型第二次响应模型看到工具执行返回的具体数据温度28晴朗湿度75结合用户最初的问题“上海今天天气怎么样”生成最终的自然语言回答“上海今天天气晴朗气温28摄氏度湿度75%感觉会比较暖和。”后续对话当用户问“那北京呢用华氏度告诉我。”时对话历史中已经包含了之前的全部交互。模型能理解“北京”指代地点“用华氏度”是新的单位要求。它再次发起工具调用参数为{location: 北京, unit: fahrenheit}程序执行后返回华氏度数据模型最终整合回答。实操心得对话历史的管理是关键这个简易示例中我们手动维护messages列表。在复杂 Agent 中对话历史管理Context Management是个大学问。你需要决定保留多少轮历史token 有限如何对历史进行总结压缩以及如何确保工具调用和结果被正确关联。一个常见的坑是忘记将tool角色的消息执行结果传回给模型导致模型“失忆”不知道工具执行是否成功。4. 进阶实战构建多工具、可规划的旅行规划 Agent单一工具的 Agent 只是个开始。真正的价值在于让 Agent 能自主规划、按顺序或并行使用多个工具来完成复杂目标。我们升级一下场景构建一个“旅行规划助手”它能调用多个工具查询天气、查询航班模拟、查询酒店模拟。4.1 设计工具集与系统提示词首先我们定义更丰富的工具集。为了模拟我们创建三个工具函数。# 模拟工具函数 def search_flights(departure: str, arrival: str, date: str) - str: 模拟查询航班信息。 # 模拟数据 flights [ {airline: 东方航空, flight_no: MU5101, departure_time: 08:00, arrival_time: 10:15, price: 1200}, {airline: 中国国航, flight_no: CA1501, departure_time: 14:30, arrival_time: 16:45, price: 1100}, ] return json.dumps({flights: flights, query: {departure: departure, arrival: arrival, date: date}}) def search_hotels(location: str, check_in: str, check_out: str) - str: 模拟查询酒店信息。 hotels [ {name: 西湖宾馆, star: 4, price_per_night: 600, rating: 4.5}, {name: 杭州国际青年旅舍, star: 2, price_per_night: 150, rating: 4.2}, ] return json.dumps({hotels: hotels, query: {location: location, check_in: check_in, check_out: check_out}}) # get_current_weather 函数沿用之前的 # 定义多工具 Schema travel_tools [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气情况用于旅行前的天气参考。, parameters: { type: object, properties: { location: {type: string, description: 城市名}, }, required: [location], }, } }, { type: function, function: { name: search_flights, description: 查询指定日期、出发地和目的地的航班信息。, parameters: { type: object, properties: { departure: {type: string, description: 出发城市机场代码或名称如‘北京’、‘PEK’。}, arrival: {type: string, description: 到达城市机场代码或名称如‘杭州’、‘HGH’。}, date: {type: string, description: 出发日期格式 YYYY-MM-DD。}, }, required: [departure, arrival, date], }, } }, { type: function, function: { name: search_hotels, description: 查询指定城市、入住和离店日期的酒店信息。, parameters: { type: object, properties: { location: {type: string, description: 酒店所在城市}, check_in: {type: string, description: 入住日期格式 YYYY-MM-DD}, check_out: {type: string, description: 离店日期格式 YYYY-MM-DD}, }, required: [location, check_in, check_out], }, } } ]接下来设计一个强大的系统提示词System Prompt这是 Agent 的“人格”和“行为准则”。一个好的系统提示词能显著提升 Agent 的规划能力和可靠性。system_prompt 你是一个专业的旅行规划助手。你的目标是帮助用户规划一次完整的旅行。 请遵循以下步骤和原则 1. **明确需求**首先与用户沟通明确旅行的核心要素目的地、出发地、旅行日期、人数、预算、兴趣点等。如果信息不全主动询问。 2. **分步规划**规划通常按逻辑顺序进行先确定目的地和日期 - 查询目的地天气作为参考 - 查询往返交通航班/高铁- 查询住宿。 3. **善用工具**你有三个工具get_current_weather、search_flights、search_hotels。根据当前规划步骤选择合适的工具。一次可以调用一个或多个工具。 4. **信息整合**获得工具返回的数据后以清晰、有条理的方式向用户汇报并可以给出初步建议如“上午的航班价格更优”、“这家酒店评分很高”。 5. **持续交互**根据用户的反馈调整规划或进行下一步。例如用户对某个航班不满意你可以重新查询其他航班。 记住你是助手最终决定权在用户。保持友好、专业、乐于助人。 4.2 实现带规划逻辑的 Agent 引擎现在我们实现一个更健壮的 Agent 循环它能处理多轮对话、多次工具调用并整合系统提示词。def run_travel_agent(): messages [{role: system, content: system_prompt}] print( 旅行规划助手启动 ) print(我可以帮你查询天气、航班和酒店信息来规划旅行。请告诉我你的需求。) while True: user_input input(\n你) if user_input.lower() in [退出, quit]: break messages.append({role: user, content: user_input}) # 我们允许模型在单轮对话中多次调用工具通过循环 # 设置一个最大轮次防止死循环 max_tool_rounds 5 for round_num in range(max_tool_rounds): # 调用模型 response openai.chat.completions.create( modelgpt-3.5-turbo, messagesmessages, toolstravel_tools, tool_choiceauto, ) response_message response.choices[0].message messages.append(response_message) # 检查是否有工具调用 if not response_message.tool_calls: # 没有工具调用直接输出并跳出工具调用循环 print(f助手{response_message.content}) break # 处理工具调用 print(f助手[正在查询信息...]) for tool_call in response_message.tool_calls: func_name tool_call.function.name func_args json.loads(tool_call.function.arguments) # 根据工具名分派执行 if func_name get_current_weather: result get_current_weather(**func_args) elif func_name search_flights: result search_flights(**func_args) elif func_name search_hotels: result search_hotels(**func_args) else: result json.dumps({error: fFunction {func_name} not found.}) # 将结果追加到消息历史 messages.append({ role: tool, tool_call_id: tool_call.id, content: result, }) # 如果这是最后一轮工具调用循环需要再请求一次模型生成最终回答 if round_num max_tool_rounds - 1: final_response openai.chat.completions.create( modelgpt-3.5-turbo, messagesmessages, ) final_message final_response.choices[0].message messages.append(final_message) print(f助手{final_message.content}) break # 否则继续循环让模型基于新的工具结果决定下一步动作 else: # 如果循环正常结束非break说明达到了最大工具调用轮次 print(助手查询步骤较多我们稍后再继续。)4.3 复杂场景测试与 Agent 行为分析让我们运行这个 Agent看它如何处理一个多步骤的复杂请求。 旅行规划助手启动 我可以帮你查询天气、航班和酒店信息来规划旅行。请告诉我你的需求。 你我想下周末从北京去杭州玩两天。 助手[正在查询信息...] 助手好的我来帮你规划。首先我们需要明确一下具体日期。“下周末”是指具体哪两天呢比如是6月15-16日周六日吗另外你们有几个人出行预算大概是多少这样我可以为你查找更合适的航班和酒店。 你就一个人预算一般吧。日期是6月15到16号。 助手[正在查询信息...] 助手[正在查询信息...] 助手好的基于你的需求北京到杭州6月15-16日一人我为你查询了相关信息 1. **天气参考**杭州当前的天气情况是【模拟数据】出行前建议再确认临近日期的预报。 2. **航班信息**6月15日出发 * 东方航空 MU5101 08:00 - 10:15 价格 1200元 * 中国国航 CA1501 14:30 - 16:45 价格 1100元 国航的航班下午出发价格稍低。如果你希望有更多白天时间在杭州可以选择早上的航班。 3. **酒店信息**6月15日入住16日离店 * 西湖宾馆 四星级 600元/晚 评分4.5 * 杭州国际青年旅舍 二星级 150元/晚 评分4.2 西湖宾馆位于西湖附近位置和设施更好青年旅舍则性价比极高。 这是一个初步方案。你对航班时间或酒店类型有偏好吗我可以进一步筛选或查询其他选项。行为分析需求澄清模型首先没有盲目调用工具而是根据系统提示词识别出“下周末”是模糊信息主动询问具体日期、人数和预算。这体现了 Agent 的“规划”和“交互”能力。并行工具调用在用户补充信息后模型在单次响应中同时发起了对get_current_weather和search_flights的调用注意日志中出现了两次[正在查询信息...]。这是因为它判断出天气和航班是相对独立且可并行获取的信息。这展示了 Function Calling 支持并行工具调用的能力可以提升效率。信息整合与建议在获得所有工具结果后模型生成了一份结构清晰的汇总报告并基于数据给出了初步建议如对比航班时间、酒店特点。这体现了 LLM 在信息整合与语言生成方面的核心价值。持续交互最后Agent 将决定权交给用户并邀请进一步反馈形成了一个完整的服务闭环。避坑指南工具调用的“幻觉”与参数校验模型有时会产生“幻觉”即调用一个不存在的工具或生成不符合参数 Schema 的arguments。例如日期格式要求YYYY-MM-DD模型可能输出“next Saturday”。必须在执行工具前进行严格的参数校验。我们的示例中直接json.loads和**func_args传递在生产环境中是危险的。应该先验证参数类型、格式、枚举值对缺失或错误的参数提供默认值或抛出清晰错误并将错误信息通过tool角色消息返回给模型让它有机会纠正。5. 生产级考量与最佳实践将一个小 demo 变成稳定可用的生产级 Agent还需要跨越很多鸿沟。以下是几个关键点的深度解析。5.1 工具设计的艺术粒度、描述与错误处理工具的设计质量直接决定 Agent 的能力上限。工具粒度是设计一个“万能”的search工具还是拆分成search_flights、search_hotels、search_attractions等多个工具更细的粒度通常更好。细粒度工具功能单一描述更精准模型更容易理解和准确调用。一个“万能搜索”工具需要极其复杂的描述和参数模型很难掌握。当然也要避免过度拆分导致工具数量爆炸。描述即契约工具的description和参数的description是你与模型签订的“契约”。要用最清晰、无歧义的语言书写。好的描述示例“查询从departure_city飞往arrival_city在departure_date日期的直飞航班经济舱价格。” 差的描述“搜索航班。”错误处理与鲁棒性工具函数内部必须有完善的错误处理网络超时、API 限流、无效输入等。当错误发生时不应直接崩溃而应返回结构化的错误信息例如{error: API_TIMEOUT, message: 航班查询服务暂时无响应请稍后再试。}。并将此错误信息通过tool角色返回给模型模型可以据此向用户解释或尝试其他方案。5.2 对话历史与上下文管理OpenAI 的 GPT 模型有上下文长度限制如 4K、8K、16K、128K tokens。长对话中历史消息会迅速耗尽额度。选择性记忆不是所有历史都需要原封不动地传递。可以设计策略只保留最近 N 轮对话或总结之前的长期记忆。总结与压缩一种高级技巧是让模型自身对过长的历史进行总结。例如在历史达到一定长度后插入一条系统消息“请将上述对话总结成一个简洁的段落保留用户的核心需求和已完成的行动要点。”然后将这个总结作为新的“压缩后的历史”开头替换掉冗长的原始消息。关键信息提取对于 Agent 执行用户的核心约束如预算、日期、偏好至关重要。可以主动将这些信息从历史中提取出来作为系统提示词的一部分或单独维护确保在长对话中不丢失。5.3 超越基础 Function Calling智能规划与工作流我们之前的 Agent 是“反应式”的根据当前对话状态决定下一步动作。更强大的 Agent 需要“前瞻性”规划。任务分解Task Decomposition对于“帮我规划一个包含交通、住宿、景点和餐厅的七日欧洲游”这样的复杂请求需要先将其分解为子任务。这可以通过让一个“规划器”LLM或同一个 LLM 的特定提示来完成生成一个任务列表然后由“执行器”LLM 按顺序或并行地调用工具完成每个子任务。ReAct Function Calling 结合你可以结合 ReAct 的链式推理和 Function Calling 的稳定性。让模型以“Thought: 我需要先确定目的地和日期。用户已提供... 接下来我应该调用天气工具了解当地气候。Action: 调用get_current_weather...” 的方式思考但“Action”部分输出的是标准的 Function Calling 结构。这样既有了可解释的推理链又有了稳定的工具调用接口。工作流引擎对于极其复杂、有固定流程的业务如客服工单处理、电商退货可以引入外部的工作流引擎如状态机。LLM Agent 作为“决策节点”根据当前状态和用户输入决定工作流下一步走向哪个节点每个节点关联特定的工具或操作。5.4 成本、延迟与性能优化频繁调用 LLM 和外部工具会产生成本和延迟。缓存对频繁且结果变化不大的查询如城市信息、产品目录进行缓存。可以在调用工具前先检查缓存。批量处理如果模型在一次响应中请求多个独立工具调用如同时查天气和汇率应尽可能并行执行这些工具调用减少总体延迟。模型选型对于简单的工具调用决策可以使用更小、更快的模型如gpt-3.5-turbo。对于需要复杂规划、推理和总结的步骤再使用gpt-4。这种混合使用策略可以优化成本和速度。流式输出Streaming对于最终给用户的答案如果生成时间较长可以使用流式输出让用户先看到部分内容提升体验。从理解 LLM 与 Agent 的根本区别到掌握 Function Calling 这一核心桥梁技术再到亲手构建从简单到复杂的 Agent最后思考生产环境中的挑战与优化这条路径清晰地勾勒出了 AI 应用开发从“玩具”到“工具”的演进方向。Agent 不是 LLM 的简单包装而是为其装上了感知世界的传感器和改造世界的手脚。而 Function Calling就是让大脑能精确控制手脚的神经协议。