一、引言
如果你今天作为开发者、IT 管理者或创业公司创始人正在构建 AI 智能体，你很可能经历过这个故事的某个版本：
在一个下午里，你把一个 MCP 服务器接入 Claude、ChatGPT，或者你们内部的智能体系统。
突然之间，这个智能体可以读取内部文档、调用你的 API、创建工单、查询数据库。
每个人都很兴奋......
然后有人说："我们把它指向 staging，甚至 production 吧。"
刹车瞬间踩死。
安全团队想要一次审查。
合规团队想要一条审计链路。
平台团队询问谁将运行所有这些 MCP 服务器。
突然之间，这个优雅的协议开始看起来像一长串风险和运维杂务。
这篇文章讨论的正是那个差距：
为什么 MCP 容易做演示，却难以在生产环境运行
什么是 "MCP Gateway / 控制平面" 模式
像 IBM 的 ContextForge 和 Peta 这样的解决方案如何实现这种模式------并且具有非常不同的权衡
一条从"酷炫演示"走向"可以在安全审查中辩护的生产系统"的实践路线图
目标不是夸大任何单一产品，而是在现实的生产环境背景下思考 MCP------尤其是当你的智能体将触达真实系统和真实数据时。
二、为什么每个人一开始都喜欢 MCP
让我们从吸引力开始。
Model Context Protocol（MCP）是一个开放标准，它允许 AI 应用（MCP 客户端）以一致的方式连接外部系统（MCP 服务器）。这些系统可能是：
内部 REST 或 gRPC API
数据库和数据仓库
知识库和文件系统
DevOps 工具、CRM、工单系统等等
你可以把 MCP 看作一种"AI 工具的 USB"。
构建一个 MCP 服务器一次，任何兼容 MCP 的客户端都可以发现并调用其工具。
你不必为每个模型、智能体或 UI 编写定制的集成代码，而是通过 MCP 暴露标准工具。
不断增长的预构建 MCP 服务器生态意味着，你可以用相对较少的代码拼接出令人惊讶的强大智能体。
对于 AI 智能体开发者而言，这是一个梦想：你获得了一种统一的方式，将工具连接到智能体，并让模型处理编排。
对于 IT 管理者和创业公司领导来说，这看起来是一条通往"真正能做事的 AI"的快速路径，而不仅仅是回答问题。
那么问题出在哪里？
三、在生产环境中真正阻碍 MCP 的因素
一旦你试图超越原型阶段，三类阻碍会反复出现：
安全风险
运维复杂性
有限的控制与治理
这些几乎完全对应安全团队、基础设施团队和业务利益相关者真正关心的内容。
（一）安全风险：密钥、爆炸半径与合规缺口
乍一看，"智能体调用 MCP 工具"似乎是无害的。
在底层，却存在几个严重的安全问题。
① 凭据暴露在 AI 上下文中
在简单的 MCP 设置中，常见情况包括：
API 密钥存放在 .env 文件、本地配置或 MCP 服务器 JSON 中。
密钥被粘贴进示例或文档中以"先跑起来"。
工具调用将授权头、URL 或原始响应回显到日志中，有时甚至进入 LLM 上下文。
这意味着凭据可能最终出现在：
LLM 输入和输出
智能体日志和追踪
共享配置仓库
换句话说：凭据暴露在 AI 上下文中------这正是安全团队不希望看到的。
② 没有用于合规的审计链路
考虑一个智能体调用类似这样的操作：
delete_user_account(user_id=123, force=true)
如果稍后被审计，你是否可以证明：
谁发起了该操作（哪个用户，哪个智能体）？
在什么策略或角色下运行？
是否有人类批准？
它触达的是 production 还是较低环境？
默认情况下，MCP 并不提供统一、不可篡改的审计链路。
你可能拥有分散的证据，存在于 MCP 服务器日志、客户端应用日志和 LLM 聊天记录中。
但你无法轻松向 SOC 2 或 HIPAA 审计员提供一条干净的端到端叙述。
这就是"没有用于合规的审计链路"问题。
③ 手动凭据轮换
在许多团队中，轮换一个密钥的过程如下：
找出每一个使用该密钥的 MCP 服务器或配置。
手动更新环境变量或配置文件。
重新部署或重启服务。
希望没有人在某个被遗忘的仓库中提交过该密钥。
这不是自动化的生命周期管理。
它容易出错、缓慢，而且通常不符合现代标准，例如：
高频轮换
即时解密
避免客户端持有长期密钥
因此，从安全和合规角度来看，原生 MCP 存在三个明显问题：
凭据出现在不该出现的地方
没有权威审计链路
手动且脆弱的密钥轮换机制
（二）运维复杂性：一动物园的小服务器
即使安全问题得到解决，平台和基础设施团队也会提出自己的担忧。
① 手动服务器部署
每新增一个 MCP 服务器，就意味着另一个需要：
打包
部署（Kubernetes、虚拟机、容器、无服务器等）
配置（密钥、网络、可观测性）
而且几乎总是需要多个环境：
开发
预发布
生产
因此，添加一个集成可能意味着多个 MCP 服务器部署、多套配置和多套监控告警。
这就是"手动服务器部署"问题------当你希望拥有几十个工具时，它很难扩展。
② 24/7 空转成本
大多数 MCP 工具是间歇使用的。
然而，如果你将每个 MCP 服务器作为长期运行的服务：
即使空闲，它也消耗计算和内存。
你仍然为可观测性、网络和平台开销付费。
当你拥有大量服务器时，"小实验"就变成了真实的基础设施成本。
很多 MCP 服务器大部分时间什么也不做，却仍然在消耗资源。
这就是"24/7 空转成本"问题。
③ 到处都是自定义 REST 集成
MCP 生态在增长，但现实是：
许多内部服务仍然只是普通 REST 或 gRPC。
许多外部 SaaS 产品并非 MCP 感知。
因此你最终要么为每个 API 编写自定义 MCP 包装器，要么维护一条一次性的非 MCP 集成路径。
这本质上是"每个端点都要自定义 REST 集成"的问题------你在重复实现本应标准化的基础设施。
（三）控制与治理不足：二元权限与缺乏护栏
即使安全和运维问题得到缓解，领导层仍然担心爆炸半径------如果智能体执行了危险操作怎么办？
① 二元权限
在许多设置中，访问是"全有或全无"：
如果客户端可以连接到 MCP 服务器，它通常可以看到所有工具。
如果用户被启用某个集成，他们就拥有该集成提供的全部能力。
但真实世界的策略更细致：
初级工程师的智能体可能只能读取数据。
高级 SRE 可能拥有部署权限，但没有计费权限。
客户支持机器人可能可以发放小额退款，但不能发放大额退款。
没有细粒度、工具级策略，你就只能使用不符合组织风险模型的二元权限。
② 没有审批工作流
某些操作不应完全自动化：
回滚生产部署
轮换 root 凭据
删除大量数据
发起大额金融交易
理想情况下，智能体应该提出操作、提供上下文和理由，然后等待人类批准或拒绝。
但 MCP 本身并未定义审批机制。
如果工具调用被允许，它就会执行。
这就是"没有审批工作流"问题。
③ 没有环境隔离
最后，是边界问题：
开发环境的智能体误触生产工具。
内部工具跨环境或跨团队泄露。
共享 MCP 服务器却没有清晰隔离。
如果没有环境感知的策略和路由，很容易出现配置错误导致真实损害。
这就是"没有环境隔离"问题。
四、MCP Gateway 模式：缺失的一层
为了使 MCP 在生产环境中可行，许多团队正在收敛到类似的架构：MCP Gateway 或 MCP 控制平面。
你可以把它理解为：
一个具备策略感知能力的智能路由层，位于 AI 客户端与 MCP 服务器（或普通 API）之间，自动执行安全、治理和生命周期管理。
不是：
Agent → MCP 服务器 → 系统
而是：
Agent → MCP Gateway → MCP 服务器 / REST / 其他工具
一个好的 MCP Gateway 会直接解决我们前面讨论的三类问题。
（一）规模化的零信任安全
在安全层面，MCP Gateway 允许你围绕工具建立零信任模型。
零密钥暴露
外部 API 密钥不会离开密钥库。
它们不会存储在客户端配置中，不会硬编码在 MCP 服务器中，也不会暴露在 LLM 上下文中。
网关签发服务令牌取代原始 API 密钥。
客户端使用与策略绑定的短期令牌进行身份验证，而不是使用长期共享密钥。
仅在内存中解密。
密钥仅在需要时在内存中解密，用于调用下游系统，然后立即清除。
自动轮换。
你可以在密钥库中轮换密钥，而无需重新部署或重新配置每个客户端。
这将"凭据出现在 AI 上下文 + 手动轮换"的混乱局面转变为集中管理、可审计的流程。
（二）细粒度权限控制
在零信任之上，网关允许你定义细粒度、工具级权限。
按用户 / 按智能体的策略
人类用户可以做的事情可能与自治智能体不同。
按工具 / 按操作的控制
例如：read_reports 广泛允许；delete_user 仅允许在 staging 或在审批之后。
环境隔离
为开发、预发布和生产完全分离策略、凭据，有时甚至是独立网关实例。
上下文感知规则
决策可以考虑时间、位置和数据敏感性，例如："在非办公时间禁止来自不可信 IP 的生产删除操作。"
通过这些能力，你从二元开关权限转向符合实际风险承受能力的权限模型。
（三）快速扩展与成本控制
在运维层面，网关可以处理 MCP 服务器的自动生命周期管理。
按需服务器池
MCP 服务器仅在需要时启动，空闲时关闭，从而减少 24/7 空转成本。
几分钟内转换任意 API
网关可以将 REST 或 gRPC 服务包装为"虚拟 MCP 服务器"，无需为每个服务手写包装器。
即时扩展新工具
新 API 可以在网关中注册，并立即进入 MCP 生态，而无需大规模重新部署。
采用这种模式的团队通常可以显著降低成本。
与"所有 MCP 服务器永久运行"相比，追求 70% 的基础设施成本下降并不罕见。
（四）完整的可观测性
一个好的 MCP Gateway 提供端到端可视性。
每个 MCP 调用都会记录谁、什么、何时、何地以及结果。
日志具备防篡改能力，并可导出到 SIEM 系统，以满足 SOC 2、HIPAA 等要求。
可以按团队或项目进行成本分摊。
可以针对异常模式发出警报，例如流量激增、异常工具调用或异常访问时间。
现在，你拥有一个集中位置，安全、合规和运维团队可以查看智能体真正做了什么。
这就是 MCP Gateway 模式的概念基础。
不同项目以不同侧重点实现这一模式。
下面看两个具体例子：IBM 的 ContextForge 和 Peta。
五、ContextForge：强大、企业级、但复杂
IBM 的 ContextForge MCP Gateway 是一个开源项目，旨在成为功能丰富的网关、代理和注册中心。
从高层看，它为希望将 MCP 作为基础设施一部分来管理的组织设计。
它能做什么
ContextForge 位于：
原生 MCP 服务器
REST 和 gRPC API
智能体到智能体（A2A）服务
之前，并通过统一网关向 AI 客户端暴露。
关键能力包括：
多种传输协议
支持 stdio、HTTP/JSON-RPC、WebSocket、流式 HTTP 等。
虚拟 MCP 服务器
可将非 MCP 服务包装为虚拟 MCP 服务器，通常从 OpenAPI 等定义推导 schema。
注册与发现
作为中央工具注册中心，支持跨网关和集群的发现与联邦。
管理界面与可观测性
提供管理 UI，并与 OpenTelemetry 等工具集成。
它将 MCP Gateway 模式实现为一个通用、协议感知的网关和注册系统。
权衡：能力与复杂性
强大也意味着复杂。
它引入：
大量配置面（认证、联邦、传输、路由规则等）
多组件架构
类似运行另一个大型 API 网关的运维复杂度
如果你已经拥有成熟平台团队和 Kubernetes 基础设施，它非常合适。
对于小团队或早期创业公司，它可能显得沉重。
六、Peta：零信任 MCP 控制平面与人工审批
与 ContextForge 的通用网关思路不同，Peta 更加聚焦。
它关注：
零信任安全
细粒度环境策略
人工审批
高效运行 MCP 服务器
它包含三个组件：
Peta Core --- 零信任网关与运行时
Peta Console --- 控制平面与策略引擎
Peta Desk --- 审批客户端
Peta Core
Peta Core：
终止 MCP 客户端连接
验证身份与策略
注入凭据并路由调用
按需编排 MCP 服务器生命周期
特点包括：
服务令牌替代原始密钥
密钥存储在加密 vault 中
仅在内存中短暂解密
按需启动 MCP 运行时
这直接解决安全与运维复杂性问题。
Peta Console
Peta Console 允许：
建模环境
定义 RBAC / ABAC 策略
管理服务令牌
监控使用与异常
它成为 MCP 治理的"单一控制面板"。
Peta Desk
当智能体提出高风险操作时：
请求到达 Core
被判定需要审批
发送到 Desk
人类查看上下文
批准、修改或拒绝
全过程记录
这种人类参与模型允许智能体拥有强大能力，同时保持最终控制权。
安全与合规姿态
Peta 架构对齐：
零信任安全
合规级审计日志
环境隔离
它试图回答："生产级 MCP 安全是什么样？"
权衡
Peta 是较年轻项目。
生态较小。
但专注于 MCP 生产治理问题。
它减少拼装通用组件的需求。
更快达到价值。
七、如何选择：ContextForge、Peta 或自建
如果你是开发者：
想停止硬编码密钥？
想要工具注册中心？
想避免自己实现审批和日志？
ContextForge 提供强大灵活性。
Peta 提供更聚焦的治理能力。
如果你是 IT / 安全负责人：
关注密钥暴露？
关注审计？
关注环境隔离？
网关是必需层。
如果你是创业公司创始人：
关注速度与风险。
选择集中密钥与日志的方案。
逐步引入审批机制。
八、从演示到生产的路线图
阶段 1：盘点与风险评估
列出所有 MCP 工具。
识别数据类型与环境。
识别密钥存储位置。
阶段 2：将敏感工具置于网关之后
集中密钥。
签发短期令牌。
阶段 3：添加细粒度策略与环境隔离
区分 dev / staging / prod。
限制破坏性操作。
阶段 4：引入人工审批
为高风险操作配置审批。
阶段 5：优化成本
采用按需运行。
阶段 6：在治理下扩展 MCP
九、结语
MCP 提供强大抽象：
以标准方式将智能体连接到工具。
但 MCP 本身不解决：
密钥管理
合规审计
成本生命周期管理
人工控制
这正是组织卡在"原型"与"生产"之间的原因。
MCP Gateway / 控制平面模式：
集中密钥
统一访问控制
增加策略与审批
智能管理生命周期
ContextForge 提供强大企业级实现。
Peta 提供聚焦零信任与审批的实现。
关键结论：
不要只根据演示难易度评估 MCP。
要评估 MCP 加上治理层之后的整体能力。
当你这样做时，
智能体获得受控生产访问不再是风险，
而是可扩展能力。
参考资料
Anthropic --- Model Context Protocol 概览
https://www.anthropic.com
Anthropic --- MCP GitHub 组织与示例服务器
https://github.com/modelcontextprotocol
IBM --- ContextForge MCP Gateway
https://github.com/IBM/context-forge
Peta --- 零信任 MCP 控制平面
https://peta.io
一旦做到这一点，让智能体获得真实、受治理的生产访问就不再是你试图为其辩护的风险------而是你可以自信扩展的能力