公众号名称：看山 Agent 架构

作者名称：看山Agent架构

发布时间：2026-05-13 18:05

把任务交给一个Agent，够了吗？

答案很直接：不够。

单体Agent在处理明确、单线程的任务时表现尚可，但一旦面对复杂问题——比如供应商选择、全链路优化、多维度决策——单个Agent的能力天花板立刻暴露：认知宽度不够、长任务专注度衰减、对自身错误的“盲区”无法自查。

这不是模型能力的问题，是【架构的问题】。一个人再聪明，面对需要多视角交叉验证的复杂决策，也需要团队。Agent同理

所以有了【多Agent集群】。但把多个Agent放进一个系统，新的问题立刻浮现：

它们之间怎么配合？
谁该干什么？
干完怎么验证？
遇到模糊问题怎么自发协作？

这四个问题，对应四种核心协作模式：

要解决的问题	选用的模式	概述
任务来了，该交给谁？	路由模式	按能力匹配，精准分发
交出去的任务，怎么保证闭环交付？	委托模式	全权委托，只看最终结果
交付的结果，怎么保证质量？	辩论模式	多方对抗，交叉验证
任务本身就模糊不清，怎么协作？	群体模式	自发分工，动态涌现

这四种模式，不是四个并列的选项，而是一条从“能用”到“好用”到“可靠”到“智能”的协作深度演进之路。下面逐个拆解

一、路由模式：让最合适的大脑，去处理最匹配的问题

路由模式是多Agent集群中最基础、也最直观的协作方式。它的核心思想很简单：先问一句“这个活交给谁最合适”。

这个逻辑，医院的分诊台已经用了几十年。分诊护士不负责治病，只做一件事——询问症状，判断科室，把患者精准分给对应的专科医生。而专科医生只接诊自己擅长的领域。遇到疑难杂症，护士会同时通知多个科室，进行联合会诊

在Agent集群中，路由模式做的就是这件事。它不是让所有Agent一起去抢同一个任务，也不是让一个Agent硬扛所有问题，而是在任务入口处设置一道“匹配层”——

【根据任务类型，将其分发给最擅长处理该任务的那一个或那一组Agent】

1.1 路由模式的架构：星型网络

路由模式的拓扑结构是典型的【星型网络】，由两类核心角色和一个可选角色组成：

【路由器】：系统的入口网关。它的职责不是执行任务，而是“做出选择”——判断当前任务属于哪个领域、需要什么能力，然后将任务精准分发。路由器是整个系统的大脑皮层，决定了每一次协作的起点。
【专家Agent】：术业有专攻的执行单元。每个专家Agent都是异质的——它们使用的模型可以不同，系统提示词可以不同，挂载的知识库也可以不同。正是因为存在这种差异，路由器才能进行有意义的匹配。如果所有专家都一样，匹配就失去了意义。
【聚合器（可选）】：专门用于“多专家联合会诊”的场景。当路由器判断某个任务涉及多个领域、需要综合多方意见时，它会将任务同时分发给多个相关专家，再由聚合器对各位专家的输出进行整合，形成统一的最终结果

这套架构的设计哲学是【高度解耦】。每个专家Agent彼此独立，新增或移除一个专家节点，不需要修改路由器的调度逻辑，也不会影响其他专家的正常运行。

系统的扩展性和容错性，从架构层面就得到了保障。

1.2 路由模式的三个核心机制

一个高效的路由模式，必须回答三个关键问题，每个问题对应一套机制：

1.2.1 如何准确判断“该把任务分给谁”？——【语义路由】

路由器的核心能力不是执行，是【判断】。它需要在没有人工干预的情况下，自动识别每个任务的性质和需求，并匹配到最合适的专家。

这个判断能力的实现，业界主要依赖两种技术路线：

一种是【嵌入相似度匹配】。将任务描述和每个专家的能力描述分别转化为向量，通过计算向量相似度，找到匹配度最高的专家。这种方式适合专家种类多、能力边界清晰的场景。
另一种是【模型意图分类】。用一个专门训练的轻量级分类模型，直接对用户输入进行意图识别，输出对应的专家标签。这种方式适合任务类型相对固定、对分类准确率要求较高的场景。

两种路线并不互斥，工程实践中也常采用级联组合——先用意图分类做初筛，再用相似度匹配做精排。

1.2.2 不同开发者编写的Agent之间如何有效沟通？——【A2A协议】

在多Agent系统中，专家Agent可能由不同开发者、不同团队编写，使用不同的技术栈和通信格式。要让它们协同工作，必须有一套标准化的通信语言。

