对于复杂的多领域工作流，仅依赖单个 AI 会话本质上是低效的。Claude agent 团队通过并行执行多个专用 agent 解决了这一问题，从而以更高的速度交付更深入的结果。本指南将介绍 Claude Code agent 团队的工作原理、搭建方法，以及最大化其价值的最佳实践。
什么是 Claude agent 团队
Claude Code agent 团队是一种多实例协作系统，多个 Claude 会话在同一代码库上并行工作。其中一个会话被指定为主控 agent，负责接收整体任务、将其拆解为子任务，并整合最终输出。其余的子 agent 则作为队友，每个队友都运行在各自独立的上下文窗口中，负责一部分具体工作，并可直接与其他队友通信。
agent 团队的优势
agent 团队与常见的 AI 助手不同之处在于：后者按顺序逐一处理任务，而 agent 团队打破了这一限制——当工作可以真正实现并行化时，实际耗时也会相应缩短。
同时，agent 团队不只是多个会话的简单叠加，协同层还带来了手动多会话操作所不具备的三项能力：
点对点消息传递： 队友之间可以直接互相发送消息，无需经过你或主控中转。例如，在一个包含安全审查员的 agent 团队中，安全审查员可以在运行过程中随时向性能审查员标记发现的问题，而不会中断整个团队的工作。
文件锁定： 当某个队友写入文件时，会获取一个锁，阻止其他 agent 同时写入。这样可以避免因静默覆盖而引发的合并冲突。
依赖跟踪： 主控在拆解任务时会编码任务之间的依赖关系，协同层会强制执行这些依赖，确保没有任何 agent 会在其前置条件满足之前开始工作，且无需手动轮询检查。
agent 团队实际是如何运作的
一个 agent 团队由以下几个部分组成，各自承担特定角色：
团队主控是主 Claude Code 会话，负责创建团队、启动队友、协调各队友的工作，并整合最终结果。这也是你直接交互的会话。
队友是独立的 Claude Code 实例，各自在自己的上下文窗口中独立完成分配的任务。它们不与主控或彼此共享上下文，所有通信都通过任务列表和消息箱明确进行。
共享任务列表和消息箱共同实现协同工作。**共享任务列表是 agent 群组共同读写的实时队列：主控在拆解任务时填充队列，队友则认领任务、逐一完成并标记为已完成。依赖关系会被自动强制执行——当某个队友完成一项任务后，任何因它而被阻塞的任务都会自动解除阻塞，无需人工干预。消息箱则是用于 agent 之间直接通信的消息系统，消息会在队友与主控之间自动传递。
团队配置和任务列表都保存在本地（~/.claude/teams/ 和 ~/.claude/tasks/）。Claude Code 会自动生成并维护这些文件，请勿手动编辑，因为任何改动都会在下一次状态更新时被覆盖。
如何搭建 Claude Code agent 团队
在 Claude Code 中，Claude agent 团队功能默认是关闭的，被标记为实验性功能，需要手动开启。以下是完整的设置流程。在启用 agent 团队之前，请确认你的 Claude Code 版本为 v2.1.32 或更高**。**可以在终端中运行 claude --version 进行检查。
第一步：启用功能开关
将环境变量 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 设为 1。有以下三种方式：
方式 A：~/.claude/settings.json（推荐）
方式 B：Shell 配置文件（~/.bashrc 或 ~/.zshrc）
方式 C：内联设置，仅对单次会话生效
如果你修改了 settings.json 或 shell 配置文件，需要重启 Claude Code 才能使该设置生效。
第二步：安装 tmux（推荐，非必须）
agent 团队有两种显示模式：进程内模式（所有队友都在主终端内运行）和分屏模式（每个队友拥有独立面板，需要 tmux 或 iTerm2）。让每个队友在自己独立的终端面板中运行，可以更方便地实时监控整个团队的工作。
要确保保持在分屏模式，请在 ~/.claude/settings.json 中设置 teammateMode：
要覆盖默认的“auto”设置，可在 ~/.claude/settings.json 中将 teammateMode 设为 in-process。若只想在单次会话中强制使用进程内模式，可通过参数传入：claude --teammate-mode in-process。
第三步：通过提示词启动你的 agent 团队
启用 agent 团队后，只需用自然语言告诉 Claude 你希望 agent 团队完成什么任务、交付什么成果以及采用怎样的团队结构。你可以在提示词中指定各个角色，Claude 会据此创建团队、启动队友，并安排任务。
示例提示词：
你可以指定智能体团队使用的模型，例如“让每个团队成员都使用 Sonnet”。团队成员不会继承主智能体的模型。用户必须在角色文件的 frontmatter 中指定模型，或通过 /config 设置默认的团队成员模型。
步骤 4：为复杂任务申请计划审批（可选）
对于风险较高、复杂度较大的任务，你可以要求团队在执行前先制定计划。智能体群组中的团队成员将以只读模式工作，由主智能体审阅、修订并最终通过计划。只有当计划通过主智能体审批后，团队成员才会开始执行。
请注意，主智能体会做出决策，因此你也可以为其决策提供一些标准。
示例提示词：
步骤 5：设置 git worktree 以实现文件隔离（可选，推荐）
如果有团队成员需要写入文件，强烈建议使用 Claude Code worktree。git worktree 是一个独立的工作目录，运行在自己的分支上，同时与主工作区共享同一份 .git 历史记录。每个智能体都拥有独立的文件访问权限，一个 worktree 中的编辑不会影响另一个智能体正在进行的工作。
要为某个智能体启用此功能，只需在该智能体的 YAML frontmatter 中添加 isolation: worktree。Claude Code 会为每次并行的智能体调用创建一个全新的 worktree，并在该智能体完成后自动清理。
命令行使用方式：claude --worktree 或 claude -w 会在其自己的 worktree 中启动会话。桌面应用会为每个会话自动创建一个 Claude Code worktree。
步骤 6：定期监控
智能体团队并非设置后就能放任不管，长时间运行的团队可能会出现偏差。智能体可能会卡在权限提示上、过早将任务标记为完成，或者偏离既定范围。你可以每 10 到 15 分钟检查一次，查看共享任务列表中是否存在卡住或无人认领的任务。如果某个任务在 20 到 30 分钟内没有进展，可能是遇到了权限限制，或角色设置有误，需要人工介入。
对比一览：子智能体与智能体团队
子智能体是一种委派模式，智能体团队则是一种协作模式。这一差异会影响方方面面，从上下文的管理方式到运行成本的高低。
| 子智能体（Subagents） | Agent teams | |
|---|---|---|
| 通信方式 | 单向：主控分派任务，子智能体汇报结果 | 点对点通信 + 主控协调 |
| 共享状态 | 无 | 带依赖关系跟踪的共享任务列表 |
| 上下文窗口 | 拥有独立的上下文窗口；结果返回给主控 | 每个成员拥有各自的上下文窗口（最多 1M token） |
| 文件冲突预防 | 未内置 | 内置文件锁定机制 |
| token 成本 | 较低 | 较高（每个成员都是一个独立实例） |
| 会话恢复 | 支持 | /resume 和 /rewind 不会恢复进程中的成员 |
| 嵌套 agent | 支持 | 不支持；只有主控可以创建成员 |
| 适用场景 | 专注型任务委派、可重复的工作流程 | 可并行、相互依赖、跨领域的工作 |
子智能体是一种单向委派模式：主智能体发出任务，子智能体在自己的上下文窗口内执行，然后返回结果。没有共享状态，兄弟智能体之间没有直接通信，也没有协调层，只是一个简洁的“分发—返回”循环。
智能体团队则在共享任务列表上协作，具备自动的依赖关系管理，团队成员之间可通过邮箱进行点对点消息传递。
简而言之，当工作可以拆分为真正独立的并行任务线，且这些任务线之间需要共享发现并相互协调时，智能体团队才能发挥价值。而对于追求快速结果、顺序执行的任务、单文件编辑，或者成本可预测性比速度更重要的场景，子智能体是更好的选择。
何时选择智能体团队，何时选择子智能体
适合使用智能体团队的情形：
团队成员之间需要直接沟通
工作需要在多条并行工作流之间维护带依赖关系的共享任务列表
任务规模过大，单一会话无法承载，每个工作者都需要拥有各自完全独立的上下文
适合使用子智能体的情形：
你只需要最终摘要，而不需要完整的中间输出
任务本身足够自成一体，能够独立返回一个干净的结果
你想限制可用工具，或将任务路由到成本更低的模型
你需要多条互不依赖的并行研究路径
如果你无法识别出至少三条真正独立的并行工作流，那么单一会话或子智能体往往会以更低的成本取得更好的效果，胜过智能体团队。
智能体团队的实际应用场景
当工作能够自然地划分为范围明确、边界清晰的工作流，这些工作流可以彼此独立推进（或者它们之间的依赖关系可以被明确编码），并且协调开销相对于并行执行所节省的时间来说很小时，智能体团队的价值就会显现。以下是五个智能体团队优于单一会话的实际应用场景。
并行代码审查
同时为一个 pull request 分配三名审查者，分别是安全智能体、性能智能体和测试覆盖率智能体。主智能体会将三份并行报告汇总成一份带优先级的行动清单。这种模式同样适用于架构审查（可伸缩性智能体、安全智能体、可维护性智能体），也适用于跨不同监管框架的合规检查。
多假设并行调试
针对一个生产环境的 bug，创建五个智能体，每个各持一种假设，分别检查特定的文件或日志。最先确认自己假设成立的智能体给出修复方案，其余智能体即可停止。相比按顺序逐一排查每种猜测、在一条思路上耗费数小时调试后又回退重来，这种方式效率更高。
跨层重构
跨层重构任务通常既包含顺序步骤，也包含并行步骤。例如，一次破坏性的 API 变更需要同时更新后端接口、调用这些接口的前端组件，以及覆盖两者的测试套件。后端工作必须先完成，前端才能开始。而一旦后端任务开始进行，测试套件智能体就可以并行搭建新的测试结构框架。在智能体团队中，主智能体会利用共享任务列表的依赖关系管理功能来编码这种先后顺序。
无上下文污染的调研排查
一项技术决策可能需要调研多个相互独立的证据体系，例如选择数据库引擎、评估三个第三方 API、以及评估构建工具链。为每个智能体分配一个互不重叠的领域，各自发布一份结构化摘要，再由主智能体汇总成对比文档。这种隔离保留了各自独立的视角，从而提升结果的质量。
大型代码库迁移
在大型代码库中升级一个主要依赖项，通常会涉及多个模块。如果这些模块边界清晰、可以同时迁移，智能体团队就能发挥作用。为每个独立模块分配一个智能体：各自迁移所负责的模块、运行自己的测试套件，并汇报迁移摘要，其中包括任何发生变化的接口。主智能体会在宣布迁移完成前审查这些接口变更，并协调合并顺序。
设计 Agent 团队时该做和不该做的事
用 Claude Code 搭建并行 agent 系统上手很简单，但也很容易出错。以下设计原则决定了你的 agent 团队是真正发挥作用，还是白白浪费时间。
构建并行 agent 系统的实用建议
提前批准权限： 队友智能体启动时会继承 lead 的权限设置。如果 lead 以 --dangerously-skip-permissions 模式运行，所有队友也会继承这一设置。生成之后你可以调整单个队友的模式，但队友的模式无法在生成时单独配置。因此在启动团队之前，就要通过 lead 规划好整体的权限策略。
写出精炼的角色提示词： 每条角色提示词都应说明四件事：要做什么、在哪些文件或领域内工作、重点关注什么以及要排除什么，以及交付物应是什么样子。生成队友时，你可以引用来自任意子智能体范围（项目、用户、插件或 CLI 定义）的子智能体类型。这样你只需定义一次角色——比如安全审查员或测试执行者——就能同时把它作为委派子智能体和 agent 团队队友复用。
严格执行文件隔离： 对于任何要写入磁盘的智能体，都要做好隔离。两个智能体同时修改同一个文件，是产生输出损坏最常见的原因之一。
按固定节奏检查进度： 活跃的 agent 团队建议每 10–15 分钟检查一次。留意共享任务列表中长时间没有进展的任务。如果某个任务卡住超过 20–30 分钟，可能是权限问题、角色定义不当，或存在循环依赖，这类情况通常需要人工介入解决。
显式编码依赖关系： 如果任务 B 在逻辑上依赖任务 A，就应在任务分解阶段把这种依赖关系写入任务列表，而不是作为角色提示词中的一条指令。协调层会自动执行依赖关系；而写在提示词里的指令则可能被误读或忽略。
在 md 文件中明确划定所有权边界： 对于跨多个会话的项目，写一条规则，确保每个模块或目录只有一个负责的智能体。这样可以在团队启动之前就避免职责重叠。
清理工作始终通过 lead 进行，而不是通过队友： lead 会在清理资源之前检查是否还有活跃的队友。队友缺乏完整的团队上下文，无法安全地执行清理操作；如果由队友来做，可能导致会话状态不一致。
组建 agent 团队时可以避免的常见错误
不要为一个单一会话就能干净处理的任务组建团队： 在写第一个角色文件或发出第一条集群提示词之前，先画出任务图。哪些子任务是真正独立的？哪些存在依赖关系？这是一项需要顺序完成的工作吗？如果你无法说清三条边界清晰的并行任务线，那么单一会话的表现会优于团队协作。
不要让两个智能体处理同一个文件。 这是合并冲突和静默覆盖最常见的原因。如果任务分解后发现两个智能体都需要接触同一个组件，那这部分工作就应该顺序执行——由一个智能体完成后再交给另一个。
不要跳过 Claude Code 中的权限预批准环节。 运行中途弹出的权限提示会打断并行执行，需要人工介入处理，这种额外开销会抵消并行带来的大部分收益。启动前应提前为工作目录批准文件写入和 shell 命令的执行权限。
不要指望能恢复你的 Claude Code 团队。 如果会话被清理，/resume 和 /rewind 都无法恢复进程中的队友智能体。长时间运行前应保存好重要的中间输出。
如果没有明确理由，团队规模不要超过五个智能体。 token 成本是线性增长的，但协调开销的增长速度更快。三个角色定义清晰、专注的智能体，表现通常会持续优于五个角色模糊的智能体。只有在确实存在待处理的并行工作流时才增加队友——而不是因为“人多力量大”的直觉。
另一种范式：在 Kimi Agent Swarm 中搭建你的多智能体团队
Claude Code 的 agent 团队在开发者原生场景中表现出色，能与终端工作流和 Git 生态深度集成。不过，多智能体协作这一范式远不止于命令行场景。Kimi Agent Swarm 让这种范式真正面向所有人开放。
Kimi Agent Swarm 是 Kimi 为复杂、大规模任务打造的多智能体协作系统。它会将一个宏观目标拆分成若干离散子任务，并调度不同的智能体和技能，同时处理搜索、阅读、分析、写作、编程、生成电子表格、制作 PPT 以及构建网页等工作。无需设置环境变量，也不需要配置 Git。
Kimi Agent Swarm 的核心特性
最多可并行协作 300 个子智能体： Kimi Agent Swarm 会将复杂任务拆解，并调度多个子智能体同时处理各项子任务。系统能够协调多达 300 个子智能体，在单次运行中执行超过 4,000 次工具调用。
多技能复合执行： Agent Swarm 可以在单次运行中组合多种专项技能，包括深度研究、生成 PPT、撰写报告、氛围编程（vibe-coding）、建站、撰写论文等，在输出深度和格式覆盖面上都超越单一智能体。
大规模文档处理： Agent Swarm 可以批量处理 20 多种格式的文件（PDF、Word、Excel、PPT、图片等），在整套文档范围内并行完成阅读、信息提取和内容总结，能够处理参考资料库、竞品情报文件或多来源数据汇集等场景。
主动式广域研究： 对于需要覆盖广泛信息面的任务，Agent Swarm 会派出多个子智能体并行搜索网页、定位来源、下载内容、对结果进行分类，并生成结构化摘要。
多视角推理： Agent Swarm 可以针对同一问题同时运行多个专家视角，从而得到比单一视角更完整的分析，并发现顺序审查容易遗漏的盲点。
深度内容产出： Agent Swarm 的并行架构专为持续深度的输出而设计，适合生成数百页的研究报告、长篇行业分析、学术文献综述、结构化学习指南以及长篇叙事内容等。
单次运行输出多种格式： 针对同一任务，Agent Swarm 可以同时产出多种类型的交付物，例如 PDF 报告、PPT 演示文稿、网页、Excel 数据集和代码项目。
如何在 Kimi Agent Swarm 中运行一个 agent 团队
第一步：打开 Kimi Agent Swarm，输入你的提示词
打开 Agent Swarm 页面，在输入框中描述你的任务。为了获得更好的效果，请尽量具体说明任务范围、期望的交付物，以及时间范围、信息来源或格式要求等约束条件。
示例提示词：
第二步：让 Kimi Agent Swarm 开始工作
发送提示词后，Agent Swarm 会将任务拆解为多个子任务，并派出子智能体并行处理。你可以实时查看进度，包括任务规划、子智能体生成以及并行执行的过程。
第三步：接收、预览并下载或分享结果
运行完成后，你的交付物即可在界面中直接预览。根据任务类型的不同，输出内容可能包括研究报告、数据分析、PPT 演示文稿、网页、代码项目，或以上多种形式的组合。你可以下载这些文件并直接分享。
Kimi Agent Swarm 的适用场景
招投标与提案撰写： 同时分配并行智能体处理技术规格、合规要求、定价模型和案例研究；协调者将它们整合成一份完整连贯的提案。
财务分析： 同时分配并行智能体处理市场数据、竞争对手披露文件、宏观指标和内部模型；协调者将它们综合成一份统一的分析报告。
商业研究： 分配并行智能体分别从不同来源获取竞争格局、客户访谈、行业报告和监管背景信息；协调者输出一份结构化成果。
安全测试： 运行并行智能体分别执行侦察、漏洞扫描、依赖审计和权限提升检测；协调者将结果汇总成最终报告。
全栈开发： 构建并行智能体分别负责前端组件、后端接口、数据库架构和测试套件；协调者统筹整个技术栈的集成工作。
结语
Claude Code 的 agent 团队专为工程工作流打造，能够直接从终端为复杂代码库带来并行执行能力。如果你的工作不局限于代码，Kimi Agent Swarm 将同样的多智能体范式带到了研究、分析、内容创作等更多场景。只需描述你的任务，剩下的交给集群处理即可。