一个人指挥一支 AI 团队：用 Claude Code 打造你的多 Agent 开发军团

发表于 更新于 分类于 阅读次数： 本文字数： 4.8k 阅读时长 ≈ 4 分钟

cover

你一个人在终端里写代码。

但你旁边有一个 Agent 在帮你审查 PR，另一个在写测试，第三个在查数据库，第四个在生成文档。它们各干各的，互不干扰，最后把结果汇报给你。

这不是什么遥远的未来。这是 2026 年 3 月，Claude Code 已经支持的能力。

Anthropic 在 Opus 4.6 发布时，正式推出了 Agent Teams 功能。一个编排者（Orchestrator）可以同时调度最多 10 个子代理，并行处理任务，通过共享任务列表和消息系统协调工作。

有人用 13 个 Agent 搭了一套完整的开发流水线，每个 Agent 负责一个环节，还能互相审查对方的工作。

今天这篇文章，我来拆解 Claude Code 的多 Agent 体系，帮你搞清楚：子代理、Agent Teams、Skills、MCP 这些概念到底是什么关系，怎么用它们搭建你自己的 AI 开发团队。

先理清概念：你手里有哪些”兵种”

Claude Code 的多 Agent 生态有四个核心组件，它们各司其职：

组件 角色 类比
子代理（Subagents） 干活的工人 外包的自由职业者
Agent Teams 协作的团队 能互相沟通的项目组
Skills 专业知识库 工人手里的操作手册
MCP Servers 外部连接器 通往数据库、API、工具的桥梁

一句话总结：Skills 教会 Agent 怎么做，MCP 让 Agent 能连接外部世界，子代理负责并行干活，Agent Teams 让多个代理之间能协商。

子代理：你的平行分身

子代理是 Claude Code 多 Agent 能力的基础。当你的任务足够复杂时，Claude 会自动（或你手动要求它）生成子代理来并行处理。

工作原理

每个子代理有自己独立的上下文窗口。它接收一个任务，独立完成，然后把结果返回给主代理。主代理只看到结果摘要，不会被子代理的中间过程”污染”。

这是子代理最大的价值——不是并行速度，而是上下文隔离。

想象一下，你让 Claude 调研一个技术方案。它需要读 10 个文件、查 3 个 API 文档、对比 5 种实现方式。如果全在主对话里做，20 万 Token 很快就被中间结果塞满了。但如果让子代理去做调研，主代理只收到一份干净的总结。

一位深度用户说得很到位：

“子代理的真正价值是：所有中间噪音留在子代理的上下文里，主代理只拿到信号。”

实际用法

你可以让 Claude 自动决定是否使用子代理，也可以显式要求：

1
2
3
4
5
6
帮我用子代理并行完成这三件事：
1. 调研目前主流的认证方案（OAuth 2.0, Passkey, Magic Link）
2. 审查 src/auth/ 目录下现有代码的安全性
3. 生成认证模块的测试用例

每个任务独立完成，最后汇总给我。

Claude Code 最多可以同时运行 10 个子代理。

成本提醒

子代理不是免费的。每个子代理都开一个新的上下文窗口，Token 消耗是累加的。Anthropic 文档明确指出：多代理工作流的 Token 消耗大约是单代理的 4-7 倍。用之前想清楚，这个任务是否真的值得并行。

Agent Teams：能互相”说话”的代理团队

子代理有一个局限：它们只能跟主代理单线通信，不能互相沟通。如果你需要多个代理之间协调配合，就要用 Agent Teams。

和子代理的区别

子代理 Agent Teams
通信模式 只跟主代理通信 代理之间可以互相通信
协作方式 完成任务后交付结果 持续协作，共享任务列表
适用场景 独立的并行任务 需要协调的复杂项目
Token 成本 4-7x ~15x

打个比方：子代理像你外包给自由职业者的任务，各做各的；Agent Teams 像你带的一个项目组，成员之间需要开会、对齐、互相 Review。

怎么启用

Agent Teams 目前是实验性功能，默认关闭，且需要使用 Opus 4.6 模型。启用步骤：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 创建配置目录
mkdir -p ~/.claude

# 添加 Agent Teams 配置到 settings.json
cat >> ~/.claude/settings.json << 'EOF'
{
  "agentTeams": {
    "enabled": true
  }
}
EOF

# 验证配置
claude /team

启用后，你可以用 /team 命令进入团队模式，或者直接描述一个复杂任务让 Claude 自动组建团队。

团队协作机制

Agent Teams 有几个关键的协作机制：

  • 共享任务列表：所有代理都能看到、认领和更新任务
  • 消息邮箱：代理之间可以互相发消息
  • 直接消息 & 广播：可以给特定代理发消息，也可以广播给全员（但广播成本随团队规模翻倍）
  • Team Lead：一个代理作为组长，负责分配任务和汇总结果

每个 Teammate 启动时会自动加载项目的 CLAUDE.md、MCP 服务器和 Skills，保持和主代理一致的项目上下文。

Skills：给你的 Agent 装上”技能包”

光有 Agent 还不够。一个什么都不懂的 Agent 就像一个没经过培训的新员工——你得教它。

Skills 就是那份”培训手册”。

Skills 是什么

一个 Skill 就是一个 SKILL.md 文件，包含 YAML 元数据和具体的指令。它告诉 Claude 在遇到特定类型的任务时应该怎么做。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
---
name: frontend-design
description: Generate production-ready React components with modern design patterns
tools:
  - Read
  - Write
  - Edit
  - Bash
---

## Instructions

