# 多 Agent 协作：隔离和共享怎么平衡

## 从单体到多体

前一篇讨论了 Hermes 的三层自动改进机制。当单个 agent 的改进能力变强后，一个自然的延伸是让多个 agent 协作处理更复杂的任务。但多体协作马上带来一个矛盾：每个 agent 需要隔离的上下文空间来保证推理质量，同时又需要共享知识来提升协作效率。这两个需求在抢同一份有限资源。

在《多 Agent 不是银弹》那篇中，我们讨论过多 agent 系统的 token 消耗通常是单体的 15 倍。Hermes 的 ACP 协议用两个参数卡住了这个矛盾的边界：900 秒超时和 24000 字符消息长度上限。

这两个数字不只是性能参数，它们实际上定义了协作模式的可行空间。24000 字符约束下，agent 之间只能传递压缩后的关键信息，没法共享完整的推理过程。实际运行中，跨 agent 的消息基本只保留结论和关键数据点，推理中间步骤被丢弃。每个 agent 因此需要在隔离环境中重建足够的上下文来独立推理。

我认为这里有一个被低估的设计洞察：隔离在这里不是一个主动追求的设计理想，而是一个被物理约束逼出来的现实。但恰恰是这种"被逼的隔离"反而产生了好的工程结果。因为完全共享推理过程的系统，容易出现一个 agent 的错误推理链污染其他 agent 的情况。强制隔离意味着每个 agent 必须独立验证自己的推理，这实际上提供了一种天然的错误隔离机制。

## Hermes 的三种编排哲学

在这个约束下，Hermes 生态中出现了三种不同的编排方式。

**竞争式**。Gladiator 让两个团队分别处理同一个任务，然后合并结果。评分公式里"学习能力"的权重比"答案质量"还高。竞争的目的是选出最能从过程中学习的 agent，不只是选出最好的答案。每次竞赛成本 5-6 美元，适合高价值决策场景。我认为竞争式的真正价值在于它提供了天然的 A/B 测试框架：两个策略处理同一个任务，结果直接可比。这种内建的对比实验能力，让系统能持续产生关于"哪种策略更好"的信号，而不需要额外搭建评估基础设施。

但竞争式有一个隐含的资源效率假设：你愿意为了获得对比信号而付出双倍（甚至更多）的计算成本。5-6 美元一次竞赛，如果某个任务一天触发 20 次，月成本就到了 3000 美元以上。这意味着竞争式在实践中只适用于那些决策价值远超计算成本的场景。

**对抗审议式**。Council 设置了 5 个角色（质疑者、反对者、仲裁者等），通过 MCP 服务器协调，受 60 秒超时限制。角色分化减少了"所有人做同样的事"的冗余。但 60 秒意味着每个角色发言机会有限，讨论没在窗口内收敛就会被强制终止。这个设计选择传递了一个判断：宁可得到一个不完美但及时的结论，也不要一个完美但迟到的结论。在多数工程场景中我认同这个判断。决策延迟的隐性成本往往比决策质量的轻微下降更严重。

**协同式**。ACP 和 Swarm 走严格隔离加结果汇总。每个 agent 在自己的沙箱独立工作，完成后提交给协调器。隔离性最强，推理质量可预测性最高。代价是知识共享效率最低：两个 agent 在处理同一个问题的不同侧面时，没法利用对方的中间结果。这意味着协同式在任务之间相关性高的场景中效率损失最大，在任务完全独立的场景中效率损失可以忽略。

三种编排方式不是互斥的。一个系统可以在不同阶段使用不同的编排策略：探索阶段用竞争式产生多样性，评估阶段用审议式收敛共识，执行阶段用协同式保证可靠性。

## Agent 数量的收益递减

OpenCode 项目配了 17 个 agent，分成研究、规划、实现、质量、文档、基础设施六大类。17 这个数字远超大多数任务需要的并行度。我的判断是这更像技术演示而非生产最佳实践。

