Multi-Agent框架，其实可以很简单~

公众号名称：丁师兄大模型

作者名称：魔法学院的Chilia

发布时间：2026-04-23 21:03

**✅**我是丁师兄，专注于智能驾驶大模型，持续分享LLM面试干货。

✅****大模型1v1辅导，已帮助多名同学成功上岸

offer捷报

恭喜学员拿下大模型独角兽月之暗面offer，总包60w+。从最开始面试被卡，回来做面试复盘，每场面试都录音回听，补齐短板。训练营这边，我布置的实战作业一个都没有落下，项目手动复现吃透。

上岸靠的不是运气，而是方法+强度，逼你在实战中，一步步把能力练出来！！～需要大模型1v1辅导的同学快上车哦～

在上一篇文章中，我们以 Claude Code 为例，介绍了一些 Agent 框架的设计思路，包括 System prompt 的设计和 Tool 的设计。

在这篇文章中，我们主要介绍 Multi-Agent 框架的设计。首先会介绍 Claude Code 中 sub-agent 的使用，这是一种极简的 Multi-Agent 设计方案，已经相对成熟，在工业级场景上具备大规模应用的能力。

但是除此之外，其实还有很多种 Multi-Agent 的类型。因此本文会简要介绍其他类型的 Multi-Agent 架构。最后介绍 Claude Code 中仍处于实验阶段的 Agent Teams。

Claude Code 中的 Sub-agent

“对于通常所谓的’人格’，我都能自行控制；…我能将自己的意识划为几部分，运用自己对于事物本质的把握，专心致志处理两个以上彼此分离的问题，意识到问题的所有方面。”——《领悟》，特德 · 姜

（1）为什么我们需要 subagent？

节省主 Agent 的上下文窗口：这一点我们已经在万字长文解析 Agent 框架中的上下文管理策略中有所介绍。

尽管现在模型的上下文长度越来越长，但毕竟也是有限的；而我们面对的信息却是海量的。

有一种说法是，LLM Agent 的核心，其实是一种压缩——从海量网页、文档中找到关键信息，将大量数据压缩成几个核心要点。

那么，我们可以使用多个智能体，每个只关注一个子问题，它们各自的上下文窗口同时处理不同信息，最后把有价值的部分汇总给主 Agent，这样主 Agent 的上下文窗口就不会被海量的信息所污染。

并行探索，效率更高。在解决问题时，主 Agent 可以启动多个 subagent；而且，每个 sub-agent 在执行任务时，可以并行调用多个工具。

这样，对于复杂的任务，agent 可以在几分钟内完成原本需要数小时才能完成的工作。

在任务实现的效果上，多 Agent 的架构也明显优于单 Agent。多 Agent 的架构特别擅长处理需要广度优先（BFS）处理的问题，因为这类问题需要并行探索多个相互独立的线索。

Anthropic 的博客 How we built our multi-agent research system 中说，使用 Claude Opus 4 作为主 Agent、Claude Sonnet 4 作为 subagent 的多智能体系统，其表现比单独使用 Claude Opus 4 的单智能体系统高出 90.2%。

他们发现，单智能体系统往往因为缓慢的顺序搜索而难以找到答案。

（2）使用多智能体的代价是什么？

当然就是烧钱了！

Anthropic 也在他们的博客中直言不讳地指出，多智能体系统之所以有效，主要就是因为它们能够投入足够多的 token 来解决问题。

他们发现，token 使用量本身解释了在 BrowseComp 榜单上 80% 的性能差异，另外两个因素是工具调用次数和模型选择。多智能体系统本质上是在有限时间内投入了更多的 token 来解决问题。

Multi-agent systems work mainly because they help spend enough tokens to solve the problem. In our analysis, three factors explained 95% of the performance variance in the BrowseComp evaluation. We found that token usage by itself explains 80% of the variance, with the number of tool calls and the model choice as the two other explanatory factors. ---- “How we built our multi-agent research system”, Anthropic

在实际使用中，我发现多 Agent 架构确实会快速消耗大量 token。普通智能体单次交互的 token 用量约为普通聊天的 4 倍，而多智能体系统的 token 用量则达到普通聊天的 15 倍左右！

所以，多智能体系统只适用于任务本身价值足够高，值得为性能提升付出额外成本的情况。

（3）哪些场景适合用多智能体，哪些不适合呢？

通过上面的介绍我们便能知道，多智能体架构主要适用于下面三个场景：

