Loop Engineering：多智能体协作架构内幕与最佳实践

把多个大模型塞进一个系统里，让它彼此对话、分工、反复确认，这几乎是当下所有"高级 Agent"产品背后的真实形态。但你如果真的动手搭过一套多智能体系统，很快就会撞上几个很朴素的问题：怎么把任务切给不同的 Agent？它们之间的上下文怎么传？谁来判定"这件事做完了"？出错的时候错误是在哪一层被放大的？

这些问题的集合，我倾向于叫它 Loop Engineering（循环工程）。它本质上不是"怎么调 prompt"的问题，而是把传统的控制流、数据流、状态机，套在了带不确定性的大模型能力之上。单一 Agent 的工程难点是上下文管理和工具调用，多 Agent 的难点则是编排、交接、收敛和成本。

这篇文章不聊产品叙事，只聊机制。我会先讲单 Agent 的天花板在哪，再拆解四种主流多 Agent 拓扑，然后深入 Loop Engineering 的五个核心构件，最后给出评估、调试方法和我认同的最佳实践。

一、为什么单 Agent 不够

很多团队一开始都用单 Agent 顶所有事：一个 system prompt 写满角色设定，挂一堆工具，靠 ReAct 式的"思考-行动-观察"循环往前推。这种做法在中等复杂度任务上能跑，但撞到真实的企业级长任务时，有四个硬约束绕不开。

上下文窗口的物理上限。模型一次能看到的 token 是有天花板的。一个调研类任务，光是把相关网页、文档、代码仓的片段喂进去，就能轻松撑爆 200k 的上下文。更麻烦的是，长上下文里模型的有效注意力会稀疏化，越靠后的指令越容易被前面堆积的内容稀释。单 Agent 被迫在"截断历史"和"丢失指令"之间做取舍，这个取舍本身就是架构缺陷，不是调参能解的。

专注度的稀释。让一个模型同时负责规划、检索、计算、写作、校验，等于让它在一轮推理里扮演五个角色。角色越多，每个角色能分到的注意力预算越少，质量就线性下滑。更隐蔽的问题是"指令竞争"：你让它"既要全面又要简洁还要严谨"，这几条要求会互相打架，模型在不同 token 位置上会偏向不同目标，输出变得忽好忽坏、难以复现。拆成专注单一目标的子 Agent，等于把互相冲突的约束分到不同的决策单元里，各自只需要满足一个清晰的目标函数。Anthropic 在构建多智能体研究系统时明确验证过这一点：把"规划者"和"执行者"的上下文拆开，让各自只看自己该看的东西，任务质量显著提升。隔离注意力，是提升质量最直接的手段。

长任务的状态漂移与错误累积。单 Agent 跑一个几十步的长任务，前面某一步犯了个小错，后面每一步都在这个错误之上继续推理，错误被层层放大，最后输出跑偏还很难定位是哪个环节出的问题。这就是所谓的 error compounding。多 Agent 之所以能缓解，是因为每一步可以由一个 freshly 初始化的子 Agent 去做，它拿到的是上游压缩过的结论，而不是被前面所有错误污染过的原始上下文。

能力与风险的耦合。所有工具、所有知识、所有权限都挂在一个 Agent 身上，一旦它判断失误，造成的是全局性后果（比如误删库、误发消息）。拆分之后，写代码的 Agent 不需要有发邮件的权限，权限和责任可以更细粒度地隔离。

我的看法是，单 Agent 不是不能用，而是它的适用边界很清楚：任务能在几十步内收敛、上下文能装下、出错代价可控。一旦任务超出这个边界，靠堆 prompt 只会让系统越来越脆，真正的杠杆是架构层面的拆分。

二、四种主流多 Agent 拓扑

多 Agent 系统怎么连，决定了它的隔离性、并行度、错误传播路径和调试难度。业界实践里反复出现的有四种拓扑，它们不是互相替代的关系，而是各自解决不同结构的问题。

