公众号名称：看山 Agent 架构

作者名称：看山Agent架构

发布时间：2026-06-12 19:45

本文是agent集群模式系列的下篇，承接什么是Agent集群的四种设计模式？一文讲清

旨在讲清智能体集群四种模式之间的区别与联系、适用场景、设计思路、注意事项及枢衡的实践与探索。

一、四种模式不是并列选项，而是一条控制权下放路径

上一篇文章讨论了 Agent 集群的四种设计模式：路由、委托、辩论、群体:

什么是Agent集群的四种设计模式？一文讲清

那篇文章回答的是”有哪些模式”。

但真正关键的问题不是列举模式，而是理解它们之间的关系。

四种模式不是横向并列的四个按钮，供系统架构师根据偏好随意挑选；而是一条控制权逐步下放的路径，每一步都建立在前一步的能力基础之上，每一步也都引入新的治理挑战。

从控制论的视角来看，这条路径的本质是从”控制 Agent”走向”设计环境”。

低阶系统要求中心安排每一步：任务谁来接、怎么分解、哪一步该做什么，都需要中心显式指令。

成熟系统则要求中心设计规则、状态、边界和反馈，让 Agent 在局部互动中形成更高层次的协作秩序。

中心不是消失，而是改变位置：从台前指挥者变成后台环境设计者。

这种转变类似于组织管理学中从”命令-控制型”向”赋能-平台型”的演进：中心不再直接指挥每个执行动作，而是通过设计激励机制、信息结构和决策边界，让分布式节点自主形成有效协作：

• 路由模式解决”谁来做”。系统仍然掌握入口控制权，任务到来后由中心判断应该分配给哪个 Agent。这是最基础也最直接的控制形式：中心保留着对任务入口的完全掌控，每一个任务都必须经过中心的识别和分发才能进入执行层；

• 委托模式解决”怎么做完”。中心不再逐步指挥，而是给出目标、边界和验收标准，让专家节点独立完成闭环。这里的控制权下放体现为中心交出”过程控制权”，但保留”目标定义权”和”结果验收权”；

• 辩论模式解决”做得对不对”。系统承认单点推理不可靠，于是引入反方、审查者和裁决者，通过结构化对抗来暴露盲区和错误；

• 群体模式解决”问题还没定义清楚时，如何让答案长出来”。中心退到更后面，通过环境、规则、状态和反馈培育涌现——这里中心甚至连”正确答案”都不知道，只能设计一个能让正确答案自行生长的环境。

这条控制权下放路径与软件工程中的委托模式有深层共鸣。

在面向对象设计中，委托模式允许对象将部分职责转交给其他对象，从而避免继承带来的紧耦合。

类似地，Agent 集群中的委托不是简单的任务转发，而是控制权的结构性转移：中心从”执行者”转变为”协调者”，从”做事”转变为”确保事被做成”。

这种转变带来的不仅是效率提升，更重要的是系统复杂度的管理方式发生了变化：低阶系统用中心化的复杂度来管理分布式执行，高阶系统用分布式的自治来消化复杂度，中心只保留必要的治理复杂度。

这个判断来自枢衡的真实实践。我们最初用角色分工解决任务路由，用SDC（战略决策者）、RDD（信息采集者）、CAD（审议与风控者）、EMD（流程统筹者）、EOD（交付执行者）五个角色分别承接战略、信息、审议、统筹和交付。

随后我们发现，仅有分工不足以保证质量：Agent 会犯错、会幻觉、会用旧材料审新事实、会在长上下文中遗忘关键约束。

于是逐步引入SSoT单一事实源、G1-G5五级质量门、信誉账本、Source Sync事实同步协议、上下文治理和 Skill 自进化治理。

换言之，模式演进不是理论推演，而是在一次次错误、返工、审议和接管中被逼出来的。

每一次治理机制的引入，都对应着一次真实任务中的失败教训；每一次控制权的下放，都伴随着新的失控风险的暴露和应对。

模式	核心问题	中心控制什么	中心下放什么
路由	谁来做	入口分配权	无
委托	怎么做完	目标、边界、验收标准	过程控制权
辩论	做得对不对	规则、裁决权	判断权
群体	答案如何涌现	环境、规则、反馈	执行顺序、具体答案

这张表格揭示了四种模式之间深层的递进关系。

路由模式下中心仍然紧握入口控制权，系统本质上还是”中心决策、节点执行”的星型结构。

委托模式迈出了控制权下放的第一步:中心不再关心”怎么做”，只关心”做成什么样”。

辩论模式进一步承认：即便中心定义了验收标准，单个 Agent 的自检仍然不可靠，需要引入外部对抗来检验质量。

群体模式则是最大程度的放手:中心甚至不预设答案，只设计让答案能自己长出来的土壤。

这条路径的每一步都在回答同一个问题：【在不失控的前提下，中心还能把多少控制权交给分布式节点？】

---

二、路由模式：中心掌握入口控制权

路由是 Agent 集群最基础的协作形态。

它的核心问题是：任务来了，应该交给谁？

这个问题看似简单，却是整个集群协作秩序的第一道闸门。

如果路由判断出错，下游执行再努力也只是把错误方向做得更完整：让不擅长写深度分析的 Agent 去写 L4 长文，产出再长也是泛泛而谈；让缺乏事实核查能力的 Agent 去补充证据，补充再多也可能是幻觉包装成的”证据”。

因此，路由模式的价值不在于完成任务本身，而在于把任务放到正确的能力节点上。

在主流 Agent 框架中，路由模式的实现方式各异，但其核心思想一致。

• OpenAI 的 Swarm 和 Agents SDK 采用显式切换（Explicit Handoff）机制：每个 Agent 配置一组可切换目标，当当前 Agent 判断任务需要其他角色的能力时，显式调用切换函数将控制权转移给目标 Agent 。

• AutoGen 在此基础上扩展了状态化切换（Stateful Handoff）：切换时不仅传递任务描述，还传递完整的对话历史，确保接收 Agent 拥有足够的上下文继续处理。这种设计在概念上可以建模为一个有向图G = (V, E)，其中顶点 V 代表 Agent 集合，边 E 代表可能的切换路径，每条边附带自然语言描述以指导路由决策 。

• CrewAI 则采用层级委托模型，Orchestrator 作为中心协调者全程掌控，通过DelegateWorkTool将子任务分配给专家 Agent，所有 Agent 间通信都通过中心节点进行，形成典型的 Hub-and-Spoke 拓扑 。