这就是A2A（Agent-to-Agent）协议的核心价值。它相当于多智能体世界的“TCP/IP协议”，定义了Agent之间如何互相发现、声明能力、建立连接和传递信息。一个标准的A2A通信流程包含四个步骤：

发现：新Agent加入时，向系统注册自己的存在和能力标签，告知路由器或其他Agent“我能干什么”。
能力声明：用结构化的数据格式（如JSON Schema），描述自己能处理的任务类型、输入输出格式和性能边界。
握手：两个需要协作的Agent之间建立通信链路，确认协议版本、数据格式和交互节奏。
响应：接收方完成处理后，按照约定的结构化格式返回结果。

A2A协议的存在，让多Agent系统从“同一团队内部协作”扩展为“跨团队、跨技术栈的标准化协作”，是工业级落地的基础设施。

1.2.3 如何有效综合多个专家的意见？——【Agent混合聚合】

在某些复杂任务中，单个专家的判断可能存在盲区。路由器的解法是“联合多个专家会诊”——将同一个问题并行分发给多个相关专家，再由聚合器对各专家的回答进行综合分析，输出统一结果。

这套机制在业界被称为【MoA（Mixture of Agents，Agent混合）】。它的核心不在于收集了多少个专家的意见，而在于聚合算法如何从多份输出中提炼出最可靠、最一致的结论。

最简单的聚合策略是加权投票——根据每个专家的历史准确率或置信度评分，给不同权重，按权重合成最终结果。
更复杂的方案则引入一个专门的聚合模型，对多份输出进行二次推理和矛盾检测，识别出最可靠的信息并整合为最终答案。

值得注意的是，Agent混合聚合虽然能提升输出质量，但对应的计算成本和响应延迟也会增加。

在实践中，需要根据任务的容错要求和实时性需求，决定是否启用多专家会诊——【不是所有场景都值得付出额外的Token和等待时间】

1.3 路由模式，为什么是最适合起步的模式？

路由模式是多Agent集群的“第一块地基”。它解决的不是“最高端的协作问题”，而是“最基础也最紧迫的问题”——任务来了，谁干。

这个模式对起步者最友好的地方在于它的【简洁性】：你不需要复杂的博弈机制，不需要多轮辩论，只需要做好三件事——

【定义好专家的能力边界】
【设计好路由器的匹配规则】
【在必要时引入一个简单的聚合器】

这样一套系统，已经能在任务分类、客服分流、数据处理等大量实际场景中创造价值。

如果只从这四个模式中选一个最先落地，路由模式是当之无愧的首选

1.4 我的实践：路由时代的【枢衡】集群

最初的枢衡集群，采用的就是这种模式：【基于行政职能分工的语义路由协议】

1.4.1 在 v1.0 时代，路由模式是由 “三省” 协作完成的一个闭环

1. 【路由器 (Router)】：中书省与尚书省的接力

语义识别 (中书省 - Central Secretariat)：它扮演的是“分诊护士”的角色。当您的指令输入时，中书省负责意图蒸馏 (Intent Distillation)。它不执行任务，而是将模糊的需求“翻译”成一份《指令草案》，明确该任务属于“财会、法务、资源还是执行”维度。

任务分发 (尚书省 - Department of State Affairs)：它是真正的“路由器硬件”。尚书省通过语义映射表 (Role Mapping Table)，将中书省的草案拆解为原子任务，并精准推送给对应的“专科医生”（六部）。

2. 【专家 (Experts)】：六部职能模块

当时的“分诊”是按照职能极其解耦的：

户部 (Revenue)：处理所有涉及“钱”和“对价”的问题（后演化为财务/CPA）。
工部 (Works)：处理所有涉及“工具、代码、落地”的问题（后演化为 EOD）。
兵部 (Defense)：处理涉及“风险、安全、策略”的问题（后演化为 CAD）。
吏部、礼部、刑部：分别处理人员、沟通标准和合规审计。

3. 【聚合器 (Aggregator)】：门下省 (Chancellery)

会诊审计：在六部产出结果后，并不会直接推给我。门下省负责“封驳”和“聚合”。它会审查专家们的回答是否逻辑冲突（如户部算出的成本，工部说技术无法实现），并进行最终的帕累托最优对齐。

1.4.2 为了解决文章中提到的三个问题，我们当时是这样落地的：

1.语义路由怎么做？ (Semantic Routing)

