Claude Code智能体团队：何时需要使用多智能体以及如何操作

在 Claude Code 生态系统中，能够实现各智能体之间相互协作的团队架构已经可行，且成品效果相当不错。不过要让其真正发挥作用比听起来要困难得多，还有很多人在未权衡利弊的情况下就匆忙组建智能体团队。一旦子智能体运行顺畅，智能体团队似乎就成了显而易见的下一步发展，但实际上并非如此。团队本质上是一个需要付出真实代币成本的协调层，存在已知的故障模式，并且仅擅长处理有限类型的问题。

数月实际多智能体应用中所得到的最不引人注目的经验，也是最有用的：首先从一个配置良好的智能体、合适的工具以及规范的上下文管理入手。只有当有明确理由时才添加更多智能体。Anthropic关于构建高效智能体的指导也提出了相同观点，建议团队先寻找最简单的可行方案，仅在必要时再增加复杂性。

以下是思考该决策的方法以及做出决策后应采取的行动。这些内容假设你已经了解子智能体、它们与技能的区别，以及为何隔离上下文是使用子智能体的主要原因。目前仍存在的问题是：何时仅靠单个子智能体反馈已不够用，以及应为其替代什么。

相关内容涵盖以下方面：

• 为何大多数团队目前还不需要多个智能体，以及人们因误以为更多智能体会提升效率而犯下的常见错误。
• 四个能表明单个智能体已无法满足需求的明确信号。
• 一种与供应商无关的分类方式，介绍了四种智能体组合模式：协调器、流水线、并行专家和群体。
• Anthropic平台为智能体团队提供的架构，用于区分稳定功能与实验性或仅限预览的功能。
• Claude Code智能体团队是什么，以及它们与子智能体的区别。
• 智能体之间的通信方式：三种形式、四种时序模式以及它们之间应传递的内容。
• 八种故障模式及相应的实际解决措施。
• 选择原生方案、自主实现方案或混合协调方案的决策框架。

大多数团队不需要超过一个智能体

许多寻找代理团队的人其实是在解决错误的问题。他们的常见逻辑是：子代理已经有效，系统日益复杂，因此团队便是下一步的解决方案。但这种逻辑将能力与复杂性混为一谈。团队并不会提升系统的能力，只会使其更加分散化，而分散化本身是一种成本而非升级。

Anthropic关于构建高效智能体的文章详细阐述了其中的经济性考量。非智能体驱动的工作流更具可预测性、成本更低且更易于调试，其核心建议是：当普通函数就能完成任务时，直接编写该函数，而非组建由多种概率分布构成的团队来处理。对于那些尚未理解大语言模型本质上是概率性系统的人而言，这一点很容易被忽视。即便是明确的指令也未必能被正确执行。每增加一个智能体，就多了一个可能出错、产生幻觉或输出内容被下一个智能体误解的组件，因此大规模使用智能体会进一步增加出错的可能性。

单个智能体的处理上限比人们想象的要高。只要给予合适的工具、明确的系统提示，将繁重任务妥善分配给子智能体，并做好上下文管理，一个智能体就能完成令人惊讶的大量工作。当出现以下四种情况中的至少一种时，其处理上限就会被达到：

1. 即便通过子智能体分配任务，该工作量仍超出单个上下文窗口的承载能力。
2. 不同部分需要真正的专业化处理，这意味着需要不同的工具访问权限和行为限制，而不仅仅是不同的提示语。
3. 部分工作可以并行进行，此时时间效率至关重要。
4. 输出质量需要独立的评估，例如由未见过第一个智能体推理过程的第二个智能体来进行评价。

这些都不是关于处理能力的说明，全都与架构有关。当有特定需求时，使用额外的智能体是合理的；而如果没有这样的需求，它们只会增加复杂性。如果无法指出具体的需求，那么单智能体方案依然可行。

四种触发条件及示例

上下文隔离。假设某项任务需要读取数十个文件、进行大量搜索并处理庞大的中间结果，而这些内容都不必保留在主会话中。此时可以使用子智能体来处理这些任务。但如果调查规模过大，以至于连子智能体的上下文空间也被占满，或者任务被拆分为多个独立的并行调查，那就需要使用多个智能体。这是最常见的合理触发条件。

