配了三个月 AI 编程工具，今天才发现 MCP 的账被算错了——78% 上线率背后，40% 连 token 都没算过

配了三个月 MCP 工具，今天看到两组数据打架：一组说 78% 企业已在生产环境跑 MCP，另一组说实际生产渗透率只有 41%。哪个是真的？都是真的——区别在于怎么定义「生产」。

78% 从哪来的

这个数字来自 2026 年 4 月的 CTO 调查，样本是企业内部已有 AI 团队的 50 人以上公司。在这些公司里，78% 报告至少有一个 MCP 驱动的 Agent 在跑。但同一个调查里，当研究员追问「跑在哪一层」时，答案开始分层：只有 30% 的 MCP 部署真正处理了客户数据或金融交易；大多数跑在内部效率场景——Jira 读票、Confluence 写文档、CI 流水线触发。

Stacklok 的《State of MCP in Software 2026》用了更严格的定义——什么叫「在生产」？不只是跑起来，而是有监控、有告警、有回滚机制、可对结果负责。按这个标准，渗透率是 41%。

差距不只是数字

表面看 78% vs 41% 只是统计口径差异，实际反映的是企业部署 MCP 时真实踩到的几个坑。

第一个是上下文膨胀。当 MCP server 返回的数据量一大——比如一次查完整个数据库结果——内容直接灌进模型的激活上下文。乘以多轮 ReAct 循环，token 预算分分钟爆掉。有人在生产环境里测出 72% 的上下文被元数据消耗，实际有用的任务数据不到三成。解法是在 MCP server 层做 aggressive chunking，不是让裸数据直接流进 context window。

第二个是工具调用循环。模型没有明确的终止判断时，会在几个工具之间来回调用，参数略有不同，看起来像在推进任务，实际上在空转。真实金融数据管道里，这个现象最明显——实时数据 feed 触发连续重查，看起来有目的性，实际上没有输出。解法是做 eval-driven 开发，给每个工具调用设置 step limit 和循环检测。

第三个是安全。2025 年就有人发现了工具投毒（tool poisoning）攻击向量：MCP server 返回的 tools/list 里藏着描述字段，模型没有办法区分「工具描述」和「操作指令」，两者在同一上下文里以相同信任级别到达。到 2026 年初，已公开的 MCP 相关 CVE 超过 14 个，分布在主流 AI 工具的生产环境里，不是沙盒，是真的线上事故。

上线 vs 跑好是两件事

所以 78% 的 MCP 上线率不是假的，但它更接近「实验性部署」的统计，不是「大规模生产运行」的统计。企业用了 MCP，但大多数只是把它跑起来，还没有把它跑稳。

这个阶段像极了你第一次把 React 跑起来——create-react-app 成功了，Hello World 出来了，但离生产级的性能监控、错误边界、SEO 优化还差十万八千里。区别在于，Hello World 跑崩了只是页面 500，MCP 跑崩了可能是一次生产级别的数据泄露。

下一步是什么

如果你在评估要不要在生产环境里跑 MCP，或者是已经在跑但遇到了 token 爆炸、循环调用或者安全问题，给三个具体的检查点：

第一，上线前做 server trust audit——不是审计代码，是审计每个 MCP server 的认证机制和传输层加密，标准参照你不信任的第三方 API。

第二，从第一个工具开始就要做 token 预算和循环守卫，不要等产品大了再补。

第三，MCP 适合接「有明确边界、内部使用、调用频率可预期」的工具；不适合接「返回数据量大、实时性要求高、需要复杂事务控制」的场景。选对场景比选对工具更重要。