Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

title: “Subagent Driven Development — Execute plans via delegate_task subagents (2-stage review)” sidebar_label: “Subagent Driven Development” description: “Execute plans via delegate_task subagents (2-stage review)”

{/* 本页面由 website/scripts/generate-skill-docs.py 根据技能对应的 SKILL.md 文件自动生成。请直接编辑源文件 SKILL.md，而非此页面。 */}

子代理驱动开发

通过 delegate_task 子代理执行计划（两阶段审查机制）。

技能元数据
来源可选 — 通过 hermes skills install official/software-development/subagent-driven-development 安装
路径optional-skills/software-development/subagent-driven-development
版本1.1.0
创建者Hermes Agent（基于 obra/superpowers 改编）
许可证MIT
支持平台linux、macos、windows
标签delegation、subagent、implementation、workflow、parallel
相关技能plan、requesting-code-review、test-driven-development

参考：完整 SKILL.md 内容

:::info 以下是当触发该技能时 Hermes 加载的完整技能定义。技能处于激活状态时，代理将依据此内容执行操作。
::

子代理驱动开发

概述

通过为每个任务分配全新的子代理，并结合系统化的两阶段审查机制来执行实现计划。

核心原则： 每个任务使用独立的子代理 + 两阶段审查（先审查需求规格，再审查代码质量）= 高质量与快速迭代。

适用场景

在以下情况下可使用此技能：

  • 已有实现计划（来自 plan 技能或用户需求）
  • 任务之间大多相互独立
  • 对代码质量和规范合规性要求较高
  • 希望在任务之间实现自动审查

与手动执行的区别：

  • 每个任务拥有独立的上下文环境（避免因历史状态积累导致的混乱）
  • 自动化审查流程可及早发现问题
  • 所有任务都能接受一致的质量检查
  • 子代理可在开始工作前提出疑问

工作流程

1. 读取并解析计划

读取计划文件，提前提取所有任务及其完整文本内容和上下文信息，进而生成待办清单：

# Read the plan
read_file("docs/plans/feature-plan.md")

# Create todo list with all tasks
todo([
    {"id": "task-1", "content": "Create User model with email field", "status": "pending"},
    {"id": "task-2", "content": "Add password hashing utility", "status": "pending"},
    {"id": "task-3", "content": "Create login endpoint", "status": "pending"},
])

关键点： 仅需阅读计划内容一次，并提取所有相关信息。切勿让子智能体去读取计划文件——应直接在上下文中提供完整的任务文本。

2. 单项任务处理流程

针对计划中的每一项任务：

第一步：派遣执行子智能体

使用 delegate_task 函数，并传入完整的上下文信息：

delegate_task(
    goal="Implement Task 1: Create User model with email and password_hash fields",
    context="""
    TASK FROM PLAN:
    - Create: src/models/user.py
    - Add User class with email (str) and password_hash (str) fields
    - Use bcrypt for password hashing
    - Include __repr__ for debugging

    FOLLOW TDD:
    1. Write failing test in tests/models/test_user.py
    2. Run: pytest tests/models/test_user.py -v (verify FAIL)
    3. Write minimal implementation
    4. Run: pytest tests/models/test_user.py -v (verify PASS)
    5. Run: pytest tests/ -q (verify no regressions)
    6. Commit: git add -A && git commit -m "feat: add User model with password hashing"

    PROJECT CONTEXT:
    - Python 3.11, Flask app in src/app.py
    - Existing models in src/models/
    - Tests use pytest, run from project root
    - bcrypt already in requirements.txt
    """,
    toolsets=['terminal', 'file']
)

第2步：派遣规范合规性审核员

在实施人员完成相关工作后，需根据原始规范进行核查：

