子代理驱动开发 — 通过 delegate_task 子代理执行计划（两阶段审查）

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

子代理驱动开发

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

技能元数据

来源	内置（默认已安装）
路径	skills/software-development/subagent-driven-development
版本	1.1.0
作者	Hermes Agent（改编自 obra/superpowers）
许可证	MIT
平台	linux, macos, windows
标签	delegation、subagent、implementation、workflow、parallel
相关技能	writing-plans、requesting-code-review、test-driven-development

参考：完整 SKILL.md

:::info 以下是当此技能被触发时 Hermes 加载的完整技能定义。这是技能激活时代理所看到的指令。 :::

子代理驱动开发

概述

通过为每个任务分派全新的子代理并执行系统性的两阶段审查来执行实施计划。

核心原则： 每个任务使用全新子代理 + 两阶段审查（规范审查，然后质量审查）= 高质量、快速迭代。

何时使用

使用此技能当：

• 你有一个实施计划（来自 writing-plans 技能或用户需求）
• 任务基本独立
• 质量和规范符合性很重要
• 你希望在任务之间进行自动化审查

与手动执行对比：

• 每个任务使用新上下文（不会因累积状态而产生混淆）
• 自动化审查流程及早发现问题
• 所有任务的一致质量检查
• 子代理可以在开始工作前提问

流程

1. 阅读和解析计划

读取计划文件。一次性提取所有任务及其完整文本和上下文。创建待办事项列表：

# 读取计划
read_file("docs/plans/feature-plan.md")
 
# 创建包含所有任务的待办事项列表
todo([
    {"id": "task-1", "content": "创建包含 email 字段的 User 模型", "status": "pending"},
    {"id": "task-2", "content": "添加密码哈希工具", "status": "pending"},
    {"id": "task-3", "content": "创建登录端点", "status": "pending"},
])

关键： 一次性读取计划。提取所有内容。不要让子代理读取计划文件——直接在上下文中提供完整的任务文本。

2. 每个任务的工作流

对于计划中的每个任务：

步骤 1：分派实施子代理

使用 delegate_task 并提供完整上下文：

delegate_task(
    goal="实现任务 1：创建包含 email 和 password_hash 字段的 User 模型",
    context="""
    计划中的任务：
    - 创建：src/models/user.py
    - 添加 User 类，包含 email（str）和 password_hash（str）字段
    - 使用 bcrypt 进行密码哈希
    - 包含 __repr__ 用于调试
 
    遵循 TDD：
    1. 在 tests/models/test_user.py 中编写失败的测试
    2. 运行：pytest tests/models/test_user.py -v（验证失败）
    3. 编写最小实现
    4. 运行：pytest tests/models/test_user.py -v（验证通过）
    5. 运行：pytest tests/ -q（验证无回归）
    6. 提交：git add -A && git commit -m "feat: add User model with password hashing"
 
    项目上下文：
    - Python 3.11，Flask 应用位于 src/app.py
    - 现有模型位于 src/models/
    - 测试使用 pytest，从项目根目录运行
    - bcrypt 已在 requirements.txt 中
    """,
    toolsets=['terminal', 'file']
)

步骤 2：分派规范符合性审查者

实施者完成后，对照原始规范进行验证：

delegate_task(
    goal="审查实现是否与计划中的规范匹配",
    context="""
    原始任务规范：
    - 创建 src/models/user.py，包含 User 类
    - 字段：email（str）、password_hash（str）
    - 使用 bcrypt 进行密码哈希
    - 包含 __repr__
 
    检查项：
    - [ ] 规范中的所有需求都已实现？
    - [ ] 文件路径与规范匹配？
    - [ ] 函数签名与规范匹配？
    - [ ] 行为符合预期？
    - [ ] 没有添加额外内容（无范围蔓延）？
 
    输出：PASS 或需要修复的具体规范差距列表。
    """,
    toolsets=['file']
)

如果发现规范问题： 修复差距，然后重新运行规范审查。仅在符合规范后继续。

步骤 3：分派代码质量审查者

在规范符合性通过后：

delegate_task(
    goal="审查任务 1 实现的代码质量",
    context="""
    要审查的文件：
    - src/models/user.py
    - tests/models/test_user.py
 
    检查项：
    - [ ] 遵循项目约定和风格？
    - [ ] 适当的错误处理？
    - [ ] 清晰的变量/函数命名？
    - [ ] 充分的测试覆盖？
    - [ ] 没有明显的 bug 或遗漏的边缘情况？
    - [ ] 没有安全问题？
 
    输出格式：
    - 关键问题：[必须在继续前修复]
    - 重要问题：[应该修复]
    - 次要问题：[可选]
    - 结论：APPROVED 或 REQUEST_CHANGES
    """,
    toolsets=['file']
)

如果发现质量问题： 修复问题，重新审查。仅在批准后继续。

步骤 4：标记完成

todo([{"id": "task-1", "content": "创建包含 email 字段的 User 模型", "status": "completed"}], merge=True)

3. 最终审查

在所有任务完成后，分派最终的集成审查者：

delegate_task(
    goal="审查整个实现的一致性和集成问题",
    context="""
    计划中的所有任务已完成。审查完整实现：
    - 所有组件是否能协同工作？
    - 任务之间是否存在不一致？
    - 所有测试是否通过？
    - 是否已准备好合并？
    """,
    toolsets=['terminal', 'file']
)

