我自己做Agent开发也有两年多了接触到ReAct这个范式的时候第一反应其实是这不就是一个for循环里套两次大模型调用吗。后来真正把它放到生产环境里才意识到事情没那么简单。很多时候你写Demo完全没问题但一接真实工具、一跑真实流量各种意外就冒出来了。这篇就想把ReAct Agent从概念到落地完整聊一遍包括推理-行动循环怎么设计、工具怎么配、生产环境需要补哪些组件、会遇到哪些坑以及我实测下来比较稳的处理方式。适合正在做Agent开发的工程师也适合准备面试想系统理解Agent范式的同学参考。1. ReAct Agent的核心机制从想到做再到看的闭环1.1 为什么只有思考不够用CoT到ReAct的演进逻辑先得说清楚ReAct这个词不是React.js那个前端框架。虽然拼写一样但这里指的是论文ReAct: Synergizing Reasoning and Acting in Language Models里提出的一种Agent范式核心思想是把**推理Reasoning和行动Acting**交替执行让模型一边想、一边做、一边观察结果再基于观察继续想。在ReAct出现之前主流的方案是CoTChain of Thought思维链。CoT的思路很直接你让模型在给出答案之前先把推理步骤写出来Lets think step by step这样复杂问题的准确率会明显提升。但CoT有个先天短板——它的推理过程是封闭的模型基于的是训练时学到的静态知识。如果问题需要查实时数据比如当前这个订单派送到哪了或者需要操作外部系统比如把这张工单的状态改成已处理CoT只能凭记忆编编错了你也很难发现。ReAct解决的就是这个封闭推理的问题。它把决策过程拆成交替出现的多个步骤Thought思考模型描述当前怎么理解问题、下一步打算怎么做Action行动模型从预定义的工具列表里选择某个工具并传入参数Observation观察系统执行工具后返回的结果喂回给模型这三个字段周而复始直到模型认为已经拿到了足够信息输出Final Answer最终答案。这个设计和人解决问题的思路很像。你订了个外卖发现超时了你不会只在脑子里推演可能堵车了吧而是会打开App看一眼骑手位置行动看到位置显示还在两公里外观察再判断还要等一阵先找客服问问下一个思考。没有行动和观察的纯思考放在真实环境里基本等于闭着眼猜。从实现的角度看CoT是一次性生成ReAct是多次迭代生成每一轮模型都会看到上一轮工具的真实返回。这个差异决定了ReAct能做的任务边界远大于CoT查询类、操作类、多步骤决策类只要你能提供工具它就能干。1.2 一次完整的ReAct循环是怎么跑起来的理解了概念再看机制。一次标准的ReAct循环用文字描述大概是这样的用户提问订单OD20241001现在到哪了帮我催促一下。模型第一轮输出Thought: 用户想知道订单物流状态我需要先查询订单信息再查物流轨迹。我手上有query_order和query_logistics两个工具先查订单编号对应的物流单号。 Action: query_order Action Input: {order_id: OD20241001}系统执行工具返回Observation: {logistics_no: SF1234567890, status: shipping, carrier: SF}模型拿到这个结果继续推理Thought: 已经拿到物流单号也确认订单状态是运输中。接下来查一下这个物流单号的实时轨迹。 Action: query_logistics Action Input: {logistics_no: SF1234567890}返回轨迹数据后模型再做一轮思考这时候如果判断信息足够就切到收尾状态Thought: 查到了物流轨迹包裹已经到达用户所在城市的分拨中心但配送员还没接单。用户要求催促我应该调用催单工具。 Action: urge_delivery Action Input: {logistics_no: SF1234567890}工具执行成功返回已创建催单任务。模型最后输出Thought: 催单任务创建成功我已经掌握了足够信息来回答用户。 Final Answer: 您的订单OD20241001目前已经到达您所在城市的分拨中心预计今天晚些时候会安排配送。我已为您发起催单快递员接单后您会收到短信通知。这个过程看起来很顺但注意几个容易被忽略的细节每一轮的Thought/Action/Observation都是完整拼接到上下文里的下一轮模型调用时输入是系统提示词 全部历史消息 最新观察结果。这是ReAct循环的本质——模型不是没记忆而是记忆全靠拼接。Action Input必须是结构化的尤其当你用Function Calling模式时工具参数的格式由模型生成系统负责解析校验。如果格式乱掉整个循环就会卡住。循环必须设置终止条件不能允许模型无限循环下去。一般有两种收口方式一是模型主动输出Final Answer二是系统侧强制设置最大迭代次数max_iterations我一般设5到8轮复杂任务放宽到10轮。注意ReAct的行动不是让模型自由发挥它只能从你预先声明的工具集合里选。工具集合就是Agent的行动空间这也是为什么后面要花大篇幅讲工具设计——行动空间定得不好Agent再聪明也没用。2. 工具接入与行动空间设计给Agent配好手脚2.1 三种主流工具接入方式怎么选模型本身是个大脑但落地干活得靠工具。目前接入工具的方式主要有三种各有利弊。第一种Function Calling函数调用。这是目前最主流的方式。你在请求里通过tools参数声明一批函数每个函数带名字、描述、参数Schema。模型在需要时返回一个结构化的函数调用请求比如{name: query_order, arguments: {order_id: ...}}然后你的系统执行这个函数把结果以tool消息的形式回传给模型。OpenAI、Claude、文心、通义、Qwen等主流模型基本都支持。优点是解析稳定、少出错缺点是不同的模型服务商在函数调用的协议细节上略有差异迁移时要适配一次。第二种纯文本工具描述。不依赖模型的原生函数调用能力而是把所有工具说明写进系统提示词约定模型输出固定格式比如Action: query_order Action Input: {order_id: OD20241001}系统拿到这段文本后自己写正则或者用JSON解析。这是ReAct论文早期常用的方式好处是兼容任何文本模型坏处是输出格式不稳定。模型偶尔会多写一句我这就帮您查或者把Action Input写成单引号你的解析器就得一遍遍打补丁。第三种MCPModel Context Protocol标准协议。这是最近一两年兴起的工具标准化方案核心是让工具以统一协议暴露给Agent运行时工具描述、调用、结果返回都走固定格式。适合多Agent复用工具、跨团队提供工具服务的场景。但注意MCP解决的是工具怎么暴露的问题不等于Agent就自动会用了最终执行路径还是回到上面两种模式之一。我的排序建议是能用Function Calling就用Function Calling它是目前稳定性和开发效率的平衡点。如果你的模型不支持、或者对格式控制要求极其严格再退回文本描述。MCP用于平台化、工具共享起步阶段不用急着上。2.2 工具命名、参数Schema与容错设计工具选型只是第一步真正决定Agent能力上限的是工具本身的质量。我踩过不少坑总结出三条硬性规范。工具命名要像函数名不能像一句话。query_order、create_refund_request、escalate_to_human这都没问题。但你要是起个get_the_latest_order_info_for_user也不是不行就是描述又长又占token。更忌讳的是用中文名加空格比如查询 订单模型在构造Action Input的时候容易产生歧义。命名清楚、简短、语义唯一是成本很低的优化。参数Schema必须严格描述必须详细。以JSON Schema为例每个参数要声明类型、是否必填、取值范围、示例值。这不是走形式是为了让模型理解传什么进去。比如一个query_order工具{ name: query_order, description: 根据订单号查询订单基本信息包括物流单号、订单状态、商品清单。如果订单不存在返回error。, parameters: { type: object, properties: { order_id: { type: string, description: 订单号格式为OD后接数字例如OD20241001 } }, required: [order_id] } }description里写清楚订单号格式、返回值包含什么、失败时返回什么模型才知道怎么填参数、怎么理解返回结果。description写得太笼统模型就会猜一猜就容易出岔子。工具的错误返回必须结构化。工具会失败这是生产环境的常态。关键设计是工具失败时返回的Observation也要是结构化的、可被模型理解的文本。举例Observation: {error: ORDER_NOT_FOUND, message: 订单号OD99999999不存在请检查订单号是否正确}这比直接抛异常、返回空的后果要好得多。模型看到error字段就知道前一步操作没生效下一步应该是纠正输入或者换一个工具而不是继续在这个错误结果上推理。我见过太多Demo里没有错误分支模型拿到工具异常结果后一脸茫然然后开始了长达N轮的假装成功。提示如果工具本身的功能比较复杂建议拆成多个原子工具而不是一个万能大工具。比如处理订单售后这种就太粗了拆成query_order、create_refund_request、query_refund_status、escalate_to_human四个模型每次只需要选一个参数也简单出错概率小得多。复杂工具一次传五六个参数模型很容易漏传、传错。3. 生产级Agent架构不是写个循环调模型那么简单3.1 生产环境需要哪些核心组件本地写个ReAct Demo可能二三十行代码就够了一个while循环、一个模型调用接口、一组工具函数。但拿到生产环境你会发现问题根本不是跑不跑得通而是跑得稳不稳、贵不贵、能不能排查。我梳理下来生产级Agent架构至少要包含五层Agent运行时。这是核心调度引擎负责维护循环、拼接上下文、调用模型、执行工具、判断终止条件。你写的那个while循环就是运行时的最小形态但生产环境它还需要额外能力并发控制、超时控制、重试机制、任务队列。尤其当你的Agent要服务线上用户时不能一个请求把进程阻塞住要同步转异步任务丢队列里跑跑完再通知。模型层。模型层要做的事情比调一次接口多得多不同任务的模型选型、请求重试与降级、token用量统计、上下文管理。你不可能所有任务都用同一个模型高复杂度任务用强模型简单任务用弱模型这中间还需要一个路由策略。工具层。工具的注册、鉴权、限流、执行、结果格式化都归这层管。生产环境的工具往往不是本地函数而是内部RPC、外部HTTP API甚至数据库操作。工具层还要考虑权限隔离比如这个Agent能不能调退款接口不是运行时说了算是工具层要做的鉴权控制。记忆层。第3.2节细讲。简单说短期记忆是当前任务上下文长期记忆是跨任务的持久化信息比如用户画像、历史行为、业务知识库。评估与可观测层。这是生产环境和Demo差距最大的一层。Demo跑崩了你print几行日志就行。线上Agent每轮干了什么、用了哪些工具、花了多少token、最后结果对不对全都要有迹可循。没有这个你连Agent为什么给用户退错款都复盘不了。很多团队从Demo直接上生产代价往往是上线后发现根本没法运营。我见过最典型的场景Agent在测试环境跑得好好的上生产之后开始调真实接口、对真实用户说话没人知道它中间经历了什么出了事故只能干瞪眼。所以架构这件事还是得上线前就搭好。3.2 记忆机制怎么选短期记忆与长期记忆的配合记忆这个词在Agent领域被讨论得很多但实际落地时要先分清两种完全不同的东西。短期记忆任务内上下文。就是当前任务中模型看到的所有消息包括用户提问、系统提示词、历轮的Thought、Action、Observation。实现上就是消息数组不断追加。这里有个矛盾点上下文窗口有限而ReAct循环每增加一轮就会新增Think、Action、Observation三段内容token消耗是递增的跑个十轮的任务可能光上下文就上万token。所以生产环境通常要做上下文裁剪把非常早期的Thought精简掉、把过长的工具返回结果摘要化、把无信息量的中间轮次压缩。这是成本和推理能力之间的天平要自己拿捏。长期记忆跨任务持久化。这是指Agent在多个任务之间能记住的信息。比如一个客服Agent用户上次问过什么问题、上次投诉过什么、用户的会员等级是什么这些信息如果每次都要重新问或者重新查体验就很差。落地方式一般是用向量库存语义信息比如用户的历史工单文本用KV存储存结构化属性比如用户ID、会员等级在每次任务开始时把相关信息检索出来塞进系统提示词。我的建议是前期不要追求全量记忆先把短期记忆管好再做一个简单的记忆表存关键结构化信息。记忆不是越多越好塞太多不相关的东西反而干扰模型判断。我见过一个Agent因为把用户三个月前的抱怨全塞进上下文结果对当前问题的回答态度都变了这属于记忆的副作用需要用时效性和相关性做过滤。3.3 模型选型与关键超参temperature、max_tokens与成本控制ReAct Agent的模型层需要关注三个参数调整。temperature。Agent任务和写文案不一样它需要确定性不需要创造力。temperature我一般设0到0.3之间很多模型服务商还支持seed参数配合使用。如果设太高模型在Thought阶段会发散出各种奇怪的想法甚至编造不存在的工具和结果。这个参数很多人忽略但它直接决定了循环的稳定性。max_tokens。模型单次输出的最大长度。ReAct循环中模型单轮输出不需要很长几百token足够。如果你不设上限模型有时候会喋喋不休写一大段再调用工具既浪费token又拖慢响应。我一般设512到1024。模型路由。一个Agent只绑一个模型是上不了生产规模的思维。我常用的策略是主循环用能力强的模型简单子任务比如格式化用户问题、给工具返回做摘要用便宜快的小模型。比如主循环上旗舰模型成本大概是普通模型的几十倍但如果任务本身不需要那么强就是纯浪费。成本上有个简单的估算公式单任务成本 ≈ 模型单价 ×输入token 输出token× 平均循环轮数。你会发现循环轮数是乘法因子所以控制轮数、控制工具返回长度是成本优化的关键杠杆。4. 实战演练从零搭一个工单自动处理Agent4.1 需求定义与工具清单前面讲的都是概念和架构这部分我拿一个实际场景完整走一遍客服工单自动处理Agent。目标不算复杂用户提交工单Agent先判断工单类型能自动处理的直接处理不能处理或者需要高权限操作的转人工。这个场景覆盖了查询、操作、转交三类典型的工具动作很适合做范例。先列工具清单工具名功能参数权限等级query_order查询订单详情order_id低query_logistics查询物流轨迹logistics_no低create_refund_request创建退款申请order_id, reason, amount高escalate_to_human转人工处理order_id, reason中resolve_ticket关闭工单ticket_id, resolution中这五个工具就是Agent的行动空间。注意create_refund_request是创建退款申请而不是直接退款这是有意设计的系统可以通过流程控制让Agent创建申请后再触发人工审批避免模型直接执行资金操作。这是生产环境很重要的边界思维——Agent可以发起动作但高危动作必须有人兜底。4.2 主循环的代码骨架下面是一个简化但可运行的主循环实现思路用Python写。核心逻辑是组装消息列表 → 请求模型 → 判断输出类型 → 执行工具 → 追加观察结果 → 继续循环。import json def run_agent(user_query, max_iterations8): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_query} ] for step in range(max_iterations): # 1. 请求模型要求返回结构化输出 response call_llm(messages, toolsTOOLS, temperature0.2) msg response.message # 2. 判断是函数调用还是最终回答 if msg.get(tool_calls): messages.append(msg) for tool_call in msg[tool_calls]: # 3. 执行工具 result execute_tool( tool_call[name], json.loads(tool_call[arguments]) ) # 4. 把工具结果作为observation回传 messages.append({ role: tool, tool_call_id: tool_call[id], content: json.dumps(result, ensure_asciiFalse) }) continue # 5. 没有工具调用视为最终回答 if msg.get(content): return msg[content] # 6. 达到最大轮数仍未收敛转为人工 return escalate_to_human(max_iterations exceeded)几个实现细节值得展开。call_llm这里实际项目中要包装好重试和降级逻辑。模型接口超时、限流都是常态重试策略一般用指数退避最多尝试三次三次失败就走降级模型或者直接转人工。不要在这里赌模型一定可靠。execute_tool这里要做的事情包括参数校验用JSON Schema校验模型传进来的参数、权限校验当前Agent是否有权调用该工具、执行、结果格式化。每一步都可能出问题但把校验和职责分开排查起来会清晰很多。循环上限我设8次这个数字基于经验大多数工单处理任务模型3到5轮就能完成超过8轮基本就是陷入死循环或者问题超出能力范围继续跑只会浪费token。设定上限后一定要写好达到上限怎么办的分支不能让它静默返回空结果。4.3 Prompt模板与控制参数参考主循环代码只是骨架真正的灵魂在系统提示词里。ReAct Agent的提示词一般包含这几块角色定义、可用工具说明、工具使用规范、输出要求。下面给一个参考模板你可以按自己的场景调整你是客服工单处理助手。你的目标是根据用户提交的问题选择适当的工具进行处理。 你可以使用的工具如下 1. query_order: 根据订单号查询订单详情 2. query_logistics: 根据物流单号查询物流轨迹 3. create_refund_request: 创建退款申请创建后需要人工审批 4. escalate_to_human: 将工单转交给人工客服 5. resolve_ticket: 关闭工单 使用工具时必须遵循以下规范 - 每次只能调用一个工具等待工具返回结果后再决定下一步 - 如果工具返回错误请仔细阅读错误信息修正参数后重试或者转人工处理 - 涉及退款操作时只创建退款申请不要声称退款已完成 - 如果用户问题不属于你的处理范围调用escalate_to_human - 当所有必要信息都已获取且问题已解决输出最终回答 - 回答要礼貌、简洁说明你已经做的操作和后续流程控制参数方面除了前面说的temperature还要设置单轮响应的max_tokens。工具调用类的输出结构其实很固定一般不会超过300 token所以我一般把输出上限设成512给一点余量但不放纵。上下文管理上我会设定一个固定的token水位线比如累计超过8000 token就把早期的History消息做一次压缩摘要。这个模板相比论文里的原始ReAct格式做了一些工业化调整工具说明直接列在System里而不是让模型自己发现工具增加了如果工具返回错误的明确指引对高风险操作做了行为约束。这些都是从踩坑中来的后面会展开说。5. 常见故障排查实录绕开这些坑能省一个月的调优时间5.1 死循环与反复调用同一工具这是ReAct Agent最常见的故障表现是模型在一个工具上来回转圈参数稍微变一变反复调用同一个接口。比如查询订单永远返回同一个状态模型却认为再查一次就会不一样。排查思路先看工具返回的Observation是否包含了足够信息。比如query_order返回了订单已签收但用户问的是为什么还没到模型发现信息不足以回答就会试图反复查。这时候正确解法是让模型转人工或者给出解释性回答而不是死磕。看Prompt里有没有写清楚什么条件下必须停止。我建议加一条硬约束如果工具返回的结果与之前相同或者你已经调用了同一工具超过两次应当基于现有信息回答或转人工。最后一道防线永远是max_iterations。别指望模型自律工程上必须兜底超限走降级分支。5.2 输出格式不稳定导致解析失败纯文本模式的老大难Function Calling模式下也会偶尔出现。模型有时会在Action前多说一句话有时Action Input的JSON不合法有时干脆编造一个不存在的工具名。我采取的组合拳是解析层做多个回退策略。先尝试严格JSON解析失败就尝试截取第一个{到最后一个}之间的子串再解析再不行就提示模型上次输出格式有误请重新输出符合格式的内容。解析失败发回给模型时要给出明确的错误信息比如Action Input必须是合法的JSON对象当前解析失败JSONDecodeError: Expecting ...。模型看到具体报错通常下一轮就修正了。Function Calling模式下很多服务商允许你强制工具调用也就是指定它必须返回某个工具调用这可以省掉一部分模型想直接回答的情况。5.3 工具执行失败后Agent硬编观察结果这是最危险的一种坑。工具调用报错了但模型没有把错误信息当回事直接在推理里写出了本该由工具返回的数据仿佛工具成功执行了一样。比如query_order返回订单不存在模型却在Final Answer里说订单已发货。产生这个问题的原因通常是工具返回的Observation不够结构化、不够显眼。模型没意识到这是个错误结果把错误信息当成一个普通字符串浏览过去了。排查方案是在工具描述和Prompt里反复强调如果Observation含error字段说明操作失败必须处理失败并且把错误信息的格式做得足够醒目比如统一用ERROR: ...前缀。在更高要求的场景可以在代码层加校验——如果上一步工具返回error就不允许模型进入Final Answer流程强制它先做下一步动作。这类规则属于半监督控制比纯靠模型自觉靠谱得多。5.4 上下文窗口溢出与token成本失控ReAct循环是累积式拼接上下文工具返回结果可能很大比如一个订单接口返回几百行明细。跑上几轮上下文很快就爆了。成本控制要从两头抓。工具返回侧做字段裁剪只保留模型真实需要的字段。比如物流查询返回几十个节点可以只保留最近几个节点和状态摘要。上下文管理侧要做滑动窗口或者摘要压缩。最早期轮次的Thought和Observation对中后期的推理影响往往不大可以把它们压缩成一段摘要文本。我自己有一个简单的判断标准如果一条历史消息超过200 token且距离当前已超过3轮就把它摘要化。优先压缩工具返回不压缩系统提示词和当前最新的Observation。5.5 超时与长任务处理同步调用的Agent请求如果跑5轮循环每轮模型要2到5秒加上工具执行时间总耗时可能20秒以上。在Web场景下这很容易超时。生产环境的解法是改成异步任务流用户请求进来立刻返回处理中的任务IDAgent在后台跑跑完后通过Webhook或者轮询让前端获取结果。另外一个思路是并行化子问题一个复杂任务拆成几个独立子Agent并行跑最后汇总结果但这属于多Agent协作的范畴了复杂度会明显上升建议先做好单Agent的稳定性再考虑。整理一份问题速查表故障现象直接原因优先处理方案循环不终止模型重复调用同一工具设置max_iterationsPrompt加停止条件Action Input解析失败输出格式不规范多重解析回退解析失败回灌模型纠错Agent编造工具结果工具错误信息不醒目统一error格式代码层限制进入Final Answer上下文溢出工具返回过大、历史累积工具字段裁剪、历史摘要压缩请求超时循环轮数多、模型响应慢异步化任务队列轮询/回调获取结果模型幻觉温度过高、信息不足temperature设0.2以下信息不足时引导转人工6. 上线前的评估与灰度发布Agent也能测试关键看你怎么测6.1 离线评测集不要靠感觉判断效果很多团队上线Agent前的验证方式是找十条数据跑跑看感觉还行就上了。这个做法在Demo阶段没问题但生产环境必须建立离线评测集。评测集就是一批标注好正确答案的输入输出对至少准备50到100条覆盖真实场景的样本。样本要分门别类简单查询类、需要多轮工具调用类、异常输入类、权限边缘类。每条样本要标注期望行为可以是最终回答正确且工具调用序列合理。评测执行时自动跑Agent记录每条的最终回答、工具调用序列、消耗轮数、消耗token然后和标注对比。不一定要一开始就做复杂的LLM-as-judge自动判定可以先人工打标。重点看三类指标任务成功率、平均循环轮数、超时率。成功率是核心另外两个决定成本和质量。每次改Prompt、改工具描述都重跑一遍评测集一眼就能看出改动是正向还是负向。这比凭感觉说效果好多了靠谱得多。6.2 灰度发布与人工审批兜底即使离线评测通过也建议灰度上线。先让Agent处理线上5%到10%的流量所有自动执行的动作都打到影子模式或者走人工审批。影子模式的意思是Agent正常跑、工具正常调用但结果只记录不生效人工去看它做没做对。人工审批尤其重要特别是涉及资金、内容发布、权限变更等高危工具。我所在的业务里凡是create_refund_request这类动作工具层会强制写入一个审批状态只有人工在后台点确认后才会真正发起退款流程。Agent可以生成这个申请但不能独立完成闭环。这个半自动设计让我放心很多也让业务方愿意给Agent更多权限。因为一旦出事决定权还是在人手里Agent只是提效工具。灰度期间还要关注用户投诉率和转人工率。如果转人工率异常升高说明Agent经常说自己处理不了如果投诉率升高那多半是Agent答错了得赶紧回看日志。6.3 可观测性建设没有日志就没有复盘和优化可观测性这块一口气说清楚。Agent的上线后运营核心是三类数据要完整落地第一类是全链路日志。每一轮请求要记录用户的原始输入、模型完整的输入消息含当前拼接的上下文、模型输出内容、解析结果、工具调用的入参和出参、工具耗时、累计token消耗。别怕日志量大Agent的每次任务背后是十几次模型调用和工具调用没有完整链路出问题根本无从排查。我习惯给每次Agent任务分配一个trace_id所有日志、所有模型调用都挂在同一个ID下。排查时拉出来就像放电影一样把整个任务过程回放一遍。第二类是运行指标。按任务维度统计平均轮数、平均延时、token消耗分布、工具调用次数、工具失败率、超时任务数。这些指标一旦有异常波动比如平均轮数从4轮涨到7轮就说明可能是Prompt改动回归了或者模型服务端有波动。第三类是结果审计。Agent最终给出的回答要和工具执行记录、上下文一起留存。不一定要全量人工复核但要有抽样审计的能力。业务方问这个Agent凭啥这么回答你得能拉出证据链。可观测性做得好不好直接决定Agent在线上能不能持续变好。没有观测的Agent就像闭着眼睛开车开得好是运气出了事都不知道撞哪了。说到最后我个人的体会是ReAct这个范式本身并不神秘它的核心就一句话——让模型在思考、行动、观察之间循环直到问题解决。但把它放到生产环境真正考验你的不是循环算法而是围绕这个循环搭起来的工程体系工具怎么设计、上下文怎么管、成本怎么控、出错怎么兜底、上线怎么验证。你在搭这些的时候可能做的都是很笨的活比如给工具写详细的参数描述、给错误信息统一格式、给每条日志打trace_id但这些恰恰是Agent能否稳定跑起来的分水岭。如果你准备在自己的项目里落地ReAct我的建议是别急着堆功能先把第4章的工单Agent这个例子完整跑通然后把第5章的坑挨个踩一遍或者提前绕开再把第6章的评估和日志补上。这套链路走下来你对Agent的理解会深一个量级。