如何构建一支 4 个 Agent 的团队，让你在睡觉时也能交付功能（内含详细设置）

四个 AI Agent 可以在你睡觉时完成一个功能开发。但大多数人从未将它们串联起来。

他们一个个手动触发：这里派一个审查员，那里调一个测试生成器，每个都不知道上一个做了什么。你仍然是瓶颈。

解决方案：规划 → 编码 → 测试 → 审查，自动链式交接。一次触发，四个阶段，一觉醒来功能就完成了。

以下是完整的流水线，附可直接复制粘贴的代码 👇

在深入之前，我每天都在我的 Telegram 频道分享关于 AI 和 vibe coding 的笔记：https://t.me/zodchixquant 🧠

为什么流水线胜过一堆积压的 Agent

一个 Agent 包揽所有工作，它的上下文窗口会被规划、代码、测试和审查笔记塞满，质量逐渐下降。

四个专业 Agent 各自保持干净、狭窄的上下文。

关键在于交接文件。每个 Agent 将其输出写入下一个 Agent 可读取的位置：Planner 将规格说明写入 .pipeline/spec.md，Coder 读取它并写入 .pipeline/changes.md，以此类推。

按顺序运行它们的编排器只是一个斜杠命令。就这么简单：四个子 Agent，一个命令，一个共享的交接文件夹。

Agent 1：规划者（子 Agent，opus）

Planner 从不写代码。它将一个模糊的功能需求转化为具体的规格说明，让 Coder 无需猜测即可执行。

创建 .claude/agents/planner.md：

markdown

1---
2name: planner
3description: 将功能需求转化为实现规格说明。用作功能流水线的第一阶段。
4tools: Read, Grep, Glob, Write
5model: opus
6---
7
8你是一名规划专家。你**不**编写实现代码。
9
10给定一个功能需求：
111. 读取代码库的相关部分，了解当前模式。
122. 将规格说明写入 `.pipeline/spec.md`，内容包括：
13   - 需要创建或修改的文件及其确切路径
14   - 所需的接口或函数签名
15   - 实现必须处理的边界情况
16   - 需要遵循的现有模式（指明要模仿的文件名）
173. 将任何歧义之处标记为**开放问题**，置于规格说明顶部。
18
19保持规格说明精炼。Coder 仅读取此文件，因此不要留有任何缺口，也不要编造任何未经要求的需求。

规划阶段使用 opus，因为这一步决定了后续所有工作的质量上限。模糊的规格说明无论 Coder 多优秀，都会产生模糊的代码。

Agent 2：编码者（子 Agent，sonnet）

Coder 读取规格说明并编写实现代码。它不做规划，也不审查自己的工作，只按照规格说明构建。

创建 .claude/agents/coder.md：

markdown

1---
2name: coder
3description: 实现 `.pipeline/spec.md` 中的规格说明。用作功能流水线的第二阶段，在规划者之后。
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8你是一名实现专家。
9
101. 完整读取 `.pipeline/spec.md`。如果有开放问题，则停止并提出来，而不是猜测。
112. 精确实现规格说明描述的内容。遵循其指明的模式。不要添加未要求的额外功能。
123. 向 `.pipeline/changes.md` 写入简短摘要：哪些文件发生了变更、每个变更的作用，以及测试者应重点关注的内容。
13
14你编写的代码要与仓库保持一致。不要重构无关代码或“改进”规格说明范围之外的内容。

Sonnet 是这里的最佳选择：针对清晰的规格说明进行实现，正是 Sonnet 擅长处理的那种平衡成本与质量的工作。

.pipeline/changes.md 中的交接记录让测试者能够瞄准正确的测试范围，而不是盲目测试。

Agent 3：测试者（子 Agent，sonnet）

Tester 读取变更内容，编写能证明功能正常运行的测试，然后执行测试。

创建 .claude/agents/tester.md：

markdown

1---
2name: tester
3description: 为 `.pipeline/changes.md` 中描述的变更编写并运行测试。功能流水线的第三阶段。
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8你是一名测试专家。
9
101. 读取 `.pipeline/changes.md`，了解已构建的内容及其位置。
112. 读取变更后的文件以及 `.pipeline/spec.md` 中的规格说明。
123. 编写覆盖以下方面的测试：正常路径、规格说明中列出的边界情况，以及至少一个失败用例。匹配仓库使用的测试框架。
134. 运行测试。如果有测试失败，将失败信息写入 `.pipeline/test-results.md` 并**停止**。不要自行修复代码。
145. 如果全部通过，在 `.pipeline/test-results.md` 中注明。
15
16你测试的是行为，而不是实现细节。测试失败意味着流水线暂停，交由审查者处理，而不是由你来修补。

Agent 4：审查者（子 Agent，opus）

最后一道关卡。Reviewer 读取流水线产生的所有内容，在合并到主分支之前给出最终裁决。

创建 .claude/agents/reviewer.md：

markdown

1---
2name: reviewer
3description: 对整个流水线输出进行最终审查。在第一个人工签署之前的第四个也是最后一个阶段。
4tools: Read, Grep, Glob, Bash
5model: opus
6---
7
8你是一名高级审查者。你只能读取，不能编辑代码。
9
101. 从 `.pipeline/` 读取规格说明、变更摘要和测试结果。
112. 运行 `git diff` 查看实际变更。
123. 评估：代码是否匹配规格说明？测试是有意义的还是肤浅的？是否存在安全、性能或正确性问题？
134. 向 `.pipeline/review.md` 写入裁决：
14   - 裁决：SHIP（可发布） / NEEDS WORK（需要修改） / BLOCK（阻止）
15   - 对于 NEEDS WORK 或 BLOCK，列出需要修复的具体内容和位置。
16
17作为最后一道防线。如果测试通过但代码错误，请给出 BLOCK。绿色测试不等于正确的行为。

只读工具意味着审查者不能通过编辑来掩盖问题，它只能做出判断。

编排器：一个命令运行全部四个 Agent

现在是时候将四个独立的 Agent 转化为流水线了。一个斜杠命令按顺序调用它们，每个 Agent 接收上一个写好的交接文件。

创建 .claude/commands/ship.md：

text

1为以下内容运行完整功能流水线：$ARGUMENTS
2
3按顺序执行以下阶段。不要跳跃。每个阶段完成后，确认交接文件存在再开始下一个。
4
51. 将上述功能需求委托给 `planner` 子 Agent。等待 `.pipeline/spec.md`。
62. 如果规格说明中有开放问题，停止并向用户展示。否则委托给 `coder` 子 Agent。等待 `.pipeline/changes.md`。
73. 委托给 `tester` 子 Agent。等待 `.pipeline/test-results.md`。如果测试失败，停止并展示失败信息。
84. 委托给 `reviewer` 子 Agent。展示 `.pipeline/review.md`。
9
10报告最终裁决。不要合并任何内容。保留分支供我早上审查。