MCP 与多 Agent

前面五节我们把一个 Agent 该有的零件都装齐了：工具、记忆、检索、规划。现在剩下两个真正决定它能不能长成产品的问题。第一个是接口——你的 Agent 要接公司的数据库、Slack、日历、代码仓库，每接一个都要重写一遍胶水代码，接口的数量是「Agent 数 × 数据源数」，这笔账迟早会压死人。第二个是协作——多请几个 Agent 一起干，是不是就更快更强？这一节的答案会让你意外：官方实测多 Agent 能带来 90.2% 的性能提升，但它烧掉的 token 是普通聊天的十五倍，而且在编码任务上官方明说「不适用」。另外还有一个更有意思的东西——MCP 的核心概念在 2026 年 7 月刚被官方改过一次，教材写完就过时，这件事本身值得当一课来讲。

MCP 的官方坐标：谁、哪一天、原话怎么说

MCP 有明确的官方公告，坐标如下：

官方的定义原文值得逐字读一遍，因为它把「MCP 是什么」说得比任何二手解释都准：

a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments. Its aim is to help frontier models produce better, more relevant responses.

翻译：一套用于把 AI 助手连接到「数据实际所在的那些系统」的新标准，涵盖内容仓库、业务工具和开发环境；目的是帮助前沿模型给出更好、更相关的回答。

请注意最后那句 help frontier models produce better, more relevant responses——MCP 的目标不是让模型更聪明，而是让模型能看到该看的东西。这个定位非常清晰，也解释了为什么它是「协议」而不是「模型技术」。

它要解决的到底是什么问题：一笔 N×M 的账

官方对设计动因的表述同样值得逐字看：

even the most sophisticated models are constrained by their isolation from data—trapped behind information silos and legacy systems. Every new data source requires its own custom implementation, making truly connected systems difficult to scale.

翻译：即使最先进的模型也受制于「与数据相隔离」这件事——被困在信息孤岛和老旧系统背后。每接一个新数据源都要写一套自己的定制实现，这让「真正互联的系统」难以规模化。

两个词当场翻译：information silos（信息孤岛）说白了就是「数据各自锁在各自的系统里，互相不通气」；legacy systems（老旧系统）指那些还在跑、但没人愿意动的旧软件。

而官方给的解法原话是：It provides a universal, open standard... replacing fragmented integrations with a single protocol（提供一个通用的开放标准……用单一协议取代碎片化的集成）。

这笔账画出来最直观：

【MCP 之前】每个 AI 应用 × 每个数据源，各写一套

   Claude ────┬── 自己写的 Slack 接法
              ├── 自己写的 GitHub 接法
              └── 自己写的 Postgres 接法
   Cursor ────┬── 又写一遍 Slack 接法
              ├── 又写一遍 GitHub 接法
              └── 又写一遍 Postgres 接法
   你的应用 ──┬── 再写一遍 Slack 接法
              ├── 再写一遍 GitHub 接法
              └── 再写一遍 Postgres 接法

   3 个应用 × 3 个数据源 = 9 套代码
   N 个应用 × M 个数据源 = N×M 套   ← 这就是「碎片化集成」

【MCP 之后】每一边只实现一次

   Claude ───┐                    ┌─── Slack MCP server
   Cursor ───┼──── MCP 协议 ──────┼─── GitHub MCP server
   你的应用 ─┘                    └─── Postgres MCP server

   3 + 3 = 6 套代码
   N + M 套   ← 从乘法变成了加法

把这个差别换算成可感知的量：假设有 10 个 AI 应用和 50 个数据源。乘法是 500 套集成代码，加法是 60 套。而且乘法模式下，每新增一个数据源，全部 10 个应用都得各自改一遍代码；加法模式下只需写一个 server，10 个应用当天全都能用。

LSP 类比：为什么这个参照系特别贴切

官方提到的 LSP（Language Server Protocol，语言服务器协议）值得展开，因为它是一个已经被历史验证过的成功案例。

LSP 解决的是编辑器世界里一模一样的账。在 LSP 之前：VS Code 要支持 Python 的自动补全，得自己写一套 Python 语义分析；要支持 Go，再写一套 Go 的。而 Vim 想支持 Python，又得自己从头写一套。M 个编辑器 × N 种语言 = M×N 套插件，全世界的程序员在重复劳动。

