Hermes Agent 子代理委派模式怎么选并行研究、代码审查与多文件工作的 Delegation 实践【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent当一个任务在 Hermes Agent 会话里变得庞大——多主题研究、整模块审查、跨文件重构——可以让它派生隔离的子代理subagent并行处理。每个子代理有自己的对话、自己的 terminal 会话和自己的工具集只有最终摘要会回到父代理的上下文中间的工具调用不会进入你的上下文窗口。本文按官方文档给出的三类最常见任务——并行研究、代码审查、多文件工作——讲清楚任务该不该委派、每种模式怎么下达指令与编写 context、要打开哪些配置、如何验证结果。前提你已有一个可用的 Hermes 会话CLI、TUI 或消息网关均可且父代理具备委派任务所需的工具web、terminal、文件等。子代理继承父代理已启用的工具集delegate_task不接受模型侧的toolsets参数子代理无法获得父代理没有的能力。先判断任务该不该委派模式指南给出的候选标准是推理密集的的子任务调试、代码审查、研究综合会把大量中间数据灌进上下文的任务相互独立的并行工作流例如同时研究主题 A 和 B需要新视角的任务即希望子代理不带会话中积累出来的假设去处理问题。以下情况应改用其他手段情形改用单次工具调用直接调用该工具机械的多步操作、步骤之间夹着逻辑execute_code需要与用户交互的任务子代理不能用clarify在主会话完成快速文件编辑直接做必须熬过会话关闭或进程重启的长任务cronjob或terminal(backgroundTrue, notify_on_completeTrue)delegate_task与execute_code不是替代关系功能参考从多个维度做了对比维度delegate_taskexecute_code推理完整 LLM 推理循环只是 Python 代码执行上下文全新的隔离对话没有对话只有脚本工具访问全部非屏蔽工具加推理7 个工具经 RPC无推理并行默认 10 个并发子代理可配置单个脚本适用需要判断的复杂任务机械的多步流水线Token 成本较高完整 LLM 循环较低只返回 stdout文档给出的经验法则是子任务需要推理、判断或多步问题求解时用delegate_task机械的数据处理或脚本化流程用execute_code。两者还有一种常见组合gather then analyzeexecute_code廉价地完成 10 次以上顺序机械采集再把那个昂贵的推理任务交给上下文干净的子代理这是文档中认为通常效率最高的组合。实际使用中你一般不需要显式要求委派agent 会根据任务复杂度自动判断何时派生子代理下面各模式描述的是它做出该决定后幕后的实际调用。模式一并行研究在对话中用一条自然语言指令列出多个主题并要求并行研究。文档示例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 Focus on recent developments and key players.背后的工具调用是一个tasks批量每个主题一个任务delegate_task(tasks[ { goal: Research WebAssembly outside the browser in 2025, context: Focus on: runtimes (Wasmtime, Wasmer), cloud/edge use cases, WASI progress }, { goal: Research RISC-V server chip adoption, context: Focus on: server chips shipping, cloud providers adopting, software ecosystem }, { goal: Research practical quantum computing applications, context: Focus on: error correction breakthroughs, real-world use cases, key companies } ])三个子代理并发执行各自独立搜索网页并返回摘要父代理再把它们综合成一份连贯的简报。研究类任务的context只需给出每个任务的关注点即可不必重复背景。模式二代码审查代码审查的价值在全新上下文子代理没有先入之见地去接近代码。文档示例是对认证模块做安全审查。自然语言指令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( goalReview src/auth/ for security issues and fix any found, contextProject 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. Fix issues found and verify tests pass. )context字段是这一模式的关键项目路径、技术栈、相关文件清单、测试命令、审查重点要一次给全原因见下文写 goal 与 context 的通用规则。用 /review 命令审查对话刚产出的工作如果审查对象是当前会话刚产出的工作成果PR、diff、代码、文档、设计可以直接用/review命令不用手写 prompt。功能参考说明它在 CLI、TUI、Desktop 和所有网关消息平台都可用/review # 审查最近 10 条消息所呈现的内容 /review focus on security # 为审查者追加指令机制是最近 10 条用户/助手消息排除工具输出和系统消息被快照为审查者的初始证据审查者经与delegate_task相同的后台委派通道派发拿到完整子代理工具集会真正打开 PR、读 diff、运行代码完成后完整审查结果作为普通后台子代理完成重新进入会话主代理看到后可以据此修复问题或回复你。文档给出的标准流程主代理开 PR你输入/review第二双眼睛在你继续工作的同时做调查。默认审查者使用主模型。要固定专用审查模型在config.yaml配置auxiliary.review取值为文档示例auxiliary: review: provider: openrouter # or nous, anthropic, a direct base_url, ... model: anthropic/claude-opus-4.6 # a strong reviewer model注意/review与/refine是两回事/refine审查对话以更新记忆和技能/review审查的是对话产出的工作成果。模式三多文件工作重构或协调式修改横跨很多文件时把任务拆给并行的子代理每个负责代码库的不同部分。文档示例响应格式重构拆成三个任务改 handlers、更新 SDK、更新文档delegate_task(tasks[ { goal: Refactor all API endpoint handlers to use the new response format, context: Project at /home/user/api-server. Files: src/handlers/users.py, src/handlers/auth.py, src/handlers/billing.py Old format: return {data: result, status: ok} New format: return APIResponse(dataresult, status200).to_dict() Import: from src.responses import APIResponse Run tests after: pytest tests/handlers/ -v }, { goal: Update all client SDK methods to handle the new response format, context: Project at /home/user/api-server. Files: sdk/python/client.py, sdk/python/models.py Old parsing: result response.json()[data] New parsing: result response.json()[data] (same key, but add status code checking) Also update sdk/python/tests/test_client.py }, { goal: Update API documentation to reflect the new response format, context: Project at /home/user/api-server. Docs at: docs/api/. Format: Markdown with code examples. Update all response examples from old format to new format. Add a Response Format section to docs/api/overview.md explaining the schema. } ])context 中的项目路径、新旧格式、测试命令均为文档示例中的具体值实际使用时替换为你项目对应的信息。拆分规则每个子代理有自己的 terminal 会话可以在同一项目目录工作而互不干扰——前提是它们编辑不同的文件。如果两个子代理可能碰到同一个文件文档建议你在并行工作完成后自己处理那个文件。需要更强隔离时可在config.yaml打开delegation.worktree_isolation: true让每个子代理进入独立的 git worktreedelegation: worktree_isolation: true # default: false开启后每个子代理的 terminal 起点是repo/.worktrees/subagent-id位于独立分支hermes-subagent/subagent-id父代理的检出保持不变子代理结束时其结果条目新增worktree字段报告path、branch、commits相对基线的领先提交数和dirty父代理逐个git log branch、git merge branch审查或合并。没有提交且工作区干净的 worktree 会被自动清理pruned: true若 git 检查探针失败则保留并标记inspection_failed: true此时应人工检查 worktree 而不是假设子代理没产出。该选项仅限 git 仓库和本地 terminal 后端在非 git 目录或 docker/ssh/modal 后端上会静默回退到共享工作区行为不会报错。写 goal 与 context 的通用规则以下规则适用于上面三种模式子代理什么都不知道。它从完全全新的对话开始对父会话的历史、此前的工具调用一无所知唯一上下文来自父代理传入的goal和context。委派修一下我们在讨论的那个 bug时子代理完全不知道你说的是哪个 bug。必须显式传入文件路径、错误信息、项目结构和约束# BAD - subagent has no idea what the error is delegate_task(goalFix the error) # GOOD - subagent has all context it needs delegate_task( goalFix the TypeError in api/handlers.py, contextThe file api/handlers.py has a TypeError on line 47: NoneType object has no attribute get. The function process_request() receives a dict from parse_body(), but parse_body() returns None when Content-Type is missing. The project is at /home/user/myproject and uses Python 3.11. )一个例外当父代理有已解析的工作区目录时每个子代理的系统提示会内嵌该工作区的项目上下文文件.hermes.md AGENTS.md 链 CLAUDE.md .cursorrulesSOUL.md 除外仓库内的子代理会直接按仓库自身约定工作。goal 要具体。Fix the bug 太模糊Fix the TypeError in api/handlers.py line 47 where process_request() receives None from parse_body() 才给了子代理足够的下手依据。包含文件路径。子代理不了解你的项目结构始终给出相关文件的绝对路径、项目根目录和测试命令。子代理的产出是结构化摘要。子代理收到的是由 goal 和 context 构造的聚焦系统提示被要求说明做了什么、发现了什么、修改了哪些文件、遇到什么问题。可选地任务可以附带output_schema一个 JSON Schema 对象作为输出契约子代理事先看到该 schema父代理在结果返回时做校验校验失败时子代理只得到一次有界的纠正回合结果上会带上schema_validtrue/false失败时另有schema_errors。文档建议 schema 保持宽松只要求你真正会读的字段。关键配置项以下配置项都位于config.yaml的delegation:段摘选自功能参考的配置示例# In ~/.hermes/config.yaml delegation: max_iterations: 250 # Max turns per child (default: 250) # max_concurrent_children: 10 # Parallel children per batch # max_spawn_depth: 1 # Tree depth (default 1 flat) # orchestrator_enabled: true # Set to false to force all children to leaf # worktree_isolation: false # Give each child its own git worktree # model: google/gemini-3-flash-preview # Optional provider/model override # provider: openrouter # Optional built-in providermax_concurrent_children每次delegate_task调用的并行批量大小下限 1、无硬上限也可用DELEGATION_MAX_CONCURRENT_CHILDREN环境变量设置。tasks数组超过上限时调用返回工具错误说明上限而不是静默截断。默认值在不同文档中不一致模式指南与功能参考都写默认 10而配置参考的 Delegation 一节写默认 3——如果实际批量大小对你重要请显式设置该项以消除歧义。max_iterations每个子代理的迭代上限默认 250。耗尽预算的子代理带exit_reason: max_iterations和truncated: true返回父代理据此区分预算停止和任务完成。文档建议简单任务群调低以省成本长调查调高。max_spawn_depth默认 1即扁平委派——父派子子不能再委派。提到 2 后roleorchestrator的子代理可以派生 leaf 孙代理。功能文档说 3 及以上可继续加深、无上限成本是实际限制配置参考则说明该值被钳制在 1–3两者在 1 和 2 的行为上描述一致上限处不一致。嵌套委派是显式选择delegation.orchestrator_enabled: false是全局开关强制所有子代理为 leaf。文档给出成本警告max_spawn_depth: 3且max_concurrent_children: 3时树可达 3×3×3 27 个并发 leaf 代理每加一层花费成倍增长。model/provider让子代理使用与父代理不同的模型例如主会话保持前沿模型做规划delegation.model固定到廉价模型跑所有子代理。注意这是全局固定delegate_task没有按任务指定模型的参数一个批次里的所有子代理都跑在配置的委派模型上留空则子代理继承父代理的模型。默认没有墙钟超时。子代理只可能因 API 错误、工具错误或迭代预算耗尽而失败若确需硬上限例如无人值守 cron 驱动委派的费用控制自行设置child_timeout_seconds下限 30 秒0或负值表示不启用。结果验证与运行监控检查结果。子代理的摘要只是摘要。文档的明确建议子代理说修好了 bug 且测试通过时自己跑一遍测试或读一遍 diff 再下结论。失败不会静默。子代理失败不可重试的 provider 错误、超时、崩溃或无可用输出时永远有回音CLI 的委派树打印一行原因文档示例⚠️ Subagent failed — your goal: HTTP 404: model not found (after 12s)网关平台Telegram、Discord、Slack 等即使该平台tool_progress关闭也会以独立聊天通知送达同一行父代理在工具结果中拿到status: failed加完整error文本可以重试、改道或上报。Live transcripts。每次delegate_task派发都会按任务创建一个只追加的人类可读日志hermes_home/cache/delegation/live/delegation_id/task-n.log文件在派发时预创建可立即观看子代理实时工作tail -f ~/.hermes/cache/delegation/live/deleg_ab12cd34/task-0.logdeleg_ab12cd34是文档示例中的委派 id真实值取自派发响应返回的live_transcripts路径。每行带时间戳展示子代理的助手文本、工具调用、工具结果和最终状态标记同目录的manifest.json描述整个批次goal、任务数、逐任务状态。日志在完成保留后继续存在兼作完整保真的运行记录超过 7 天的目录会在下次派发时自动清理。/agents与实时监控。TUI 提供/agents叠加层别名/tasks运行中和近期完成的子代理的实时树视图、按分支的成本/token/文件改动汇总、可单独停止某个子代理而不影响兄弟任务、以及完成后的逐轮历史回放。经典 CLI 中CtrlT或F6在 composer 上方打开实时名册。经典 CLI 和各网关平台上/agents还会列出后台委派及逐子代理的实时活动文档示例deleg_ab12cd34 · running · research the delegation stall monitor各子代理的 API 调用数与最近活跃时间被卡住监测标记的委派会显示stalling · no progress 450s — interrupting便于区分慢和卡死。限制与边界委派不是持久执行。顶层委派在后台运行但仍是进程内的会话关闭、/stop、/new或进程重启都可能取消或搁置进行中的工作正常的后续消息不会取消后台批次。必须熬过这些边界的任务应改用cronjob或terminal(backgroundTrue, notify_on_completeTrue)。批量结果默认合并返回。tasks数组调用立即返回一个句柄默认所有任务完成后父上下文收到一条合并消息结果只在父代理轮次之间送达因此父代理应完成不依赖子结果的工作然后结束轮次不要在等待期间轮询 transcript 或 CI。delegation.independent_completions: true可改为按完成单元逐个送达。工具集受限。子代理不能用clarify无法与用户交互、memory不写共享持久记忆、send_message、cronjobleaf 子代理默认角色不能再调用delegate_task。两种角色都保留execute_code做程序化工具调用。默认共享工作区。除开启worktree_isolation外子代理共享父代理的工作目录——对研究和只读类工作没问题但并行子代理编辑同一仓库可能互相冲突拆分时两个子代理不碰同一文件就是你要遵守的规则。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Hermes Agent 子代理委派模式怎么选：并行研究、代码审查与多文件工作的 Delegation 实践
Hermes Agent 子代理委派模式怎么选并行研究、代码审查与多文件工作的 Delegation 实践【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent当一个任务在 Hermes Agent 会话里变得庞大——多主题研究、整模块审查、跨文件重构——可以让它派生隔离的子代理subagent并行处理。每个子代理有自己的对话、自己的 terminal 会话和自己的工具集只有最终摘要会回到父代理的上下文中间的工具调用不会进入你的上下文窗口。本文按官方文档给出的三类最常见任务——并行研究、代码审查、多文件工作——讲清楚任务该不该委派、每种模式怎么下达指令与编写 context、要打开哪些配置、如何验证结果。前提你已有一个可用的 Hermes 会话CLI、TUI 或消息网关均可且父代理具备委派任务所需的工具web、terminal、文件等。子代理继承父代理已启用的工具集delegate_task不接受模型侧的toolsets参数子代理无法获得父代理没有的能力。先判断任务该不该委派模式指南给出的候选标准是推理密集的的子任务调试、代码审查、研究综合会把大量中间数据灌进上下文的任务相互独立的并行工作流例如同时研究主题 A 和 B需要新视角的任务即希望子代理不带会话中积累出来的假设去处理问题。以下情况应改用其他手段情形改用单次工具调用直接调用该工具机械的多步操作、步骤之间夹着逻辑execute_code需要与用户交互的任务子代理不能用clarify在主会话完成快速文件编辑直接做必须熬过会话关闭或进程重启的长任务cronjob或terminal(backgroundTrue, notify_on_completeTrue)delegate_task与execute_code不是替代关系功能参考从多个维度做了对比维度delegate_taskexecute_code推理完整 LLM 推理循环只是 Python 代码执行上下文全新的隔离对话没有对话只有脚本工具访问全部非屏蔽工具加推理7 个工具经 RPC无推理并行默认 10 个并发子代理可配置单个脚本适用需要判断的复杂任务机械的多步流水线Token 成本较高完整 LLM 循环较低只返回 stdout文档给出的经验法则是子任务需要推理、判断或多步问题求解时用delegate_task机械的数据处理或脚本化流程用execute_code。两者还有一种常见组合gather then analyzeexecute_code廉价地完成 10 次以上顺序机械采集再把那个昂贵的推理任务交给上下文干净的子代理这是文档中认为通常效率最高的组合。实际使用中你一般不需要显式要求委派agent 会根据任务复杂度自动判断何时派生子代理下面各模式描述的是它做出该决定后幕后的实际调用。模式一并行研究在对话中用一条自然语言指令列出多个主题并要求并行研究。文档示例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 Focus on recent developments and key players.背后的工具调用是一个tasks批量每个主题一个任务delegate_task(tasks[ { goal: Research WebAssembly outside the browser in 2025, context: Focus on: runtimes (Wasmtime, Wasmer), cloud/edge use cases, WASI progress }, { goal: Research RISC-V server chip adoption, context: Focus on: server chips shipping, cloud providers adopting, software ecosystem }, { goal: Research practical quantum computing applications, context: Focus on: error correction breakthroughs, real-world use cases, key companies } ])三个子代理并发执行各自独立搜索网页并返回摘要父代理再把它们综合成一份连贯的简报。研究类任务的context只需给出每个任务的关注点即可不必重复背景。模式二代码审查代码审查的价值在全新上下文子代理没有先入之见地去接近代码。文档示例是对认证模块做安全审查。自然语言指令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( goalReview src/auth/ for security issues and fix any found, contextProject 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. Fix issues found and verify tests pass. )context字段是这一模式的关键项目路径、技术栈、相关文件清单、测试命令、审查重点要一次给全原因见下文写 goal 与 context 的通用规则。用 /review 命令审查对话刚产出的工作如果审查对象是当前会话刚产出的工作成果PR、diff、代码、文档、设计可以直接用/review命令不用手写 prompt。功能参考说明它在 CLI、TUI、Desktop 和所有网关消息平台都可用/review # 审查最近 10 条消息所呈现的内容 /review focus on security # 为审查者追加指令机制是最近 10 条用户/助手消息排除工具输出和系统消息被快照为审查者的初始证据审查者经与delegate_task相同的后台委派通道派发拿到完整子代理工具集会真正打开 PR、读 diff、运行代码完成后完整审查结果作为普通后台子代理完成重新进入会话主代理看到后可以据此修复问题或回复你。文档给出的标准流程主代理开 PR你输入/review第二双眼睛在你继续工作的同时做调查。默认审查者使用主模型。要固定专用审查模型在config.yaml配置auxiliary.review取值为文档示例auxiliary: review: provider: openrouter # or nous, anthropic, a direct base_url, ... model: anthropic/claude-opus-4.6 # a strong reviewer model注意/review与/refine是两回事/refine审查对话以更新记忆和技能/review审查的是对话产出的工作成果。模式三多文件工作重构或协调式修改横跨很多文件时把任务拆给并行的子代理每个负责代码库的不同部分。文档示例响应格式重构拆成三个任务改 handlers、更新 SDK、更新文档delegate_task(tasks[ { goal: Refactor all API endpoint handlers to use the new response format, context: Project at /home/user/api-server. Files: src/handlers/users.py, src/handlers/auth.py, src/handlers/billing.py Old format: return {data: result, status: ok} New format: return APIResponse(dataresult, status200).to_dict() Import: from src.responses import APIResponse Run tests after: pytest tests/handlers/ -v }, { goal: Update all client SDK methods to handle the new response format, context: Project at /home/user/api-server. Files: sdk/python/client.py, sdk/python/models.py Old parsing: result response.json()[data] New parsing: result response.json()[data] (same key, but add status code checking) Also update sdk/python/tests/test_client.py }, { goal: Update API documentation to reflect the new response format, context: Project at /home/user/api-server. Docs at: docs/api/. Format: Markdown with code examples. Update all response examples from old format to new format. Add a Response Format section to docs/api/overview.md explaining the schema. } ])context 中的项目路径、新旧格式、测试命令均为文档示例中的具体值实际使用时替换为你项目对应的信息。拆分规则每个子代理有自己的 terminal 会话可以在同一项目目录工作而互不干扰——前提是它们编辑不同的文件。如果两个子代理可能碰到同一个文件文档建议你在并行工作完成后自己处理那个文件。需要更强隔离时可在config.yaml打开delegation.worktree_isolation: true让每个子代理进入独立的 git worktreedelegation: worktree_isolation: true # default: false开启后每个子代理的 terminal 起点是repo/.worktrees/subagent-id位于独立分支hermes-subagent/subagent-id父代理的检出保持不变子代理结束时其结果条目新增worktree字段报告path、branch、commits相对基线的领先提交数和dirty父代理逐个git log branch、git merge branch审查或合并。没有提交且工作区干净的 worktree 会被自动清理pruned: true若 git 检查探针失败则保留并标记inspection_failed: true此时应人工检查 worktree 而不是假设子代理没产出。该选项仅限 git 仓库和本地 terminal 后端在非 git 目录或 docker/ssh/modal 后端上会静默回退到共享工作区行为不会报错。写 goal 与 context 的通用规则以下规则适用于上面三种模式子代理什么都不知道。它从完全全新的对话开始对父会话的历史、此前的工具调用一无所知唯一上下文来自父代理传入的goal和context。委派修一下我们在讨论的那个 bug时子代理完全不知道你说的是哪个 bug。必须显式传入文件路径、错误信息、项目结构和约束# BAD - subagent has no idea what the error is delegate_task(goalFix the error) # GOOD - subagent has all context it needs delegate_task( goalFix the TypeError in api/handlers.py, contextThe file api/handlers.py has a TypeError on line 47: NoneType object has no attribute get. The function process_request() receives a dict from parse_body(), but parse_body() returns None when Content-Type is missing. The project is at /home/user/myproject and uses Python 3.11. )一个例外当父代理有已解析的工作区目录时每个子代理的系统提示会内嵌该工作区的项目上下文文件.hermes.md AGENTS.md 链 CLAUDE.md .cursorrulesSOUL.md 除外仓库内的子代理会直接按仓库自身约定工作。goal 要具体。Fix the bug 太模糊Fix the TypeError in api/handlers.py line 47 where process_request() receives None from parse_body() 才给了子代理足够的下手依据。包含文件路径。子代理不了解你的项目结构始终给出相关文件的绝对路径、项目根目录和测试命令。子代理的产出是结构化摘要。子代理收到的是由 goal 和 context 构造的聚焦系统提示被要求说明做了什么、发现了什么、修改了哪些文件、遇到什么问题。可选地任务可以附带output_schema一个 JSON Schema 对象作为输出契约子代理事先看到该 schema父代理在结果返回时做校验校验失败时子代理只得到一次有界的纠正回合结果上会带上schema_validtrue/false失败时另有schema_errors。文档建议 schema 保持宽松只要求你真正会读的字段。关键配置项以下配置项都位于config.yaml的delegation:段摘选自功能参考的配置示例# In ~/.hermes/config.yaml delegation: max_iterations: 250 # Max turns per child (default: 250) # max_concurrent_children: 10 # Parallel children per batch # max_spawn_depth: 1 # Tree depth (default 1 flat) # orchestrator_enabled: true # Set to false to force all children to leaf # worktree_isolation: false # Give each child its own git worktree # model: google/gemini-3-flash-preview # Optional provider/model override # provider: openrouter # Optional built-in providermax_concurrent_children每次delegate_task调用的并行批量大小下限 1、无硬上限也可用DELEGATION_MAX_CONCURRENT_CHILDREN环境变量设置。tasks数组超过上限时调用返回工具错误说明上限而不是静默截断。默认值在不同文档中不一致模式指南与功能参考都写默认 10而配置参考的 Delegation 一节写默认 3——如果实际批量大小对你重要请显式设置该项以消除歧义。max_iterations每个子代理的迭代上限默认 250。耗尽预算的子代理带exit_reason: max_iterations和truncated: true返回父代理据此区分预算停止和任务完成。文档建议简单任务群调低以省成本长调查调高。max_spawn_depth默认 1即扁平委派——父派子子不能再委派。提到 2 后roleorchestrator的子代理可以派生 leaf 孙代理。功能文档说 3 及以上可继续加深、无上限成本是实际限制配置参考则说明该值被钳制在 1–3两者在 1 和 2 的行为上描述一致上限处不一致。嵌套委派是显式选择delegation.orchestrator_enabled: false是全局开关强制所有子代理为 leaf。文档给出成本警告max_spawn_depth: 3且max_concurrent_children: 3时树可达 3×3×3 27 个并发 leaf 代理每加一层花费成倍增长。model/provider让子代理使用与父代理不同的模型例如主会话保持前沿模型做规划delegation.model固定到廉价模型跑所有子代理。注意这是全局固定delegate_task没有按任务指定模型的参数一个批次里的所有子代理都跑在配置的委派模型上留空则子代理继承父代理的模型。默认没有墙钟超时。子代理只可能因 API 错误、工具错误或迭代预算耗尽而失败若确需硬上限例如无人值守 cron 驱动委派的费用控制自行设置child_timeout_seconds下限 30 秒0或负值表示不启用。结果验证与运行监控检查结果。子代理的摘要只是摘要。文档的明确建议子代理说修好了 bug 且测试通过时自己跑一遍测试或读一遍 diff 再下结论。失败不会静默。子代理失败不可重试的 provider 错误、超时、崩溃或无可用输出时永远有回音CLI 的委派树打印一行原因文档示例⚠️ Subagent failed — your goal: HTTP 404: model not found (after 12s)网关平台Telegram、Discord、Slack 等即使该平台tool_progress关闭也会以独立聊天通知送达同一行父代理在工具结果中拿到status: failed加完整error文本可以重试、改道或上报。Live transcripts。每次delegate_task派发都会按任务创建一个只追加的人类可读日志hermes_home/cache/delegation/live/delegation_id/task-n.log文件在派发时预创建可立即观看子代理实时工作tail -f ~/.hermes/cache/delegation/live/deleg_ab12cd34/task-0.logdeleg_ab12cd34是文档示例中的委派 id真实值取自派发响应返回的live_transcripts路径。每行带时间戳展示子代理的助手文本、工具调用、工具结果和最终状态标记同目录的manifest.json描述整个批次goal、任务数、逐任务状态。日志在完成保留后继续存在兼作完整保真的运行记录超过 7 天的目录会在下次派发时自动清理。/agents与实时监控。TUI 提供/agents叠加层别名/tasks运行中和近期完成的子代理的实时树视图、按分支的成本/token/文件改动汇总、可单独停止某个子代理而不影响兄弟任务、以及完成后的逐轮历史回放。经典 CLI 中CtrlT或F6在 composer 上方打开实时名册。经典 CLI 和各网关平台上/agents还会列出后台委派及逐子代理的实时活动文档示例deleg_ab12cd34 · running · research the delegation stall monitor各子代理的 API 调用数与最近活跃时间被卡住监测标记的委派会显示stalling · no progress 450s — interrupting便于区分慢和卡死。限制与边界委派不是持久执行。顶层委派在后台运行但仍是进程内的会话关闭、/stop、/new或进程重启都可能取消或搁置进行中的工作正常的后续消息不会取消后台批次。必须熬过这些边界的任务应改用cronjob或terminal(backgroundTrue, notify_on_completeTrue)。批量结果默认合并返回。tasks数组调用立即返回一个句柄默认所有任务完成后父上下文收到一条合并消息结果只在父代理轮次之间送达因此父代理应完成不依赖子结果的工作然后结束轮次不要在等待期间轮询 transcript 或 CI。delegation.independent_completions: true可改为按完成单元逐个送达。工具集受限。子代理不能用clarify无法与用户交互、memory不写共享持久记忆、send_message、cronjobleaf 子代理默认角色不能再调用delegate_task。两种角色都保留execute_code做程序化工具调用。默认共享工作区。除开启worktree_isolation外子代理共享父代理的工作目录——对研究和只读类工作没问题但并行子代理编辑同一仓库可能互相冲突拆分时两个子代理不碰同一文件就是你要遵守的规则。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考