10 步搭一支 Claude agent 团队：从一个 agent 到 20 个并行干活
Codez (@0xCodez)
2026-05-24
原文
---
title: "10 步搭一支 Claude agent 团队：从一个 agent 到 20 个并行干活"
author: Codez (@0xCodez)
source_url: https://x.com/0xCodez/status/2058513716509913581
substack: https://movez.substack.com/
published_at: 2026-05-24T11:41:30Z
fetched_at: 2026-05-27
cover_image: https://pbs.twimg.com/media/HJE3c6GWgAIpf1O.jpg
language: zh
translator: Hermes
---
# 10 步搭一支 Claude agent 团队：从一个 agent 到 20 个并行干活
我把 Claude 上 multi-agent orchestration（多 agent 编排）真正能跑通的东西，全部整合到这一篇——官方文档、cookbook、Netflix 和 Spiral 的实战配置。
**收藏。存下。** 看完你就知道怎么把一个被压垮的 agent，拆成一支最多 20 人的协同团队，并行干活。
> 关注我的 Substack 拿第一手 AI alpha：[movez.substack.com](https://movez.substack.com/)
不是夸张。2026 年 4 月之前，这事要砸几个月做基建。_现在一份 YAML 配置加 10 步就够了。_
---
## 为什么单个 agent _会撞墙_
你做了一个 agent。能跑。于是你给它加活。
加上研究能力。加上写报告。加上数据分析。再加一个审核环节。每加一项，system prompt 就长一截，工具列表就多一栏，context window 就挤一分。
直到某一天，你发现 agent 变慢了、变糊了，原本最拿手的活也做不好了。这不是模型的问题。**是架构的问题。**
单个 agent 只有一个 context window，你硬加上去的每项能力都在抢这一份有限的注意力。复杂度过线之后，一个 generalist（通才）一人扛十件事，远不如十个 specialist（专才）一人一件。
解法是搭一支团队。不是把 prompt 写更长——**是分工。**
Claude 的官方文档里写死了三条架构规则：**一支队伍最多 20 个不同的 agent**，每个 agent **各占一个独立的 context window**，所有 agent **共用一个文件系统**。思考各自一摊，工作台共用一份——团队能并行而不乱套，靠的就是这个分工。
## 决策与设计
> 01． 先确认你真的需要一个团队
别因为 multi-agent 听起来牛就上。它更费 token，还多出协调开销。下面三个里有一个成立，再考虑用：
- **可并行。** 活能拆成相互独立的子任务——不同 log 文件、不同代码模块。单个 agent 只能挨个干；团队可以一齐上。
- **要专才。** 不同问题要不同专长——安全审查、文档编写、定价建模——一个通才在这几件事之间来回切换上下文，样样都做不好。
- **要升档。** 多数活都简单，但偶尔几个子任务意外地难。团队可以把硬骨头挑出来发给更强的模型，而不是每一步都用强模型烧钱。
> 02． 写代码前先把角色画出来
Multi-agent 设计就是团队设计。动代码之前先在纸上把团队画出来：一个 coordinator（调度方），加一串各管一摊的 specialist，每个一句话讲清自己干啥。
套一个现成模式。Anthropic 文档里那个事故响应（incident-response）的例子：一个 lead agent 主导调查，subagent 同时铺开**部署历史、错误日志、监控指标、客服工单——一齐查。**
四个 specialist，一个 coordinator，单个 agent 要挨个做的事，团队并行就做完了。
每个角色起名，一句话写清职责，标上它用的模型和工具。两个角色有重合就合并。**少而锋利的 specialist，胜过一堆模糊的。**
> 03． 每个角色挑一个模型——省钱就靠这一步
大多数人都漏掉的关键一步：团队里每个 agent 都可以跑不同模型。你不是只能用一个模型。
Every 旗下 Spiral 的生产实践就是证明——他们用 **Haiku 当 coordinator**，用 **Opus 当写作的 subagent**。
Coordinator 只负责派活和排序，又快又便宜的模型完全够用。贵的重活只在真正需要的 specialist 那里发生。
按活配模型。按角色混搭模型档位，是控成本、提速度上最大的一根杠杆。
---
## 搭团队
> 04． 配好 Managed Agents
所有 multi-agent 请求都跑在 Claude Managed Agents 上，必须带上 beta header `managed-agents-2026-04-01`。SDK 会自动加。
为什么用 Managed Agents 而不是自己搭？因为团队一旦要远程运行、要支持多用户、要共享文件系统、要保存状态，你就撞上一堆基建问题——会话、记忆、安全、沙箱。
**Managed Agents 把这些全包了，你只管设计团队。** 装上 Anthropic SDK，去 Console 把 API key 配好，就能开干。
> 05． 每个 specialist 单独建一个 agent
自下而上，先把 specialist 都建起来。每个都是独立的 agent，有自己的模型、prompt 和限定的工具集。建好后记下 agent ID——coordinator 要用。
真正重要的纪律：**每个 specialist 的工具权限要收紧。** Cookbook 销售提案那个例子里，researcher 只拿到 web search，librarian 只能读文件，pricing modeler 只看到规则文件和席位数。
每个 agent 只能碰自己活上需要的东西，一点都不多——这样它能保持专注，整个系统也能审计。
> 06． 建 coordinator，声明它带的队伍
该建 lead agent 了。把一个 agent 标成 coordinator 的方法是：设置 `multiagent` 字段，把它能委派的 subagent ID 列出来。配置故意写得很简洁：
```yaml
name: Engineering Lead
model: claude-opus-4-7
system: >
You coordinate engineering work. Delegate code review
to the reviewer agent and test writing to the test agent.
tools:
- type: agent_toolset_20260401
multiagent:
type: coordinator
agents:
- type: agent
id: $REVIEWER_AGENT_ID
- type: agent
id: $TEST_WRITER_AGENT_ID
```
是 `agent_toolset_20260401` 这个工具让 coordinator 拥有委派能力。一支队伍最多容纳 20 个 agent。
你可以钉死某个 agent 版本、引用最新版，也可以用 `{"type": "self"}` 让 coordinator 复制自己出来，做递归并行。
> 07． Coordinator 的 prompt 按管理者来写，别按干活的人写
团队成败就在这一步。Coordinator 的 system prompt 别想着自己干活——它要写的是怎么 _委派_ 工作。
一个好的 coordinator prompt 会这样写：这是你的 specialist 名单，每个是干嘛的，怎么决定哪一件分给谁，几个人的输出怎么合到一起。它推理的是顺序和综合，不是领域细节——领域细节归 specialist 管。
**如果你在 coordinator 里写领域指令，那段内容本来应该写在 subagent 里。**
下面是一个真实的事故响应团队 coordinator prompt——注意它从不自己查任何东西，只做派活和综合：
```text
You are the incident-response coordinator. You do NOT
investigate anything yourself. Your only job is to delegate
to your specialists and synthesize what they return.
Your specialists:
- deploy_agent → reviews recent deploy history for changes
- logs_agent → searches error logs for anomalies
- metrics_agent → checks dashboards for abnormal patterns
- tickets_agent → scans support tickets for user reports
How to work:
1. When an incident arrives, delegate to ALL FOUR
specialists in parallel — do not wait for one before
starting the next.
2. Give each specialist only the incident description and
the time window. Nothing else.
3. When results return, look for correlation across them
(e.g. a deploy that lines up with a log spike and ticket
surge points to a root cause).
4. If one specialist's finding is unclear, send it a
follow-up — it remembers its previous turn.
Output format:
- ROOT CAUSE: one sentence, or "unconfirmed"
- EVIDENCE: one bullet per specialist that contributed
- RECOMMENDED ACTION: one clear next step
Never include raw logs or full ticket text in your final
answer — synthesize, do not dump.
```
每一行讲的都是怎么委派、怎么关联、怎么定输出形状。真正翻日志、读指标的活在 specialist 那里——本来就该在那。
---
## 运行、观察、改进
> 08． 搞清楚团队怎么通信
跑 coordinator 的时候，底层机制很具体，值得搞清楚：
Coordinator 每委派一个 subagent，就生出**一条独立的会话线程**——一条上下文隔离的事件流，有自己的历史。Coordinator 在主线程里汇报；它每委派一次，运行时就冒出一条新线程。
关键是，**线程是持久的：** coordinator 可以给之前调过的 agent 再发一条后续消息，那个 agent 会保留之前所有轮的内容。
一条绕不开的硬限制：**coordinator 只能往下委派一层。** 超过一层会被忽略。
Specialist 自己不能再开子团队。这是故意的——让系统保持可预测、可追踪。
> 09． 在 Claude Console 里全程盯着
生产级 multi-agent 系统和实验性的，差别就在可观测性。
每一次运行都会在 Claude Console 里产生一份完整的 trace：**哪个 agent 做了什么、按什么顺序做、为什么这么做。** 你能看到每一次委派决定，能查每个 subagent 的推理，从头到尾跟着整条序列走完。
结果不对的时候，trace 会告诉你是哪个 specialist 出了问题，问题出在委派还是 specialist 本身。**别蒙眼跑团队——去读 trace。**
> 10． 扩到 20 个，加上共享记忆
小团队跑通之后再扩。把 specialist 加到 20 个的上限，让 coordinator 把活并行铺到全员身上。
然后用共享记忆把闭环合上。许多 subagent 都在同一个领域干活时，Dreaming 这个功能能把它们集体学到的东西汇总，**把共同的洞见沉淀到团队级的记忆库**——这是单个 agent 会话独自做不出来的东西。
团队不只是并行干活；它整体也在越用越精。
Netflix 的平台团队就是这么在生产里跑的：multi-agent orchestration 处理**几百个同时跑的 build** 的日志，并行的 subagent 在几千个应用里捞反复出现的问题——单 agent 系统下，这种活挨个干根本干不完。
---
## _搞垮_ agent 团队的几个错
- **一个 agent 就够却非要搭团队。** Multi-agent 更贵，协调更慢。活既不需要并行，也不需要专长，也不需要升档，你只是凭空加了一层复杂度。
- **Coordinator 自己下场干活。** Lead agent 里写的是领域指令而不是委派逻辑，那你做的就是一个臃肿的单 agent，套了一身团队的戏服。
- **工具权限放得太松。** 每个 specialist 什么都能碰，专注就垮了，trace 也读不下去。每个 agent 都要把权限收紧到刚好够它干自己那份活。
- **跟一层深度的限制硬刚。** Coordinator 只能委派一层。设计一套藏起来的子 coordinator 层级是浪费时间——更深的那层会被忽略。
- **蒙眼跑。** Console trace 就是为了让你看到哪个 agent 做了什么。跳过它，一台齿轮转着的系统你根本调不动。
---
## 结语
大多数人会接着往一个 agent 里塞更多能力，看着它变慢、退化，然后得出结论说 agent 还没成熟。
搭团队的那批人手里就完全是另一回事：一个会委派的 coordinator，各自带 context 并行干活的 specialist，一个用来协作的共享文件系统，一个让整支团队越用越精的记忆库。
**挑一个能拆成并行块的任务。画出三个 specialist 加一个 coordinator。先把这支小团队搭起来。** 仅这一步，就会改变你的 agent 能接住多少活。