在枢衡中，路由首先体现为五角色分工体系。

• RDD（Research & Data Dispatcher）负责信息采集与事实核查，

• CAD（Critical Analysis & Defense）负责审议、风控与反论，

• EMD（Execution & Milestone Director）负责流程设计与质量门控制，

• EOD（Execution & Output Deliverer）负责最终内容生成与交付，

• SDC（Strategic Decision Coordinator）负责战略框架制定与终裁。

这个分工让任务不再被一个通用 Agent 直接吞下：“通用”意味着没有特长，没有特长的 Agent 在处理复杂任务时往往只能给出平均水平的输出。

角色识别是路由的第一道工序：这是证据任务、审议任务、写作任务、调度任务，还是战略判断任务？不同性质的任务需要不同的认知能力组合，路由的作用就是匹配任务性质与 Agent 能力。

路由的优势是效率。

任务清楚、边界明确时，路由模式能显著减少沟通成本。

生成 Word 文档、补充外部证据、核对引用标题、设计执行流程等等，这些任务都有明确的输入输出格式，路由后由对应角色直接处理，无需多轮协商。

AutoGen 的显式切换机制在实践中被证明能提供清晰的审计轨迹，每次切换都是离散的决策点，安全推理可以在这些决策点介入评估切换是否合适。

但路由的弱点也同样明显：路由器本身会成为单点瓶颈。

若 L4 深度长文被误判为普通写作任务，直接交给 EOD，文章可能结构完整、语言流畅，却缺少证据支撑、反论审视和实操深度。

这种”降级路由”错误的代价往往比”升级路由”更高：把简单任务路由给复杂角色的成本只是资源浪费，把复杂任务路由给简单角色的成本则是质量灾难。

因此，成熟的路由不是简单分派，而是任务分级。

枢衡将任务区分为 L1 到 L4 四个层级：

• L1 简单任务可以单点处理，如格式转换、信息提取；

• L2 执行型任务适合调度模式，如按模板生成文档、批量数据处理；

• L3 分析型任务需要 RDD、CAD、SDC 多角色协作，如研究报告、竞品分析；

• L4 战略型和创新型任务才进入群体模式，如框架设计、机制创新、复杂博弈分析。

路由模式的第一条纪律是：不要把所有任务都升级为群体，否则通讯熵增会拖垮效率；也不要把复杂任务降级为单点写作，否则质量无法保证。

这种分级思想与软件工程中的”复杂度匹配原则”一脉相承，用最简单的架构解决简单问题，只在必要时引入复杂度。

路由模式仍然是四种模式中控制感最强的模式。

中心决定谁开始、谁参与、谁等待，掌握着任务分配的完全自主权。

但这并不意味着它”低级”。真正成熟的集群不会抛弃路由，而是把路由作为底层能力内嵌到系统中。

没有路由，群体会变成无序聊天，所有 Agent 同时说话，没有秩序，没有分工，没有入口筛选；有了路由，集群才有进入更复杂模式的入口秩序。

LangGraph 等框架通过状态机实现确定性路由：每个 pipeline 阶段对应一个节点，阶段间的转移通过显式条件边编码，基于类型化的状态属性进行路由决策 。这种设计确保了对于给定的 pipeline 版本和输入状态，节点遍历序列是可复现的，路由不再是黑盒判断，而是可审计、可追溯的显式决策。

然而，纯路由模式的天花板也很清晰：

当任务需要多角色深度协作、需要反复迭代打磨、需要动态调整执行策略时，仅靠中心的路由判断是不够的。中心不可能预判每一步该让谁参与，也不可能预先知道哪个环节会出问题需要额外审查。

这就是为什么必须从路由走向委托：把过程控制权从中心下放给专家节点。

---

三、委托模式：把过程控制权交给专家

路由只解决”把任务交给谁”，委托解决”交出去之后怎么保证交付”。

这是一个质的跃迁：路由模式下中心仍然通过频繁的切换指令控制着执行节奏，委托模式下中心则完全退出过程干预，只保留目标定义权和结果验收权。

委托意味着中心不再控制每一步，而是定义目标、边界、输入、输出和验收标准。

它是从”我来做”到”你负责闭环”的转变，也是集群架构从”中心驱动”向”节点自治”演进的关键一步。

在软件工程理论中，委托模式是一种基本的设计原则：对象将部分职责转交给其他对象，从而在不引入继承耦合的前提下实现功能复用和职责分离。

这一原则在 Agent 集群中的映射非常自然：中心将特定领域的执行职责委托给专家 Agent，专家 Agent 在其能力边界内自主决策如何完成任务。

但软件对象与Agent 之间存在本质差异：对象的行为是确定的、可预测的，而 LLM Agent 的行为是概率性的、上下文依赖的，且存在幻觉和能力漂移等风险。

这意味着 Agent 集群中的委托不能是简单的”调用-返回”，必须包含更丰富的契约机制和更严格的质量保障。

在枢衡中，委托无处不在，且每种委托都有明确的输入契约、输出契约和验收标准：

• RDD 被委托补充外部证据时，必须提供标题、作者、年份、链接、关键结论、可支撑什么主张、不能支撑什么主张，这不是”请帮我找点资料”的模糊请求，而是有严格格式要求的结构化输出；

• CAD 被委托审议时，不是泛泛地”提点意见”，而是必须检查事实源可靠性、角色边界合规性、逻辑链完整性和风险暴露度；

• EMD 被委托制定 G1-G5 流程时，需要明确每个质量门的进入条件、检查清单和通过标准；

• EOD 被委托成稿时，必须等待 SSoT 素材包齐备，不得自行补脑，这是防止写作 Agent 为追求文章流畅而脑补事实的关键约束。

委托的核心风险是黑箱。

中心把任务交出去后，执行过程可能不可见、不可控、不可预测。

• RDD 可能用不完整引用包装成看似充分的证据，比如给出一个真实的论文链接，但对其结论做过度解读；

• EOD 可能把不确定内容写得更确定比如将”可能有效”表述为”已被证明”，因为确定性的表述在文章中更流畅；

• CAD 可能因旧上下文污染而误审，比如用上一轮任务中获得的印象来评判当前任务，而没有意识到事实已经更新。

这些风险不是假设，而是在枢衡的实践中确实出现的问题。