流水线（Pipeline）。把任务切成一串顺序环节，每个环节是一个专精的 Agent：A 做抽取，B 做归纳，C 做校验，数据像工厂流水线一样往后传。它的好处是职责单一、容易预测、上下文隔离最彻底；坏处是不能并行，上游卡住下游全停，而且对需要来回推敲的任务不适用。它最适合"输入输出结构已被先验知识固定"的场景，比如"从一叠合同里抽取关键条款再生成结构化报告""多步 ETL 后做分层摘要"。什么时候别用？当环节之间需要反复回看前序结果、或者某环节可能发现前序错误需要返工时，纯流水线会非常僵硬，你得在外面再套一层协调逻辑，那就退化成了主管-下属。

主管-下属（Manager-Worker / Orchestrator-Workers）。这是一个中枢 Agent（Orchestrator 或 Lead）负责任务分解、派发、结果合并，下面挂一群在各自上下文窗口里独立工作的子 Agent。Anthropic 的多智能体研究系统用的就是这套范式：Lead 把一个研究问题拆成若干有明确定义的子问题，每个子 Agent 在自己的上下文里并行检索、阅读、写报告，最后 Lead 把结果汇总。它的核心优势是并行与隔离兼得，子 Agent 的错误被限制在局部，主 Agent 通过合并逻辑做一道过滤。代价是主轴 Agent 成为瓶颈和单点故障，且 token 消耗远大于单 Agent（实测约 15 倍）。一个工程上容易忽略的点是：主管的"合并"本身也是一次 LLM 调用，它要能看懂所有子结论再综合，这要求主管上下文足以容纳浓缩后的全局状态，所以子 Agent 的回传质量直接决定主管会不会变成新的瓶颈。

辩论/评审（Debate / Critic）。让两个或多个 Agent 围绕同一问题给出方案，再由一个评审者或投票机制收敛。它对应着一篇叫 "More agents is all you need" 的工作的核心思想：通过"采样-投票"让性能随 Agent 数量提升，本质是利用多个独立采样的"森林"来对冲单次推理的随机性偏差。这套范式在"答案对错高度敏感"的场景（如数学验证、安全审查）里特别有效，但成本随 Agent 数线性上涨，且只在任务难度足够高时收益才明显。

共享黑板（Blackboard）。所有 Agent 不互相直接通信，而是读写一块共享的状态空间（黑板）。每个 Agent 看到黑板后决定自己能干点什么，写回自己的贡献，系统随黑板的演进而推进。它适合那些"问题结构在运行前完全未知、需要 emergent 协作"的开放任务，但最难点在于黑板的冲突解决和收敛判定，工程上最容易失控。

把四种拓扑放在一起看，你会发现一个清晰的取舍轴：隔离性越强、越串行（流水线），越可控但越慢；共享越开放（黑板、辩论），越能 emergent 出好结果，但越难收敛和调试。选型时先问自己两个问题：子任务之间有没有强依赖？错误被放大一次我能不能承受？答案决定了你该往轴的哪一端走。

三、Loop Engineering 的五个核心构件

拓扑只是骨架。决定一套多 Agent 系统能不能用的，是循环本身怎么设计。我把 Loop Engineering 拆成五个构件，缺一个系统就会在某个维度塌掉。

任务分解（Decomposition）。主管 Agent 拿到一个目标，第一步要切出子任务。关键在于"显式 scope"：每个子任务必须带清晰的输入定义、产出格式、成功判据和边界，不能只丢一句"你去研究一下 X"。Anthropic 的经验是，主管在派发前就要把子问题的范围写死，子 Agent 才不会跑偏。分解的粒度要随查询复杂度缩放：简单问题一个 Agent 直出，复杂问题才值得拆成几十个子任务。过早分解是浪费，过粗分解则失去了隔离的意义。

交接（Handoff / Context Condensation）。子 Agent 干完活，怎么把成果交回给主管？如果原样把整个上下文回传，主管的窗口一样会爆。正确做法是子 Agent 在自窗口里完成"浓缩"：只回传结论、关键证据引用和必要的元信息，把原始检索内容留在自己那里。这就是所谓 context isolation + condensation。举个具体例子：子 Agent 读了四十篇网页，回传时不该把四十篇全文贴回去，而是回传"关于 X 的三个结论，分别引用 page-12 的第 3 段、page-27 的图表、page-31 的引述"，主管若要深究再去取原文。交接协议的设计直接决定主管能并行管理多少个子 Agent，也决定错误是就地被压缩掉，还是被原样带入上层。一个有用的经验是：交接内容里强制要求附"置信度"和"未覆盖的子问题"，让主管能识别哪些地方还需要补洞。

