深入理解 Hermes 多 Agent 协作：架构、工具集与生产实践

1.1 进程级隔离，不是协程#

很多人第一次接触多 Agent，会以为它只是开了几个 asyncio 协程。完全不是。

每个子代理（subagent）是一个完全独立的进程，拥有：

• 独立的 Python 解释器进程：不共享内存、不共享全局变量
• 独立的终端会话：workdir、环境变量、进程状态完全隔离
• 独立的对话上下文：子代理 A 不知道子代理 B 的存在，它们各自和自己的 LLM 对话
• 独立的工具调用链路：每个子代理有自己注册的工具集，互不干扰

这意味着什么？子代理 A 在执行 terminal 工具时 rm -rf /tmp/data，完全不会影响子代理 B 正在读取 /tmp/data/other.txt。它们就像两台独立的机器。

1.2 数据流：中间结果不回流#

这是最关键的架构决策。子代理执行过程中产生的所有中间结果都不会回到主代理的上下文窗口：

1
子代理A:
2
  ├── 搜索 Google → 打开 10 个网页 → 读取全文 → 提取关键信息
3
  ├── 执行 shell → 运行 grep/awk 处理 → 过滤出 5 条关键记录
4
  └── 最终只返回：一份 200 字的摘要

子代理 A 读了 10 个网页、执行了 20 个命令——这些过程的输出全部不会塞回主代理的上下文。只有最后那份 200 字的摘要回来。

这解决了一个核心问题：token 爆炸。

假设你派一个子代理去分析一个 500 行的 Python 文件：

• 不用子代理：文件全文进入主对话上下文 → 500 行 × 平均 30 字符 ≈ 15,000 token
• 用子代理：文件只在子代理的上下文里 → 主对话只收到 “这个文件用了 FastAPI，包含 3 个路由，建议添加异常处理” → 约 50 token

300 倍的 token 节省。

1.3 通信协议：JSON-RPC over 进程管道#

主代理和子代理之间通过 JSON-RPC 协议通信：

1. 主代理调用 delegate_task → 序列化任务参数（goal、context、toolsets）
2. 启动新的 Hermes Agent 进程 → 通过 stdin/stdout 传递 JSON-RPC 消息
3. 子代理执行完成后 → 将结果（status、summary、exit_reason）序列化为 JSON
4. 主代理反序列化结果 → 合并到当前对话

这个设计的好处是：

• 语言无关：理论上子代理可以用任何语言实现
• 易于调试：可以 dump 出完整的 JSON-RPC 消息流
• 天然隔离：进程崩溃不影响主代理

2.1 工具集分类#

我把它们分成四大类：

🔧 基础设施类

这两个是最基础的工具集，几乎所有子代理都需要至少其中一个。

🌐 网络与信息类

📝 生产力类

🤖 元能力类

2.2 工具集组合模式#

在实践中，有一些经过验证的工具集组合模式：

模式 A：研究员（Researcher）

1
toolsets: [web, search, browser]
2
# 适合：资料搜集、竞品分析、技术调研

模式 B：工程师（Engineer）

1
toolsets: [terminal, file, web]
2
# 适合：代码实现、Bug 修复、项目构建

模式 C：分析师（Analyst）

1
toolsets: [terminal, file, session_search]
2
# 适合：代码审计、历史分析、模式识别

模式 D：全栈（Full-Stack）

1
toolsets: [terminal, file, web, browser, vision]
2
# 适合：端到端任务（调研→实现→验证）

重要规则：子代理不能调用 delegate_task（防止无限递归）。这是硬性限制。

3.1 全局配置#

在 ~/.hermes/config.yaml 中：

1
delegation:
2
  max_iterations: 50        # 每个子代理的最大工具调用轮数
3
  default_toolsets:          # 默认工具集（不指定时继承）
4
    - terminal
5
    - file
6
    - web
7
  max_concurrent_children: 3 # 默认并发上限（当前硬编码为 3）

3.2 max_iterations 怎么选？#

经验法则：如果一个子代理在 30 轮内没完成，通常不是时间不够，而是任务定义太模糊。与其增加 max_iterations，不如重写 goal，让它更具体。

3.3 context 的用法：传多少合适？#

context 字段是给子代理的背景信息。这里有一个微妙的平衡：

传太少：子代理不知道项目结构、文件路径、约束条件，会花大量轮次去”探索” 传太多：浪费 token，而且可能引入不必要的信息干扰

最佳实践：