委托不是放任。委托越深，越需要契约化输入和验收标准。

枢衡在委托模式中引入四层保障机制：

• 第一层是任务包（Task Package）。任务包明确定义目标、边界、输入素材、输出格式和完成标准。它不是自然语言的”请帮忙写篇文章”，而是结构化的需求文档：目标读者是谁、文章类型是什么、必须包含哪些要点、不能触及哪些话题、引用格式要求、字数限制等。任务包的作用是在委托发生时就消除歧义，让执行 Agent 对”什么算完成”有清晰认知。

• 第二层是 SSoT素材包。SSoT 定义当前任务的唯一事实源，明确哪些信息是经过验证可用的、哪些信息是待定需要补充的、哪些信息是禁止使用的。EOD 成稿时必须基于 SSoT，不得引用 SSoT 之外的事实；RDD 补充证据时必须更新 SSoT，确保新补充的事实被纳入统一事实源。SSoT 的存在解决了多 Agent 协作中最常见的事实不一致问题：如果没有唯一事实源，每个 Agent 可能基于不同版本的信息工作，最终产出的内容会在事实层面自相矛盾。

• 第三层是 G1-G5 质量门。G1 是任务理解门：确认 Agent 是否正确理解了任务需求；G2 是素材完备门：确认输入素材是否齐备、事实源是否可靠；G3 是初稿完成门：确认初稿是否按要求完成；G4 是审议门：由 CAD 对内容进行多维度审议；G5 是终裁门：由 SDC 做最终验收。每个质量门都有明确的进入条件和通过标准，Agent 不能跳级，不能自我豁免。质量门的作用是将长周期的委托切分为可验证的短周期，让中心在每个阶段都能确认方向正确，而不是等到最后才发现偏离。

• 第四层是 HITL。人类保留对重大争议的裁决权。当 Agent 之间出现无法自动协调的分歧、当质量门反复失败、当任务涉及高风险判断时，系统会将决策权上交人类。HITL 不是对委托的否定，而是委托体系的安全阀：它确保了在最坏情况下，系统不会在没有人类知情的情况下做出重大错误决策。

委托模式让专家节点获得过程控制权，但不获得事实豁免权。

RDD 的证据仍需 Source Sync 验证，CAD 的审议仍可被申诉，EOD 的文章仍需通过 G4 审议。

真正成熟的委托，是把执行权下放，同时把验收权制度化。这种”放权不放责”的原则，是委托模式能够在实践中落地的关键：如果专家节点既控制过程又免于验收，系统会迅速退化为中心失去控制力的松散联盟。

从路由到委托的转变，本质上是控制粒度的变化。

路由是”谁来做”：每次任务切换都是一次显式的控制点。

委托控制的是”做成什么样”：过程如何展开由专家节点自主决定，中心只在结果层面把关。

这种转变带来了效率的显著提升：中心不再需要预判每一步该做什么，也不再需要为每个执行细节提供指令。

但它也带来了新的挑战：如何确保专家节点的自治不会偏离目标？如何在不介入过程的前提下保证质量？

这些问题推动着系统从委托走向辩论：让判断权从单点推理中释放出来。

---

四、辩论模式：把判断权从单点推理中释放出来

辩论模式的前提是承认单点推理不可靠。

在路由和委托模式中，系统的基本假设是：只要任务分配正确、过程契约清晰，单个 Agent 就能给出可靠的输出。

但实践中这个假设反复被证伪。

一个 Agent 可以写出连贯的错误，不仅犯错，还能为自己的错误给出漂亮的解释；可以过度自信地引用不存在的事实，因为 LLM 的生成机制偏向于产生流畅、确定的表述，而非诚实地标注不确定性；可以在长上下文中遗忘关键约束，因为注意力机制会稀释远距离的信息关联。

辩论模式通过引入不同角色之间的结构化张力，让系统的判断经受反论压力测试，从而暴露单点推理无法自我发现的盲区。

在学术研究中，多智能体辩论的价值和局限正在被深入探讨:

Johns Hopkins 大学和 Vector Institute 的研究者在 “Talk Isn’t Always Cheap: Understanding Failure Modes in Multi-Agent Debate” 中系统性地揭示了辩论的退化机理 。他们的实验涵盖 CommonSense QA、MMLU 和 GSM8K 三类任务，测试了同质和异质 Agent 组合在辩论过程中的表现变化。

研究结果令人警醒：辩论在某些条件下不仅不能提升准确性，反而会系统性降低性能。在异构设置中（1 个强 Agent + 2 个弱 Agent），CommonSense QA 的准确率从辩论前的 44.4% 下降到辩论后的 39.4%（下降 5.0 个百分点），MMLU 从 33.6% 下降到 24.4%（下降 9.2 个百分点）。

更关键的是，研究者发现模型在辩论中频繁地从正确答案转向错误答案:红色的”正确→错误”转换在几乎所有设置中都多于绿色的”错误→正确”转换。

这种退化现象背后有三种相互强化的机制。

• 第一种是谄媚（Sycophancy）：Agent 倾向于同意其他 Agent 的观点，即使这些观点与自己的初始判断相矛盾。LLM 的训练数据中包含了大量社交互动模式，模型学会了”达成共识”比”坚持己见”更安全的倾向。在辩论场景中，这表现为放弃自己的正确判断去迎合多数意见;

• 第二种是社会从众（Social Conformity）：当多个 Agent 表达相似观点时， dissenting Agent 承受压力改变自己的立场，即使其初始判断可能是正确的。这种从众效应在异构设置中尤为危险，弱 Agent 的错误观点可能通过数量优势影响强 Agent;

• 第三种是推理的表面化：辩论中的 Agent 倾向于关注观点的修辞包装而非实质内容，一个表述流畅但逻辑有缺陷的论点可能比表述笨拙但逻辑严谨的论点更具说服力。

这三种机制共同导致了一个反直觉的结论：【更多的讨论并不总是更好，未经设计的辩论可能使系统比单点推理更不可靠。】

这些研究发现对 Agent 集群的辩论设计提出了严格要求。

• 有效的辩论需要【证据锚点】：所有论点必须绑定到可追溯的事实源，不能是纯粹的观点表达；

• 需要【轮数上限】：辩论不能无限进行，否则退化风险随轮次增加而累积；

• 需要【裁决者】：必须有一个超越辩论各方的权威来做出最终判断；