LSP 之后：语言方只需写一个「语言服务器」（比如 Python 的 Pylance、Rust 的 rust-analyzer），编辑器方只需实现一次 LSP 客户端。结果是任何编辑器都能一夜之间支持几十种语言。

JSON-RPC 2.0 这个词也翻译一下：RPC 是 Remote Procedure Call（远程过程调用），说白了就是「让另一台机器上的一个函数替我跑一下，把结果给我」。JSON-RPC 就是用 JSON 这种文本格式来描述「我要调哪个函数、参数是什么」。相当于你给餐厅后厨递一张标准格式的菜单点单条：「菜名：宫保鸡丁，要求：不要花生」——后厨照单做菜，不用跟你面谈。

三个角色：Hosts、Clients、Servers

现行的官方规范把参与者分成三种角色。这三个词很容易混，用一个类比一次说清：

为什么要把 Host 和 Client 分开？因为一个 Host 通常要同时连好几个 server，而每条连接的状态、权限、生命周期都是独立的。一位秘书专门对接一家供应商，比让老板一个人同时跟五家供应商在同一个会议室里说话要清楚得多。

★ Server 能提供什么：Resources、Prompts、Tools

MCP server 能给出三类东西。官方对这三者的一句话说明如下，我把原文和翻译并列，因为这三个词的边界很容易被讲混：

最容易搞混的是 Resources 和 Tools。分界线其实很清楚：Resources 是「你可以读什么」，Tools 是「你可以做什么」。读一份文件是 Resource，把文件删掉是 Tool。好比去图书馆：「架子上有哪些书」是 Resources，「帮我把这本书借出去」是 Tools——后者有副作用，前者没有。

而 Prompts 那一条注意它的服务对象是 for users——是给人用的。它是 server 作者预先写好的一段模板，用户在界面上点一下就能用，比如「帮我把这个 GitHub issue 总结成一段周报」。相当于银行柜台旁边摆的那叠已经印好格式的发票申请单——不用你自己想该写什么。

★★ Client 端能力：只剩 Elicitation，而且有三项已被弃用

接下来是本节时效性最强、也最容易写错的一段。如果你手边有一本 2025 年出版的 AI 工程书，它这一节大概率已经过时了。

先说现在的正确说法：客户端能力现在只列 Elicitation 一项。

• Elicitation（信息征询）server 可以主动向用户索取额外信息。说白了就是：干活干到一半发现缺个参数，server 有权反过来问用户一句「请问你要哪个仓库」。相当于装修工量到一半打电话问你「主卧的插座要装几个」——不是他自作主张，也不是干不下去，而是有一条正式的通道回头问你。

然后说被弃用的那三项——这一条极其重要：

按官方的 feature lifecycle（特性生命周期）政策，被弃用的特性至少还会保留 12 个月，所以现有实现不会立刻崩掉。但从写文档、写教材、做技术选型的角度：

如果你把 Sampling 列为「MCP 四大核心概念」之一，截至 2026 年 8 月，这已经是过时信息。

正确的说法是：Resources / Tools / Prompts 三大 server 能力 + Elicitation 客户端能力；早期的 Sampling / Roots / Logging 已被官方弃用。

这件事本身特别值得当一课来讲。你可能会觉得「一本书刚出版就有一节过时了」很尴尬，但这恰恰是快速演进领域的常态，而不是意外。三个可迁移的经验：

• 经验一 · 写技术内容必须标注核实时间「截至 2026 年 8 月」这七个字不是废话，它是让读者判断信息新鲜度的唯一依据。不标时间的技术断言，三个月后就是有害信息。
• 经验二 · 分清「原理」和「接口」的半衰期JSON-RPC 是什么、N×M 为什么要变成 N+M、LSP 的历史经验——这些十年后还成立。而具体有哪几个 capability、字段叫什么名字，半年就可能变。学习时该把重量压在前者。
• 经验三 · 一手规范永远优先于二手教程包括本节在内的任何二手内容都会滞后。动手实现时以官方规范页面为准，把教程当地图不当法条。

★ 版本号的官方内部不一致：如实呈现

这里还有一件有意思的事，也是做技术核实时的一个典型情形：官方文档自己内部对不上。

