· 月明Verse · voiceover · 20 分钟阅读
多智能体协作：不是人越多越好
多智能体协作这个词，现在几乎成了 AI 工作流的标配。
图示：封面（原文配图暂缺）
多智能体协作这个词，现在几乎成了 AI 工作流的标配。
各种文章都在说：让 AI 组队，一个写代码一个审查一个测试，效率翻倍。听起来很合理。我也信过。
直到我在真实环境里跑了很久，发现一个反直觉的事实：大多数场景下，多 Agent 不仅没有提效，反而把简单的事情复杂化了。
原因不是 AI 不够聪明，而是协作本身是有成本的。
图示：协作成本（原文配图暂缺）
协作是有成本的
我后来画了一张图，把这个成本拆开看：
协作总成本 = 通信成本 + 协调成本 + 上下文传递成本
通信成本是什么？我要让子 Agent 知道做什么、输出什么格式、结果交给谁。说得不清楚，五个 Agent 给我跑出五个不同风格的结果，还得我回头来统一。
协调成本是什么？五个 Agent 同时跑，总有一个先完成，总有一个后完成。先完成的要不要等后完成的？后完成的发现前完成的有个 bug，要不要停下来？这些在单 Agent 场景里根本不存在的决策，在多 Agent 场景里全是成本。
上下文传递成本是什么？子 Agent 跑完了，结果要传回来，消耗 token，消耗时间。
这三个成本相加，有时候比一个 Agent 从头做到尾还要高。
所以，不是 AI 不行，是我选错了协作方式。
五种协作模式
那什么时候多 Agent 是值得的？Cloud Code 团队把协作模式分成了五种。我翻译成我自己踩过坑之后的理解：
第一种：分身的艺术——调度子Agent
适用场景：任务可以拆成独立部分，各自做完拼起来就行。
我现在的内容 Pipeline 就是典型：抓取、去重、提炼、配图、发布。五个环节顺序执行，每个环节的输入就是上一个环节的输出。这种场景，调度子 Agent 是最自然的选择。
好处是主 Agent 是我的单一控制点。任务分配、进度追踪、结果汇总，都由主 Agent 负责。我只对接主 Agent，不用同时盯着五个人。
坏处也在这里：主 Agent 成了单点。一旦我给它发消息，所有子 Agent 都可能被中断。这是我真实遇到过的问题。
图示：调度子Agent（原文配图暂缺）
所以调度子 Agent 适合的场景是：任务相对独立，我不需要频繁介入，预期跑完才有输出。
第二种：真正并行——Agent团队
适用场景：任务数量多，运行时间长，不能被任何消息打断。
我有个数据处理的需求，要对一批文件做质量检查。二十多个文件，互相独立，每个检查大概需要三到五分钟。
如果用调度子 Agent，一个外部事件进来，二十个任务全废。
Agent 团队解决的是这个问题：启动一批独立进程，每个进程长期持有上下文，专门从任务队列里抢单执行。任务队列是文件系统的某个目录，Agent 自己去看有没有新任务，做完了自己标记完成。
这种模式下，用户只和 Team Lead 对话，Team Lead 不处理具体任务，只负责任务分发。子 Agent 是真正的独立运行，不受用户消息影响。
图示：Agent团队（原文配图暂缺）
解决我那个问题的方法，就是这个公式。把子 Agent 做成独立进程，跑在不同的 tmux session 里，有自己的任务队列，主 Agent 只负责任务分发，不管执行的生命周期。这样外部事件进来，Worker 继续跑，主 Agent 响应外部事件，两件事互不干扰。
代价是：架构变复杂了。任务队列、Agent 注册、心跳检测、超时处理……这些都是要自己搭的。
第三种：师傅带徒弟——生成验证者
适用场景：对输出质量要求高，单次生成容易出错。
我让 AI 写代码有个习惯：让它先写，我 review，发现问题让它改，改完再 review。这个来回的过程就是”生成验证者”模式的核心。
区别在于：在 AI 工作流里，生成和验证是两个独立 Agent。生成 Agent 负责产出，验证 Agent 负责审查。审查不通过就打回去，生成 Agent 继续改，直到验证 Agent 说可以。
图示：生成验证者（原文配图暂缺）
这个模式适合什么？代码 Review、文档校对、方案评审。任何”第一次做容易出错，但有明确标准可以判断对错”的场景。
第四种：广播找人——消息总线
适用场景：大量独立 Agent 并行工作，需要广播通知，不需要点对点通信。
这个模式我目前没有强烈需求，但能想到的应用是：监控系统。每个监控 Agent 负责一个服务，发现问题就往总线发事件。告警 Agent 订阅这个事件，总线负责分发。监控 Agent 和告警 Agent 之间不需要知道彼此的存在。
图示：消息总线（原文配图暂缺）
消息总线的好处是解耦。发送方和接收方不认识，总线认识双方。添加新 Agent 不影响现有架构。
代价是：事件格式要统一，消息语义要清晰，调试的时候链路追踪麻烦。
第五种：会议室白板——共享状态
适用场景：多个 Agent 协作求解，没有明确的分工边界。
这个模式对应的是”黑板系统”。所有 Agent 共享一块白板，每个 Agent 看到的是同一个上下文。Agent A 写了点什么，Agent B 在这个基础上继续写，最后大家一起在这块白板上得出结论。
图示：共享状态（原文配图暂缺）
我想象的一个应用场景是：研究一个开源项目。多 Agent 同时读代码、读文档、读 issue，读到什么东西就往白板上写。最后白板上就是这个项目的完整分析报告——不是我告诉 AI 要写什么，而是 AI 自己协作出来的。
代价是：上下文会膨胀，协作过程不可预测，输出质量取决于 Agent 之间的配合。
怎么选？
图示：三问题决策树（原文配图暂缺）
我把选择逻辑压缩成三个问题：
第一个问题：任务能不能拆开独立跑？
不能拆，或者拆了还要互相等 → 不要多 Agent，一个从头做到尾。
能拆 → 进入第二个问题。
第二个问题：这些子任务跑的时候，能不能接受被打断？
能接受 → 调度子 Agent。
不能接受，比如跑数据、跑测试，预期运行期间有其他事情可能进来 → Agent 团队。
第三个问题：对输出质量要求高不高？
要求高 → 生成验证者，加一个审查环节。
质量要求一般 → 上面两个哪个顺手用哪个。
三个问题问完，大部分情况你就知道该用哪种了。没有”最强大”的模式，只有”最适合”当前任务的模式。
我的真实选择
我现在主要用两种。
调度子 Agent 用于常规的内容 Pipeline。任务天然可拆，流程固定，我只需要最后看结果。用这个模式成本最低。
Agent 团队用于数据处理这种长任务。二十多个文件要检查，互相独立，不能暴露在任何外部事件的洪流里。开始跑就去干别的，回来它们还在跑。
剩下三种我暂时没有强需求。但我在关注共享状态这个方向，如果有一天我的研究任务变得复杂了，多 Agent 协作求解可能真的比一个人做更快。
涌现很好，但生命需要新陈代谢
写到这里，我想把话题稍微拉开一点。
多 Agent 协作，本质上是一种涌现——多个简单的 Agent 放在一起，通过协作产生单个 Agent 做不到的复杂行为。这在系统科学里叫 emergence，生物学里最典型的例子是蚂蚁群：每只蚂蚁只会做很简单的事，但蚁群能筑巢、能种地、能牧蚜。这种能力不是任何一只蚂蚁有的，是整体突现的。
但自然界还有一个事实：涌现的生命会消亡。
一个蚁群不会永远活着。老蚁后死去，新蚁后没跟上，蚁群就结束了。单个的蚂蚁有寿命，整体的蚂蚁群落有新陈代谢机制。社会性昆虫解决这个问题的办法是不断产生新的个体，同时淘汰失效的个体——这是维持系统健康的内建机制。
Hermes 的 Skill 系统，恰好走到了涌现这一步，但完全没有新陈代谢。
Skill 系统的半成品困境
Hermes 的 Skill 可以被任何人创建，这是它的优点。但问题是：创建之后呢？
只能建，不能维护。
我用 Hermes 半年多，自己创建的 Skill 已经有几十个。官方提供的 Skill 也有几十个。我发现我没有办法回答这几个最基本的问题：
哪些 Skill 是官方提供的，哪些是我自己创建的？
哪些 Skill 我经常用，哪些已经积灰了？
哪些 Skill 互相冲突，用了 A 就不能同时用 B？
哪些 Skill 适合什么场景，我没有依据，只能靠猜？
更糟糕的是，我没办法统计使用量。我前两天想从源码层面加一个 load_count 统计，改了两行发现要动 Hermes 的核心逻辑，算了。但这个问题本身就说明了一个设计缺陷：Skill 系统没有内置的使用追踪机制。
我还发现一个更具体的问题：我分不清哪些 Skill 是我自己做的，哪些是 Hermes 官方提供的。
比如 skills-maintenance 这个 Skill，它能跑健康检查、输出诊断报告——但这不是 Hermes 官方做的，是我照着网上文章拼出来的，我自己都不知道自己当时有没有写对。如果我不记录下来，下次遇到问题，我根本想不起来我自己做过这个。
这就是 Skill 系统的本质困境：它鼓励创建，但不提供维护的途径。
四个 Skill 互踩的真实故事
说个具体的例子。
我昨天要给一篇文章配图，发现 creative 目录下有四个 Skill：
svg-to-hires-pnghtml-to-png-renderhermes-article-illustration-workflowexcalidraw
用途都是”生成配图”，但质量参差不齐。我一个个读过去，发现它们互相踩对方：
svg-to-hires-png 的避坑指南里写着：“HTML + Playwright 截图绝对不要用，字模糊，分辨率不够。“读起来像过来人的血泪教训。
但问题是，html-to-png-render 的输出质量其实更好——CSS Grid 控制布局，Playwright 渲染深色主题效果现代。真正分辨率翻车的原因是我没有设置正确的 viewport 参数，不是 HTML + Playwright 这个方法本身有问题。
svelte-to-hires-png 的警告是对的，但它把锅扣在了方法论上，而不是使用者的操作上。结果就是：下次遇到配图需求，我会因为这段警告放弃一个更好的方案。
更离谱的是，excalidraw 依赖的一个 npm 包链路已经坏了，根本跑不通。但 Skill 文档里完全没有提示这一点。新来的使用者会以为按照文档操作就能出图，结果卡在 npm 报错里不知道哪里出问题。
读到这里你发现没有：这四个 Skill 没有元数据。没有创建时间，没有质量评分，没有信任等级，没有声明和谁冲突。 我判断用哪个，只能靠全文读一遍，然后赌自己的判断力。
为什么 Skill 系统对 Hermes 是灾难
我思考了一下，这件事的本质问题不是”Skill 质量参差不齐”。
本质问题是：Skill 系统的维护完全依赖人的记忆，而人的记忆是不可靠的。
生物学里有个概念叫”孤儿基因”——基因突变产生的新基因，如果没有配套的维持机制，很快就会被自然选择淘汰。Skill 也是一样：创建一个 Skill，如果没有配套的记录、更新、淘汰机制，时间一长，它就变成了知识库里的孤儿——我不知道它是谁写的，不知道它还能不能用，不知道它和谁冲突。
当 Skill 数量从十个变成五十个，孤儿 Skill 就会开始污染 Agent 的决策。Agent 读到一堆互相矛盾的 Skill，不知道该信哪个，最后选了一个次优方案，输出了质量差的结果，然后用户以为是 Agent 能力不行。
实际上不是 Agent 的问题，是** Skill 系统的基础设施缺失**。
我的解法
目前我只能靠人肉维护：每个 Skill 的 YAML frontmatter 里强制加元数据。
---
created: 2026-04-18
updated: 2026-04-18
quality_score: 1-5
trust_level: verified | internal | deprecated
replaces: [skill_name]
conflicts_with: [skill_name]
deprecated_reason: "..."
---quality_score 是我自己的评分，5 分最优，1 分废弃。trust_level 区分官方验证过的和我自己拼的。replaces 和 conflicts_with 声明关系，让 Agent 仲裁时有依据。
但这个方案有个根本问题：它是人写的，不可靠。
我给自己定了一个规则：每次创建 Skill 都要填这些字段。但我不能保证下次创建 Skill 的时候还记得这个规则，更不能保证下次我就不会偷懒。
Hermes 官方如果真的想让 Skill 系统健康运转，需要在工具链层面解决：创建 Skill 时强制要求元数据，输出 Skill 列表时显示质量评分和信任等级，过期的 Skill 有明确的淘汰标记。
在那之前，我能做的是：记下来，遵守它，然后等官方出手。
最后
多 Agent 不是银弹，Skill 系统也不是。
它们都解决了一个问题——复杂性管理——同时引入了另一个问题：系统本身的复杂性维护。
多 Agent 通过协作分散认知负载，但引入了协作成本。Skill 系统通过自定义扩展能力，但引入了维护成本。
我的建议是：从简单的开始，等你真的遇到瓶颈了，再往复杂走。不要因为”看起来很厉害”就用多 Agent。也不要因为”能创建 Skill”就拼命创建，创建了不维护，它就是债务，不是资产。
有时候一个 Agent 做到尾，比五个 Agent 互相等待更快。
有时候一个写好的 Skill，比二十个混乱的 Skill 更管用。
本文提到的技术方案基于 Hermes Agent 和 Cloud Code 的多智能体协作设计，关于 Skill 系统的维护工具链改天再写。