一个 MCP Server 挂 100 个工具之后，Agent 反而更不会干活了

8 月 22 日，MCP（Model Context Protocol，模型上下文协议）官方博客发布了更新后的路线图，署名是两位首席维护者 David Soria Parra 和 Den Delimarsky。路线图列了五个优先方向：长任务的消息原语、HTTP 原生传输统一、Agent 身份与企业安全、基础原语改进、SDK 开发体验。

MCP 新路线图的五个优先方向（图源：MCP 官方博客）

对开发者来说，这份文档里最有价值的东西，我觉得不是那五个方向的清单。是一句坦白得少见的话。原文大意是：连接一个挂着一百个工具的 server，意味着模型在用户还没提出任何问题之前，就要为整张工具表面付出上下文成本，而且随着列表变长，工具选择的质量还会下降。

这句话出自协议官方，不是社区吐槽。等于 MCP 自己承认了：工具接得多，不等于 Agent 能力强，挂过头了甚至是负资产。

为什么团队总想把所有系统接进同一个 Server

这个冲动很好理解。

一个公司做内部 Agent，接了 Jira、Confluence、数据库、监控系统、日志平台、客服工单。每接一个系统就要处理一次鉴权、一次部署、一份文档。最快的方法当然是把它们全部塞进同一个 MCP Server：一次部署、一个入口、一份配置，运维上确实省事。

过去两年 MCP 生态也一直在鼓励这种思路。各种「把 XXX 接入 MCP」的项目层出不穷，数字上看，server 支持的工具数量成了某种能力指标，好像谁挂的工具多，谁的 Agent 就更全能。

但从模型那一侧看，事情完全是另一回事。

MCP Server 暴露工具的方式，本质上是把每个工具的名称、描述、参数 schema 一次性摊开给模型。客户端连接 server 时，这份工具清单就进了上下文。也就是说，用户还没开口，模型已经背着几百个工具的说明书在干活了。这些 token 既占上下文窗口，也占成本，而且大多数工具对当前任务是无关的。

这就像给新员工入职第一天就发一套全公司的操作手册，两千页，所有部门所有岗位的内容都在里面，然后让他回答任何问题前先把手册过一遍。手册越厚，他找到正确章节的概率反而越低。

工具目录膨胀的三笔账

把这笔账算细一点，全量暴露工具目录的代价至少有三层。

第一笔最好算，是上下文。工具定义本身要占 token，一百个工具的 schema 和描述，足以挤占本来留给用户问题和中间结果的空间。长对话里这个矛盾更明显：上下文越紧张，真正有用的信息被稀释得越厉害。

第二笔是选择质量，官方点名承认的就是它：工具越多，选择越差。原因不复杂，工具多了以后，名称和描述会互相干扰。一个数据库 server 同时挂着「查询订单」「查询订单详情」「按用户查订单」「搜索订单」四个工具，模型在四个近似选项里挑一个的出错率，远高于在两个明确选项里挑。工具之间的边界越模糊，模型越容易选错，或者干脆自己编参数去凑一个不合适的工具。

第三笔账最容易被漏掉：权限面。挂一百个工具，等于把一百个可被调用的能力暴露给模型，也就暴露给任何能影响模型输入的东西。提示词注入攻击的核心从来不是「模型被骗」，而是「被骗的模型手里恰好握着危险工具」。Reddit 上有个帖子流传很广，发帖者描述自己的 Claude sub-agent 被注入指令后，差点诱导主会话删掉数据库；还有用户让 Claude 管理一个月的资金流水。这些都是个人自述，不能当成产品事实，但它们指向同一个问题：工具面越大，单次失误和单次注入的破坏半径就越大。

三笔账叠在一起，会得出一个和直觉相反的结论：工具目录的价值不随数量线性增长。过了某个点，每多挂一个工具，都在让其余所有工具变得更不可靠。

全量暴露工具目录的三笔账：上下文成本、选择质量与权限面

渐进式发现：先给小入口，再随任务展开

路线图给出的方向叫 progressive discovery（渐进式发现）。官方的表述是：server 可以先提供一个小的入口，随着对话逐渐收窄，再逐步暴露更多工具目录。

先把边界说清楚：这是一个「正在启动的工作」，不是已经发布的能力。路线图是规划文档，渐进式发现还没有进入 MCP 规范，目前能用的还是 2026-07-28 版本里的既有机制。把它写成「MCP 已支持工具渐进式暴露」是不准确的。

同样要说清楚的是，渐进式发现不是把工具列表做个折叠菜单。界面上收起来很容易，难的是让模型的上下文、选择质量和权限面同时收窄。想象一个挂了八十个工具的企业 server，如果默认只暴露五个：查工单、查文档、查数据库 schema、建任务、搜索日志，剩下七十五个按领域分组，模型在对话中确认了任务范围之后再逐层展开，会发生三件事：初始上下文变小；候选工具之间的干扰减少；server 也有机会在展开某一层工具时，顺带要求对应层级的授权。

这里面真正值得琢磨的一点是：工具暴露的时机，本身就是一种权限控制。默认可见，就是默认可调用；按需展开，才有按需授权。这两件事在协议层面被绑在了一起。

渐进式工具发现：默认只暴露个位数入口工具，随任务收窄逐层展开、逐层授权

长任务不能再靠一来一回