具体情况是这样：

• versioning 页面说/specification/versioning 页面上写着 The current protocol version is 2025-11-25
• latest 页面实际指向/specification/latest 实际解析到的是 2026-07-28
• 而 2026-07-28 显然是生效的它已有完整 changelog，并且 Roots 页面上明确标注了 deprecated as of protocol version 2026-07-28
• 但 changelog 里又有 draft 字样changelog 中出现 introduced in this draft（在本草案中引入）的表述

那么该怎么写？正确做法是如实呈现两个数字，不要单给一个：

截至 2026 年 8 月，官方 versioning 页标注的 current 版本为 2025-11-25，最新修订为 2026-07-28。

为什么不挑一个「看起来更权威」的写？因为挑哪一个都会误导一部分读者。写 2025-11-25，读者会以为 Sampling 还没被弃用；写 2026-07-28，读者去查 versioning 页面会发现跟你说的不一样，然后怀疑整篇文章。把矛盾如实摆出来，读者自己能判断——这比替读者做一个可能错的决定负责得多。

顺带这也是一个很好的观察：一份活跃演进中的规范，其文档的各个页面之间出现短暂不一致是很正常的。相当于一个正在施工的工地，图纸改了三版，墙上贴的那张可能还是第二版。看到这种情形不要慌，也不要急着断言谁错了——记下时间、记下两处出处，就是最专业的处理。

2026-07-28 的其他重大变更：MCP 变成无状态了

那次修订改的不止是弃用三个特性，还有一系列结构性调整。这些改动的方向高度一致：让协议更简单、更适合大规模部署。

其中「无状态」这个改动最值得体会，因为它是所有大规模服务的必经之路。用一个类比说透：

有状态就像一家只有一位老客服的小店——你打电话过去，她记得你上次买了什么、说到哪儿了，体验很好。但她一请假，或者店里要同时接一千个电话，就完了：因为「上下文」只在她一个人脑子里。

无状态就像大型客服中心——每次打进来随机分给一位坐席，所以你每次都得把订单号说一遍。麻烦一点，但代价是换来了「随便加坐席就能扩容」的能力。协议设计从有状态转向无状态，几乎总是因为要上规模。

官方还给出了几个扩展机制，简单记一下方向：

• Tasks处理异步长任务——有些活儿要跑十分钟，不能让请求一直挂着。相当于洗衣店给你一张取衣单，洗完了你再来取，而不是站在那儿等两小时。
• Skills over MCP把「技能」这种更高层的封装也通过 MCP 分发。
• MCP Apps对话内嵌交互 UI——不只返回文字，还能在对话里嵌一个能点的界面。相当于客服不再口述「你要选套餐 A 还是 B」，而是直接推给你一个可以点的菜单。

动手写一个最小 MCP server

说了这么多，一个 MCP server 到底长什么样？下面是一个能跑的最小例子。看完你会发现它朴素到几乎让人失望——而这正是一个好协议该有的样子。

# 安装： pip install mcp
#
# 这个 server 提供两样东西：
#   · 一个 Tool（模型可以执行的函数）
#   · 一个 Resource（模型或用户可以读的数据）
# 注意区别：Tool 有副作用/会算东西，Resource 只是「读得到的内容」。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("库房助手")          # server 的名字，会显示给用户

# ---------- Tools：Functions for the AI model to execute ----------
@mcp.tool()
def stock_check(sku: str) -> str:
    """查询某个货号当前库存。sku 例如 A-1001。"""
    FAKE = {"A-1001": 42, "A-1002": 0, "B-2003": 7}
    if sku not in FAKE:
        return f"没有货号 {sku} 的记录"
    n = FAKE[sku]
    return f"{sku} 当前库存 {n} 件" + ("（已缺货）" if n == 0 else "")

@mcp.tool()
def restock_request(sku: str, qty: int) -> str:
    """发起补货申请。这是一个有副作用的动作，所以属于 Tool。"""
    if qty <= 0:
        return "补货数量必须大于 0，已拒绝"
    if qty > 1000:
        return "单次补货上限 1000 件，请拆单——这是刻意的护栏"
    # 真实场景这里会写数据库 / 调 ERP 接口
    return f"已为 {sku} 提交补货申请 {qty} 件，待主管审批"

