如何在10步内组建一支Claude智能体团队：从单个智能体到20个并行协作

我已经把Claude上关于多智能体编排的有效方案——官方文档、菜谱、Netflix和Spiral的真实部署——全部整合到这套指南中。

请收藏此文。保存它。 读完后，你将知道如何把一个超负荷的智能体变成一支最多20个智能体并行协作的协调团队。

关注我的Substack获取最新AI资讯：movez.substack.com

这不是夸张。在2026年4月之前，这需要数月的架构工程投入。而现在，只需要一个YAML配置和10个步骤。

为什么单个智能体会碰壁

你构建了一个智能体。它运行良好。于是你给它加了更多任务。

增加研究能力。增加报告撰写。增加数据分析。增加审查步骤。每一次增加都让系统提示更长、工具列表更大、上下文窗口更拥挤。

然后某天你发现智能体变慢了，更困惑了，连原本擅长的事情也做不好了。这不是模型问题，而是架构问题。

单个智能体只有一个上下文窗口，你每增加一项能力，它们都在争夺同一份有限的注意力。超过一定复杂度后，一个身兼十职的通才，表现反而不如十个各司其职的专家。

解决方法是组建团队。不是更大的提示词，而是分工协作。

三个事实定义了架构，直接来自官方文档：最多20个独特的智能体组成一个花名册，每个都在各自独立的上下文窗口中运行，所有智能体共享同一个文件系统。 独立思考，共享工作空间——这就是团队无混乱并行工作的关键。

决策与设计

1. 确认你真的需要一支团队

不要因为听起来厉害就用多智能体。它会消耗更多令牌，增加协调开销。只有当以下三种情况之一成立时，才使用它：

• 并行化。 工作可以拆分为独立的子任务——独立日志文件、独立代码模块。单个智能体顺序执行它们；团队同时执行。

• 专业化。 不同问题需要不同专长——安全审查员、文档撰写员、定价建模师——而一个通才在它们之间切换上下文会降低所有任务的质量。

• 升级。 大部分工作简单，但某些子任务出奇困难。团队将困难任务路由给更强模型，而不必在每一步都支付高昂成本。

2. 在写任何代码之前先规划角色

多智能体设计就是组织设计。写代码前，先在纸上画出团队草图：一个协调员，和一组每个只做一件明确工作的专家。

以真实模式为锚点。Anthropic 记录的 incident-response 示例：一名主智能体负责调查，子智能体并行展开到部署历史、错误日志、指标和支持工单中——全部同时进行。

四名专家，一名协调员，原本单个智能体顺序执行的工作现在并行完成。

为每个角色命名，用一句话说明其职责，注明其模型和工具。如果两个角色重叠，合并它们。更少、更精准的专家胜过许多模糊的专家。

3. 为每个角色选择模型——省钱的要点就在这儿

大多数人都忽略的招数：团队中的每个智能体可以运行不同模型。你不必被锁定在同一个模型上。

Every 公司 Spiral 的生产模式就证明了这一点：他们使用Haiku 作为协调员，Opus 作为写作子智能体。

协调员只负责路由和排序，快速廉价的模型就能胜任。昂贵的重活只在需要它的专家那里发生。

根据工作匹配模型。按角色混合模型层级是影响成本和速度的最大杠杆。

构建团队

4. 设置托管智能体 (Managed Agents)

每个多智能体请求都运行在 Claude Managed Agents 上，并且需要 beta 请求头 managed-agents-2026-04-01。SDK 会自动设置它。

为什么要用 Managed Agents 而不是你自己搭建？因为一旦团队需要远程运行、扩展到多个用户、共享文件系统并持久化状态，你就会面临基础设施问题——会话、内存、安全、沙箱。

Managed Agents 处理所有这一切，你只需设计团队。 安装 Anthropic SDK，从 Console 设置你的 API 密钥，即可开始。

5. 将每个专家创建为独立的智能体

自下而上先构建专家。每个专家都是一个独立的智能体，拥有自己的模型、系统提示和限定工具集。创建它们并保存好智能体 ID——协调员将会引用它们。

重要的原则：严格限定每个专家能用的工具。 在 Cookbook 的销售提案示例中，研究员只能使用网络搜索，图书管理员只能读取文件，定价建模师只能看到规则文件和座位数。

每个智能体只接触其工作所需的内容，不多不少——这样能让它保持专注，并使整个系统可审计。

6. 创建协调员并声明花名册

现在创建主智能体。你通过设置 multiagent 字段将智能体标记为协调员，并列出它可以委派的子智能体 ID。配置刻意简洁：

name: Engineering Lead
model: claude-opus-4-7
system: >
  你协调工程工作。将代码审查委派给审查智能体，
  将测试编写委派给测试编写智能体。
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 这个工具赋予了协调员委派的能力。花名册最多可包含 20 个条目。

你可以固定某个具体的智能体版本、引用最新版本，或者使用 {"type": "self"} 让协调员复制自身以实现递归并行化。