实现：我们采用了【意图森林 (Intent Forest)】机制。通过计算用户 Query 与“六部职能描述符”之间的语义向量相似度（Embedding Similarity），如果得分超过 0.85，则自动挂载该专家的 ID。

2.通信协议是什么？ (A2A Protocol)

实现：那是我们最早的【@{Agent_ID} 触发机制】。中书省输出的标准格式包含：Task_ID | Context_Ref | Expert_Target。这确保了不同职能的 Agent 能在同一个上下文（Context）中接力工作。

3.如何综合意见？ (Agent Aggregation)

实现：我们使用的是【结构化对撞法】。聚合器（门下省）会强制各专家输出 [Belief] 和 [Confidence]。如果信心指数低于阈值，聚合器会触发“重新路由”，要求专家们针对争议点进行第二次协同推理。

二、委托模式：把任务交出去，不只是“分活”，更是“托付”

路由模式解决了一个关键问题：任务来了，该交给谁。但分配正确，只是协作的起点。任务交出去之后，一个更深入的问题立刻浮现：

【怎么保证它被完整、高质量地闭环交付？】

这就是委托模式要解决的核心问题。

打个比方。路由模式像医院的分诊台——护士根据症状，把患者分给对应的专科医生。但患者到了医生那里之后怎么办？医生是自己独立完成诊断、开药、复查，还是每一步都要跑回分诊台请示？

委托模式干的就是后面这件事。它确保接受任务的Agent，有能力独立完成完整的执行闭环，不需要上级反复追问，最后交付的是一个完整结果，而不是一堆需要再加工的中间产物。

这正是我在做Agent集群精简时反复验证过的一个原则：【意图委派】，主节点只定义最终目标和验收标准，不干预子节点的执行路径——怎么干，是接受委托那一方自己决定的。

2.1 委托模式的架构：有向树

委托模式的拓扑结构是有向树——指令自上而下逐级传递，汇报自下而上逐级汇聚。

这种单向链路决定了它天然适合处理长程、复杂的工程任务：每一层只需要对上一级负责，不需要关心更上层在干什么。

架构中有三个关键角色：

【经理Agent】：拥有全局视角，负责将上层交下来的模糊需求拆解成可执行的子任务，分配给下属，并在最后验收交付成果。

经理维护的是全局上下文——它知道这个任务的最终目标是什么、各个子任务之间的依赖关系是什么、当前整体进度到哪了。

【员工Agent】：只关注自己分到的具体任务，不需要了解整体目标。它的职责边界非常清晰：高质量完成属于自己的那一部分，然后交回结果。

各员工节点之间一般不直接通信——这不是设计缺陷，而是刻意为之。减少横向通信的好处是显而易见的：避免了我在早期集群中踩过的“消息风暴”坑，也降低了上下文污染的风险。每个员工只和它的直属经理对话，通信路径一清二楚。

【人在回路HITL】：在委托模式中，人不是旁观者，而是架构中的关键决策节点。人的参与在两个环节必不可少：

一是执行前，审查经理的任务拆解是否到位。经理可能过度拆分导致效率损耗，也可能拆分不足导致子任务依然过于复杂——人的经验判断是兜底。

二是执行后，评审最终产出成果。Agent交付的结果是否符合真实业务预期，最终判断权在人手里。这不是对Agent不信任，而是对任务质量负责。

在我搭建Agent集群的实践中，这两个环节都出过问题。

一次是经理把任务拆得太碎，员工之间产生大量不必要的依赖等待；

另一次是缺乏人对产出结果的把关，一个逻辑偏差顺着链路一直传递到最后。从那以后，人在回路成了不可简化的保底机制。

2.2 委托模式的三个核心机制

2.2.1 机制一：【递归分解】

委托模式处理复杂任务的底层逻辑，是递归分解。

经理接到一个复杂任务，拆成若干子任务分配给员工。

员工在执行过程中，如果发现某个子任务依然过于复杂，超过了自己的处理能力边界，它可以继续拆解成更小的任务，再下发给下一层。

这就是递归——每一层都在做同一件事：拆解、分配、验收，直到每个最底层的子任务都够简单、够明确。

递归的终止条件通常来自两方面：

一是子任务已经足够原子化，不需要进一步拆解；
二是再无可用员工，需要经理亲自处理。

在实践中，拆解的关键是明确定义每个子任务的交付标准——如果只给任务不给标准，验收环节注定混乱。

2.2.2 机制二：【分发与归约】

这个机制通常出现在需要并行处理大规模数据的场景里。

