子智能体驱动开发

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

技能元数据

来源	内置（默认安装）
路径	skills/software-development/subagent-driven-development
版本	1.1.0
作者	Hermes 智能体（改编自 obra/superpowers）
许可	MIT
平台	linux, macos, windows
标签	委派, 子智能体, 实现, 工作流, 并行
相关技能	编写计划, 请求代码审查, 测试驱动开发

信息

以下是 Hermes 在触发此技能时加载的完整技能定义。这是智能体在技能处于活动状态时看到的指令。

子智能体驱动开发

概述

通过为每个任务派遣新的子智能体并执行系统化两阶段审查来执行实施计划。

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

何时使用

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

• 您有一个实施计划（来自编写计划技能或用户需求）
• 任务大多是独立的
• 规格符合性和质量很重要
• 您希望在任务之间进行自动化审查

与手动执行相比：

• 每个任务都有新上下文（避免因累积状态而产生混淆）
• 自动化审查流程可以尽早发现问题
• 所有任务都有质量检查的一致性
• 子智能体可以在开始工作前提出问题

流程

1. 读取并解析计划

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

# 读取计划
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：创建包含 email 和 password_hash 字段的用户模型",
    context="""
    计划中的任务：
    - 创建：src/models/user.py
    - 添加包含 email (str) 和 password_hash (str) 字段的 User 类
    - 使用 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: 添加包含密码哈希的用户模型"

    项目上下文：
    - 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: 完成 [功能名称] 实现"

任务粒度

每个任务 = 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 完成]

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

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

---
title: "智能体编排详解"
description: "智能体系统的编排模式、工作流设计与最佳实践"
slug: "agent-orchestration"
---

## 记住

每个任务使用全新的智能体 每次都要进行两阶段审查 规范合规性优先 代码质量其次 绝不跳过审查 尽早发现问题

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

## 延伸阅读（按需加载）

当编排涉及显著的上下文使用量、较长的审查循环或复杂的验证检查点时，请为具体学科加载以下参考资料：

- **`references/context-budget-discipline.md`** — 四层上下文退化模型（PEAK / GOOD / DEGRADING / POOR），随上下文窗口大小缩放的阅读深度规则，以及无声退化的早期预警信号。当一次运行明显消耗大量上下文时（多阶段计划、多个智能体、大型产出物）加载。
- **`references/gates-taxonomy.md`** — 四种规范的检查点类型（预检、修订、升级、中止），包含行为、恢复和示例。在设计或审查任何带有验证检查点的工作流时加载——明确使用该词汇，以便每个检查点都有定义的进入、失败行为和恢复规则。

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