78%的企业说MCP已上线生产，但真正的生产长什么样——这件事今天被数据说清楚了

78%，这是企业里说 MCP 已经进生产环境的比例。

但如果你问：这些生产环境里，有多少在处理真实的客户流量或金融交易？

答案是：可能不到三分之一。

这个数字出自 CTO 调查和 Stacklok 的专项报告——两者的口径差异，恰好暴露了 MCP 落地最真实的状态。

两个 78%，一个 41%，差在哪？

2026 年 4 月的 CTO 调查显示，78% 的企业 AI 团队（定义为 50 人以上的 AI/ML 团队）已在生产中运行至少一个 MCP 支持的 Agent。这个数字出现在每一份供应商报告里，被反复引用。

但同一次调查里明确注明：这 78% 的大多数，把 MCP 严格用在内部开发者提效场景——读 Jira 工单，写 Confluence 文档、触发 CI 流水线。

真正路由实时客户流量或金融交易的，只有最成熟的约 30%。

Stacklok 的《2026 年 MCP 软件状态报告》用了更严格的生产定义，数字是 41%。

这两个数字的差，不是在挑刺。这说的是同一件事的两个阶段：企业用了，但还没敢把它用到真正重要的地方。

真实生产数据长什么样？

MCP Dev Summit 2026 上，几个顶级企业的工程师透露了他们的实际规模：

• AWS：内部 AI 社区有「数万」名构建者，MCP 是他们连接 Agent 到内部系统的「最常用方式」
• Uber：1,500+ 个内部 Agent，每周执行 60,000+ 次，90% 以上的工程组织每周使用 AI
• Duolingo：一个 AI Slackbot，接了 180+ 个 MCP 工具，服务 30% 的员工（250+ 周活用户），代码已开源

这些不是试点项目，是生产流量。但它们的共同点：都在内部。

安全这把刀已经悬着了

为什么企业迟迟不把 MCP 用到客户流量层？不是不想，是怕。

2026 年上半年，Invariant Labs 命名了一个攻击向量：工具投毒（Tool Poisoning）。

MCP 客户端初始化会话时，会调用 tools/list，服务器返回的工具描述字段直接注入模型的 system prompt。模型没有办法区分「这是工具描述」和「这是操作指令」——两者在同一个上下文窗口里，以相同的信任级别到达。

一份中毒的工具描述，可以指示 Agent 调用受限工具、窃取数据、覆写自己的系统提示约束。

具体数据：

• Endor Labs 扫描了 2,614 个 MCP 实现：82% 使用有路径遍历风险的文件操作 API，67% 使用了可能引发代码注入的 API，34% 使用了可能引发命令注入的 API
• Invariant Labs 发现：5.5% 的公开 MCP 服务器携带中毒的工具元数据
• Snyk 记录了一个具体攻击链：Agent 收到中毒的 tools/list 响应后，被引导调用文件读取工具，并把输出转发到攻击者控制的端点——全程无需用户任何额外操作

34% 的生产实现含有命令注入风险的 API，5.5% 的服务器已经中毒——这不是小众场景下的理论风险。

那 30% 为什么不着急？

一个值得注意的反直觉现象：真正把 MCP 用到客户流量的那 30%，往往也是安全最到位的。他们普遍做了这几件事：

1. MCP Gateway 而不是直连：所有 MCP 流量经过网关，IT 可以审计、限流、阻断
2. Registry 管控：所有 MCP 服务器必须在 Registry 登记，不允许随便接
3. PII 脱敏层：数据流出前自动脱敏，即便 Agent 被引导读到了敏感数据，也无法传出
4. 静态分析前置：工具描述在注入 system prompt 之前，用 LLM 本身做一次「投毒检测」

换句话说：这 30% 的团队，不是用了更安全的 MCP，而是在 MCP 外面包了一层安全管控。

标准在跑，安全在追

好消息是，标准层面已经在响应这个问题。

2026 年 7 月，AIUC-1 agentic 安全标准第三季度更新，把 MCP 和 A2A 协议安全、Agent 身份与访问管理、第三方风险监控列为三大重点领域，新增了 23 项专门针对协议认证、传输安全和运行时隔离的控制项。

MCP 的无状态规范（2026 年 7 月正式版）也把授权收紧到了与 OAuth 2.0 和 OpenID Connect 对齐的水平。

但标准成熟和实际部署之间，有时间差。这个时间差里，企业能做的事只有一件：不要追 78% 这个数字，看它背后到底是 41% 还是 30%。

下一步：如果你已经在用 MCP，先跑一次工具描述扫描——看看你的 Agent 初始化时，system prompt 里到底装了什么。