多代理常见的浪费，是每个代理都拿着同一段长提示词和仓库规则，一起去“帮忙写代码”。各自读需求、搜目录、猜风险，产物却拼不起来。看着很忙，其实都在重复付上下文税。

我现在更愿意按工作阶段分角色：规划代理只把模糊需求压成可验收的计划；实现代理只改它被分配的文件；验收代理不参与设计，专门尝试推翻结果。Claude Code 的子代理本来就在独立上下文里运行，适合把搜索、日志和大段中间材料留在主会话外。[1] 但“独立”不等于“随便分工”。角色之间没有输入和输出协议，隔离只会把混乱复制三份。

不要把一个万能 Skill 发给所有人#

Skill 适合装工序，不适合装部门介绍。一个 Skill 至少有 SKILL.md，可附带脚本、参考资料和资源；Claude Code 也支持在子代理配置里预加载 Skills。[2][3][1] 让规划、实现、验收各自只携带本阶段的检查表，别共享一份不断膨胀的 AGENTS.md。

规划代理只读代码、列假设、定义验收；实现代理按计划落盘并跑局部测试；验收代理从需求反查、检查 diff，默认不给写权限。写代码的人容易替自己的方案找理由，没参与实现的人更容易问“这个边界条件测过吗？”

一个经验是把 Skill 里的规则写成动作，而非人格。不要说“你是一位资深架构师”；写“输出不超过五步的计划，每步列目标文件、风险、验收命令”。子代理的最终回传是摘要，主会话不会保留它完整的推理和检索过程。[1] 因此输出格式比口号重要。主代理能否据此继续，取决于摘要里有没有路径、命令、失败条件和未解决项。

用文件当交接面，别靠聊天记录#

同一轮任务里，计划代理的产物应该是一个短文件，例如 .agent-runs/feature-123/plan.md。实现代理只读它，不从主对话重新解释需求；验收代理读取需求、计划和最终 diff，避免被实现代理的自我总结带偏。这个目录可以加入 .gitignore，因为它是过程记录，不是产品代码。

交接文件最好有固定字段：目标、非目标、允许改动的文件、验收命令、回滚点、未知项。没有“非目标”的计划常常会在实现时越界；没有“未知项”的计划则会把猜测伪装成结论。对于需要并行落盘的任务，再让每个实现代理使用独立 worktree。Claude Code 将 worktree 隔离列为并行工作方式之一，但工作区隔开并不能解决接口冲突，边界仍要先写进计划。[1]

我会给每个阶段加一个很小的完成条件。规划完成是每个步骤都有验证方式；实现完成是计划里的命令至少跑过一遍；验收完成是列出已验证项、没验证项和阻塞原因。验收失败时只报告，不顺手修，否则它又成了第二个实现代理，根因也丢了。

快速上手：三个角色，一条低风险流水线#

先在仓库创建三个 Skill 目录，再为每个子代理绑定一个。下面只会写本地文件；先把 .agent-runs/ 加进 .gitignore，避免交接记录混进提交：

mkdir -p .claude/skills/{feature-plan,feature-implement,feature-verify}
mkdir -p .agent-runs
printf '.agent-runs/\n' >> .gitignore

规划 Skill 的正文只保留交接要求。实现和验收 Skill 也照这个思路写，不要复制一整份项目手册：

<!-- .claude/skills/feature-plan/SKILL.md -->
---
name: feature-plan
description: 把一个明确功能拆成可执行计划；只读调查，不修改代码。
---

1. 读取需求和相关模块。
2. 写入 .agent-runs/$TASK/plan.md。
3. 每步列出目标文件、风险和验收命令。
4. 单列非目标与未知项；信息不足时停止，不猜测。

接着把计划代理设成只读，并预加载这个 Skill。字段名和可用工具以本机 Claude Code 版本为准；官方文档把 skills、tools 和权限模式都列为子代理可配置项。[1] 一个保守的示例是：

# .claude/agents/feature-planner.md
---
name: feature-planner
description: 为明确功能生成可验收的只读计划。
tools: Read, Grep, Glob, Bash
skills: feature-plan
---

只调查。把交接文件写到 .agent-runs/$TASK/plan.md，完成后报告路径。

实际调用时，把任务编号、边界和停止条件一次给全：使用 feature-planner 规划 TASK=feature-123；只检查 src/payments；不改代码；验收命令必须可本地执行。 计划出来后，主代理先读一遍 plan.md，确认没有越过边界，再叫实现代理。不要让实现代理直接接收“把功能做掉”这种原始需求，它会重新展开问题，前面的规划就白做了。

最后让验收代理只读检查：对照需求和计划，运行其中的验收命令，检查 git diff --check，再把“通过、失败、未覆盖”写进 .agent-runs/feature-123/verify.md。如果项目没有测试，明确记录没有测试，不要把“构建成功”写成“功能正确”。这种不够体面的结果反而最有用，它告诉你下一次该补的不是提示词，而是可执行验收。

什么时候别拆#

改一个文案、修一个明确的类型报错，拆三段通常比直接改更慢。值得拆的是跨模块改动、要读长日志的排障、或你希望连续运行几个小时的任务。还有，阶段多不代表并发多：规划和验收天然依赖前一阶段，硬并行只会制造过期输入。真正能并行的是边界互不重叠的实现任务，而且它们仍要共享同一份计划和验收口径。

角色 Skill、交接文件和完成条件合在一起，主代理才有地方做判断。它不必亲自吞下所有日志，也不用盲信某个子代理的“已完成”。

Sources#

[1] https://docs.anthropic.com/en/docs/claude-code/sub-agents — Claude Code Docs: Create custom subagents [2] https://docs.anthropic.com/en/docs/claude-code/skills — Claude Code Docs: Extend Claude with skills [3] https://agentskills.io/specification — Agent Skills Specification