高度并行化的任务，能够同时拆解出大量互不依赖的子任务，给 subagent 并行处理
信息量远超单个上下文窗口承载能力的场景，需要通过多个 agent 分头处理来突破记忆限制
需要调用繁多且复杂的工具时，可以让不同智能体各专其职、互不干扰地操作工具，最后合并结果

比如，目前我在实际使用中发现 Claude Code 最常调用的 subagent 的场景就是调研类的任务。

因为每个 subagent 都负责调研某一方面/不同的文件夹，反正它们都是只读的，不涉及到互相干扰，因此当然可以并行进行：大家分头搜集信息，然后主 Agent 做汇总。

那什么情况下不适合用多智能体呢？

（当然，之所以会有这个问题，是因为现在智能体的能力还没有达到足够高的水平，这才会有一些目前不适合用的场景。相信在不久的将来，这些都将不会成为限制。）

需要所有智能体共享同一个上下文（如实时协作编辑）的任务不适合用多智能体。

就像文件系统常会有读写冲突、写写冲突一样，如果不同智能体要协作编辑，就必然要引入锁机制，还需要智能体之间的通信。

而类似 Claude Code 框架中的 subagent 每个都只有各自独立的上下文，所以难以保持强一致性。

智能体之间存在大量相互依赖关系的任务（如 A 的结果必须实时传给 B 才能继续），目前也不适合用多智能体。这是因为目前 LLM 智能体间的协调能力还不够成熟，容易出错或延迟。

其实，大多数编程任务都不太适合用 subagent。在我实际使用的过程中，我发现 Claude Code 其实除了用 Explore 来看代码库之外，很少用 General-Purpose Agent 来做修改操作。

这是因为代码的逻辑往往是线性的，或者需要紧密的模块间协同，很难拆分成大量真正独立的子任务。

总而言之，subagent 目前主要适用于并行度高的场景，而编程类的可并行部分显然少于调研类任务。

（4）Claude Code 中内置的 subagent

根据逆向工程 under-the-hood-of-claude-code-its-not-magic-it-s-engineering 中 Agent 工具的描述，Claude Code 包含了五个内置的 subagent：

Available agent types and the tools they have access to:
- general-purpose: General-purpose agent for researching complex questions, searching for code, and executing multi-step tasks. When you are searching for a keyword or file and are not conf
ident that you will find the right match in the first few tries use this agent to perform the search for you. (Tools: *)
- statusline-setup: Use this agent to configure the user's Claude Code status line setting. (Tools: Read, Edit)
- Explore: Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. \"src/components/**/*.tsx\"), search code for keywords (eg. \"API en
dpoints\"), or answer questions about the codebase (eg. \"how do API endpoints work?\"). When calling this agent, specify the desired thoroughness level: \"quick\" for basic searches, \"med
ium\" for moderate exploration, or \"very thorough\" for comprehensive analysis across multiple locations and naming conventions. (Tools: All tools except Agent, ExitPlanMode, Edit, Write,
NotebookEdit)
- Plan: Software architect agent for designing implementation plans. Use this when you need to plan the implementation strategy for a task. Returns step-by-step plans, identifies critical f
iles, and considers architectural trade-offs. (Tools: All tools except Agent, ExitPlanMode, Edit, Write, NotebookEdit)
- claude-code-guide: Use this agent when the user asks questions (\"Can Claude...\", \"Does Claude...\", \"How do I...\") about: (1) Claude Code (the CLI tool) - features, hooks, slash comm
ands, MCP servers, settings, IDE integrations, keyboard shortcuts; (2) Claude Agent SDK - building custom agents; (3) Claude API (formerly Anthropic API) - API usage, tool use, Anthropic SD
K usage. **IMPORTANT:** Before spawning a new agent, check if there is already a running or recently completed claude-code-guide agent that you can resume using the \"resume\" parameter. (T
ools: Glob, Grep, Read, WebFetch, WebSearch)

我们可以看到，不同的 subagent 在执行权限和分工上都有很大的区别：

general-purpose 是一个功能最全面的代理，适用于需要多步骤处理、复杂研究、代码搜索和跨领域任务，它可以使用几乎所有的工具（等会儿我们会看到为什么是“几乎”，而不是全部）。

Explore 是一个专门用于快速探索和理解代码库的 Agent，擅长按文件名模式搜索（如 src/**/*.tsx）、关键词搜索、回答代码相关问题。