• 需要【退出机制】：当辩论陷入僵局或明显退化时，系统能够终止辩论并切换到其他模式。

在枢衡中，辩论主要发生在SDC、CAD、EOD、RDD四个核心角色之间，形成一个完整的对抗-验证-裁决闭环：

• SDC 作为框架提出者，负责定义任务的战略方向和分析框架；

• CAD 作为攻击者，负责攻击逻辑漏洞、证据薄弱点和风险盲区；

• RDD 作为事实补充者，负责提供和验证外部证据源；

• EOD 作为执行者，将框架转化为可读文本，并在受到不当审议时提出申诉。

• 人保留最终的 HITL 权力。

这个结构让系统不再依赖某一个 Agent 的单点自信：任何角色的输出都必须经受其他角色的检验。

GUARDIAN 标题误审案例是枢衡中典型的辩论事件：

事件的起因是 RDD 在早期阶段给出一篇 arXiv 论文的不准确标题，SDC 在后续核验原始 arXiv 页面时发现了这一错误并予以纠正。EOD 按 SDC 的纠正写入成稿，一切看似正常。但在 G4 审议阶段，CAD 使用了 RDD 的旧材料（包含错误标题的版本）来审议 EOD 的成稿，从而误判 EOD”篡改”了标题，但是实际上 EOD 使用的是 SDC 纠正后的正确标题。EOD 检测到这一错误审议后，提出Logic Appeal，逻辑申诉，要求 SDC 复核原始来源。SDC 重新检查 arXiv 页面后，裁定 EOD 正确、CAD 误审。

这个案例的价值在于它揭示了辩论模式中多个深层问题。

首先，它证明了辩论必须是双向的：不仅审查者可以质疑写作者，写作者也必须有权质疑审查者。如果系统只允许 CAD 审查 EOD 而不允许 EOD 申诉，CAD 的错误审议将成为不可挑战的”终审判决”；

其次，它暴露了事实版本管理的关键性：CAD 误审的根本原因是使用了过期的 RDD 材料，这说明在辩论环境中，旧事实比未知更危险。Agent “半记得”旧版本时，会自信地犯错，因为它确实”有依据”，只是依据过时了；

第三，它展示了裁决机制的必要性：当 EOD 和 CAD 各执一词时，必须有 SDC 这样更高优先级的事实核查权来做出终裁。

基于这些教训，枢衡将辩论模式制度化为六个相互支撑的机制：

• Constructive Challenge，建设性挑战：CAD 的审议不是”找茬”，而是有结构、有标准、有边界的质量检验。审议必须针对具体的事实源、逻辑链或风险点，不能是泛泛的”感觉不对”；

• Source Sync，事实同步：所有参与辩论的角色必须在同一个事实基准上工作。任何事实更新都必须同步到 SSoT，辩论中引用的材料必须是 SSoT 中的当前版本；

• DISPUTED 标记：当辩论中出现无法即时裁决的分歧时，相关内容被标记为 DISPUTED，不允许作为确定结论进入最终输出，必须等待进一步验证或人类裁决。

• Logic Appeal，逻辑申诉：被审议方有权对审议结论提出申诉，要求更高权限的角色复核。申诉不是”不服”，而是要求重新检查事实源和推理链。

• SDC 终裁：SDC 拥有对事实争议的最终裁决权。当辩论各方无法达成共识时，SDC 基于原始来源和逻辑一致性做出判断。

• HITL：对于涉及重大风险、事实不清或 SDC 无法 confident 裁决的争议，上交人类判断。

辩论模式的核心洞察是：【高质量的对抗比高质量的同意更有价值。】

一个总是说”好的”的 CAD 对系统毫无价值，一个总是说”不行”但说不出原因的 CAD 同样有害。

真正有价值的辩论，是能够指出具体问题、提供替代证据、推动系统向更可靠结论逼近的对抗。这种对抗不是人际关系中的”冲突”，而是认知层面的”压力测试”，通过引入角色张力来暴露单点推理的盲区。

但辩论模式也有明确的能力边界。它适用于”答案存在但可能被单点推理遗漏”的场景，不适用于”答案本身还不存在”的场景，后者需要群体模式的涌现能力。

它适用于有明确事实可核查的任务，不适用于纯粹主观判断的任务；适用于有充足时间进行多轮对抗的任务，不适用于需要即时响应的场景。

理解这些边界，是避免”辩论滥用”的关键。

---

五、群体模式：当中心也不知道答案时，系统只能靠环境涌现

群体模式最容易被误解。

它不是最高级的万能模式，也不是所有任务的终点，恰恰相反，它是四种模式中适用场景最挑剔、治理成本最高、失控风险最大的模式。

更准确地说，群体模式是控制权下放程度最高的模式：中心不仅不控制过程，甚至不预设答案，只设计一个能让答案自行生长的环境。

它适合问题模糊、目标未完全定义、需要创新和涌现的场景，如复杂博弈分析、机制设计、创新框架探索；

它不适合时间紧、格式明确、验收标准稳定的普通执行任务，如按模板生成文档、格式转换、信息提取。

群体模式与复杂系统科学中的涌现（Emergence）理论有深层联系。

涌现是指系统整体表现出单个组成部分所不具备的性质：蚁群中没有一只蚂蚁”知道”巢穴的整体设计，但千万只蚂蚁的局部互动却能建造出精密的蚁巢。在”Emergent Collective Memory in Decentralized Multi-Agent AI Systems”中，研究者通过系统性实验验证了这一现象在 AI Agent 系统中的存在 。

他们设计了一个去中心化的多 Agent 环境，Agent 通过维护个体记忆和在环境中留下持久痕迹（stigmergy）来实现协调。实验揭示了一个关键的相变现象：在低密度环境（Agent 数量少）中，个体记忆单独就能提供68.7%的性能提升（1563.87 vs 927.23, p < 0.001），而环境痕迹在没有记忆的情况下完全失效。但在高密度环境（ρ > 0.20）中，基于环境痕迹的协调开始占主导，性能超过纯记忆系统36-41%。这个实验首次在去中心化认知多 Agent 系统中验证了相变理论：存在一个临界密度阈值（理论预测 ρ_c = 0.230，实验验证误差在 13% 以内），低于此阈值时个体认知主导，高于此阈值时集体涌现主导。

这项研究对 Agent 集群设计有重要启示：Agent 不一定只能靠中心命令协作，也可以通过环境痕迹间接协调。

