第一次让 Claude Code 创建一个团队时，我以为它和我现有的子智能体工作流差不多——只是更快而已。五个智能体……
我做了好几个月的多智能体工作流。智能体团队只用一个会话就取代了我自定义的调度逻辑——但它的局限也真实存在。
第一次让 Claude Code 创建一个团队时，我以为它和我现有的子智能体工作流差不多——只是更快而已。五个智能体做之前一个智能体做的事，对吧？并行执行更多，汇报结构不变。
事实并非如此。
注：本文部分研究由 AI 辅助完成。文中所有测试、真实观察与局限均为我本人独立记录。
我亲眼看到研究智能体直接给探索智能体发消息。不经过我。也不经过协调器。
一个智能体对另一个说：
“我找到了三种实现这个技能的模式——第三种有依赖问题，你在开发前最好检查一下。”
探索智能体在我完全没插手的情况下，直接调整了自己的方案。
我已经用 Claude Code 搭建多智能体工作流好几个月了。我发布过一个《30 个专业子智能体系列》，成为我阅读量最高的技术文章之一。但这次完全不同。子智能体是向你汇报。智能体团队是互相交流。
这场快得超出所有人预期的进化
先回顾一下。如果你一直在关注 Claude Code 的多智能体发展，我们之前的状态是这样的：
子智能体（我们大多数人一直在用的）是专注型工作者。你在 ~/.claude/agents/ 里用 Markdown 文件和 YAML 前置配置定义它们。它们有自己的上下文窗口，完成任务后向你汇报。父智能体统一调度一切。可以理解成经理给外包人员派活——每个人独立干活、交付结果、然后结束。
它的局限是什么？外包人员之间不沟通。如果你的安全审核人员发现了会影响后端架构师工作的问题，信息必须经过你中转。你会变成自己多智能体系统里的瓶颈。
智能体团队（2026 年 2 月 5 日发布）彻底颠覆了这个模式。不再是孤立的工作者向经理汇报，而是一个拥有共享任务看板和点对点通信的团队。团队负责人（Team Lead）负责协调，但成员之间可以互相发消息、标记依赖、根据他人发现调整工作。
这套系统能运转，靠三个核心组件：
1
**团队负责人（Team Lead）**你当前的 Claude Code 主会话。负责规划、分派、监控。不需要自己做所有事。
2
**团队成员（Teammates）**独立的 Claude Code 实例，每个都有自己的上下文窗口、加载 CLAUDE.md、连接 MCP 服务、拥有可用技能。
3
**共享任务列表（Shared Task List）**任务有三种状态：待处理 → 进行中 → 已完成。支持依赖关系——任务 A 完成后，任务 B 自动解锁。
思维模型的转变：
从“跑腿的外包人员”变成“一支会协作的团队”。
[## 调度 Claude Code 会话组成的团队 - Claude Code 文档
协调多个 Claude Code 实例以团队形式协作，支持共享任务、智能体间消息传递……
claude.com](code.claude.com/docs/en/age…)
搭建：5 分钟启用智能体团队
这仍是实验性功能。Anthropic 没有隐瞒这一点——需要显式开启开关。下面是启用方法。
方案 1：配置文件（持久生效）
在你的 Claude Code settings.json 中添加：
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
方案 2：环境变量（仅当前会话）
export
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS
=
1
前置条件
•
Claude Code（最新版）
•
我使用的是 Opus 4.6（2026 年 2 月 5 日发布）——模型版本对协调质量影响很大
•
充足的 API 额度——后面会讲到 Token 消耗的现实问题
你的第一个团队
启用后，创建团队只需要自然语言。不需要配置文件，不需要 YAML：
"创建一个团队，用于开发一个自动化代码审查的 Claude Code 技能。
我需要一个智能体研究现有模式，一个探索最佳实现方案，还有一个负责编写实际的技能文件。"
Claude Code 会自动生成团队负责人（你的会话），创建任务看板，并启动成员。你会实时看到任务分配。
运行后端选项
有三种执行后端控制团队成员如何运行：
| 后端 | 工作方式 | 最适合 | | --- | --- | --- | | 进程内（In-process） （默认） | 成员在同一进程内运行 | 快速任务、更低资源开销 | | tmux 分屏 | 每个成员一个可见终端面板 | 调试、实时观察智能体协作 | | iTerm2 | 仅 macOS，原生标签页集成 | 喜欢可视化监控的 macOS 开发者 |
第一次使用建议先用进程内模式。想亲眼看到真实协作过程时再切到 tmux——看着智能体在不同终端面板里实时协调，真的很震撼。
我实际测试了什么
我目前正在为我的开源项目（claude-code-skill-factory）开发新的 Claude Code 技能。这是非常合适的场景——多个技能需要调研、模式探索和实现，天然具备并行性。
我的团队配置
我创建了一个分工明确的团队：
•
研究智能体梳理现有技能模式、分析文档、总结最佳实践
•
探索智能体测试不同实现方案、验证可行性
•
构建智能体编写实际的 SKILL.md 文件、Python 脚本和校验逻辑
让我惊喜的地方（优点）
研究智能体和探索智能体的输出质量非常高。不是“勉强能用的初稿”，而是真的很好。研究智能体不只是总结文档，它还会跨多个技能实现对比模式，并指出我之前都没注意到的不一致之处。
探索智能体基于这些发现，测试了我自己都不会尝试的方案。当某个方案遇到依赖问题时，它会切换到备选方案，并把原因、失败路径一起发给构建智能体。这种经验知识通常只存在于人脑里，几乎不会被文档化。
点对点消息机制是它和智能体最本质的区别。当研究智能体发现某个技能模式已被废弃时，探索智能体几分钟内就知道了——完全不需要我中转。在我之前的子智能体工作流里，这类协调永远是手动的。
让我意外的地方（缺点）
**会话隔离是最大痛点。**每个成员都运行在独立环境中。代理 A 无法访问智能体 B 创建的文件。如果探索代理在自己的工作区生成了原型，构建代理无法直接看到。你最终还是要在代理之间手动传递文件，这在一定程度上抵消了点对点协作的意义。
这不是 Bug——而是为了安全和上下文管理做出的架构设计。但这意味着你的团队更像没有共享仓库的远程开发者，而不是共用代码库的同地工程师。
Token 消耗明显更高。我目前还没有精确的倍数——实验仍在进行中——但 5 个成员就意味着 5 套独立上下文，每个都要加载 CLAUDE.md、独立处理。Anthropic 文档说 Token 消耗大致呈线性增长，和我观察到的一致。对研究和探索类任务来说，价值对得起成本。但对常规实现任务？大概率不值。
决策框架：什么时候用什么
在同时使用代理团队和原有子代理工作流后，我整理了一套 CTO 级决策矩阵：
适合用代理团队的场景：
•
并行探索同一个问题有多种方案，需要同时测试
•
跨领域协调安全审查 + 性能审查 + 测试覆盖，一个领域的发现会影响另一个
•
重度研究任务需要在开发前综合多方视角
•
多假设验证你不知道正确方案，让代理自己讨论验证
适合用子代理的场景：
•
专注、隔离的任务单文件代码审查、文档生成
•
对 Token 敏感的工作预算有限，子代理更轻量
•
定义清晰的范围你明确知道要什么，不需要探索
•
串行依赖步骤 2 必须等步骤 1 完全结束才能开始
适合用单会话的场景：
•
同一文件编辑多代理编辑同一文件会产生合并冲突
•
简单任务一个代理 10 分钟能搞定的事，别开五个
•
调试需要反复迭代，而不是并行
•
强上下文工作理解全局比速度更重要
警惕“代理集群陷阱”
不是所有任务都需要团队。我已经看到开发者给本来单个代理就能做好的任务强行上多智能体。协调的开销——任务管理、消息路由、上下文重复——都是成本。
经验法则：能用一句话描述清楚的任务，用一个代理。任务包含三个及以上独立工作流，且确实需要不同视角时，再考虑团队。
目前还不完美的地方（尚未支持）
这是实验性软件。当成生产环境用一定会让你失望。我遇到的问题如下：
**会话管理还很粗糙。**进程内成员不支持会话恢复。主会话结束，成员全部消失。对长时间任务，要把工作拆成可完成的小块，而不是跨几天的大项目。
**任务状态延迟。**成员有时会忘记把任务标为已完成。任务看板显示“进行中”，但实际早已结束。有依赖任务时会造成不必要延迟。临时方案： 让团队负责人提醒成员更新状态。
**一个会话只能一个团队。**不支持嵌套团队或同一会话开多个团队。需要层级协调（团队中的团队）的复杂项目，要拆成连续的团队会话。
**关闭速度慢。**结束会话时，系统会等每个成员完成当前请求再关闭。5 个成员可能需要一分多钟。
没有共享文件系统。前面提到过——每个代理的工作区都是隔离的。这是实际使用中最麻烦的限制。我相信未来会改进，但现阶段要把任务拆成可通过消息传递的产物，而不是共享文件。
**我还在摸索最佳团队规模。**3 个成员效率很高。5 个时，协调开销开始超过并行收益。Anthropic 做过 16 个代理的压力测试（他们的 C 编译器项目——10 万行 Rust，API 成本 2 万美元），但那不是常规工作流。日常开发，我建议从 3–4 个成员开始，只有任务确实受益于更多并行流时再扩容。
我对未来的判断
**坦率的战略判断：*****多智能体调度正在成为 AI 辅助开发的默认模式。***不是明年。就是现在。
演进路径非常清晰：
单代理（2024）→ 子代理（2025 年中）→ 代理团队（2026 年 2 月）
我认识的每个 Claude Code 用户都自己造过多智能体工作流——用脚本启动多个实例、用 tmux 手动协调、写自定义调度层。我们所有人都提前造出了 Anthropic 现在官方提供的功能。
这就是信号。当整个社区都在造同一种“ workaround”，平台就会跟进。代理团队就是 Anthropic 在说：“我们看到你们在做什么了。这是官方基础设施。”
对于已经有成熟子代理工作流的 Claude Code 用户：是时候进化了。不是抛弃——是进化。你现有的子代理配置依然能用。CLAUDE.md 依然能加载。但调度层已经内置，继续维护自定义脚本会变成技术债务。
Anthropic 的压力测试——16 个代理构建能编译 Linux 内核的 Rust C 编译器——不只是演示。它在宣告上限在哪里。我们大多数人都会远低于这个上限，但知道上限存在，会彻底改变你对可能性的认知。
诚实的总结
我会把代理团队用在所有场景吗？不会。会话隔离、Token 成本、实验性的粗糙边缘，让我只会选择性使用。
我还能退回到只用子代理吗？ 也不会。对重度研究和探索任务，看着代理互相协调、质疑彼此的结论，产出比我手动调度好得多。
真相在中间——这没问题。调度能力确实惊艳。基础设施还不完全成熟。两件事可以同时成立。
**我下一步要测试的：**在生产级软件上运行代理团队，而不只是开源技能开发。那才是真正的压力测试——更严格的约束、更高的 stakes、更少容忍实验性缺陷。
**如果让你给一组代理分配第一个任务，你会让它们做什么？**我很好奇你会优先测试哪些场景。
✨ 感谢阅读！如果你想了解更多 AI 开发工具和多智能体系统的实战心得，欢迎订阅关注。
本文基于我之前关于 Claude Code 多智能体的系列文章。如果你不熟悉子代理，可以先从这篇开始：《2026 年你需要的 30 个专业 Claude Code 子代理》
Claude Code（兼容 Claude AI 桌面端）开源项目地址：
GitHub - alirezarezvani/claude-skills: 适用于 Claude Code 和 Claude AI 的技能集合……
也可以直接在 Claude Code 里用这条命令安装插件：
/plugin marketplace add alirezarezvani/claude-skills
# 然后安装技能包：
/plugin install marketing-skills@claude-code-skills # 5 个营销技能
/plugin install engineering-skills@claude-code-skills # 18 个工程技能
/plugin install product-skills@claude-code-skills # 5 个产品技能
/plugin install c-level-skills@claude-code-skills # 2 个高管顾问技能
/plugin install pm-skills@claude-code-skills # 6 个项目管理技能
/plugin install ra-qm-skills@claude-code-skills # 12 个合规/质量技能
# 或单独安装单个技能：
/plugin install content-creator@claude-code-skills # 内容创作者
/plugin install fullstack-engineer@claude-code-skills # 全栈工程师