循环迭代（Loop Iteration）。主管拿到所有子结果后，并不是总能一次收敛。它可能需要根据已有结论再派生新的子任务（比如发现某个子问题答案矛盾，于是派一个新 Agent 去交叉验证），这构成了循环。每一轮循环都要有明确的"本轮目标"和"本轮增量"，避免无谓重算。Loop 的价值在于让系统具备"发现缺口、主动补洞"的能力，而不是一次性的静态编排。

终止条件（Termination）。这是多 Agent 系统最容易翻车的地方。没有显式终止判据，系统要么过早停（答案不全），要么陷入无限循环（反复派生子任务、反复检索）。可靠的终止条件通常是组合式的：所有子任务都被标记为完成、多轮之间结论增量低于阈值、或硬性预算（轮次上限、token 上限）耗尽。这里的"增量阈值"很关键：主管在汇总完一轮后，要能判断"这一轮相对上一轮，新增的有效信息是否值得再开一轮"。如果增量趋近于零，继续循环只是在烧 token。我的建议是永远给预算兜底，哪怕是粗粒度的最大轮次，也比没有强，因为预算是最后一道防呆墙，保证任何逻辑漏洞都不会让系统真的跑飞。

错误传播（Error Propagation）。当某个子 Agent 返回了明显错误的结论，主管要能识别而不是照单全收。常见机制有三层：子 Agent 自带自检（返回 confidence 或显式"我无法确认"）、主管做一致性交叉验证、以及全局的回退路径（重新派发、或降级到人工）。关键是错误要能被"标记"而不是"静默合并"，否则一个错误子节点的输出会污染整个汇总结果。

这五个构件合起来，其实就是把软件工程里"控制流 + 数据依赖 + 异常传播"的那一套，重新用大模型的不确定性语义实现了一遍。差别在于传统工程的每一步是确定的，而这里的每一步都有概率，所以你必须在循环里显式处理"可能错"这件事。

四、通信与状态共享

多 Agent 跑起来之后，最常被低估的难题是"它们怎么知道彼此在做什么"。通信协议和状态共享方式，直接决定了系统的可观测性和调试难度。

上下文隔离与共享的权衡。主管-下属范式里，子 Agent 之间默认不共享上下文，这是隔离错误、控制成本的关键。但有些任务需要子 Agent 看到彼此中间产物（比如一个写代码、一个写测试，测试方需要看代码草稿）。这时候纯隔离就不够，需要显式的共享通道。设计原则是：共享默认关闭，需要时才开，且共享内容经过浓缩而非原始上下文。

消息协议。不管用什么框架，Agent 之间传递的应该是结构化的"消息"而非自然语言独白：带上 sender、target、task_id、payload、status 字段。结构化让你可以 replay、可以审计、可以在任意节点注入 mock。把它当成微服务之间的 RPC 来理解就行，区别只是 payload 里塞的是自然语言结论而不是强类型对象。

状态机与共享黑板。复杂的长任务最好有一层显式的状态机：哪些子任务 pending、running、done、failed，全局可见。黑板模式就是把这层状态外置成一个可被所有 Agent 读写的存储。状态外置的好处是系统变成了可观测的，坏处是引入了并发冲突，需要定义清楚"谁有资格标记某条状态为完成"。

预算与令牌治理。多 Agent 系统的一大隐性成本是 token。一个主管加几十个子 Agent，token 用量轻松是单 Agent 的十几倍。所以通信层通常要带预算器：每个子任务有 token 上限，主管有全局上限，超限就强制收敛或降级。把成本当成一等公民来管理，而不是跑完再看账单。

五、评估与调试：非确定性会被放大

多 Agent 系统最反直觉的一点是，单 Agent 的不确定性和错误，在多 Agent 里不是被平均掉，而是经常按拓扑结构被放大。评估与调试必须针对这一点专门设计。

