1. 从一个Agent干所有事到一群Agent各司其职的架构转折如果你最近在折腾AI Agent相关的东西大概率会有一种感觉单个Agent的能力天花板来得比想象中快。你给它挂上工具、塞进记忆、写好系统提示词它在简单任务上表现惊艳但一旦任务链条变长、涉及多个专业领域、需要反复迭代验证它就开始精神分裂——上下文越堆越乱工具调用开始互相干扰错误在链条里悄悄传播最后你拿到一个看起来像模像样但经不起推敲的结果。这不是模型不够强的问题而是架构问题。Loop Engineering循环工程这个词最近在Agent圈子里被反复提起它讲的不是某个具体框架而是一套关于如何让多个Agent在一个可控的循环里协作的工程方法论。核心思路很朴素与其让一个全能Agent硬扛不如把任务拆开让多个各有所长的Agent在明确的循环结构中分工、交接、校验、收敛。我接触多智能体协作这套东西有一段时间了从最早用单Agent硬撑到后来尝试多Agent编排中间踩过的坑足够写一本小册子。这篇文章不打算给你讲抽象概念而是把多智能体协作架构的内幕拆开——循环是怎么转的、Agent之间怎么交接、状态怎么管、并发怎么扛、错误怎么收敛以及那些只有真正跑过生产环境才会知道的细节。不管你是刚听说多智能体这个词的新手还是已经在搭Agent系统但总觉得哪里不对劲的开发者下面这些内容应该都能对上你的实际场景。2. Loop Engineering到底在循环什么2.1 循环不是简单的while循环很多人第一次听到Loop Engineering会下意识理解成写个循环让Agent反复执行直到完成。这个理解只对了一半。如果只是简单的while not done: agent.step()那确实不需要专门起个名字。Loop Engineering里的循环指的是一个带有状态、带有角色分工、带有收敛判据的协作回路。拆开来看一个完整的协作循环包含四个要素角色Role每个Agent在循环里扮演什么角色是规划者、执行者、审查者还是协调者。角色决定了它的输入是什么、输出是什么、能调用哪些工具。状态State循环每转一圈哪些信息被保留、哪些被丢弃、哪些被传递给下一个Agent。状态管理是多智能体系统里最容易翻车的地方。交接Handoff一个Agent把控制权交给下一个Agent时传递的是什么。是一段自然语言描述还是一个结构化的任务对象差别巨大。收敛判据Convergence循环什么时候停。是任务完成、达到最大轮次、还是审查者判定通过。没有明确收敛判据的循环就是死循环。我见过太多多Agent项目死在状态管理和收敛判据上。角色分得挺清楚工具也挂好了但循环转了三圈之后每个Agent拿到的上下文都不一样最后谁也不知道当前任务到底进行到哪一步了。2.2 为什么单Agent撑不住复杂任务要理解Loop Engineering的价值得先理解单Agent的失效模式。我总结下来主要是三个上下文污染。单Agent处理长任务时所有中间结果、工具返回、错误信息都堆在同一个上下文窗口里。前面一个失败的尝试会一直影响后面的判断模型会记得自己刚才走错了路然后在新一轮里表现得畏首畏尾或者反复纠结于已经排除的方案。能力耦合。一个Agent既要会规划、又要会写代码、还要会审查代码质量这三件事对提示词的要求是冲突的。规划需要发散思维写代码需要严谨审查需要挑剔。你把它们塞进同一个系统提示词里模型只能取一个折中结果每件事都做得不够好。错误传播。单Agent在链条中间犯了一个错这个错误会作为事实进入后续所有推理。它没有独立的校验环节自己审查自己往往审查不出来——因为审查用的还是同一套被污染的上下文。多智能体协作的本质就是用架构手段把这三个问题隔离开。规划归规划、执行归执行、审查归审查每个Agent有自己干净的上下文错误在交接点被拦截而不是被传播。2.3 循环工程和普通工作流的区别这里要区分一个容易混淆的概念多智能体循环和传统工作流引擎比如那些拖拽式的流程编排工具不是一回事。传统工作流的节点是确定性的——A节点做完必然走B节点B节点的输入输出格式是预先定义死的。而多智能体循环里的节点是概率性的——规划Agent可能决定跳过某个步骤审查Agent可能要求执行Agent重做协调Agent可能根据中间结果动态调整后续角色。这意味着你不能用工作流引擎那套节点连线的思路来设计多智能体系统。你需要的是循环控制逻辑谁来决定下一轮谁上场、状态怎么在轮次之间传递、什么时候判定收敛。这才是Loop Engineering真正要解决的问题。3. 多智能体协作的四种主流拓扑结构3.1 顺序流水线最简单也最容易踩坑顺序流水线是最直观的拓扑Agent A做完交给Agent BB做完交给C像工厂流水线一样。规划者出方案执行者按方案干活审查者检查结果通过就结束不通过就打回执行者重做。这个结构的好处是逻辑清晰、调试容易。每个Agent的输入输出边界明确出问题了一眼就能看出是哪个环节。适合任务步骤相对固定、每个步骤职责清晰的场景比如需求分析→代码生成→测试用例生成→代码审查这种。但它有个隐蔽的坑打回重做的成本会累积。如果审查者打回三次执行者就要重做三次每次重做都要重新消耗token和时间。更麻烦的是如果审查者的反馈不够具体执行者可能反复在同一个地方犯错。我在实际项目里遇到过审查者说代码质量不达标但不说具体哪里不达标结果执行者改了五轮都没改对最后是我手动介入把审查者的提示词改成必须指出具体行号和问题类型才解决。顺序流水线里审查者的反馈质量直接决定循环效率。反馈越具体打回次数越少。别让审查者说不好要让它说第37行的边界条件没处理。3.2 层级调度规划者执行者协调者层级调度在顺序流水线的基础上加了一个**协调者Orchestrator**角色。协调者不直接干活它负责拆解任务、分配给合适的执行者、收集结果、决定下一步。这个结构适合任务可以自然分解成子任务的场景。比如一个帮我分析这份销售数据并生成报告的任务协调者可以拆成数据清洗→统计分析→图表生成→报告撰写四个子任务每个子任务交给专门的Agent。层级调度的关键设计点是协调者的决策粒度。协调者太细每个小步骤都要它决策它自己就成了瓶颈协调者太粗只做一次任务分解就不管了那它跟顺序流水线没区别。我的经验是协调者应该在子任务边界做决策而不是在每一步操作上做决策。子任务内部怎么执行交给执行者自己决定。3.3 对等协商Agent之间互相评审对等协商拓扑里没有明确的上下级多个Agent地位平等通过互相评审来推进任务。比如两个Agent分别生成一个方案然后互相审查对方的方案指出问题各自修改直到达成一致或达到最大轮次。这个结构适合需要多视角的任务比如方案设计、创意生成、风险评估。不同Agent可以有不同的性格——一个偏保守、一个偏激进通过碰撞产生更全面的结果。但它的成本很高。N个Agent互相评审通信复杂度是O(N²)。而且如果两个Agent陷入你说我不好、我说你不好的循环没有外部仲裁者就很难收敛。我一般只在任务确实需要多视角、且能接受较高成本时才用这个拓扑。3.4 黑板模式共享状态驱动的协作黑板模式Blackboard来自经典AI领域核心思想是所有Agent共享一块黑板共享状态空间每个Agent观察黑板上的状态当发现自己能处理的部分就主动处理处理完把结果写回黑板。这个结构的优势是解耦彻底。Agent之间不直接通信只通过黑板交互新增或移除Agent不影响其他Agent。适合任务边界模糊、需要动态响应的场景。代价是控制流不明确。谁在什么时候触发哪个Agent需要一套调度机制。而且黑板上的状态如果设计不好会变成一锅粥每个Agent都往里写东西最后没人能理清状态演变过程。拓扑结构适用场景主要优势主要风险顺序流水线步骤固定的线性任务逻辑清晰、易调试打回成本累积层级调度可分解的复杂任务灵活、可扩展协调者成瓶颈对等协商需要多视角的任务结果全面成本高、难收敛黑板模式边界模糊的动态任务解耦彻底控制流不明确选哪种拓扑取决于你的任务特征。我的建议是从顺序流水线开始遇到瓶颈再升级。很多人一上来就搞层级调度甚至对等协商结果复杂度爆炸连基本的任务都跑不通。4. Agent之间的交接协议状态怎么传才不丢4.1 自然语言交接的致命缺陷最直觉的交接方式是Agent A把结果用自然语言描述出来传给Agent B。这种方式在简单场景下能用但在多轮循环里会出大问题。问题在于自然语言是有损压缩。Agent A脑子里上下文里有完整的状态但它用自然语言描述时只能描述它认为重要的部分。它认为不重要的细节被丢掉了而Agent B可能恰恰需要那些细节。更糟的是Agent A的描述里可能包含它自己的理解和推断这些理解可能是错的但Agent B会把它当成事实。我踩过的一个典型坑规划Agent把任务描述成优化数据库查询性能执行Agent理解为加索引但规划Agent实际想的是重构查询逻辑。两边对同一个词的理解不一致执行Agent加了一堆索引性能没提升反而写入变慢了。这个问题的根源就是自然语言交接的歧义性。4.2 结构化交接用Schema约束传递内容解决自然语言交接问题的办法是结构化交接。定义一个明确的Schema规定Agent之间传递什么字段、每个字段什么类型、哪些必填哪些可选。一个典型的结构化交接对象长这样{ task_id: task_001, from_agent: planner, to_agent: executor, task_type: code_generation, objective: 实现用户登录接口, constraints: [ 使用JWT做认证, 密码必须bcrypt加密, 接口响应时间200ms ], context: { existing_code: ..., database_schema: ..., api_spec: ... }, acceptance_criteria: [ 单元测试覆盖率80%, 通过安全扫描 ], max_retries: 3 }这个结构的好处是约束明确、验收标准明确、上下文完整。执行Agent拿到这个对象不需要猜测规划Agent的意图所有需要的信息都在字段里。但结构化交接也有代价Schema设计成本高。你需要预先想清楚Agent之间可能传递哪些信息设计一套能覆盖大多数场景的Schema。而且Schema一旦定下来新增字段需要改所有相关Agent的提示词。我的经验是Schema不要追求大而全先定义核心字段用扩展字段兜底。核心字段是每个交接都必须有的task_id、objective、constraints、acceptance_criteria扩展字段用context对象装里面可以放任意键值对。这样既保证了核心信息的结构化又保留了灵活性。4.3 共享内存 vs 消息传递Agent之间传递状态有两种基本模式共享内存和消息传递。共享内存模式下所有Agent读写同一个状态存储可以是一个数据库、一个Redis、或者一个内存对象。Agent A写完Agent B直接读不需要显式传递。这种模式的好处是状态一致性强不会出现A以为传了、B以为没收到的情况。坏处是耦合度高所有Agent都依赖同一个状态结构改一处要动全身。消息传递模式下Agent之间通过消息队列或直接调用传递状态。每个Agent有自己的状态只把需要传递的部分发出去。好处是解耦坏处是状态可能不一致——如果消息丢了或者顺序乱了Agent之间的状态就对不上。在实际生产环境里我倾向于混合模式核心状态任务ID、当前阶段、全局约束放共享内存保证一致性中间结果某个Agent的临时输出用消息传递保持解耦。这样既不会因为状态不一致导致循环跑飞也不会因为过度耦合导致改不动。4.4 交接时的上下文裁剪策略多智能体系统里上下文窗口是稀缺资源。每个Agent的上下文里塞太多东西不仅浪费token还会稀释关键信息。所以交接时必须做上下文裁剪。裁剪策略有三种全量传递把上游Agent的完整上下文传给下游。简单粗暴但上下文会越滚越大几轮之后就爆了。摘要传递上游Agent把上下文压缩成摘要再传。节省空间但摘要过程本身可能丢信息。按需传递根据下游Agent的角色只传它需要的信息。最省空间但需要预先知道每个Agent需要什么。我实际用的是按需传递摘要兜底。每个Agent在定义时声明自己需要哪些字段交接时只传这些字段。如果某个字段是自由文本且很长就压缩成摘要。这样既控制了上下文大小又不会丢关键信息。上下文裁剪不是可选项是必选项。我见过一个多Agent系统跑了五轮之后每个Agent的上下文都超过10万token光上下文成本就占了总成本的70%。后来加了按需传递成本直接降到原来的三分之一。5. 循环控制什么时候该停、什么时候该重试5.1 收敛判据的三种设计循环最怕的就是停不下来。设计收敛判据本质上是在回答什么情况下我们认为任务完成了。基于结果的判据审查Agent判定结果满足验收标准。这是最理想的判据但依赖审查Agent的判断质量。如果审查Agent太宽松任务没做完就放行太严格永远通不过。基于轮次的判据达到最大轮次就停。这是兜底判据防止死循环。但最大轮次设多少是个问题——设小了任务没做完就停设大了浪费资源。基于成本的判据累计token消耗或时间超过阈值就停。适合对成本敏感的场景。我的做法是三者结合审查通过就停结果判据审查不通过但达到最大轮次也停轮次判据累计成本超阈值强制停成本判据。三个判据里任何一个满足就退出循环然后根据退出原因决定后续处理——审查通过就交付轮次耗尽就标记为未完成并报警成本超限就降级处理。5.2 重试策略全量重做还是增量修复审查不通过时执行Agent需要重做。这里有个关键选择全量重做还是增量修复。全量重做是把任务从头再做一遍忽略之前的尝试。好处是干净不会受之前错误的影响。坏处是浪费——如果之前90%都做对了只错了一处全量重做等于把90%的正确工作也扔了。增量修复是只修改审查指出的问题部分。好处是节省坏处是可能引入新的不一致——改了A处B处依赖A处的逻辑就崩了。我的经验是根据错误类型选择策略。如果是局部错误某个函数写错了、某个边界条件没处理用增量修复如果是全局错误整体思路不对、架构设计有问题用全量重做。判断标准是审查Agent的反馈——如果反馈里出现整体思路架构这类词就全量重做如果反馈里是具体的行号、函数名就增量修复。5.3 死循环的识别与打断死循环是多智能体系统里最隐蔽的问题。它不像程序死循环那样CPU跑满而是Agent们礼貌地互相推诿每轮都消耗token但没有任何进展。识别死循环的信号有三个状态不变连续两轮之后共享状态里的关键字段没有变化。反馈重复审查Agent给出的反馈和上一轮几乎一样。轮次异常轮次在增加但任务完成度没有提升。打断死循环的办法是引入外部仲裁。当检测到上述信号时暂停循环把当前状态和最近几轮的交互记录交给一个仲裁Agent或者直接人工介入由它判断是继续、换策略还是终止。我在生产环境里加了一个简单的死循环检测每轮结束后计算当前状态和上一轮状态的差异度如果连续两轮差异度低于阈值就触发仲裁。这个机制帮我省了不少token。6. 并发与资源管理多Agent同时跑怎么不打架6.1 哪些环节可以并行多智能体系统不一定全是串行的。有些环节可以并行能显著缩短总耗时。独立子任务并行如果协调者把任务拆成了几个互不依赖的子任务这些子任务可以同时交给不同的执行Agent。比如生成前端代码和生成后端代码可以并行只要接口约定好了。多方案并行生成让多个Agent同时生成不同方案然后由审查Agent选最优。适合创意类任务。审查与执行并行执行Agent在生成下一部分内容时审查Agent可以同时审查上一部分。这种流水线并行能提高吞吐。但并行不是免费的。并行的代价是协调复杂度上升和状态一致性难保证。我的建议是只在子任务确实独立、且并行收益明显时才并行。如果两个子任务之间有依赖强行并行只会引入bug。6.2 并发下的状态一致性多个Agent同时读写共享状态很容易出现竞态条件。Agent A读到状态是X准备写X1同时Agent B也读到X也准备写X1。最后状态是X1但实际应该加2。解决办法有几种加锁读写共享状态时加锁保证同一时间只有一个Agent能操作。简单但会降低并发度。乐观并发控制每个Agent写状态时带上版本号版本号不匹配就重试。并发度高但实现复杂。分区把共享状态按Agent分区每个Agent只读写自己的分区。彻底避免竞态但要求状态可以自然分区。在实际项目里我用得最多的是分区关键字段加锁。大部分状态按Agent分区少数全局字段比如任务阶段、总轮次加锁访问。这样既保证了并发度又避免了关键状态的竞态。6.3 资源配额与限流多Agent系统很容易把资源打满。每个Agent都在调LLM API并发一高要么被限流要么账单爆炸。资源管理要做三件事配额分配给每个Agent或每个任务分配token配额用完就停。这能防止单个任务吃掉所有资源。限流控制并发请求数避免触发API限流。我一般会设置一个全局并发上限超过就排队。优先级不同任务有不同优先级高优先级任务优先获取资源。这在多任务共享一个Agent池时很重要。我踩过的一个坑没做配额管理一个失控的循环在半小时内烧掉了几百万token。后来加了每任务token上限和全局并发上限再也没出现过这种情况。资源管理不是优化项是必需项。7. 错误处理与可观测性出问题了怎么查7.1 多Agent系统的错误分类多Agent系统里的错误比单Agent复杂因为错误可能发生在多个层面Agent内部错误单个Agent的LLM调用失败、工具调用失败、输出格式不符合Schema。交接错误Agent A传给Agent B的信息不完整、格式错误、或者语义有歧义。循环控制错误收敛判据失效、死循环、轮次计算错误。状态错误共享状态被污染、状态不一致、状态丢失。不同层面的错误需要不同的处理策略。Agent内部错误通常重试就能解决交接错误需要修正Schema或提示词循环控制错误需要调整判据状态错误需要回滚或重建状态。7.2 日志与追踪每个Agent的输入输出都要留痕多Agent系统出问题时最难的是定位是哪个环节出的错。所以全链路追踪是必须的。每个Agent的每次调用都要记录输入是什么、输出是什么、耗时多少、消耗多少token、调用了哪些工具、工具返回什么。这些记录串起来就是一条完整的执行链路。我用的是一个简单的追踪方案每个任务一个trace_id每次Agent调用生成一个spanspan里记录上述信息最后把所有span按时间顺序串起来。出问题时按trace_id一查整条链路一目了然。追踪的粒度要适中。太粗了查不出问题太细了日志量爆炸。我的经验是Agent级别的输入输出必须记工具调用级别的输入输出按需记。工具调用如果涉及外部系统数据库、API必须记如果是纯计算可以不记。7.3 失败恢复从哪个检查点继续多Agent任务跑到一半失败了是重头再来还是从检查点继续如果任务耗时很长重头再来成本太高就需要检查点机制。每完成一个阶段把当前状态存下来。失败后从最近的检查点恢复而不是从头开始。检查点的设计要点是状态要完整。不仅要存任务数据还要存循环状态当前轮次、已尝试的方案、审查反馈历史。否则恢复后Agent不知道之前发生过什么可能重复之前的错误。但检查点也不是越多越好。存检查点本身有成本恢复时加载检查点也有成本。我一般只在阶段边界存检查点不在每个Agent调用后都存。8. 生产环境落地的几个硬核经验8.1 提示词版本管理多Agent系统里每个Agent的提示词都是一份代码。提示词改了Agent的行为就变了。如果没有版本管理改出问题都不知道回滚到哪个版本。我的做法是提示词和代码一起进版本控制。每个提示词文件有版本号Agent调用时记录用的是哪个版本。出问题时可以对比不同版本的提示词定位是哪次修改引入的问题。更进一步可以做A/B测试同一个Agent同时跑两个版本的提示词对比效果。这在优化提示词时特别有用。8.2 成本控制的实际手段多Agent系统的成本比单Agent高因为Agent数量多了、循环轮次多了、上下文传递多了。控制成本要从几个方面入手上下文裁剪前面说过按需传递摘要兜底能省大量token。模型分级不是所有Agent都需要用最强的模型。规划Agent和审查Agent可以用强模型执行Agent里简单的部分可以用弱模型。缓存相同的输入可以缓存输出避免重复调用。特别是审查环节如果两次审查的输入一样直接返回缓存结果。提前终止审查通过就停不要为了多跑几轮更保险而浪费资源。我实测下来做好这四点多Agent系统的成本可以控制在单Agent的1.5到2倍而不是想象中的5倍10倍。8.3 人工介入的时机与方式多Agent系统不是完全自动的。有些情况下必须人工介入死循环检测触发前面说过连续两轮状态无变化时触发仲裁。高风险操作涉及删除数据、修改生产配置等操作必须人工确认。成本超限任务成本超过阈值暂停等人工决定是否继续。质量不达标审查Agent连续多轮判定不通过可能需要人工看看是任务本身有问题还是Agent能力不够。人工介入的方式要设计好。最好是异步介入——系统暂停发通知给人工人工处理完再恢复。不要设计成同步阻塞否则人工不在线时整个系统就卡住了。8.4 从单Agent迁移到多Agent的渐进路径如果你现在有一个跑得还行的单Agent系统想迁移到多Agent不要一次性重构。我的建议是渐进式迁移第一步把单Agent里最独立的一个环节拆出来做成一个独立的Agent。比如把代码审查从主流程里拆出来做成一个专门的审查Agent。这样改动最小风险可控。第二步观察拆分后的效果。如果审查质量提升了、主流程上下文变小了说明拆分方向对。如果没提升甚至变差了说明这个环节不适合拆。第三步继续拆下一个环节。每次只拆一个拆完观察稳定了再拆下一个。第四步当拆出三个以上Agent后引入协调者来管理它们之间的交接。这个路径的好处是每一步都可回滚。拆坏了就退回去不会影响整个系统。9. 我对多智能体协作的一点个人判断跑了这么多多Agent项目我最大的体会是多智能体不是银弹它解决的是特定类型的问题。任务链条长、需要多专业能力、对错误传播敏感的场景多Agent架构能带来明显提升。但如果任务本身很简单硬上多Agent只会增加复杂度和成本。另一个体会是架构设计比模型选择更重要。我见过用同样的模型因为架构设计得好多Agent系统表现远超单Agent也见过用最强的模型因为架构混乱多Agent系统还不如单Agent。Loop Engineering这套方法论的价值就在于它把架构设计的经验沉淀下来了——循环怎么转、状态怎么传、错误怎么收敛这些问题的答案不依赖于你用哪个模型。最后说一个容易被忽视的点多Agent系统的调试成本远高于单Agent。单Agent出问题你看一遍上下文就知道哪里错了。多Agent出问题你要在多个Agent的上下文之间来回跳还要理清它们之间的交接关系。所以可观测性不是可选项是必选项。在搭多Agent系统之前先把日志和追踪做好后面会省很多事。如果你正准备上手多智能体协作我的建议是先用顺序流水线跑通一个最小闭环把交接协议和收敛判据设计好再考虑更复杂的拓扑。别一上来就搞层级调度和对等协商那些是给已经跑通基础架构的人用的。基础不牢拓扑越复杂翻车越快。
