四个 AI agent 接力，能在用户睡觉时把一个 feature 完整做出来。
大多数人尝试过 subagent，但从来没有真的把它们连成流水线——他们手动调 reviewer、手动调 test generator、一个接一个，每个都忘了上一个做了什么。用户仍然是瓶颈。
darkzodchi 给的方案是：Planner → Coder → Tester → Reviewer，handoff 文件串联，一个 slash command 触发整条链。
4 个 agent 而不是 1 个
为什么不是一个 agent 做所有事？
因为单个 agent 干所有事会让 context window 被填满：
- 规划思路
- 改的代码
- 写的测试
- review 备注
context 满了之后，模型质量会下降——它会忘早期约束、混淆不同任务的状态、做"自作主张"的判断。
4 个 specialist 各自有干净的、窄的 context。这是流水线比"一个超级 agent"好的根本原因。
关键设计：Handoff 文件
4 个 agent 不是"互相调用"——它们通过文件系统交接。
.pipeline/
├── spec.md # Planner 写
├── changes.md # Coder 写
├── test-results.md # Tester 写
└── review.md # Reviewer 写
每个 agent 只读上一个 agent 写的文件，然后写自己的输出。Handoff 文件就是 agent 之间的契约。
这个设计为什么好？ 因为 context window 不能跨 agent 共享，但文件系统可以。把交接内容写到磁盘，等于显式序列化 agent 之间的状态——下一个 agent 不需要在前一个 agent 的"记忆"里找信息，只需要读一个文件。
第一个 agent：Planner（用 Opus）
Planner 永远不写代码。它把一个模糊的 feature request 转成具体的 spec，Coder 可以照着做而不需要猜测。
配置示例（.claude/agents/planner.md）：
---
name: planner
description: Turns a feature request into an implementation spec. Use as the first stage of the feature pipeline.
tools: Read, Grep, Glob, Write
model: opus
---
You are a planning specialist. You do NOT write implementation code.
Given a feature request:
1. Read the relevant parts of the codebase to understand current patterns.
2. Write a spec to `.pipeline/spec.md` containing:
- Files to create or modify, with exact paths
- The interface or function signatures needed
- Edge cases the implementation must handle
- Which existing patterns to follow (name the file to copy from)
3. Flag anything ambiguous as an OPEN QUESTION at the top of the spec.
Keep the spec tight. The Coder reads this and nothing else, so leave
no gaps and invent no requirements that weren't asked for.
关键设计：
- Plannaer 用 Opus——这阶段定下"质量天花板"。spec 写得模糊，后面所有阶段都跟着模糊。用 Opus 是值得的。
- Plannaer 不写代码——硬规则，避免它"顺手实现一下"。
- OPEN QUESTIONS 标记在 spec 顶部——Coder 看到就停下问用户，而不是猜测。
第二个 agent：Coder（用 Sonnet）
Coder 读 spec，写实现。不规划，也不 review 自己的代码——只按 spec 写。
---
name: coder
description: Implements the spec at .pipeline/spec.md. Use as the second stage of the feature pipeline, after the planner.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---
You are an implementation specialist.
1. Read `.pipeline/spec.md` in full. If it has OPEN QUESTIONS, stop and
surface them instead of guessing.
2. Implement exactly what the spec describes. Follow the patterns it
names. Do not add features it didn't ask for.
3. Write a short summary to `.pipeline/changes.md`: which files changed,
what each change does, and anything the Tester should focus on.
关键设计：
- Coder 用 Sonnet——"按清晰的 spec 写实现"是 Sonnet 最擅长的事。用 Opus 浪费。
- 如果 spec 有 OPEN QUESTIONS，Coder 必须停下——避免猜测式实现（猜测产生的代码最难 debug）。
- Coder 写 changes.md 告诉 Tester 改了什么——这让 Tester 不需要"读全部 diff 才能知道该测哪里"。
第三个 agent：Tester（用 Sonnet）
Tester 读 changes，写测试，跑测试。
---
name: tester
description: Writes and runs tests for changes described in .pipeline/changes.md. Third stage of the feature pipeline.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---
You are a test specialist.
1. Read `.pipeline/changes.md` to see what was built and where.
2. Read the changed files and the spec at `.pipeline/spec.md`.
3. Write tests covering: the happy path, the edge cases the spec named,
and at least one failure case. Match the repo's test framework.
4. Run the tests. If any fail, write the failures to
`.pipeline/test-results.md` and STOP. Do not fix the code yourself.
5. If all pass, note that in `.pipeline/test-results.md`.
关键设计：
- Tester 失败不修代码——它只报告"哪个 case 失败、为什么"。修代码是 Coder 的事，Tester 不做修复是分权。
- 必须写"失败 case"——只测 happy path 的测试覆盖是假的。
第四个 agent：Reviewer（用 Opus，只读）
Reviewer 是最后一道闸门。只读，不改代码。
---
name: reviewer
description: Final review of the full pipeline output. Fourth and last stage before human sign-off.
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior reviewer. You are read-only. You do not edit code.
1. Read the spec, the changes summary, and the test results from
`.pipeline/`.
2. Run `git diff` to see the actual changes.
3. Assess: does the code match the spec? Are the tests meaningful or
superficial? Any security, performance, or correctness issues?
4. Write a verdict to `.pipeline/review.md`:
- VERDICT: SHIP / NEEDS WORK / BLOCK
- For NEEDS WORK or BLOCK, list exactly what to fix and where.
关键设计：
- Reviewer 用 Opus——判断力比速度重要。
- Reviewer 工具集只有 Read 类——结构上禁止它编辑代码，避免"review 时顺手改一下"的诱惑。
- VERDICT 三档：SHIP / NEEDS WORK / BLOCK——这是给用户的清晰信号。
触发器：Slash Command
一个 slash command 把 4 个 agent 串起来：
.claude/commands/ship.md：
Run the full feature pipeline for: $ARGUMENTS
Execute these stages in order. Do not skip ahead. After each stage,
confirm the handoff file exists before starting the next.
1. Delegate to the `planner` subagent with the feature request above.
Wait for `.pipeline/spec.md`.
2. If the spec has OPEN QUESTIONS, stop and show them to me. Otherwise
delegate to the `coder` subagent. Wait for `.pipeline/changes.md`.
3. Delegate to the `tester` subagent. Wait for `.pipeline/test-results.md`.
If tests failed, stop and show me the failures.
4. Delegate to the `reviewer` subagent. Show me `.pipeline/review.md`.
Report the final verdict. Do not merge anything. Leave the branch for
my morning review.
然后一行触发整条链：
/ship add rate limiting to the login endpoint
睡前触发，醒来读 verdict。
推广判断
这篇 post 末尾推荐了 Teamly（$29/月 for 5 agents）——它的"Coordinator"功能跟 darkzodchi 手搓的 handoff 文件本质相同，只是把"自己写 handoff 协议"换成"用平台做"。
要不要接 Teamly 这种产品？ 取决于：
- 已经能跑通 4-agent 流水线 → 不需要，Handoff 文件就是全部机制
- 想要 24/7 跑、跨人协作、多 agent 类型（不只是 code） → 可能值得尝试 Teamly 的"marketing team / research team"模式
但核心架构是 handoff 文件 + 串行 orchestrator——这个思路不会变。Teamly 只是把它产品化。
诚实说不适合谁
- 单人小项目（< 10k 行代码）→ 4-agent 流水线过度工程
- 高度依赖 GUI / 设计稿的 feature（前端交互）→ 流水线生成的前端代码 review 通过率低，不如手动
- 需要强领域知识（金融、医疗）→ Planner 写不出准确 spec，整个流水线崩
- Subagent 不熟 → 先用 2 个（Planner + Coder）跑通，再加 Tester，再加 Reviewer
darkzodchi 没说的两件事
1. Handoff 文件格式是 implicit contract——.pipeline/spec.md、changes.md 这些文件的具体 schema 没有标准化。两个 agent 之间的"什么算有效 handoff"是写 agent prompt 时手调的。这意味着改一个 agent 的输出格式可能悄悄破坏下游——没有类型系统保护。
2. 串行不是唯一选择——4 个 agent 也可以并行：planner 完成后，3 个 coder 同时改 3 个文件，tester 跑 3 套测试，reviewer 综合判断。串行 vs 并行的取舍是 latency vs 一致性。darkzodchi 默认串行是因为简单，并行需要处理 conflict resolution（如果两个 coder 改同一个文件怎么办），这套机制没给。
结论
4-agent 流水线的本质是用文件系统替代 context 共享。每个 agent 读上一个 agent 写的文件，写自己的输出文件。Handoff 文件是契约，slash command 是 orchestrator，4 个 subagent 是工人。
SOTA Sync 的判断："agent 之间的 handoff"会成为 agent 工程的下一个范式。单 agent 工具的天花板已经被 context window 卡住了——4-agent 流水线是绕过的方式。
但真正的下一道关卡是 handoff 的 schema 标准化。当前每个团队都自己设计 handoff 格式（spec.md / changes.md / test-results.md / review.md），没有跨工具的协议。这是 Agent Protocol 未来 12 个月会冒出来的标准机会。