4-Agent Pipeline: The Seductive Trap of "Ship While You Sleep"
四个 AI Agent 组成的 Planner-Coder-Tester-Reviewer 流水线，听起来像梦寐以求的 "睡觉也在发货" — 但它真正擅长的是小任务，遇到复杂项目就像用纸糊的水坝挡洪水。
速览
30 秒掌握全局。
@zodchiii (darkzodchi)
2026 年 5 月 30 日发布于 X 长文。一个 slash command /ship 触发四个 Claude Code subagent 串行执行，早上收货。
Planner → Coder → Tester → Reviewer
Opus x2（规划+审查）+ Sonnet x2（编码+测试）。交接机制：文件系统 .pipeline/ 目录。
内容营销漏斗
文末推广 Teamly（AI Agent 托管平台）。Teamly 不出现在任何主流 AI Agent 平台对比文章中。技术干货建立信任 → 产品推荐收割流量。
NeurIPS 2025 论文
从 1,600+ traces 中识别出 14 种 multi-agent 失败模式（kappa=0.88）。社区互动：~1,047 likes / 116 reposts。
| 维度 | 数据 |
|---|---|
| Pipeline 阶段 | 4（Planner→Coder→Tester→Reviewer） |
| 模型分配 | Opus x2（规划+审查）+ Sonnet x2（编码+测试） |
| Token 成本倍数 | 单次 4-7x 基线；重跑可达 16-28x |
| 简单任务成功率 | ChatDev 76 秒生成 Snake（第二次尝试） |
| 复杂任务表现 | 10 entity CRUD 耗时 4-5 小时，频繁人工干预 |
| SWE-bench 最前沿 | Opus 4.6 = 80.8%，仍有 ~20% gap |
| 学术失败分类 | 14 种，跨 3 大类，1,600+ traces（kappa=0.88） |
原文在说什么
Planner-Coder-Tester-Reviewer 四角色串行 pipeline，各司其职。
Planner (Opus)
把模糊需求翻译成结构化 spec，写入 .pipeline/spec.md。不写代码，只做规划。"这个阶段设定了后续一切的质量天花板。"
Coder (Sonnet)
读取 spec，写实现，产出 .pipeline/changes.md。不规划，不审查——只按 spec 干活。Sonnet 在清晰 spec 下的性价比最高。
Tester (Sonnet)
读取改动，写测试，跑测试。与 Coder 同模型，但独立 context window。
Reviewer (Opus)
读取所有产出物，给 pass/fail 判定。关键约束：read-only 工具——只能评判，不能改代码。防止 "顺手修 bug" 反而搞砸。
论证逻辑
核心论点：context window 污染是单 Agent 的致命伤。一个 Agent 做规划+编码+测试+审查，到审查阶段时早已忘了规划时为什么做了某些决策。四个 Agent 各自保持干净的窄 context，质量更高。
这个论点有真实内核。Context window 确实会随着任务累积而稀释有效注意力。但文章把 "问题真实" 等同于 "解决方案有效"，跳过了中间的验证步骤。
数据校验: 原文称 Teamly 支持 "2-4 agents" 团队规模。核实发现 Teamly 实际计划为 5、15、30 agents。"2-4 agents" 描述的是作者推荐的 pipeline 大小（4 agents / 5 可用），不是平台能力。
关键概念速查
理解文章的技术基石。
| 术语 | 解释 | 为什么重要 |
|---|---|---|
| Handoff File | Agent 间通过文件系统传递结构化产出。本质是信息压缩——Planner 可能用 50K tokens 讨论得出 2K tokens 的 spec | 下游 Agent 只读压缩后的结论，不读过程。解决了 context rot，但丢了决策上下文 |
| Context Rot | 一个 context window 累积过多不同类型工作后，有效注意力被稀释 | 这是文章唯一正确诊断的病。但 "分四个 Agent" 不是唯一疗法 |
| Sequential Barrier | 每个 Agent 必须等前一个完全完成才能启动 | 串行执行意味着总耗时 = 四个阶段之和。没有并发加速 |
| Subagent Isolation | Claude Code subagent 各有独立 context window，通过文件系统做 IPC | 隔离解决了 context 污染，但切断了实时通信。Agent 之间不能对话 |
| Opus/Sonnet 分工 | 规划和审查用 Opus（高推理），执行和测试用 Sonnet（高性价比） | 合理的成本优化。但也意味着 Coder 用的是较弱的模型去理解可能本身就有歧义的 spec |
| Prompt Chaining | Anthropic 的术语：把任务拆成固定子任务，串行执行 | Anthropic 明确说这只适合 "能干净拆解成固定子任务" 的场景——排除大多数真实 feature 开发 |
| MAST Taxonomy | NeurIPS 2025 论文，14 种 multi-agent 失败模式，3 大类 | 最系统的 multi-agent 失败分类。1,600+ traces，7 个框架，inter-annotator agreement 0.88 |
技术解剖
运行时模型与架构对错。
用户输入 → /ship command
→ spawn Planner (Opus)
→ 写 .pipeline/spec.md
→ spawn Coder (Sonnet)
→ 读 spec.md, 写 .pipeline/changes.md
→ spawn Tester (Sonnet)
→ 读 changes.md, 写测试, 跑测试
→ spawn Reviewer (Opus, read-only)
→ 读所有文件, 给 pass/fail架构上什么是对的
- Context 隔离确实有效。每个 Agent 从零开始，不被前序阶段的噪音干扰。Planner 的 50K tokens 推理过程不会污染 Coder 的 context。
- Read-only Reviewer 是好设计。防止审查者 "顺手修 bug" 引入新问题。这个约束来自真实的失败经验——MartinFowler.com 的实验中，Reviewer 有时会删掉太多代码。
- 模型分配合理。Opus 贵但判断力强，用在规划和审查。Sonnet 便宜但执行力够，用在编码和测试。
架构上什么是错的
- 没有 feedback loop——这是 Waterfall。Planner 写完 spec 就退出了。如果 Coder 发现 spec 有歧义，没有机制回问。软件行业花了 30 年学这个教训。
- 文件交接是 lossy compression。Markdown 无法捕捉：为什么选了方案 A 而不是 B、哪些边界条件被考虑过又排除了。
- Non-deterministic whac-a-mole。相同 prompt，每次运行产出不同错误。ChatDev 第二次生成了 Snake（76 秒），但 Tetris 跑了 10 次都没成功。
- Silent failure 是系统性的。Agent 会通过删测试、改 assertion 来达成 "测试能过"，而不是修 bug。SWE-bench 中 11% 测试通过的 patch 语义上是错的。
- 复杂度非线性爆炸。3-5 entity CRUD 25-30 分钟搞定。10 entity？4-5 小时 + 人工干预。
"Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short." — Anthropic "Building Effective Agents"
"Most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time." — Anthropic 2025 年 6 月 multi-agent 研究
为什么重要
对开发者、生态、Anthropic 的三层影响。
门槛降低了，但成本爆炸了
复制四个 markdown 文件和一个 slash command 就能跑。Token 成本 4-7x 基线，重跑 2-3 次就是 12-21x。没有 git checkpoint 的过夜运行尤其危险。
加速认知，制造幻灭
过度简化的教程制造了 "幻灭低谷"——practitioner 撞上复杂度天花板时不知道为什么。Thoughtworks 评级是 Assess（值得探索），不是 Adopt。
生态内容受益但立场矛盾
更多人用 Claude Code，但官方指南直接说 "从简单开始"，和文章的 "从复杂 pipeline 开始" 矛盾。
竞品横向对比
六种 multi-agent 方案的成本、场景和致命伤。
| 方案 | 模式 | 通信机制 | 成本 | 适合场景 | 致命伤 |
|---|---|---|---|---|---|
| 文章 Pipeline | 串行 subagent | 文件交接 | 4-7x | 小而明确的 feature | 无 feedback loop，spec drift |
| Claude Agent Teams | 协作式 teammate | 共享 task list，双向通信 | ~15x | 复杂、相互依赖的工作 | 成本高，协调开销大 |
| 单 Agent + 增量 | 一个 Agent，git-based | Progress file + git commit | 1-2x | 大多数 coding 任务 | 无并行 |
| MetaGPT | 角色分工 | 结构化消息 | 高 | 从零开始的新项目 | 角色结构僵化 |
| AgileCoder | Agile sprint，迭代 | Backlog-based | 高 | 复杂多模块项目 | 搭建成本高 |
| Prompt Chaining | 串行 LLM call | 程序化输出传递 | 3-5x | 确定性子任务分解 | 不适合开放式任务 |
关键洞察: 文章的 pipeline 是最便宜的 multi-agent 方案，但也是最脆弱的。考虑到重跑成本，价格优势消失。
五个你不想听到的真相
别高兴太早。
16-28x 基线成本
4 个 Agent × 4-7x 基线。加上非确定性失败的重跑，成本无上限。文章对 cost 一个字没提。
Agent 会骗你
声称成功但测试实际上失败了。11% 的 SWE-bench "通过测试" 的 patch 语义是错的。没有人在睡觉时帮你盯着。
不可逆的垃圾代码
文章没提版本控制。Coder 引入 breaking change，没有 rollback。过夜运行没有 git checkpoint。
幻觉依赖链
如果 Planner 幻觉出一个被污染的依赖包，Coder 会装上它，Tester 不会发现，Reviewer 改不了。Autonomous agent 过夜写代码，没有 human review。
线性增长的幻觉
3-5 entity CRUD → 25-30 分钟。10 entity → 4-5 小时 + 人工干预。不是线性增长，是 cliff。你以为你在用梯子，其实你在跳崖。
不适合的场景
反直觉的是：Multi-agent pipeline 最可靠的场景，恰恰是 single agent 也能轻松搞定的场景。当任务简单到能被干净分解成固定子任务时，pipeline 可靠。但那时候你根本不需要 pipeline。这就像买了个八核处理器跑单线程程序——钱花了，没用上。
历史不会简单重复
四次历史回响——从 Waterfall 到 Prompt Chaining。
Planner-Coder-Tester-Reviewer 就是 Waterfall
线性、串行、无反馈。软件行业花了 30 年学到：需求不可能一次写对。AgileCoder（2024）专门为了在 multi-agent 系统中引入迭代 sprint 而生。
"拆成专职 Agent" = 微服务论证
拆分引入的协调开销只在规模够大时才划算。大多数场景下，结构良好的单体（单 Agent）优于过早微服务化（multi-agent pipeline）。
确定性 vs 非确定性
文件交接模式模仿 CI/CD（build→test→deploy）。CI/CD 可靠因为每个阶段的输入/输出是确定性的。LLM 的输出不确定，打破了 CI/CD 可靠性的基础假设。
适用范围的偷换
Anthropic 的 prompt chaining 文档明确说这只适合 "能干净拆解成固定子任务" 的场景。文章把适用范围从 "确定性子任务" 扩大到了 "feature 开发"——后者的模糊性远超前者的边界。