想象这样一个任务：需要对数百份市场调研报告进行标准化字段提取。

委托模式的处理方式是“分发与归约”：经理首先将原始数据按能处理的批次大小切分，发送给对应数量的员工节点并行处理；每个员工按统一标准完成自己的那部分任务，提交规范化结果；最后，经理回收所有成果，统一汇总分析，形成最终交付物。

这种模式的价值在于将原本无法线性加速的任务变得可并行化——耗时瓶颈从“单点处理”转移到了“分发切分”和“归约整合”的效率上。在供应链Agent沙盘中，供应商资质文件的多维度审核，用的就是这个逻辑。

2.2.3 机制三：【中断机制】

委托模式中，经理把任务分出去之后并不是直接等结果，还需要设置“安全阀”

Agent在执行过程中可能跑偏，可能在某个步骤陷入死循环，也可能因为上下文偏差做出有风险的决策。中断机制的设计分两种：

【被动中断】：设定风险阈值，运行过程中自动监测。如果某个风险评分超过阈值——比如输出偏离了预设方向、调用了不该调用的数据源、响应时间异常延长——系统自动挂起当前任务并通知用户介入。
【主动中断】：把任务流程切成多个阶段，每完成一个阶段就主动停下来，等待用户确认后再继续。这个设计的核心不是不信任Agent，而是在处理高风险任务时，把决策节奏控制权交还给用户。

两种中断机制配合使用，可以大幅降低一个自动运行的系统在无人看管时产生连锁错误的风险。

在我之前的实践中，没有设置中断机制的那些实验性集群，一旦某个Agent跑偏，往往要到最终输出阶段才能发现——整个中间过程的Token和时间全浪费了。

中断机制本质上是一个时间维度的容错设计：既然错误无法完全避免，就在错误产出的第一时间阻止它继续传播。

2.3 路由与委托的关系

路由模式回答了“该把任务交给谁”，委托模式回答了“交出去之后怎么保证交付质量”。

两个模式在逻辑上是上下游关系：路由是分发层，委托是执行层。路由把任务精准地分给合适的专家，委托确保专家在接到任务后能独立完成闭环。

在实践中，它们往往是一起使用的。路由到正确的节点只是第一步，委托保证执行深度才是系统的真正分水岭。

2.4 我的实践：委托时代的【枢衡】集群

在枢衡集群的演进中，【委托模式（Delegation Pattern）】的引入是为了解决 v1.0 路由模式带来的“通讯风暴”与“上下文污染”。

2.4.1 进化起点：从【群聊互怼】到【意图委派】

在集群早期，我们采用的是全员广播模式，结果导致了严重的【通讯熵增】（即“消息风暴”）

在枢衡集群的早期版本中，我们尝试让所有 Agent 横向通信，结果 CAD（审计）在 EMD（执行）还没干完活时就开始介入，导致了严重的逻辑踩踏

后来我们引入了【意图委派】，SDC 作为‘经理’，下达的是一个包含【Belief（现状）】和【Desire（目标）】的闭环任务

员工 Agent 在接到任务后，被物理隔离在独立的子线程中。这种隔离确保了专家能“深度潜水”，而不是不断浮出水面请示

2.4.2 核心机制实战：供应链沙盘中的【分发与归约】

在处理 1688 供应商资质审核时，我们面临的是非结构化的工商信息和工厂实拍图。“经理 Agent（SDC）”将 50 家候选供应商切分为 5 个批次，分发给 5 个“RDD（资源部）”子节点并行处理

每个 RDD 节点只负责提取特定的对价参数（如注册资本、主营占比、地缘优势分数）。

最终由 SDC 进行‘归约’，生成了一张支持战略决策的对比矩阵。这一过程将原本需要 2 小时的人工审核压缩到了10分钟

2.4.3 安全锚点：从“自动跑偏”到【阶段性中断】

这是我们最惨痛也最宝贵的教训——资本主权的物理熔断

在腾讯 (00700.HK) 投资模拟实验中，我们曾因为缺乏主动中断机制，导致 Agent 在市场波动剧烈时，为了维持逻辑自洽而不断修补错误假设

后来，我们强制在 SDC 的执行链路中插入了‘人在回路’的中断点：每当资产净值触及 -3% 的预警线，系统必须挂起，等待“物理确认”

这种“阶段性止损”确保了 AI 不会在无人看管的情况下，拿着真实的策略去撞物理世界的南墙

但即使任务分对了、执行够深，一个新的问题依然悬而未决：交付的结果是正确的吗？怎么在信任的同时保持对质量的控制？