1
context: |
2
  博客仓库: /root/workspace/myboke (Astro 框架)
3
  文章目录: src/content/posts/
4
  图片目录: src/content/posts/images/ (.avif 格式)
5
  已有文章 60+ 篇，分类: AI工具/Vue/工程化/浏览器
6
  部署路径: /www/wwwroot/boke.hackerdream.xyz/
7
  服务器: 4G Ubuntu, 需要 Swap 防 OOM

原则：传”如果不告诉它，它就会做错或浪费时间”的信息。

3.4 并发控制：3 个同时跑#

当前默认最大并发是 3 个子代理。这是经过验证的甜蜜点：

• 1 个：太慢，失去并行优势
• 2 个：不错，但复杂任务还是不够
• 3 个：最佳平衡——速度 vs token 消耗 vs 结果质量
• >3 个：边际效益递减，token 成本线性增长

4.1 常见错误类型#

错误 1：超时

1
exit_reason: "timeout"

子代理在 max_iterations 内没完成。通常原因：

• 任务定义太模糊（“帮我优化整个项目”）
• 子代理在某个循环里出不来（如搜索太多网页）

解法：重写 goal，加上明确的退出条件：

1
goal: |
2
  只搜索前 5 个搜索结果。
3
  如果搜不到相关资料，返回"未找到"并停止。
4
  不要尝试访问所有搜索结果的页面。

错误 2：工具权限不足

1
error: "Tool 'browser' is not available in this subagent"

子代理试图调用不在 toolsets 中的工具。

解法：检查 toolsets 参数，确保包含了需要的工具。

错误 3：进程崩溃

1
exit_reason: "crashed"

子代理进程异常退出（通常是 OOM 或未处理的 Python 异常）。

解法：

• 对于 OOM：检查子代理是否在读取超大文件
• 对于异常：通常会在 summary 中看到错误栈

错误 4：被中断

1
exit_reason: "interrupted"

主代理被用户停止，连带终止了所有子代理。

4.2 容错模式：降级处理#

在生产环境中，你应该设计”即使某个子代理失败，整体任务仍然能完成”的流程：

1
# 伪代码示例
2
results = delegate_task(tasks=[A, B, C])
3

4
# A 和 B 成功，C 失败
5
if C.failed:
6
    # 降级：用已有知识替代 C 的输出
7
    c_fallback = "根据已有知识，这个分类应该是..."
8
    merge(A, B, c_fallback)
9
else:
10
    merge(A, B, C)

实际案例：在写博客时，子代理 C（搜索历史会话）超时了。但由于子代理 B 已经检查了仓库中已有的文章，我仍然可以判断”这篇文章和已有内容角度不同”，直接跳过 C 继续写作。

5.1 实测数据#

以一个完整的”搜资料+写博客”任务为例：

注意：B 子代理的 492K input token 是因为它读取了大量文件内容。在实际生产中，你应该：

1. 限制子代理读取的文件数量和大小
2. 使用 search_files 而非 read_file 全量读取
3. 让子代理只读取必要的文件

5.2 省钱技巧#

1. 精简 context：不要传整个项目的文件树，只传关键路径
2. 限制搜索范围：明确告诉子代理”只搜前 N 个结果”
3. 减少文件读取：用 search_files 的 limit 参数
4. 合理设置 max_iterations：不要盲目给 50，够用就行
5. 利用子代理 A 做预处理：让第一个子代理过滤掉不相关的内容，减少后续处理量

6.1 指定不同的模型#

子代理可以使用和主代理不同的模型：

1
delegate_task:
2
  tasks:
3
    - goal: "搜索最新资料"
4
      toolsets: [web, search]
5
      model:
6
        provider: "openrouter"
7
        model: "anthropic/claude-sonnet-4"  # 用更快的模型

策略：

• 研究型任务：用更强的模型（opus/sonnet），保证质量
• 简单操作：用更快的模型（haiku），省钱省时间
• 代码生成：用 code 专用模型

6.2 跨平台 ACP 子代理#

你可以让子代理使用不同的 ACP（Agent Communication Protocol）后端：

1
delegate_task:
2
  acp_command: "claude"  # 子代理用 Claude Code 而非 Hermes Agent
3
  tasks:
4
    - goal: "重构这段代码"
5
      toolsets: [terminal, file]

这让 Hermes 可以跨框架调度——Hermes 作为调度者，子代理可以是 Claude Code、OpenCode、或任何其他 ACP 兼容的 Agent。