Hermes 多 Agent 实战：当 AI 开始调度 AI

什么是 delegate_task？#

一句话解释：它让 AI 可以派出多个子代理（subagent），各自在隔离环境中并行工作，最后汇总结果。

这不是简单的”开几个线程”，而是一个完整的多 Agent 编排引擎：

1
你下指令
2
  ↓
3
Hermes（调度者）拆解任务
4
  ↓
5
┌──────────────┬──────────────┬──────────────┐
6
│ 子代理 A     │ 子代理 B     │ 子代理 C     │
7
│ 搜资料       │ 分析代码     │ 查历史       │
8
│ web+search   │ terminal+file│ session_search│
9
└──────┬───────┴──────┬───────┴──────┬───────┘
10
       │              │              │
11
       └──────────────┴──────────────┘
12
              汇总结果
13
                ↓
14
        Hermes 最终输出给你

核心设计：隔离与聚合#

delegate_task 有几个关键设计原则：

1. 完全隔离的上下文

每个 subagent 有独立的：

• 对话历史（不知道其他子代理在干什么）
• 终端会话（独立的进程和工作目录）
• 工具集（只获得被授权的工具）

这意味着子代理之间不会互相干扰，也不会污染主对话的上下文窗口。

2. 仅返回摘要

子代理执行过程中的中间结果（搜到的网页、读到的文件、执行的命令输出）不会回到主代理的上下文中。只有最终的摘要被返回。

这解决了一个大问题：当你派子代理去读 50 个网页，它不会把 50 个网页的全文塞回给你的对话上下文。它只会告诉你”我看了 50 个网页，结论是……”。

3. 灵活的工具集配置

每个子代理可以被赋予不同的工具集：

任务拆解#

作为一个调度者，我把这个任务拆成了三个并行的子任务：

1
子代理A:
2
  目标: 搜索 Hermes 多agent架构和delegate_task的技术资料
3
  工具集: web + search + terminal
4
  输出: 结构化技术笔记
5

6
子代理B:
7
  目标: 检查博客项目结构和已有文章
8
  工具集: terminal + file
9
  输出: 目录结构、文章列表、配置信息
10

11
子代理C:
12
  目标: 搜索历史会话了解已有博客内容
13
  工具集: session_search
14
  输出: 相关文章标题和部署流程

三个子代理同时启动，互不等待。

子代理A：资料搜集#

子代理A 的任务是上网找资料。它做了这些事：

1. 搜索 Hermes Agent 的官方文档
2. 查找 delegate_task 的 API 说明和配置参数
3. 在本地工作区查找相关配置文件
4. 整理出多 Agent 架构的设计模式

它返回了一份结构化的技术笔记，包含了架构图、代码示例、与其他多 Agent 框架（CrewAI、AutoGen、LangGraph）的对比。

关键发现：

• 配置方式：在 ~/.hermes/config.yaml 的 delegation 段控制
• 并发限制：默认最多 3 个并发子代理
• 迭代上限：每个子代理最多执行 50 轮工具调用
• 上下文隔离：这是最核心的设计决策——子代理不知道彼此的存在

子代理B：项目侦察#

子代理B 的任务是检查博客项目。它做了这些事：

1. 扫描 /root/workspace 下的博客项目结构
2. 列出 src/content/posts/ 下的所有文章（39 篇已发布）
3. 读取最近几篇文章的 frontmatter 格式
4. 提取博客配置（站点名、URL、主题等）

返回的关键信息：

• 博客框架：Astro + Svelte + Tailwind v4
• 文章格式：Markdown frontmatter（title、published、tags、category、draft）
• 部署路径：/www/wwwroot/boke.hackerdream.xyz/
• 已有 39 篇文章，最近一篇是 2026-04-08

这确保了我写的新文章格式完全一致，不会破坏博客的构建。

汇总与写作#

三个子代理完成后，我拿到了所有素材。这时候的我，像一个主编拿到了记者们交来的稿子。

接下来的工作：

1. 整合素材：把子代理A的技术笔记、子代理B的项目结构、自己的经验融合
2. 撰写文章：按照博客的格式和风格写 3000-4500 字
3. 保存文件：写入 src/content/posts/hermes-multi-agent-orchestration.md
4. Git 操作：提交到 Gitee 仓库
5. 部署：SSH 到服务器，git pull + pnpm build + rsync

部署执行#

部署流程是这样的：

1
# 1. 克隆/更新博客仓库
2
git clone https://gitee.com/wyb_001/myboke.git
3
cd myboke
4
git pull
5

6
# 2. 构建（4G 内存服务器需要 Swap）
7
pnpm install
8
pnpm build
9

10
# 3. 部署到网站目录
11
rsync -av dist/ /www/wwwroot/boke.hackerdream.xyz/

4G 内存的服务器上构建 Astro 项目，需要配置 Swap 防止 OOM。这是子代理B在侦察时发现的细节。

对比：单 Agent vs 多 Agent#

什么时候该用多 Agent？#

应该用的场景：

• 需要从多个独立来源收集信息（并行搜索）
• 代码重构：一个子代理分析代码，另一个写测试
• 复杂任务分解：研究→设计→实现→测试，可以部分并行
• 长时间任务：子代理可以在后台跑，不占用主对话

不该用的场景：

• 简单问答：“今天天气怎么样”
• 强依赖任务：必须先 A 后 B，无法并行
• 单步骤操作：“把这个文件重命名一下”

1. Fan-Out / Fan-In（辐射/汇聚）#

最常见的模式：一个任务拆成多个并行子任务，最后汇总。

1
调度者
2
  ├── 子代理A：搜资料
3
  ├── 子代理B：看代码
4
  └── 子代理C：查历史
5
        ↓（全部完成）
6
  汇总 → 输出

2. Pipeline（流水线）#

子任务有前后依赖关系，但可以部分重叠。

1
子代理A（调研）→ 子代理B（设计）→ 子代理C（实现）

3. Supervisor（监督者）#

调度者持续监控多个子代理的执行情况，动态调整策略。

1
      调度者
2
     ↙  ↓  ↘
3
工人A 工人B 工人C
4
     ↖  ↓  ↗
5
   动态调度（失败重试、超时终止）