delegate_task(
    goal="Review if implementation matches the spec from the plan",
    context="""
    ORIGINAL TASK SPEC:
    - Create src/models/user.py with User class
    - Fields: email (str), password_hash (str)
    - Use bcrypt for password hashing
    - Include __repr__

    CHECK:
    - [ ] All requirements from spec implemented?
    - [ ] File paths match spec?
    - [ ] Function signatures match spec?
    - [ ] Behavior matches expected?
    - [ ] Nothing extra added (no scope creep)?

    OUTPUT: PASS or list of specific spec gaps to fix.
    """,
    toolsets=['file']
)

若发现规范问题： 填补缺失内容，然后重新进行规范审查。只有在符合规范要求后才能继续。

第3步：派发代码质量审查员

在通过规范检查后：

delegate_task(
    goal="Review code quality for Task 1 implementation",
    context="""
    FILES TO REVIEW:
    - src/models/user.py
    - tests/models/test_user.py

    CHECK:
    - [ ] Follows project conventions and style?
    - [ ] Proper error handling?
    - [ ] Clear variable/function names?
    - [ ] Adequate test coverage?
    - [ ] No obvious bugs or missed edge cases?
    - [ ] No security issues?

    OUTPUT FORMAT:
    - Critical Issues: [must fix before proceeding]
    - Important Issues: [should fix]
    - Minor Issues: [optional]
    - Verdict: APPROVED or REQUEST_CHANGES
    """,
    toolsets=['file']
)

如发现质量问题： 修复问题后需重新进行审核。只有获得批准后方可继续后续步骤。

第4步：标记为已完成

todo([{"id": "task-1", "content": "Create User model with email field", "status": "completed"}], merge=True)

3. 最终审核

在所有任务均完成之后，需指派一名最终集成审核员进行核查：

delegate_task(
    goal="Review the entire implementation for consistency and integration issues",
    context="""
    All tasks from the plan are complete. Review the full implementation:
    - Do all components work together?
    - Any inconsistencies between tasks?
    - All tests passing?
    - Ready for merge?
    """,
    toolsets=['terminal', 'file']
)

4. 验证并提交

# Run full test suite
pytest tests/ -q

# Review all changes
git diff --stat

# Final commit if needed
git add -A && git commit -m "feat: complete [feature name] implementation"

任务粒度

每个任务 = 2-5分钟的专注工作时间。

任务过大：

  • “实现用户认证系统”

理想规模：

  • “创建包含邮箱和密码字段的用户模型”
  • “添加密码哈希函数”
  • “创建登录接口”
  • “实现JWT令牌生成功能”
  • “创建注册接口”

需避免的误区 —— 绝对不要这样做

  • 未制定计划就直接开始开发
  • 跳过审查环节（无论是规范合规性还是代码质量检查）
  • 在存在未修复的关键/重要问题时继续推进
  • 对涉及同一文件的多个任务同时分配多个执行子代理
  • 要求子代理阅读计划文件（应在上下文中直接提供完整内容）
  • 忽略任务背景说明（子代理需要了解该任务所处的整体情境）
  • 对子代理的疑问置之不理（应在其继续工作前予以解答）
  • 对规范合规性仅满足“差不多”即可
  • 跳过审查循环（审核者发现问题 → 开发者修复 → 再次审核）
  • 用开发者自我审查替代正式审查（两者都是必要的）
  • 在规范合规性尚未通过时就开始代码质量审查（顺序错误）
  • 在任一审查环节仍有未解决问题时便进入下一个任务

问题处理方式

当子代理提出疑问时

  • 清晰且完整地予以解答
  • 如有需要，提供更多背景信息
  • 不要催促其立即开始开发

当审核者发现问题时

  • 由开发者子代理（或新的子代理）进行修复
  • 审核者再次进行审查
  • 重复此过程直至问题得到解决
  • 绝对不能跳过重新审查环节

当子代理无法完成任务时

  • 派遣新的修复子代理，并明确说明出错原因
  • 不要在控制器会话中尝试手动修复（以免造成上下文污染）

效率优化建议