这个问题，交给第三种模式来回答

三、辩论模式：让Agent在对抗中逼近真相

单体Agent在处理复杂推理时，有一个很难突破的天花板：它对自己的错误是“盲”的

不是它不想改，而是幻觉和逻辑漏洞在个体视角下往往是自洽的

就像一个自己改自己作文的人，很难发现所有毛病——那些跳跃的因果、被忽略的反例、默认成立的假设，在单视角下全是隐形的

辩论模式解决的就是这个问题。核心思路很简单：让多个Agent围绕同一个问题进行对抗，在互相质疑中暴露各自的认知盲区，最终逼近更高质量的答案

它的底层逻辑是：

高质量决策不是一次性推理出来的，而是在【提案→质疑→修正→再质疑】的循环中逐步收敛的

3.1 辩论模式的三方架构

一个标准辩论模式需要三个角色：

【正方（提案方）】：负责生成初始方案，并提供支撑性的证据与论证

角色定位是【建设性】和【防御性】——不仅要提出方案，还要在后续辩论中维护自己的逻辑链条，回应反方的质疑

【反方（挑战方）】：负责系统性地审视正方的每一个论证环节，寻找逻辑漏洞、事实错误和未被考虑的边界情况

角色定位是【批判性】和【攻击性】——它的任务不是提出替代方案，而是用最严格的标准检验正方方案的可靠性

【法官（仲裁方）】：负责主持整个辩论流程，汇总双方的核心论点，并做出最终的裁决与收敛

注意：法官不能用和正反方同等能力的模型，必须使用推理能力更强的模型，否则面对双方各执一词的局面，它没有能力做出高质量的判断

这三个角色的分工，本质上是把人类学术评审中的“作者-审稿人-编辑”三角结构，映射到了Agent协作系统中。

3.2 辩论为什么会有效？

这个架构之所以能提升推理质量，背后有两个关键机制：

一是【对抗暴露盲区】

正方在构建论证时，天然倾向于寻找支持自己的证据，忽略反例和边界条件。

反方的存在，强制系统必须面对“如果这个假设不成立呢？”“如果这个极端情况出现了呢？”的问题。正方的盲区，在反方的视角下无处可藏。

二是【多轮交互强制深度思考】

辩论不是一问一答就结束的，而是多轮推进的

每一轮的发言，都必须直接回应对手的上一轮论证，进行针对性的回应或反击

这强制Agent在多轮交互中维持高度的上下文一致性与逻辑稳定性——你上一轮说过的话，对方会拿放大镜看，不能前后矛盾，不能偷偷换概念。

辩论模式不是让Agent“想得更多”，而是让Agent“想得更好”。前者靠加算力就能做到，后者需要结构化的对抗机制。

3.3 实践中的关键设计点

在落地辩论模式时，有几个工程细节会直接决定效果上限：

3.3.1【角色设定要明确立场】

不是简单地说“你是正方”，而是给出具体的角色身份和能力边界

比如：正方可以设定为“一名经验丰富、擅长提出创新性方案的提案策划师”，反方则设定为“一名专注于风险审查、擅长发现逻辑漏洞的资深审核员”

明确的角色设定，会让Agent的论证方向更聚焦，避免双方在无关细节上纠缠。

3.3.2【多轮辩论要设硬性上限】

辩论很容易陷入无限循环——正方回应了反方的质疑，反方又从回应中找到了新的漏洞，正方再回应……

如果不设终止条件，资源消耗会失控

通常的做法是设定轮数上限（比如3-5轮），同时设定终止条件——如果本轮辩论中，法官判定双方已就核心问题达成一致，或剩余分歧已不影响最终决策，辩论提前终止

3.3.3 【法官的模型选择是胜负手】

在辩论三角中，法官的角色是“裁判员”，不是“辩论选手”

正反方可以用能力中等但各有偏向的模型（形成真实对抗），但法官必须使用推理能力更强、在立场上更中立的模型

如果法官本身逻辑能力不够，面对双方交锋时容易被更有说服力的论证带偏，而不是做出真正准确的裁决。

这套架构也可以结合【外部知识库】、【RAG检索增强】等手段进一步提高辩论质量——比如反方在质疑事实性错误时，可以实时调取外部数据作为反驳依据，让辩论不再停留在“逻辑互搏”，而是有了事实锚点。

3.4 我的实践：辩论时代的【枢衡】集群

在枢衡集群的 BDI 治理协议中，辩论模式并不是一个独立的插件，而是已经内化为【SDC（决策）与 CAD（审计）】之间的常态化博弈