专业化。这项工作需要的不仅仅是独立的指令，还需要不同的工具访问权限和行为约束。无法编写文件或运行shell命令的代码审查员与代码生成器的风险特征有着本质区别。不过，这些差异往往可以通过独立的子代理来体现，每个子代理都有其自身的系统提示和受限的工具列表，因此仅凭专业化程度并不应成为升级到团队模式的理由。代理团队相关的文档也指出，子代理在此类场景中优势明显：它们拥有独立的上下文环境，能向调用方返回总结结果，并具备针对特定任务的指令。

并行工作。该任务被分解为多个互不共享可变状态的独立子任务：三个智能体同时检查代码库中缺陷的不同方面，或四个智能体各自审查文档中的不同章节。在这种情况下，由于各智能体可同时运行，多智能体系统能真正节省时间。不过这需要消耗更多总令牌数，因此只有当时间成本高于资源成本时，这种方案才具有合理性。

独立评估。输出结果需要另一种未被第一种评估思路影响的意见。可以想象这样一种评估者：只查看最终输出而不了解其背后的推理过程；或者是一种红队人员，其任务是寻找缺陷而非验证结论。这正是Anthropic多智能体研究系统的核心理念——多个并行子智能体分别探索不同方面，再由一个主导智能体独立进行整合。

当其中某个结论显然是正确的且能够明确指出是哪一个时，增加智能体所带来的成本才是合理的。

四种组合智能体的方法

假设决策已经作出。但研究很快便发现情况十分混乱，因为各前沿实验室开发的多智能体模式虽存在一些共性，具体实现方式却各不相同。以下是基于Anthropic的工作流程文档及其工程团队的实际经验整理出的综合分类体系。这并非Anthropic官方的划分标准，而是一种分析性总结，用于对应上述资料中所描述的内容。

顺序流水线

各智能体或处理阶段按固定顺序运行，后续阶段会使用前序阶段的输出结果。在四种模式中，这种结构最容易向工程师解释，因为它看起来就像普通的软件流程：先研究再综合，先起草再评审，先提取再验证。

它的优势在于各阶段之间存在明确的契约关系。其缺点则是错误会逐级扩散，因为第一阶段的提取错误可能导致后续阶段出现严重错误并带来巨大代价。在各个阶段之间设置验证机制是必要的，这样才能防止处理流程误入错误方向。JSON契约架构以及能够记录整个执行过程轨迹的其他工具，是最理想的验证手段。

集中式协调器，还是规划-执行模式？

一个主导智能体将任务拆分，分配给各个工作智能体，并汇总结果。这些工作智能体之间不会相互协调，而是直接向统筹智能体汇报。这是最常见且最有用的默认模式。当子任务的结构事先未知，但明确的上层负责主体十分重要时，应使用此模式。Anthropic的Research功能正是遵循这种结构：主导智能体分析查询，同时启动多个专用子智能体，随后合并它们找到的信息。

如果工作流程已经足够明确，可以编写脚本实现，则无需使用此模式；那样的话，流水线会更简单、更易预测。

其典型的故障表现为协调器故障：负责分配任务的代理给出的指示模糊不清，导致工作者重复进行相同的搜索，忽略任务边界，或产生相互矛盾的结果。解决方法是为每位工作者设定明确的目标、预期的输出格式、信息来源指引以及清晰的任务边界。

并行专家、辩论与红队机制

在这种模式下，多个代理同时处理同一任务或相关的子任务，随后对这些结果进行投票、评价或汇总。这种方法适用于那些韧性比完美性更重要的场景：对某个漏洞的不同解释、对政策决策的对抗性审查，以及从多角度进行的安全评估。

成本显而易见。代理数量越多，所需的令牌就越多，聚合工作量也会增大，同时还会因共识机制而产生过度自信的风险。据报道，Anthropic的研究系统不得不设置工作量预算并明确分工，以防止员工无序地分散精力。只有在该领域确实有此需求时才应采用这种模式。

群体协作，或去中心化的共享上下文

协调是通过共享状态、共享消息线程或环境变化来实现的，而非依靠严格的领导者。此时多代理系统开始转变为分布式系统，随之而来的是各种复杂性：所有权界定不清、共享状态上的竞态条件以及难以调试的问题。这种模式适用于那些需要代理在会话或运行时边界之间相互协作的真正开放性问题。而在需要明确责任或严格遵循规则的情况下，则应避免使用此模式。