在枢衡的实践中，这种间接协调体现为共享环境的设计：不是让所有 Agent 同时说话，而是建立一个能产生局部互动和持续留痕的环境。

在这个环境里，Agent 不只是响应命令，还能通过任务列表、文件、记忆、信誉账本、SSoT、diary 和协议文件相互影响。

共享环境比群聊更重要：群聊是过程，环境才是状态。群聊的内容会消失在历史消息中，环境中的记录则是持久的、结构化的、可被后续任务继承的。

Stigmergy，间接协调，是群体模式环境设计的核心原则之一。这一概念源自生物科学：蚂蚁通过信息素痕迹协调筑巢和觅食，没有中央指挥，每只蚂蚁只根据环境中的痕迹做出局部决策 。

在 LLM Agent 集群中，stigmergy 的实现方式是共享工件（Shared Artifacts）：一个 Agent 产生的文件、更新的事实源、留下的审议记录，都成为环境中的”数字信息素”，触发其他 Agent 的后续行动。

有开发者在生产环境中实践了这一思路，通过让 Agent 读写共享环境而非直接对话，实现了80% 的 API token 使用量减少，这证明了环境协调不仅概念优雅，在实际效率上也有显著优势。

枢衡的群体模式正在形成类似共享环境结构的路上，我们会在Part7细说枢衡由任务列表等六个模块的共享环境设计。

但群体模式的风险也最大。

• 通讯熵（Communication Entropy）会随 Agent 数量增加而指数级增长，因为每个额外的 Agent 都增加新的交互维度，未经治理的群聊很快就会变成信息噪声；

• 责任会模糊：当多个 Agent 参与同一任务时，“谁对最终结果负责”变得难以回答；

• 验收会变难：群体产出的成果可能不符合任何预设标准，因为标准本身可能就是涌现过程的一部分；

• 共享环境也可能被污染：证据、过期框架、未同步材料、错误记忆，都可能成为下次任务的隐性污染源。

我在枢衡实践中做出了一个关键判断：常作任务应转向调度模式，群体模式应保留给博弈、反论、群体智能和复杂机制设计。

这个判断基于成本-收益分析：对于格式明确、验收标准清晰的任务，群体模式的涌现能力带来的边际收益不足以抵消其治理成本和效率损失；而对于问题本身模糊、需要多方视角碰撞才能逐步澄清的任务，群体模式的涌现能力是其他模式无法替代的。

群体模式不是日常执行工具，而是复杂系统的思维空间。

它的价值在于涌现：让系统能够处理”问题还没定义清楚”的场景，在于探索，让系统能够进入未知的认知领域；不在于高效成稿，这更适合路由和委托。

理解这一点，是避免”为了用群体而用群体”的关键。

---

六、四种模式不是替代关系，而是模式栈

经过对四种模式的分别讨论，一个关键问题浮现：它们之间是什么关系？

真实系统是模式栈（Pattern Stack）：不同模式承担不同层次的功能，像网络协议栈一样分层协作，上层依赖下层提供的基础能力，下层在上层的调度下发挥特定作用。

从架构视角看，这四种模式与主流 Agent 框架的编排模式形成了有趣的映射关系。GroovyWeb 的技术综述将多 Agent 编排模式归纳为控制光谱：

Supervisor（中心监督）→ Router（路由分配）→ Pipeline（流水线）→ Swarm（群体自治）。

这个光谱从左到右代表了控制权的逐步下放：

• Supervisor 模式中一个中心 Agent 决定所有任务分配，

• Router 模式通过意图分类将请求路由到最合适的专家，

• Pipeline 模式让 Agent 按固定顺序串行处理（A → B → C），

• Swarm 模式则让 Agent 基于共享记忆自主认领任务。

枢衡的四种模式可以映射到这个光谱上，但增加了更丰富的治理维度：我们的”辩论”模式在这个光谱中没有直接对应，因为它不是关于任务如何流动，而是关于质量如何被验证。

在枢衡的模式栈中，各层的功能划分如下：

• 底层是路由层，解决【效率问题】。没有路由，任务入口会混乱，角色边界会模糊，每个任务都需要协商”谁来处理”。路由层确保任务快速、准确地到达正确的处理节点。它是模式栈的”物理层”：所有上层协作都建立在任务被正确路由的基础上；

• 中层是委托层，解决【深度问题】。没有委托，中心会被过程细节淹没，无法专注于战略判断。委托层让专家节点在各自领域内深入执行，中心只需关注目标和验收。它是模式栈的”传输层”——确保任务能够被完整、深入地执行；

• 验证层是辩论层，解决【可靠性问题】。没有辩论，系统会形成顺滑的伪共识，每个 Agent 都给出看似合理但未经充分检验的输出，系统整体看起来运转良好，实际上可能在系统性犯错。辩论层通过对抗性检验暴露盲区。它是模式栈的”校验层”，确保输出不仅完成，而且正确；

• 探索层是群体层，解决【涌现问题】。没有群体，系统很难处理未定义问题。当问题本身不清楚、答案需要多方碰撞才能逐步浮现时，路由、委托、辩论都无法发挥作用，因为它们都预设了”问题已经定义清楚”。群体层通过环境设计和局部互动培育涌现。它是模式栈的”应用层”，处理最复杂、最开放的任务类型；

• 贯穿全栈的是治理层，包括信誉评估、记忆管理、上下文治理、熔断机制、经验清洗和 Skill 自进化。治理层不直接参与任务执行，但确保各层协作不会失控。

枢衡的实践完整展示了这个模式栈的运作方式：

一个 L4 长文任务的处理流程如下：

• SDC 首先进行路由和框架制定：判断这是 L4 任务，需要多角色协作；

• RDD 被委托补充外部证据：在证据领域内自主搜索、筛选、验证；

• CAD 被委托做审议和反论：在质量保障领域内独立工作；

• EMD 设计 G1-G5流程：确保质量门按序执行；

• EOD 生成 Word 初稿，在写作领域内发挥专长；

• CAD 分段 G4辩论：逐段审议并提出挑战；

• EOD 根据审议反馈修改；

• SDC 最终验收。

• 若 CAD 在 G4 阶段超时（watchdog timeout / frames=0），SDC 临时接管生成可用版本。这是中心恢复能力的体现。

