Skip to main content

委派与并行工作

Hermes 可以创建独立的子代理，让它们并行处理任务。每个子代理都有自己的对话、终端会话和工具集，最后只把总结结果返回给你，中间过程不会灌满你的主上下文窗口。

如需完整功能参考，请参阅 子代理委派。

什么情况下适合委派​

委派通常适合这些任务：

  • 需要深度推理的子任务，例如调试、代码审查、研究综合
  • 会产生大量中间数据，不适合塞回主上下文的任务
  • 可以拆成彼此独立的多个并行工作流
  • 你希望某个任务在“干净上下文”里重新分析

不太适合委派的情况通常是：

  • 只需要一次简单工具调用
  • 明显是机械流水线，更适合 execute_code
  • 需要频繁向用户确认的问题
  • 非常小、非常快的局部文件修改

一个实用判断标准是：

  • 能拆开
  • 彼此依赖低
  • 每个子任务本身又值得单独思考

满足这三点时，委派通常就值得考虑。

一个重要前提：子代理什么都不知道​

子代理对你当前对话完全没有记忆。它只能看到你显式写进 goal 和 context 的内容。

所以不要委派这种任务：

Fix the bug we were just talking about.

而应该委派这种任务：

Fix the TypeError in src/auth/login.py where process_request() receives None
from parse_body(). Run pytest tests/auth/ -v after the fix.

文件路径、错误现象、约束条件、测试命令，这些都应该提前写清楚。

模式一：并行研究​

这是最典型的委派场景之一。你可以把多个研究方向同时丢给不同子代理，然后由主代理统一汇总。

例如：

Research these three topics in parallel:
1. Current state of WebAssembly outside the browser
2. RISC-V server chip adoption in 2025
3. Practical quantum computing applications

这类任务适合委派的原因很简单：

  • 每个研究主题彼此独立
  • 每个子任务都需要自己的搜索和筛选
  • 主代理最后只需要拿摘要做整合

适合给这类子代理的工具集通常是：

["web"]

这样能让它们专注调研，而不会顺手跑不必要的终端命令。

模式二：代码审查​

代码审查很适合放到一个全新上下文中做，尤其是安全审查、回归审查、模块级复盘这类容易受先入为主影响的任务。

例如：

Review the authentication module at src/auth/ for security issues.
Check for SQL injection, JWT validation problems, password handling,
and session management. Fix anything you find and run the tests.

更稳的写法通常是补全上下文：

delegate_task(
    goal="Review src/auth/ for security issues and fix any found",
    context="""Project at /home/user/webapp. Python 3.11, Flask, PyJWT, bcrypt.
Auth files: src/auth/login.py, src/auth/jwt.py, src/auth/middleware.py
Test command: pytest tests/auth/ -v
Focus on: SQL injection, JWT validation, password hashing, session management.""",
    toolsets=["terminal", "file"]
)

这里真正关键的不是“把任务丢出去”，而是把上下文写到子代理无需猜测。

模式三：对比多个方案​

当你要比较三种方案、三套技术栈或三种实现路径时，并行委派特别合适。

例如：

Evaluate these approaches for full-text search in our Django app:
1. PostgreSQL tsvector
2. Elasticsearch
3. Meilisearch
Compare setup complexity, query capability, resource cost, and maintenance overhead.

这种任务的优点在于：

  • 每个子代理独立思考，不会互相影响
  • 主代理只负责最后的比较与结论
  • 结果更像“三份独立评估”，而不是一份混在一起的草率总结

模式四：多文件重构​

大型重构也很适合拆成多个子代理，只要它们的写入范围足够清晰。

例如可以按职责拆成：

  • API 层修改
  • SDK 或客户端修改
  • 文档更新

当多个子代理会同时修改代码库时，最重要的是避免它们改同一个文件。只要写入范围是分离的，并行通常就很高效。

一个好习惯是给每个子代理都写清楚：

  • 项目根目录
  • 需要修改的具体文件
  • 新旧格式差异
  • 测试命令

模式五：先机械采集，再委派分析​

有些任务既包含大量机械数据采集，又包含高推理分析。这种情况下，通常不要一开始就委派。

更高效的组合通常是：

  1. 先用 execute_code 做批量采集、过滤、归档
  2. 再把整理后的结果交给子代理做深度分析

原因是：

  • execute_code 很适合串行跑十几次工具调用
  • 子代理更适合拿着已经整理好的数据做一次重推理
  • 这样通常更便宜，也更稳

工具集怎么选​

给子代理的工具集应该尽量小，而不是默认全开。

常见选择方式：

任务类型推荐工具集原因
网络调研["web"]只需要搜索和提取
代码分析 / 修复["terminal", "file"]需要读写文件并运行测试
文档或只读分析["file"]只读取文件即可
混合型开发任务["terminal", "file", "web"]同时需要代码和外部资料

工具集越收敛，子代理越专注，也越不容易出现副作用。

实用写法建议​

目标要可执行​

“帮我看看这个模块”太空泛。

“检查 src/billing/ 是否存在重复扣费风险，并运行 pytest tests/billing/ -v 验证修复结果”就更像一个能执行的任务。

上下文要够具体​

最好显式给出：

  • 文件路径
  • 项目路径
  • 错误信息
  • 技术栈
  • 测试命令
  • 关注重点

委派后仍要验证结果​

子代理返回的是总结，不是绝对真相。如果它声称：

  • bug 已修复
  • 测试已通过
  • 风险已排除

主代理或你自己最好仍做一次验证。

常见限制​

使用委派时，也要记住几条现实限制：

  • 默认并发子代理数量有限
  • 子代理不是无限递归的，不适合层层再委派
  • 子代理没有你的当前对话历史
  • 子代理不适合需要反复和用户澄清的场景

所以它更像“并行工作者”，而不是“另一个带全部记忆的你”。

一个简单原则​

当任务复杂、多维、可拆分，而且每个子任务都值得单独思考时，不要让主代理一个人硬扛。

把它拆开、并行推进，再由主代理做最终整合，通常就是更高效也更稳定的做法。