对大多数从业者而言，前两种模式几乎能涵盖所有需求。

Anthropic 当前的产品

在自行搭建系统之前，不妨先了解 Anthropic 已经提供的功能及其设计理念。目前存在多种用于实现智能体功能的平台，且它们彼此不可替代。可以将其想象成从原始控制到托管管理的阶梯结构。下图展示的是2026年4月左右的状况，这些产品更新速度很快。

1. Messages API。 您完全掌控整个流程。虽然有工具可用，但执行逻辑仍需由您自行编写，且不支持多智能体协作。这是灵活性最高但工作量也最大的层级。

Claude Agent SDK。其代理循环、工具、上下文处理、子代理、钩子功能以及成本跟踪等功能均来自Anthropic，但在您管理的基础设施上运行。子代理为原生支持，而多代理功能则主要由您自行设计实现。认证通过Bedrock、Vertex AI和Azure Foundry完成，因此这是最具可移植性的版本。

Claude托管代理。Anthropic会为您处理运行时相关事务：容器管理、数据压缩、提示词缓存、事件记录、有状态会话以及一系列内置工具。单代理使用功能已十分成熟，而多代理会话则处于独立的预览阶段。

托管代理多智能体。这是一项仅限有限用户访问的研究预览版本，且存在明显限制：其设计仅支持一个协调层。协调者可以调用其他智能体，但它所调用的智能体无法再进一步调用其他智能体。这属于多智能体编排，但还并非真正的递归式智能体群体。

Claude Code子智能体。在单个主会话中运行的独立工作上下文，负责将结果反馈回来。这是官方支持的功能，但并非点对点的团队协作形式。

Claude Code智能体团队。截至2026年4月的版本，该功能仍处于实验阶段且默认处于禁用状态，需通过特定的环境变量才能启用。已知的限制包括会话恢复行为、任务协调中的边缘情况，以及尝试恢复那些已不存在的团队成员的会话。

从实际应用来看，“Claude支持智能体团队”这一说法是成立的，而“Claude在所有平台上都能提供生产级、通用的多智能体编排功能”则不成立。

Claude Code中的智能体团队实际应用

简单回顾一下两者的区别：

• 子智能体在单个主会话中运行。Claude Code的主实例负责创建它们，每个子智能体都在自己的上下文窗口中独立工作并返回结果，由你负责进行编排，主会话不会承担生成结果的工作。

智能体团队是相互通信的独立 Claude Code 会话。每位团队成员拥有自己的上下文窗口和会话状态，同时还有一个共享的任务列表以及用于发送直接消息的邮箱。团队成员可以互相分配任务并协调工作，无需等待负责人转达每一项指令。负责人负责制定方向，团队成员则据此行动并彼此交流。

设置方式

1. 团队配置文件位于 ~/.claude/teams/{name}/config.json。
2. 共享任务列表位于 ~/.claude/tasks/{name}/。
3. 团队成员通过可复用的智能体文件来定义，实际上这些是被分配了相应角色的子智能体定义。
4. 钩子功能可在任务转换之间起到质量管控的作用。

在设计中有两个架构层面的要点。首先，子代理可以保留自己的自动记忆。这有助于实现专业化，但一旦工作被分配给多个拥有独立记忆的代理，就需要做出架构决策：哪些知识应保留在本地，哪些需要共享，哪些又需要被汇总回来。这就是一个系统设计问题。

其次，文档明确指出在哪些情况下团队表现会不如子代理：顺序任务、对同一文件的编辑，以及各步骤之间存在大量依赖关系的情况。如果代理必须按顺序传递相同的成果而无法并行工作，那么顺序流水线中的子代理会更简单且更易预测。

由于当时的团队仍处于试验阶段且默认处于关闭状态，只有出于上述清单中的明确原因时才应启用它们，并要做好出现缺陷的准备。

代理之间如何通信

智能体之间的通信通常被视为提示词相关问题，但在大规模应用中则属于系统层面的问题。其大致存在三种形式。

