Perplexity 正在离开 MCP——而且他们没错

MCP——Model Context Protocol——赢了。大约一年时间，它就从 Anthropic 的一个副项目，变成了每个框架把工具接入 agent 的默认方式：到 2026 年 3 月，每月 SDK 下载量超过 9700 万次，公开 MCP server 超过 10,000 个。 它赢得太快，以至于整个行业跳过了一个问题：它在生产环境里到底好不好用？

Perplexity 刚刚给出了回答。在他们的 Ask 2026 活动上，CTO Denis Yarats 说他们内部正在弃用 MCP——理由是上下文膨胀和别扭的鉴权。当一家靠 agent 质量生死存亡的公司，悄悄从赢家标准那里走开时，值得搞清楚为什么。

这笔账用上下文来付

这是「什么都插上」的演示会跳过的部分。你挂上的每一个 MCP 工具都会带着它的描述——名字、参数、用法说明——而这段文字会在 agent 还没做任何事之前 就坐进模型的上下文窗口里。挂上几个 server，没事。接上一套真正的工具箱，那么按照一些 2026 年的分析，工具的元数据可以吃掉 40–50% 的可用上下文窗口，还没等到第一个有用的 token。

你「随手插上」的每一个工具，都是你为上下文窗口付的租金，每一轮都要付，不管 agent 用不用它。

而且这不只是成本问题。一个被工具定义塞满一半的窗口，就是一个留给真正任务的空间更少的窗口——对话、检索到的事实、计划。这跟那个让长周期 agent 崩溃的 context rot 是同一个问题，只不过这次是你故意在启动时、在工作开始之前就把它引进来的。

反派不是 MCP——反派是「自助餐」思维

我不是反对 MCP。一个共享的工具协议真的很好；问题在于 10,000 个 server 却没有真正的注册表和信任层 的野蛮生长，也在于那种「把每一个你可能用得上的 server 都拴上」的条件反射。MCP 让添加工具毫无摩擦——而毫无摩擦正是你最终用半个窗口去付租金的那条路。

解决办法，是像对待任何一个严肃代码库里的依赖那样对待工具：

• 要精选，不要堆积。 窗口里的每一个工具要么配得上它的位置，要么滚蛋。一套 agent 真正在用的精简工具集，胜过一套它 也许 会用的自助餐。
• 按需加载。 一个预订任务，agent 并不需要全部 50 个工具定义。把工具集按任务来限定范围——动态地——而不是一开始就把所有东西全塞进去。
• 给窗口做预算。 在任务开始之前，就要知道你的工具吃掉了多少比例的上下文。如果接近一半，你已经输了。
• 信任也是一个依赖问题。 一个工具描述，就是你的 agent 会读到的、受攻击者影响的文本。一万个未经审核的 server 是一条供应链，不是一个库。

结论

Perplexity 离开 MCP，不等于「MCP 死了」。这是第一个大玩家说出了那句没人明说的话：一个让添加工具变得 免费 的协议，会让添加工具变得 太容易，而代价会落在你最付不起的那个地方——上下文窗口。

把工具当成依赖，而不是自助餐。精选它们，按需加载它们，并在 agent 开工之前就给窗口做好预算。