这个链条同时使用了路由、委托、辩论和治理四种机制。它不是”选一个模式”，而是”按层叠加模式”：路由确保任务到达正确节点，委托确保节点深入执行，辩论确保产出质量可靠，治理确保整个过程可控。

模式选择本质上是风险管理。

低风险任务不应过度群体化：为简单的文档生成启用群体模式，成本（通讯熵增、治理开销、时间延迟）远高于收益（边际质量提升）；

高风险任务不应直接委托给执行节点：涉及重大事实判断的内容，如果跳过辩论层，可能产生严重错误而系统不自知。

模式匹配度比模式复杂度更重要：真正成熟的系统，不以使用了多高级的模式为荣，而以为每个任务选择了最合适的模式组合为准。

成熟 Agent 集群的能力不是永远使用最高级模式，而是知道何时切换:

任务清楚、边界明确时，用路由和委托就足够；

结果影响重大时，必须叠加辩论；

问题本身模糊时，才启用群体；

对外交付时，G4 和 Source Sync 是必选项；

时间紧急时，中心需要恢复接管能力，跳过部分审议流程。

这种动态切换能力，是模式栈的终极价值：它让系统能够根据任务特性自动调整协作复杂度，既不过度设计，也不偷工减料。

---

七、从控制 Agent 到设计环境

从路由到群体，真正变化的是控制对象发生了根本性转变。

低级系统控制 Agent：告诉它做什么、怎么做、什么时候做，每一个动作都需要中心的显式指令；

成熟系统控制环境：定义规则、状态、反馈、边界、奖惩和恢复路径，让 Agent 在局部互动中形成期望的集体行为。

这种转变的本质，是从”直接控制”到”间接治理”的范式迁移。

这个范式迁移在复杂系统理论中有深厚的根基。

物理学家约翰·霍兰德在研究复杂适应系统时提出了”涌现秩序”（Emergent Order）的概念：系统的宏观秩序不必来自中央指令，而可以通过微观个体的局部互动自发产生。

蚁群、鸟群、市场经济都是涌现秩序的例子：没有中央指挥部，却能形成高度协调的集体行为。

但涌现不是魔法，它需要精心设计的环境条件：蚁群的信息素系统、鸟群的邻近对齐规则、市场的价格机制，这些都是”环境设计”的产物。没有这些环境基础设施，涌现不会发生，只会混乱。

在 Agent 集群中，环境设计意味着中心不再直接干预每个 Agent 的每个决策，而是通过设计共享的认知基础设施来引导行为。枢衡的环境设计包含六个相互关联的子系统：

1.CREDIBILITY_LEDGER（信誉环境）

是 Agent 行为的”成绩单”。

它记录每个 Agent 在历次任务中的表现：事实准确性、审议质量、交付及时性、申诉成功率等维度。

高分 Agent 在任务调度时获得优先权，可以降低低风险任务的抽样率，减少不必要的重复检查；低分 Agent 则面临更严格的审查或任务降级。

信誉环境的作用是将历史表现转化为未来机会，让”做得好”成为”更容易获得好任务”的正反馈。

但信誉环境的设计需要极度谨慎：如果评分标准有偏差，系统会系统性地奖励错误行为；如果评分维度不完整，Agent 会优化被测量的指标而忽视真正重要的品质。

枢衡的信誉账本采用多维度评分 + 人类抽查校准的机制，避免单一指标导致的优化扭曲。

2.SSoT（事实环境）

是 Agent 认知的”坐标系”。

它规定当前任务中哪些事实是已验证可用的、哪些是需要补充的、哪些是禁止使用的。

所有 Agent 在同一个 SSoT 上工作，从根本上消除了”各说各话”的事实分歧。

SSoT 的设计挑战在于动态更新：随着 RDD 补充新证据、随着 Source Sync 发现旧错误，SSoT 需要持续更新，而所有 Agent 必须及时感知这些更新。

在 GUARDIAN 误审案例中，CAD 的错误根源就是没有及时感知 SSoT 的更新，使用了过期材料。

SSoT 不仅是一个文件，更是一个版本化管理的事实协议。

3.Task List（任务环境）

是执行状态的”仪表盘”。

它记录谁负责什么、做到哪一步、阻塞在哪里、预计何时完成。

任务环境让所有 Agent和人类监督者对整体进度有共同认知，避免”我以为你做完了”的协作失败。

在群体模式中，任务环境还承担着协调功能：Agent 可以根据任务列表自主认领未分配任务，或根据阻塞状态决定是否需要介入协助。

4.MEMORY 和 diary（经验环境）

是系统的”集体记忆”。

diary 记录每次任务的关键决策、错误复盘和机制演化：不是流水账式的”今天做了什么”，而是结构化的”这次任务中学到了什么”；MEMORY 则保存长期偏好、成功案例模板和反模式警示。

经验环境让系统能够从历史中进化，避免重复踩同一个坑。

但它的风险也同样明显：如果 diary 记录了错误的经验总结，Agent 会稳定地学坏：每次遇到类似情况都重复错误的做法，还以为自己”有经验”。因此，经验环境需要定期审计和清洗，错误记录必须被标记和纠正。

5.协议文件（规则环境）

定义了 Source Sync、Constructive Challenge、上下文治理、Skill 自进化治理等协作规则。

它不是建议性的”最佳实践”，而是强制性的”法律制度”：违反协议的 Agent 行为会被识别并纠正。

协议文件的存在让”规则”从隐性变为显性，从口头约定变为可执行、可审计的代码。

6.G1-G5（质量环境）

决定任务何时能进入下一阶段。

它像一道道的进化筛选器，只有满足当前阶段的全部标准，任务才能”毕业”到下一阶段。

质量环境的作用是将”好”的定义从主观的”我觉得不错”转化为客观的”通过了全部检查项”。

这些组件共同构成一个共享环境，Agent 在其中行动，不再完全依赖聊天上下文。环境比对话更持久、更结构化、更可审计。

当一个 Agent 完成任务时，它留下的不是一条”我做完了”的消息，而是一个更新后的文件、一个标记完成的任务项、一条写入 diary 的经验记录，这些环境痕迹会被后续 Agent 感知和响应，形成链式的涌现效果。

这六种环境共同取代了逐步命令：SDC 不需要在每一句话里提醒 EOD”不要新增事实”，因为 SSoT 已经规定了事实边界；不需要每次都口头告诉 CAD”做 Source Sync”，因为 G4 协议已经明确要求；不需要每次都解释长上下文风险，因为上下文治理已经落盘为可执行规则。