3.4.1 典型案例：C2M 实验中的“材料主权之争”

这是“对抗暴露盲区”最直观的体现。

在枢衡集群的 C2M实验中，【SDC（正方)】提议采用‘银离子喷涂技术’来解决夏季衬衫的防臭痛点，逻辑链条完整且具备技术可行性。

然而，【CAD（反方）】立即发起了‘职业怀疑’：通过实时调取欧盟 REACH 法规库，指出该涂层在出口环节存在极高的环保准入风险，且会导致 BOM 成本突破 15% 的利润红线。

这场辩论强制系统放弃了看似完美的‘高科技方案’，转而选择了成本更低、更合规的‘物理导汗织物’

如果没有反方的‘杠精式’审计，正方的盲区（法律合规性）将直接导致商业决策的物理失败

3.4.2 核心机制：腾讯 (00700.HK) 投资中的“贪婪与恐惧”博弈

这是“法官裁决”和“多轮迭代”的实战演练。

在腾讯虚拟投资项目的复盘中，我们观察到了深度的逻辑对撞。【SDC（正方）】坚决主张在财报发布前全仓买入以捕捉 Alpha 收益；

而【CAD（反方）】则基于其 ACCA 审计底座，不断质疑市场已定价（Price-in）风险以及 -5% 的回撤硬约束。

双方交锋三轮后，作为【法官】的用户介入

法官并没有简单地二选一，而是采纳了双方逻辑的交集：

执行‘锁利防御’，即在 493.2 HKD 入场的同时，在 480 HKD 设置刚性的物理对冲线

这种结果不是推理出来的，而是正反双方在‘收益’与‘风险’的极度拉扯中，由法官裁定出的帕累托最优解

辩论模式在本质上，是把审计准则中的【实质性程序（Substantive Procedures）】引入了 AI 协作。正方提交的是【财务报表（提案）】，反方执行的是【分析性程序（质疑）】

在实践中，最成功的辩论不是谁赢了谁，而是通过对抗，将那些【未被识别的重大错报风险】（如供应链中的断裂隐患、投资中的估值陷阱）在执行前彻底物理化、显性化

辩论模式解决了一个关键问题：交付的结果怎么验证质量。但辩论能跑起来的前提是——任务本身是明确的，正方反方都知道自己在争什么

如果连任务本身都模糊不清、无法预设，中心节点也不知道答案，那怎么办？

这就是【群体模式】要解决的问题：彻底放弃中心调度，让Agent在去中心化的交互中，自发找到协作方式。这也是最反直觉的一种模式

四、群体模式：没有指挥中心，协作却自然发生

前三种模式——路由、委托、辩论——都默认一个前提：系统里有一个知道全局、能做出判断的中心节点

【路由有调度器，委托有经理，辩论有法官】

但真实世界的问题是：如果连中心节点都无法做出判断，怎么办？

有些任务在开始之前，本身就模糊不清。

不是“该谁干”的问题，也不是“干得好不好”的问题，而是“我们连问题是什么都还没搞明白”

这种情况下，中心节点再聪明也没用——因为它也不知道该把任务发给谁，该委托给谁，该让谁和谁辩论

【群体模式】解决的，就是这个最棘手的问题。

它的核心思路很简单，却也很颠覆：

【既然没人知道全局答案，那就彻底放弃中心节点】

让大量Agent遵循简单的局部规则自由交互，在交互中自发找到协作方式

4.1 群体模式的框架：没有层级，只有个体与环境

群体模式的拓扑结构是网状或场状——没有上下级，没有指令链，每个节点都是平等的

在这个框架里，核心设计任务不再是编排“指令流”（谁派活、谁验收、谁复核），而是构建一个让Agent自由互动的“交互场”

这个框架中只有两个基础元素：

【个体Agent】：轻量、擅长遵循规则的执行单元。每个Agent不需要理解全局目标是什么，只需要根据当前环境中接收到的局部信息，判断“现在我需要做什么”

这种设计刻意压低了单个Agent的智能复杂度——群体模式不要求个体聪明，只要求个体对局部规则有忠实执行力

【共享环境】：Agent之间不直接对话，而是通过共享环境进行间接通信。环境承载着所有Agent的状态信息、执行痕迹和交接信号

把通信介质从“点对点对话”改为“共享环境”，是群体模式实现解耦的关键——生产者和消费者不需要知道彼此的身份或位置，它们只需要在环境中写入或读取信息

