1. 项目概述从“单打独斗”到“团队协作”的智能体进化如果你最近在折腾大语言模型应用尤其是想让它不只是个“聊天高手”而是能真正帮你干点实事——比如查查天气、订个餐、分析下数据那你肯定绕不开两个词ReAct和Function Calling。这俩不是什么新框架而是两种让大模型LLM学会“动手”的核心范式。你可以把它们理解成给一个超级聪明但“四肢不勤”的大脑配上的两套不同的“手脚”和“工具使用说明书”。简单来说ReAct更像是一个“思考型助手”。它让模型在面对问题时先“想一想”Reason再“动动手”Act调用外部工具比如搜索引擎、计算器、数据库API去获取信息然后根据新信息继续思考如此循环直到解决问题。整个过程是透明的你能看到它的思考链就像看一个人写解题步骤。而Function Calling则更像一个“指令接收器”。你提前定义好一堆工具函数比如get_weather(city)然后直接问模型“北京天气怎么样”。模型不会输出大段思考而是直接返回一个结构化的调用请求{“name”: “get_weather”, “arguments”: {“city”: “北京”}}。你的程序拿到这个请求就去执行真正的函数并把结果返回给用户或模型进行下一步处理。为什么这很重要因为纯聊天模型的知识是静态的、可能过时的也没有执行能力。ReAct和Function Calling打破了这堵墙让LLM能够与实时、动态的外部世界互动成为真正能处理复杂任务的智能体Agent。当前火热的AI Agent开发无论是基于LangChain、LangGraph还是其他框架其核心的“工具调用”能力都建立在这两种范式之上。理解它们就是理解了智能体为何能“自主”工作的第一性原理。2. 核心范式深度对比ReAct vs. Function Calling虽然目标一致——让LLM使用工具但ReAct和Function Calling在实现哲学、流程和适用场景上有着根本性的不同。选择哪一种往往决定了你Agent的“性格”和“能力边界”。2.1 ReAct范式深思熟虑的“规划-执行”循环ReAct的核心思想是“链式思考与行动”。它要求模型将推理Reasoning和行动Acting交织在一起。2.1.1 工作流程拆解一个标准的ReAct循环通常如下思考Thought模型分析当前状态包括用户问题、已有的观察结果规划下一步该做什么。例如“用户想知道珠穆朗玛峰的高度。我需要查找一个可靠的数据源比如维基百科API。”行动Action模型根据上一步的思考决定调用哪个工具并生成符合工具输入格式的调用指令。例如Search: 珠穆朗玛峰 海拔观察Observation系统执行工具调用如执行搜索并将返回的结果如“海拔8848.86米”作为观察反馈给模型。循环模型基于新的观察再次进入“思考”阶段判断信息是否足够回答用户若不够则继续下一轮“行动”。最终模型汇总所有观察生成给用户的最终答案。2.1.2 优势与适用场景透明度高完整的“Thought-Action-Observation”轨迹就像程序的日志非常适合调试和解释Agent的决策过程。你可以清楚地看到它为什么失败比如思考方向错了。动态规划能力强由于每一步行动都基于上一步的观察和新的思考ReAct Agent非常适合处理需要多步、非线性规划的复杂任务。例如“帮我比较一下Python和Go在Web后端开发上的优劣并给出学习建议。” 这种任务可能需要先搜索各自特点再查找性能基准最后结合社区活跃度综合判断路径不是固定的。对工具描述依赖相对较低模型通过“思考”来理解何时使用工具有时即使工具描述不那么精确模型也能通过上下文推断。2.1.3 劣势与挑战延迟高每一步都需要模型生成一次文本Thought和Action导致调用次数多、总体响应慢。成本高更多的LLM调用意味着更高的API费用。稳定性挑战模型生成的“Action”格式必须严格匹配工具定义的输入格式否则解析会失败。需要精心设计提示词Prompt来约束输出格式或使用输出解析器。可能陷入循环如果模型思考陷入死胡同可能会在“思考-行动”中无限循环需要设置最大步数限制。2.2 Function Calling范式精准高效的“函数调度”Function Calling或Tool Calling采取了不同的策略。它把“思考”过程隐藏起来让模型直接输出一个结构化的函数调用请求。2.2.1 工作流程拆解定义工具Functions开发者预先定义好一系列工具每个工具都是一个函数有明确的名称、描述和参数参数类型、是否必需等。例如{ “name”: “get_current_weather” “description”: “获取指定城市的当前天气” “parameters”: { “type”: “object” “properties”: { “location”: { “type”: “string” “description”: “城市名如‘北京’” }, “unit”: { “type”: “string” “enum”: [“celsius” “fahrenheit”] “default”: “celsius” } }, “required”: [“location”] } }请求与响应将用户查询和定义好的工具列表一起发送给LLM。LLM不会生成自然语言中间步骤而是直接返回一个或多个结构化的函数调用请求。用户输入“旧金山今天天气如何”LLM响应{“name”: “get_current_weather” “arguments”: {“location”: “San Francisco” “unit”: “celsius”}}执行与回复你的程序解析这个JSON调用本地或远程的get_current_weather函数获取真实天气数据。然后你可以选择直接将结果返回给用户。将结果作为新的上下文再次调用LLM让其生成一个友好、归纳性的回答“旧金山今天晴气温22摄氏度……”。2.2.2 优势与适用场景高效、低延迟一次LLM调用就能决定要使用的工具及其参数减少了交互轮次速度更快。成本更低调用次数少自然费用更低。稳定可靠输出是结构化JSON易于程序解析几乎不会出现格式错误。主流API如OpenAI Anthropic都原生支持。适合明确、单一的任务对于“查天气”、“订日历”、“计算器”这类目标明确、工具匹配直接的任务它是最高效的选择。2.2.3 劣势与挑战黑盒性你失去了模型内部的推理过程只知道它决定调用哪个函数但不知道“为什么”选这个。调试时如果函数调用不合理追溯原因更困难。复杂任务规划能力弱对于需要多个工具动态组合、且有复杂依赖关系的任务单次Function Calling可能不够。虽然可以设计“规划函数”或依赖框架进行多轮但其本质仍是“一次规划多次执行”灵活性不如ReAct的逐步推理。严重依赖工具描述模型完全依靠你提供的函数名称和描述来决定是否调用。描述不准确或不清晰会导致模型无法正确匹配用户意图。2.3 范式选择决策指南如何选择可以遵循这个简单的决策树任务是否步骤清晰、工具明确如果是优先考虑Function Calling。例如数据查询、单位转换、发送邮件。任务是否需要复杂推理、探索或动态规划如果是ReAct更合适。例如研究分析、复杂问题排查、创意性任务规划。是否需要完整的可解释性如果需要审计或理解Agent的每一步决策选ReAct。是否对延迟和成本极度敏感如果是选Function Calling。是否可以兼得当然可以现代Agent框架如LangGraph允许你混合使用。你可以用Function Calling快速处理标准化子任务而在顶层的决策和规划层采用ReAct式的推理。这就像团队中既有高效执行指令的专员也有负责整体策划的经理。注意这两种范式并非互斥。在实际的复杂Agent系统中它们常常协同工作。例如一个基于ReAct的Agent其“Action”步骤中调用的具体工具其接口可能就是通过Function Calling方式与LLM交互来确定的。3. 核心实现与框架应用实战理解了理论我们来看看如何落地。这里不会只讲概念我会结合主流框架分享具体的实现套路和踩坑经验。3.1 基于LangChain实现ReAct AgentLangChain的Agent模块封装了ReAct范式。最经典的是使用create_react_agent函数。3.1.1 基础搭建步骤from langchain import hub from langchain.agents import create_react_agent AgentExecutor from langchain_community.tools import Tool from langchain_openai import ChatOpenAI # 1. 定义工具 def search_api(query: str) - str: # 模拟一个搜索工具 return f“根据查询‘{query}’找到的结果是XXX。” search_tool Tool( name“Search” funcsearch_api description“用于回答关于当前事件或特定信息的问题。输入应该是一个搜索查询词。” ) def calculator(expression: str) - str: # 极度简化实际应用请使用安全评估 try: return str(eval(expression)) except: return “计算错误” calc_tool Tool( name“Calculator” funccalculator description“用于执行数学计算。输入是一个数学表达式如‘3 * 5 2’。” ) tools [search_tool calc_tool] # 2. 获取ReAct提示词模板LangChain Hub上有官方版本 prompt hub.pull(“hwchase17/react”) # 3. 初始化LLM llm ChatOpenAI(model“gpt-4” temperature0) # 4. 创建Agent和Executor agent create_react_agent(llm tools prompt) agent_executor AgentExecutor(agentagent toolstools verboseTrue handle_parsing_errorsTrue) # 5. 运行 result agent_executor.invoke({“input”: “特斯拉当前股价是多少如果是100股总价值多少美元”}) print(result[“output”])3.1.2 关键配置与避坑指南提示词Prompt是灵魂hwchase17/react这个模板经过了大量优化定义了严格的Thought/Action/Action Input/Observation格式。不要轻易大幅修改其结构否则容易破坏输出解析。handle_parsing_errorsTrue这个参数至关重要。当模型输出格式不符合预期时它会尝试修复而不是直接崩溃。在实际生产中你还需要更健壮的异常处理。verboseTrue调试时打开可以像看“直播”一样看到Agent的思考链对于理解其行为和调试Prompt无比有用。工具描述Description要精准这是模型选择工具的主要依据。描述应清晰说明工具的用途、输入格式和输出示例。例如“计算器”的描述比“进行数学运算”要好得多。控制循环与超时AgentExecutor有max_iterations和max_execution_time参数务必设置防止无限循环或长时间运行。3.2 利用原生API实现Function Calling以OpenAI API为例Function Calling是其原生特性无需额外框架。3.2.1 基础调用示例import openai from typing import List Dict Any import json # 1. 定义函数工具列表 functions [ { “name”: “get_current_weather” “description”: “获取当前天气” “parameters”: { “type”: “object” “properties”: { “location”: {“type”: “string” “description”: “城市或地区如‘北京’或‘San Francisco CA’”} “unit”: {“type”: “string” “enum”: [“celsius” “fahrenheit”] “default”: “celsius”} }, “required”: [“location”] } }, { “name”: “currency_converter” “description”: “货币转换” “parameters”: { “type”: “object” “properties”: { “amount”: {“type”: “number” “description”: “金额”} “from_currency”: {“type”: “string” “description”: “源货币代码如USD”} “to_currency”: {“type”: “string” “description”: “目标货币代码如CNY”} }, “required”: [“amount” “from_currency” “to_currency”] } } ] # 2. 模拟的工具执行函数 def execute_function(function_name: str arguments: Dict) - str: if function_name “get_current_weather”: # 模拟调用真实天气API return json.dumps({“location”: arguments[“location”] “temperature”: “22” “unit”: arguments.get(“unit” “celsius”) “condition”: “晴朗”}) elif function_name “currency_converter”: # 模拟调用汇率API return json.dumps({“converted_amount”: arguments[“amount”] * 7.2 “currency”: arguments[“to_currency”]}) else: return json.dumps({“error”: “未知函数”}) # 3. 主循环 def run_conversation(user_input: str): messages [{“role”: “user” “content”: user_input}] # 第一轮调用让模型决定是否调用函数、调用哪个 response openai.chat.completions.create( model“gpt-4” messagesmessages functionsfunctions function_call“auto” # “auto”让模型决定 “none”不调用 或指定{“name”: “xxx”}强制调用 ) response_message response.choices[0].message # 检查模型是否想调用函数 if response_message.function_call: # 4. 解析并执行函数 function_name response_message.function_call.name function_args json.loads(response_message.function_call.arguments) print(f“模型决定调用函数 {function_name} 参数 {function_args}”) function_response execute_function(function_name function_args) # 5. 将函数执行结果作为新的上下文消息发送给模型让它生成面向用户的回答 messages.append(response_message) # 添加模型的上一条消息包含函数调用 messages.append({ “role”: “function” “name”: function_name “content”: function_response }) second_response openai.chat.completions.create( model“gpt-4” messagesmessages ) return second_response.choices[0].message.content else: # 模型认为无需调用函数直接回答 return response_message.content # 测试 print(run_conversation(“波士顿现在多少度”)) print(run_conversation(“100美元换成人民币是多少”)) print(run_conversation(“讲个笑话”)) # 此问题无需调用函数3.2.2 实战技巧与深度解析function_call: “auto”这是最常用的设置。模型会根据对话上下文和函数描述自主决定是否需要调用函数。你也可以强制指定某个函数{“name”: “get_weather”}或禁止调用“none”。函数描述是命门description和parameters里的description必须清晰、无歧义。模型完全依赖这些描述来做匹配。用自然语言描述清楚输入是什么、输出大概是什么。“function”角色消息这是OpenAI定义的特定角色用于向模型传递函数执行结果。必须在消息列表中准确添加否则模型会丢失这部分关键上下文。处理多个函数调用一次响应中模型可能会决定并行调用多个函数parallel_function_calls。你的代码需要能处理一个响应中包含多个function_call对象的情况。错误处理函数执行可能失败网络超时、参数无效。最佳实践是将错误信息也通过“function”角色消息返回给模型让它有机会向用户解释或尝试其他方案而不是直接向用户抛出一个技术错误。3.3 进阶架构使用LangGraph构建可控工作流当你的Agent需要处理包含分支、循环、状态管理的复杂工作流时基础的AgentExecutor可能显得力不从心。这时LangGraph就派上用场了。它用“图”的概念来定义Agent的执行流程节点Node是处理步骤边Edge决定下一步走向。3.3.1 为什么需要LangGraph想象一个客服Agent用户说“我想订机票”。这个任务可能包含1询问目的地/时间条件分支2查询航班工具调用3询问舱位选择分支4确认订单工具调用5如果支付失败重试或取消循环。用ReAct硬编码提示词来管理这个状态机非常痛苦。LangGraph让你能可视化、可编程地控制这个流程。3.3.2 构建一个简单的决策Agentfrom typing import TypedDict Annotated List from langgraph.graph import StateGraph END from langchain_core.messages import HumanMessage from langchain_openai import ChatOpenAI import operator # 1. 定义状态State。这是在整个图中传递的数据结构。 class AgentState(TypedDict): messages: Annotated[List operator.add] # 消息列表会自动追加 needs_clarification: bool # 是否需要澄清 flight_info: dict # 存储查询到的航班信息 # 2. 定义各个节点函数 def receive_input(state: AgentState): 接收用户输入 # 这里可以从state[‘messages’]中取出最新用户消息 # 简单起见我们假设输入已存在 print(“节点收到用户输入”) return {“needs_clarification”: False} # 初始化状态 def decide_action(state: AgentState): 决策节点判断是否需要澄清信息 llm ChatOpenAI(model“gpt-4” temperature0) # 基于对话历史让LLM判断信息是否完整 prompt f“”” 当前对话 {state[‘messages’]} 用户想查询航班。请判断信息是否完整需要目的地、出发地、时间。 如果完整回复‘proceed’如果不完整回复‘clarify’。 “”” decision llm.invoke(prompt).content.strip().lower() if “clarify” in decision: return {“needs_clarification”: True} else: return {“needs_clarification”: False} def clarify_details(state: AgentState): 澄清节点询问缺失信息 llm ChatOpenAI(model“gpt-4” temperature0) # 生成一个澄清问题 clarification_msg llm.invoke(“生成一个礼貌的问题询问用户航班的目的地、出发地和日期。”).content # 将问题添加到消息历史 new_msg HumanMessage(contentclarification_msg) return {“messages”: [new_msg]} def search_flights(state: AgentState): 搜索节点调用航班搜索工具 # 模拟工具调用 print(“节点正在搜索航班...”) # 这里应解析state[‘messages’]中的关键信息调用真实API flight_data {“flight”: “CA1234” “price”: 1500} # 模拟数据 return {“flight_info”: flight_data} def finalize_response(state: AgentState): 最终响应节点整理信息并回复 info state.get(“flight_info” {}) response f“为您找到航班{info.get(‘flight’ ‘N/A’)} 价格{info.get(‘price’ ‘N/A’)}元。” # 将最终回复加入消息历史 final_msg HumanMessage(contentresponse) return {“messages”: [final_msg]} # 3. 构建图 workflow StateGraph(AgentState) # 添加节点 workflow.add_node(“receive” receive_input) workflow.add_node(“decide” decide_action) workflow.add_node(“clarify” clarify_details) workflow.add_node(“search” search_flights) workflow.add_node(“finalize” finalize_response) # 设置入口点 workflow.set_entry_point(“receive”) # 添加边定义流程逻辑 workflow.add_edge(“receive” “decide”) # 根据决策节点的结果决定下一步走向 workflow.add_conditional_edges( “decide” # 这个函数根据state返回下一个节点名 lambda x: “clarify” if x[“needs_clarification”] else “search” {“clarify”: “clarify” “search”: “search”} ) workflow.add_edge(“clarify” “decide”) # 澄清后再次回到决策节点判断 workflow.add_edge(“search” “finalize”) workflow.add_edge(“finalize” END) # 结束 # 编译图 app workflow.compile() # 4. 运行 initial_state {“messages”: [HumanMessage(content“我想订去上海的机票”)], “needs_clarification”: False “flight_info”: {}} result app.invoke(initial_state) print(“最终消息” result[“messages”][-1].content)3.3.3 LangGraph核心优势与心法显式状态管理所有数据都在State对象中流动清晰可控避免了全局变量或复杂闭包。灵活的路由控制add_conditional_edges让你能基于LLM的判断或业务逻辑轻松实现分支、循环这是构建复杂Agent的核心。可调试性与可观测性图的每个节点都是独立的函数易于单元测试。你可以记录每个节点的输入输出对整个工作流进行监控和调试。与ReAct/Function Calling结合图中的任何一个节点都可以是一个完整的ReAct Agent或一次Function Calling。例如search_flights节点内部可以封装一个使用Function Calling调用航班API的LLM交互。实操心得对于简单、线性的任务直接用LangChain AgentExecutor更快捷。但当你的业务逻辑涉及“如果...那么...”、“重复直到...”时尽早引入LangGraph这类工作流引擎。先在白板上画出状态图再编码会事半功倍。另外将复杂的工具调用如需要多步ReAct封装成一个独立的“工具节点”可以保持图的清晰度。4. 避坑指南与性能优化实战纸上得来终觉浅绝知此事要躬行。下面这些坑都是我趟过雷的。4.1 提示词工程不只是写描述工具描述的黄金法则为Function Calling定义工具时描述要采用“动词开头宾语输入输出说明”的格式。例如差“天气工具”中“获取天气”优“获取指定城市当前的天气情况。输入参数‘location’应为城市名称字符串例如‘北京’或‘New York’。返回该城市的温度、天气状况和湿度。”好的描述能极大提升模型匹配的准确率。为ReAct设定明确边界在ReAct的Prompt中一定要明确告诉模型可用的工具列表、每个工具的精确使用格式以及最重要的停止条件。例如“当你拥有足够信息给出最终答案时你必须以 ‘Final Answer‘ 开头输出答案并停止。” 防止它无休止地思考下去。少样本示例Few-Shot威力巨大在Prompt中提供1-2个完整的、正确的ReAct轨迹示例Thought/Action/Observation/Final Answer对于引导模型遵循格式和理解任务意图效果比任何抽象描述都好。4.2 错误处理与稳定性解析失败是常态无论是ReAct的输出格式解析还是Function Calling的JSON解析都可能失败。必须在代码中包裹try...except。对于ReAct可以设置handle_parsing_errorsTrue并准备一个降级策略例如提示模型重试或转为简单对话。工具调用超时与降级外部API可能失败。为每个工具调用设置超时如timeout10s并准备默认返回值或友好的错误信息通过观察Observation或函数响应Function Response反馈给模型让它决定下一步。验证LLM输出对于关键操作如确认支付、删除数据不要完全信任LLM的输出。应该在执行前增加一层业务逻辑验证或者采用“确认-执行”两步走策略先让LLM生成待执行命令经用户或系统确认后再执行。4.3 性能与成本优化缓存是利器对于频繁查询且结果变化不快的工具如某些百科查询、汇率缓存引入缓存机制如Redis。可以将“用户问题工具参数”哈希后作为键缓存工具返回结果。这能显著减少对外部API的调用和LLM的重复推理。精简上下文ReAct的每一步都会将完整的思考轨迹追加到上下文。随着步数增加令牌数会爆炸。需要定期清理或总结过长的历史。对于Function Calling也要注意每次传入的对话历史长度。模型选型对于工具调用中的“路由”或“规划”任务决定用什么工具使用速度快、成本低的模型如gpt-3.5-turbo可能就足够了。对于需要深度推理或生成最终复杂答案的任务再用更强大的模型如gpt-4。这种混合模型策略能有效平衡效果和成本。设置预算与熔断为Agent的运行设置最大迭代次数max_iterations和最大令牌消耗预算。防止在极端情况下因逻辑错误导致无限循环产生天价账单。4.4 安全性与可靠性工具权限隔离不是所有工具都应该被所有问题触发。实现一个工具权限过滤器。根据用户身份、会话上下文或问题内容动态过滤掉当前可用的工具列表。例如普通用户不能调用“删除数据库”工具。防范Prompt注入用户输入可能包含恶意指令试图让模型绕过你的系统提示词。对用户输入进行基本的清洗和检查避免其直接拼接进系统指令的关键部分。在关键工具调用前可以增加一个“安全审查”节点用另一个LLM调用或规则引擎来判断该操作是否安全。人工审核环Human-in-the-loop对于高风险操作如发送邮件、生成重要内容设计流程让Agent生成待执行动作后暂停等待用户明确确认后再执行。这在LangGraph中很容易实现只需增加一个等待用户输入的节点即可。构建一个健壮、高效的Agent系统远不止是拼接LLM和工具。它涉及到软件工程、提示词工程、运维监控的方方面面。从ReAct和Function Calling这两个核心范式出发理解其优劣并在合适的场景选用或混合它们是你迈向高级Agent开发者的坚实第一步。记住没有银弹只有对问题和工具的深刻理解才能设计出真正解决问题的智能体。