非确定性的放大效应。单层采样有随机性，多 Agent 里每个节点都有随机性，而且它们通过交接层层传递。一个 90% 准确率的子 Agent，如果它的错误结论被三个下游 Agent 当成事实引用，最后系统的有效准确率可能远低于 90%。所以评估不能只看最终输出，要逐节点测每个 Agent 在它职责范围内的准确率，定位是哪个环节是 bottleneck。"More agents"能提升整体，前提是单个 Agent 本身足够准，否则只是把噪声放大了更多倍。

死循环与抖动。没有好终止条件的系统会出现两类病态：一是子任务不断派生新子任务，无限递归；二是两个 Agent 反复就同一结论来回确认、互相反驳，永远不收敛。调试时要在循环里埋"轮次计数"和"结论 delta 监控"，一旦 delta 连续几轮趋零或为负（在反复推翻自己），就强制终止。

成本爆炸。前面提过 token 是单 Agent 的约 15 倍，这是架构带来的固有开销。调试成本问题优先看三点：是不是对简单查询派了过多子 Agent（Anthropic 早期就犯过"简单问题起 50 个子 Agent"的错）、子 Agent 有没有在回传前做好浓缩、主管有没有被同步瓶颈卡住导致空转等待。

评估方法。实践里最管用的是 LLM-as-judge 配合 rubric：先写清楚"好答案"的评分维度（全面性、准确性、引用质量、结构），再让一个较强的模型按 rubric 打分，而不是只看最终对错。早期用约 20 个有代表性的 case 就能发现问题，再逐步扩到几百个。人工要重点盯"引用质量"这种模型评委容易漏的维度。这里有个细节：评委模型要有明确的评分标准，否则它给出的分数噪声比系统本身还大。

可观测性是调试的前提。每一轮循环、每一次交接、每个子 Agent 的完整输入输出，都要落盘可回放。出了问题才能像查分布式系统日志一样，定位是哪条消息触发的偏移。没有 tracing 的多 Agent 系统，出事时你只能瞎猜。实践中建议至少记录四类事件：任务派发（task_id、scope、目标 Agent）、任务完成（耗时、token、置信度、回传摘要）、循环收敛（本轮相对上轮的 delta、终止原因）、异常（失败、超时、超限）。这四类事件构成一张完整的因果链，任何跑偏都能顺着链回溯到根因。

还有一个容易被忽视的工程细节：想让评估稳定，首先要让系统尽量可复现。大模型本身有采样随机性，所以关键路径上（尤其是评委和主管合并环节）应明确 temperature 设置，必要时对核心判定逻辑做低温度采样，对探索性子任务才放开。把"随机"和"确定"分层管理，评估才有意义。

六、最佳实践与反模式

最后把上面所有内容收敛成一份可以直接对照的清单。

值得坚持的做法。显式写死每个子任务的 scope 和成功判据，别指望模型自己猜你的意图。子 Agent 之间默认上下文隔离，只在确有依赖时开共享通道。回传内容必须先浓缩再上交，保护主管的窗口。给循环加组合式终止条件，且永远有预算兜底。把成本当成一等公民，每个子任务带 token 上限。评估用 rubric 加 LLM-as-judge，并逐节点测准确率而不是只看终态。全链路埋 tracing，确保任意一步可回放。

需要警惕的反模式。简单问题起一堆子 Agent，把并行变成纯开销。主管既是规划者又亲自干执行，导致主干成为瓶颈和单点故障。没有终止条件，或者终止条件只靠"我觉得完了"，结果陷入循环。子 Agent 把原始上下文原样回传，主管窗口迅速溢出。角色边界模糊，一个 Agent 又写代码又做安全审查又发消息，权限和责任全糊在一起。只在最终输出做评估，一旦跑偏完全无法定位是哪层的问题。

我的看法是，Loop Engineering 的难不在"让 Agent 说话"，而在让这套带概率的系统像确定性的分布式系统一样可信。你要设计的不是对话，而是控制流、数据依赖、异常传播和成本治理。拓扑选型解决了"怎么连"，五个核心构件解决了"怎么转"，通信与状态层解决了"怎么察"，评估与调试解决了"怎么信"。四块都补齐，多 Agent 系统才从 demo 走向能扛真实负载的工程。

单 Agent 是刀，多 Agent 是流水线工厂。工厂比刀能造更复杂的货，但工厂自身就是一门工程。这一篇聊的，就是这门工程最本质的骨架。