Claude Code 智能体团队的思考

本周我完成了在 Claude Code 生态系统中构建一个由相互交互的智能体组成的协调团队。我实际上喜欢系统的最终版本的工作方式，但它并不像听起来那么简单就能让它工作起来。

我担心许多人在没有完全理解权衡的情况下就跳入构建智能体团队。我理解，一旦你的子智能体开始工作，智能体团队听起来像是自然的下一步。

让我明确一点：它们不是。

智能体团队是一个协调层，具有真实的 token 成本、已知的失败模式，以及它们能很好解决的一小部分问题。

几个月真实多智能体使用中最有用的结论并不那么光鲜：大多数系统应该从1个配置良好的智能体、好的工具和严格的上下文管理开始。就这样。只有当你能说出具体原因时才添加更多智能体。Anthropic 自己关于构建有效智能体的指南直接说道："我们建议找到尽可能简单的解决方案，只在需要时增加复杂性。"

这篇文章是关于如何清晰地思考这个决策，以及一旦做出决策后该做什么。

本文将涵盖什么？

• 为什么大多数团队还不需要多个智能体。 常见的失败模式：因为感觉更强大而选择智能体团队，而不是因为它们能解决特定问题。
• 当1个智能体不够用时。 4个具体触发因素，以及为什么每个都很重要。
• 组合智能体的4种模式。 一个与供应商无关的分类法：编排器、管道、并行专家、集群。
• Anthropic 的智能体团队技术栈。 清楚地了解今天存在的内容、稳定的内容，以及仍然处于实验性或仅预览的内容。
• Claude Code 智能体团队实践。 这个功能到底是什么，它如何工作，以及它与子智能体有何不同。
• 智能体如何通信。 3种通信形式，4种时序模式，以及实际上在智能体之间传递什么。
• 为什么智能体团队会失败。 8种失败模式及其实用缓解措施（大多数关于此主题的文章都跳过的部分）。
• 原生 vs DIY vs 混合。 一个选择如何编排的决策框架，没有供应商的框架。

让我们开始吧！

1、为什么大多数团队还不需要多个智能体

大多数选择智能体团队的人正在解决错误的问题。

推理通常是这样的：子智能体工作得很好，系统变得越来越复杂，智能体团队是下一步。但这种逻辑混淆了能力和复杂性。智能体团队不会给你一个更强大的系统，它给你一个更分布式的系统。分布式是一种成本，而不是升级。

Anthropic 关于构建有效智能体的文章明确了经济学：非智能体工作流更可预测、更便宜且更易于调试。指导是直接的——"如果你能编写一个函数来完成工作，那就这样做，而不是召集一个概率分布委员会。" 我真的喜欢这个陈述，因为不理解 LLM 工作原理的人忽略了它们是概率性的这一点，这意味着，即使你要求一个明确的操作，LLM 也可能正确或不正确地执行它。多智能体协调增加了开销并复合了错误风险。你添加的每个智能体都是另一个可能失败、产生幻觉或产生下一个智能体误解的输出的组件。所以基本上，你实际上是在决定在大规模上复合错误概率。

单智能体的上限比大多数人想象的要高。一个设计良好的智能体，拥有正确的工具、专注的系统提示、为繁重工作提供清晰的子智能体委托以及适当的上下文管理，将处理很多事情。当以下4个特定条件之一为真时，就达到了上限：

1. 工作量太大，无法放入一个上下文窗口中，即使有子智能体委托。
2. 工作的不同部分需要真正不同的专业化——不仅仅是不同的提示，还有不同的工具访问和行为约束。
3. 工作的部分可以并行运行，而且挂钟时间很重要。
4. 输出的质量需要独立批评（例如，使用一个没有看到第一个智能体推理的第二个智能体）。

这些条件中没有一个与能力有关。它们与架构有关。当其中一个为真时，添加智能体是合理的。当没有一个为真时，你是在增加摩擦。

如果你不能具体指出其中一个，单智能体路径仍然是开放的。

2、当1个智能体不够用时

前面提到的4个条件值得具体的例子。