另外两个机制支撑着这个框架的运行：

【交接机制】：Agent之间的任务流转不经过中心审批

AgentA完成自己的工作后，可以直接将控制权或上下文传递给AgentB——不需要向上级请示，不需要路由匹配。权力完全下放到了节点之间

【局部规则】：硬编码在Agent设定中的明确行为规范

这些规则定义了Agent在什么情况下应该做什么、什么时候应该交接、什么时候应该终止。它们是群体模式“去中心化但有序”的底层保障

这种架构将系统的耦合度压到了最低

前三种模式中，中心节点一崩全系统停摆的噩梦，在群体模式下不存在：即使十个Agent中有三个出问题，剩余七个依然能正常工作，任务不会中断。

容错能力，从架构层面就得到了系统性保障。

4.2 群体模式的三个核心机制

4.2.1 机制一：【留痕】——间接协作的基石

个体Agent通过修改共享环境，实现与其他个体的间接通信与协作

这个过程的本质是【解耦】：生产者不需要知道消费者的身份或位置，只需要将“痕迹”写进共享环境；消费者则根据自己的职责，对环境中的变化做出响应。

这和路由模式中点对点的定向分发完全不同

定向分发需要知道接收方是谁、能力是什么

而留痕只需要一个【可共享的“黑板”】——谁写了什么、谁读到了什么，都是去中心化的。

4.2.2 机制二：【动态交接】——谁最懂谁说了算

群体模式中，Agent之间的协作链路不是预设的，而是【动态生成】的

当AgentA在执行中发现某些环节需要协助，它不需要层层上报等待审批，而是直接锁定最可能帮上忙的Agent，快速完成任务流转。

这个机制背后有一个重要的原则转变：

在前三种模式中，协作决策权掌握在中心节点手里；

在群体模式中，【谁最懂业务，就由谁来决定和谁协作】

决策权从中心转移到了最接近具体问题的节点

4.2.3 机制三：【涌现】——无法被设计，只能被培育

这是群体模式中最具魅力也最难把握的特性。

涌现是系统论里的经典现象：微观层面每个个体只执行简单的局部规则，个体可能甚至“有点笨”；但当大量个体并行交互时，宏观层面却能展现出惊人的“审慎决策”和“自我修复”能力

经典案例是【生命游戏】——三条简单规则，演化出令人震撼的复杂程度。

笔者简单复现了“生命游戏”

【生命游戏】是英国数学家康威在1970年提出的一个经典模型，它用几条极其简单的规则，展示了复杂行为如何从群体交互中自发产生

它的运行环境是一个无限大的二维网格

每个格子只有两种状态——活着或死了，最初随机设定

在每一代更新中，每个格子都根据周围八个邻居中存活细胞的数量，重新决定自己是继续存活、新生还是死亡

三条规则非常简单：

1.存活的细胞周围若恰好有2或3个存活邻居，则继续存活；
2.否则因孤独或拥挤而死亡。
3.死亡的细胞若周围恰好有3个存活邻居，则新生。

没有中央控制，没有全局规划。

每个细胞只根据周围环境做出机械反应。但就是这三条规则，经过无数代的迭代，却能涌现出令人震撼的复杂结构——滑翔机、飞船、甚至能够自我复制或进行逻辑运算的“元胞自动机”

微观枯燥，宏观却充满精密与活力

这个模型的关键价值在于，它揭示了【涌现】的底层逻辑：

【简单的局部规则，通过大量的并行互动，足以产生难以预见的复杂行为】

这也是为什么在群体模式中，我们不再执着于控制每一个执行细节，而是转向设定规则、培育环境——让Agent像生命游戏中的细胞一样，在交互中自发找到协作方式。

涌现无法被直接设计，只能通过培育来实现。它的底层公式可以这样表达：

【涌现 = 简单的局部规则 × 大量的并行互动 × 开放的环境】

这个公式意味着，构建群体模式时，核心工作不是穷举所有可能的协作路径，而是做三件事：

1.设计简洁而稳定的局部规则

2.为Agent提供充足且高频的交互机会

3.构建一个开放但反馈清晰的环境

这也呼应了多Agent系统开发中的一个深刻范式转变：开发者的角色从“建筑师”变成了“园丁”

建筑师试图掌控一切细节，但群体模式的复杂性早已超出掌控边界；

园丁设定土壤、光照和水源，然后让生命在其中自然生长

好的群体模式不是设计出来的，是培育出来的

4.3 我的实践：【枢衡】的终局目标