# ---------- Resources：Context and data for the user or model ----------
@mcp.resource("warehouse://rules")
def rules() -> str:
    """库房规章。这是「读得到的东西」，没有任何副作用，所以是 Resource。"""
    return (
        "1. 单次补货上限 1000 件，超出须拆单。\n"
        "2. 缺货货号优先补货，队列按缺货时长排序。\n"
        "3. 所有补货申请须经主管审批后生效。\n"
    )

# ---------- Prompts：Templated messages and workflows for users ----------
@mcp.prompt()
def daily_report(area: str) -> str:
    """给用户用的模板：一键生成某区域的库存日报。"""
    return (
        f"请为库房 {area} 区生成今日库存日报，要求：\n"
        f"1. 先读 warehouse://rules 了解规章；\n"
        f"2. 列出所有缺货货号；\n"
        f"3. 对缺货货号给出建议补货量，但不要直接提交申请。\n"
    )

if __name__ == "__main__":
    # 本地运行时走 stdio（标准输入输出），
    # 部署到线上则用 Streamable HTTP —— 注意 HTTP+SSE 自 2025-03-26 起已弃用
    mcp.run()

这段代码里有四处值得留意，都对应本节讲过的概念：

• Tool 与 Resource 的分界线画得很清楚stock_check（查库存，要算）和 restock_request（提申请，有副作用）是 Tool；rules（一段固定的规章文本，纯读）是 Resource。拿不定主意时问一句：「这件事做完，世界变了吗？」变了就是 Tool。
• Prompt 是给人用的daily_report 不是给模型自动调的，是用户在界面上点一下、填个区域名就能发起的模板。注意它最后一句刻意写了「不要直接提交申请」——模板本身就是一道护栏。
• 工具里写了硬性上限qty > 1000 直接拒绝。护栏要写在 server 里，不要只写在提示词里——提示词能被绕过，代码不能。
• docstring 就是模型看到的说明书函数的文档字符串会被当作工具描述交给模型。写得含糊，模型就用错；这一行文字的重要性不亚于函数体。

MCP 的采用现状：只说有一手来源的

关于「谁支持了 MCP」，网上传闻极多。本节只写有官方一手来源的，并明确标注证据。

OpenAI 已官方支持 MCP——这一条有两条独立的官方证据：

注意那两个参数——allowed_tools 和 require_approval——它们其实就是上一节讲过的两条工程原则的官方落地：缩小工具集和写操作加审批。一个协议的成熟度，往往就体现在它是不是把安全护栏做成了一等公民的参数，而不是留给使用者自己想办法。

Anthropic 侧：Messages API 提供 MCP connector，无需自建 MCP client 即可连接远程 MCP server。

而下面这一条必须说清，因为它比「某家大厂宣布支持」更能说明 MCP 的行业地位。

★★ 治理已中立化：MCP 进了 Linux Foundation

MCP 现在的正式主体是 Model Context Protocol a Series of LF Projects, LLC——也就是说，它已经被置于 Linux Foundation 旗下的 LF Projects 之下，不再是 Anthropic 一家的项目。

为什么这一条比「OpenAI 宣布支持」更重要？因为「谁在支持」会变，而「谁拥有」决定了它能不能被信任。

换成大白话：如果一个「开放标准」的最终决定权还在某一家公司手里，那所有竞争对手在采用它之前都会犹豫——万一哪天这家公司改规则、加限制、或者把它做成自家产品的护城河怎么办？这不是多疑，是历史上反复发生过的事。

而「成员资格属于个人而非公司、没有为特定公司预留席位」这一条，恰恰是针对这个疑虑的正面回答。相当于一条马路的产权从「某家沿街商铺的私人车道」变成了「市政道路」——从那一刻起，对面那家竞争的商铺也愿意让顾客走这条路了。

这里必须做一个严格的限定：微软、谷歌官方支持 MCP 的一手公告我没有取到（搜索只返回自媒体内容）。所以本节提到生态时的准确说法是：OpenAI（官方文档确认）、Anthropic（官方文档确认），以及 Linux Foundation 治理下的社区生态。不要断言微软或谷歌已官方支持——哪怕这件事听起来很可能是真的，没核到一手来源就不该写成事实。

