企业官网建设流程全解析

上个月我们团队接一个 MCP Server，Demo 阶段十分钟不到就把工具调通了，当时都觉得这技术路径稳了。结果灰度上线第一天，问题接连冒出来：有 Agent 把"查询用户"和"删除用户"两个工具搞混，权限根本收不住；有工具调用的下游 API 卡了 40 秒，整个对话直接僵死；等想复盘的时候，日志里连"谁调过什么工具、传了什么参数"都翻不出来。经历这一轮之后我才彻底明白：接入 MCP 工具时，"能调用"只是入场券，权限、超时、审计这三件事不做好，压根谈不上生产可用。

这篇内容不是 MCP 协议科普，而是一份实战治理笔记。适合正准备把 MCP 接进业务系统、或者已经在接但总隐隐觉得不对劲的朋友。我会把权限拆成连接、工具、资源、数据行四个层级；把超时拆成连接、执行、流式三层；再把审计做成可直接落地的字段清单和复盘链路。每个环节都会给出可以照做的配置和踩坑记录。

1. 能调用只是入场券：MCP 接入的生产门槛

1.1 一个"跑通了"的 Demo 和一台不能上线的服务

MCP（Model 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 或域名白名单是必须的，否则一个浏览器工具可以随便访问内网地址。

给你一张我常用的工具权限矩阵样例，可以直接根据自己项目改：

这张表的关键在于"可见"和"可调用"分成两列。即便某个工具不可调用，能看见它也会干扰模型决策。我实际踩过的坑是：开放了一个"删除临时文件"的工具，虽然 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. 超时：别让一次工具调用卡死整个 Agent

3.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_keys=True)}") cached = store.get(f"mcp:dedup:{idem_key}") if cached: return json.loads(cached) result = mcp_client.call_tool(tool_name, payload) store.setex(f"mcp: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。这其实混淆了业务日志和审计日志。业务日志关心的是"功能正常吗"，审计日志关心的是"谁在什么时间通过什么工具做了什么操作"，两者关注的字段、保存方式甚至存储位置都应该分开。审计日志的第一原则是不可变性：只能追加，不能修改，更不能随便删除。除非你把它放在独立存储里、权限单独收敛，否则很难保证出事之后日志还是可信的。

那审计到底记什么？我整理过一组最小化字段，基本够用：

这套字段看起来不多，但已经能回答绝大多数问责问题。输出部分如果业务需要，可以单独存一份完整结果并在审计里关联存储 ID，不要一股脑塞进审计日志。工具返回内容可能很大，全量记录既浪费存储，也容易把敏感数据拖进日志里。我们在这个问题上吃过亏：一个文件读取工具把文件内容整个写进了审计日志，结果服务器磁盘一天就被撑满，还在日志里留下了大量客户数据。后来改成只记录输出大小和文件路径 hash，只在需要复查时通过 request_id 去原始存储取完整结果，问题才算解决。

4.2 脱敏与 Diff 记录：审计里的敏感数据怎么处理

审计要完整，隐私也要保护，这两者看起来矛盾，其实可以通过脱敏来平衡。工具调用参数里经常包含 token、密码、身份证号、地址这类敏感信息，全量写进审计显然不可取，但完全不记又没法排查问题。我建议的做法是：在进入审计链路前先做字段级脱敏，高敏感字段只保留部分内容或者做单向 hash，非敏感字段保留原值。关键是要在保护敏感信息的同时不破坏关联能力——比如你 hash 了用户手机号，但同一个手机号在不同事件里 hash 结果一致，排查时仍然能通过 hash 去关联同一用户的操作记录。

另外，借鉴数据库变更审计框架（Java 系的 audit4j 就是一个例子）的思路，工具调用审计也可以记录"变更前"和"变更后"。数据库审计框架擅长记录 update 语句前后的数据 diff，MCP 工具调用同样适用：如果调用的是一个写操作，审计里最好包含变更摘要，比如"将订单状态从 pending 改为 paid"。这样以后的回放不只是一条日志，而是能还原出操作对系统产生了什么影响。实现上不需要自己从零造，很多 Agent 框架和网关组件已经支持对工具调用做前后状态采集，关键是你要在接入时规划好，而不是等出了事再想补。

审计数据的存储权限也要单独设计。审计库账号应该只允许 insert 和 select，不允许 update 和 delete；访问审计数据需要独立审批，最好和业务系统的权限体系分离。这不是加大运维负担，而是防止"删数据的人顺便删审计"。我甚至会在审计存储前面加一层只读副本，线上出问题时用副本复盘，绝不让排查过程干扰原始审计链路。

4.3 出问题后的完整复盘链路：从会话回溯到工具调用

审计做到位，最终价值体现在事故复盘时。我给你描述一个我们真实处理过的场景：用户投诉"AI 把我的文件删了"。没有审计之前，这种投诉基本没法查，因为 Agent 的执行过程千变万化，你不知道它在哪个环节动了文件。接好审计之后，复盘链路就变得清晰了：

首先，根据用户的 user_id 和投诉时间范围，找到对应的 session_id；然后去审计系统里把该 session 下的所有工具调用列出来，按时间排序；接下看每个调用的事件 ID、工具名、输入参数 hash 和状态码；最后定位到"删除文件"这个工具调用，查看它的参数、审批记录和前后状态，判断这究竟是用户明确指示、模型误判，还是工具本身 bug。

这条链路里，request_id 贯穿始终非常关键。Agent 框架在生成工具调用时通常会给每个调用分配一个 ID，MCP 协议里也有调用请求 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 跑得顺而乐观，生产环境却经不起一次权限失控、一次超时误伤、一次审计缺位。能把"能调用"做成"可治理"，这个工具才真正算接进了你的系统。