# How to build a 4-agent team, that ships a feature while you sleep (Exact Setup Inside)
**作者**: darkzodchi
**日期**: 2026-05-30T10:46:40.000Z
**来源**: [https://x.com/zodchiii/status/2060674246880149900](https://x.com/zodchiii/status/2060674246880149900)
---
Four AI agents can ship a feature while you sleep. Most people never wire them up.
They fire a reviewer here, a test generator there, by hand, one at a time, each forgetting what the last one did. You're still the bottleneck.
The fix: Planner → Coder → Tester → Reviewer, chained to hand off automatically. One trigger, four stages, a finished feature by morning.
Here's the full pipeline, with copy-paste code 👇
Before we dive in, I share daily notes on AI & vibe coding in my Telegram channel: https://t.me/zodchixquant 🧠
## Why a pipeline beats a pile of agents
One agent doing everything fills its context window with planning, code, tests, and review notes until quality drops.
Four specialists each stay in a clean, narrow context.
The trick is the handoff file. Each agent writes its output where the next one can read it: Planner drops a spec at .pipeline/spec.md, Coder reads it and writes .pipeline/changes.md, and so on.
The orchestrator running them in order is a single slash command. That's the whole thing: four subagents, one command, a shared folder for handoffs.
## Agent 1: The Planner (subagent, opus)
The Planner never writes code. It turns a vague feature request into a concrete spec the Coder can follow without guessing.
Create .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.
```
Planning runs on opus because this stage sets the quality ceiling for everything after it. A vague spec produces vague code no matter how good the Coder is.
## Agent 2: The Coder (subagent, sonnet)
The Coder reads the spec and writes the implementation. It doesn't plan and it doesn't review its own work, it just builds what the spec says.
Create .claude/agents/coder.md:
```
---
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.
You write code that matches the repo. You do not refactor unrelated
code or "improve" things outside the spec's scope.
```
Sonnet is the right call here: implementation against a clear spec is exactly the balanced cost-quality work Sonnet handles best.
The handoff note at .pipeline/changes.md is what lets the Tester target the right surface instead of testing blind.
## Agent 3: The Tester (subagent, sonnet)
The Tester reads what changed and writes tests that prove the feature works, then runs them.
Create .claude/agents/tester.md:
```
---
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`.
You test behavior, not implementation details. A failing test means
the pipeline pauses for the Reviewer, not that you patch around it.
```
## Agent 4: The Reviewer (subagent, opus)
The last gate. The Reviewer reads everything the pipeline produced and gives a verdict before any of it reaches your main branch.
Create .claude/agents/reviewer.md:
```
---
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.
Be the last line of defense. If the tests are green but the code is
wrong, say BLOCK. Green tests are not the same as correct behavior.
```
Read-only tools mean the Reviewer can't paper over problems by editing, it can only judge.
## The orchestrator: one command to run all four
Now the piece that turns four separate agents into a pipeline. A slash command that invokes them in order, each one picking up the handoff file the last one wrote.
Create .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.
```
Then a single line kicks off the whole chain: /ship add rate limiting to the login endpoint.
## Where I run the overnight version
That's what I use Teamly for: managed cloud hosting built specifically for AI agents.
You hire a team, it runs 24/7 on dedicated infrastructure, and you never touch a server.
The reason @Teamly fits this article specifically: the handoff problem is already solved for you.
Everything we built by hand above (the spec file, the changes file, the orchestrator chaining one agent to the next) Teamly does with a Coordinator.
It routes work between agents, passes context from one to the next, and keeps a shared brief they all read from.
The same Planner-to-Coder-to-Tester flow, except you don't wire the handoffs yourself.
The difference is that @Teamly isn't code-only. The exact same orchestration runs a marketing team, a research team, or a support team.
Your Claude Code pipeline ships features overnight; a Teamly marketing team ships content the same way, with the same hand-off logic underneath.
## Build the exact team you need
New feature, that team just rolled out: My Team
Now you can build your team with just 3 questions.
You also can control: voice rules, forbidden phrases, integrations, team style (Strict / Casual / Creative), and team size (2-4 agents).
@Teamly returns a team with a real rationale for why each specialist is there, not boilerplate. Swap any agent with one click. Edit the brief if it's off.
The point is a structured brief that forces clarity, then composes a team you can audit before hiring.
Same handoff architecture as the pre-built teams, fitted to your specific problem.
## Try it free first
You can test the whole thing free for 3 days on Teamly 5, no charge until day 4.
If you stay, pricing is $29/mo for 5 agents.
Cheap enough that one shipped feature pays for the month.
## The bottom line
The difference between a pile of agents and a pipeline is the handoff.
Four specialists writing to shared files, one orchestrator running them in order, each stage building on the last instead of starting from scratch.
Build the Planner and Coder first and run them as a two-stage chain. Once that flow feels solid, add the Tester and Reviewer.
By the time all four are wired up, you'll kick off a feature before bed and read a verdict with your coffee.
For daily notes on AI agents, vibe coding and Claude Code setups: https://t.me/zodchixquant 🧠
## 相关链接
- [darkzodchi](https://x.com/zodchiii)
- [@zodchiii](https://x.com/zodchiii)
- [666K](https://x.com/zodchiii/status/2060674246880149900/analytics)
- [https://t.me/zodchixquant](https://t.me/zodchixquant)
- [Teamly](https://teamly.to/)
- [@Teamly](https://x.com/@Teamly)
- [@Teamly](https://x.com/@Teamly)
- [@Teamly](https://x.com/@Teamly)
- [https://t.me/zodchixquant](https://t.me/zodchixquant)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [6:46 PM · May 30, 2026](https://x.com/zodchiii/status/2060674246880149900)
- [666.1K Views](https://x.com/zodchiii/status/2060674246880149900/analytics)
- [View quotes](https://x.com/zodchiii/status/2060674246880149900/quotes)
---
*导出时间: 2026/5/31 11:29:10*
---
## 中文翻译
# 如何构建一个在你睡觉时交付功能的 4 智能体团队（内含详细配置）
**作者**: darkzodchi
**日期**: 2026-05-30T10:46:40.000Z
**来源**: [https://x.com/zodchiii/status/2060674246880149900](https://x.com/zodchiii/status/2060674246880149900)
---
四个 AI 智能体可以在你睡觉时完成功能交付。大多数人从未将它们连接起来。
他们在这里手动触发审查者，在那里手动触发测试生成器，一个接一个，每次都忘记了上一步做了什么。你仍然是瓶颈。
解决方案是：规划员 → 编码员 → 测试员 → 审查员，链接在一起以自动交接。一次触发，四个阶段，早上醒来就是一个完成的功能。
以下是完整的流水线，包含可复制粘贴的代码 👇
在深入之前，我每天都会在 Telegram 频道上分享关于 AI 和 vibe coding 的笔记：https://t.me/zodchixquant 🧠
<img src="/doc/2362/image/img_312cfa54de99.jpg" alt="Image" style="zoom:67%;" />
## 为什么流水线胜过一堆散乱的智能体
如果一个智能体包办一切，它的上下文窗口会被规划、代码、测试和审查笔记填满，直到质量下降。
四个专家型智能体各自保持在一个干净、狭窄的上下文中。
诀窍在于交接文件。每个智能体将其输出写入下一个智能体可以读取的地方：规划员将规范放入 `.pipeline/spec.md`，编码员读取它并写入 `.pipeline/changes.md`，以此类推。
按顺序运行它们的协调器只是一个斜杠命令。整个系统的核心就是：四个子智能体，一个命令，一个用于交接的共享文件夹。
## 智能体 1：规划员（子智能体，Opus）
规划员从不编写代码。它将模糊的功能请求转化为具体的规范，让编码员无需猜测即可遵循。
创建 `.claude/agents/planner.md`：
```
---
name: planner
description: 将功能请求转化为实现规范。用作功能流水线的第一阶段。
tools: Read, Grep, Glob, Write
model: opus
---
你是一名规划专家。你不编写实现代码。
收到功能请求时：
1. 阅读代码库的相关部分以理解当前的模式。
2. 将规范写入 `.pipeline/spec.md`，包含：
- 要创建或修改的文件，以及精确的路径
- 所需的接口或函数签名
- 实现必须处理的边缘情况
- 要遵循的现有模式（指明要复制的源文件）
3. 将任何模棱两可的内容标记在规范顶部的“待解决问题”中。
保持规范简洁。编码员只阅读这个文件而不看其他，所以不要留
任何缺口，也不要虚构未被要求的需求。
```
规划阶段使用 Opus 是因为这一阶段决定了后续所有工作的质量上限。如果规范模糊，无论编码员多优秀，产出的代码也会模糊。
## 智能体 2：编码员（子智能体，Sonnet）
编码员阅读规范并编写实现代码。它不做规划，也不审查自己的工作，它只是构建规范所描述的内容。
创建 `.claude/agents/coder.md`：
```
---
name: coder
description: 实现 .pipeline/spec.md 中的规范。用作功能流水线的第二阶段，在规划员之后。
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---
你是一名实现专家。
1. 完整阅读 `.pipeline/spec.md`。如果有“待解决问题”，请
停下来并展示它们，而不是猜测。
2. 严格实现规范描述的内容。遵循其指定的模式。
不要添加规范未要求的功能。
3. 将简短摘要写入 `.pipeline/changes.md`：哪些文件发生了变更，
每个变更的作用，以及测试员应关注的重点。
你编写的代码应与代码库匹配。不要重构无关的代码
或“改进”规范范围之外的内容。
```
在这里使用 Sonnet 是正确的选择：基于清晰规范进行实现，正是 Sonnet 擅长的平衡成本与质量的工作。
在 `.pipeline/changes.md` 的交接笔记能让测试员定位到正确的测试范围，而不是盲目测试。
## 智能体 3：测试员（子智能体，Sonnet）
测试员阅读变更内容，编写测试以证明功能有效，然后运行测试。
创建 `.claude/agents/tester.md`：
```
---
name: tester
description: 为 .pipeline/changes.md 中描述的变更编写并运行测试。功能流水线的第三阶段。
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---
你是一名测试专家。
1. 阅读 `.pipeline/changes.md` 以了解构建了什么以及在哪里。
2. 阅读变更的文件和位于 `.pipeline/spec.md` 的规范。
3. 编写涵盖以下内容的测试：正常路径、规范命名的边缘情况，
以及至少一个失败案例。匹配代码库的测试框架。
4. 运行测试。如果有任何失败，将失败信息写入
`.pipeline/test-results.md` 并停止。不要自己修复代码。
5. 如果全部通过，在 `.pipeline/test-results.md` 中注明。
你测试的是行为，而不是实现细节。测试失败意味着
流水线暂停等待审查员，而不是让你绕过它去修补。
```
## 智能体 4：审查员（子智能体，Opus）
最后一道关卡。审查员阅读流水线产生的所有内容，并在代码进入主分支之前给出裁决。
创建 `.claude/agents/reviewer.md`：
```
---
name: reviewer
description: 对完整流水线输出进行最终审查。人工批准前的第四阶段，也是最后阶段。
tools: Read, Grep, Glob, Bash
model: opus
---
你是一名高级审查员。你是只读的。你不编辑代码。
1. 阅读来自 `.pipeline/` 的规范、变更摘要和测试结果。
2. 运行 `git diff` 查看实际的变更。
3. 评估：代码是否符合规范？测试是否有意义还是流于表面？
是否存在安全、性能或正确性问题？
4. 将裁决写入 `.pipeline/review.md`：
- 裁决：可发布 / 需修改 / 阻塞
- 对于“需修改”或“阻塞”，精确列出需要修复的内容和位置。
成为最后一道防线。如果测试通过但代码是错的，就说“阻塞”。
绿色的测试不等于正确的行为。
```
只读工具意味着审查员不能通过编辑来掩盖问题，它只能进行评判。
## 协调器：用一条命令运行全部四个
现在是将四个独立的智能体变成流水线的关键部分。一个斜杠命令按顺序调用它们，每一个都读取上一个写入的交接文件。
创建 `.claude/commands/ship.md`：
```
针对以下内容运行完整的功能流水线：$ARGUMENTS
按顺序执行这些阶段。不要跳过。在每个阶段之后，
在开始下一阶段之前确认交接文件是否存在。
1. 将上述功能请求委派给 `planner` 子智能体。
等待 `.pipeline/spec.md`。
2. 如果规范有“待解决问题”，停止并展示给我。否则
委派给 `coder` 子智能体。等待 `.pipeline/changes.md`。
3. 委派给 `tester` 子智能体。等待 `.pipeline/test-results.md`。
如果测试失败，停止并向我展示失败信息。
4. 委派给 `reviewer` 子智能体。向我展示 `.pipeline/review.md`。
报告最终裁决。不要合并任何内容。保留分支
供我早上审查。
```
然后，只需一行命令即可启动整个链条：/ship add rate limiting to the login endpoint（给登录接口添加限流）。
## 我在哪里运行夜间版本
这就是我使用 Teamly 的原因：专为 AI 智能体构建的托管云服务。
你招募一个团队，它在专用基础设施上 24/7 运行，而你无需触碰服务器。
@Teamly 特别适合本文的原因在于：交接问题已经为你解决了。
我们上面手动构建的所有东西（规范文件、变更文件、连接一个智能体到下一个的协调器）Teamly 通过协调器来实现。
它在智能体之间路由工作，将上下文从一个传递到下一个，并维护一个共享的简报供所有人阅读。
同样的规划员到编码员到测试员的流程，只是你不需要自己手动连接交接。
不同之处在于，@Teamly 不仅限于代码。完全相同的编排逻辑可以运行营销团队、研究团队或支持团队。
你的 Claude Code 流水线在夜间交付功能；Teamly 营销团队以同样的方式交付内容，底层使用相同的交接逻辑。
## 构建你所需的确切团队
新功能刚刚推出：My Team
现在你只需回答 3 个问题即可构建你的团队。
你还可以控制：语音规则、禁用短语、集成项、团队风格（严格 / 随意 / 创意）以及团队规模（2-4 个智能体）。
@Teamly 返回的团队对每个专家存在的原因都有真实的解释，而不是套话。一键即可交换任何智能体。如果简报有偏差，可以编辑。
关键在于一个结构化的简报，它强制清晰度，然后组成一个你可以在雇佣前审核的团队。
与预构建团队相同的交接架构，专为你的特定问题量身定制。
## 先免费试用
你可以在 Teamly 5 上免费试用整个系统 3 天，第 4 天前不收费。
如果你留下来，价格是每月 29 美元，包含 5 个智能体。
足够便宜，交付一个功能就能抵消一个月的费用。
## 总结
一堆散乱的智能体与流水线的区别在于交接。
四个专家型智能体写入共享文件，一个协调器按顺序运行它们，每个阶段都建立在上一阶段的基础上，而不是从头开始。
先构建规划员和编码员，并将它们作为两阶段链条运行。一旦流程感觉稳固，再添加测试员和审查员。
等到这四个全部连接好，你就会在睡前启动一个功能，并在喝咖啡时阅读裁决。
关于 AI 智能体、vibe coding 和 Claude Code 配置的每日笔记：https://t.me/zodchixquant 🧠
## 相关链接
- [darkzodchi](https://x.com/zodchiii)
- [@zodchiii](https://x.com/zodchiii)
- [666K](https://x.com/zodchiii/status/2060674246880149900/analytics)
- [https://t.me/zodchixquant](https://t.me/zodchixquant)
- [Teamly](https://teamly.to/)
- [@Teamly](https://x.com/@Teamly)
- [@Teamly](https://x.com/@Teamly)
- [@Teamly](https://x.com/@Teamly)
- [@Teamly](https://x.com/@Teamly)
- [https://t.me/zodchixquant](https://t.me/zodchixquant)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [6:46 PM · May 30, 2026](https://x.com/zodchiii/status/2060674246880149900)
- [666.1K Views](https://x.com/zodchiii/status/2060674246880149900/analytics)
- [查看引用](https://x.com/zodchiii/status/2060674246880149900/quotes)
---
*导出时间: 2026/5/31 11:29:10*