1. 通俗语言消息。这是最显而易见的形式，但在大规模应用中可靠性最低。Claude Code的团队成员通过邮件箱直接互相发送消息，虽然灵活，但自然语言不如结构化调用精确，容易导致智能体之间产生误解。
2. 结构化调用。使用JSON Schema工具定义并严格遵循这些规则。Anthropic的工具定义能确保传入的参数符合相应架构，这一机制使得智能体与工具之间的通信更加可靠；同样地，当将智能体间的交互建模为工具调用而非自由格式的消息时，也能提高其精确度。

共享状态或成果。这是最容易被低估的形式。Anthropic的多智能体研究报告建议让子智能体将输出结果写入文件系统或外部系统，并返回轻量级的引用，而非通过主导智能体的上下文来处理所有信息。原因很简单：文件可以直接被审计、版本控制及检查，而总结文件的消息则无法具备这些功能。

时机与格式同样重要。存在四种模式：

• 同步调用。管理者调用专家，等待后继续执行。这种模式易于理解，但可能存在瓶颈。据报道，Anthropic的研究团队发现同步主导执行会因处理速度较慢的智能体而受阻，因此排除了在任务执行过程中进行调整的可能性。

顺序式交接。任务所有权从一名智能体传递给下一名，前者完成某项工作后，后者再接手。OpenAI将这两种方式明确区分开来：顺序式交接让专家负责后续工作，而作为工具使用的智能体则由管理者掌控。谁需要承担责任取决于采用了哪种方式。

事件驱动或流式处理。智能体是对事件作出反应，而非通过同步调用。这种方式更适合处理耗时较长的任务，但调试和测试较为困难，有时使用钩子功能会有所帮助。

共享状态轮询。虽然不够美观，但往往是最为可靠的方案。代理程序会查看共享文件或数据存储以获取进度信息，将更新内容记录在那里后再继续执行。Anthropic长期开展的工具开发工作使得JSON功能列表、进度文件以及git提交记录成为稳定的共享状态，而人工检查点也能自然地融入其中。

各智能体之间传递的内容决定了整个系统的可靠性。传递完整的对话历史虽能最大程度保持连贯性，但会呈线性增加成本和延迟。压缩后的摘要通常更为合适，这也是 Claude Code 的子智能体按设计所采用的方式。传递结构化输出文件、代码补丁、JSON 特性列表及存储的报告等任务专用成果往往是实际中最理想的方案。接收端的智能体可以直接查看这些成果，而无需依赖摘要，这使得系统具备对话式传递无法比拟的可审计性。

传递的内容还决定了传递的方式与时机，这进一步强调了核心观点：构建智能体团队属于系统设计问题，其解决难度远高于简单的线性流程编排。

智能体团队失败的八种方式

大多数多智能体教程都会跳过这一部分。Anthropic的工程笔记是很好的参考资料。这些笔记更像是一个团队逐步解决问题的日记，他们一次解决一个漏洞，逐渐意识到增加智能体只会让管理问题愈发复杂。从中可以提炼出八点经验。

• 协调偏差。模糊的职责分配会导致智能体重复彼此的工作，忽略边界条件，或返回无法整合的结果。Anthropic的研究系统帖子直接指出了这一问题，解决办法是让协调器明确指定每个智能体的目标、输出格式、数据来源及工作范围。在职责未明确定义的情况下，智能体会像人类一样自行决定，而且往往处理得不好。

错觉性的所有权认知。代理A认为代理B已经验证了某些实际上并未被任何人验证过的内容。解决此问题的方法是使用明确的完成标记：任务钩子、在标记任务完成之前进行端到端验证，以及记录实际已确认内容而非仅假设内容的持久化状态文件。

隐蔽的中间环节故障。由于无法判断故障是源于搜索查询不当、数据来源不可靠还是工具故障，因此调试需要完整的生产环境追踪。顶层会话流仅是简化后的视图，要了解被调用代理的真实操作情况，必须查看工作节点级别的历史记录。应在生产环境中首次出现故障之前就提前设置好追踪机制。

上下文膨胀与内存污染。上下文窗口是一种有限的资源，而那些过时或混乱的共享内存会损害整个系统的性能。每一次工具调用、文件读取以及部分分析结果都会被存入上下文并持续存在，而在团队协作中这种情况会愈发严重。目前已知的缓解方法包括总结已完成的工作阶段、将繁重任务分配到子智能体中，以及优先使用小型、专注型的内存文件而非大型共享内存文件。