MCP 的另一面：接入变简单，攻击面也变大

现在说代价。这一段的分量不亚于前面所有优点。

OpenAI 官方文档里有一句非常直白的警告：A malicious server can exfiltrate sensitive data from anything that enters the model's context（一个恶意的 server 可以把进入模型上下文的任何敏感数据窃取出去）。

exfiltrate 这个词翻译一下：它是「把数据偷偷运出去」的意思，比 steal 更强调「悄悄地、成规模地搬走」。

为什么 MCP 会放大这个风险？把逻辑捋一遍：

• 第一步 · 上下文是共享的模型的上下文里同时装着：你的问题、你的公司文档、A server 返回的内容、B server 返回的内容。所有 server 的输出都进了同一个池子。
• 第二步 · 工具是模型自己选的模型决定调哪个工具、传什么参数。如果它被上下文里某段文字诱导（就是 §11.4 讲过的提示词注入），它可能把 A server 给的敏感数据，当成参数传给 B server。
• 第三步 · 而 B server 是第三方写的MCP 生态的价值就在于「任何人都能写 server」，但这也意味着你装的那个 server 是谁写的、它把参数发到哪去了，你未必清楚。

这就像你家装修时来了五个工种的师傅，钥匙都给了。整体效率高了很多，但你家的门禁从「一把钥匙一个人」变成了「五把钥匙五个人，其中有几个你只在网上见过」。方便和风险是同一枚硬币。

该怎么办？三条最基本的：

• 用工具白名单OpenAI 的 allowed_tools 就是干这个的。只放开这个任务确实需要的工具，别把整个 server 的能力全打开。
• 给写操作开审批require_approval。凡是会把数据发出去、或者产生不可撤销后果的调用，都过一道人工确认。
• 对 server 来源做尽调跟你不会随便运行网上下载的 exe 是同一个道理。一个 MCP server 拿到的权限，往往比一个普通程序更大——因为它连着你的真实业务数据。

从一个 Agent 到多个 Agent：AutoGen 的思路

现在换到本节的下半场。工具接口标准化之后，一个自然的想法是：既然一个 Agent 能干活，多请几个一起干是不是更好？

这个方向有一篇微软的官方论文，坐标如下：

• 论文标题《AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation》（AutoGen：通过多 Agent 对话实现下一代大模型应用）
• arXiv 编号2308.08155（2023 年 8 月 16 日，v2 为 2023 年 10 月 3 日）
• 作者与机构共 14 人，微软主导，含 Qingyun Wu、Chi Wang、Ahmed Hassan Awadallah、Ryen W. White、Doug Burger（微软技术院士）等

它的核心主张是：让 agent 变成 customizable, conversable（可定制的、可对话的）的单元，并且可以自由组合三类模式——LLM、人类输入、工具。对话模式既可以用自然语言定义，也可以用代码编程定义。

customizable, conversable 翻译一下：「可定制」是说每个 agent 的角色、能力、可用工具都可以单独配；「可对话」是关键——agent 之间的协作方式就是「互相说话」，而不是通过某种特殊的机器协议。

为什么这个设计有意思？相当于一家公司的会议室：里面可以坐着几位各有专长的员工（LLM agent）、一位真人（人类输入）、桌上摆着一台能跑代码的电脑（工具）。他们之间的协作媒介就是「开会说话」——这套形式对三类参与者一视同仁，所以能自由组合。

顺带做一个必要的限定：另一个常被一起提到的框架 CrewAI，我没有取到它的权威论文或官方技术报告。所以本节只把它作为「开源框架」提及，不赋予它论文级的权威。这跟前面对微软/谷歌是否支持 MCP 的处理是同一个原则。

Anthropic 的多 Agent 研究系统：架构长什么样

比论文更能说明工程现实的，是 Anthropic 那篇多 Agent 工程博客《How we built our multi-agent research system》（我们是怎么构建多 Agent 研究系统的），作者为 Jeremy Hadfield、Barry Zhang、Kenneth Lien 等。发布日期我没有取到，所以不写日期。