它支持指定探索深度（quick、medium、very thorough）。工具权限方面，它只能读不能写。

Plan 是一个扮演规划师角色的 agent，用于设计方案、制定分步计划、识别关键文件、权衡架构决策。与 Explore 类似，它的权限也是只读不写，输出的是结构化的实施计划。

statusline-setup（状态栏配置）是一个高度专用的 subagent，唯一用途是帮助用户配置 Claude Code 命令行工具的状态栏显示。

claude-code-guide（Claude 产品指南）这是一个专门回答关于 Claude 相关产品问题的 subagent。

我们可以根据不同 subagent 执行的难度来让它们使用不同大小的模型。比如 Explore 不需要复杂推理，所以默认用的是快且便宜的 haiku 模型；

而 Plan 和 General-Purpose 需要与主对话保持相同的能力水平，所以继承的是主 Agent 所使用的模型（就像孙悟空吹一把毫毛变出许多个自己的分身，或者科幻小说中提到的自我意识的复制一样）。

当然，这些配置我们都可以通过修改 Claude 的配置文件来自己定义。

每个 subagent 都有自己专用的 system prompt，在这个开源逆向 repo 中，我找到了上面五个 subagent 中四个的 system prompt：

Explore（agent-prompt-explore.md）
Plan（agent-prompt-plan-mode-enhanced.md）
Claude Guide（agent-prompt-claude-guide-agent.md）
Status line setup（agent-prompt-status-line-setup.md）

唯独没有找到 General-Purpose 的。那么 General-Purpose 的 system prompt 在哪里呢？我一开始认为 General-Purpose 继承的就是主 Agent 的 system prompt。

这就要引出一个误区：General-Purpose Agent 继承的是主 Agent 的 system prompt，因此可以使用所有的 tools。（which is not true）

实际上，General-Purpose Agent 和主 Agent 的 system prompt 有很多差别，这是因为在 system prompt 的拼接时（上一篇文章中我们已经说过，system prompt 并不是固定的，而是动态拼接的），会有一个变量 IS_SUBAGENT 来根据是否为 subagent 来拼上不同的话术。

例如：在输出风格上，主 Agent 的要求是“完成任务后提供详细的书面报告”，而 General-Purpose 这个 subagent 则被要求输出“简明扼要的总结，只包含所做的工作和关键发现”，因为子 Agent 的输出并非直接面向用户，而是要先汇报给主 Agent、再呈现给用户，因此只需要保留核心信息就可以了。

General-Purpose Agent 的工具列表也和主 Agent 不一样，并不是完全继承的。

虽然上面的 Agent 工具描述中，General-Purpose 能使用的工具是”（Tools: *）“，但是并不意味着真正的“所有工具”，而是“所有执行类工具”，管控类工具（Agent，TaskOutput，TaskStop，AskUserQuestion，EnterPlanMode，ExitPlanMode)）被系统层面过滤掉了。

这里我们可以特别地看到，General Purpose 这个 subagent 是没有 Agent 工具的。

事实上，所有的 subagent 都没有 Agent 工具，所以 subagent 不能递归地启动新的 subagent。这是 Claude Code 有意为之的设计，为的就是防止无限递归。

当然，这样设计也是因为目前的 Agent 能力还有限，就像 Anthropic 的开发者在博客 How we built our multi-agent research system 中承认的那样，“LLM 智能体在实时协调和委派其他智能体方面还不够出色”。

还有若干不同的地方，比如 subagent 每次 Bash 调用之间工作目录会被重置，因此必须始终用绝对路径；等等。

（5）Claude Code中subagent 运行流程

Agent Tool 的 prompt 是由这两个拼在一起的：

tool-description-agent-when-to-launch-subagents.md
tool-description-agent-usage-notes.md

这个 prompt 对 subagent 的调用方式做了清晰的说明。

下面我们结合 Agent Tool 的描述 prompt，以及实际运行流程的例子，来对调用 subagent → subagent 执行 → 回收 subagent 结果这一套流程进行详细的说明和模拟。

（a）什么时候该调用 subagent

如果某个 agent 的描述中提到”应主动使用”，则不需要等用户明确要求，主 agent 应自行判断并启动。

（b）并发与后台执行

应尽量并发启动多个 agent，即：在同一条消息里发出多个 Agent 工具调用，而不是分多次发。

对于需要结果才能继续的任务用前台模式，不需要立刻得到结果的可以用后台模式（run_in_background），后台任务完成后会自动通知，不要轮询或 sleep 等待。