为何每个任务都应使用新的子代理：

  • 避免因历史状态积累导致的上下文污染
  • 每个子代理都能获得清晰、专注的上下文环境
  • 避免受到之前任务代码或思路的干扰

为何采用两阶段审查机制：

  • 规范审查能及早发现功能实现不足或过度设计的问题
  • 质量审查可确保代码实现质量良好
  • 能在问题跨任务扩散之前及时发现

成本与效益的权衡：

  • 需要调用更多子代理（每个任务需1名开发者 + 2名审核者）
  • 但能及早发现问题（比日后修复复杂问题更为经济）

与其他技能的集成方式

与“计划”技能结合

该技能用于执行由plan技能生成的计划：

  1. 用户需求 → 计划方案 → 具体实现计划
  2. 实现计划 → 子代理驱动开发 → 可运行的代码

与测试驱动开发结合

开发者子代理应遵循TDD流程：

  1. 先编写无法通过的测试用例
  2. 编写最简化的代码实现
  3. 验证测试是否通过
  4. 提交代码

应在每个开发者子代理的上下文中包含TDD相关指导。

与“请求代码审查”技能结合

两阶段审查流程本身即构成代码审查。对于最终集成阶段的审查，可使用“请求代码审查”技能中的审查维度。

与系统化调试技能结合

如果子代理在开发过程中遇到错误：

  1. 按照系统化调试流程操作
  2. 在修复之前先找出根本原因
  3. 编写回归测试用例
  4. 继续进行开发工作

实际工作流程示例

[Read plan: docs/plans/auth-feature.md]
[Create todo list with 5 tasks]

--- Task 1: Create User model ---
[Dispatch implementer subagent]
  Implementer: "Should email be unique?"
  You: "Yes, email must be unique"
  Implementer: Implemented, 3/3 tests passing, committed.

[Dispatch spec reviewer]
  Spec reviewer: ✅ PASS — all requirements met

[Dispatch quality reviewer]
  Quality reviewer: ✅ APPROVED — clean code, good tests

[Mark Task 1 complete]

--- Task 2: Password hashing ---
[Dispatch implementer subagent]
  Implementer: No questions, implemented, 5/5 tests passing.

[Dispatch spec reviewer]
  Spec reviewer: ❌ Missing: password strength validation (spec says "min 8 chars")

[Implementer fixes]
  Implementer: Added validation, 7/7 tests passing.

[Dispatch spec reviewer again]
  Spec reviewer: ✅ PASS

[Dispatch quality reviewer]
  Quality reviewer: Important: Magic number 8, extract to constant
  Implementer: Extracted MIN_PASSWORD_LENGTH constant
  Quality reviewer: ✅ APPROVED

[Mark Task 2 complete]

... (continue for all tasks)

[After all tasks: dispatch final integration reviewer]
[Run full test suite: all passing]
[Done!]

请记住

Fresh subagent per task
Two-stage review every time
Spec compliance FIRST
Code quality SECOND
Never skip reviews
Catch issues early

卓越的品质并非偶然，而是系统化流程的必然结果。

进一步阅读（相关时加载）

当任务编排涉及大量上下文使用、漫长的审核循环或复杂的验证检查点时，请加载以下针对特定领域的参考资料：

  • references/context-budget-discipline.md — 四级上下文质量衰退模型（PEAK / GOOD / DEGRADING / POOR）、随上下文窗口大小变化的阅读深度规则，以及上下文质量隐性下降的早期预警信号。当任务明显会消耗大量上下文时（如多阶段计划、多个子智能体、大型输出文件），请加载此文档。
  • references/gates-taxonomy.md — 四种标准关卡类型（预检、修订、升级处理、中止），包括其运作机制、恢复策略及实际案例。在设计或审查包含验证检查点的任何工作流时，请加载此文档——明确使用相关术语，以便为每种关卡设定清晰的触发条件、失败处理方式及恢复规则。

以上两篇参考资料改编自 gsd-build/get-shit-done（MIT © 2025 Lex Christopherson）。