原文：https://mp.weixin.qq.com/s/YFU_ZLN8dvvI3cO9vHM53w
为什么需要多 Agent？
单个 Agent 有两个根本限制。
第一，上下文窗口是有限的。 一个复杂项目涉及的文件、历史、工具调用结果，很快就会撑满单个上下文窗口。窗口越满，模型注意力越分散，"Lost in the Middle"问题越严重，输出质量下降。
第二，一个 Agent 同时只能做一件事。 如果一个任务有四个相互独立的子任务，单 Agent 必须串行------研究完再写，写完再审查，审查完再测试。四个子任务各需 5 分钟，总共 20 分钟。
多 Agent 的架构价值：让子任务并行，让每个 Agent 保持干净的上下文，专注于自己的职责范围。
但多 Agent 不是免费的------它引入了协调开销、通信成本、上下文一致性问题。设计糟糕的多 Agent 系统，协调成本会吃掉并行带来的所有收益，甚至让整体变得更慢更脆。
这篇要讲的，就是三个框架各自怎么解决这个问题。
多 Agent 系统的四个核心设计问题
在拆解三个框架之前，先明确多 Agent 系统必须回答的四个架构问题：
角色怎么分离------谁做什么，怎么定义每个 Agent 的职责边界，防止职责重叠或遗漏。
上下文怎么隔离------Agent 之间的信息怎么分隔，防止一个 Agent 的上下文污染另一个 Agent 的判断。
Agent 之间怎么通信------结果怎么传递，任务怎么分配，协调靠语言还是靠结构。
结果怎么汇总------多个 Agent 的输出怎么合并，冲突怎么解决，最终给用户一个一致的答案。
三个框架对这四个问题的答案，揭示了三种完全不同的多 Agent 哲学。
OpenClaw：两层模式，从子 Agent 到 Agent Teams
多 Agent 模式，各有适用场景
OpenClaw 的多 Agent 支持分两个层次，常被混淆，但其实解决的是不同的问题：
第一层：子 Agent（SubAgent）
主 Agent 通过 sessions_spawn 工具或 /subagents spawn 命令派生子 Agent。调用是非阻塞的------主 Agent 发出指令后立刻继续工作，不等待子 Agent 完成。子 Agent 完成后，把结果发回给主 Agent（或直接发到指定的消息渠道）。
这是最常用的模式，适合"主 Agent 需要把某个子任务外包出去，自己继续干别的"这种场景。
关键限制：子 Agent 只能向主 Agent 汇报，不能和其他子 Agent 直接通信。 所有协调都要经过主 Agent 这个中间层。
第二层：路由 Agent（Routed Agents）
Gateway 层面的多 Agent，每个 Agent 有独立的工作空间（workspace）、会话存储（sessions）和认证配置（auth profiles）。通过 bindings 配置把不同渠道、不同用户路由到不同的 Agent。
适合场景：工作和个人的 Agent 分离、不同用户访问不同 Agent、需要严格安全隔离的场景。
这一层的 Agent 之间完全独立------不共享记忆，不共享上下文，通信需要通过 webhook 或消息队列显式转发。
上下文隔离：文件系统是协调层
OpenClaw 的多 Agent 上下文隔离，核心是文件系统隔离：
每个 Agent 有自己的 workspace，独立的 MEMORY.md、SOUL.md、会话记录，存储在 ~/.openclaw/agents/<agentId>/ 下。
Agent 之间通信的标准方式是文件------一个 Agent 写结果到某个文件，另一个 Agent 读这个文件。
Claude Code：Agent Teams，P2P 通信，文件系统协调
两种模式的本质区别
Claude Code 的多 Agent 分两个明确的层次，官方文档直接说明了区别：
子 Agent（Subagents）：在单个会话内派发，只能向主 Agent 汇报结果，不能和其他子 Agent 直接通信。适合"快速的、聚焦的、汇报给主 Agent 就完事"的任务。
Agent Teams（实验性功能） ：多个完全独立的 Claude Code 实例组成团队，每个成员有自己的上下文窗口，可以直接互相通信（P2P），不需要经过 Team Lead 中转。
这个 P2P 通信能力是 Agent Teams 相对于子 Agent 最核心的架构差异。子 Agent 像一组分别汇报的承包商，Agent Teams 像一个坐在同一个房间里的项目组，成员之间可以直接对话、相互验证、共同决策。
文件系统作为协调层
Claude Code 多 Agent 协调靠的不是互发消息，而是共享文件。
类比一下：团队协作写文档，不是每个人改完口头转述给下一个人，而是大家都能打开同一个共享文档实时看到对方写了什么。
Claude Code 里，每个"Teammate"就是一个独立运行的 Agent 实例，各自负责不同的子任务。它们之间的协调就是这个逻辑------一个 Teammate 写完了某个模块，另一个需要调用这个模块的 Teammate，直接读文件就知道了，不需要有人通知它。
但如果多个 Teammate 同时修改同一个文件，就会产生冲突。Claude Code 用 Worktree 模式解决这个问题------每个 Teammate 在自己独立的 Git 分支里工作，就像每个人先在自己的草稿纸上写，写好了再提交合并，不会出现两个人同时改同一行、互相覆盖的情况。
什么时候用 Agent Teams，什么时候用 Subagent
官方给出了明确的选择标准：
用 Subagents：任务是快速的、聚焦的、不需要相互通信、只需要汇报结果。
用 Agent Teams：任务需要跨前端/后端/测试多个层面协调、需要 Teammate 之间直接共享发现和挑战彼此的方案、任务可以真正并行且相互依赖少。
单 Session 更好：顺序任务、修改同一文件、任务之间依赖性强。
Hermes Agent：隔离子 Agent + PLUR 共享情景记忆
核心设计：完全隔离，通过文件和 Skills 协调
Hermes Agent 的多 Agent 设计哲学是：每个子 Agent 完全隔离，包括上下文、终端和对话历史，通过文件系统和 Skills 层进行协调。
-
独立的对话线程（独立上下文，不继承父 Agent 历史）
-
独立的终端实例
-
通过
execute_code的 Python RPC 脚本（零上下文成本的工具调用通道）
Skills：跨 Agent 的共享知识层
多个 Agent 协作时，有一个很现实的问题：一个 Agent 摸索出了好的做法，另一个 Agent 完全不知道。
Hermes 解决这个问题的方式，不是让 Agent 互相发消息同步经验，而是通过 Skills 这个共享知识库。
Skills 是什么？就是 Agent 完成复杂任务后，自动写下来的"工作笔记"------这件事怎么做、踩过什么坑、下次注意什么。Markdown 格式，存在本地文件里。
默认情况下，每个 Agent 的笔记是各自保存的，互相看不到。但如果把 Skill 放进 ~/.hermes/skills/ 这个共享目录，所有 Agent 启动时都会加载它。
举个例子：你让一个 Agent 研究竞品，它摸索出了一套高效的分析流程，把这个流程保存成了 Skill。下次另一个 Agent 做类似任务，直接加载这份 Skill，不用从头摸索。
更进一步的是 PLUR 插件------它让 Agent 之间的学习可以双向传播。你纠正了某个 Agent 的做法，这个纠正会自动同步给同项目的其他 Agent，不需要手动更新每一个。
这是 Hermes 多 Agent 协作最独特的地方：Agent 之间不靠实时通话协调，靠的是积累共同经验。今天一个 Agent 踩过的坑，明天所有 Agent 都绕过去了。
多 Agent 系统设计的核心取舍
取舍一：让 AI 决定怎么分工，还是你来定规则？
同一件事，两种做法。
一种是告诉 AI"帮我做竞品分析"，让它自己决定先查什么、再查什么、什么时候结束。省事，但每次做法不一样，出了问题你不知道卡在哪。
另一种是你把步骤写清楚："第一步搜资料，第二步整理对比，第三步写报告，每步完成后才进下一步。"慢一点，但出了问题一眼就看到哪步没走完。
任务越固定、越不能出错，越该你来定规则。任务越开放、越需要随机应变，越该让 AI 自己判断。
取舍二：Agent 之间互发消息，还是靠文件传话？
想象两个同事协作。
一种是坐在一起，做完一块就口头告诉对方，对方可以马上追问。实时，但两个人得同时在线。
另一种是做完存到共享文件夹，对方什么时候方便什么时候去取。不用同步，但你不知道对方什么时候看到。
多 Agent 协作也是这两种模式。需要来回确认的任务，用实时消息。只是传递结果的任务，用文件更省事。
取舍三：子 Agent 知道主 Agent 在想什么，还是完全不知道？
你让一个同事去审查你的方案。
如果他全程旁听了你的思考过程，他审查时会下意识顺着你的逻辑走，很难发现你一开始就想错的地方。
如果他什么都不知道，直接看你的结论，反而更容易发现问题。
子 Agent 也是这样。需要它帮你执行、背景越多越好 → 让它继承主 Agent 的上下文。需要它帮你审查、独立判断 → 让它从零开始。