枢衡系统的终局不是设计一个完美的控制中心，而是让一群遵循简单规则的Agent在去中心化交互中，自发涌现出完成复杂任务的集体智能：

4.3.1 现状审计：枢衡已具备的【群体基因】

在我们的进化过程中，其实已经自发产生了一些【群体模式】的微观特征，这正是我们冲击终极形态的物理底座：

1【留痕（Stigmergy）机制】的雏形

“local_capital.db”和 “MEMORY.md”就是“共享环境”

在腾讯投资实验中，CAD（审计）并不是因为接到了 SDC 的指令才去检查风险，而是因为它观测到数据库中“对价位”这一环境信号发生了剧烈波动。这种【基于环境变化的响应】正是群体模式的基石

2【局部规则】的强制化（The BDI Protocol）

每一个成员（SDC, CAD, RDD…）都有硬编码的【BDI 行为规范】

比如 CAD 的规则是“职业怀疑”，EMD 的规则是“对价执行”。这些规则是去中心化的，即使TL（SDC）暂时宕机，CAD 依然会根据环境中的逻辑偏差发出告警

【枢衡】主要角色设定

3【初级“涌现”现象】：5022 警告与自我压实

正如此前提到的“5022 警告”，当集群通讯熵增超过临界点时，系统自发产生的 “Dehydration（脱水/压实）”动作，并不是我预设的代码，而是集群为了生存（防止上下文崩溃）自发涌现出来的【负熵行为】

4.3.2 逻辑断层：枢衡距离“终局目标”的差距

虽然有基因，但我们目前的治理仍带有浓重的 “委托模式（经理-员工）”色彩，主要差距体现在：

1.SDC 的“权力幻觉”：

目前SDC作为 TL，依然承担了过多的“指挥中心”职能。这种 “向心性” 虽然保证了确定性，但压制了多样性。在真正的群体模式下，SDC 应该消失在背景中，变成环境的一部分。

2.通信的“显式性”与“线性”：

枢衡现在的协作依然高度依赖 “@提及”和显式的文本交接，这是一种“低速同步通信”

群体模式需要的是【异步环境通信】——Agent 像蚂蚁释放信息素一样，通过修改数据库状态来引导后续 Agent，而不是通过说“请你处理这个任务”。

3.机制设计的缺失：

枢衡目前对 Agent 的激励是不充分的

借用经济学中的概念，涌现需要【激励相容（Incentive Compatibility）】

为了实现这一点，我们正在设计出一套让各个 Agent 【为了自利（如：提升逻辑分值）而自发达成目标】的博弈机制

4.3.3 进化路径：如何“培育”涌现？

为了向群体模式演进，我建议从以下三个维度执行 “园丁式治理”：

1.强化“信息素”环境（Stigmergy Enhancement）

我们将local_capital.db 从“存储库”升级为【信号场】

未来的任务流转不通过“@提及”，而是通过改变数据库中的【Task_Status】

当状态变为【AUDIT_REQUIRED】时，CAD 应该像闻到血腥味的鲨鱼一样自发介入

2.引入“博弈分值”机制（Game Theory Alignment）

模仿 EntroCamp 的虾米系统。为每个 Agent 设置 “对价分值”

1.如果 CAD 成功发现了一个重大错报风险，其分值增加

2.如果 SDC 制定了一个被证明高收益的方案，其分值增加

3.这会促使 Agent 在执行简单局部规则的同时，自发通过博弈逼近【帕累托最优（Pareto Optimal）】

3.放任“合理的混乱”

减少对执行路径的干预

搭建者作为“园丁”，只需要设定“最大回撤 -5%”和“会计准则一致性”两个最高护栏，即土壤与光照

中间的逻辑推导过程，即生长过程，可以容忍短期的冗余，以换取最后“涌现”出的创新决策

【写在最后】

这是我的第一篇万字长文。感谢您读到这里。

四个模式拆完了，但它们之间的关系——为什么是这个顺序？从路由到群体，底层逻辑到底是什么？在实际项目中该怎么选？

这些问题的答案，我将放在下一篇里：

《从路由到群体：Agent集群的四种模式，是一条从“控制”到“放手”的演进之路》

此外，也要感谢黄佳老师和《Agent设计模式》一书提供的系统性思考框架，让我有机会把零散的实战经验，整理成完整的知识体系。

我们下一篇见

【看山 Agent 架构】

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

30次集群崩溃复盘 | 20+智能体实战

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

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

cover_image

Original 看山Agent架构看山 Agent 架构

修改于

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