路线图的另一个优先方向，是消息原语。

MCP 最初的交互模型是请求与响应：客户端发请求，server 返回结果，一来一回，干净利落。但 Agent 的工作方式早就不符合这个模式了。一个任务可能跑二十分钟，server 需要推送中间结果，用户可能想在任务进行到一半时改需求。

官方为此在做几件事：Tasks 扩展（目前还是实验性的 SEP-2663 提案，目标是成熟后进入规范）、订阅与进度通知机制，以及 server 主动发起的事件，让客户端不必轮询结果。roadmap 里特别提到要审查这些原语之间的组合是否顺畅，因为单独看每个机制都能用，拼在一起跑长任务时才暴露问题。

这一条落到实际，是长任务必须有「中途可干预」的通道。任务跑到第十二分钟发现方向错了，是等它跑完再人工回滚，还是能在中途 steer（转向）？前者把纠错成本交给事后，后者才配得上「Agent 在干活」这个说法。今天很多团队的答案是前者，因为协议层面的原语凑不齐。

Agent 身份的重点不是发工牌，是委托链

第三个值得展开的方向是 Agent 身份。

MCP 现在的授权模型建立在「一个人在浏览器里点确认」之上。这对交互式客户端没问题，但现实里越来越多的调用方是跑在云上的 Agent：它有自己的身份，代表一个不在场的用户行动，还可能把更窄的权限再委托给子 Agent。粘贴 API key 和长期 token 的做法，撑不住这种结构。

路线图在这块的工作包括：定稿并推广 DPoP（Demonstrating Proof of Possession，持有证明，RFC 9449），通过 Workload Identity Federation（工作负载身份联合）、Enterprise-Managed Authorization 背后的 ID-JAG 授权、标准 token exchange（令牌交换）来定义 Agent 身份与委托的路径，并继续参与 IETF OAuth 和 WIMSE 工作组。

技术名词很密，但翻译成人话就一句：server 要能识别「这个请求是哪个 Agent 代表哪个用户、拿着多窄的权限发起的」，并且能沿着这条委托链往回收权。

真正要紧的是委托链可识别、可收窄，发工牌反倒是其次。发工牌是一次性动作，识别委托链是持续验证：A 用户委托给 Agent B，B 又把查询权限委托给子 Agent C，server 在每一跳都能看到凭证的范围，任何一跳出问题都能单独切断。这对企业安全团队的意义，比「Agent 有了自己的身份」大得多。

现在动手搭内部 MCP Server 的团队该做什么

规范里的渐进式发现和委托身份都还没落地，但这不意味着只能干等。入口设计的思路现在就能用。

把 server 的工具分成两层：一层是默认暴露的最小集，覆盖最高频的任务入口，控制在个位数；另一层是按领域分组的完整目录，通过明确的工具调用或对话确认来展开。如果现有 MCP 实现不支持动态目录，可以在 server 外面再包一层网关，用配置控制每个客户端连接时实际可见的工具集。做法土一点没关系，关键是让「可见性」变成一个显式决定的变量，而不是 server 有什么模型就全看到什么。

授权侧，现在就避免一把长期 token 通吃的做法。每个 Agent 用独立的、可撤销的凭证，server 端记录每次委托的发起方和范围。等 DPoP 和 Workload Identity Federation 的路径定下来，迁移的成本会低很多。

长任务侧，从今天起就给每个任务设计停止条件：什么情况下自动终止，什么情况下需要人工确认，任务进行中的状态怎么暴露给上层。这些即便不依赖协议原语，也可以在应用层先实现。

最后是审计。工具调用日志、委托链、每个工具的暴露级别，这三样东西从第一天就该记录。渐进式发现把「暴露」变成了动态行为，动态行为没有审计，出问题时就无从追溯。

入口、过程、身份：这三个概念是什么关系

这篇路线图里的三件事，各自回答 Agent 系统里一个不同的问题。

渐进式发现管的是入口：模型在任何一个时刻能看到什么、能调用什么。入口设计决定了上下文成本和选择质量的下限，也决定了默认权限面的大小。事件原语管的是过程：任务开始之后，结果怎么流回来，人怎么在中途干预。它决定了一个长任务是可控的执行，还是发射之后只能等结果的盲飞。委托身份管的是责任：每一个动作是谁发起、以什么权限、代表谁。它决定了出问题之后，这条链上每一跳能不能被识别和切断。

过去谈 MCP，谈的都是「连接」：怎么把系统接进来。这份路线图实际上把 MCP 从连接协议往运行时治理推了一步。连接回答的是「能力有没有」，治理回答的是能力以什么代价、什么边界、什么责任结构被使用。前者决定 Agent 能不能干活，后者决定它在企业里能不能被长期放心地用下去。这份路线图补的，正是后一半。

对大多数团队，追规范进度没什么好追的，短期内更实际的动作是回头看看自己的 server 入口：如果今天把默认工具集砍到五个，Agent 的表现是变差了，还是反而变好了？这个实验的成本很低，答案可能比预想的更倾向后者。

参考来源

以上官方来源用于确认路线图的优先方向与表述口径；渐进式发现、Tasks 扩展、Agent 身份委托均属规划中的工作，不应视为已正式可用的能力。两条 Reddit 帖子为用户自述，仅作为高权限 Agent 权限边界问题的社区背景，不构成产品事实或漏洞证据。