• 上下文隔离。 工作需要读取数十个文件、运行广泛的搜索并保存大量中间输出——这些中间工作都不需要保留在你的主会话中。子智能体可以处理这个。但如果调查本身太大，即使子智能体的上下文也填满了，或者结果需要分解为独立的并行调查，你就是在看多个智能体。这是最常见的合法触发因素。
• 专业化。 工作不仅需要不同的指令，还需要不同的工具访问和不同的行为约束。一个不能写文件或运行 shell 命令的代码审查器与代码生成器具有完全不同的风险特征。你仍然可以将这些差异编码为单独的子智能体，每个都有量身定制的系统提示和受限的工具列表，所以不要将专业化作为决定何时升级到智能体团队的唯一维度。事实上，Claude Code 智能体团队文档明确指出子智能体在这里表现出色——隔离的上下文、返回给调用者的摘要、特定于任务的指令。
• 并行工作。 任务分解为不共享可变状态的独立子任务。3个智能体同时调查代码库错误的不同角度。4个智能体审查文档的不同章节。这就是多智能体系统产生真正的挂钟时间节省的地方，因为它们同时运行。但成本是更多的总 token。当挂钟时间比 token 支出更重要时，这种权衡是合理的。
• 独立批评。 输出的质量需要第二个没有被第一个意见推理污染的意见。一个只读取最终输出而不读取产生它的推理的评估智能体。一个积极尝试寻找缺陷而不是验证声明的红队智能体。这就是 Anthropic 多智能体研究系统背后的模式，其中并行子智能体调查不同方面，主导智能体独立综合。

当这些条件之一明显为真——并且你能说出是哪一个——时，添加智能体就能赚回其成本。

3、组合智能体的4种模式

现在，假设你确实想继续使用多智能体系统。如果你去研究从哪里开始，你会发现自己有点问题，因为多个前沿实验室一直在以不同的方式开发多智能体模式和解决方案。尽管如此，有一些共同点值得探索。

以下是一个综合分类法，基于Anthropic 工作流文档和Anthropic Engineering 生产经验中出现的模式。需要明确的是，我下面介绍的不是 Anthropic 的官方分类法，而是一个分析综合，映射回文档描述的内容。

3.1 顺序管道

智能体或阶段按定义的顺序运行。后面的阶段使用前面的输出。这是最容易向技术受众解释的模式，因为它看起来最像普通软件。研究然后综合。起草然后批评。提取然后验证。

优势在于阶段之间的契约是明确的。弱点是错误会级联：如果第一个阶段提取了错误的内容，后面的阶段可能会付出巨大代价出错。此模式中阶段之间的验证门不是可选的——它们是防止管道自信地朝错误方向运行的关键。验证门的最佳示例是 json 契约模式和其他工件，以确保执行过程中的血统。

3.2 中央编排器或规划者-执行者

1个主导智能体分解任务，委托给工作智能体，并综合结果。工作智能体彼此不协调——它们向编排器报告。这是最常见且最有用的默认模式。当子任务结构事先不清楚但清晰的顶级所有权很重要时使用它。Anthropic 的 Research 功能正是使用这种模式：主导智能体分析查询，同时生成专门的子智能体，然后综合发现。

当工作流已经固定到可以脚本化时避免使用它。如果你事先知道步骤，管道更简单且更可预测。

主要的失败模式是编排器失败：主导智能体使用模糊的委托提示导致工作智能体重复彼此的搜索、错过重要边界或产生无法组合的输出。修复是明确的：为每个工作智能体提供目标、预期输出格式、源指导和任务边界。

3.3 并行专家、辩论和红队

多个智能体同时检查相同或相关的子任务，然后投票、批评或聚合。当健壮性比整洁性更重要时使用此模式：关于错误的相互竞争假设、对策略决策的对抗性审查、从多个角度进行安全审查。

成本显然是更多智能体意味着显著更多的 token、更多的聚合工作，以及从共识中产生虚假信心的风险。Anthropic 的研究系统不得不添加工作预算和更明确的委托，以防止工作智能体无纪律地分散。只有当领域真正需要时，此模式才有意义。

3.4 集群或去中心化共享上下文系统

协调通过共享状态、共享消息线程或环境变化而不是一个严格的领导者来实现。这就是多智能体系统开始成为分布式系统的地方，伴随着相关的复杂性：所有权歧义、共享状态竞态条件、调试困难。当问题真正开放且智能体必须跨会话或运行时边界互操作时使用此模式。当你需要简单的责任或严格的合规性时避免使用它。