它的架构是 orchestrator-worker（编排者—工作者）模式：

            ┌─────────────────────────┐
            │     LeadResearcher      │  ← orchestrator（编排者）
            │  负责：拆解问题、派活、汇总  │
            └────────────┬────────────┘
                         │
        ① 先把自己的计划写进 Memory
           为什么必须写？因为上下文超过 200,000 token
           会被截断——计划要是只放在上下文里，
           跑到一半就可能被截没了
                         │
        ② 派生若干 Subagents 并行搜索
           ┌─────────┬─────────┬─────────┐
           ▼         ▼         ▼         ▼
       Subagent1  Subagent2  Subagent3  …   ← workers
       各自有独立上下文，互不干扰
       lead 通常并行起 3–5 个
       每个 subagent 又可并行用 3+ 个工具
                         │
        ③ 结果汇总回 LeadResearcher
                         │
                         ▼
                ┌───────────────┐
                │ CitationAgent │  ← 专门处理引用归属
                │ 哪句话来自哪个源 │
                └───────────────┘

这个架构里有三处设计值得单独记住：

• 计划要落到 Memory，不能只放上下文因为超过 200,000 token 会被截断。好比项目经理不能只把计划记在脑子里，必须写在白板上——开了一天会之后，脑子里最早那部分已经被挤掉了。
• Subagent 各有独立上下文这是多 Agent 最大的技术优势：每个 subagent 都有一份完整的、干净的上下文预算。五个 subagent 等于把可用的「工作台面」扩大了五倍，而且互不干扰。
• 专门有一个 CitationAgent引用归属（哪句话来自哪个来源）被单独拆成一个 agent 来做。这个细节说明了一件事：多 Agent 的价值往往不在「更聪明」，而在「让每个环节都有人专门负责」——就像出版社里校对和排版是两个不同的岗位。

★★ 多 Agent 到底值不值：一组必须带上下文的官方数字

接下来是本节最重要的一组数据。Anthropic 在这篇博客里给出了自己的内部实测，而这组数字是被滥用最严重的一组：

现在说为什么这组数字必须带限定。两个限定，缺一个都构成误导：

• 限定一 · 90.2% 是内部评测，不是公开基准原文写的是 our internal research eval。这意味着这个数字无法被第三方复现，也无法跟别家的数字做横向比较。它是有价值的工程经验，但它不是榜单成绩。
• 限定二 · Anthropic 自己划了适用边界原文：some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit... most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time。

把限定二完整翻译一遍，因为它每一句都在打某种流行说法的脸：

• 要求所有 agent 共享同一上下文的场景，不适合多 Agent 的核心优势正是「各有独立上下文」。如果任务要求大家看到同样的东西，这个优势就变成了纯粹的成本。
• agent 之间依赖很多的场景，不适合A 必须等 B 的结果、B 又要等 C——这种任务并行不起来，多请人只是多付钱。
• 大多数编码任务，比研究任务更难并行这一句直接否掉了「多 Agent 是写代码的未来」这种流行叙事。写代码是高度串行的：接口没定好，下游没法动手；改了一处，别处全要跟着改。
• LLM agent 目前还不擅长实时协调和分派原文 not yet great——注意是 yet（尚未），这是一个关于现状的判断，不是关于原理的否定。

所以正确的引用方式是这样的一整句话，而不是那个孤零零的 90.2%：

在 Anthropic 的内部研究评测上，多 Agent 系统（Opus 4 作 lead + Sonnet 4 作 subagents）相对单体 Opus 4 有 90.2% 的性能提升，代价是 token 用量约为普通聊天的 15 倍；而 Anthropic 自己明确指出，需要共享上下文、agent 间依赖多、以及大多数编码任务，都不适合这套架构。

把 15 倍这个代价换算成可感知的量：假设一次普通对话的成本是一顿早饭钱（比如 5 块），那么单 Agent 大约是 20 块（一份外卖），而多 Agent 系统是 75 块（一顿正经餐厅饭）。如果这个任务本身的价值撑不起 75 块，那 90.2% 的性能提升就毫无意义。这也正是 Anthropic 官方给出的判据原文：multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance（多 Agent 系统需要那些「任务价值足够高，值得为提升的性能付费」的场景）。

