子智能体驱动开发

通过delegate_task子智能体执行计划（两阶段审查）。

技能元数据

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

---
title: "子智能体驱动的开发"
description: "通过分派独立子智能体执行实现计划，并进行系统性两阶段审查的技能"
slug: "subagent-driven-development"
---

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

# 子智能体驱动的开发

## 概述

通过为每个任务分派全新的子智能体并辅以系统性的两阶段审查来执行实现计划。

**核心原则：** 每个任务使用全新子智能体 + 两阶段审查（先规格合规性审查，再代码质量审查） = 高质量、快速迭代。

## 何时使用

当满足以下情况时使用此技能：
- 你有一个实现计划（来自写作计划技能或用户需求）
- 大多数任务是相互独立的
- 质量和规格合规性很重要
- 你希望在任务之间进行自动化审查

**与手动执行相比：**
- 每个任务拥有全新的上下文（不会因累积状态而产生混淆）
- 自动化的审查流程能早期发现问题
- 在所有任务间保持一致的质量检查
- 子智能体可以在开始工作前提出问题

## 流程

### 1. 阅读并解析计划

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

```python
# 阅读计划
read_file("docs/plans/feature-plan.md")

# 创建包含所有任务的待办事项列表
todo([
    {"id": "task-1", "content": "创建包含邮箱字段的用户模型", "status": "pending"},
    {"id": "task-2", "content": "添加密码哈希工具函数", "status": "pending"},
    {"id": "task-3", "content": "创建登录端点", "status": "pending"},
])

关键点： 只需阅读计划一次。提取所有内容。不要让子智能体去读计划文件——而是在上下文中直接提供完整的任务文本。

2. 每任务工作流

对于计划中的每个任务：

步骤 1：分派执行者子智能体

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

delegate_task(
    goal="执行任务 1：创建包含邮箱和密码哈希字段的用户模型",
    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

    检查项：
    - [ ] 是否遵循项目约定和风格？
    - [ ] 错误处理是否恰当？
    - [ ] 变量/函数名称是否清晰？
    - [ ] 测试覆盖是否充分？
    - [ ] 是否有明显错误或遗漏的边界情况？
    - [ ] 是否有安全问题？

    输出格式：
    - 关键问题：[继续前必须修复]
    - 重要问题：[应该修复]
    - 次要问题：[可选]
    - 结论：通过 (APPROVED) 或 需要修改 (REQUEST_CHANGES)
    """,
    toolsets=['file']
)

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

步骤 4：标记完成

todo([{"id": "task-1", "content": "创建包含邮箱字段的用户模型", "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 [feature name] implementation"

任务粒度

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

粒度太粗：

• "实现用户认证系统"

粒度合适：

• "创建包含邮箱和密码字段的用户模型"
• "添加密码哈希函数"
• "创建登录端点"
• "添加 JWT 令牌生成"
• "创建注册端点"

危险信号——绝对不要做

• 没有计划就开始实现
• 跳过审查（无论是规格合规性审查还是代码质量审查）
• 在存在未修复的关键/重要问题时继续推进
• 为涉及相同文件的任务分派多个执行者子智能体
• 让子智能体去读计划文件（应在上下文中提供完整文本）
• 忽略场景设置上下文（子智能体需要了解任务在整体中的位置）
• 忽略子智能体的问题（在让他们继续之前必须回答）
• 接受"差不多"的规格合规性
• 跳过审查循环（审查员发现问题 → 执行者修复 → 再次审查）
• 让执行者自我审查代替实际审查（两者都需要）
• 在规格合规性审查通过之前开始代码质量审查（顺序错误）
• 当任一审查存在未解决问题时继续下一个任务

问题处理

如果子智能体提出问题

• 清晰、完整地回答
• 如有需要，提供额外上下文
• 不要催促他们开始实现

如果审查员发现问题

• 执行者子智能体（或一个新的）负责修复
• 审查员再次审查
• 重复直到获得批准
• 不要跳过再次审查

如果子智能体任务失败

• 分派一个新的修复子智能体，并具体说明哪里出了问题
• 不要在控制会话中尝试手动修复（会导致上下文污染）

效率说明

为何每个任务使用全新子智能体：

• 防止累积状态造成的上下文污染
• 每个子智能体获得干净、专注的上下文
• 不会因先前任务的代码或推理而产生混淆

为何两阶段审查：

• 规格审查能早期发现构建不足或过度的问题
• 质量审查确保实现构建良好
• 在问题跨任务复合之前将其捕获

成本权衡：

• 更多的子智能体调用（每个任务有执行者 + 2 个审查员）
• 但能早期发现问题（比后期调试复合问题更便宜）

与其他技能的集成

与写作计划技能

此技能执行由写作计划技能创建的计划：

1. 用户需求 → 写作计划 → 实现计划
2. 实现计划 → 子智能体驱动开发 → 可运行的代码

与测试驱动开发

执行者子智能体应遵循 TDD：

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

在每个执行者的上下文中包含 TDD 指令。

与请求代码审查

两阶段审查过程本身就是代码审查。对于最终集成审查，请使用请求代码审查技能的审查维度。

与系统性调试

如果子智能体在实现过程中遇到错误：

1. 遵循系统性调试流程
2. 在修复前找到根本原因
3. 编写回归测试
4. 恢复实现

示例工作流

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

--- 任务 1：创建用户模型 ---
[分派执行者子智能体]
  执行者: "邮箱需要唯一吗？"
  你: "是的，邮箱必须唯一"
  执行者: 已实现，3/3 测试通过，已提交。

[分派规格审查员]
  规格审查员: ✅ 通过 — 所有需求已满足

[分派质量审查员]
  质量审查员: ✅ 批准 — 代码整洁，测试良好

[标记任务 1 完成]

--- 任务 2：密码哈希 ---
[分派执行者子智能体]
  执行者: 无问题，已实现，5/5 测试通过。

[分派规格审查员]
  规格审查员: ❌ 缺失：密码强度验证（规格要求“最少 8 个字符”）

[执行者修复]
  执行者: 已添加验证，7/7 测试通过。

[再次分派规格审查员]
  规格审查员: ✅ 通过

[分派质量审查员]
  质量审查员: 重要问题：魔数 8，应提取为常量
  执行者: 已提取 MIN_PASSWORD_LENGTH 常量
  质量审查员: ✅ 批准

[标记任务 2 完成]

...（对所有任务继续此流程）

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

每个任务使用独立的子智能体
每次进行两阶段评审
规范合规性优先
代码质量其次
评审绝不可跳过
及早发现问题

质量并非偶然，而是系统化流程的结果。

延伸阅读（相关时加载）

当编排过程涉及大量上下文消耗、冗长评审循环或复杂验证检查点时，请根据具体专业领域加载以下参考文献：

• references/context-budget-discipline.md — 四级上下文衰减模型（峰值/良好/衰减/低劣）、随上下文窗口规模缩放的阅读深度规则，以及静默衰减的早期预警信号。当一次运行明显会消耗大量上下文（多阶段计划、众多子智能体、大型产出物）时加载。
• references/gates-taxonomy.md — 四类标准关卡类型（预检、修订、升级、中止）及其行为、恢复机制与示例。在设计或评审任何设有验证检查点的工作流时加载——请明确使用此术语词汇表，以便每个关卡都有定义明确的进入条件、失败行为与恢复规则。

两份参考文献均改编自 gsd-build/get-shit-done（MIT © 2025 Lex Christopherson）。