Hermes Agent 的子 Agent 编排

子 Agent 是主 Agent 委派的执行单元，负责完成独立的子任务，结果汇总回主 Agent。

当任务可以拆分为多个独立分支、需要并行探索、或者不同步骤需要不同能力配置时。

技能是可复用的能力单元，子 Agent 是运行时的工作单元。技能被子 Agent 调用，子 Agent 被主 Agent 编排。

子 Agent 随任务创建，任务完成后销毁。它的上下文和结果会汇报给主 Agent，但不会长期驻留。

子 Agent 通过主 Agent 的协调总线通信，不直接互相调用。主 Agent 负责结果聚合和上下文传递。

并行提升速度但增加 Token 消耗。每个子 Agent 都有独立的上下文窗口，总消耗 = sum(各子Agent消耗) + 聚合消耗。

主 Agent 分配子任务，子 Agent 执行后汇报结果。

• 主 Agent 掌握全局上下文
• 子 Agent 聚焦局部任务
• 结果汇总后由主 Agent 决策下一步

多个子 Agent 按顺序接力执行，每个子 Agent 处理一个阶段。

• 前一个子 Agent 的输出是后一个的输入
• 每个阶段可配置不同模型和能力
• 流水线整体进度可追踪

多个子 Agent 同时探索不同方向，最快返回有效结果的被采纳。

• 并行探索降低延迟
• 适合开放式研究任务
• 需要结果质量评估机制

结合上述模式，根据任务阶段动态切换编排策略。

• 前期竞速探索方向
• 中期主从深入执行
• 后期流水线收尾汇总

多个子 Agent 并行执行相同任务，通过投票或择优选取最佳结果。

• 适合验证型或探索型任务
• 多路并行为结果质量提供冗余
• 需要结果比较和选择机制

子 Agent 在执行过程中可以再创建自己的子 Agent，形成层级结构。

• 适合深层嵌套的复杂任务
• 每层可以有不同的精力和策略
• 总深度建议控制在 3 层以内

子任务太大则失去并行意义，太小则协调成本高于执行收益。一个好的判断标准：子 Agent 应该能独立完成一个可交付的子结果。

子 Agent 不应该从零开始。主 Agent 需要传递足够的背景信息，但也要避免把整个上下文都丢给它。

自由格式的回复不利于主 Agent 做聚合和判断。定义统一的结果格式，包含结论、证据和置信度。

子 Agent 可能卡在某个分支上。为每个子任务设置超时时间，超时后应有降级或重试策略。

子 Agent 失败时应该返回错误信息，而不是沉默或返回空结果。主 Agent 需要知道哪里失败了才能做决策。

子 Agent 运行状态需要可观测。为每个子 Agent 添加执行状态追踪，主 Agent 应该能看到哪些子 Agent 运行中、已完成、已超时或已失败。

每个子 Agent 消耗独立的上下文窗口。为子 Agent 分配合理的上下文预算，避免某个子 Agent 占用过多资源影响整体执行。

子 Agent 不是免费的。每个子 Agent 都有自己的上下文消耗和协调开销。超过 5-7 个并行子 Agent，协调成本会超过并行收益。

不同子 Agent 负责不同任务，应该有不同的行为提示。一刀切的系统提示会让子 Agent 失去角色分化优势。

没有依赖关系时并行执行，有依赖关系时串行化。如果先执行的子 Agent 输出是后续步骤的输入，应该用流水线而非主从式编排。

主从式是最容易理解和调试的编排模式。先用它跑通子 Agent 的基本工作流，再考虑引入其他模式。

当任务有明确的阶段划分且阶段间依赖固定时，切换到流水线。注意每个阶段的输出格式要标准化，便于下游消费。

当需要快速找到可行方案时，竞速式编排多个子 Agent 并行探索不同方向。需要建立结果质量标准来判断哪个方案最好。

当任务有多个阶段且不同阶段需要不同策略时，组合使用多种编排模式。注意保持整体的可观测性和错误传播路径清晰。

如果一个任务不需要并行，大概率也不需要子 Agent。先确认任务是否真的可以拆分，再决定是否引入子 Agent。

任务拆分越清晰，子 Agent 的执行质量越高。花时间在设计任务拆分和上下文传递上，远比在子 Agent 层面调参有效。

不会有人一开始就用混合式编排。从最简单的模式开始，随着对任务理解的加深逐步升级编排策略。