睡着了也能上线功能：4 Agent 流水线架构

一个 Agent 打包所有事情——规划、写代码、写测试、写评审——上下文窗口迟早被撑满，质量随着 token 消耗一路下滑。大多数团队手动串 agent，每个环节靠人盯着，最终还是人在当瓶颈。

破局思路很简单：四个专职子 Agent，分别只做一件事，通过共享文件交接上下文，一条 slash 命令跑完整条流水线。

为什么是四个，而不是一个万能 Agent

单一 Agent 的问题不是能力不够，而是角色切换太频繁。规划时想的和写代码时想的不一样，写代码时和写测试时又不一样。每一次切换都在消耗上下文空间，同时产生大量中间噪音。

四个专职 Agent 各守一个窄而干净的上下文：

Planner 做规划，写规格说明，不碰代码
Coder 读规格说明，写实现，不评价自己
Tester 读变更记录，写测试，不改代码
Reviewer 读所有产出，给结论，不动手改

每个 Agent 都只知道自己该知道的，不多不少。

核心机制：handoff 文件

流水线运转的关键不是 Agent 本身，而是交接文件。每个 Agent 完成后把产出写到一个固定位置，下一个 Agent 从这里读取：

.pipeline/spec.md        ← Planner 输出
.pipeline/changes.md    ← Coder 输出
.pipeline/test-results.md ← Tester 输出
.pipeline/review.md     ← Reviewer 输出

Planner 写规格说明，Coder 按规格说明写代码并补充变更摘要，Tester 读变更摘要定向测试，Reviewer 读所有文件给出裁决。文件即接口，上一个 Agent 写什么，下一个 Agent 就只能读什么。

这种设计的直接效果：每个 Agent 的上下文始终是"干净的新工作"，不会累积规划噪音、评审噪音或者历史版本的干扰。

Planner：质量天花板的第一步

Planner 的职责是把模糊的功能需求转化为一篇可直接执行、无需追问的规格说明，包括：

需要创建或修改的具体文件路径
接口或函数签名
需要处理的边界情况
参照哪个现有文件遵循既有模式

规格说明开篇必须标注任何模糊之处，作为 OPEN QUESTIONS 留给人工确认，而不是让 Coder 瞎猜。

Planner 用 Opus 模型运行——规划阶段一旦含糊，后续所有环节都会放大这个含糊。Plan 烂，代码再好也是错的。

Coder：规格说明之外不多做

Coder 只做一件事：按规格说明实现，不多不少。它读 spec.md，遇到 OPEN QUESTIONS 就停下来汇报，不自行填补空白。

实现完成后，Coder 写一份简短的变更摘要到 changes.md：改了哪些文件、每个改动做了什么、Tester 需要重点关注什么。handoff note 是 Tester 的定向指南，没有它 Tester 就只能盲测。

Coder 用 Sonnet 模型——有明确规格说明的实现工作， Balanced Cost-Quality 的场景， Sonnet 性价比最高。

Tester：行为验证，不是实现检查

Tester 读 changes.md 定向找到需要测试的代码和区域，然后写覆盖三类场景的测试：

Happy path：主流程跑通
边界情况：规格说明中列出的 corner case
至少一个失败场景：确保测试本身有区分度

测试框架与仓库现有规范保持一致。测试写完后执行，任意一个失败就把结果写到 test-results.md 并暂停流水线——Tester 不修代码，只报告结果。

修代码是 Coder 的事，Test 把关，两者不能同一个人。

Reviewer：最后一道防线，只读不动手

Reviewer 读取规格说明、变更摘要、测试结果，然后运行 git diff 对照实际改动，给出裁决：

SHIP：所有检查通过，可以合并
NEEDS WORK：有问题但可快速修复
BLOCK：问题严重，必须打回重做

Reviewer 是只读角色——工具集中没有 Edit 或 Write，只有 Read、Grep、Glob、Bash。这意味着它无法靠悄悄改代码来掩盖问题，只能诚实给出判断。绿色测试不等于正确行为，这条原则在这里被强制执行。

Reviewer 也用 Opus，因为这个阶段需要最强的推理判断能力，代价最高但最值得。

编排层：一条命令启动整条流水线

把四个 Agent 串联起来的不是什么复杂的调度系统，而是一个 slash command：

/ship add rate limiting to the login endpoint

这条命令依次：

调用 planner 子 Agent，等待 .pipeline/spec.md 生成
检查是否有 OPEN QUESTIONS，有则停止并展示问题
调用 coder 子 Agent，等待 .pipeline/changes.md 生成
调用 tester 子 Agent，等待 .pipeline/test-results.md 生成；测试失败则停止
调用 reviewer 子 Agent，读取 .pipeline/review.md 并展示最终裁决

一条命令，四个阶段，不用人在中间盯着。睡前触发，天亮读裁决。

从 2 到 4：渐进式构建

不要一上来就建完整条流水线。作者的建议是：先跑通 Planner + Coder 的两阶段链，等这个 flow 稳定了，再加入 Tester 和 Reviewer。

为什么这样分步？因为前两个阶段最容易验证——规格说明写得好不好，看 Coder 的输出就知道。等两阶段稳固了，加测试和评审才不会引入额外的干扰项。

关键心得

四个 Agent 通过共享文件交接上下文，避免了单一 Agent 上下文窗口爆炸的问题。每一步的输出文件定义了 Agent 之间的接口边界，文件即契约，写什么只能读什么。

Reviewer 只读不动手是这条流水线的安全保障：它不能悄悄改代码来让测试变绿，只能诚实给出 BLOCK 或 SHIP 的判断。

整体架构的精髓总结一句话：handoff 文件定义边界，slash 命令定义顺序，Reviewer 定义出口。