需要注意的是，“并发执行”和”后台执行”是两个截然不同的概念。

并发决定的是数量。如果并发执行，同一轮对话中会一次性发出多个 Agent 工具调用，这些子 Agent 会同时启动。

后台决定的是阻塞行为。通过设置 run_in_background: true，subagent 在后台运行，主对话不会等待其完成，可以立即继续执行其他任务或者响应用户。

“并发”和”后台”可以随意组合，比如并发但不后台运行、后台运行但不并发。

（c）任务描述与 prompt 书写

主 agent 的每次调用都附带着 3-5 个词的简短描述；

并且提供足够清晰详细的 prompt，说明 sub-agent 要做什么，因为在一般情况下（只要不指定 CAN_FORK_CONTEXT=True），sub-agent 就不会继承主 agent 的上下文，因此它对整个问题的背景是完全不了解的，它能看到的只是主 agent 给它委派的 prompt。

所以主 agent 给它的 prompt 就需要足够详细，确保 subagent 能自主完成并返回所需信息。

上面三条（a）（b）（c）都是在讲 subagent 该什么时候调用、如何调用。

下面是我运行的一个示例，可以看到 Claude Code 主动使用了 3 个并行的、后台执行的 Explore Agent 来帮我查看代码库：

三个并行的 subagent，正在后台执行。屏幕上打出来的“探索项目整体结构和配置”这种字样就是 sub-agent 的 description。

启动 subagent 方式和调用一个普通 tool 一样，只不过调用的是 Agent 这个 tool。

下面我们看一个例子，看看 subagent 的调用在 message 中大概是个什么格式：

[
{
"role": "assistant",
"content": [
{
"name": "Agent",
"type": "tool_use",
"input": {
"prompt": "探索xxxx 代码库的整体结构。请找出：\n1. 项目根目录下的所有文件和目录\n2. 主要的配置文件（package.json, composer.json, readme.txt, README.md 等）\n3. 主要入口文件\n4. 项目使用的主要编程语言\n\n请读取 readme.txt 或 README.md、package.json、composer.json（如果存在）的内容，并详细报告。",
"description": "探索项目整体结构和配置",
"subagent_type": "Explore",
"run_in_background": true
}
},
{
"name": "Agent",
"type": "tool_use",
"input": {
"prompt": "探索 xxx 代码库中的 PHP 文件。...... ,最后，报告 PHP 代码的主要模块和功能",
"description": "分析PHP源码和WordPress插件逻辑",
"subagent_type": "Explore",
"run_in_background": true
}
},
{
"name": "Agent",
"type": "tool_use",
"input": {
"prompt": "探索 xx代码库中的 JavaScript 和前端相关文件。请：\n1. ...\n2. ..., 5. 报告前端资源的组织结构和构建流程",
"description": "探索前端JS/CSS资源和构建工具",
"subagent_type": "Explore",
"run_in_background": true
}
}
]
},
]

可以看到，这里并行地起了 3 个 Explore 类型的 subagent，而且是在后台执行的（run_in_background=true）。subagent 的调用方式和普通的 tool call 一样，只是 name 设成了”Agent”。

在传入的参数中，“description”就是刚才说的”3-5 个词的简短描述”，它会被打印在屏幕上；而”prompt”就是实际交给 sub-agent 去执行的一个指令，它需要描述清晰到底需要 sub-agent 去做一个什么样的事。

（d）subagent 执行

如上所述，subagent 运行在独立的上下文当中，所以它能看到的就是自己的 system prompt+刚才主 agent 传给它的 prompt。

之后，它就开始利用自己可以使用的工具、根据 system prompt 中的约束，来解决这个 prompt 问题了。

（e）回收结果

Subagent 完成后，它的最后一条 assistant message 会作为字符串返回给主 agent，这个消息对于用户是不可见的。主 agent 需要自己把这个结果整理一下，然后用文字告诉用户。

同时返回的还有 agent ID，可供后续 resume 使用（sub-agent 的 resume 和主 agent 一样，可以恢复上一次调用时候完整的上下文继续工作）。

下面是一个返回内容的示例：

{
"role": "user",
"content": [
{
"type": "tool_result",
"content": [
{
"text": "以下是 xxx 目录下的调研结果.....", ##
#sub
-agent返回的那条消息
"type": "text"
},
{
"text": "agentId: xxx (use SendMessage with to: 'xxxxx' to continue this agent)\ntotal_tokens: xxx\ntool_uses: x\nduration_ms: xxxx",
"type": "text"
}
],
}
]
}