对于大多数从业者来说，前2种模式几乎涵盖了所有内容。下面是4种模式的摘要。

3.5 4种智能体团队模式总结

4、Anthropic 的智能体团队技术栈。

现在，在你继续并开始构建自己的技术栈之前，让我们看看 Anthropic 是否有可用的东西（以及我们是否可以向他们的想法学习）。Anthropic 现在提供多个智能体工作的表面，它们不能互换。

最清晰的思考方式是将其视为一个阶梯——从原始控制到托管管理：

1. Messages API — 你完全拥有循环。工具使用存在但你自己实现执行逻辑。没有内置多智能体支持。这是最灵活的层级，也是工作量最大的。
2. Claude Agent SDK — Anthropic 的智能体循环、工具、上下文管理、子智能体、钩子和成本跟踪在你操作的基础设施中运行。子智能体原生支持。超出子智能体的多智能体模式在很大程度上仍然是你的设计。关键是，Agent SDK 通过 Bedrock、Vertex AI 和 Azure Foundry 进行身份验证，使其成为最可移植的层级。
3. Claude Managed Agents — Anthropic 托管运行时。你获得托管基础设施、容器、提示缓存、压缩、有状态会话、事件历史记录和内置工具。单智能体使用是成熟的。多智能体会话是一个单独的、受控的预览。
4. Managed Agents multiagent — 一个 Research Preview，访问受控，有一个重要约束：当前设计仅支持一个协调器级别。协调器可以调用其他智能体，但被调用的智能体本身不能调用更多智能体。这是多智能体编排，但它还不是通用的递归智能体社会。
5. Claude Code 子智能体 — 在单个主会话内运行并返回结果的隔离工作上下文。一个官方功能，不是点对点团队。
6. Claude Code 智能体团队 — 截至2026年4月，此功能处于实验性且默认禁用。它需要特定的环境变量才能启用。已知限制包括会话恢复行为、任务协调边缘情况，以及恢复的会话可能引用不再存在的队友的可能性。这是诚实的情况。

实际上这意味着什么：

• "Claude 支持智能体团队" 是正确的。
• "Claude 具有生产级、通用原生多智能体编排功能" 不准确。

5、Claude Code 智能体团队实践

让我们从子智能体与智能体团队的简短回顾开始：

• 子智能体在单个主会话内运行。你的主 Claude Code 实例生成它们，它们在自己的上下文窗口内隔离工作，然后返回结果。你进行编排。主会话永远不会吸收它们为产生结果所做的工作。
• 智能体团队是相互通信的独立 Claude Code 会话。每个队友都有自己的上下文窗口、自己的会话状态，以及对共享任务列表和用于直接队友消息传递的邮箱的访问权限。队友可以相互分配任务并自行协调，而无需等待领导传递每个指令。领导设定方向；队友可以按照它执行并相互交谈。

那么，如何创建这些智能体团队？

5.1 实际设置

1. 团队配置位于 ~/.claude/teams/{name}/config.json。
2. 共享任务列表位于 ~/.claude/tasks/{name}/。
3. 队友定义是可重用的智能体文件——本质上是被分配队友角色的子智能体定义。
4. 钩子可以作为任务转换之间的质量门。

对设计很重要的2个架构说明：

首先，子智能体可以维护自己的自动记忆。这对于专业化很有用，但当你将工作拆分到多个具有自己记忆的智能体时，你就是在做一个架构决策：哪些知识留在本地，哪些被共享，哪些被摘要返回。你面临的是一个系统设计问题。

其次，文档直接说明了智能体团队何时比子智能体更差：顺序任务、相同文件编辑、步骤之间有许多依赖项的工作。如果智能体需要顺序传递相同的工件而不是并行工作，使用顺序管道的子智能体更简单且更可预测。

截至2026年4月，智能体团队处于实验性且默认禁用。只有当你有来自上述列表的明确理由时才启用它们，并期望遇到尚未解决的边缘情况。

6、智能体如何通信

智能体通信通常被视为提示问题。在规模上，它是一个系统问题。

智能体之间有3种主要的通信形式。