4. 验证和提交

# 运行完整测试套件
pytest tests/ -q
 
# 审查所有更改
git diff --stat
 
# 最终提交
git add -A && git commit -m "feat: complete [功能名称] implementation"

任务粒度

每个任务 = 2-5 分钟的集中工作。

太大：

• “实现用户认证系统”

合适的规模：

• “创建包含 email 和 password 字段的 User 模型”
• “添加密码哈希函数”
• “创建登录端点”
• “添加 JWT Token 生成”
• “创建注册端点”

危险信号——绝对不要做这些

• 没有计划就开始实施
• 跳过审查（规范符合性 OR 代码质量）
• 在存在未修复的关键/重要问题时继续
• 为涉及相同文件的任务分派多个实施子代理
• 让子代理读取计划文件（改为在上下文中提供完整文本）
• 跳过场景设置上下文（子代理需要理解任务在整体中的位置）
• 忽略子代理的问题（在让他们继续之前回答）
• 对规范符合性采取”差不多就行”的态度
• 跳过审查循环（审查者发现问题 → 实施者修复 → 再次审查）
• 让实施者自我审查替代实际审查（两者都需要）
• 在规范符合性通过之前开始代码质量审查（顺序错误）
• 在任一审查存在未解决问题时移动到下一个任务

处理问题

如果子代理提问

• 清晰且完整地回答
• 如果需要，提供额外上下文
• 不要催促他们进行实施

如果审查者发现问题

• 实施者子代理（或新的子代理）修复它们
• 审查者再次审查
• 重复直到批准
• 不要跳过重新审查

如果子代理未能完成任务

• 分派一个新的修复子代理，附带关于问题所在的明确说明
• 不要尝试在控制者会话中手动修复（上下文污染）

效率说明

为什么每个任务使用全新子代理：

• 防止累积状态导致的上下文污染
• 每个子代理获得干净、集中的上下文
• 不会因先前任务的代码或推理而产生混淆

为什么两阶段审查：

• 规范审查及早发现过度/不足构建
• 质量审查确保实现构建良好
• 在问题跨任务累积之前捕获它们

成本权衡：

• 更多的子代理调用（每个任务 1 个实施者 + 2 个审查者）
• 但能及早发现问题（比调试后来累积的问题更便宜）

与其他技能的集成

与 writing-plans 配合

此技能执行由 writing-plans 技能创建的计划：

1. 用户需求 → writing-plans → 实施计划
2. 实施计划 → 子代理驱动开发 → 工作代码

与 test-driven-development 配合

实施子代理应遵循 TDD：

1. 先编写失败的测试
2. 实现最小代码
3. 验证测试通过
4. 提交

在每个实施者上下文中包含 TDD 指令。

与 requesting-code-review 配合

两阶段审查过程就是代码审查。对于最终集成审查，使用 requesting-code-review 技能的审查维度。

与 systematic-debugging 配合

如果子代理在实施过程中遇到 bug：

1. 遵循 systematic-debugging 流程
2. 在修复之前找到根本原因
3. 编写回归测试
4. 恢复实施

示例工作流

[读取计划：docs/plans/auth-feature.md]
[创建包含 5 个任务的待办事项列表]

--- 任务 1：创建 User 模型 ---
[分派实施子代理]
  实施者："email 应该是唯一的吗？"
  你："是的，email 必须是唯一的"
  实施者：已实现，3/3 测试通过，已提交。

[分派规范审查者]
  规范审查者：✅ PASS——所有需求已满足

[分派质量审查者]
  质量审查者：✅ APPROVED——代码清晰，测试良好

[标记任务 1 完成]

--- 任务 2：密码哈希 ---
[分派实施子代理]
  实施者：无问题，已实现，5/5 测试通过。

[分派规范审查者]
  规范审查者：❌ 缺少：密码强度验证（规范说"至少 8 个字符"）

[实施者修复]
  实施者：已添加验证，7/7 测试通过。

[再次分派规范审查者]
  规范审查者：✅ PASS

[分派质量审查者]
  质量审查者：重要：魔法数字 8，提取为常量
  实施者：已提取 MIN_PASSWORD_LENGTH 常量
  质量审查者：✅ APPROVED

[标记任务 2 完成]

...（对所有任务继续）

[所有任务完成后：分派最终集成审查者]
[运行完整测试套件：全部通过]
[完成！]

记住

每个任务使用全新子代理
每次都进行两阶段审查
规范符合性优先
代码质量其次
绝不跳过审查
及早发现问题

质量不是偶然。它是系统化流程的结果。

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

当编排涉及大量上下文使用、长审查循环或复杂验证检查点时，加载这些参考资料以获取具体指导：

• references/context-budget-discipline.md — 四级上下文退化模型（PEAK / GOOD / DEGRADING / POOR）、随上下文窗口大小扩展的阅读深度规则，以及静默退化的早期预警信号。当一次运行将消耗大量上下文时加载（多阶段计划、许多子代理、大型产出物）。
• references/gates-taxonomy.md — 四种规范门类型（Pre-flight、Revision、Escalation、Abort），包含行为、恢复方法和示例。在设计或审查任何具有验证检查点的工作流时加载——明确使用此词汇表，以便每个门都有定义的入口、失败行为和恢复规则。

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