多Agent编排：让三匹马同时跑
15 多Agent编排：让三匹马同时跑
Multi-Agent Orchestration: Running Three Horses at Once
一个Agent不够用的时候，让三个Agent并行工作。delegate_task是Hermes最强大也最容易用错的工具。
为什么需要多Agent
一个Agent的能力上限取决于它的上下文窗口和工具集。当任务足够复杂时，单Agent会撞上两堵墙。
上下文爆炸。一个Agent同时处理调研、编码和测试，三件事的信息全挤在同一个上下文里，互相干扰。调研的网页内容
占了大量token，留给代码推理的空间就不够了。
时间瓶颈。线性执行三个任务，每个30分钟，总共90分钟。如果能并行，总时间就是最慢那个的时间。
Hermes的delegate_task工具就是为了解决这两个问题。它能同时启动最多3个子Agent，每个有独立的上下文和工具
集。
delegate_task详解
delegate_task不是简单的「开个子线程」，它做了几件关键的事。
特性 说明
独立上下文 子Agent有自己的对话历史，不会污染主Agent的上下文
受限工具集 可以指定子Agent只能使用哪些工具。调研Agent只给web和browser，编码Agent只给terminal和file
独立终端会话 每个子Agent有自己的终端，互不干扰
并发上限3个 硬编码限制，防止资源耗尽
结果回传 子Agent完成后，结果返回给主Agent做汇总
3个并发的限制是经过考虑的设计。Nous Research在测试中发现，超过3个子Agent后，主Agent的汇总质量会急剧下
降。不是算力不够，是大模型在整合过多独立信息源时的注意力分散问题。
一个实际案例：竞品分析报告
假设你要写一份AI编程工具的竞品分析，覆盖三个产品：Claude Code、Cursor、Hermes Agent。传统做法是一个一个
调研，然后手动整合。
用delegate_task，流程变成这样：
主Agent 主Agent
→ →
并行执行
拆分任务+定义模板 汇总+生成报告
中间的并行执行展开看：
1 主Agent定义任务模板
「请按以下维度调研[产品名]：定位、核心功能、技术架构、定价、社区规模、优缺点。结果用markdown表格输
出。」
2 派出三个子Agent
子Agent A调研Claude Code，子Agent B调研Cursor，子Agent C调研Hermes。每个子Agent只分配web和
browser两个工具，不需要file或terminal。
3 主Agent汇总
三个子Agent返回各自的调研结果后，主Agent整合成一份对比报告，补充自己的判断和推荐。
三个调研任务并行，总时间从「A+B+C」变成「max(A, B, C)」。实测下来，一份通常要40分钟的竞品分析，15分钟就能
出。
受限工具集的安全设计
delegate_task的受限工具集不只是效率工具，更是安全机制。
想象一个场景：你让子Agent去网上搜索一段代码，它搜到了一个有恶意注入的代码片段。如果这个子Agent同时有
terminal权限，它可能会执行这段代码。但如果它只有web权限，搜索结果只会作为文本返回给主Agent审查。
这就是受限工具集的价值：最小权限原则在Agent层面的落地。
推荐 不推荐
好的实践：调研子Agent只给web+browser，编码子Agent 坏的实践：每个子Agent都给全部工具。方便是方便，但失
只给terminal+file+code_execution，汇总子Agent什么外 去了隔离的安全保障。
部工具都不给，只处理文本。
和Anthropic三Agent架构的关系
Anthropic在Agent设计指南中提出了一个经典的三Agent架构：Planner负责规划、Generator负责执行、Evaluator负责
评估。这个模式在很多场景下被证明有效。
Hermes的delegate_task和这个架构有相似之处，但也有关键区别：
维度 Anthropic三Agent Hermes delegate_task
角色划分 固定角色（规划/执行/评估） 任务驱动，角色灵活
通信方式 链式传递（规划→执行→评估） 星形结构（主Agent↔子Agent）
并行性 通常串行 最多3个并发
记忆 无内置记忆 主Agent保持完整记忆
Hermes的模式更灵活。你可以用delegate_task实现Anthropic的三Agent架构——一个子Agent做规划、一个做执行、
一个做评估。但你也可以让三个子Agent做同类型的并行任务（比如同时调研三个产品）。架构不是固定的，取决于你的
任务怎么拆。
Anthropic的三Agent架构是思维框架，告诉你「复杂任务可以拆成规划、执行、评估」。Hermes的delegate_task是执行
工具，让你把框架落地。一个管设计，一个管实现。
核心建议
多Agent编排容易过度设计。不是所有任务都需要拆成子Agent。如果一个任务在单Agent的上下文窗口里就能处理好，拆
分反而会增加通信开销和汇总错误。只在上下文不够用或者需要并行加速时，才考虑delegate_task。
经验法则：如果你发现自己要给主Agent写很长的汇总指令来整合子Agent的结果，说明任务拆分可能有问题。好的拆分
应该让汇总变得简单：每个子Agent的输出是自包含的、格式统一的、可以直接拼接的。
Multi-Agent Orchestration: Running Three Horses at Once
一个Agent不够用的时候，让三个Agent并行工作。delegate_task是Hermes最强大也最容易用错的工具。
为什么需要多Agent
一个Agent的能力上限取决于它的上下文窗口和工具集。当任务足够复杂时，单Agent会撞上两堵墙。
上下文爆炸。一个Agent同时处理调研、编码和测试，三件事的信息全挤在同一个上下文里，互相干扰。调研的网页内容
占了大量token，留给代码推理的空间就不够了。
时间瓶颈。线性执行三个任务，每个30分钟，总共90分钟。如果能并行，总时间就是最慢那个的时间。
Hermes的delegate_task工具就是为了解决这两个问题。它能同时启动最多3个子Agent，每个有独立的上下文和工具
集。
delegate_task详解
delegate_task不是简单的「开个子线程」，它做了几件关键的事。
特性 说明
独立上下文 子Agent有自己的对话历史，不会污染主Agent的上下文
受限工具集 可以指定子Agent只能使用哪些工具。调研Agent只给web和browser，编码Agent只给terminal和file
独立终端会话 每个子Agent有自己的终端，互不干扰
并发上限3个 硬编码限制，防止资源耗尽
结果回传 子Agent完成后，结果返回给主Agent做汇总
3个并发的限制是经过考虑的设计。Nous Research在测试中发现，超过3个子Agent后，主Agent的汇总质量会急剧下
降。不是算力不够，是大模型在整合过多独立信息源时的注意力分散问题。
一个实际案例：竞品分析报告
假设你要写一份AI编程工具的竞品分析，覆盖三个产品：Claude Code、Cursor、Hermes Agent。传统做法是一个一个
调研，然后手动整合。
用delegate_task，流程变成这样：
主Agent 主Agent
→ →
并行执行
拆分任务+定义模板 汇总+生成报告
中间的并行执行展开看：
1 主Agent定义任务模板
「请按以下维度调研[产品名]：定位、核心功能、技术架构、定价、社区规模、优缺点。结果用markdown表格输
出。」
2 派出三个子Agent
子Agent A调研Claude Code，子Agent B调研Cursor，子Agent C调研Hermes。每个子Agent只分配web和
browser两个工具，不需要file或terminal。
3 主Agent汇总
三个子Agent返回各自的调研结果后，主Agent整合成一份对比报告，补充自己的判断和推荐。
三个调研任务并行，总时间从「A+B+C」变成「max(A, B, C)」。实测下来，一份通常要40分钟的竞品分析，15分钟就能
出。
受限工具集的安全设计
delegate_task的受限工具集不只是效率工具，更是安全机制。
想象一个场景：你让子Agent去网上搜索一段代码，它搜到了一个有恶意注入的代码片段。如果这个子Agent同时有
terminal权限，它可能会执行这段代码。但如果它只有web权限，搜索结果只会作为文本返回给主Agent审查。
这就是受限工具集的价值：最小权限原则在Agent层面的落地。
推荐 不推荐
好的实践：调研子Agent只给web+browser，编码子Agent 坏的实践：每个子Agent都给全部工具。方便是方便，但失
只给terminal+file+code_execution，汇总子Agent什么外 去了隔离的安全保障。
部工具都不给，只处理文本。
和Anthropic三Agent架构的关系
Anthropic在Agent设计指南中提出了一个经典的三Agent架构：Planner负责规划、Generator负责执行、Evaluator负责
评估。这个模式在很多场景下被证明有效。
Hermes的delegate_task和这个架构有相似之处，但也有关键区别：
维度 Anthropic三Agent Hermes delegate_task
角色划分 固定角色（规划/执行/评估） 任务驱动，角色灵活
通信方式 链式传递（规划→执行→评估） 星形结构（主Agent↔子Agent）
并行性 通常串行 最多3个并发
记忆 无内置记忆 主Agent保持完整记忆
Hermes的模式更灵活。你可以用delegate_task实现Anthropic的三Agent架构——一个子Agent做规划、一个做执行、
一个做评估。但你也可以让三个子Agent做同类型的并行任务（比如同时调研三个产品）。架构不是固定的，取决于你的
任务怎么拆。
Anthropic的三Agent架构是思维框架，告诉你「复杂任务可以拆成规划、执行、评估」。Hermes的delegate_task是执行
工具，让你把框架落地。一个管设计，一个管实现。
核心建议
多Agent编排容易过度设计。不是所有任务都需要拆成子Agent。如果一个任务在单Agent的上下文窗口里就能处理好，拆
分反而会增加通信开销和汇总错误。只在上下文不够用或者需要并行加速时，才考虑delegate_task。
经验法则：如果你发现自己要给主Agent写很长的汇总指令来整合子Agent的结果，说明任务拆分可能有问题。好的拆分
应该让汇总变得简单：每个子Agent的输出是自包含的、格式统一的、可以直接拼接的。