多智能体的协调模式分类

我们刚才已经详细介绍了 Claude Code 中使用的 subagent 的工作方式——这是一种在实际落地中能够良好工作的 Multi-Agent 设计方案。

然而，Multi-agent 的设计远远不只这一种，下面会根据协调模式来进行分类介绍。

多智能体的协调模式是非常重要的。如果这个设计得不好就会产生很多问题，比如：智能体之间的 message 可能形成回路、资源竞争可能产生冲突、错误可能会像病毒一样扩散。

Google DeepMind 在 2025 年的一项研究中发现：当智能体数量超过 4 个后，如果拓扑设计不当，准确率增益会迅速饱和甚至下降——这就是所谓的“协调税”（Coordination Tax）。

如果按照协调模式（即信息如何在智能体间流动）来分类，多智能体的设计大致可以分为四类。

（1）Orchestrator-Worker

我们刚才看到的 Claude Code 中的 subagent 设计方式就属于这一类，这也是最符合直觉的一类。

如果画出拓扑图来的话，它会是一个 star 结构：

上面的是 Orchestrator，下面三个是 Worker

这种模式有一个中央的“协调器”（Orchestrator）和若干个“工作节点”（Worker）。

Orchestrator 是整个系统的入口和决策中心。当用户输入一个任务后，协调器会首先将复杂任务拆分成若干个可以独立执行的子任务，然后分发给不同的工作节点。

在工作节点完成之后，收集所有工作节点的输出，进行整合，最终生成对用户的响应。Worker 节点之间是不能直接通信的，所有信息都要经过 Orchestrator。

虽然这种方法简单可控，而且能保证全局一致性（不会出现多个智能体对共享资源做出冲突决策的情况），但是也会有很多短板：

单点瓶颈：就和所有的中心化系统一样，所有流量都要经过 Orchestrator 这一个节点，这就产生了一个 bottleneck。
上下文窗口的压力：虽然 Worker 的上下文是隔离的，但是 Orchestrator 毕竟需要所有子任务的结果才能最终聚合信息。如果子任务特别多的话，上下文也可能被撑爆。
不能紧密协作：如果工作节点之间需要相互讨论、质疑、迭代改进，这种模式会强制所有交流绕经 Orchestrator，延迟很高。

因此，就产生了下面这些更为复杂的协调拓扑结构。

（2）Hierarchical

这种模式将 Agent 组织成一棵多级树。顶层是负责分解高维度的目标；中层负责将子目标进一步拆解并分给下层；底层是执行层，负责具体操作。每一层只与上下层交互，同层之间不直接通信。

如果画出拓扑图来的话，它会是一个树结构：

这种方式的可扩展性强**，**新增智能体通常只需要在某个叶子节点下添加，可以支持数十甚至上百个智能体。

而且对于刚才说的上下文长度爆炸的问题，它也能够有效解决，因为中层向上层汇报时，会将细节总结为高层可理解的摘要，大大减少了顶层需要处理的 token 数量。

但是，就像我们在刚才讲 Claude Code 的 subagent 时说的那样，“LLM 智能体在实时协调和委派其他智能体方面还不够出色”。

所以 Claude Code 才特意设计子 Agent 不能派生出更多的子 Agent，从而否决了这种 Hierarchical 的设计，防止无限递归和滥用子 Agent 的风险。

（3）Mesh（对等网络）

Mesh 模式中，Agent 之间建立显式的点对点连接，直接传递信息给对方。每个 Agent 知道自己需要与哪些伙伴直接交流，消息可以不经过任何中央节点。

它们共享一个任务（如写代码、做研究），需要频繁交换中间结果、互相批评、迭代改进。

如果画出拓扑图来的话，它会是一个稠密图：

当然，这个连接方式可以是全连接（每个 Agent 与其他所有 Agent 都相连），但更常见的是按需连接（比如代码任务中 Planner ↔ Coder ↔ Verifier 形成三角关系）。

毕竟在全连接中，连接数可是 N（N-1）/2，要是节点数太多，直接就组合爆炸了。

Mesh 在学术界的一个成熟形态是多智能体辩论：多个智能体围绕一个问题相互批判、改进答案。

但是纯 Mesh 在生产环境中很少单独使用，主要就是因为可控性问题：

