MCP 上生产：鉴权、限流与可观测性怎么落地
数据截至 2026-07，规范与各项目能力以官方文档当前版本为准。
把 MCP server 从本地 demo 推到生产环境，最难的从来不是把工具函数写对，而是鉴权、限流、可观测性这三块传统后端功课——而 2026-07-28 发布的新规范恰好把其中最影响部署架构的一条改掉了：协议层不再要求会话追踪，粘性会话、共享 session 存储、网关深度包检测这一整套绕路，现在可以拆掉了。
常见的误解是把 MCP 当成”给大模型开个函数接口”，觉得部署上跟写一个普通 REST 服务没区别，鉴权套个 API Key、限流按 IP 拍个数就完事。这个类比在本地跑 stdio 传输的时候勉强成立，但一旦是远程 server、面向不特定客户端、还要接进别人家的 agent 栈，问题就完全不是一个量级了：调用方是模型驱动的，请求量的形状不可预测；一次任务可能连续打十几个工具调用；出了问题你要能回答”是哪个用户的哪个 agent 在哪一步调了什么、拿到了什么”。这篇按真实上线顺序，把三块分别过一遍。
一、先看清 2026-07-28 这版改了什么
官方博客把这次修订称为自协议发布以来最大的一次修订，兑现了 2026 路线图，此前已经先发过 release candidate。内容涵盖六块：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固、正式的弃用策略。
对部署影响最直接的是前两块和授权加固。无状态化由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同实现，完成了 “The Future of MCP Transports” 里定下的计划：协议层不再要求会话追踪，远程 server 可以直接跑在普通轮询负载均衡后面，按 Mcp-Method 头做路由。Tasks（长时间运行操作）已经从核心协议移到 extension，用户也可以自建 extension 与官方认可的并存。至于 MCP Apps，官方博客没有展开细节，这里不替它编内容，具体以官方规范文档当前版本为准。
需要先校准一个时间感：MCP 是 2024-11 发布的，到 2026-07 大约一年八个月；2025-12 捐给 Linux 基金会下的 Agentic AI Foundation，到现在大约七个月。它不是一个跑了很多年的老协议，架构层面的大改动在这个阶段发生并不奇怪，做技术选型时把这个节奏考虑进去。
关于生态规模，按官方与行业公开资料的口径，公开 MCP server 在生产中超过 10,000 个，SDK 月下载量超过 9,700 万。这类汇总数字用来判断”值不值得投入”够了，不要当成精确统计写进技术方案。
二、鉴权：把授权加固落到具体动作上
这次授权规范同样由 6 个 SEP 加固，方向是让它更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署，而不是停留在协议自己发明一套。其中被点名的一条是：要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。
这条看着小，实际是在堵一类真实存在的攻击面。授权响应里如果不校验签发方标识，客户端就无法确认这个授权码到底来自哪个授权服务器——在一个客户端可能同时对接多个 MCP server、每个 server 又指向不同授权服务器的场景里，混淆的后果是拿着 A 家的凭据去 B 家换令牌。落到工程上，你要做的事很具体：
- 客户端侧：走授权码流程时，把响应里的签发方标识与你发起请求时记录的授权服务器做严格比对，不一致直接失败，不要”宽容处理”。用现成的 OAuth 客户端库时确认这项校验是默认开启还是需要显式打开。
- server 侧：把自己当成一个标准的 OAuth 受保护资源来部署，而不是自己撸一套 token 校验。令牌的签发方、受众、有效期、作用域这几项逐项验，尤其是受众——只接受明确签发给本 server 的令牌，别接受”任何本组织签发的有效令牌”。
- 凭据存储：远程 server 拿到的下游凭据（比如它要代表用户去访问数据库或第三方 API 的那把钥匙）不要跟 MCP 会话绑在内存里。协议层已经不要求会话追踪了，你如果还把凭据挂在会话对象上，等于自己给自己重新造了一个有状态依赖。
- 最小权限：一个 MCP server 暴露的工具往往读写混杂，尽量按作用域拆开，让只需要查询的调用方拿不到写权限的令牌。这一步在 demo 阶段省掉最省事，出事时最贵。
授权这块单独展开的内容不少，站内另有一篇专门讲加固细节，可以对照看：MCP 授权加固。
三、限流：无状态之后，限流键要重新挑
以前远程 MCP server 常见的做法是靠会话做限流：一个会话建立起来，后续请求都落在同一个实例上，计数器放本地内存就够用了。协议层不再要求会话追踪之后，这条路径的前提没了——请求会被普通负载均衡撒到任意实例上，本地计数器各算各的，等于限流形同虚设。
替代方案要重新想清楚三个问题。
第一，用什么做限流键。 备选一般是这几个：调用方身份（令牌里的 subject 或 client id）、组织/租户、来源 IP、以及具体工具名。经验上单用 IP 最不靠谱，因为 agent 往往跑在云上，一堆用户共享出口 IP；比较稳妥是以身份为主键、按工具名再分一层——同一个用户查一次目录和跑一次全表扫描，配额显然不该同价。
第二，计数器放哪。 无状态之后计数状态必须外置，通常是集中式缓存。这里要接受一个现实：分布式限流做到完全精确代价很高，多数场景用近似算法（漏桶、滑动窗口计数）就够了，允许边界上有少量超发，换取延迟可控。别为了限流精确度把每个请求都变成一次强一致写。
第三，超限之后返回什么。 不要只丢一个错误码了事。调用方是模型驱动的客户端，它需要能判断”该等多久再试”，所以响应里给出明确的重试等待时间，并且在错误文本里写清楚是哪一类配额被打满了。否则 agent 大概率会立刻重试，把你从限流打成雪崩。
还有一个容易漏的点：限流要区分”单次工具调用”和”一次任务”。Tasks 已经移到 extension，长时间运行的操作可能一次提交、多次轮询状态。如果你的限流只数请求数，轮询会把配额吃光；比较合理是把轮询类请求单独归一类，给更宽松的配额，或者干脆按任务数计费和限流。部署形态相关的更多讨论见 MCP 部署与负载均衡。
四、可观测性：无状态让链路更好拼，也更容易漏
无状态是把双刃剑。好处是每个请求自包含，落到哪个实例都一样，日志不再需要跨实例拼会话；坏处是你失去了那个天然的关联键——以前一个 session id 就能把一串调用串起来，现在得自己造。
上线前建议至少把这几件事做掉：
- 每个请求打一个关联 ID。客户端传入的就沿用，没有就在入口生成，并且在响应里回带。日志、指标、追踪三处都带上它，事后复盘时它是唯一靠得住的线索。
- 结构化日志，字段先定死。至少包含：关联 ID、调用方身份、工具名、入参摘要（注意脱敏）、耗时、结果状态、错误分类。字段名在项目初期就定下来，后面加机器分析才不用做一堆正则。
- 入参不要原样落盘。MCP 工具的参数里经常混着用户的真实业务数据，直接全量写日志既是隐私问题也是存储问题。做法是只记结构和长度，敏感字段哈希或截断。
- 指标按工具名分维度。整体 QPS 和 P99 延迟看不出问题，因为一个 server 里可能有几十个工具，慢的永远是那两三个。按工具名拆开的调用量、错误率、延迟分位，才是能指导优化的东西。
- 把协议错误和业务错误分开统计。参数校验失败、鉴权失败、工具内部异常、下游超时，这四类的处置方式完全不同，混在一个”错误率”里等于没监控。
- 给客户端兼容性留一个观测口。记录每个请求声明的协议版本，你才知道旧客户端到底还剩多少、能不能下线兼容层。这一点在下一节会用到。
调试阶段的具体手法站内有单独一篇：MCP 调试技巧。
五、版本兼容：12 个月窗口怎么排
这次改动是破坏性的。维护者 David Soria Parra 称这是自加入授权以来最实质的变更，原话是 “A lot of things that made MCP are gone.”。2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然；官方的弃用机制给旧版本留了 12 个月的窗口。
十二个月听着宽裕，但如果你的 server 是对外服务的，实际可支配时间要打折——你没法控制别人什么时候升级客户端。可操作的排法大致是：先在观测里把旧版本客户端的占比和身份摸清楚，再决定兼容层维持多久；新功能只在新版本上做，旧版本只做安全修复；下线前至少提前一个完整通知周期告知，并在响应里带上弃用提示，而不是到期直接断。
版本共存的具体处理可以参考 MCP 版本兼容，升级前的逐项核对建议对着 MCP 升级检查清单 走一遍。
另外提一句发现侧的变化：官方注册表 registry.modelcontextprotocol.io 提供 server 发现、文档与 API 参考，由 modelcontextprotocol GitHub 组织维护、社区驱动；路线图里还有 MCP Server Cards，思路是通过 .well-known URL 暴露 server 元数据，让注册表和爬虫不用真的连上去就能知道你有什么能力。如果你的 server 打算对外开放，这块值得提前留意，具体格式以官方文档当前版本为准。
六、诚实说局限
有几件事这篇没法给你答案，得说明白。
一是具体参数没有标准答案。限流阈值多少、超时设多长、缓存 TTL 给几秒，取决于你的工具是查数据库还是调外部大模型，差着数量级。这篇给的是选型思路，不是配置模板。
二是规范太新，实践沉淀还不够。这版发布于 2026-07-28，各家 SDK 和网关的跟进节奏不一致，你在某个 SDK 上遇到的行为可能是它还没实现完，而不是规范如此。遇到不一致时以官方规范文档和对应 SDK 仓库的当前状态为准，不要照搬包括本文在内的任何二手描述。
三是网上有大量已经过期的中文资料。这个方向的中文内容本来就少，存量里不少还停在更早的版本，甚至把旧版本当作当前稳定版在介绍。看到具体版本号、具体接口形态的说法，都建议回官方博客和规范文档对一次。
四是**“无状态”不等于”不能有状态”**。协议层不再要求会话追踪，说的是协议这一层；你的应用当然可以有状态，只是这个状态要由你自己显式管理和外置，而不是搭协议会话的便车。这个区别不搞清楚，很容易做出一个”改完之后到处丢上下文”的版本。
小结
这次规范修订对生产部署最实在的收益，是让远程 MCP server 回到了普通无状态 Web 服务的部署模型：普通负载均衡就能扛，横向扩容不用再折腾会话亲和。代价是原来搭便车的那些东西——会话级限流、会话级凭据、靠 session id 串日志——都要自己重做一遍。鉴权上重点是把自己当标准 OAuth 受保护资源来部署，并落实客户端对签发方标识的校验；限流上重点是换掉本地计数器、按身份加工具名分层、把轮询类请求单独归类；可观测性上重点是自造关联 ID 并按工具名拆指标。破坏性变更有 12 个月窗口，先用观测数据摸清旧客户端占比再排下线节奏，比拍脑袋定日期稳妥得多。