更务实的经验法则是从 2-3 个 agent 开始。从 1 到 2 的提升通常明显（两个 agent 并行处理独立子任务）。从 2 到 3 取决于任务本身是否有足够并行性。从 3 往上就不确定了，协调开销的增长可能抵消并行带来的收益。

为什么协调开销增长不是线性的？因为 N 个 agent 之间的潜在交互路径是 N*(N-1)/2。从 3 个 agent 到 4 个，交互路径从 3 条变成 6 条。从 4 到 5 变成 10 条。即使不是每条路径都需要通信，协调器需要考虑的潜在冲突也在二次增长。

这跟《多 Agent 不是银弹》中的观察一致：多数情况下，打磨单体 agent 配合扎实的验证框架，性价比高于堆 agent 数量。Hermes 生态里真正跑起来的多 agent 部署，多数也就 2-5 个 agent 的规模。我认为这个数字范围会在相当长的时间内保持稳定。协调机制的技术进步可能把甜点往上推一两个位，但根本的二次复杂度问题不会消失。

## 隔离粒度怎么选

隔离可以发生在不同层级。进程级隔离最简单，agent 各跑各的进程，消息传递通信。容器级隔离更彻底，每个 agent 有自己的文件系统。沙箱级隔离最极端，代码执行被限制在安全策略内。

粒度选择直接影响协作便利性。进程级下 agent 间可以共享内存快速交换数据，但一个 agent 崩溃可能影响同机器上的其他 agent。沙箱级下安全性最高，但数据交换必须通过协调器中转，延迟明显增加。

大多数 Hermes 生产部署选了中间方案：容器级隔离加轻量消息队列。在安全性和性能之间取了个中间值。我认为这个选择本身反映了一个成熟度判断：在系统行为还不够可预测的阶段，容器级隔离提供了一个"出了问题最多丢一个容器的工作"的兜底。随着系统稳定性提升，部分场景可能会放松到进程级来换取性能。但初始阶段选择更严格的隔离，让你有了"放松约束"的选项；反过来，如果初始选择太宽松，出了问题后再收紧就需要架构重构。

## 知识一致性的问题

在隔离架构下有个容易被忽视的问题：多个 agent 各自在隔离环境工作时，对同一个事情的理解可能产生分歧。一个 agent 处理任务 A 时学到了某个 API 的新行为，另一个 agent 处理任务 B 时还在用旧理解。协作汇总时就可能产生矛盾输出。

这个问题本质上是分布式系统中的一致性问题在知识层面的映射。CAP 定理告诉我们，在分布式系统中不可能同时满足一致性、可用性和分区容忍性。多 agent 知识系统面临类似的约束：不可能同时实现强一致性（所有 agent 知识同步）、高可用性（agent 不需要等待同步就能工作）和隔离性（agent 之间不互相干扰）。

协同式编排通过集中汇总来缓解，协调器检测和解决矛盾。但协调器自己也有上下文窗口限制，agent 数量一多，汇总阶段需要处理的信息量线性增长。

竞争式编排对这个问题的回答更直接：两个团队独立工作，结果通过评分选胜者，不需要在知识层面达成一致。但失败方过程中发现的有用线索就丢了。这是一种"接受信息损失来换取决策效率"的取舍。

目前可观察到的一种折中是：隔离执行、共享记忆库。agent 在任务处理过程中保持隔离，完成后把新知识写入共享存储，下一轮任务时所有 agent 从同一个库加载。这在时间维度上做了平衡：同一时刻隔离，跨任务周期共享。缺点是知识共享有一轮的延迟。在快速变化的环境中，一轮延迟可能意味着 agent B 在使用 agent A 已经证伪的知识来做决策。

当 agent 的改进能力和协作能力同时增强时，一个更根本的问题浮现：这些越来越强的自动化能力应该被赋予多大的自主权？谁来决定这个边界？