4-Agent Pipeline：让 AI 团队在你睡觉时交付功能
四个专职 AI Agent 串联成 pipeline，通过交接文件自动传递信息——一个命令，四个阶段，一个完成的功能。
翻译
原文全文翻译，忠实于作者表述。
核心主张
四个 AI Agent 可以在你睡觉的时候交付一个完整功能。大多数人从来没把它们正确串联起来。
他们在这里触发一个 Reviewer，在那里触发一个测试生成器，手动一个个来，每个都忘了上一个干了什么。你仍然是瓶颈。
解决方案：Planner → Coder → Tester → Reviewer，自动交接、串联执行。一个触发器，四个阶段，到早上一个完成的功能。
One agent doing everything fills its context window with planning, code, tests, and review notes until quality drops.
一个 Agent 做所有事情——把规划、代码、测试和 review 笔记塞满自己的 context window，直到质量下降。
为什么 Pipeline 胜过散乱的 Agent
四个专家 Agent 各自保持干净、窄范围的 context。诀窍是交接文件（handoff file）。每个 Agent 把自己的输出写到下一个 Agent 能读到的地方：Planner 把 spec 放在 .pipeline/spec.md，Coder 读取它并把改动写在 .pipeline/changes.md，以此类推。
编排器（orchestrator）按顺序运行它们——就是一个 slash command。整个方案：四个 subagent，一个命令，一个共享文件夹做交接。
Opus
Sonnet
Sonnet
Opus
Planner（Opus）
永远不写代码。把模糊需求变成具体 spec。用 Opus 因为这个阶段设定了后续一切的质量天花板。模糊的 spec 产出的代码也是模糊的——不管 Coder 有多强。
Coder（Sonnet）
读取 spec 并编写实现。不规划，不审查自己——只按 spec 做事。Sonnet 在清晰 spec 下的实现工作性价比最高。.pipeline/changes.md 让 Tester 可以精确瞄准测试面。
Tester（Sonnet）
读取什么发生了变化，编写测试证明功能正常，然后运行它们。
Reviewer（Opus）
最后一道门。读取 pipeline 产出的所有内容，在任何代码进入 main 分支之前给出判定。Read-only 工具——只能评判，不能编辑。
编排器：/ship 命令
一个 slash command 按顺序调用四个 Agent，每个拾取上一个写的交接文件。一行命令启动整个链：
/ship add rate limiting to the login endpoint工程级解读
运行时模型、架构拆解、DIY 对比、选型决策。
这篇文章回答的问题：如何用四个专职 AI Agent 组成自动化 pipeline，在你睡觉时交付一个功能？
运行时模型
你的本地终端（Claude Code CLI）
└─ /ship slash command（orchestrator）
├─ spawn subagent: Planner (Opus)
│ └─ 写 .pipeline/spec.md
├─ spawn subagent: Coder (Sonnet) ← 顺序屏障
│ └─ 写 .pipeline/changes.md
├─ spawn subagent: Tester (Sonnet) ← 顺序屏障
│ └─ 写测试 + 运行结果
└─ spawn subagent: Reviewer (Opus) ← 顺序屏障
└─ 输出 verdict（只读）| 组件 | 职责 | 模型 | 工具权限 |
|---|---|---|---|
| Planner | 需求 → spec | Opus（质量天花板） | 读代码库 + 写 spec |
| Coder | spec → 实现 | Sonnet（性价比） | 读写代码 + 写 changes.md |
| Tester | changes → 测试 | Sonnet（性价比） | 读代码 + 写测试 + 运行 |
| Reviewer | 全部 → 判定 | Opus（判断力） | 只读 |
| Orchestrator | /ship → 串行调度 | 默认模型 | spawn subagents |
| Handoff Files | 进程间通信 | 文件系统 | .pipeline/ Markdown |
交接文件机制：核心创新
每个交接文件本质上是一个结构化约定（contract）：
- spec.md — 功能描述、边界条件、错误处理、接口设计
- changes.md — 修改了哪些文件、改了什么、为什么这么改
- 测试结果 — 覆盖率、哪些通过/失败
独立 Context Window
每个 Agent 只包含自己阶段需要的上下文 + 交接文件。前一个阶段的长对话历史不会污染当前阶段的注意力。
自然压缩
Planner 可能用了 50K tokens 讨论得出 spec，Coder 只需读 spec.md（可能 2K tokens）。信息在交接点被自然压缩。
持久化留痕
每个阶段的产出都是持久化的文件，可以随时检查和回溯。比内存中的上下文传递更可靠。
DIY 对比：手搓版 vs Pipeline
| 维度 | 手搓版 | Pipeline |
|---|---|---|
| 触发方式 | 手动复制粘贴 prompt | 一行 /ship 命令 |
| 上下文传递 | 自己读输出，手写下一个 prompt | 自动通过文件交接 |
| 错误恢复 | 自己判断哪阶段出问题 | 文件系统天然留痕 |
| Context 管理 | 自己记住每个 Agent 上下文 | 每个 Agent 干净启动 |
| 失败成本 | 你花时间协调 | 某阶段失败只影响后续未启动阶段 |
省的到底是什么？不是 AI 算力——四个 Agent 串行跑的总 token 消耗和一个 Agent 差不多。省的是你的协调成本和context window 的有效利用率。
选型决策框架
| 场景 | 该用吗 | 理由 |
|---|---|---|
| 单一明确功能（如加 rate limiting） | 非常适合 | 规划→实现→测试→审查的标准流程 |
| 探索性任务（"试试 X 方案"） | 不适合 | 规划阶段无法产出确定 spec |
| 跨多模块大型重构 | 谨慎使用 | 需拆分为多个 pipeline |
| Bug 修复 | 可简化 | Planner + Coder 两步即可 |
| 紧急 hotfix | 不适合 | Pipeline 保障质量而非速度 |
诚实限制
- 没有错误处理：Coder 产出有编译错误时 Tester 怎么处理？文章没说
- 没有回退路径：Reviewer 说"不通过"后怎么办？没有反馈循环
- 交接文件 schema 是隐式的：完全取决于 prompt，没有 formal schema
- 串行 = 慢：四个 Agent 串行跑，总时间 = 四者之和（12-20 min）
- Teamly 推广嫌疑：结尾明显转向广告，影响客观性
核心价值
- Context 隔离：每个 Agent 干净启动，不受前序阶段污染
- 信息压缩：交接文件天然压缩了每个阶段的思考过程
- 自动化编排：一行命令替代手动协调
- 可审计：每个阶段产出持久化，可回溯
- 模型选择合理：规划/评判用 Opus，执行用 Sonnet
金句
四个专家各守一个干净、窄范围的上下文。
Four specialists each stay in a clean, narrow context.
模糊的 spec 产出的代码也是模糊的——不管 Coder 有多强。
A vague spec produces vague code no matter how good the Coder is.
只读工具意味着 Reviewer 无法通过编辑来掩盖问题——它只能评判。
Read-only tools mean the Reviewer can't paper over problems by editing, it can only judge.
苏格拉底对话
关于 pipeline 架构本质的深层探讨。
个性化洞察
基于你的技术栈和 MiniAgent 项目，提炼可执行的发现。
1. MiniAgent 的 ContextPack 可以借鉴 handoff file 模式
MiniAgent 的 RuntimeSupervisor + EventStore 架构和 pipeline 在精神上一致——都是"先存储，再传递"。如果 MiniAgent 要支持链式 Agent（Codex → Claude 的 handoff），可以在 ContextPack 中增加类似 spec.md / changes.md 的结构化字段。
在 ContextPack schema 中增加 task_contract 字段，让 handoff 不只是上下文压缩，还包含明确的任务契约。
2. 你可以在 Claude Code 中立即实验
.claude/agents/ 和 .claude/commands/ 是 Claude Code 原生功能，不需要额外代码。创建四个 agent 定义文件 + 一个 ship 命令即可。你的 QA 背景让你天然适合评估 Tester 和 Reviewer 的输出质量。
选一个小功能（如给 MiniAgent 的某个 endpoint 加参数校验），跑一次完整 pipeline，评估 spec 质量和 Coder 的理解准确度。
3. Opus/Sonnet 分工策略值得应用到 MiniAgent
规划/评判用 Opus，执行用 Sonnet 的逻辑可以泛化——不同类型任务路由到不同能力的模型。MiniAgent 的 adapter 已经支持多模型，但还没有基于任务类型的智能路由。
在 MiniAgent 的 Task 模型中增加 complexity_tier 字段，让 RuntimeSupervisor 根据任务复杂度动态选择 adapter/model。
4. 文章缺少的失败模式正是你的机会
作为 QA 工程师，你应该立即注意到：没有错误恢复、没有重试、没有超时、没有成本上限。这些恰好是你比文章作者更有洞察的地方。
如果使用这个方案，至少增加：(a) 每阶段的超时和失败检测，(b) Tester 失败时回退 Coder 的条件分支，(c) token 成本追踪。
5. "睡觉时交付"需要打折
四个 Agent 串行跑，每个 3-5 分钟，总共 12-20 分钟——午休时间就够了。"睡觉时交付"是营销话术。真正适合过夜的场景是批量重复任务（如给 20 个 endpoint 加 rate limiting）。
把 pipeline 用在批量任务上，而不是单个功能。一个 /ship 命令可以循环调用多个 feature。