缺乏全局视图：没有中央节点持有完整状态，需要各个 Agent 靠自己拼凑因果链，非常困难。
状态一致性问题：如果多个智能体同时修改共享资源，需要额外的锁或共识机制，否则会出现冲突。

因此，在工业界中更常见的做法是 Hybrid：在 Mesh 之上叠加一个中央协调节点，这样既能保留局部直接通信，又能维持全局的控制。下面我们要讲的 Claude Code 中的 Agent Team 就属于这一类型。

还有一种和 Mesh 比较类似的设计，叫做 Swarm（虫群）。

在 Mesh 中的 Agent 们彼此认识，可以直接通过发 message 交流；但是 Swarm 中的 Agent 们不直接认识彼此，而是通过共享环境间接地交流。就像一大群蚂蚁或蜜蜂，个体只做简单的事，整体智能从互动中涌现。

比如说，Swarm 中的智能体可以通过一个共享的黑板（Blackboard）来交换信息。

一个 Agent 在黑板写入，其他 Agent 读取。因此 Agent 之间没有显式的连接边，但是所有 Agent 都连接到黑板；这种拓扑是隐式的。

Swarm 目前还是实验性的，不过之后我们会看到，Claude Code 的 Agent Team 也采用了一部分它的思想。

Claude Code 的 Agent Team

“我们可以做出决定，可以跟别人达成共识，可以分享信息。我可以跟齐佛沃尔的大使交谈，你可以跟海恩的物理学家交谈，不同星球之间思想的交流不再遥遥无期…我们可以交谈了，我们终于能够一起交谈了。”——《一无所有》，厄休拉 · 勒古恩

顾名思义，Agent Teams 就是一个能够让多个 Agent 像团队一样协同工作的机制。

如下图所示，Agent Teams 中有两个角色：

团队领导（Team Lead）：这是你最初启动的那个主 Agent。它的职责是创建团队成员、分配任务，并整合最终结果。
队友（Teammates）：每个队友都有自己的上下文窗口，可以独立工作，并且可以相互直接通信，而不仅仅是向领导汇报。

由此可见，Agent Team 和 subagent 的一个明显不同就是，Agent Team 的 teammate 之间可以直接通信。

首先需要确认的是，teammate 的上下文窗口确实是独立的，而且 Lead 的历史对话不会传递给 teammates。那么，teammate 之间的通信是怎么做到的呢？

mailbox：这是一种去中心化直接通信的方式，就像发短信一样。teammates 之间可以用 message 发给特定队友，或用 broadcast 发给所有人。发送之后，系统（Mailbox）负责投递，lead 不需要轮询或转发。

空闲通知（Idle notification）：队友完成工作或进入空闲状态时，自动通知 lead，让 lead 知道可以分配新任务或进行下一步。

共享的任务列表（shared task list）：它是团队成员之间协作的核心，确保工作被合理分配、有序推进，并自动处理依赖关系。

每个任务有三个状态：pending（待处理）、in progress（进行中）、completed（已完成），而且任务可以声明对其他任务的依赖。

Lead 可以明确指派任务给某个 teammates，队友也可以在完成自己的任务后，可以自我认领下一个未分配、未阻塞的任务。系统通过文件锁来防止多个队友同时认领同一个任务。

依赖关系由系统自动管理，无需人工干预。当被依赖的任务被标记为“已完成”时，所有依赖它的任务会自动解除阻塞，状态从“被依赖阻塞”变为“可认领”。

现在大家在回顾一下第二节讲的多智能体的协调模式分类。其实从 Agent Teams 中我们可以看到几个设计模式的影子。

首先，它介于 Mesh 和 Orchestrator 之间：在 Mesh 之上叠加一个中央协调节点，这样既能让 Teammates 直接通信，又能维持全局的控制。

而且，每个队友都能够访问到一个共享的任务列表（shared task list），从这里也能看到类似 Swarm 中通过“黑板（blackboard）”进行信息交流的思想。

关于 Agent Teams 的使用，可以看官方的文档：

https://code.claude.com/docs/en/agent-teams

作者：魔法学院的Chilia

来源：https://zhuanlan.zhihu.com/p/2018114851793315554

END

加入学习

**✅**我是丁师兄，专注于智能驾驶大模型，持续分享LLM面试干货。

✅****大模型1v1辅导，已帮助多名同学成功上岸

**微信：**dsxaigc

cover_image

魔法学院的Chilia 丁师兄大模型

内容效果不满意？点此反馈