1. 纯语言消息 — 最明显但在规模上最不可靠。Claude Code 智能体团队允许队友通过"邮箱"直接相互发送消息。这很灵活，但自然语言不如结构化调用精确，这意味着智能体之间有更多误解的空间。
2. 结构化调用 — JSON Schema 工具定义和严格的工具使用。Anthropic 的工具定义保证符合模式的参数。这是使智能体到工具通信可靠的层，当建模为工具调用而不是普通消息时，它也是使智能体到智能体调用更精确的相同机制。
3. 共享状态或工件 — 最被低估的通信形式。Anthropic 的多智能体研究系统明确建议让子智能体将输出写入文件系统或外部系统，并返回轻量级引用，而不是将所有内容通过主导智能体的上下文。原因很简单：文件是可审计的、有版本的，可以直接检查。总结文件的消息则不是。

通信的时序与格式同样重要。4种模式：

1. 同步调用 — 管理者调用专家，等待，然后继续。易于推理，但可能造成瓶颈。Anthropic 的研究团队发现，同步的主导智能体执行被慢速工作智能体阻塞，并防止了飞行中转向。
2. 顺序交接 — 所有权从一个智能体转移到另一个智能体。一个智能体产生结果；下一个智能体接收它。OpenAI 正式区分了交接（专家拥有下一个响应）和智能体作为工具（管理者保持控制）。这种区别对责任很重要。
3. 事件驱动或流式 — 智能体响应事件而不是同步调用。更适合长时间运行的工作，更难调试和测试。有时钩子可以在这里提供帮助。
4. 共享状态轮询 — 最不吸引人但通常最健壮。智能体检查共享文件或数据存储的进度，写入更新，然后继续。Anthropic 的长时间运行的工具使用 JSON 功能列表、进度文件和 git 提交作为持久共享状态。人在环中的检查点自然适合这里。

如你所见，智能体之间传递的内容塑造了整个系统的可靠性。一方面，传递完整的对话历史记录最大化了连续性，但成本和延迟线性增长。另一方面，压缩摘要通常更好——这是 Claude Code 子智能体的设计。但可能，传递特定于任务的工件——结构化输出文件、代码补丁、JSON 中的功能列表、存储的报告——通常是实际的甜蜜点。接收智能体可以直接检查工件而不是信任摘要，这使得系统以对话交接无法实现的方式可审计。

这意味着传递的内容也塑造了传递的方式和时间。因此，强化了这样一个观点：当你构建智能体团队时，你面临的是一个系统设计问题。这些问题不像线性编排流那样容易解决。

7、为什么智能体团队会失败

这是大多数多智能体教程跳过的部分。我发现的一个来源使用了 Anthropic 的工程笔记。它们读起来不像研究论文，而更像一个团队的日记，他们一个接一个地发现错误，额外的智能体会增加管理问题。以下是我从中提取的8件事：

• 协调漂移。 模糊的委托导致工作智能体重复彼此的搜索、错过重要边界或产生无法组合的输出。Anthropic 的研究系统文章直接发现了这一点：解决方案是教编排器为每个工作智能体指定目标、输出格式、源指导和范围边界。如果你不定义所有权，智能体会即兴发挥——而且它们即兴发挥得很糟糕（猜猜怎么着，人类也是如此）。
• 幻觉的所有权。 一个智能体假设另一个已经检查了某些东西，但没有人检查。修复是明确的完成工件：任务钩子、在标记任何内容完成之前进行端到端验证，以及记录实际已确认内容而不是假设内容的持久状态文件。
• 静默中间失败。 调试智能体需要完整的生产跟踪，因为无法判断失败是来自糟糕的搜索查询、低质量源还是工具问题。顶级会话流只是一个浓缩视图。要理解被调用的智能体实际做了什么，你必须检查工作级别的历史记录。从一开始就设置跟踪，而不是在第一次生产事件之后。
• 上下文膨胀和内存污染。 上下文窗口是有限资源。变得过时或嘈杂的共享内存会降低整个系统。Anthropic 的上下文工程工作精确地定义了问题：每个工具调用、每个文件读取、每个部分分析都进入上下文并留在那里。在一个智能体团队中，这会复合。缓解措施是成熟的：总结已完成的阶段，在子智能体中隔离繁重工作，优先使用小型专注的内存文件而不是大型共享文件。
• 模式不匹配和脆弱的提示契约。 通过自然语言交换数据的智能体是脆弱的。第二个智能体误解第一个智能体的摘要；错误静默传播。Anthropic 的严格工具使用正是存在的原因，因为非严格工具调用可能产生不兼容的类型或缺少字段。狭窄的智能体/工具契约减少了这种情况发生的表面区域（谁会想到基本工程契约会成为 AGI 的解决方案……）
• 工具误用和安全失败。 更多的开放环境为提示注入创造了更多入口点。更多的工具为攻击者在进入后创造了更多行动方式。Anthropic 的可信智能体研究将提示注入确定为命名的网络攻击向量，而不是边缘情况。METR 对 Anthropic 内部智能体监控系统的红队测试即使在资源充足的内部系统中也发现了新的安全漏洞。缓解措施：限制权限，将工具限制在任务实际需要的范围内，为重要操作保留人工审批点。
• 成本爆炸和延迟叠加。 智能体团队消耗的 token 显著多于单个会话。并行性可以减少挂钟时间，但它不会减少总 token 支出——它会增加。对任务运行多个智能体是通过并行花费更多结构化努力来更快，而不是花费更少。如果任务不能证明该成本是合理的，单个设计良好的智能体更快且更便宜。
• 评估困难。 许多不同的内部轨迹可能以看起来成功的最终输出结束。如果你唯一的测试是最终文本听起来是否合理，你不是在评估系统——你是在欣赏它。Anthropic 的建议：评估是否达到了正确的最终状态，而不是是否遵循了预期的过程。过程会有所不同；结果是你实际可以检查的。