顺带那个「token 用量单独解释 80% 性能方差」的发现也很值得琢磨。它的含义是：在 BrowseComp 这类评测上，一个 Agent 系统表现好不好，八成可以由「它花了多少 token」来预测。换成大白话：很多所谓的「架构创新」带来的提升，本质上是「花了更多钱」带来的提升。这是评判任何 Agent 架构宣传时该有的第一反应——先问它花了多少 token。

协调失控：官方举的那几个真实例子

Anthropic 博客里还有一段特别适合科普，因为它描述的失败方式非常具体、非常好笑，也非常真实。原文是：

Early agents made errors like spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources, and distracting each other with excessive updates（早期的 agent 会犯这样的错：为简单查询派生 50 个 subagent、为不存在的来源无休止地翻遍全网、用过多的状态更新互相干扰）。

三种失控方式各自对应一个很好认的病：

官方还举了一个更具体的分工失效例子，值得完整记住：一个 subagent 去查 2021 年的汽车芯片危机，另外两个却在重复调查 2025 年的供应链。三个人干了两件事，其中两个人干的是同一件事——这就是分工失效的教科书样本。

好比三位装修工进场，包工头只说了一句「把卫生间弄好」：一个人在贴瓷砖，另两个都在换同一根水管。不是他们不努力，是分工描述得不够具体。这也直接给出了工程上的解法：lead agent 派活时必须写清「你负责什么、不负责什么、输出格式是什么」，含糊的任务描述必然导致重复劳动。

同步执行瓶颈：多 Agent 现在最硬的一个限制

还有一个结构性限制值得单独讲：lead agent 是同步等待 subagent 的。

同步等待说白了就是：lead 派完活之后就站在那儿等，等到所有 subagent 都交活才能继续。这带来三个后果：

• 无法中途干预subagent 走错了方向，lead 在它交活之前看不到、也管不了。
• 单个卡住就阻塞全系统四个 subagent 里有一个卡在一个死循环里，另外三个早交完了也没用，整个任务停在那儿。这就是「最慢的那一环决定整体速度」。
• 失败恢复很贵中途出问题往往只能整批重做，因为中间状态难以精确恢复。

相当于一位包工头派了四个人去四个工地，规定「全都干完了一起回来汇报」。其中一个人的水电改造卡住了，另外三个人只能在原地等着，谁也不能先交工。而包工头因为约好了「干完再说」，甚至不知道有人卡住了。

这个限制也解释了为什么本章前面反复强调的那些原则在多 Agent 场景下更加重要：硬性步数上限、超时机制、全程 tracing。单 Agent 卡住你烧一份钱，多 Agent 卡住你同时烧五份。

单 Agent 还是多 Agent：一张决策表

把上面所有的官方限定整理成一张可以直接照着用的表：

如果只能记一条，记这条：多 Agent 的适用条件是「任务能真正拆成互不依赖的几摊」，而不是「任务很难」。难而串行的任务（比如重构一个大型代码库），多请几个 Agent 只会让协调开销吃掉全部收益。

常见误解一次澄清

写给要动手的人：八条实操建议

• 接工具优先走 MCP，不要手写胶水哪怕现在只有一个应用一个数据源。N×M 变 N+M 的收益在第三个数据源出现时就开始显现。
• Tool 与 Resource 分清楚判据是一句话：「这件事做完，世界变了吗？」变了写成 Tool，没变写成 Resource。混着写会让模型不知道哪些操作是危险的。
• 护栏写在 server 代码里数量上限、权限校验、参数白名单——写在 server 里而不是提示词里。提示词能被注入绕过，代码不能。
• 工具的 docstring 当成产品文案来写它就是模型看到的全部说明。写得含糊，模型就用错。这一行文字的重要性不亚于函数体。
• 上生产前先查规范的当前版本这个领域半年一变。本节写的是截至 2026 年 8 月的状况，动手时以官方规范页面为准。
• 先把单 Agent 做扎实再考虑多 Agent上一节讲过，单步 95% 走 20 步只剩 36%。单 Agent 不可靠时，多 Agent 只会把不可靠乘以五。
• 上多 Agent 前先算成本按 15 倍 token 估一遍。如果这个任务的商业价值撑不起，就不要上——这是官方给的判据，不是我的意见。
• 派活的描述必须具体到「不负责什么」否则就会出现「一个查 2021 年芯片危机、两个重复查 2025 年供应链」那种分工失效。写清边界和输出格式。