一个 delegate_task 函数,5种协作模式,让你的 Hermes Agent 从「单兵作战」升级为「AI团队指挥官」——每条模式都附可复制的配置代码。
为什么 delegate_task 是 Hermes Agent 最被低估的功能
2026年6月,大多数 Hermes Agent 用户的使用方式还停留在:打开终端 → 输入指令 → 等回复 → 继续输入。本质上还是「一对一聊天」。
但 Hermes Agent 真正强大的地方在于 delegate_task——它能让你以主Agent的身份,派生子Agent去独立完成子任务,然后汇总结果。
这就像你从「一个人干活」变成了「团队Leader」:你定义目标、分配任务、审核结果,而每个子Agent各自负责自己的专业领域。
实测数据:用 delegate_task 构建的内容创作流水线,从选题到发文全自动,每天稳定产出1-2篇高质量文章,人工干预率低于10%。
核心概念:delegate_task 的三个关键参数
在深入5种模式之前,先理解 delegate_task 的核心参数:
delegate_task(
goal="作为[角色],请完成以下任务:\n1. ...\n2. ...\n输出文件:~/path/to/output.md",
context="背景信息:...\n参考文件:~/path/to/input.md",
toolsets=["web", "terminal", "file"], # 授予子Agent的工具集
role="leaf" # leaf=叶子节点,不继续委派
)
| 参数 | 作用 | 实战建议 |
|---|---|---|
goal |
任务目标,越具体越好 | 写明角色、步骤、输出路径 |
context |
背景信息和输入文件路径 | 把上游输出文件路径写进去 |
toolsets |
授予的工具权限 | 最小权限原则:只给需要的 |
role |
leaf=执行节点,不递归委派 |
叶子任务用leaf,协调器不设 |
模式一:顺序流水线(Sequential Pipeline)
适合场景:有明确上下游依赖的任务链,如「调研→大纲→写作→审核→发布」。
架构图:
主Agent(协调)
│
├─→ researcher(调研)→ 01-research.md
│ ↓
├─→ outliner(大纲) ← 读取调研结果 → 01-outline.md
│ ↓
├─→ writer(写作) ← 读取大纲 → 01-article.md
│ ↓
├─→ reviewer(审核) ← 读取文章 → 01-review.md
│ ↓
└─→ publisher(发布) ← 读取终稿 → 草稿箱
代码实现:
# 步骤1:启动调研Agent
delegate_task(
goal="""作为AI创业内参的调研Agent,请完成以下任务:
1. 搜索2026年6月AI Agent工具领域的最新动态
2. 筛选出3个最有选题价值的新闻事件
3. 对每个选题:说明核心观点、目标读者、预估热度、素材来源URL
输出文件:~/ai-neican/research/outputs/01-research.md""",
context="目标读者:AI创业者/独立开发者。重点关注:Hermes Agent、OpenClaw、Claude Code 等工具的更新。",
toolsets=["web", "terminal", "file"],
role="leaf"
)
# 步骤2:启动大纲Agent(等步骤1完成后)
delegate_task(
goal="""作为AI创业内参的大纲Agent,请完成以下任务:
1. 阅读 ~/ai-neican/research/outputs/01-research.md
2. 选取最佳选题
3. 输出结构化大纲(引言钩子、5章要点、字数分配、结尾CTA)
输出文件:~/ai-neican/outline/outputs/01-outline.md""",
context="请先读取调研报告,再制定大纲。",
toolsets=["file", "terminal"],
role="leaf"
)
# 步骤3-5:依次执行 writer → reviewer → publisher
# (代码结构相同,goal 和 context 替换即可)
关键技巧:
- 每个步骤完成后检查输出文件是否存在且内容完整(字数>阈值)
- 如果某步骤失败,从失败点重试,不用从头开始
- 文件路径用绝对路径(~展开),避免子Agent找不到文件
模式二:并行扇出(Parallel Fan-out)
适合场景:多个独立任务可以同时执行,如「同时搜索中英文信息源」「同时对多个竞品做分析」。
架构图:
主Agent(协调)
│
├─→ Agent A:搜索中文社区(知乎/CSDN/公众号)
├─→ Agent B:搜索英文社区(HN/Reddit/dev.to) ← 三者并行
├─→ Agent C:搜索GitHub(Hermes/OpenClaw releases)
│
└─→ 汇总Agent:合并三个来源的结果 → 去重 → 排序
代码实现:
# 并行启动三个搜索Agent
delegate_task(
goal="搜索中文AI社区(知乎、CSDN、腾讯云)关于Hermes Agent的最新教程和讨论,输出5条最有价值的信息,每条含标题+URL+核心观点。输出到 ~/search-cn.md",
toolsets=["web"],
role="leaf"
)
delegate_task(
goal="搜索英文社区(Hacker News、Reddit r/ClaudeAI、dev.to)关于Hermes Agent的最新讨论,输出5条最有价值的信息。输出到 ~/search-en.md",
toolsets=["web"],
role="leaf"
)
delegate_task(
goal="检查GitHub上NousResearch/hermes-agent和openclaw/openclaw的最新release和commit,输出版本号+更新内容摘要。输出到 ~/search-gh.md",
toolsets=["web"],
role="leaf"
)
# 等待三者完成,然后汇总
delegate_task(
goal="读取 ~/search-cn.md、~/search-en.md、~/search-gH.md,合并去重,按重要性排序,输出最终热点报告到 ~/hotspot-final.md",
toolsets=["file"],
role="leaf"
)
关键技巧:
- Hermes Agent 支持同时运行多个 delegate_task(非阻塞调用)
- 并行数量建议控制在3-5个,太多会导致token消耗激增
- 汇总Agent的prompt要明确「去重规则」和「排序标准」
模式三:协调者-专家(Coordinator-Worker)
适合场景:复杂项目需要不同专业领域的Agent协作,如「一个全栈项目需要前端Agent+后端Agent+测试Agent」。
架构图:
主Agent(协调者)
│
├─→ 前端Agent:React组件 + 样式(toolsets: file, terminal)
├─→ 后端Agent:API路由 + 数据库(toolsets: file, terminal)
├─→ 测试Agent:单元测试 + E2E(toolsets: file, terminal)
└─→ 集成Agent:合并代码 + 解决冲突(toolsets: file, terminal)
代码实现:
# 协调者定义项目规范
project_spec = """
技术栈:React 18 + TypeScript + FastAPI + PostgreSQL
代码规范:ESLint airbnb + Black formatter
目录结构:
/frontend - React应用
/backend - FastAPI应用
/tests - 测试文件
"""
# 分配给各专家
delegate_task(
goal=f"""作为前端专家Agent,请按以下规范开发登录页面:
{project_spec}
具体任务:
1. 创建 React 登录组件(邮箱+密码+提交按钮)
2. 添加表单验证(邮箱格式、密码≥8位)
3. 添加加载状态和错误提示
输出到:/project/frontend/Login.tsx""",
toolsets=["file", "terminal"],
role="leaf"
)
delegate_task(
goal=f"""作为后端专家Agent,请按以下规范开发登录API:
{project_spec}
具体任务:
1. 创建 FastAPI login 端点(POST /api/auth/login)
2. 实现JWT token生成和验证
3. 数据库查询(PostgreSQL users表)
输出到:/project/backend/auth.py""",
toolsets=["file", "terminal"],
role="leaf"
)
关键技巧:
- 协调者的 project_spec 是核心——规范越详细,各Agent产出越一致
- 建议在 spec 里写清楚「接口契约」:API端点格式、数据类型、错误码
- 集成Agent负责检查接口是否对齐(前端调用的API是否和后端暴露的一致)
模式四:辩论-综合(Debate-Synthesis)
适合场景:需要多角度思考的决策类任务,如「选型评估」「风险分析」「方案对比」。
架构图:
主Agent(裁判)
│
├─→ Agent A:正方——论证「方案X的优势」
├─→ Agent B:反方——论证「方案X的风险和劣势」
│
└─→ Agent C:综合双方论点,输出决策建议
代码实现:
# 辩论主题
topic = "一人公司应该选择 Hermes Agent 还是 OpenClaw 作为主力AI Agent平台?"
# 正方:Hermes优势
delegate_task(
goal=f"""辩论话题:{topic}
你的立场:**支持 Hermes Agent**
请从以下角度论证:
1. 多Agent协作能力(delegate_task生态)
2. Skill系统灵活性(自定义Skill的难易度)
3. 社区活跃度和更新频率
4. 成本效益分析
输出3个核心论点,每个带具体数据和案例。输出到 ~/debate-pro.md""",
toolsets=["web", "file"],
role="leaf"
)
# 反方:Hermes劣势/OpenClaw优势
delegate_task(
goal=f"""辩论话题:{topic}
你的立场:**支持 OpenClaw(反对 Hermes Agent)**
请从以下角度论证:
1. OpenClaw的部署和运维便利性
2. 社区插件生态(ClawHub)
3. 企业级功能支持
4. Hermes的不足和风险
输出3个核心论点,每个带具体数据和案例。输出到 ~/debate-con.md""",
toolsets=["web", "file"],
role="leaf"
)
# 综合裁决
delegate_task(
goal="""读取 ~/debate-pro.md 和 ~/debate-con.md,综合双方论点:
1. 列出双方论点的真实性验证结果
2. 给出最终推荐和适用场景
3. 标注不确定的部分(需要人工判断)
输出到 ~/debate-verdict.md""",
toolsets=["file"],
role="leaf"
)
关键技巧:
- 辩论Agent的立场必须明确且对立,prompt里要写入「你的立场是XXX」
- 综合Agent需要做事实核查——正方和反方都可能引用不准确的数据
- 最终输出要标注「不确定项」,这是人工介入的价值点
模式五:层级树(Hierarchical Tree)
适合场景:大规模复杂任务,需要多层委派,如「AI内容工厂的全流程自动化」。
架构图:
主Agent(总指挥)
│
├─→ 内容总监Agent(role不设leaf,可继续委派)
│ │
│ ├─→ 热点扫描Agent → 热点报告
│ ├─→ 选题决策Agent → 选题清单
│ └─→ 排期Agent → 发布日历
│
├─→ 生产总监Agent
│ │
│ ├─→ 写作Agent(role=leaf)
│ ├─→ 配图Agent(role=leaf)
│ └─→ 排版Agent(role=leaf)
│
└─→ 运营总监Agent
│
├─→ 发布Agent(role=leaf)
└─→ 数据复盘Agent(role=leaf)
代码实现:
# 层级1:总指挥启动三位总监
delegate_task(
goal="""作为内容总监Agent,你需要组建一个3人团队:
1. 热点扫描员:搜索当日AI领域热点
2. 选题决策员:从热点中筛选可写选题
3. 排期员:制定发布计划
你可以继续使用 delegate_task 委派子任务。最终输出一份完整的「今日内容计划」到 ~/content-plan.md""",
toolsets=["web", "file", "terminal"],
role="coordinator" # 不设leaf,允许继续委派
)
delegate_task(
goal="""作为生产总监Agent,你需要:
1. 读取 ~/content-plan.md
2. 为每个选题启动写作Agent
3. 为每篇文章启动配图Agent
4. 最终输出排版完成的HTML
你可以继续委派子任务。""",
toolsets=["file", "terminal"],
role="coordinator"
)
关键技巧:
- 只有总监层不设 role="leaf",执行层必须设 leaf
- 层级深度建议不超过3层,否则协调成本超过收益
- 每层的输出文件路径要在context里明确传递
避坑指南:delegate_task 常见问题
1. 子Agent超时但文件已写入
症状:delegate_task 报超时错误,但检查输出文件发现内容已完整写入。
对策:不要因为超时就重试。先检查输出文件是否存在且字数充足(>1000字),如果内容完整直接进入下一步。
# 检查输出文件的模式
import os
output_path = os.path.expanduser("~/ai-neican/research/outputs/01-research.md")
if os.path.exists(output_path):
size = os.path.getsize(output_path)
if size > 2000: # 大于2KB,基本内容完整
print("✅ 文件已生成,跳过重试")
else:
print("⚠️ 文件太小,需要重试")
2. 子Agent找不到上游文件
症状:子Agent报错「文件不存在」。
根因:~ 路径展开问题。不同Agent的home目录可能不同。
对策:使用绝对路径或在goal里写出完整路径:
# ❌ 错误
context="读取 ~/output.md"
# ✅ 正确
context="读取 /home/agent/ai-neican/research/outputs/01-research.md"
3. 子Agent输出格式不一致
症状:同样prompt,不同子Agent输出格式差异大。
对策:在 goal 里给出输出模板:
goal="""...
输出格式(严格遵守):
## 标题
[一句话核心观点]
## 来源
- URL: [链接]
- 发布日期: [日期]
## 分析
[3-5句话深度分析]
"""
4. Token消耗失控
症状:一次 delegate_task 消耗了预期3倍的token。
根因:子Agent的context继承了主Agent的全部对话历史。
对策:
- 给子Agent的 context 要精简,只传必要信息
- 避免在 context 里贴大段文本,改用文件路径引用
- 对简单任务限制 toolsets(不给web权限可以省大量token)
实战案例:一人公司的AI内容工厂
我自己的AI创业内参项目,就是用 delegate_task 构建的:
每日流程(全自动,cron触发):
1. 07:00 热点扫描Agent启动 → 搜索中英文AI动态 → 输出3-5个候选选题
2. 08:00 主Agent判断选题(简单的规则判断,复杂选题人工确认)
3. 08:30 写作Agent启动 → 按模板生成1500-2500字文章
4. 09:00 配图Agent启动 → GPT Image 2生成3张插图
5. 09:30 发布Agent启动 → 上传到微信公众号草稿箱
成本核算(单篇文章):
- 热点扫描:~5000 tokens ($0.03)
- 文章写作:~8000 tokens ($0.05)
- 配图生成:3张 × $0.04 = $0.12
- 总计:约 $0.20/篇,月成本约 $6
效果数据(2026年5月):
- 月产出:62篇文章
- 平均阅读量:1200+
- 粉丝增长:+3400
- 人工干预次数:仅3次(选题判断)
总结
delegate_task 的本质不是「让AI帮你干活」,而是「让你学会当一个AI团队的指挥官」。
五个模式从简单到复杂:
1. 顺序流水线 — 入门首选,有依赖关系的任务链
2. 并行扇出 — 提速利器,独立任务同时执行
3. 协调者-专家 — 专业分工,不同领域各司其职
4. 辩论-综合 — 决策辅助,多角度论证
5. 层级树 — 终极形态,多层委派大规模协作
立即行动:从模式一开始,把你现在手工做的一个重复任务(比如每日信息收集),拆成2-3个 delegate_task,感受一下「指挥AI团队」的效率提升。