模式不匹配与脆弱的提示词约定。以自然语言进行数据交换的智能体十分脆弱。如果第二个智能体误解了第一个智能体的总结内容，错误就会悄无声息地蔓延。之所以需要严格的工具使用规范，是因为非严格的调用方式可能会导致类型不兼容或字段缺失。在智能体与工具之间建立严格的约定能够减少此类问题的发生概率，这反倒体现了传统工程规范在人工智能环境中的独特作用。

工具滥用与安全漏洞。开放程度越高的环境意味着越多的提示注入攻击入口，而工具种类越多，攻击者进入系统后可实施的手段也就越多。Anthropic针对可信智能体的研究将提示注入视为一种网络攻击途径而非边缘情况；据报道，METR对Anthropic内部智能体监控系统进行的红队测试，即便在资源充足的内部系统中也发现了新的漏洞。应通过限制权限、仅使用任务所需的工具，以及对重大操作进行人工审批来降低风险。

成本激增与延迟累积。团队在多次会话中使用的标记数量远超单次会话所需。并行处理虽能缩短总耗时，但由于需要同时投入更多结构化工作，反而会增加总标记消耗。除非任务确实需要如此高的投入，否则精心设计的单个智能体能更快、更省钱地完成任务。

评估难度。多种不同的内部处理路径都可能产生看似成功的结果。如果唯一的测试标准是最终文本是否合乎逻辑，那其实只是在欣赏系统而非对其进行评估。Anthropic的建议是检查是否达到了正确的最终状态，而非是否遵循了预定的流程。流程各有不同，但结果才是可验证的。

原生型、自主开发型或混合型

那么关键问题来了：是自行构建编排系统，还是使用现成的解决方案？这是在三种选项之间的架构权衡，实际上可能还有更多选择，因此请将此视为一种有主见的观点。

1. 原生托管型意味着Anthropic拥有运行时及协调机制：即Claude Managed Agents，更具体地说则是Managed Agents多智能体版本或Claude Code智能体团队。其优势在于工程开销更低，且无需维护托管的框架与基础设施。缺点则是可移植性有限（Managed Agents只能通过直接的Claude API访问），多智能体功能仍处于试验阶段或仅限预览，同时还依赖于第三方。当基础设施管理成为痛点且能够接受Anthropic特有的限制时，可选择此方案。

DIY 意味着你需要自行掌控编排逻辑，通常还包括运行时环境，消息 API 就是最典型的例子。这种方式能提供最大的控制力，但工程成本也最高。如果你的业务逻辑较为特殊、合规要求严格、路由规则需针对特定领域设计，或者确实需要服务提供商的便携性，那么可以选择这种方案。

混合模式指的是由 Anthropic 提供循环机制与工具，而你负责系统架构设计，Claude Agent SDK 就是最典型的例子。你可以使用 Anthropic 的智能体循环、上下文管理、钩子功能、子智能体以及可观测性机制，同时仍能掌控更高层次的设计。通过 Bedrock、Vertex AI 和 Azure Foundry 进行身份验证，相比原生托管方案具有更强的可移植性优势。当你希望使用 Anthropic 的循环机制，但又不想让整个架构完全遵循 Anthropic 当前对多智能体系统运作方式的设想时，可选择此模式。

简而言之：当基础设施是痛点时选择原生托管模式，当拓扑结构与策略是痛点时选择自行构建模式，而当你希望使用 Anthropic 的基础组件但又需要保留自身架构决策的空间时，则选择混合模式。

架构问题

大多数人认为代理团队应具备的能力是处理能力，其理论依据是代理数量越多，处理能力就越强。而真正有用的思维框架则是架构设计：新增一个代理能解决什么问题，又会带来多少成本？

子代理负责确定由谁在何种环境下使用何种工具来完成工作。代理团队则在之上增加一层协调机制，包括共享的任务状态、可直接互相沟通的队友，以及能够自动组织的并行处理流程。只有对于真正需要这种协调机制的问题，这样的架构设计才能发挥作用。

对于一个实际应用场景，组建一支配置合理的单一智能体团队大约需要一周时间。后续复杂度可能会上升，但并非必须从这里开始。上述的故障清单与通信模式仅作为参考资料，并非要求一次性构建所有内容的计划。首先确定四个触发条件中哪些是真实的，如果都没有，则单一智能体方案依然是正确选择。