Hermes Agent 入门（七）：Subagent、Delegate 与多 Agent 协作，让 AI 学会分工
Hermes Agent 入门（七）：Subagent、Delegate 与多 Agent 协作，让 AI 学会分工
前面六篇，我们已经逐步给 Hermes 补齐了：
模型
↓
Tools
↓
Memory
↓
Skills
↓
Gateway
↓
Cron
↓
MCP / Plugin
到了这里，Hermes 已经可以处理相当复杂的任务。
比如：
“检查一下昨晚网站为什么出现 502。”
Hermes 可以自己：
看 Nginx
↓
看 Docker
↓
看数据库
↓
看 CPU
↓
看 IO
↓
看日志
↓
分析结果
但这里会逐渐出现一个问题：
一个 Agent 为什么一定要一件一件检查？
假设一次故障调查需要：
Nginx 日志分析 5 分钟
Docker 状态分析 4 分钟
数据库日志分析 6 分钟
CPU / IO 调查 4 分钟
如果主 Agent 顺序执行：
Nginx
↓
Docker
↓
Database
↓
CPU / IO
理论上可能要十几分钟。
但实际上这四个调查：
互相基本独立。
那么更加合理的方式应该是：
主 Agent
┌───────────┼───────────┐
↓ ↓ ↓
Subagent A Subagent B Subagent C
Nginx Docker Database
Subagent D
CPU / IO
└───────────┬───────────┘
↓
主 Agent
↓
汇总结果
↓
给出结论
这就是这一篇要讲的：
Subagent 与 Delegation
让 Hermes 不再只是：
自己干活
而是学会：
拆任务
+
分工
+
并行
+
汇总
一、什么是 Subagent？
Subagent 可以翻译成：
子 Agent
它本质上是由主 Agent 临时创建出来的另一个 Hermes Agent 实例。
例如：
主 Agent：
帮我调查网站故障。
主 Agent判断：
这个问题比较复杂。
于是创建：
Subagent A：
调查 Nginx
Subagent B：
调查 Docker
Subagent C：
调查数据库
Subagent D：
调查系统性能
每个 Subagent：
拥有自己的上下文
拥有自己的 Terminal Session
可以调用允许的 Tools
可以独立思考
可以独立完成任务
完成后：
Subagent
↓
生成总结
↓
返回主 Agent
主 Agent 再：
综合所有结果
↓
得出最终结论
Hermes 里负责完成这个过程的核心 Tool 叫：
delegate_task
二、Delegate 到底是什么意思？
Delegate 就是：
委派
比如老板收到一个任务：
调查网站为什么慢。
他不会自己：
查网络
查数据库
查前端
查服务器
查日志
全部亲自完成。
更加合理的是：
网络工程师
→ 查网络
DBA
→ 查数据库
后端工程师
→ 查 API
运维
→ 查服务器
最后老板：
收集结果
↓
判断真正原因
↓
做决定
Hermes 的：
delegate_task
干的事情基本就是这样。
三、一个最简单的 Subagent
Hermes 内部可以执行类似：
delegate_task
goal:
调查为什么测试失败
context:
项目位于 /home/user/project
错误发生在 test_api.py
当前报错是 AssertionError
然后：
主 Agent
↓
创建 Child Agent
↓
Child Agent 调查
↓
完成
↓
返回 Summary
不过普通用户通常不用手动写：
delegate_task(...)
你只需要告诉 Hermes：
这个问题比较复杂。
把日志、Docker、数据库和系统资源分别交给不同 Subagent 并行调查，
最后由你统一总结。
Hermes 就可以自行使用 Delegation。
四、Subagent 最重要的特点：它什么都不知道
这一点非常重要。
假设你和主 Agent 已经聊了半个小时：
用户：
我们调查 prod-web-2。
主 Agent：
好的。
用户：
它的数据库在 10.0.0.12。
主 Agent：
知道了。
用户：
昨天 23:00 左右出现过 502。
然后主 Agent 创建一个 Subagent：
调查数据库。
这个 Subagent 并不会自动知道：
prod-web-2
10.0.0.12
昨天 23:00
502
因为 Subagent 是：
全新的 Conversation。
它默认没有主 Agent 的完整聊天历史。
所以一个非常差的 Delegation：
goal:
调查一下刚才那个问题
Subagent 会想：
？？？
什么问题？
五、正确方式：把必要 Context 一起传进去
正确的 Delegation 应该类似：
Goal：
调查 prod-web-2 昨晚 23:00 左右出现 502
是否与 PostgreSQL 有关。
Context：
目标服务器：prod-web-2
数据库地址：
10.0.0.12
异常时间：
22:50 - 23:20
目前已知：
Nginx 返回 502，
Web Container 没有发生重启。
请重点检查：
数据库连接数
慢查询
连接池
锁
资源占用
相关日志
只调查，不修改任何配置。
这样 Subagent 拿到任务后：
不需要重新问主 Agent
就可以直接开始调查。
所以多 Agent 是否好用，很大程度取决于：
主 Agent 会不会把任务描述清楚。
六、Subagent 不能回来问用户
这点也很重要。
主 Agent 可以：
“你说的是哪台服务器？”
然后等待用户回答。
但 Subagent 一般不能直接跑回来：
@用户
数据库 IP 是多少？
它需要自己完成任务。
因此：
Goal
+
Context
必须尽可能完整。
换句话说：
普通 Agent
可以边做边问
Subagent
应该拿到完整任务后独立完成
这也是为什么：
“帮我查一下那个问题”
非常不适合 Delegate。
七、Subagent 最终不会把全部过程塞回主 Agent
假设一个 Subagent：
执行了 30 次 Tool Call
读取 5000 行日志
分析 20 个文件
跑了 15 条命令
如果它把整个过程全部塞回：
Parent Context
主 Agent 的上下文会很快爆炸。
所以 Hermes 的设计更接近：
Child Agent
大量工作
↓
大量 Tool Call
↓
大量临时 Context
↓
最终 Summary
然后主 Agent只收到：
总结后的结果。
例如：
Database Investigation Result
发现：
23:13:41 到 23:18:02
PostgreSQL active connections
从 47 增长到 200。
max_connections = 200。
API 日志同期出现：
connection pool exhausted
数据库 CPU 只有 38%，
不存在 CPU 瓶颈。
初步判断：
502 与应用连接池耗尽高度相关。
未修改任何配置。
而不是收到：
几十页数据库日志。
这对控制 Context 很重要。
八、真正厉害的是 Parallel Batch
单独启动一个 Subagent：
主 Agent
↓
Subagent
↓
结果
并没有特别神奇。
真正有价值的是：
同时多个。
例如：
Incident Investigation
┌────────┬────────┬────────┐
↓ ↓ ↓ ↓
Nginx Docker Database System
↓ ↓ ↓ ↓
Agent A Agent B Agent C Agent D
Hermes 当前支持一次 Delegation 创建多个任务。
默认可以同时运行多名 Subagent。
于是：
Agent A
不需要等：
Agent B
完成。
它们可以：
并行工作。
九、完整案例：调查网站 502
现在做一个真正适合多 Agent 的任务。
用户在 QQ：
昨晚网站为什么出现几次 502？
帮我完整调查一下，
先不要修改服务器。
主 Agent 分析：
502
可能涉及：
Nginx
Upstream
Docker
Database
System Resource
于是创建四个 Subagent。
十、第一个 Agent：Nginx
任务：
调查 prod-web-1 昨晚 22:30 - 23:30
Nginx 502。
重点检查：
access.log
error.log
upstream error
timeout
connection refused
response time
不要修改任何配置。
Agent A 开始：
grep 日志
↓
按时间过滤
↓
统计 502
↓
查看 error.log
↓
整理时间线
最后返回：
Nginx Result
22:57:13
开始出现 upstream timeout
23:02 - 23:06
共出现 42 次 502
错误主要为：
upstream timed out
没有发现：
connection refused
说明后端进程仍然存活，
但响应明显变慢。
十一、第二个 Agent：Docker
Agent B：
调查 prod-web-1 昨晚 22:30 - 23:30
Docker Container 状态。
检查：
是否发生 restart
OOM
healthcheck
CPU
Memory
Container log
不要重启 Container。
结果：
Docker Result
api Container：
没有 Restart。
没有 OOMKilled。
Healthcheck 一直正常。
22:56 开始出现：
database acquire timeout
23:06 后恢复。
Container 本身没有崩溃。
十二、第三个 Agent：Database
Agent C：
调查 PostgreSQL。
异常时间：
22:30 - 23:30。
检查：
连接数
slow query
locks
connection pool
错误日志
CPU
IO
结果：
Database Result
22:56 起连接数快速增长。
23:01：
active connections = 200
达到：
max_connections = 200
期间应用出现：
remaining connection slots are reserved
CPU：
41%
Disk IO：
正常
没有发现锁等待异常。
主要问题是：
连接数达到上限。
十三、第四个 Agent：系统资源
Agent D：
调查 prod-web-1
22:30 - 23:30 的系统资源。
检查：
CPU
RAM
Swap
Load
IO Wait
Disk
Network
返回：
System Result
CPU：
最高 48%
Memory：
最高 63%
Swap：
0
Load：
正常
Disk：
正常
IO Wait：
最高 2.1%
Network：
无明显异常
系统层没有发现资源瓶颈。
十四、最后由主 Agent 汇总
主 Agent 收到：
Nginx Agent
Docker Agent
Database Agent
System Agent
四份 Summary。
然后进行：
Correlation
建立时间线：
22:56
数据库连接开始增长
↓
22:56
API 开始出现 database acquire timeout
↓
22:57
Nginx 出现 upstream timeout
↓
23:01
PostgreSQL 达到 200 Connections
↓
23:02
大量 502
↓
23:06
连接数量下降
↓
502 恢复
最终回答：
昨晚的 502 主要不是 Nginx 自身故障，
也不是服务器 CPU / IO 不够。
故障链路基本可以确定为：
PostgreSQL 连接数达到上限
↓
API 无法及时获得数据库连接
↓
API 响应超时
↓
Nginx upstream timeout
↓
返回 502
其中：
PostgreSQL max_connections = 200，
23:01 左右连接数达到上限。
Docker Container 没有重启，
系统 CPU、内存和 IO 也没有明显异常。
建议下一步重点检查：
1. API Connection Pool 配置
2. 是否存在连接泄漏
3. 为什么 22:56 开始连接数突然增加
4. max_connections 是否合理
当前未修改任何配置。
这就是多 Agent 相比单 Agent 非常典型的优势。
十五、什么任务特别适合 Parallel Delegation？
最典型的是：
互相独立的调查任务。
例如：
服务器故障
├── 系统
├── 网络
├── Docker
└── Database
又比如代码审查：
PR Review
├── Security
├── Performance
├── Logic
└── Tests
或者资料调查：
技术选型
├── 方案 A
├── 方案 B
├── 方案 C
└── Benchmark
这些天然适合：
并行。
十六、并不是 Agent 越多越好
比如一个任务：
修改一个 Nginx 配置。
硬拆：
Agent A
查文档
Agent B
读配置
Agent C
分析语法
Agent D
修改配置
Agent E
测试配置
反而可能：
更慢
+
Token 更多
+
沟通成本更高
因为这些步骤其实存在明显依赖：
读配置
↓
理解
↓
修改
↓
验证
这种任务：
一个 Agent
通常更加合适。
十七、判断是否应该 Delegate 的简单方法
可以先问：
这些任务能不能同时做？
如果：
A 不需要 B 的结果
B 不需要 C 的结果
C 不需要 A 的结果
非常适合：
Parallel Subagent
如果：
B 必须等 A
C 必须等 B
D 必须等 C
那还是：
一个 Agent 顺序执行
更自然。
十八、Subagent 会继承哪些 Tool？
这里涉及一个很重要的权限设计。
目前 Hermes 的 Subagent 会继承：
Parent Agent 已经启用的 Toolset
也就是说：
Parent
本身没有：
PVE Admin
Tool：
Child
也不能自己凭空获得。
所以：
父 Agent 权限
决定了：
子 Agent 能力上限。
模型不能自己说：
“我要给 Subagent 开 root 权限。”
然后权限就突然出现。
十九、但 Subagent 并不会拥有所有特殊能力
为了避免：
无限扩散
Hermes 会限制普通 Leaf Subagent 的一些能力。
普通子 Agent 默认不应该自行：
写长期 Memory
给用户发跨平台消息
创建 Cron
向用户提 Clarify
继续无限 Delegate
它的职责更加明确：
完成分配给自己的任务
↓
返回结果
而不是：
自己变成另一个长期运行的 Hermes。
二十、Memory 和 Subagent 也要分清楚
假设主 Hermes 记得：
prod-web-1 使用 Debian 13。
Docker 项目位于 /opt/docker。
不要想当然认为所有 Subagent 都自动获得：
主 Session 的全部 Memory Context。
Subagent 核心上下文仍然来自：
Goal
+
Context
+
Workspace Context
因此真正重要的信息：
服务器
路径
时间
任务限制
已知情况
仍然应该显式传给 Child。
这样可以避免 Subagent 因为缺少上下文而自行猜测。
二十一、项目目录有一个例外
如果主 Agent 已经处于：
某个 Workspace
Hermes 可以把项目级 Context 提供给子 Agent。
例如项目里存在：
.hermes.md
AGENTS.md
CLAUDE.md
.cursorrules
之类的项目说明。
Subagent 在处理这个项目时，也可以获得对应的项目规范。
例如：
AGENTS.md：
项目使用 pnpm。
禁止修改 migrations。
提交前运行：
pnpm test
这样每个 Subagent 就不需要重新摸索：
这个项目怎么开发。
对于代码任务非常重要。
二十二、每个 Subagent 都有自己的 Terminal Session
主 Agent：
Terminal Session A
Subagent：
Terminal Session B
另一个 Subagent：
Terminal Session C
它们并不是：
所有人共享同一个 Shell。
这个设计对于：
并行执行命令
非常重要。
比如：
Agent A
grep nginx.log
Agent B
docker logs api
Agent C
查询 postgres
Agent D
跑 iostat
可以同时进行。
二十三、但是文件系统默认可能还是同一份
Terminal Session 独立：
不代表磁盘文件独立。
例如三个 Agent 同时修改：
src/app.py
就可能出现：
Agent A
修改第 50 行
Agent B
同时修改第 50 行
Agent C
重新格式化整个文件
最后：
互相覆盖
冲突
因此：
并行调查
非常简单。
但：
并行写代码
就要更加小心。
二十四、这时候就需要 Git Worktree Isolation
Hermes 当前支持给 Delegated Subagent：
独立 Git Worktree。
配置概念上类似：
delegation:
worktree_isolation: true
打开以后：
Main Repo
│
├── Parent
│
├── Worktree A
│ └── Subagent A
│
├── Worktree B
│ └── Subagent B
│
└── Worktree C
└── Subagent C
于是：
Agent A
修改自己的 Branch
Agent B
修改自己的 Branch
Agent C
修改自己的 Branch
不会直接互相覆盖。
二十五、Worktree 特别适合并行代码任务
例如：
实现一个新功能：
1. Backend API
2. Frontend
3. Tests
可以：
Agent A
↓
Backend Worktree
Agent B
↓
Frontend Worktree
Agent C
↓
Test Worktree
完成后：
主 Agent
↓
检查各 Branch
↓
Review
↓
Merge
而不是三个 Agent 同时：
在 main 工作目录乱改。
如果主要用 Hermes 开发大型项目，这个功能非常值得开启。
二十六、Subagent 可以使用不同模型
这是另一个非常实用的功能。
假设：
主 Agent
使用一个：
能力非常强
但是比较贵
的模型。
例如主要负责：
拆任务
架构判断
综合结果
最终决策
而 Child 主要只是：
搜索
看日志
简单分析
收集资料
那么完全没必要：
10 个 Agent 全部跑最贵模型。
可以配置：
model:
default: "main-model"
delegation:
model: "cheaper-model"
provider: "your-provider"
于是：
主 Agent
强模型
↓
负责思考和指挥
Subagents
便宜模型
↓
负责大量执行工作
二十七、这样可以形成“经理 + 工人”模式
例如：
Frontier Model
主 Agent
│
│ 分配任务
┌──────────────┼──────────────┐
↓ ↓ ↓
Cheap Model Cheap Model Cheap Model
Agent A Agent B Agent C
↓ ↓ ↓
调查 搜索 日志分析
└──────────────┼──────────────┘
↓
主 Agent
↓
最终判断
这样往往比：
所有工作
都让最贵模型亲自干
更加经济。
二十八、但 Subagent 模型不要省过头
例如：
主 Agent：
强推理模型
Subagent：
极小模型
结果子 Agent：
日志读错
Tool Call 失败
关键证据没找到
总结错误
最后：
主 Agent
拿到的是：
垃圾输入。
再强也很难得到正确结论。
所以更加合理：
主 Agent
→ 高能力模型
Child
→ 足够可靠的中档模型
而不是：
Child
→ 只追求最便宜。
二十九、怎么看现在有哪些 Subagent？
Hermes 提供：
/agents
还可以使用：
/tasks
查看当前 Agent 和后台任务。
例如：
Background Delegations
Agent A
Nginx investigation
running
Agent B
Database investigation
running
Agent C
Docker investigation
finished
Agent D
System investigation
running
在支持的 CLI / TUI / Desktop 界面中，还可以直接看到：
每个 Agent
运行时间
当前活动
Tool Call
Token
涉及的文件
这对复杂任务非常重要。
否则启动十个 Agent 后：
你根本不知道谁卡住了。
三十、Subagent 甚至可以中途被“纠偏”
假设 Agent B 正在：
疯狂查 Docker
但主 Agent突然发现：
问题可能在 PostgreSQL。
没有必要直接杀掉。
可以给正在运行的 Child 发送：
Steer
类似：
停止继续调查容器启动问题。
重点检查：
22:50 - 23:10
应用日志中的数据库连接错误。
Child 在合适的执行节点收到新指令后：
调整调查方向。
这比：
停止
↓
重新创建 Agent
↓
从头来
更高效。
三十一、当然也可以 Stop 某个 Agent
例如：
Agent A
调查 DNS
但主 Agent 很快确认：
DNS 完全正常。
那么 Agent A 后续继续查：
纯浪费 Token。
这时可以停止它。
而且：
停止 Agent A
不会自动把：
Agent B
Agent C
Agent D
也一起干掉。
所以大规模并行任务仍然可以精确管理。
三十二、Hermes 还有一个非常好用的 /review
除了：
delegate_task
Hermes 还有一个特别适合开发工作的命令：
/review
例如刚刚：
Hermes 修改完代码。
你可以：
/review
Hermes 会创建一个独立 Reviewer Subagent。
它不会只是问原来的 Agent：
“你觉得自己写得对不对？”
而是：
另一个 Agent
↓
重新检查
↓
看代码
↓
看 Diff
↓
运行必要工具
↓
独立 Review
三十三、可以指定 Review 重点
例如：
/review focus on security
让 Reviewer：
主要检查安全问题。
或者：
/review focus on concurrency bugs
检查：
并发问题。
对于 AI 写代码：
Writer Agent
↓
Reviewer Agent
这种结构往往比：
同一个 Agent
↓
自我评价
更可靠。
三十四、可以形成“开发 + Review”模式
例如：
用户：
实现 API Token 管理功能。
主 Agent：
分析需求
↓
修改代码
↓
跑测试
完成以后：
/review focus on security
Reviewer：
检查：
Token 是否明文存储
日志是否泄露 Token
权限验证
Token Scope
SQL Injection
CSRF
错误返回
然后：
Review Result：
发现两个问题：
1. Token 会出现在 debug log
2. delete_token API 缺少 ownership check
这时候再：
主 Agent
↓
修复
这就开始形成一个简单的：
AI Developer
+
AI Reviewer
协作流程。
三十五、Subagent 还可以返回结构化结果
普通 Subagent 最终可能回答：
数据库有问题，
看起来连接数满了……
但如果主 Agent 同时派：
10 个调查 Agent
每个人返回格式完全不同：
Agent A
一大段 Markdown
Agent B
表格
Agent C
三句话
Agent D
JSON
主 Agent 汇总起来会比较麻烦。
Hermes Delegation 当前支持：
Structured Output
可以要求 Child：
按照指定 JSON Schema 返回。
例如统一成：
{
"component": "database",
"status": "abnormal",
"severity": "high",
"summary": "connection pool exhausted",
"evidence": [],
"recommended_actions": []
}
这样：
Nginx Agent
Docker Agent
Database Agent
System Agent
都返回统一格式。
特别适合：
自动化工作流
大量并行任务
程序化汇总
三十六、那 Subagent 能不能再创建 Subagent？
可以，但要区分：
Leaf Agent
和：
Orchestrator Agent
普通结构：
Main
├── Agent A
├── Agent B
├── Agent C
└── Agent D
这叫：
Flat Delegation
也是最简单、最容易控制的模式。
三十七、更高级的是 Nested Delegation
比如任务：
调查整个系统故障。
主 Agent 创建：
Infrastructure Agent
Application Agent
Infrastructure Agent 再拆：
Infrastructure Agent
├── Network Agent
├── Storage Agent
└── PVE Agent
Application Agent：
Application Agent
├── Nginx Agent
├── API Agent
└── Database Agent
最后：
Main
┌───────┴───────┐
Infrastructure Application
┌────┼────┐ ┌────┼────┐
Network Storage PVE Nginx API Database
这就形成：
Agent Tree
三十八、Hermes 默认不会无限递归
如果允许：
Agent
↓
创建 Agent
↓
再创建 Agent
↓
再创建 Agent
没有限制，很容易出现：
Agent Explosion
例如：
1
↓
10
↓
100
↓
1000
Token 直接爆炸。
所以 Hermes 对：
Delegation Depth
有明确控制。
默认更偏向：
Flat
只有显式提高：
max_spawn_depth
以后，Orchestrator Child 才能够继续向下 Delegate。
概念配置例如：
delegation:
max_spawn_depth: 2
这样才允许：
Parent
↓
Orchestrator
↓
Leaf
进一步增加 Depth 时则可以形成更深的树。
三十九、刚开始千万别玩太深
看起来：
10 层 Agent
很高级。
但实际上：
调试困难
Token 消耗大
任务重复
Agent 相互覆盖
结果难汇总
对于绝大多数私人 Agent：
Main
↓
3 - 5 个 Child
已经很好用了。
复杂一点：
Main
↓
2 个 Orchestrator
↓
各自几个 Child
基本就够。
没必要为了：
“多 Agent”
而无限套娃。
四十、最多开多少 Child？
Hermes 当前默认的并发 Child 数量是：
10
可以配置。
例如：
delegation:
max_concurrent_children: 5
对于个人服务器，我反而不推荐开特别高。
因为：
10 个 Agent
意味着可能同时：
10 个模型请求
10 套 Tool Call
10 个 Terminal
大量 Token
如果背后 API：
Rate Limit 很低
很容易直接：
429
四十一、我的建议并发数量
普通 VPS：
2 - 4
比较舒服。
普通开发任务：
3 - 5
通常够用。
大型 Research：
5 - 10
可以考虑。
不要一上来：
50 个 Subagent
除非你非常清楚：
Provider 限速
Token 成本
系统资源
任务设计
会发生什么。
四十二、Subagent 和 execute_code 不要混淆
假设你有：
10000 条 JSON
需要：
过滤
排序
统计
这种任务：
不需要再找一个 AI 思考。
更合理：
execute_code
或者：
Python
处理。
而这种：
阅读 5000 行日志
理解错误原因
关联不同组件
判断真正故障点
才适合：
delegate_task
可以记：
机械计算
↓
Code
需要推理
↓
Subagent
否则你会花：
很多 Token
让 AI 做：
Python 一秒钟能完成的事。
四十三、Subagent 和 /bg 也不同
Hermes 还有：
/bg
例如：
/bg 调查一下最新的 PostgreSQL 优化方案
它会：
创建一个后台 Session
让任务独立执行。
而：
delegate_task
更加偏：
主 Agent
↓
主动拆分自己的任务
↓
Child
↓
结果重新进入主任务
简单理解：
/bg
=
用户自己开一个旁路后台任务
delegate_task
=
Agent 为了完成当前任务主动找帮手
四十四、Subagent 和 Profile 也不是一回事
这一点也很容易误解。
假设你创建：
coder profile
sysadmin profile
personal profile
这些 Profile：
有自己的 Hermes Home
自己的 Memory
自己的配置
自己的长期状态
它们属于：
长期存在的独立 Agent。
而 Subagent：
Main
↓
临时 Spawn
↓
完成一个任务
↓
结束
更加接近：
临时工。
所以：
Profile
=
长期员工
Subagent
=
临时任务 Worker
两个概念完全不同。
四十五、一个错误做法：让多个长期 Agent 共用一个 Profile
例如：
Agent A
Agent B
Agent C
全部使用：
同一个 ~/.hermes
并且都：
写 Memory
很容易产生：
Memory 冲突
状态污染
配置互相影响
真正需要多个长期 Agent：
每个 Agent
↓
独立 Profile
而一次任务里的临时分工：
使用 Subagent。
不要混在一起。
四十六、MCP + Subagent 是非常强的一种组合
上一篇我们已经有：
PVE MCP
Minecraft MCP
NAS MCP
OpenWrt Plugin
现在可以直接：
用户：
检查整个家庭服务器环境。
主 Agent：
Delegate
生成：
Agent A
↓
PVE MCP
Agent B
↓
NAS MCP
Agent C
↓
OpenWrt Tool
Agent D
↓
Minecraft MCP
四个 Agent：
并行检查
最后：
Main
↓
汇总
例如：
家庭基础设施检查完成。
PVE：
正常。
OpenWrt：
WAN 正常。
NAS：
volume1 86%，
需要关注。
Minecraft：
TPS 18.2，
存在轻微性能问题。
整体没有严重故障。
这已经非常接近：
AI NOC
的雏形。
四十七、Cron + Subagent 还能更进一步
上一篇做过：
每天 09:00
生成服务器日报。
以前：
Cron
↓
一个 Agent
↓
检查所有东西
现在可以：
Cron
↓
Main Agent
├── PVE Agent
├── NAS Agent
├── Docker Agent
├── Network Agent
└── Backup Agent
↓
Main
↓
Daily Report
↓
QQ / 飞书
这样每天自动获得：
基础设施日报。
四十八、但是自动化 Delegation 一定要限制成本
例如：
每 10 分钟
↓
10 个 Subagent
一天：
144 次任务
×
10 Child
=
1440 个 Agent Run
Token 成本可能非常夸张。
所以比较合理：
高频检查
→ Script
异常发现
→ Agent
复杂调查
→ Subagent
例如：
每 5 分钟
HTTP Script
↓
发现 502
↓
才启动 Hermes
↓
Hermes Delegate
├── Nginx
├── Docker
└── Database
这样：
平时几乎不花 Token
真正异常时：
才启动多 Agent 调查。
这比：
24 小时不停让 10 个 AI 检查
合理得多。
四十九、多 Agent 最容易出现的一个问题：重复调查
例如主 Agent 一句话：
调查 502。
然后：
Agent A
查 Nginx + Docker + DB
Agent B
查 Docker + DB + System
Agent C
查 Nginx + DB
三个人：
大量重复。
这就是一个非常差的任务拆分。
正确做法：
Agent A
只负责 Nginx
Agent B
只负责 Docker
Agent C
只负责 Database
Agent D
只负责 Host Resource
每个任务：
边界明确。
最后主 Agent：
负责跨域关联。
五十、另一个问题：让所有 Agent 都能修改东西
例如：
Agent A
修改 Nginx
Agent B
修改 Docker
Agent C
修改数据库
Agent D
修改系统参数
同时运行。
最后可能出现：
谁改了什么都不知道。
故障调查阶段，我强烈建议：
Subagent
=
Read Only
即：
调查
分析
提出方案
不：
重启
删除
改配置
更新软件
最终：
Main Agent
↓
汇总方案
↓
用户确认
↓
再执行修改
五十一、推荐的运维 Agent 权限模型
可以设计：
Main Agent
有限管理权限
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Investigator Investigator Investigator
Read Only Read Only Read Only
↓ ↓ ↓
Nginx Database Docker
└──────────────┼──────────────┘
↓
Main
↓
提出修复方案
↓
人工确认
↓
修改
这种结构会安全很多。
五十二、代码开发也适合同样思路
例如：
实现用户注册功能。
可以：
Main
│
├── Agent A
│ 分析现有 Auth 架构
│
├── Agent B
│ 调查数据库 Schema
│
└── Agent C
查现有测试
这三个：
先只调查。
然后主 Agent：
根据调查结果
↓
制定方案
↓
实现
完成以后：
/review
再找一个 Reviewer：
独立审查。
这种：
Explore
↓
Implement
↓
Review
流程很适合 AI Coding。
五十三、一个更完整的 Coding Workflow
最终可以形成：
用户：
实现 OAuth 登录。
↓
Main Agent
先 Delegate：
Agent A
调查 Auth 架构
Agent B
调查数据库
Agent C
调查 Frontend
Agent D
调查 Tests
↓
Main
汇总
↓
制定 Implementation Plan
↓
Worktree Agents
Agent A
实现 Backend
Agent B
实现 Frontend
Agent C
实现 Tests
↓
Main
Merge
↓
/review
↓
Reviewer Agent
↓
修复问题
↓
最终测试
这已经是一个比较完整的：
AI Software Team
雏形。
五十四、怎么配置 Delegation？
基础配置可以放在：
~/.hermes/config.yaml
例如：
delegation:
max_iterations: 250
max_concurrent_children: 4
model: "your-subagent-model"
provider: "your-provider"
max_spawn_depth: 1
worktree_isolation: false
对于第一次使用，我建议：
max_concurrent_children:
3 - 4
max_spawn_depth:
1
worktree_isolation:
false
先玩：
Flat Delegation
不要一开始就套很多层。
五十五、如果主要写代码
可以考虑：
delegation:
max_concurrent_children: 4
max_spawn_depth: 1
worktree_isolation: true
这样：
不同 Subagent
编辑代码时更加不容易互相冲突。
当然，最后还是应该：
Review Diff
Run Tests
人工检查关键代码
而不是：
Child 说完成
↓
直接生产部署。
五十六、我的实际推荐
对于服务器运维：
Main Agent
+
3 个 Readonly Subagent
就已经非常够用。
例如：
System
Docker
Application
如果有数据库：
再加 Database
即可。
对于 Coding：
Main
+
Explorer
+
Implementation Worker
+
Reviewer
通常也够。
不要为了做出：
“AI 公司”
一下创建：
CEO Agent
CTO Agent
Manager Agent
Senior Agent
Junior Agent
Intern Agent
十几层角色。
Agent 名字再高级：
也不会凭空增加智力。
真正重要的是：
任务边界清晰
Context 完整
Tool 合适
权限合理
最终结果有人统一判断
五十七、整个 Hermes 架构现在已经逐渐完整
回头看前七篇：
Hermes
│
┌────────┴────────┐
↓ ↓
Memory Skills
│ │
└────────┬────────┘
↓
Main Agent
│
┌────────────┼────────────┐
↓ ↓ ↓
Subagent Subagent Subagent
│ │ │
└────────────┼────────────┘
↓
Tools
┌────────────┼────────────┐
↓ ↓ ↓
Built-in Plugin MCP
│
┌────────┼────────┐
↓ ↓ ↓
PVE NAS Minecraft
↑
Cron
↑
Gateway
↑
QQ / 飞书
Hermes 已经不再只是：
一个 AI。
而开始接近：
一个 Agent Runtime。
五十八、Subagent 真正解决的不是“多”
而是：
并行性
+
上下文隔离
+
职责划分
这是这一篇最值得记住的地方。
很多任务：
并不是模型不够聪明。
而是：
一个 Context
里面塞太多东西。
比如同时：
分析 Nginx
分析数据库
分析代码
分析系统
很容易：
上下文越来越乱。
拆成：
四个专注 Agent
每个人只看自己的问题：
反而更加清晰。
最后再让能力更强的 Main Agent：
做最终关联。
这就是多 Agent 最大的实际价值之一。
五十九、但最终责任还是应该在 Main Agent
Subagent 返回：
“我认为数据库有问题。”
并不代表：
事实一定如此。
Main Agent 应该：
比较证据
寻找矛盾
检查时间线
判断不同 Agent 的结论是否冲突
例如：
DB Agent：
数据库连接满了。
System Agent：
数据库服务器 CPU 很低。
这两个并不矛盾。
Main Agent 应该理解：
连接上限
≠
CPU 瓶颈
最终形成正确因果关系。
所以：
Child
=
调查员
Main
=
分析员 / 决策者
比：
大家各说各话
有效得多。
六十、最后总结
Hermes 的 Delegation 可以简单理解成：
复杂任务
↓
Main Agent
↓
拆解
├── Subtask A
├── Subtask B
├── Subtask C
└── Subtask D
↓
并行执行
↓
Summary
↓
Main Agent
↓
关联结果
↓
最终答案
几个最重要的原则：
Subagent 默认不知道主聊天历史
↓
所以 Context 一定要完整
能够并行的任务
↓
才值得并行
机械处理
↓
用代码
需要推理
↓
用 Subagent
调查阶段
↓
尽量 Read Only
多个 Agent 写代码
↓
使用 Worktree Isolation
便宜模型可以跑 Child
↓
但不能便宜到不可靠
Agent 数量
↓
不是越多越好
真正优秀的多 Agent 系统并不是：
同时运行 50 个 AI。
而是：
该一个人完成的任务
一个人完成
该并行的任务
并行
该交给脚本的工作
交给脚本
最后由一个 Agent
统一做判断。
这才是真正有用的：
Agent Orchestration。
下一篇
现在 Hermes 已经拥有：
模型
Memory
Skills
Gateway
Cron
MCP
Plugin
Subagent
能力已经相当强。
而能力越强：
安全问题越重要。
尤其到了现在：
QQ
↓
Hermes
↓
Subagent
↓
MCP
↓
服务器
任何一层权限设计不合理，都可能产生比较大的风险。
所以下一篇就很适合专门解决：
《Hermes Agent 入门（八）：权限、安全与隔离，怎样放心让 AI 操作服务器》
会完整讨论：
为什么不要让 Hermes 直接使用 root？
独立 Linux User 怎么设计？
sudo 白名单怎么写？
Terminal Local / Docker / SSH 应该怎么选？
Gateway 用户白名单怎么做？
QQ Bot 被盗会发生什么？
MCP 为什么应该分 Readonly / Admin？
API Token 怎么做最小权限？
Subagent 应该拥有哪些 Tool？
Cron 为什么应该比交互 Session 权限更低？
Prompt Injection 能不能让 AI 读取服务器密钥？
怎么限制：
~/.ssh
.env
API Key
数据库密码
Docker Sandbox 到底能隔离什么？
Agent 能不能管理生产服务器？
哪些操作应该强制人工确认？
怎么设计：
Read
↓
Diagnose
↓
Propose
↓
Approve
↓
Execute
这样的安全工作流？
最后可以给出一套完整的推荐架构：
Internet
↓
QQ / 飞书
↓
User Allowlist
↓
Hermes Gateway
↓
Restricted Agent
↓
┌──────────────┼──────────────┐
↓ ↓ ↓
Readonly MCP Docker Sandbox Web Tools
↓
Admin Operation
↓
Human Approval
↓
Restricted sudo / API
↓
Production
完成第八篇以后，整个系列就不只是：
“怎么把 Hermes 玩起来”
而会进一步进入：
“怎么把 Hermes 真正长期、安全地用起来”。
- 点赞
- 收藏
- 关注作者
评论（0）