2025年我做得最多的一件事就是把各种现有AI Agent架构挨个拆开看了一遍。起因其实很简单团队要在一个复杂的业务流程系统里引入多步骤的智能处理能力市面上可参考的Demo不少但真正能扛住长链路、高失败率、频繁工具交互的落地案例不多。这份调研把主流的Agent架构模式、任务规划算法和复杂任务处理系统的工程方案梳理成了一条线文章会把核心结论、选型依据和踩坑经验一并写出来适合那些已经跑通过基础Agent、正准备往复杂场景推进的开发者参考。1. AI Agent 架构全景从单体大脑到多体协作1.1 ReAct 架构为什么能成为事实标准做调研的第一站基本都是ReAct这套“推理-行动-观察”的循环已经是当前Agent产品最重要的底子。它的核心设计其实很简单让大模型交替输出思考过程和工具调用动作再把工具返回结果喂回去形成下一轮决策。这个过程就像一个工程师拿到了一个不断出结果的新设备边看说明边操作而不是一次性把整本说明书背下来再动手。ReAct能成为事实标准根本原因在于它对“模型会犯错”这件事做了结构性容忍。单次推理结果不对没关系拿到错误反馈后模型还有机会修正下一步动作。实际测试中你会发现同样的任务在纯Prompt调用下成功率可能只有60%左右套上ReAct循环之后能提升到85%以上提升幅度主要来自“观察”环节的纠偏能力。但ReAct也有明显的天花板它本质上是贪心解码每条路径只往前走一步没有回头重选的能力。面对任务步骤超过20步的长链路模型在中间环节选错走一步后面就是连锁错误而且早期的错误要等到很后面才会暴露。这也是为什么后来大家都开始往ReAct上面叠加规划层和搜索能力。1.2 Plan-and-Execute 架构把行动变策略在ReAct的循环外面再加一层规划器就形成了Plan-and-Execute架构。规划器负责把目标拆成一串可执行子任务执行器只负责逐个落地两者不再混在同一个推理循环里。这个拆分的价值在于让“想”和“做”可以独立优化规划器可以用更大的模型、更长的上下文执行器则可以用更快、更便宜的模型批量跑。我用一个真实场景验证过这个架构的优势假设任务是“从一批PDF发票中提取金额、核对供应商信息、并按月份汇总成报表”。如果让ReAct模式直接干模型大概率会在每一步都要重新读文档、犹豫下一步做什么十几次工具调用后上下文就开始混乱。换成Plan-and-Execute后规划器先一次性把任务分解成“提取—清洗—匹配—汇总”四个阶段执行器每阶段只做一件确定的事整体稳定性和执行速度都有明显提升。需要提醒的是Plan-and-Execute架构的难点在于规划器输出的子任务边界要足够清晰否则执行器拿到模糊指令还是会在内部偷偷“想”效果会退化回ReAct。规划质量和约束条件的设计是这个架构能否发挥价值的分水岭。1.3 多 Agent 协作架构单Agent能力再强在面对需要多个专业角色配合的场景时依然会力不从心。多Agent协作架构的出发点是把大而全的Agent拆成多个职责单一的子Agent各自持有专属的工具集和Prompt再通过某种通信机制协调工作。当前主流的多Agent协作模式大概有四类我分别实测过效果和成本协作模式核心机制适合场景最大问题编排者-工作者中央控制器统一派发任务流程相对固定、分工明确编排者成为瓶颈对等式协作各Agent基于消息自主协商开放探索、讨论型任务消息量大、收敛难辩论/评审式多个Agent互相评审多轮内容生成、代码评审Token消耗惊人流水线式上一个Agent输出直接喂给下一个数据处理链条错误逐级放大编排者-工作者模式在工程项目中最常用因为它把复杂协调问题简化为单点调度方便做权限控制、状态管理和任务追踪。但凡是把业务做复杂了之后编排者本身要理解所有其他Agent的能力边界这个认知压力最终会落在Prompt设计和意图分类上一旦分类不准整个协作体系就开始失灵。1.4 架构选型的决策参考经常有朋友直接问“哪个架构最好”这个问题其实没法回答。选架构跟选交通工具一样得先看你要走的路。我给自己定了一套选型判断标准基本能应对大多数场景任务链路会不会频繁出现“一步错、后面全错”的情况会的话优先考虑Plan-and-Execute在分解层面就加隔离。任务是否需要多类专业技能配合如果需要再考虑多Agent否则一个Agent加全套工具更可控。团队的迭代速度要求高不高高的话千万别一上来就上多Agent先把单Agent流程调稳再逐步拆分。另外建议关注任务的不可逆程度。如果执行动作会产生无法回退的后果比如向客户发送邮件、扣减库存架构里必须设计明确的审批节点和人工介入接口。我见过不少团队把自动化率作为唯一目标最后在关键节点上栽了跟头——自动化率越高出错时后果越严重。2. 任务规划算法从经典搜索到 LLM 自规划2.1 经典规划算法在 Agent 中的位置聊到任务规划很多人默认是“让大模型自己想步骤”但工程实践中经典算法依然占着重要位置。最典型的是图搜索思路把任务状态看成节点工具调用看成边的转移用带权重的搜索算法在状态空间中找一条可行路径。A*算法的思路在工具调用的路径规划中很实用关键在于设计一个合理的代价函数。比如目标是从一堆非结构化文档里提取关键字段每一步工具的调用都是一个候选动作代价函数可以设置为“该动作预期带来的信息增益/成本”。信息增益高、Token消耗少的动作会被优先执行。MCTS蒙特卡洛树搜索在开放性的任务规划中也开始被反复使用它通过随机模拟若干条动作序列回传“哪条路走得通”的信号再用统计结果指导下一条路径的选择。MCTS的好处是不需要提前定义完整的搜索空间适合动作组合爆炸、没有最优解的开放式场景。代价则是计算开销巨大每扩展一个节点都要跑一次模型推理。调研下来工程落地中直接上MCTS的团队很少大部分是拿它做离线数据生成或策略仿真在线场景还是用更轻量的办法。2.2 LLM 内生的任务分解与思维链目前应用最广的任务规划算法其实是让大模型自己生成步骤序列。你可以直接告诉模型“先做A再做B最后做C”也可以通过少量示例让它模仿这种分解结构。这个思路很简单但实际执行时需要注意“一次拆到底”还是“递归往下拆”的选择。我实测下来的感觉是对少于5个步骤的简单任务一次拆到底完全够用对超过10个步骤的复杂任务一次拆到底会生成过于抽象的计划中间步骤要么不可执行要么相互依赖没说清楚。此时递归分解更稳妥——先拆成阶段再让模型对每个阶段单独拆解拆到步骤足够具体为止。递归分解的代价是多轮调用增加了延迟但换来的是执行稳定性。另一个值得注意的技术点是子任务间的依赖表达。很多Prompt只写“按顺序完成以下步骤”但现实中子任务往往不是纯串行有的是并行关系有的是条件分支。把依赖关系显式表达出来比如用编号和前置条件描述能让执行过程大幅减少返工。我通常会在规划Prompt里强制要求输出结构化计划包含步骤编号、输入需求、输出预期、前置条件四个字段效果显著。2.3 反思与自修正让规划可收敛任务规划最尴尬的情况是计划本身错了——步骤顺序合理但整体方向偏了或者第一步得到的结果让后续所有步骤失去意义。为了处理这种情况业界发展出了一类“反思-修正”机制。核心逻辑很朴素做一次规划先执行一小步拿到结果之后让模型批判一下当前进度是否合理再决定是继续执行、调整计划还是回退重试。这个做法相当于给Agent装了个“过程检查点”不让它闷头做完整个流程才发现走错了。Reflexion模式会在计划执行完后生成经验总结存到外部记忆里下次执行同类任务时先读一下这些经验从源头降低重蹈覆辙的概率。实际工程中不要把反思看得太玄乎。我一般把它实现为一个条件分支执行器每完成一个阶段向规划器汇报结果摘要规划器判断当前结果与目标是否一致返回“继续/调整/重试”的指令。只需要在架构里预留一个决策节点就能显著改善长任务的成功率。2.4 规划算法的评测与取舍评测规划算法时大家最容易陷入单一指标陷阱比如只盯着“最终任务成功率”。成功率固然重要但我会额外关注三个指标规划覆盖率计划中真正被执行的比例、无效工具调用率执行中浪费在无意义动作上的比例和流程恢复率出错后能否自我纠偏。一个覆盖率低但成功率高的Agent往往是因为它靠碰运气避开了计划表面好看实际不可靠。成本和延迟也是取舍的关键。MCTS和复杂的多轮反思算法效果可能好10个百分点但代价是好几倍的Token消耗和响应时间。在实际业务里延迟过高意味着用户根本等不到结果再聪明也没用。我的建议是先在场景上做充分测试根据任务复杂度分层选择算法简单任务走ReAct中等任务加一层规划分解只有复杂任务才铺上反思和多轮搜索。这样成本可控、效果稳定也好向团队解释系统行为。3. 复杂任务处理系统的工程化落地3.1 状态管理把 Agent 生命周期做成可观测系统调研过程中发现不少团队在Demo阶段跑得欢一上生产就崩最核心的差异不是模型选得好不好而是状态管理做成什么程度。Agent的运行本质上是一个不断变化的状态机当前在哪个阶段、哪些工具可调用、历史消息累积了多少、上下文还差多少到天花板。没有显式的状态管理Agent就是一匹蒙眼狂奔的马跑偏了都不知道从哪里追回来。我需要重点强调工作流引擎和状态持久化的作用。把Agent的每一步动作都记录成一个带时间戳和元数据的事件整个运行过程就能回放出问题时能定位到具体是哪个步骤产生了错误结果。这个能力在生产环境的价值怎么强调都不过分。我见过最让人头疼的线上事故就是因为某个中间步骤被悄悄跳过后续所有计算基于残缺数据最终输出了一份完整的错误报告——没有事件日志根本发现不了。Checkpoint断点持久化机制也非常关键。长任务跑了一半挂了如果状态没有持久化就意味着从头再来。好一点的框架支持把上下文状态落库重启后接着跑。这两项能力在选技术栈时要当作硬指标来审。3.2 记忆系统短期工作台和长期知识库的组合Agent的记忆系统听上去高大上说白了就是两类存储的组合短期记忆用来放当前任务的中间结果和工作状态长期记忆用来跨任务保存经验和知识。不加记忆系统的Agent每次对话都是失忆的做完一个复杂任务后所有中间成果归零下次开始新任务时一切从头再来。短期记忆的工程实现通常就是对上下文窗口的管理。上下文超过限制时需要进行压缩——把前面的对话总结成摘要、把不重要的细节直接丢弃。这里有一个实操经验总结摘要的成本刚开始不起眼但复杂任务累计下来会消耗大量Token。我通常会给摘要策略设定触发阈值比如上下文超过70%时才开始压缩而不是每轮都做。长期记忆方面目前最普及的技术路线是向量数据库加Embedding检索把历史任务的要点、成功经验和失败教训编码存储在新任务开始时先做一次相似检索把相关经验注入上下文。这样做的好处是Agent在下一次面对类似任务时不需要重新试错。不过需要注意检索精度相关性差的记忆注入上下文反而会成为噪音影响模型判断。3.3 工具调用与错误恢复机制工具调用是Agent从“能聊”变成“能干活”的分水岭。工程上要解决的不只是让模型输出一段函数调用而是整个调用生命周期参数生成、权限校验、执行、结果解析、异常处理。各个环节都有自身特有的坑。参数生成是最容易出问题的环节。模型经常会生成格式错误的JSON、捏造不存在的参数名或者传递超出范围的枚举值。我建议在工具定义时尽量用严格的JSON Schema并在Prompt里给出明确的示例。另一个容易被忽视的点是时间敏感型参数比如“查询最近7天的数据”模型如果不把“今天”换算成具体日期系统按旧数据查询就会错得悄无声息。错误恢复机制的核心是重试策略和降级路径。工具调用失败后是立刻重试、退避重试还是换一条路径绕过去需要根据错误类型动态决定。我最常用的策略是前两次快速重试第三次切换备选工具累计失败则回退到重新规划而不是让Agent无限折腾同一个失败的调用。3.4 观测、评测与可复现性一个复杂任务处理系统如果没有观测和评测体系就无法可靠迭代。观测层面至少要覆盖三层调用链追踪每个步骤消耗了哪些Token、花了多长时间、哪一步最贵、决策记录模型每一步的思考和选择、结果质检任务的最终输出是否符合预期。评测要建立一个有代表性的基准集不要只拿几个顺手的用例反复测。好的基准集应该包含任务的难度分层、不同类型的失败注入以及长链路任务样例最好还能在CI流程里自动跑。这里有一条亲身教训早期团队只拿“顺利路径”测系统所有用例都是标准输入、标准输出模型表现得近乎完美。后来有一天把带噪音的脏数据扔进去系统直接崩溃。从那以后我坚持在评测集里加入各种错误路径和极限数据。可复现性往往被忽略但极其重要。调试Agent的时候如果每次跑出来的中间结果都不一样那排查问题就像大海捞针。解决思路是在系统里维护一个会话ID和全量事件日志确保任何一次运行状态都可以完整重建。同样是跑崩溃了有日志和没日志的排查效率差了好几个量级。4. 从开源生态里看主流框架的取舍4.1 以图状态编排为核心的框架目前有一类框架把Agent流程建模为图结构节点是处理逻辑边是状态流转条件。这种框架在生产落地中表现非常抢眼优势在于流程可控、状态可视化、断点恢复比较容易实现。节点之间通过显式状态传递数据每一步都可在外部观察和干预。我们团队拿这类框架重构过之前的ReAct流程。最直观的感受是流程终于变得“可看见”了哪里慢、哪里出错、哪里在重试都一目了然。对于业务逻辑相对固定的复杂系统我强烈建议先考虑这种方案因为它的工程护城河在于稳定性和可维护性而不是花哨的智能。使用这类框架时要理解一个核心理念图结构本质上是告诉Agent“哪些路能走”而把“走哪条路”的决策权留给模型。对业务规则很硬的部分可以在图上做成强制约束对需要灵活探索的部分做成自由决策节点。这个张力的平衡决定了系统的智能感和可靠性之间的取舍。4.2 以对话协作为核心的多智能体框架另一类框架的立场完全不同它不预设固定流程而是把多个Agent放在一个共享对话环境中让它们自由协商。这类框架更像一个开放讨论会适合探索型场景比如生成创意方案、多角度审查文档。每个Agent分配一个角色和一段个性描述通过消息机制互相通信直至达成共识或产出最终结果。这类框架的问题在于不可控性较强。自由讨论容易发散消息总量会指数级膨胀Token成本快速上涨而收敛到有效结论往往需要外部干预。调研中我见过最夸张的案例是一个多Agent辩论场景跑了40多轮烧掉了几十万Token最后还没有定论。用这种框架之前一定要想清楚你要的是写作灵感式的头脑风暴还是确定性的业务结果。如果确实要用我的建议是给协作过程设定硬性终止条件和半成品检核点。比如规定最多10轮讨论每到第5轮必须有一个阶段总结由指定Agent对现有结论做收敛性评审。工程上这会大幅缓解发散问题同时保留开放探索的优势。4.3 轻量级方案与自建系统的边界还有一种常见路径是放弃框架在自己的代码里维护一个Agent循环。这个选择的优缺点同样鲜明。好处是高度灵活可以精确控制每一步的行为不受框架抽象层的约束坏处是所有基础设施都要自己写状态持久化、重试机制、Token统计、日志追踪全得从零开始工作量大得惊人。我建议遵循“两条腿走路”的原则复杂的业务编排用成熟框架托底细节交互再通过自定义代码补足。这比纯粹自研省掉大量重复造轮子的成本也比纯粹用框架更能适配特有业务流程。落实到选型上标准答案未必存在但评估框架时可以重点看四点状态持久化能力、断点续跑支持、观测工具成熟度、社区生态活跃度。4.4 框架选型清单如果要把上面的调研浓缩成一份快速筛选清单我建议团队在选型会议上照着这几条逐项过团队对框架的熟悉程度如何这个因素往往比技术先进性更重要因为再好的框架没人会用也是白搭框架是否支持按阶段划分的流程重组和人工介入构建复杂条件分支时是否直观特别是带并行分支的情况部署和调试体验是否顺畅上线后能否快速定位问题。在项目初期也不要急着定死框架可以先分别用两三个方案搭最小验证原型各跑几个有代表性的业务场景记录完成时间、成功率和Token消耗。数据出来后再做决定比凭感觉选型靠谱得多。我自己见过多个团队因为前期选型过于草率上线后大规模重构代价远超预期的调优时间。5. 调研中踩过的坑与实测经验5.1 规划层并没有真正“规划”调研中发现一个很普遍的误解团队上了Plan-and-Execute架构就觉得规划器在认真思考每一步。实际抓日志一看很多规划器只是把任务机械地复述了一遍或者按惯例输出“第一步做A、第二步做B、第三步总结”完全没有针对性。出现这种情况的原因通常是任务输入信息不足或者模型压根没有获得足够的上下文来理解目标。解决这个问题的关键不在模型而在Prompt的引导方式。要让规划器输出真正有操作性的计划必须把约束、可用工具、资源上限和验收标准一次性说清楚必要时要给它几个高质量计划作为Few-shot示例。如果这样仍然规划质量不佳就要考虑是不是任务本身的描述就有歧义。规划器拿到含混的目标输出含混的计划执行器自然做不出好结果。建议在架构中加一个计划自检节点规划器输出计划后另外调用一次模型对计划做完整性校验检查是否覆盖了目标、是否有步骤缺失、是否有不可执行的指令。这个校验步骤的成本很低但能有效拦掉明显有缺陷的计划避免执行阶段浪费时间。5.2 多Agent消息爆炸的排查思路多Agent系统一进入自由对话模式消息量就会迅速失控。我排查过不少这类问题最典型的诱因是Agent之间互相不理解对方在说什么。A问的问题B没答上B反问AA又答非所问形成一个死循环。这类循环在日志里看起来就像两端复读机非常容易识别。排查思路第一步是给消息加分类标签是提问、回答还是总结然后把相同标签的连续消息拉出来看重点找“无信息增量”的长循环。如果循环集中在某两个Agent之间往往是它们的角色边界定义重叠导致同一件事互相踢皮球。做法是重新划分角色职责明确哪类问题归谁回答。另一个排查重点是消息长度。有些Agent回复习惯性地把整个上下文贴回去导致每轮消息越来越大最终刷新上下文即可清零。给每个Agent增加输出长度限制和“只说增量”的指令约束能显著减少消息体积。5.3 评测指标怎么设才不会骗自己做Agent系统评测最大的坑是设计了一堆自我安慰的指标。仅看“任务完成率”很容易得出“系统很好”的结论但真实用户感受其实很差因为完成率背后隐藏了“补丁打得多不多”“人工帮了几次”这些真实成本。我建议把评测拆成三个维度有效性、效率和鲁棒性。有效性看最终输出是否达到业务标准效率看完成同样任务消耗了多少调用轮次和Token鲁棒性看对脏数据、异常输入的容忍程度。每次版本迭代都要三个维度一起看单维度上升而另外两个维度明显下滑绝不能直接上线。评测集本身的构建也值得下功夫。扒一段真实业务日志把出现过问题的输入都归入回归集再补充边界情况和反向情况。理想情况下每条用例都填上“预期行为”而不是只有“预期结果”。比如一个订单处理流程预期行为是“下一步调用查库存API”而不是只要求“把订单状态改成已支付”这样模型出错时定位更精准。5.4 什么时候该放弃复杂系统这个话题在调研中其实很少被公开讨论但它非常重要。很多时候团队不是为了解决问题而是为了用上Agent而用上Agent。一个任务如果手动执行只需要两分钟、步骤固定、没有探索性那强行加Agent就是纯粹的负资产。模型推理的不可控性在这种场景里会造成比确定性代码更多的麻烦。如果任务可以写死成代码规则就用代码。如果任务需要少量参数输入和固定模板输出用传统脚本解决就好。Agent真正适用的场景是那些规则无法穷尽、步骤需要动态调整、输出质量依赖综合理解的任务。架构越复杂系统就越脆弱维护成本也越高。我个人的一个决策习惯是每次在设计复杂Agent系统之前先问团队“这个问题如果用传统软件工程手段解决卡点到底在哪”。答不上来或者答案模棱两可的就不应该上Agent。越复杂的架构越要理由充分这是调研到最后最深刻的体会。本来到这儿调研报告的核心内容就收尾了。还有一点作为给后来者的建议那几类架构和算法没有一个是一劳永逸的方案它们在具体业务里各有各的合适位置和用武之地。上线之前先把状态管理、日志追踪和评测集这三样工程地基打好后续调什么模型、换什么算法都能在稳定的底座上平滑进行。技术迭代很快但把基础设施做扎实任何时候都不会亏。