8、原生 vs DIY vs 混合

现在，黄金问题。如果我确实想构建智能体团队，我应该自己做还是使用现成的解决方案？

构建自己的编排和使用 Anthropic 原生功能之间的选择是3个选项之间的架构权衡（我确定还有更多，但我在这里是有主见的）：

1. 原生托管 意味着 Anthropic 拥有运行时和协调表面——Claude Managed Agents，以及在更窄的意义上，Managed Agents multiagent 或 Claude Code 智能体团队。价值在于更低的工程开销、托管工具和你不必维护的基础设施。成本是受限的可移植性（Managed Agents 仅通过直接 Claude API 可用），多智能体表面要么是实验性的（智能体团队）要么是受控预览（Managed Agents multiagent）。当然，还有对第三方的依赖。当基础设施是痛点且可接受 Anthropic 特定约束时的正确选择。
2. DIY 意味着你拥有编排逻辑，通常也拥有运行时——Messages API 是最纯粹的例子。最高控制，最高工程成本。当你的业务逻辑不寻常、合规性严格、路由是特定领域的，或者你需要真正的供应商可移植性时的正确选择。
3. 混合 意味着 Anthropic 提供循环和工具，但你来架构系统——Claude Agent SDK 是最清晰的例子。你获得 Anthropic 的智能体循环、上下文管理、钩子、子智能体和可观察性。你仍然拥有更高层次的设计。Agent SDK 通过 Bedrock、Vertex AI 和 Azure Foundry 进行身份验证，这比原生托管具有有意义的可移植性优势。当你想要 Anthropic 的循环但不想将整个架构与 Anthropic 当前对多智能体系统应如何工作的看法绑定时的正确选择。

实际总结：当基础设施是痛点时使用原生托管；当拓扑和策略是痛点时使用 DIY；当你想要 Anthropic 的原语但需要为自己的架构决策留出空间时使用混合。

9、结束语

大多数人带到智能体团队的框架是能力：更多智能体意味着更多能力。实际上有帮助的框架是架构：添加智能体解决什么问题，以及它的成本是什么？

子智能体定义谁做工作、在什么上下文中以及使用什么工具。智能体团队在此之上添加了一个协调层——共享任务状态、直接队友消息传递、具有自协调的并行执行。只有当问题特别需要时，这一层才是强大的。

一个配置良好的智能体团队，针对真实用例设置，是一周合理的工作量。复杂性可以从那里增长，但不必从那里开始。本文中的研究、失败模式目录和通信模式是参考材料——不是立即实施所有内容的处方。

首先命名4个触发因素中哪一个实际上为真。如果都不是，单智能体路径仍然是正确的。

原文链接：Claude Code agent teams: when and how to go multi-agent

汇智网翻译整理，转载请标明出处