一、一个反直觉的发现：Agent越多，系统越脆弱
在搭建多智能体系统的初期，一个常见的误区是按“功能细分”的逻辑，将系统拆分为多个专用Agent。笔者在[枢衡]V2.0中，将集群拆成9个Agent，分别映射9大部门的职能，每个Agent配备专属工具集和提示词，角色边界看起来非常清
假设很朴素：角色分得越细，整体产能越高。
但系统运行后，三个问题同时爆发，互相加剧：
1.1 上下文窗口被聊天记录迅速撑爆
9个Agent每次协作，都会在共享上下文里产生大量对话历史、中间推理步骤、状态同步消息。跑不了几轮，上下文窗口就逼近上限，系统开始丢弃早期信息——而早期信息往往是最重要的任务约束和验收标准
1.2 状态同步延迟呈指数级上升
Agent之间的信息传递理论上应解耦且高效。但9个节点以网状结构互相通信时，消息链路变得极长，任何一次状态更新都需要经过多道序列化与反序列化。延迟不是线性叠加，而是随着节点数量呈现近指数级增长
1.3 单一节点的幻觉或逻辑死锁会像病毒一样传染
某个Agent如果输出了错误信息或陷入逻辑死锁，这条错误信息会通过全局共享记忆库迅速被其他Agent读取并作为决策依据。在紧耦合架构中，任何一个拜占庭节点，都会导致这种级联效应
几轮测试之后，从数据里确认了一个和直觉完全相反的结论：在多Agent系统中，节点数量与系统整体能力不是正相关，而是呈倒U型关系。越过某个临界点之后，每增加一个Agent，都是在给系统的脆弱性充值，而不是在给系统的能力加分。
二、根因分析：三个深层病灶
动手精简之前，用了一整周时间做故障复盘，把9节点集群的所有崩溃日志和异常记录逐条分析。最终锁定了三个根因：
2.1 通信拓扑过度耦合
早期设计的是全联通通信拓扑——任何Agent都可以直接给任何其他Agent发消息。这在节点数少时效率很高，但9个节点的全联通意味着36条潜在通信链路，任何一条链路的消息延迟或错误，都可能触发链式反应
更关键的问题是，Agent之间的消息没有优先级分层——用户指令和内部握手确认混在同一个队列里排队。这就是后来消息风暴事件的底层结构
2.2 角色边界虚假清晰
表面上看，9个Agent各有分工。但实际上，数据清洗Agent和逻辑推理Agent的职责边界在很多任务中是重叠的——谁该先处理输入？谁该做最终输出校验？当边界模糊时，Agent会重复执行同一子任务，或者互相等待对方先行动
这种“隐性内耗”在单次任务中不明显，但日均几十次任务累积下来，Token浪费非常可观
2.3 共享记忆无隔离机制
9个Agent共享一个全局记忆库。这个设计的原始需求是“提高信息透明度”——让每个Agent都能参考全局上下文做决策。但代价是：任何一个Agent的认知污染都会被写入记忆库，然后被所有后续Agent无差别读取
典型案例：逻辑推理Agent在一步推论中用了错误的假设，这个假设被写进记忆库，合规审查Agent基于这个错误假设做了合规判断，最终整个输出链路全部偏离
三、解决方案：砍节点+改架构，两个动作同时做
确认根因之后，做了两个决定。
3.1 决定一：砍节点，从9个压缩到5个
用PVP存证审计的视角重新审视所有Agent的职能边界，发现很多“分家”设计制造了不必要的通信链路和职责重叠
之前按照功能细分拆出的9个节点，实际上存在大量“隐性内耗”：战略Agent定完目标，还要向标准Agent“宣讲”规则；审计Agent审完风险，还要推给核查Agent“复检”事实；执行Agent干活时，人资Agent和应急Agent在旁边反复插手
这些环节不是增值，是流程债务
最终通过逻辑聚合，将原有分散的职能深度合并为5个核心Agent，每个Agent承载一个不可分割的完整闭环：
SDC（决策与标准）：原SDC + SOD合并。大脑与宪法合一，把“战略决策”和“流程标准制定”合进同一个Agent，由SDC直接固化流程标准。战略与规范不再分家，彻底消除“规则宣讲”的冗余环节
CAD（审议与合规）：原CAD + IAS合并。盾牌与审计合一，把“风险审议”和“事实核查”合并为单一的“风控闸门”，执行“交付即审计”的一站式服务。审议（风险）与核查（事实）不再分家，避免同一批数据被两个Agent反复过手
EMD（统筹与执行）：原EMD + HRD + RRA合并。将军与攻坚合一，把统筹、人资、应急响应三合一，执行层只有一个核心负责人。杜绝“执行链条”过长导致的路径漂移，也消除了人资Agent和应急Agent对执行过程的无效干扰
RDD（资源与情报）：保留独立职能。哨兵与资源，作为独立的信息探测器，专门负责数据探测和资源调度，确保数据主权的客观性，不被决策层或执行层干扰
EOD（落地与优化）：保留独立职能。工匠与优化，专注技术落位、工具优化与最终成果的“资本化”，确保交付质量。这是集群的“手”，必须独立，不能被统筹逻辑污染
为什么是5个？
在测试环境中分别跑了4节点、5节点、6节点三个版本，对比了Token消耗、端到端延迟和任务准确率
5节点在所有维度上都最优，4节点任务覆盖不全，需要人工补位（特别是RDD和EOD合并会导致“既当哨兵又当工匠”，数据客观性被交付压力污染）；6节点开始出现通信边际成本回升，重新逼近9节点的脆弱性
所以5个是当时场景下的最优收敛点，也是PVP存证审计后“职责闭环”的最小完备集
3.2 决定二：改架构，从“指令分发”升级为“意图委派”
精简节点只是第一步。如果协作方式不变，5个节点依然会产生不必要的通信开销。
在原来的9节点架构中，采用的是“指令分发”模式。编排调度Agent给子节点的指令长这样：
指令分发Prompt示例（优化前）：
你现在需要完成一份供应商评估报告
步骤1：从数据库中提取近6个月所有供应商的交货记录
步骤2：按到货准时率从高到低排序
步骤3：筛选出准时率低于90%的供应商
步骤4：逐一核查这些供应商的延迟原因，区分是物流问题还是产能问题
步骤5：生成一份评估报告，包含供应商名称、准时率、延迟原因分类、改进建议
报告格式使用标准模板A
完成后把报告全文发给我，我审核通过后再进行下一步
这个Prompt定义了每一步的执行顺序、具体操作方法和输出格式。子节点不需要思考“为什么要这么做”，只需要逐条执行。好处是可控性高，坏处是：编排调度Agent成为全局唯一的决策瓶颈，任何一步的微调都需要重新下发指令，而且，子节点在每一步执行完都必须把完整的中间结果发回给编排调度Agent审核，这就是Token消耗的大头
在精简后的5节点架构中，把这个模式改成了“意图委派”。同样的任务，编排调度Agent给子节点的指令变成了这样：
意图委派Prompt示例（优化后）：
任务目标：生成一份供应商风险评估报告
验收标准：
①覆盖近6个月所有合作供应商的交货数据
②识别出准时率低于90%的高风险供应商
③对每个高风险供应商给出风险归因（物流/产能/其他）和初步改进建议
边界约束：
①报告格式自选，但必须包含供应商名称、准时率、风险归因三项信息
②不得直接修改数据库中的供应商评级
③如果某供应商近3个月无任何交货记录，标注“数据不足”并排除出评估范围
请在完成后提交报告摘要和关键风险发现，中间过程自行规划
对比两个Prompt，核心差异不在字数，而在权力下放的程度
第一个Prompt把“怎么干”规定到了每一步的操作细节；
第二个Prompt只定义“干到什么标准算合格”和“什么绝对不能干”，至于怎么提取数据、怎么排序、怎么核查延迟原因、用什么报告格式，全部交给子节点自己决定
这一个转变带来的效果比砍节点本身更显著。Token消耗降低约40%，因为子节点之间不再传输海量的中间推理步骤，只传输结构化的里程碑状态。逻辑漂移明显减少，因为每个Agent不再受其他Agent中间步骤的干扰，只在自己的上下文空间内做专注推理
四、配套机制：内存分区，为每个Agent建立故障隔离舱
精简节点和改架构之后，还有一个没有直接触及的隐患：即使只有5个Agent，如果它们依然共享全局记忆库，认知污染的风险依然存在。
为此引入了内存分区机制。具体设计如下：
私有记忆库：每个Agent建立独立的私有记忆库，执行过程中的中间变量、临时状态、推理草稿一律写入私有库，不对外暴露
共享状态板：只在关键里程碑，由Agent主动向共享状态板写入结构化状态快照（一行JSON，包含任务ID、当前阶段、输出摘要）。其他Agent可以读取状态板来感知全局进度，但读取不到其他Agent的中间推理过程
权限隔离：合规审查Agent拥有只读权限，可以检查任何Agent的最终输出，但它自己的中间审查过程也写入私有库，不暴露给执行Agent
这套内存分区机制，使得当一个Agent产生幻觉或进入错误分支时，它的“认知污染”被严格限制在自己的私有空间内，不会通过共享记忆去带偏其他节点。不是保证不出错，而是保证出了错不传染
五、可复用资产：多Agent系统精简自查清单
基于这次从9砍5的完整经验，提炼了一张架构精简自查清单。每次搭建或调整多Agent系统时，可以逐项核对：
| 检查维度 | 自检问题 | 整改方向 |
|---|---|---|
| 节点必要性 | 每个Agent是否都有不同于其他Agent的schema、工具集或治理规则？如果只是因为提示词不同，是否可以合并？ | 合并提示词差异型Agent |
| 通信拓扑 | 当前通信拓扑是全联通还是有限联通？是否存在不合理的网状依赖？ | 限制不必要的跨Agent通信链路 |
| 职责边界 | 每个Agent的输入-输出是否明确且不与其他Agent重叠？是否有多个Agent在未协调的情况下处理同一类子任务？ | 明确各Agent的能力边界，消除隐性职责重叠 |
| 消息优先级 | 用户消息是否拥有最高优先级？Agent内部通信是否有可能堵塞用户指令？ | 设置用户消息优先通道 |
| 记忆隔离 | Agent之间是否存在共享记忆库？如果有，是否设置了写权限隔离和故障隔离机制？ | 引入私有记忆库和共享状态板隔离 |
| 容灾回退 | 单个Agent故障时，系统能否降级运行？是否能回退到单Agent模式？ | 设计单Agent独立运行和测试能力 |
使用说明：搭建完成后逐项检查
优先级：消息优先级和记忆隔离为P0（直接影响系统可靠性），节点必要性和职责边界为P1（影响运行效率），通信拓扑和容灾回退为P2（影响长期可维护性）
六、一个更深刻的设计原则：好的系统靠边界，不靠连接
这次精简留下的，不只是5个节点的具体配置方案，而是一个更底层的设计原则
9个节点到5个节点，减少的不仅是Agent数量，更是系统内部的交互边界、状态同步开销和故障传播路径。每一次精简，都是在用更清晰的边界，替代更密集的连接
这个原则后来贯穿了所有Agent集群的设计。无论是供应链C2M场景中的Agent角色划分，还是猪周期智能推演系统中的Agent集群设计，第一反应都不是“多加几个Agent”，而是“最少需要几个Agent才能完成这个认知链条”
这不是保守，是工程经济学。每多加一个Agent，加的不仅是一次模型调用的费用，还有一个新的故障点、一条新的通信链路、一个需要监控和维护的新组件。在资源有限的前提下，做减法比做加法更需要勇气，但也更能出效果
结语
多Agent系统的核心挑战，不是怎么把更多Agent塞进一个集群里，而是怎么让每一个Agent都待在它不可替代的位置上
如果在搭多Agent系统，或者正在考虑从单Agent拆成多Agent，建议先问一个问题：当前系统的每个Agent，都有自己的不可替代性吗？如果答案是否定的，不妨试试减法
关于什么时候该拆、什么时候不该拆的系统性决策框架，详见文章《多Agent一定比单Agent更强吗？拆分的5个核心信号与评测框架》。两篇配合阅读，构成一套完整的架构决策体系
【看山 Agent 架构】
工信部 AI 技术应用（高级）认证
30次集群崩溃复盘 | 20+智能体实战
深耕 Agent 集群架构，用商科思维重构复杂系统效率
注：本文内容由 AI 辅助创作，作者对内容结果负责
