1. 从一套“能干活”的提示词说起这几年 AI Agent 的概念红得发紫但很多团队拿着大模型 API 折腾了个把月最后发现所谓的 Agent 就是个“会聊天的脚本”。真正把 Agent 推向生产环境绕不开两个关键词——ReAct和多 Agent 协作。我参与过几个从零搭建 Agent 系统的项目踩过的坑不比谁少现在把这些经验整理出来希望能帮那些正准备入局或者正在结构泥潭里挣扎的团队少走弯路。这篇文章适合谁看两类人一是刚接触 Agent想搞清楚 ReAct 循环、工具调用、记忆机制这些概念到底怎么落地的人二是已经在做单 Agent 原型但发现“一个模型打天下”根本撑不住复杂业务琢磨着往多 Agent 架构演进的技术负责人或架构师。先说个大家容易忽略的前提Agent 和普通的大模型应用最大的区别在于自主性。普通应用是你问一句、它答一句模型本身没有目标、没有行动环。而 Agent 是一个闭环系统——模型在循环中感知、决策、行动再根据行动结果调整下一步。ReAct 就是把这个闭环用“推理 行动”的方式具象化了。我在后面会讲清楚三块内容ReAct 的工作机制到底是什么、它为什么会在复杂任务上露怯、多 Agent 协作的几种典型架构模式以及从单 Agent 到多 Agent 演进过程中那些落到代码和配置层面的工程细节。2. 拆解 ReAct推理与行动的闭环是怎么跑起来的2.1 ReAct 的逻辑本质ReAct 这个词来自“Reasoning”加“Acting”它要解决的核心问题是让模型不仅仅输出答案而是能够像一个有方法的人一样逐步观察现状、思考方案、调用工具、查看结果、修正路线。我见过不少刚接触的人会把 ReAct 理解成一串 if-else这是个非常大的误区。ReAct 不是预设好的流程分支而是每一步都让模型根据当前状态自主决定下一步动作。拆开来看ReAct 的单步循环包含四个阶段Thought思考模型分析当前已有的信息判断离目标还差什么Action行动模型决定调用哪个工具、传入什么参数Observation观察执行工具后返回结果作为新的上下文输入循环重复 Thought 和 Action直到模型认为可以给出 Final Answer。这个机制的核心价值在于工具调用的灵活度完全交给模型而不是被硬编码在程序里。传统程序里你要让系统查天气、订机票、发通知得在流程里写死每一步。但在 ReAct 模式里你只需要给模型准备几个工具告诉它“你有这些能力可用”剩下的路径让模型自己走。我记得第一次给团队演示 ReAct 时有人问了一个很实际的问题“模型万一选错了工具怎么办”答案是那就回到 Thought 阶段基于 Observation 重新判断。ReAct 天然支持试错因为它每走一步都能看到反馈这比传统规则引擎天然容错。2.2 从代码层面看 ReAct 的本体如果你打算自己实现 ReAct而不是用现成框架核心代码其实非常精简。底层就是个大模型的聊天接口外加一个工具注册表。一个最小实现大体长这样from openai import OpenAI client OpenAI() tools [ { type: function, function: { name: search_weather, description: 查询指定城市的实时天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ] messages [{role: user, content: 北京明天适合跑步吗}] response client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools, )注意这里的关键点是你不需要在提示词里手动描述“请先调用天气工具然后再回答”。模型看到tools参数后会自己判断“为了回答这个问题我需要调用 search_weather”然后返回一个包含函数调用指令的响应。你要做的就是解析这个响应、执行本地函数、把结果回填给模型。response.choices[0].message.tool_calls # 模型决定调用的函数工具执行完再把结果以tool角色消息传回去messages.append({ role: tool, tool_call_id: tool_call.id, content: 北京晴气温 22 度风力 2 级 }) model_output client.chat.completions.create( modelgpt-4o, messagesmessages, )这就是 ReAct 循环的具象化模型提出行动tool call你执行工具结果回到模型手里模型再决定下一步。一个完整 Agent 系统的骨架其实只需要这几十行代码。但生产环境里的复杂度呢主要堆在工具的健壮性、错误处理、上下文管理上。2.3 ReAct 的优势边界在哪里ReAct 把“让模型学会用工具”这个能力释放出来适合处理那些目标明确但路径不唯一的任务。比如查数据并生成分析报告模型需要确定查哪些库、跑哪些查询根据用户模糊需求推荐商品模型需要多轮追问澄清意图自动化运维巡检模型需要组合调用多个监控工具判断异常。它解决的核心问题是“大模型有智商但没有手”——让模型能够操纵真实世界的系统。2.4 为什么单 Agent 会在复杂任务上偏航ReAct 虽好但有个致命弱点模型在长程任务中容易出现“迷失”。就好比让一个非常聪明但记性不太好的人独自负责一个大型项目他能在每一步做出合理决策但走着走着会忘掉最初的目标或者被中途出现的次要问题带偏。这个现象在工程上叫“偏离目标漂移”。我实测过当 Agent 需要超过 10 步工具调用才能完成一个任务时模型的准确率会出现明显下降。原因有三个上下文窗口有限每一步的 Observation 都会追加进 messages积累到一定长度后早期信息会被截断或稀释注意力分散模型对中间状态的注意力要均匀分配关键约束容易被忽略错误累积某一步选错工具后续所有判断都基于错误结果就像岔路口走错了一条路后面怎么走都到不了终点。这些问题的出路不是堆提示词技巧而是尝试把任务拆开让多个专精的 Agent 各管一段把复杂任务变成小任务的组合。这就说到了多 Agent 协作。3. 多 Agent 协作为什么拆开反而更高效3.1 从“一个全才”到“一组专才”单 Agent 的目标是让一个模型学会所有技能多 Agent 的思路则完全不同——拆成多个角色每个 Agent 只负责自己最擅长的领域通过协作完成任务。打个比方单 Agent 是让一个厨师从头做到尾切菜、炒菜、摆盘都得会多 Agent 是让一个后厨团队分工切配归切配、炉灶归炉灶、甜品归甜品每个人在自己的岗位上做到极致再由一个“主厨”或“传菜员”把各环节串起来。多 Agent 协作的核心价值角色专业度提升每个 Agent 的 prompt 可以针对特定任务做极致的约束和优化而不是什么都能干但什么都不精上下文隔离每个 Agent 只维护与自己任务相关的上下文不会被无关内容干扰可观测性和可干预性增强任务被分配到不同 Agent任何一个环节出问题都可以精准定位到具体角色而不是在一个大黑盒里找出错原因。我在一个数据处理项目中体会特别深。单 Agent 要同时承担“理解查询意图”“编写 SQL”“检查 SQL 结果”“生成图表”“写解读”五个角色结果经常顾此失彼。拆成需求理解 Agent、SQL 生成 Agent、可视化 Agent 三个角色后每个 Agent 处理质量都明显上了一个台阶而且出现问题能快速定位。3.2 三种主流的多 Agent 架构模式多 Agent 不是简单把多个 Agent 堆在一起关键在于它们之间怎么通信、怎么编排。根据不同协作逻辑我把实际项目中最常见的架构整理成三种模式。3.2.1 主管-执行者模式Supervisor-Executor这种模式最容易理解和落地。一个“主管 Agent”负责理解任务、拆解任务、分配任务、汇聚结果下面挂着多个“执行 Agent”各管一摊。工作流大致是用户发来任务主管 Agent 分析任务内容主管 Agent 判断该调用哪个或哪些执行 Agent执行 Agent 完成任务返回结果主管 Agent 汇总所有结果决定是否继续细化或返回最终答案。这种模式适合任务边界相对清晰、执行步骤可以预判的场景。比如在客服系统中一个主管 Agent 判断用户问题是退款、物流还是产品咨询然后分别转给对应的处理 Agent。3.2.2 流水线模式Pipeline流水线模式是任务按照固定顺序在不同 Agent 之间传递每个 Agent 的输出是下一个 Agent 的输入。就像工厂流水线每个工位只管自己那一道工序。典型场景是内容生产链路选题 Agent - 信息搜集 Agent - 草稿撰写 Agent - 事实核查 Agent - 润色 Agent。这种模式的好处是职责极致清晰、上下文可以彻底隔离适合阶段边界明显、产出物形态稳定的流程化任务。坏处是如果前一个环节质量不佳错误会一路传导所以关键节点通常需要加人工审核或质量校验 Agent。3.2.3 自由协作模式Network / Peer-to-Peer这种模式下没有中心的“主管”多个 Agent 像同事一样互相沟通、互相质疑、共同推进目标。比如讨论型的 Agent 系统里一个 Agent 提出方案另一个 Agent 扮演反对角色指出风险第三个 Agent 负责中和并整合。这种模式的实现难度最高因为通信协议、任务交接、共识机制的复杂度会随着 Agent 数量平方级增长。我一般建议团队先从监督或流水线模式入手跑通之后再考虑自由协作除非你要研究的场景本身就是开放探索型的。3.3 单 Agent 到多 Agent 的演进什么时候该切很多团队会问我是不是所有场景都该上多 Agent我每次都是直接回答不是。多 Agent 不是银弹它带来的复杂度提升非常大通信开销、编排逻辑、错误处理难度都在指数级增加。什么时候该切到多 Agent三个信号很关键单一 Agent 的 prompt 已经复杂到难以维护你为了让一个 Agent 懂业务规则提示词写到几千字结果它还是经常顾此失彼、在规则之间打架。这说明应该拆角色了任务链路中存在明显冲突的能力要求比如既要代码生成又要严格安全审查这两类能力角色冲突一个 Agent 很难平衡单 Agent 的错误难以定位和修复当输出质量出现问题你翻遍上下文也搞不清是哪一步决策错了说明黑盒已经太大了。反过来如果任务就是一个直接的问答、一次工具调用就能完成强行拆成多 Agent 纯粹是自找麻烦。工程上的第一性原理永远是——用最简单的结构解决当前问题。架构演进应该被问题驱动而不是被潮流驱动。4. 工程化实践多 Agent 协作落地中的关键细节4.1 Agent 之间的通信协议设计这是多 Agent 架构里最容易踩坑的地方。很多人一上来就写死 Agent A 调用 Agent B 的方法是传字符串运行起来发现维护成本爆炸。我在实践中得出一个原则Agent 之间的消息必须结构化。不要传“我把结果给你”而是传一个带有角色、内容类型、结构字段的消息对象。一个实际使用的消息结构示例{ from_agent: planner, to_agent: executor_sql, task_id: task_12345, intent: generate_sql, content: { question: 统计上月各渠道的订单总量, schema_hint: orders, channels, required_output: sql_query }, meta: { timestamp: 2024-11-21T10:00:00Z, trace_id: trace_001 } }有了结构化消息你就获得了三个巨大的工程优势可追踪性每条消息都有 trace_id排查问题可以直接链路追踪可测试性每个 Agent 的输入输出都是明确的数据结构可以单独做单元测试可扩展性后续加一个 Agent不需要改其他 Agent 的代码只要新 Agent 遵循同一消息协议。4.2 每个 Agent 的上下文隔离别把所有对话焊死在一起我在不少项目里看到团队犯同一个错把多 Agent 之间的所有对话都塞到同一个 messages 数组里传给每个 Agent。这个做法在任务简单时问题不大一旦任务变长、变复杂每个 Agent 都会被无关上下文干扰准确率直线下降。正确做法是每个 Agent 维护自己的私有上下文池只接收跟自己任务相关的输入只输出跟自己角色相关的结论。主管 Agent 手里可以握一份全局简报但这份简报应该是摘要级的而不是把所有中间过程全部堆给每个执行者。层面更细化一点可以分两层理解单任务上下文当前任务相关的消息序列比如“生成 SQL”这个 Agent 只需要看到用户的原始需求、相关表结构、最近一次尝试的错误信息全局记忆上下文跨任务的有价值信息比如用户偏好、历史结论、业务约束这部分通常以摘要或向量检索结果的形式注入而不是原文全部拼接。4.3 工具注册与执行沙箱给 Agent 一个可控的操作台工具不是越多越好。我见过有人给一个 Agent 注册了 30 个工具结果模型经常选错。原因很简单——工具越多选择的正确率越低。我实践下来的建议是工具数量控制在 5-8 个以内够用就行每个工具的 description 要写清楚它的适用范围、限制条件、返回格式。模型是靠 description 来决定是否调用工具的描述写得越精确选错概率越低高危操作比如直接删除数据、发送通知必须加二次确认或人工审批节点。工具执行环境也要重视安全。如果是执行代码类的 Agent强烈建议跑在沙箱容器里限制内存、网络、文件系统权限。我在某个数据平台项目里就是给 SQL Agent 配了一个只读账号极大减少了误操作风险。工具执行结果还要做好异常处理。工具不是每次都能成功超时、断网、返回空值都是常态。Agent 的 prompt 里必须明确告诉模型——“工具调用失败后不要强行编造结果要重新尝试、换个工具、或者向用户说明失败原因”。4.4 记忆机制短期工作记忆与长期知识库Agent 在任务中会产生大量中间信息这些信息不能全留在上下文窗口里否则窗口很快会爆。需要区分短期记忆和长期记忆。短期记忆指的是当前任务过程中的上下文要定期做摘要压缩。比如每一步工具调用之后把 Observation 压缩成一句话结论丢弃原始长文本。这一步能显著提升长任务的成功率我在实践中发现上下文压缩至少能让 20 步以上的长任务成功率提升三到四成。长期记忆则是跨任务的持久化信息比如用户偏好、历史任务结果、业务领域的知识。长期记忆通常通过向量数据库存储按需检索注入。当新任务进来时先检索与当前任务相关的历史信息再拼接给模型。我自己搭过一套轻量级长期记忆方案存储用向量库检索时把任务描述向量化取 Top-K 相似记忆拼进上下文。这个方案比把全部历史都塞给模型要省 token效果也好得多。4.5 可观测性多 Agent 系统最贵的成本是排障单 Agent 出问题还能通过翻上下文猜测多 Agent 出问题如果不做埋点排查起来跟大海捞针差不多。我强烈建议从第一天开始就把可观测性做到位。至少需要记录四类日志决策日志每个 Agent 的每一次 Thought 内容模型为什么选择某个工具为什么换方向工具调用日志调用了什么工具、传入什么参数、返回什么结果、耗时多少消息日志Agent 之间传递的消息内容、时间戳、trace_id质量评估日志每个环节的产出打分或人工审核结果。有了这些日志你可以非常直观地看到整个链路每一步做了什么决定哪里偏离了预期哪个 Agent 是瓶颈。我给团队建议的落地路径是先定 trace_id 贯穿所有环节再在框架里埋好日志点最后搭一个简单的日志检索页面。不需要一开始就上复杂的可视化大盘先能查日志再慢慢优化。5. 几个真实迭代里的关键问答与避坑经验5.1 Agent“绕圈子”反复调用同一个工具怎么办这是 ReAct 模式的高频问题。模型可能在错误分支里反复执行同一个动作出不来。有个最直接的兜底方案给循环设置最大步数。比如限定最多 15 步超过直接中断并返回当前总结。这一步能防止资源浪费也能逼着模型在有限的步数里快点出结果。还有一招是在 prompt 里加入反事实提示告诉模型“如果你已经调用过某个工具且结果不理想请尝试其他路径不要重复同一动作”。实测对部分模型有效但不能完全依赖。更根上的解法其实是任务拆分——如果一个 Agent 在 15 步内还完不成任务大概率是这个任务本身太复杂了得拆给多个 Agent。5.2 Agent 之间相互踢皮球、责任模糊怎么处理在自由协作模式里经常出现 Agent A 认为该 Agent B 负责Agent B 觉得该 Agent A 处理最后两方都在等对方任务卡死。对策有三个明确角色边界每个 Agent 的 system prompt 里写清楚“你负责什么”“你绝对不负责什么”减少职责重叠。职责重叠是多 Agent 系统里矛盾的最大根源要尽量避免引入仲裁者或主管在最上层召回一个协调 Agent 或人工在出现分歧或超时时介入分配设置超时自动升级每个 Agent 收到消息后如果在一定时间内没有完成自动将任务升级给上一层主管处理。我实际经验是大多数生产系统用主管-执行者模式就够了自由协作更多用在离线的头脑风暴场景。别为了炫技把正事搞复杂。5.3 工具调用格式错误、参数校验失败怎么办模型生成的工具调用参数偶尔会出现格式错误这在开源模型上尤其常见。工程上要做的是宽容解析 自动修正。比如模型生成了一段不完整的 JSON你可以尝试用解析容错库去恢复实在恢复不了就把错误信息回传给模型——“你刚才的参数格式有误错误信息如下请重新生成合法参数”。让模型自己在下一步里修正这其实也在 ReAct 循环之中。还要在工具这层做参数校验必填字段是否缺失、枚举值是否合法、数字是否在合理范围。校验失败时返回的错误消息也要给模型足够的信息别只给一个“参数错误”这样的模糊提示。5.4 上下文费用失控大量 token 花在中间过程中多 Agent 系统的 token 消耗比单 Agent 是数量级的增长不加控制很容易爆预算。三个省钱手段我都在用中间结果压缩每个工具返回的长文本在进入模型上下文前先做摘要。只传关键结论不传原始文本控制消息保留条数上下文只保留最近 N 轮消息更早的整理成摘要。用一个滑动窗口管理消息队列用更便宜的小模型分担简单任务比如“阅读理解”“格式转换”这类任务大可不必请大模型上用一个中档模型就够了。预算大头留给核心推理环节。5.5 多 Agent 比单 Agent 更慢怎么优化延迟这是几乎必然出现的问题多一个 Agent 循环就多一轮模型调用延迟线性增长。优化思路是把能并行的环节并行化。如果任务要求 Agent B 和 Agent C 都依赖 Agent A 的产出但不互相依赖那就同时把任务派给 B 和 C让它们并发处理等两个都回来后由主管合并。另一个思路是降低调用频率。不是每一步都非得调用大模型简单判断比如“结果是否为空”可以用代码逻辑完成只有真正需要推理的环节才动用模型。合理规划才能把多 Agent 的延迟压回可接受范围。6. 架构选型的几个实际建议如果你正要启动一个 Agent 项目我把这几年的体会浓缩成几句建议第一从 ReAct 开始但别停留在 ReAct。先做一个最小可用的单 Agent 原型跑通工具调用、上下文管理、结果反馈这条链路。这个原型会是后面所有演进的基础设施。第二多 Agent 的切入时机要等痛点出现。别在一开始就规划五人小组式的豪华架构等单 Agent 在复杂任务上频繁出错、prompt 维护成本高到难以忍受时再动手拆。第三通信协议和可观测性设计要趁早。这两个东西后期补非常痛苦因为牵涉到每个 Agent 的接口变更。架构可以从小开始但数据结构和日志规范必须从第一天就定好。第四选型时要考虑团队维护能力。多 Agent 不是一次性的技术演示而是长期运行的业务系统。如果团队没人能理解全套架构宁可保持简单。系统的复杂度必须匹配团队的运维能力否则上线即噩梦。我自己在这条路上踩过不少坑最深的体会是Agent 不是把模型调参调得更聪明而是把任务结构设计得更合理。一个结构清晰、边界明确的多 Agent 系统比一个 prompt 写得天花乱坠的单 Agent 系统可靠得多。这个方向未来还会继续演进但从工程落地的角度看把 ReAct 打磨扎实、把多 Agent 的协作机制设计清晰就是当下最值得投入的事情。