环境一旦设计好，就成为持续的、隐性的约束力：Agent 在环境中行动时，正确的行为路径会更容易走通，错误的行为路径会遇到摩擦。

这就是从建筑师到园丁的转变。

建筑师预先规定每一块砖怎么放、每一根梁怎么架，对建筑的每一个细节都有精确控制。

园丁不规定每朵花什么时候开、每片叶子长多大，而是设计土壤成分、水源分布、光照条件和修剪机制：然后让植物在环境中自行生长。

Agent 集群越成熟，中心越不应沉迷于直接控制每个动作，而应更多设计环境，使正确行为更容易发生，错误行为更容易暴露。

但环境设计也有其内在风险，且这些风险往往比直接控制的风险更隐蔽。

如果环境中的事实源过期，Agent 会在错误的环境里高效协作：所有角色都严格遵循协议，但基于的事实基础本身就是错的，产出越”高质量”越危险；

如果信誉账本奖励错了，系统会把错误行为强化为正反馈循环：某个 Agent 因为恰好迎合了评分标准而获得高分，实际上其输出质量并未真正提升，系统却越来越依赖它；

如果成长日志记录了错误经验，Agent 会稳定地重复错误：把一次偶然的成功当成可复用的模式，或在错误复盘时归因不当。

因此，环境不是一次性设计完成的永恒产物，而需要持续清洗、审计和回滚机制。

枢衡定期对 diary 进行人类审核，对信誉评分进行异常检测，对 SSoT 进行交叉验证，尽最大可能确保环境本身不会成为系统性错误的源头。

---

八、放手之后如何防止失控

从控制到放手的演进，每一步都伴随着失控风险的增加。

• 路由模式下，中心掌握着任务分配的完全控制权，风险最低但也最累；

• 委托模式下，中心交出了过程控制权，黑箱风险随之出现；

• 辩论模式下，中心允许甚至鼓励 Agent 之间的对抗，审议偏离和无限循环的风险需要被约束；

• 群体模式下，中心退到环境设计者位置，通讯熵增、责任模糊、环境污染的风险达到最高。

因此，越是把控制权下放给 Agent 和环境，越需要更强的治理护栏。没有治理的群体模式，会迅速滑向通讯熵增、责任模糊、错误传播和交付不可控的混乱状态。

枢衡在实践中建立了七道治理护栏，每一道都对应着至少一次真实失败事件的教训。

第一道护栏：角色边界（Role Boundaries）：

每个 Agent 都有明确的能力边界和行为禁区，这些边界不是”建议”而是”硬约束”。

RDD 不能把弱信号（weak signal）写成 confirmed：发现相关性不等于确认因果性，RDD 必须在证据强度上诚实标注；

EOD 不能用优美的表达来美化风险：写作流畅性不能掩盖事实不确定性，“可能”不能写成”必然”；

CAD 不能用旧材料审新事实：审议必须基于当前 SSoT 版本，不能凭印象或记忆做出判断；

SDC 不能无证据拍板：战略判断必须有事实支撑，不能基于直觉或偏好做出决策。

角色边界不是限制创造力，而是防止责任稀释。当每个角色都知道”什么是我的事、什么不是我的事”时，追责和改进才有明确的对象。

第二道护栏：信誉分与能力画像（Credibility Scoring & Capability Profiling）：

Agent 不是同质的计算单元，每个 Agent 都有自己的能力强项和弱项。信誉分记录历史表现，能力画像刻画擅长领域。

高分 Agent 可以降低低风险任务的抽样率：如果一个 Agent 在连续 20 次事实核查中 100% 准确，低风险任务可以减少对其输出的重复验证。

但关键事实永不免检：无论 Agent 的历史表现多么优秀，涉及核心事实判断的内容仍需 Source Sync 验证。

CAD 可以临时阻断不符合质量标准的输出，但不能绕过 SDC和人 的终裁权：阻断是”暂停”而非”终审”。

Recovery 高分（快速修复能力）只能给轻微错误提供快速修复缓冲，不能成为 C3/C4 严重错误的免罚金牌：修复快不代表犯错可以被宽恕。

第三道护栏：Source Sync 与 SSoT（Fact Synchronization）事实源：

GUARDIAN 误审事件最深刻的教育是：旧事实比未知更危险。

Agent 对某个信息”半记得”：记得好像有这么回事，但不记得具体来源和版本，这时会自信地犯错。

这种”有根据的错误”比纯粹的幻觉更难被发现，因为它确实基于真实信息，只是信息已经过期。

Source Sync 的作用是确保所有角色在同一个事实基准上工作。任何事实的引入、更新或删除都必须经过 Source Sync 协议，所有 Agent 在每次任务开始前必须确认当前 SSoT 版本。这看似繁琐，但避免了因事实版本不一致导致的系统性错误。

第四道护栏：上下文治理（Context Governance）：

LLM Agent 的上下文窗口虽然不断扩展，但”能装下”不等于”能记住”。

长聊天会导致三种认知退化：爆窗：超出上下文限制导致早期信息被截断、遗忘：注意力机制稀释远距离信息、注意力稀释：过多无关信息干扰关键内容。

更危险的是”半记得”状态：Agent 对某个约束有模糊印象，但记不清具体内容，于是基于不完整记忆做出错误判断。

因此，关键结论必须落文件，不能只在聊天中提及，长任务必须阶段压缩，定期总结当前状态并丢弃过时细节，EOD/CAD 不得只靠聊天印象工作，必须查阅 SSoT 和协议文件。

上下文治理的本质是：聊天是过程，文件是状态：过程可以丢失，状态必须持久。

第五道护栏：分段审议（Segmented Review）：

CAD 超时事件（watchdog timeout / frames=0）说明，群体系统不仅会”判断错误”，也会”运行失灵”：Agent 可能因为任务过于复杂而陷入沉默，不是因为不想回答，而是因为无法在给定时间内组织出有效输出。

这种”运行失败”比”逻辑错误”更难发现，因为系统没有输出可供审查。

修复方式不是继续压同样的大任务，而是将 G4 审议拆分为多个子层：引用层（核查引用是否准确）、案例层（核查案例分析是否合理）、逻辑层（核查论证逻辑是否严密）、判定层（综合以上做出最终判断）。

分层审议让每个子任务足够小，Agent 能够可靠完成，同时通过分层结构保持整体审议深度。

