上个月我们团队接一个 MCP ServerDemo 阶段十分钟不到就把工具调通了当时都觉得这技术路径稳了。结果灰度上线第一天问题接连冒出来有 Agent 把查询用户和删除用户两个工具搞混权限根本收不住有工具调用的下游 API 卡了 40 秒整个对话直接僵死等想复盘的时候日志里连谁调过什么工具、传了什么参数都翻不出来。经历这一轮之后我才彻底明白接入 MCP 工具时能调用只是入场券权限、超时、审计这三件事不做好压根谈不上生产可用。这篇内容不是 MCP 协议科普而是一份实战治理笔记。适合正准备把 MCP 接进业务系统、或者已经在接但总隐隐觉得不对劲的朋友。我会把权限拆成连接、工具、资源、数据行四个层级把超时拆成连接、执行、流式三层再把审计做成可直接落地的字段清单和复盘链路。每个环节都会给出可以照做的配置和踩坑记录。1. 能调用只是入场券MCP 接入的生产门槛1.1 一个跑通了的 Demo 和一台不能上线的服务MCPModel Context Protocol这两年的热度不用多说功能上就是给 AI 模型提供一个标准化的方式去连接外部工具和数据源让模型不再只会回答问题而是能查文件、能开浏览器、能调内部 API。IDE、Agent 框架、各种工具链都在往这个方向靠很多团队的接入路径也都是先起一个 MCP Server客户端一连工具一调通了大家就觉得可以上线了。这个通了本身其实很廉价。原因很简单MCP 的链路相比业务系统来说很直接——Client 发请求Server 执行返回结果。协议越简单Demo 就越顺畅而顺畅的 Demo 恰恰掩盖了所有生产问题。我见过不少人把 MCP Server 做成一个全工具开放的服务tools/list 返回的清单是完整版任何连上来的客户端都能看到全部工具再配合宽到离谱的超时设置以及完全不落审计日志的配置。这种服务在 Demo 演示时表现特别好因为你想调哪个工具都能立刻调通但放到生产环境基本等于把一台不设防的服务器交给一个会自己拿主意的 AI 去操作。这里有个很容易被忽略的差异传统 API 的调用方是明确的代码逻辑你能在代码里写死谁能调什么MCP 的调用方是一个 Agent模型会根据当前对话自行决定调用哪个工具、以什么顺序调用。也就是说你不仅要把权限做强还要防止模型选错工具。权限不够细、工具列表不加区分就会看到 Agent 调用删除类工具这种真实事故。最近网上还流行一种演示方式直接把带着 token 的 MCP 端点地址贴在文档或教程里读者复制粘贴就能连上。演示是方便了但 token 一旦泄露任何人或任何 Agent 都能连进来执行工具操作后果已经不是演示两个字能兜住的。所以我对能调用的定义一直是它只代表你已经接上了这条数据通路离可上线还差着一整套治理能力。所谓治理能力落到具体事项上就是权限边界、超时机制、审计回放。这三件事任何一个缺失都会在流量起来之后集中爆发。1.2 为什么权限、超时、审计成了 MCP 绕不开的三座山我在接入过程中反复提醒自己MCP 本质上是一个把真实操作能力暴露给 AI 的协议而 AI 对工具的选择和执行带有很多不确定性。权限问题因此变得比传统 API 更尖锐——传统 API 的调用者是人或固定的服务你可以在代码里严格控制MCP 的调用者可能是一个会自由发挥的模型它自己决定调用哪个工具。如果 MCP Server 把所有工具都摊开来模型就可能选到它不该碰的那个。尤其当工具有写操作、删除操作、命令执行能力时一个未收紧的权限边界就是事故源。超时问题也一样。传统 API 超时大多是等一个响应最多再加个连接超时MCP 的会话是长连接里面还嵌套了多次工具调用而且 Agent 拿到结果后还会继续思考和调用下一轮。某一次工具调用卡住用户体感不是接口慢了而是AI 彻底死掉了。再叠加模型自动重试的行为超时后的重复执行可能带来比超时本身更大的副作用。审计则是最后一层安全网。当 AI 可以自主调用工具出了事情后再也不能靠我没让它干这个来推脱唯一能让各方确认事实的只有完整、不可篡改的调用记录。这也是我把它看作生产可用底线的原因功能可以迭代体验可以优化但若连谁在哪个会话里调用了什么工具、传入了什么参数、得到什么结果都查不到这个系统就失去了被信任的基础。2. 权限从工具可见到数据行级的授权粒度2.1 连接鉴权先回答谁在连我的 MCP Server权限的第一步不是谁能调用工具而是谁能连上 MCP Server。这听起来像废话但实际很多人忽略了。MCP 的传输方式主要分两类一类是本地 stdio一类是 HTTP/SSE 的网络端点。本地 stdio 看着安全因为只有本机进程能连但你要是用一个权限过宽的共享账号启动 Server任何能在这个账号下执行命令的进程都能冒充合法客户端去调用工具。所以在本地场景也要确保 Server 以独立、最小权限的服务账号运行而不是塞进某个 admin 的启动脚本里。远程 HTTP/SSE 端点就更直接了必须做鉴权。前文提到的token 贴在文档里的做法本质就是把连接凭证公开了。实践中我建议给 MCP Server 配置 OAuth2 或者至少是带 scope 的 token 体系。为什么强调 scope因为如果所有客户端都共用一把 master token你后面做的所有工具级权限都会被绕过——鉴权过了后面所有工具都对你开放。scope 至少可以区分只读读写管理三档。比如给内部演示环境一个只读 token给自动化测试一个隔离数据集的 token给生产环境单独一套永不落盘的 token。这样即使某一把 token 泄露影响范围也可控。还有一个非常常见的坑把 MCP Server 监听在 0.0.0.0。本地演示无所谓但如果这个服务运行在一个网络可达的机器上等于向局域网甚至更大范围开放了一扇门。如果你确实需要供多个客户端访问正确做法是在前面加一层统一的 MCP 网关或反向代理做认证而不是让 Server 裸奔。传输层的安全同样不能省——远程端点应该用 TLS否则 token 和工具调用内容都在明文传输。权限这件事连接层收得越紧后面工具层的压力就越小。2.2 工具级与资源级权限给 AI 划定活动边界连上来之后下一步是决定这个客户端能看到哪些工具、能调用哪些工具。很多人以为只要 Server 端代码判断工具是否可以执行就够了但忽略了一点MCP 客户端会通过 tools/list 拿到工具清单模型会在清单范围内选择。也就是说如果所有工具都在清单里即使某个工具在实际调用时才报权限错误模型还是可能反复尝试甚至因为看起来可用而走上错误路径。更合理的设计是在返回工具列表时就做过滤让 Agent 根本看不到无权使用的工具。工具可见性之外资源范围也要限制。工具是抽象入口它背后操作的可能是文件系统、数据库或外部 API。对文件类工具根目录就决定了一切——如果你给一个 filesystem 工具配置的是整个系统根目录那 AI 理论上可以去读敏感文件正确的做法是把根目录指向一个特定沙箱目录比如 /var/data/sandbox 或者 /tmp/mcp-workspace并且以只读权限挂载。对数据库类工具不能因为AI 会写 SQL就让它直连主库要考虑它能够访问哪些 schema、哪些表、是否允许 UPDATE/DELETE。对网络请求类工具DNS 或域名白名单是必须的否则一个浏览器工具可以随便访问内网地址。给你一张我常用的工具权限矩阵样例可以直接根据自己项目改工具可见角色可调用角色资源范围审批查询订单所有人已登录用户本人/被授权订单无修改订单状态客服客服主管指定客户群操作后审计删除用户管理员超级管理员生产环境需 MFA需要二次确认写文件开发者项目负责人沙箱目录自动备份后放行执行命令运维仅自动化平台白名单命令集必须双人复核这张表的关键在于可见和可调用分成两列。即便某个工具不可调用能看见它也会干扰模型决策。我实际踩过的坑是开放了一个删除临时文件的工具虽然 Server 端对非管理员角色做了调用拦截但 tools/list 还是把所有工具都列出来了。结果普通用户只是让 AI把临时目录清理一下模型就反复尝试调用删除工具一次被拒再试一次浪费了大量 token 和调用资源。把不可用的工具从列表中过滤后这类问题立刻消失。2.3 行级权限与用户身份映射防止越权查询的必经之路再往下一层是数据行级权限。很多 MCP Server 在接入时用的还是后端服务账号不管前面是谁在跟 AI 对话工具调用时打到业务系统里的身份都是同一个 agent 账号。这种做法的直接后果是AI 替用户查询数据时往往会返回超出该用户权限范围的数据。举个最简单的例子用户 A 对 AI 说帮我查一下用户 B 的订单如果 MCP Server 只校验查询订单工具是否被允许不校验当前对话用户是否有权查看用户 B 的订单那 A 就能借 AI 之手看到 B 的订单。这在权限体系里就是典型的越权而且因为隔着 AI用户还不太容易察觉。要解决这个问题MCP 接入必须做用户身份映射Agent 在调用工具时要把当前对话的真实用户身份传递下去。实现上可以在网关层从会话上下文解析 user_id通过 Header 或者上下文对象注入到工具调用请求中MCP Server 端拿到 user_id 之后再走业务系统的 RBAC/ABAC 进行行级过滤。行级权限说起来就四个字做起来牵扯很大尤其是有些工具是直接封装旧系统的旧系统根本没有当前用户概念传过去的 user_id 没人用。此时最稳妥的做法是把这类工具标记为高权限工具只对少数灰度用户开放并且用审计日志加强监控直到业务系统补齐身份链路。如果你用 Java 系技术栈你会看到像行级权限相关的方案已经比较成熟Spring Security、MyBatis 拦截器都能做数据权限过滤。MCP Server 接入这些系统时别把 MCP 当作例外权限逻辑该怎么走还怎么走。我的经验是宁可让 Agent 在边缘场景多报几个权限不足也不能让共享服务账号成为 MCP Server 的统一身份。服务账号只是底座真实身份必须逐层传递否则权限体系就是纸糊的。2.4 最小权限矩阵落地一道可以抄的作业权限矩阵做出来之后落地方法也有讲究。我的建议是先做默认拒绝再逐步放行。也就是说MCP Server 暴露给外部的工具列表初始状态应该是空列表每接入一个工具都要经过权限评审明确它的可见角色、可调用角色、资源范围才能加进去。这跟给数据库开账号一样一开始给最小权限后面按需申请、按需放开而不是一开始就把 DBA 权限给出去后面再一点点回收。评审过程中还要注意间接权限问题。一个工具本身看起来无害但它可能间接操作了另一个系统。比如导出报表工具如果底层的临时目录权限过大可能同时把其他用户的数据也导出再比如浏览器自动化工具如果目标站点没有做内网隔离AI 可能通过打开内网地址来探测网络拓扑。权限矩阵不能只看工具名还要看它依赖的资源链路。最后补充一个我常用的技巧把权限矩阵放在一个独立配置中心而不是散落在代码里。这样工具上线、角色变更、资源范围调整都能走统一的配置评审流程也方便审计时回溯某个时间点某个工具对哪些角色可见。权限不是写出来就完了它是个持续运营的过程。3. 超时别让一次工具调用卡死整个 Agent3.1 MCP 场景的三层超时每一层都要单独设如果说权限决定的是能不能调超时决定的就是卡住了怎么办。传统 API 的超时经验在 MCP 场景是不够用的因为 MCP 不是一次请求-响应就结束而是会话式的多步交互。一个 Agent 任务里可能连续调用五六个工具每一步都可能卡。你把每个工具的调用超时都设成一样的就会出现有些工具明明 500 毫秒能完成你给它 30 秒有些工具内部要等下游接口你只给它 10 秒的尴尬局面。所以我建议把超时分三层来设连接超时、工具执行超时、流式空闲超时。连接超时管的是建立 MCP 会话这一下一般 5 秒就够因为正常连接不应该超过这个时间工具执行超时才是大头得根据工具特性分别配置查询类短一点需要写文件或外部调用的长一点流式空闲超时管的是返回数据的过程中卡住的情况。我之前被坑过的就是工具返回的是一个大的流式结果前几百毫秒正常吐数据突然停住不再发送但总时长还没到于是一直挂着。后来加了流式空闲超时超过 15 秒没有数据就判定失败问题才解决。一个可以参考的配置示例{ timeout: { connect: 5000, toolCall: { select: 15000, insert: 30000, fileWrite: 60000, commandExec: 120000 }, streamIdle: 15000, totalCallDuration: 300000 } }这里的数值要根据业务调但有一点是共通的同一个工具在慢查询和写操作两种场景下超时标准必须不同。我习惯在配置中心按工具名操作类型来设定而不是给所有工具统一一个值。工具调用如果还涉及外部依赖要再往上叠加一个外部接口响应时间避免 Agent 在一个下游慢接口上反复空等。3.2 超时后的重试必须解决幂等性超时并不可怕可怕的是超时之后的自动重试。Agent 框架为了提高成功率普遍会在工具调用失败或超时后自动重试。这在只读工具上问题不大一旦工具是写操作就可能导致重复下单、重复发短信、重复创建资源。举个真实例子我们接的一个发送通知工具第一次调用时下游实际已经收到请求并发送成功但客户端因为网络抖动超时了Agent 自动重试结果用户收到了两条一模一样的通知。更严重的是订单类、转账类工具同样的错误重试一次就是一次资金级事故。解决的办法是给每次工具调用绑定幂等键核心思路是同一个请求只执行一次。实现上可以在调用侧生成 request_id把 user_id、tool_name、业务参数做一个 hash 作为幂等键MCP Server 在处理时先查一次去重表如果同样的幂等键已经执行过直接返回之前的结果而不是再执行一次。伪代码大概是这样的def call_tool_with_idempotency(tool_name, payload, user_id): idem_key sha256(f{user_id}:{tool_name}:{json.dumps(payload, sort_keysTrue)}) cached store.get(fmcp:dedup:{idem_key}) if cached: return json.loads(cached) result mcp_client.call_tool(tool_name, payload) store.setex(fmcp:dedup:{idem_key}, 3600, json.dumps(result)) return result这里有个细节需要说明幂等键的有效期不能太短至少要覆盖到可能出现的重试窗口。用户看到超时提示后可能手动再发一次所以要设一个恰当的时间窗口比如 10 分钟到 1 小时。另外如果工具本身支持幂等性比如支付类接口通常有 idempotency_key优先让工具自己保证如果工具不支持MCP Server 这层必须兜底。重试策略也要带退避不要超时后立刻重试等个几百毫秒到几秒再试一次超过两三次就放弃并告知上游。3.3 流式调用与长任务超时不是一刀切还有一类场景容易被一刀切超时误伤就是流式调用和长时间任务。现在的 Agent 工具不一定会把结果一次性返回有些会以流的方式逐步输出比如日志跟踪、数据管道监控、长文本生成。这种情况下如果你只设一个总时长为 60 秒那么一个正常要跑 3 分钟的任务到 60 秒就被强行掐断了反过来一个真正卡死的流因为总能隔几秒吐一点数据又可能一直占着资源不释放。对这种场景我的做法是区分首包时间和包间隔时间。首包时间是从发起调用到收到第一个数据块的最大等待时间超过这个时间说明请求可能根本没进入正常执行包间隔时间是指两个连续数据块之间的最长空闲时间超过它说明流卡住了。用这两个参数组合判断比单一总时长精准得多。比如设首包时间为 10 秒包间隔为 15 秒只要一直有数据在流动任务就可以继续跑下去但一旦真的卡住最多 15 秒就能发现并终止。总时长还是要设的只是作为最底层的安全网。我一般把单次工具调用的总时长上限控制在 5 分钟整个 Agent 任务中工具调用的累计时长控制在 10 分钟以内。这样既允许长任务存在又不会让某个失控调用无限占用资源。遇到接收返回码超时这类报错时也别急着调大超时先确认卡在哪个阶段——是连接没建立、请求发出去没响应、还是响应过程中断了。用分层超时的思路去排查几分钟就能定位到问题点。4. 审计让每一个 AI 动作都经得起回放4.1 审计日志不是业务日志字段和存储都要单独设计我见过很多团队的 MCP 接入把日志写在应用日志里出了事就去 grep。这其实混淆了业务日志和审计日志。业务日志关心的是功能正常吗审计日志关心的是谁在什么时间通过什么工具做了什么操作两者关注的字段、保存方式甚至存储位置都应该分开。审计日志的第一原则是不可变性只能追加不能修改更不能随便删除。除非你把它放在独立存储里、权限单独收敛否则很难保证出事之后日志还是可信的。那审计到底记什么我整理过一组最小化字段基本够用字段说明event_id / request_id唯一事件 ID贯穿会话与工具调用session_id所属会话用来回溯一次完整对话user_id / agent_id真实用户或 Agent 身份tool_name调用的工具名input_hash输入参数的 hash保留可用性同时避免全量敏感参数落盘output_summary输出摘要或结果状态码status成功、失败、超时、被拒绝duration_ms调用耗时timestamp事件时间approval是否经过人工确认/二次审批这套字段看起来不多但已经能回答绝大多数问责问题。输出部分如果业务需要可以单独存一份完整结果并在审计里关联存储 ID不要一股脑塞进审计日志。工具返回内容可能很大全量记录既浪费存储也容易把敏感数据拖进日志里。我们在这个问题上吃过亏一个文件读取工具把文件内容整个写进了审计日志结果服务器磁盘一天就被撑满还在日志里留下了大量客户数据。后来改成只记录输出大小和文件路径 hash只在需要复查时通过 request_id 去原始存储取完整结果问题才算解决。4.2 脱敏与 Diff 记录审计里的敏感数据怎么处理审计要完整隐私也要保护这两者看起来矛盾其实可以通过脱敏来平衡。工具调用参数里经常包含 token、密码、身份证号、地址这类敏感信息全量写进审计显然不可取但完全不记又没法排查问题。我建议的做法是在进入审计链路前先做字段级脱敏高敏感字段只保留部分内容或者做单向 hash非敏感字段保留原值。关键是要在保护敏感信息的同时不破坏关联能力——比如你 hash 了用户手机号但同一个手机号在不同事件里 hash 结果一致排查时仍然能通过 hash 去关联同一用户的操作记录。另外借鉴数据库变更审计框架Java 系的 audit4j 就是一个例子的思路工具调用审计也可以记录变更前和变更后。数据库审计框架擅长记录 update 语句前后的数据 diffMCP 工具调用同样适用如果调用的是一个写操作审计里最好包含变更摘要比如将订单状态从 pending 改为 paid。这样以后的回放不只是一条日志而是能还原出操作对系统产生了什么影响。实现上不需要自己从零造很多 Agent 框架和网关组件已经支持对工具调用做前后状态采集关键是你要在接入时规划好而不是等出了事再想补。审计数据的存储权限也要单独设计。审计库账号应该只允许 insert 和 select不允许 update 和 delete访问审计数据需要独立审批最好和业务系统的权限体系分离。这不是加大运维负担而是防止删数据的人顺便删审计。我甚至会在审计存储前面加一层只读副本线上出问题时用副本复盘绝不让排查过程干扰原始审计链路。4.3 出问题后的完整复盘链路从会话回溯到工具调用审计做到位最终价值体现在事故复盘时。我给你描述一个我们真实处理过的场景用户投诉AI 把我的文件删了。没有审计之前这种投诉基本没法查因为 Agent 的执行过程千变万化你不知道它在哪个环节动了文件。接好审计之后复盘链路就变得清晰了首先根据用户的 user_id 和投诉时间范围找到对应的 session_id然后去审计系统里把该 session 下的所有工具调用列出来按时间排序接下看每个调用的事件 ID、工具名、输入参数 hash 和状态码最后定位到删除文件这个工具调用查看它的参数、审批记录和前后状态判断这究竟是用户明确指示、模型误判还是工具本身 bug。这条链路里request_id 贯穿始终非常关键。Agent 框架在生成工具调用时通常会给每个调用分配一个 IDMCP 协议里也有调用请求 ID你要做的是把这个 ID 跟业务日志、审计日志关联起来。这样一旦某次调用出问题从审计事件找到 request_id再到应用日志里搜同 ID能快速看到下游系统的处理过程。如果只是把日志分散在各处而没做关联复盘时就要靠猜效率极低。我个人的底线是如果一次 MCP 接入没有审计回放能力那它只能停留在 Demo 阶段。技术实现上审计可以放在 MCP Server 里也可以放在统一网关里。放在 Server 里的好处是工具粒度可控放在网关里的好处是集中管理、不要求每个 Server 都写一遍。无论放哪里都要保证调用发生即记录而不是事后补记。我记得有次审计组件异步队列出了故障一批日志没写进去等发现的时候已经覆盖了半小时的操作记录。后来我们给审计链路加了本地缓冲和重试宁可让调用慢几毫秒也不允许审计丢失。5. 把三道坎写进接入清单一套可直接复制的 MCP 治理流程5.1 接入前、上线前、运营中三张检查表前面讲了这么多最终还是要落到怎么执行。我把自己在团队里推的一套 MCP 接入检查表分享出来你可以直接抄。接入前列出工具清单逐个标注敏感级别只读、写、高影响确定连接鉴权方式准备最小 scope 的 token为每个工具定义超时参数划分三层超时设计审计字段和存储位置确定脱敏规则检查是否有行级权限需求确认 user_id 传递链路。上线前用默认拒绝方式初始化工具列表逐个评审放行验证 tools/list 返回的是过滤后的清单测试超时、重试、幂等逻辑确认写操作不会重复执行确认审计日志已经落库并且不可修改做一次权限矩阵评审邀请业务方和安全方一起过。运营中定期 review 工具列表下线不再使用的工具监控超时率、失败率和异常调用模式检查审计覆盖率是否有调用但没有对应日志周期性做一次权限矩阵收集识别权限膨胀。这套检查表看着朴素但每一项背后都是我和团队踩过的真实坑。很多项目不是不懂权限、超时、审计而是没有把这些要求固化成流程结果在忙业务的时候被随手跳过。把它们变成上线前的硬性检查项之后MCP 接入的质量明显稳定了。5.2 典型工具场景Playwright MCP 与 Burp Suite MCP 的治理差异聊完通用流程再说两个具体的典型工具它们的权限、超时、审计侧重点很不一样。第一个是 Playwright MCP作用是让 AI 能操作浏览器比如自动填表单、点击页面、抓取内容。这颗工具的危险点在于它能访问的网络范围太广。如果不对目标站点做限制AI 在对话中完全可以去打开内网 IP探测内部服务。在接入它之前你至少要明确允许访问的域名白名单是否允许跨域跳转是否允许文件下载如果出现页面一直加载不出来的情况超时怎么处理。浏览器自动化天然容易触发超时——页面加载慢、等待元素、弹出对话框任何一个环节都能卡住。我一般给 page 操作设置更高的超时上限但流式空闲超时必须严防死守防止一个无响应的页面把整个 Agent 拖死。审计上需要记录 AI 实际访问的 URL、操作类型和选择器一旦出现AI 乱点一气的问题至少能回放它点了什么。第二个是 Burp Suite MCP它让 AI 能操控 Web 安全测试工具比如发送 HTTP 请求、分析响应、管理扫描任务。这类工具的权限敏感度比普通业务工具高得多因为它直接接触目标系统稍有不慎就会产生越权扫描甚至破坏性操作。我建议接入 Burp Suite MCP 的用户必须单独授权不能在统一用户池里开放工具列表要严格过滤默认只暴露无害的读取和请求构造类工具扫描类工具需要二次确认审计上要记录请求包摘要、目标 URL 和响应状态但不需要把完整请求体都存下来——安全测试请求可能包含 payload敏感内容不适合长期落盘。这两个例子的共通点是工具能力越强治理要求就越严格。你在评估一个 MCP 工具能不能接入时先想想它最危险的操作是什么然后问自己权限能挡住吗超时能控制住吗出问题能查出来吗三个问题都过关才轮到功能价值评估。5.3 统一 MCP 网关权限拦截、超时熔断、审计记录三合一如果你要接入的 MCP Server 不止一个靠每个 Server 自己实现权限、超时、审计不仅重复劳动还容易出现标准不统一。更推荐的做法是在 Agent 和各个 MCP Server 之间加一层统一的 MCP 网关或者叫 MCP 准入层。它的职责很简单对外它向 Agent 暴露一个经过过滤的、统一鉴权的 MCP 接口对内它转发请求到真正干活的 MCP Server并在这个过程中完成三件事。第一权限拦截。网关在返回 tools/list 时根据当前用户和会话上下文过滤工具列表在接到 tools/call 时再做一次调用鉴权并检查资源范围。这样即使某个 MCP Server 内部忘记实现权限校验网关也能兜住。第二超时和熔断。网关对每个上游工具定义超时策略出现超时或者连续失败时自动熔断避免一个故障工具拖垮整个 Agent 会话。第三审计记录。所有工具调用的元数据都在网关层统一落审计保证口径一致也方便做跨工具的调用链回溯。网关本身最好是无状态的可以把审计和幂等状态放在 Redis 或者数据库中。有人会说加一层网关不是增加了延迟吗实际影响很小因为它只做转发和治理不做业务逻辑。相比直接在 MCP Server 里堆治理代码的杂乱网关把关注点收敛了后期维护成本低得多。还有一点可以补充网关也可以承担工具的版本管理和灰度能力。比如你想把一个新工具先只开放给 10% 的用户在网关层就能做按比例的流量切入而不需要修改 MCP Server 代码。这几乎是 API 网关在微服务时代的成熟思路只不过对象从 HTTP 接口换成了 MCP 工具。我现在的习惯是每接入一个 MCP 工具都先回答三个问题它能被谁调用最慢多久必须返回如果出问题我能查到原始调用吗三个问题有一个答不上来我就不会让它进入生产。MCP 带来的是前所未有的效率但这绝不意味着可以牺牲治理性。项目可以因为 Demo 跑得顺而乐观生产环境却经不起一次权限失控、一次超时误伤、一次审计缺位。能把能调用做成可治理这个工具才真正算接进了你的系统。