When generating React components:
1. Use TypeScript with strict mode
2. Follow atomic design principles
3. Include Storybook stories
4. Write unit tests with React Testing Library
...

Skills 可以通过斜杠命令显式调用（/frontend-design），也可以在 Claude 识别到相关任务时自动触发。

怎么安装

1
2
3
4
5
6
7
8
# 安装社区 Skill
npx skills add ultralytics/superpowers

# 安装到全局（所有项目可用）
npx skills add khanglvm/agent-memory -g

# 安装到当前项目
npx skills add github.com/user/my-skill

截至 2026 年 3 月，社区已有 1,234+ 个 Skills，覆盖前端开发、数据库操作、AWS 部署、代码审查、文档生成等各种场景。

Skills 和 Agent 的关系

Skills 教会 Agent 做特定类型的事。 比如你有一个”数据库迁移” Skill，任何需要做数据库变更的子代理都会自动加载这个 Skill，按照你定义的规范来操作。

一个类比：MCP 是厨房里的刀、锅、食材。Skill 是告诉厨师怎么用这些工具的菜谱。

MCP：连接外部世界的桥梁

MCP（Model Context Protocol）是让 Claude Code 能够和外部系统交互的标准协议。把它理解为”AI 的 USB-C 接口”。

常见的 MCP 服务器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 连接 PostgreSQL 数据库
claude mcp add postgres -- npx @modelcontextprotocol/server-postgres

# 连接 GitHub
claude mcp add github -- npx @modelcontextprotocol/server-github

# 连接文件系统
claude mcp add filesystem -- npx @modelcontextprotocol/server-filesystem

# 连接 Slack
claude mcp add slack -- npx @anthropic-ai/mcp-server-slack

# 连接浏览器（Playwright）
claude mcp add browser -- npx @anthropic-ai/mcp-server-playwright

目前社区已有 50+ 个 MCP 服务器。当你的 Agent 需要查数据库、读邮件、发 Slack 消息、操控浏览器时，就是通过 MCP 实现的。

MCP + Agent 的组合威力

想象这个场景：你让一个子代理去分析线上问题。它通过 MCP 连接到 PostgreSQL 查询异常数据，连接到 Slack 读取相关的报警消息，连接到 GitHub 查看最近的 commit，然后综合所有信息给你一份根因分析报告。

这就是 MCP 的价值——让 Agent 不只活在代码里，而是能触达你的整个工作环境。

实战案例：一个三阶段的生产级流水线

有开发者分享了一个经过验证的三阶段子代理流水线：

阶段 1：PM-Spec Agent

  • 读取需求输入
  • 生成结构化的规格文档，包含验收标准

阶段 2：Architect-Review Agent

  • 验证规格文档是否符合平台约束
  • 输出架构决策记录

阶段 3：Implementer-Tester Agent

  • 根据规格编写代码和测试
  • 更新文档

主代理（Claude Code 自身）作为编排者，协调这三个阶段的执行顺序和数据传递。

这个模式的关键洞察是：每个子代理用全新的上下文启动，不会从之前的阶段继承噪声。规格文档和架构决策作为显式的”接力棒”在阶段之间传递，而不是隐式的上下文堆积。

怎么选：子代理还是 Agent Teams？

一个 60 秒决策框架：

用子代理，当：

  • 任务可以完全独立完成
  • 不需要代理之间互相沟通
  • 你想控制成本（4-7x vs 15x）
  • 典型场景：并行调研、批量代码审查、独立模块开发

用 Agent Teams，当：

  • 任务之间有依赖关系
  • 需要代理互相验证对方的工作
  • 项目复杂到需要持续协调
  • 典型场景：全栈功能开发、大规模重构、跨模块 Bug 修复

大多数时候，从子代理开始就够了。 等你发现子代理之间需要频繁同步信息时，再升级到 Agent Teams。

给新手的建议

1. 先建 Skills，再建 Agent

不要急着搭复杂的多 Agent 架构。先把你团队的编码规范、架构模式、测试策略写成 Skills。一个高质量的 Skill 比多加三个 Agent 更有效。

2. 每周做两次以上的事，就封装成子代理

PR Review、数据库迁移、部署前检查——这些重复性工作最适合用子代理自动化。把它们放到 .claude/agents/ 目录，限制好工具权限。

3. CLAUDE.md 是一切的基础

所有 Agent 启动时都会读取 CLAUDE.md。与其反复在 Prompt 里纠正 Claude 的行为，不如把规则写进 CLAUDE.md。修上下文，而不是修对话。

4. 注意成本

多 Agent 工作流的 Token 消耗远超单 Agent。用之前问自己：这个任务值得 5 倍的成本吗？如果只是一个简单的 Bug 修复，单 Agent 就够了。

写在最后

2025 年，我们在讨论”AI 能不能写代码”。

2026 年，我们在讨论”一个人能指挥多少个 AI 同时写代码”。

Claude Code 的多 Agent 体系——子代理、Agent Teams、Skills、MCP——本质上是在回答一个问题：一个人的生产力上限在哪里？

答案可能比你想的更远。一个懂得编排 Agent 的开发者，产出可以比得上一个小团队。这不是营销话术——当你有 10 个 Agent 并行处理不同模块，每个 Agent 都装载了你定义的 Skills，通过 MCP 连接到你的所有工具时，瓶颈不再是写代码的速度，而是你定义问题的速度。

未来最稀缺的不是写代码的人，而是能编排一支 AI 团队的人。

你用过 Claude Code 的子代理或 Agent Teams 吗？你会怎么设计你的 AI 团队分工？欢迎在评论区聊聊你的想法和实践经验。