这两年，很多 AI 工作流喜欢把一个任务拆成“产品经理、架构师、程序员、测试工程师”等多个 Agent，仿佛角色越多，结果就越专业。
我的实际体验恰好相反：多 Agent 最有价值的地方不是模拟一家公司，而是提供隔离、并行和独立视角。如果没有清楚的主控和边界，Agent 数量越多，通信成本、重复劳动和责任分裂反而越严重。
证据说明：子代理隔离和 Git worktree 属于 Hermes 官方机制；“一个主脑、多个独立镜头”是我的实践方法，不代表多 Agent 只有这一种正确架构。
子代理并不知道主对话发生了什么
Hermes Agent 官方文档明确说明，子代理从一个完全隔离的新会话开始，不知道父会话历史、此前工具调用或用户曾经说过什么；它只得到父代理传入的目标和上下文。[1]
这既是优势，也是风险。
- 优势：不会被主代理的推理过程过度锚定，适合独立复核；
- 风险：任务描述不完整时，它会在缺失背景下自行补全，得到看似合理但不适用的答案。
所以“让另一个 Agent 看看”并不天然等于独立审查。真正的独立审查需要提供原始代码、测试、错误和目标边界，而不是只把主代理的结论摘要转述一遍。
一个主脑，多个独立镜头
我更倾向于以下结构：
用户
↓
主 Agent：目标、范围、当前真相、最终验收
├─ 独立研究镜头
├─ 代码审查镜头
├─ 反方与风险镜头
└─ 有界机械执行镜头主 Agent 始终负责：
- 理解用户真正要解决的问题；
- 决定产品范围和技术边界；
- 选择哪些候选值得吸收；
- 维护唯一的当前真相；
- 执行最终测试、发布和验收。
子代理只提供候选、证据或独立判断，不拥有发布权，也不把自己的总结直接变成事实。
什么时候值得增加一个 Agent
我现在使用一个简单判断：它是否能带来主 Agent 当前没有的新价值？
值得委派的情况包括：
- 需要真正独立的反向审查，降低确认偏误；
- 多个研究方向互不依赖，可以并行取证；
- 大量工具过程会淹没主对话，但子任务边界清楚；
- 某个模型、工具或运行环境具有明显不同的能力；
- 需要在隔离分支中尝试一种候选实现。
不值得委派的情况包括：
- 一次简单文件读取或单条命令；
- 子代理只能重复主 Agent 已经做过的检查；
- 任务需要频繁向用户澄清；
- 多个 Agent 会同时修改同一个工作区；
- 没有明确的输出格式和验收标准。
并发写代码必须隔离工作区
如果多个 Agent 同时在同一个 Git checkout 中修改文件，它们可能覆盖彼此的改动、删除对方正在使用的文件，最后也很难确认一段代码属于哪条实验线。
Hermes 官方建议为并行 Agent 使用独立 Git worktree：每个 Agent 拥有自己的分支和工作目录，完成后再由主线审查、测试和合并。[2]
隔离的重点不只是目录，还包括：
- 独立分支与提交历史；
- 独立临时文件和运行状态；
- 明确的修改范围；
- 不能共享或复制的秘密；
- 完成后的清理和回收。
多 Agent 的隐藏成本
子代理数量增长并不是线性成本。除了模型调用，还包括上下文准备、候选比对、冲突处理、最终复核和迟到结果的吸收。Hermes 官方也提醒，增加递归委派深度会成倍放大并发和费用。[1]
因此，我不再按“岗位”长期养一组拟人化 Agent，而是按任务临时调用不同镜头。大多数普通工作，一个强主模型配合工具就够了；只有独立性、异质能力或并行取证能真正改变结果时，才增加 Agent。
结语
多 Agent 系统最难的不是让很多模型同时说话，而是保持目标、事实、写入权和验收权不分裂。
我目前最认可的形式是：一个主脑长期维护连续性，其他 Agent 按需出现、边界清楚、用完退出。这样既能获得不同视角，又不会把用户变成多个机器人之间的协调员。