7. 将协调员的提示词写成管理者而非执行者

这是决定团队成败的关键。协调员的系统提示不应试图去执行工作——它应该描述如何委派工作。

一个好的协调员提示词会这样说：这是你的专家，每个专家负责什么，如何决定谁做什么，如何合并他们的输出。它思考的是排序和综合，而不是领域细节——那些应放在专家中。

如果你将领域指令写进协调员，那么这些内容应该放在子智能体中。

以下是一个真实的事件响应团队协调员提示词——注意它从不自行调查任何事情，只负责路由和综合：

你是一个事件响应协调员。你自己不调查任何事情。
你唯一的工作是委派给你的专家并综合他们的结果。

你的专家：
- deploy_agent  → 审查最近的部署历史以查找变更
- logs_agent    → 搜索错误日志以查找异常
- metrics_agent → 检查仪表盘以查找异常模式
- tickets_agent → 扫描支持工单以查找用户报告

工作方法：
1. 当事件到达时，同时委派给所有四个专家——不要等一个完成再开始下一个。
2. 只给每个专家事件描述和时间窗口。别无其他。
3. 结果返回后，寻找它们之间的关联（例如，一次部署与日志峰值和工单激增对应，指向根本原因）。
4. 如果某个专家的发现不清晰，发送后续问题——它会记住之前的轮次。

输出格式：
- 根本原因：一句话，或“未确认”
- 证据：每个贡献的专家一个要点
- 推荐操作：一个清晰的下一步

不要在最终答案中包含原始日志或完整工单文本——进行综合，不要转储。

每一行都关于委派、关联和输出形式。实际的日志搜索和指标读取都在专家中，各归其位。

运行、观察、改进

8. 理解团队的通信方式

当你运行协调员时，具体机制值得了解：

协调员委派给每个子智能体时，都会生成它自己的会话线程——一个上下文隔离的事件流，有自己的历史。协调员在主线程中报告；新线程在委派时运行时生成。

关键的是，线程是持久的： 协调员可以向之前调用过的智能体发送后续问题，该智能体会保留之前轮次的所有信息。

设计时需要绕开的一个硬约束：协调员只能委派一层深度。 深度大于 1 会被忽略。专家不能运行自己的子团队。这是有意为之——它使系统可预测且可追踪。

9. 在 Claude Console 中观察整个过程

生产级多智能体系统与实验型系统的区别在于可观测性。

每次运行都会在 Claude Console 中产生完整追踪：哪个智能体做了什么、按什么顺序、为什么。 你可以查看每个委派决策，检查每个子智能体的推理过程，端到端跟踪整个序列。

当结果出错时，追踪会告诉你哪个专家失败，以及问题是出在委派还是专家本身。不要盲目运行团队——请阅读追踪记录。

10. 扩展到 20 个智能体并添加共享记忆

一旦小团队运行正常，就扩展它。增加专家，直到达到 20 个智能体的花名册上限，让协调员并行地将其分派给所有专家。

然后通过共享记忆形成闭环。当多个子智能体在同一个领域工作时，Dreaming 功能可以汇总它们共同学到的内容，并将共享洞察发布到团队范围的记忆存储中——这是单个智能体会话无法单独产生的。

团队不仅并行工作，还能作为一个整体随时间变得更智能。

这就是 Netflix 平台团队在生产环境中运行的模式：多智能体编排处理数百个并行构建的日志，并行子智能体在数千个应用中持续发现重复出现的问题——这些工作在单智能体设置下将极其低效。

搞垮智能体团队的常见错误

• 在单个智能体就够用的情况下组建团队。 多智能体成本更高，协调更慢。如果工作不能并行化、专业化或升级，你只是在增加没有必要的复杂性。

• 协调员自己做工作。 如果主智能体包含领域指令而非委托逻辑，你就只是构建了一个穿着团队外衣的臃肿单智能体。

• 工具范围限定不严格。 当每个专家都能触碰一切时，专注力就消失了，追踪记录也变得不可读。将每个智能体限定在刚好完成其工作的工具上。

• 对抗深度为 1 的限制。 协调员只委派一层深度。设计隐藏的次级协调员层级只会浪费时间——深度限制会被忽略。

• 盲目运行。 Console 追踪存在是为了让你看到哪个智能体做了什么。跳过它，你就无法调试一个有活动部件的系统。

结论

大多数人会继续往一个智能体中塞入更多能力，看着它变慢、退化，然后得出结论：智能体还不够成熟。

而构建团队的人会拥有不同的东西：一个负责委派的协调员、在各自上下文中并行工作的专家、一个他们协作的共享文件系统，以及一个让整个团队随时间变得更聪明的记忆存储。

选择一个可以拆分为并行任务的工作。规划三个专家和一个协调员。先构建那个小团队。 仅这一步就能彻底改变你的智能体所能处理的工作量。