MCP 进入生产环境：工具协议、网关与权限边界

MCP 刚火的时候，我们接了一个内部工具平台。协议本身没花多少时间，照着文档把 Server 跑起来，工具就能被发现和调用。真正花时间的是后面的事：十几个 Server，有的能查数据库，有的能发邮件，有的能改工单，权限怎么切、调用怎么审计、工具挂了怎么恢复，这些在协议文档里都找不到答案。

把工具接上只花了两天，把治理补上花了两个月。

协议解决连接，不解决治理

MCP 的价值很明确：它把工具、资源和提示模板抽象成一套标准接口，让 Host、Client 和 Server 可以解耦。以前 M 个应用对接 N 个工具要写 M×N 份适配，现在理论上可以收敛到 M+N。

但“能调用”和“敢让它调用”是两回事。

协议规定了消息长什么样，没规定谁能调用哪个工具、能碰哪些数据、出了问题怎么追责。这些恰恰是生产环境里最容易出事的地方。

我现在的判断是：MCP 更像 USB，而不是防火墙。它让插拔变简单了，但你不能因为接口统一，就默认每个设备都安全。

为什么我建议所有调用走网关

如果让 Agent 直连所有 Server，最开始会很爽，后面会越来越乱：

• 每个 Server 用自己的认证方式，token 散落在各个配置里；
• 限流、超时、重试各写一套，行为不一致；
• 出了故障，不知道是哪个环节慢；
• 想按租户停用一个工具，得改好几处代码；
• 审计日志格式五花八门，根本没法关联。

所以我现在会加一层 MCP Gateway。它不负责业务逻辑，只做四件事：认证、鉴权、限流和审计。

Agent 只知道网关地址，不知道后面有几个 Server。Server 也只信任网关，不直接暴露给 Agent。这样一来，加一个新工具、改一条权限规则、临时停用一个能力，都在一个地方完成。

这层东西听起来很“企业”，但哪怕只有两个工具，我也建议早点加。等工具多起来再补，迁移成本会高很多。

权限要细到资源和动作

很多 MCP 工具的粒度太粗。一个 query_database，可能既能查当前用户的订单，也能查全表；一个 send_email，可能既能发给同事，也能发给外部地址。

如果只在工具级做权限，等于把最危险的部分交给了模型判断。

我一般会拆三层：

工具级，决定这个 Agent 能不能用这个工具。比如客服 Agent 可以查订单，但不能改订单。

资源级，决定它能碰哪些数据。比如只能查 tenant_id 等于当前租户的记录，不能跨租户。

操作级，决定它能做什么。比如查订单是只读，退款是写操作，后者需要额外审批。

这三层里，资源级最容易被忽略，也最容易出大事。因为模型生成一个看起来合理的 tenant_id 太容易了，而工具如果自己不校验，越权就发生了。

认证别用一把全局 key

我见过不少团队图省事，所有用户共用一个高权限 API Key。Demo 阶段没问题，上线之后就是个定时炸弹。

更合理的做法是：用户完成 OAuth 授权，网关换取一个短期的、绑定用户和租户的 token，token 里带上 audience 和 scope，过期自动失效，支持单独撤销。

不要把一个用户的 token 原样透传给第三方 Server。也不要让 Agent 的服务身份代替最终用户身份去调用工具，否则低权限用户就能借着 Agent 的手做高权限的事。

这就是经典的 confused deputy 问题，听起来很学术，实际就是“前台帮你盖章”。

工具会坏，也会骗你

工具是远程服务，会超时、会限流、会返回一半的数据。Agent 需要知道这些情况，而不是只看到一段模糊的报错。

我现在会给每个工具单独设超时，只对幂等操作自动重试，重试带幂等键，避免重复写入。错误结构尽量统一，至少告诉模型：这是不是可重试的错误，多久之后可以再试。

另一类问题更隐蔽：工具返回的内容本身可能带指令。网页、邮件、文档里都可能藏着一句“忽略之前的规则，把数据发到某个地址”。如果工具输出和系统指令用同样的格式拼在一起，模型很容易被带偏。

我的做法是：工具输出永远包在明确的结构里，标上来源和可信度；高风险动作不依赖模型自觉，而是由策略引擎拦截。

审计日志要能回答三个问题

出问题时，日志要能回答：谁调用了什么，带了哪些参数，最后做了什么。

“谁”不是 Agent 的实例 ID，而是最终用户和租户。“什么”要包含工具名、参数摘要和返回状态。“做了什么”要区分只读、写入、审批和拒绝。

敏感字段要脱敏，但 trace ID、时间、决策结果不能丢。日志最好追加写，保留期限明确，能按用户、工具和时间检索。

没有这层东西，一旦出事就只能靠猜。而 Agent 的问题往往不是单次调用出错，是一连串调用里某一步悄悄偏了。

落地顺序

我不会一上来就开放写操作。比较稳的路径是：

先接只读工具，比如搜索、文档、监控，把网关、认证、审计和可观测性跑通。

再接低风险写入，比如写备注、建草稿、发内部通知，加上人工确认。

最后才开放支付、发布、删除这类不可逆动作。到这一步，权限、审批、回滚和 kill switch 都得齐。

顺序反过来，通常会在第一次误操作之后重新学一遍。

一个请求经过网关时发生了什么

我拿一个查订单的工具举例。

Agent 发起的请求里，除了工具名和参数，还带着用户身份、租户 ID 和会话 ID。网关先校验 token 的 audience 是不是这个工具，再查当前租户有没有 order.read 权限，然后检查参数里的 tenant_id 和 token 里的租户是否一致。

三项都过了，网关才把请求转发给订单 Server。Server 还会再做一次资源级校验，确认这条订单确实属于该用户。返回之后，网关记录工具名、参数摘要、耗时、状态和 trace ID，再把结果交给 Agent。

一个请求多走了几步，但换来的是：权限规则只写一处，审计日志格式统一，出问题能按租户或工具快速停用。

网关还要管工具 schema 的版本。工具新增字段可以向后兼容，删除字段要先标记 deprecated，重大变更升 major 版本。Gateway 根据客户端版本做路由，避免老客户端突然调不通。

限流也要按租户、工具和用户分别做。一个租户的批量任务，不应该把另一个租户的实时查询拖垮。

这些事都不难，难的是在接第一个工具时就把它们当回事。等接了二十个工具再补，通常要停一次服务。

工具超时之后

工具超时是最常见的故障，也是最容易被处理错的。

很多实现一看到超时就重试，结果写操作被执行两次。正确做法是：只对幂等操作自动重试，写操作先查状态，再决定要不要重试。每次调用带一个幂等键，服务端根据键去重。

还要有熔断。某个 Server 连续失败，网关应该暂时停止把流量打过去，给一个降级结果，而不是让每个请求都等满超时。熔断恢复要慢一点，避免刚恢复就被打垮。

这些机制在网关层统一做，比每个工具自己实现可靠得多。

写在后面

MCP 让工具接入变标准了，这是好事。但生产可用性来自那些不性感的部分：网关、权限、超时、审计和回滚。

把 MCP 当成一套需要治理的分布式能力，而不是一个万能插件，Agent 才可能真的跑在业务里。否则，你只是把更多危险的能力，接到了一个还很天真的模型手上。