用途
code-subagents 是一套“实现类子智能体调度模式”，用于在任务的设计已经确定、文件只需被创建出来，或存在可独立完成的实现工作时，指导如何派发子智能体。它的基本节奏是：每个任务使用一个全新的子智能体，每完成一批任务做一次合并审查；任务相互独立时并行派发，存在依赖时串行执行。
何时使用子智能体
资料指出，以下条件必须全部满足才使用子智能体：
- 设计已确定：计划或 design.md 已经明确文件应包含什么（类型、签名、schema、契约，或一个可照抄的既有模式）。
- 工作项有明确需求、归属文件和验证命令。
- 它不与其他进行中的工作共享文件或状态。
最典型的候选是：新文件、脚手架、样板代码，以及遵循既有模式的编辑。并行是另一个问题：只有当独立性检查通过时，才并发派发两个或更多符合条件的工作项。
以下情况不要使用：
- 任务紧耦合（编辑同一批文件）。
- 需要理解跨任务的完整系统状态。
- 失败彼此相关（修好一个可能顺带修好其他）。
- 问题尚未明确定义的探索性工作。
派发模式
串行（有依赖的任务）
有依赖的任务一次执行一个，每个任务获得一个全新子智能体，避免前序任务的上下文污染。示例流程为：任务 1（Entity）→ 审查 → 完成；任务 2（Repository，依赖 T1）→ 审查 → 完成；任务 3（Service，依赖 T2）→ 审查 → 完成。
并行（独立任务）
独立任务同时派发，每个问题域一个智能体。示例为：任务 A（auth 测试）、任务 B（billing 测试）、任务 C（notification 测试）并发执行，各自审查后完成。
独立性检查：修复任务 A 是否会影响任务 B？它们是否会编辑同一批文件？如果两者答案都是否，就并行派发。
对于共享代码树的并行工作，资料要求：
- 派发前为每个任务分配独占文件列表。
- 不要让实现者暂存或提交变更。
- 在每个任务前后捕获完整 git status，包括未跟踪文件。
- 捕获该任务的路径范围补丁，并拒绝其分配路径之外的改动。
- 如果文件归属重叠或无法隔离，则改为串行执行。
智能体选择
不要指定智能体名称；由执行框架选择描述最匹配该工作的可用智能体（参见 atelier-orchestrator 中的 Delegation）。给实现者提供设计摘录，使其不做设计决策：机械式文件创建应匹配脚手架类智能体，设计敏感的实现应匹配执行框架的通用写作类智能体。批次审查者是只读的批判性审查。
提示词模板
派发子智能体时使用以下模板。资料强调每个模板都经过实战检验，不要即兴发挥，按原样使用并填入变量：
- references/implementor-prompt.md —— 派发实现者，包含自审清单。
- references/batch-reviewer-prompt.md —— 针对一个已完成批次的计划与代码质量合并审查。
提示词质量规则：
- 聚焦——一个任务，一个问题域。
- 自包含——所需上下文都在提示词中，提供完整工作项需求，不要让子智能体自行恢复上下文。
- 文件具体——给出确切路径，而不是“相关文件”。
- 输出具体——子智能体应返回什么。
- 有约束——明确不应触碰什么。
常见错误与修正：
- “修复所有测试” → “修复 user.test.ts 中的 3 个失败”。
- 没有代码库上下文 → 粘贴相关模式与约定。
- 没有约束 → “不要修改生产代码”或限定到具体文件。
- 输出期望模糊 → “返回：根因、所做修改、测试结果”。
批次审查
每完成一个批次后运行一次合并审查，而不是为每个任务单独审查。给一位全新审查者提供：该批次工作项的完整需求、相关约束、为每个任务捕获的路径范围补丁、完整变更文件清单（含未跟踪文件）、实现者的报告与验证结果。
审查者同时检查需求符合度与代码质量：
- 每条需求与验收标准都已实现。
- 批次遵循给定约束。
- 没有未请求的工作或范围外文件。
- 测试有意义并覆盖正确边界。
- 代码遵循既有模式，没有不必要的复杂度。
按原样使用 references/batch-reviewer-prompt.md。如果审查者发现 Critical 或 Important 问题，把每个问题发回相关实现者，刷新其路径范围补丁，并再次审查该批次。Minor 问题可以记录后略过。
处理子智能体的提问
子智能体可能在实现前或实现中提问，这是好事，说明它们在思考而非猜测。应清晰完整地回答，必要时提供额外上下文，不要催促它们进入实现。如果问题暴露出计划中的缺口，那是有价值的，应记录下来。
整合结果
子智能体完成后（尤其是并行派发后）：
- 阅读每份摘要，理解改了什么。
- 捕获任务补丁，使用每个任务的独占文件列表。
- 审查批次，做一次合并的需求与质量审查。
- 运行完整测试套件，验证所有改动协同工作。
- 提交，由协调者串行提交已审查的批次。
- 更新进度跟踪（当调用方使用时）。
如果并行结果之间存在冲突，手动解决。不要派发另一个子智能体去合并——那需要过多上下文。
子智能体失败时
如果子智能体任务失败：
- 不要手动修复——那会污染你的上下文。
- 派发一个修复子智能体，给出关于哪里出错的明确指示。
- 如果失败两次，停止并升级给人类。需求或约束可能需要修订。
限制
资料未提供该模式的收费、价格、平台支持范围或具体效果数据，这些事实暂未提供。