第六道护栏：中心恢复能力（Central Fallback）：

当我半小时后需要某个文件，而 CAD 无法完成有效审议时，SDC 接管生成可用版本。

从控制到放手，不意味着中心消失。

中心应从日常指挥者转变为四个角色：框架制定者（设计协作规则和环境）、冲突终裁者（裁决 Agent 间无法自动解决的分歧）、紧急恢复者（在系统失灵时接管关键任务）、环境设计者（持续优化共享环境）。

中心的存在不是为了管理每个动作，而是为了在系统偏离轨道时有能力纠正。

第七道护栏：Skill 自进化治理（Skill Evolution Governance）：

随着系统运行，有效的流程可以沉淀为 Skill（可复用的任务模板），Skill 可以在使用后反思和修正。

但 Skill 的进化必须受控：修改必须分级授权（小修自动批准，大修需要审核）、可审计（所有修改留下痕迹）、可回滚（新版本出现问题能快速恢复旧版本）。

否则，Skill 的成长会变成漂移：每次微调都在改变行为，累积效应可能导致 Skill 逐渐偏离最初的设计目标，甚至把一次错误经验固化成长期污染。

这七道护栏构成一个层次化的防御体系：

角色边界和信誉分是”预防层”：在错误发生前通过设计约束行为；

Source Sync 和上下文治理是”检测层”：在错误发生时通过事实同步和状态持久化及时发现；

分段审议和中心恢复是”响应层”：在系统失灵时通过降级和接管保证基本功能；

Skill 自进化治理是”进化层”：确保系统在长期运行中不会退化。

四层协同，才能在大幅下放控制权的同时保持系统可靠性。

---

九、结论：真正成熟的 Agent 集群，是能自我分工、自我质疑、自我修复的环境

Agent 集群的终局，不是找到一个最强控制中心，再大的中心也无法集中管理 Agent 的复杂协作；也不是让所有 Agent 完全自由：无约束的自治只会导致混乱。

真正成熟的集群，是能根据任务自动选择模式：该路由时路由，该委托时委托，该辩论时辩论，该群体涌现时群体涌现。

四种模式各有其不可替代的价值，也各有其明确的能力边界：

• 路由让系统会分工，没有路由，任务入口混乱，角色边界模糊；

• 委托让系统会深做，没有委托，中心被过程细节淹没，无法专注于战略；

• 辩论让系统会质疑，没有辩论，系统容易形成顺滑的伪共识，在无人察觉中系统性犯错；

• 群体让系统会涌现，没有群体，系统难以处理未定义问题，只能在已知领域内重复。

• 治理层让系统不会在这些能力中失控，没有治理，群体只是热闹，委托只是放任，辩论只是争吵，路由只是机械分派。

枢衡的近期实践完整地验证了这套模式栈的有效性，每一次机制演进都对应着一次真实失败事件的驱动：

• GUARDIAN 误审让我们建立 Source Sync：当 CAD 因为使用过期材料而误审时，我们意识到事实版本管理不是”锦上添花”而是”性命攸关”；

• CAD 超时让我们建立分段 G4：当审议 Agent 因为任务过大而沉默时，我们意识到”加大任务”不是解决复杂问题的正确方式，拆分和分层才是；

• 上下文风险让我们建立上下文治理：当 Agent 在长对话中遗忘关键约束时，我们意识到聊天上下文不是可靠的状态载体，必须将关键结论落盘为持久文件；

• 写作任务转向调度模式让群体模式回到博弈与涌现的主场：当我们发现常规写作任务在群体模式中效率低下时，我们意识到模式匹配度比模式复杂度更重要。

这些变化共同证明了一个深层规律：Agent 集群的成长不是配置越来越多，而是环境越来越会自我修复。

早期系统靠中心的人工干预来纠正错误：发现问题、下发指令、检查执行。

成熟系统靠环境的设计让正确行为更容易发生、错误行为更容易暴露：SSoT 防止事实分歧，信誉账本激励正确行为，协议文件规范协作规则，质量门筛选不合格输出。

中心的角色从”修理工”转变为”园丁”，不直接修理每一株植物，而是设计让植物茁壮成长的土壤。

从控制到放手，不是放弃责任，而是把责任从单点命令转移到系统环境：

中心不再控制每个动作，但仍负责设计边界：什么可以做、什么不能做、做了有什么后果；

不再审每个细节，但要确保审查机制存在：G4 审议、Source Sync、信誉评估这些机制必须持续有效；

不再亲自完成每个任务，但要能在系统失灵时接管：中心恢复能力是最后一道安全网。

放眼更广阔的 Agent 系统演进图景，我们看到一个清晰的趋势：从单一 Agent 的能力提升，走向多 Agent 的协作优化，再走向协作环境的基础设施化。

OpenAI 的 Swarm、AutoGen 的 Handoff、CrewAI 的 Delegation、LangGraph 的状态机，这些框架都在探索同一个问题的不同侧面：如何让多个 Agent 有效协作。

但框架提供的是”可能性”，真正决定系统质量的是”治理”：如何在放权的同时保持控制，如何在自治的同时防止失控。

枢衡的实践表明，这套治理机制不是预先设计好的完美蓝图，而是在一次次错误中被逼出来的演化产物。

因此，Agent 集群真正值得追求的，不是一个听话的工具集合，也不是一群完全自由的 Agent。真正值得追求的，是一个有分工、有反论、有记忆、有信誉、有治理、有修复能力的协作环境。

在这个环境中，Agent 不是被命令做事的下属，而是在规则约束下自主协作的参与者；中心不是发号施令的老板，而是设计规则、维护秩序、在危机时出手的治理者。

路由、委托、辩论、群体四种模式，合在一起，才构成从控制到放手的完整路径。

单独看每一种模式，都有其局限和不足；但将它们叠加成模式栈，让路由提供入口秩序、委托提供执行深度、辩论提供质量保障、群体提供涌现能力，再用治理层贯穿始终：我认为，这才是 Agent 集群走向成熟的完整图景。

---

【看山 Agent 架构】

工信部 AI 技术应用（高级）认证

CAIE认证

30次集群崩溃复盘 | 数十智能体实战

深耕 Agent 集群架构，用商科思维重构复杂系统效率

注：本文内容由 AI 辅助创作，作者对内容结果负责

感谢您的喜欢

---

内容效果不满意？点此反馈