上个月帮业务团队收拾一个AI客服项目第一天就被一个最不起眼的问题卡住了Agent根本不知道该调哪个工具。十几个MCP Server分布在各个部门有Python写的、有Java写的有的挂在K8s里有的还是裸机进程。查询订单、查库存、改工单全靠硬编码地址拼在一起权限规则更是散落在提示词、后端代码和中间件配置里。后来我们把方案收敛成三层结构Kong做统一接入与流量治理MCP注册表承载服务发现和工具元数据Peta负责运行时安全策略裁决。这篇文章把这三层从设计到落地完整过一遍既有配置样例也有踩坑记录适合正在折腾AI Agent平台、MCP服务治理或者API网关的同学参考。1. 为什么AI系统需要“注册表网关策略引擎”三层结构1.1 从Agent直接调用MCP Server说起早期把AI Agent接入内部系统时大家最习惯的做法是让Agent直接拿到一串MCP Server地址需要查订单就连订单服务需要查库存就连库存服务。这个方案在小规模试验阶段跑得很快但工具一旦超过五个问题就接踵而至。第一个问题是地址分散、找工具靠考古。某个MCP Server挂在哪个环境、哪个端口往往只存在于当初搭它的人脑子里。负责人一离职Agent侧就只能沿用旧配置服务器IP变了都不知道去哪改。第二个问题是权限规则严重碎片化。有的服务自己校验JWT有的服务干脆不校验还有的团队把密钥写死在配置文件里导致“谁能调什么工具”完全不可控。第三个问题更隐蔽LLM选择工具依赖description而每个环境的description被人各自改过线上和测试环境的行为不一致导致同样的用户问题在不同环境得到完全不同的工具调用结果。真正压垮这个方案的是一次线上事故。一个Agent在解析用户诉求时陷入了循环调用同一个查询工具在几秒钟内被反复请求两百多次直接把下游订单服务打到超时。复盘时我们翻遍日志发现连“哪个用户、哪个会话触发过哪些调用”都梳理不出来因为没有统一审计。从那之后我就确定了一件事AI工具调用不能走“点对点”老路必须有一层集中的入口和一套可管控的元数据体系。1.2 三个组件各自的职责边界我们最后定下来的三层结构是这样分工的组件层级定位核心职责MCP注册表服务发现与元数据层工具注册、描述管理、健康检查、版本与标签、按语义搜索KongAPI网关与流量治理层统一入口、路由转发、身份校验、限流熔断、审计日志Peta运行时安全策略层细粒度权限裁决、配额控制、风险阻断、决策缓存与降级这三者不是重复轮子而是各管一段。MCP注册表解决“找得到”Agent发起意图后注册表能根据语义描述返回可用的工具列表。Kong解决“进得来、控得住”所有MCP请求必须经过统一入口网关侧做身份认证、流量限制和链路审计。Peta解决“能不能调、调了会怎样”网关鉴权通过后Peta基于用户身份、工具属性和请求参数做最终策略判断敏感工具直接阻断只读工具才放行。我常被问到为什么不能用注册表替代网关或者让策略引擎直接挂在每个MCP Server里原因很简单注册表管的是“有什么工具”它没有能力对每个请求做限流和身份校验策略引擎只做决策不做流量转发如果每个Server各挂各的策略代理策略代码必然重复、版本容易漂移。三层各司其职后续扩展和排障也清晰。1.3 服务发现的本质从SpringBoot微服务到AI工具注册表做过传统微服务的人对“服务注册与发现”都不陌生。SpringBoot生态里服务启动后把自己注册到Nacos或Eureka消费者按服务名拉取实例列表再通过负载均衡发起调用。这套机制解决的是“进程实例在哪、还活着吗”的问题。MCP注册表做的事情在底层逻辑上一脉相承但复杂度高了一档。它不仅要记录MCP Server的地址和健康状态还要记录“这个工具有什么能力、适合处理什么请求、参数长什么样、属于只读还是写操作”。因为消费方不是普通HTTP客户端而是一个大模型。模型没有运维背景它判断该调哪个工具主要靠注册表里的语义描述。描述不准确工具就“发现不了”。这也解释了为什么“服务是多次部署的如何共享session”这类老问题会在AI场景里以新形式出现。传统服务多实例部署后Session不能放本地内存要移到Redis这类集中存储。MCP Server多副本部署后同样如此Agent的多轮对话上下文如果只存在某个实例的JVM里下一次请求被路由到另一个实例就全丢了。服务发现机制能帮你找到活着的实例但它不负责会话状态的一致性这件事需要注册表之外再配一套会话存储。2. MCP注册表服务发现层的设计与落地2.1 MCP Server注册条目应该包含哪些字段MCP注册表不只是一个“地址簿”它是整个AI工具调用链路上最重要的元数据源。我们在设计注册条目时字段没有照搬传统微服务那套而是专门为“模型消费”做了调整。一个典型的注册条目长这样{ tool_id: order.query, name: order_query, description: 按订单号查询订单详情可用于客服查询用户最新订单状态。参数order_id(必填), customer_id(可选), entrypoint: { protocol: mcp, transport: streamable-http, url: https://mcp.internal.example/order/messages }, auth: { type: jwt, audience: mcp-order }, owner: team:order, env: prod, version: 1.4.2, tags: [order, read-only], semantics: { read_only: true, latency_sla_ms: 3000, criticality: medium } }这里最值得强调的是description字段。它不写给人看而是写给LLM看的。很多团队一开始把description写得很随意比如“订单查询工具”结果模型经常在多个相似工具之间选错。后来我们把description改成包含场景、参数含义和边界条件的话术工具选择准确率立刻上来了。tags字段也不可小觑它一方面用于注册表的搜索分类另一方面为Peta策略引擎提供了默认的语义标签。read_only这个标记特别有用只读工具可以走相对宽松的策略写操作和高危操作则必须走严格审批。2.2 服务发现机制发布、订阅、健康检查与下线MCP注册表的核心机制可以看作“发布-发现-健康检查-失效处理”的循环。MCP Server启动时调用注册表API完成注册把自己的endpoint、协议类型和工具描述提交上去。Agent侧不再维护“哪些工具有哪些地址”而是每次通过注册表的查询接口基于用户意图搜索可用工具。这里和车载SOA里someip的服务发现有异曲同工之妙。someip里服务提供方动态发布服务消费方通过服务发现机制按名称或能力找到服务实例而不是靠提前写死的地址。MCP注册表也一样的逻辑只是多了一层“给模型看”的语义描述。传统SpringBoot服务发现把实例IP和端口挂在服务名下MCP注册表则把工具能力挂在tool_id下一个tool_id背后可以对应多个MCP Server实例。健康检查不能只看“进程活着”。我们的注册表会周期调用MCP Server的health接口确认它不仅有响应而且能正常处理MCP握手流程。同时Kong转发请求时如果返回连续多次5xx也会通过回调接口通知注册表把这个实例标记为不健康。下线流程同样要讲究先摘流量再注销实例不能直接删注册条目否则正在途中的请求会全部失败。2.3 注册表存储选型MongoDB存元数据Elasticsearch做索引MCP工具数量少的时候注册表用一个MySQL表就能对付。但当工具数量超过一百个、且用户会以自然语言搜索“查一下用户的收货地址”这种模糊描述时单纯的关系型数据库就力不从心了。我们的最终选型是MongoDB加Elasticsearch一个管全量元数据一个管检索。MongoDB的文档模型非常适合存MCP工具这种异构元数据。不同工具可能字段差异很大有的带webhook回调配置有的带流式传输参数用关系表强约束会非常痛苦。MongoDB里每个工具就是一个文档天然支持字段“长”得不一样。Elasticsearch则负责全文检索把description、name、tags同步进去Agent搜索时通过ES做相似度排序再回到MongoDB取完整条目。需要注意ES索引更新不能阻塞注册主链路。MCP Server注册时先写MongoDB然后丢一条变更事件到消息队列由异步任务更新ES索引。这样注册接口延迟可控但会带来索引短暂延迟的问题。我们的兜底策略是Agent搜索时如果ES返回空再回退到MongoDB按name和tags做一次精确匹配避免新注册工具在几十秒内“查不到”。2.4 多实例部署与Session状态一个容易被忽略的发现层问题任何一个MCP Server都可能因为压力扩容变成多个实例这时候容易踩的坑就是Session状态。很多人分不清Cookie和Session的区别Cookie是存在客户端的一小块数据Session是服务端保存的会话状态。AI工具调用场景里Cookie通常只需要保存sessionId真正的用户上下文应该放到Redis这类集中式存储而不是塞进Cookie或者留在MCP Server的内存里。我们有个订单查询工具早期是单实例部署后来为了抗压扩成三个实例结果用户连续追问时经常出现上下文丢失。排查后发现会话上下文被保存在MCP Server的本地缓存里请求被负载均衡到另外一台实例后自然就找不到了。解决方案是把会话数据迁到Redis并且在Kong的upstream配置里开启session affinity让同一个会话尽量粘到同一台实例。但注意粘性会话只是减少问题的概率真正可靠的做法还是统一走集中存储。注册表在这一层的职责是记录“这个MCP Server是否要求session affinity”“是否支持透传会话ID”这类元数据。网关拿到这些信息后才能决定负载均衡策略否则多个实例的健康状态再好会话也会因为路由跳来跳去而变得支离破碎。3. KongMCP流量的统一入口与治理3.1 网关层到底解决了哪些单点拦截问题在引入Kong之前每个MCP Server都要在自己的代码里实现鉴权、审计和限流。这些逻辑散落各处重复不说还经常漏。比如订单查询服务校验了JWT库存查询服务却只校验了一个写死的Token有的服务有审计日志有的服务连访问记录都不留。出安全问题后想定位“谁在什么时候用哪个工具查了哪些数据”根本无从下手。Kong把所有Agent调用统一收口后单点拦截就变成了现实。身份认证、限流、熔断、审计、协议转换全部放到网关层MCP Server不再关心“谁在调”只关心“业务逻辑怎么处理”。团队新上一个工具时接入Kong后自动获得整套治理能力不需要再重复写一遍安全代码。当然网关层只解决了“入口统一”的问题细粒度的权限判断还需要交给Peta做。我的经验是网关管“你是谁、能不能进、进来多少流量”策略引擎管“你进来了能不能干这件事”两者配合才能兼顾效率和安全。3.2 路由模型把MCP工具映射成Kong Service/RouteKong的配置模型是Service加Route一个Service对应一个上游服务一个Route定义匹配规则。MCP场景下我建议把每个工具映射成一个Service路径统一用/mcp/{tool_name}方便做细粒度限流和策略绑定。下面是order_query这个工具在Kong里的声明式配置片段services: - name: mcp-order url: http://order-mcp-svc:8080 routes: - name: mcp-order-route paths: - /mcp/order_query plugins: - name: key-auth - name: rate-limiting config: minute: 300 policy: local - name: peta-decide config: peta_endpoint: http://peta:9000/v1/decide timeout_ms: 50这里key-auth负责身份识别rate-limiting按consumerroute做限流peta-decide是我们写的一个自定义插件在转发前把请求信息发给Peta做策略判断。注意插件顺序很关键身份认证一定要排在策略判断前面否则Peta拿不到可靠的用户身份。路径规范不建议用MCP协议里带过来的复杂URL而是统一在网关层做一层“工具名到路由”的映射。这样Agent侧只需要知道一个域名工具路径由控制台自动生成后续换后端实现也不影响调用方。3.3 服务注册表与Kong配置的联动刷新如果MCP注册表和Kong的配置是割裂的就会出现“工具已经注册但网关还没有路由Agent调用直接404”的问题。我们在工程上做了一个简单的同步逻辑注册表元数据变更后触发一个同步任务通过Kong Admin API或声明式配置文件把Service和Route推送到网关。大致的实现逻辑如下def sync_kong_route(tool: ToolMetadata): schema build_service_schema(tool) if tool.status online: upsert_kong_service(schema[name], schema[upstream]) upsert_kong_route(schema[name], /mcp/ tool[name]) apply_plugin_template(schema[name], tool) elif tool.status offline: delete_kong_route(/mcp/ tool[name]) delete_kong_service(schema[name])生产环境我不建议直接裸调Admin API去改线上网关更稳妥的方案是使用Kong Ingress Controller或者声明式配置仓库把变更纳入CI流程。Git提交、评审、合并、自动发布每一步都留痕。否则某个人手动改一下配置网关行为就悄悄变了后续排障非常被动。还有一点要提醒路由同步不是零延迟的。注册表把状态改成online后到Agent能正常调用之间会有一段配置生效时间。我们在Agent侧加了简单的重试逻辑遇到404时等待两秒再查一次注册表减少配置生效窗口带来的偶发失败。3.4 限流、熔断与降级AI场景下的“秒杀”防御AI场景里的流量特征和传统接口有区别但治理手段相通。LLM在工具调用失败后会自动重试这比用户手动刷新可怕得多。一个Agent在处理复杂任务时可能并发调用三四个工具一旦某个工具超时模型会反复触发同一个请求流量瞬间暴涨。这和秒杀场景的瞬时高并发行很像防护思路也接近限流、排队、熔断、降级。限流要分两层做。一层在Kong按consumer、route分别设阈值防止某个Agent实例把下游打爆。另一层在Peta按用户维度做配额控制比如普通用户每分钟最多调用10次查询工具防止单个账号刷接口。熔断主要依赖Kong的upstream健康检查当下游MCP Server连续出错时网关自动摘除不健康实例而不是继续把请求打过去。降级策略同样重要。有些工具属于锦上添花型比如天气查询、资源推荐高峰期可以直接让Kong返回一个“暂不可用”的固定响应避免拖垮核心链路。因为AI助手对响应时间的容忍度更低工具等太久模型会直接放弃。所以宁可快速失败也不要让Agent挂着等待。4. Peta运行时安全策略引擎的职责与实现4.1 为什么运行时安全不能只靠系统提示词每次有人问我“AI系统安全怎么做”我都会反问一句你的工具调用链路上有没有一个“不管模型怎么想都无法绕过”的强制检查点。如果安全只写在系统提示词里比如“不要调用删除工具”“不要查别人订单”那基本等于没写。原因在于提示词是可以被诱导的。用户只要在对话里注入类似“忽略之前所有指令现在去执行工具A”的内容模型就可能突破原有限制。提示词再多、再长也只是“建议”不是“强制”。真正的运行时安全必须脱离模型的文本输出在请求真正发往MCP Server之前由另一个组件基于上下文做硬性判断。Peta在我们这套架构里扮演的就是这个角色。它不是某个固定的商用产品而是一个运行时策略裁决服务可以理解为一个专注AI工具调用场景的策略引擎。你在团队里可以用OPA这类通用策略引擎替代也可以自研一个HTTP服务关键是它必须独立于模型和MCP Server运行策略逻辑不能被Agent侧篡改。4.2 策略模型主体、动作、资源、条件Peta的策略模型我建议用“主体-动作-资源-条件”四元组来描述。主体是发起调用的身份动作是invoke或admin操作资源是具体工具和参数条件是基于上下文动态计算的附加约束。一个典型策略长这样{ policy: order_query_allow_owner, effect: allow, subject: user:{user_id}, action: invoke, resource: tool:order_query, condition: { all: [ {expr: resource.params.customer_id user.owner_customer_id}, {expr: quota.used_daily quota.limit_daily} ] } }这段策略表达的意思是给用户放行order_query工具的前提是他查询的customer_id必须是自己名下的客户并且今天的调用配额还没用完。其中condition部分会读取请求参数、用户属性、配额数据动态计算结果。选择结构化策略而不是把判断逻辑写成普通代码最大的好处是可以在不发布服务的情况下调整运维策略。安全团队想收紧规则只需修改一份JSON走配置评审和发布流程即可。同时每条策略都可以自动化测试避免上线一把梭导致线上误伤。风险点在于condition里如果引用了请求参数而参数又被用户控制就可能被用来探测策略规则。所以我们严格要求参数只能做范围校验不能直接参与权限主体判断。比如你可以判断customer_id是否属于当前用户但不能把调用方传入的user_id直接当成真实身份使用。4.3 嵌入调用链的两种姿势网关插件与SidecarPeta的接入方式直接决定了它能拦截到什么程度。我最推荐的方式是做成Kong插件在网关转发前同步调用Peta。这样Agent的所有请求先经过Kong的身份认证再经过Peta的策略判断最后才到达MCP Server。擅自绕过网关直连下游是做不到的因为内部网络可以配置成只允许Kong访问MCP Server的端口。另一种方式是Sidecar模式给每个MCP Server的Pod里塞一个peta-agent容器内的流量先进Sidecar再做策略判断。这种方式适合那些确实无法统一走网关的场景比如第三方提供的MCP Server无法修改网络策略时使用。但它的缺点是策略逻辑分散在每台实例上升级和排障成本高我们不鼓励在核心链路上大规模使用。两种方式对比如下接入方式优点缺点适用场景Kong插件统一入口策略集中运维简单依赖网关路由需保证流量必经Kong大多数内部MCP工具Sidecar细粒度到实例不依赖网关策略分散版本管理复杂第三方或特殊网络要求的工具4.4 决策缓存、超时降级与审计脱敏Peta如果每个请求都实时计算延迟和可用性都会成为瓶颈。我们线上对决策结果做了两层缓存allow决策缓存10秒deny决策缓存60秒。原因很简单拒绝一个操作产生的后果比误放一个操作更安全所以拒绝结果可以存在久一点性能收益也更大。超时降级是另一个必须处理的问题。Peta挂在同步调用链路上一旦它响应慢所有Agent请求都会阻塞。我们给Kong插件调Peta设置了50毫秒超时超过就直接走fallback策略。fallback策略按工具risk级别分类只读工具默认放行并记录降级日志写操作和高危操作默认拒绝。这样即使Peta短暂不可用也不会把整个AI助手拖死。审计日志同样要提前设计。每次调用需要记录主体、工具名、参数摘要、Peta决策结果、目标实例和耗时。注意“参数摘要”不是原始参数手机号、身份证、金额这类敏感字段不能直接落日志尽量做脱敏处理。曾经有过因为审计日志收集了完整用户手机号最后被安全团队要求整改的教训。5. 完整链路演示一个“查订单”请求如何安全走完全程5.1 场景设定假设客服坐席小张登录AI客服助手输入“帮我查一下订单AB123456的物流”Agent需要调用order_query工具从订单MCP Server获取信息。安全要求是小张只能查自己负责的客户订单不能越权。调用链路涉及注册表选工具、Kong鉴权与限流、Peta策略判断、订单MCP Server执行业务。5.2 请求处理全流程整条链路的处理顺序大致如下用户输入自然语言Agent解析出意图为“查询订单”生成工具调用候选。Agent携带意图文本调用MCP注册表的搜索接口注册表返回order_query工具及其description、健康状态。Agent根据description选择order_query组装MCP请求把sessionId放在Cookie头里把订单号放进参数。Kong收到请求先校验身份凭证再检查路由级限流通过后触发Peta决策插件。插件把user_id、tool_id、order_id和调用上下文发给PetaPeta判断该用户是否有权查询该订单、当天配额是否耗尽。Peta返回allowKong把X-User-Id等信息注入请求头转发到订单MCP Server。MCP Server处理查询并返回结果Kong记录审计日志Agent把结果转成用户能看懂的话术返回。这中间sessionId的存在非常关键。小张连续追问多个问题时Agent需要通过sessionId从Redis恢复对话上下文而不是把上下文放在订单MCP Server的本地内存里。Kong的session affinity可以辅助路由但Redis才是兜底方案。5.3 关键的代码与配置示例把上面各层的核心配置和代码汇总起来就是一个可以直接抄作业的模板。注册表条目简化版{ tool_id: order.query, name: order_query, description: 按订单号查询订单详情适用于客服查询用户物流和状态。参数order_id, entrypoint: { protocol: mcp, url: https://mcp.internal.example/order/messages }, tags: [order, read-only], version: 1.4.2 }Kong的Service和Route配置前面已经给过这里重点看Peta决策插件的调用逻辑def on_http_request(ctx): user parse_jwt(ctx.request.headers[Authorization]) decision requests.post( http://peta:9000/v1/decide, json{ subject: user.sub, action: invoke, resource: ctx.request.path, parameters: ctx.ctx.params, request_id: ctx.request_id, }, timeout0.05, ).json() if decision[effect] ! allow: return kong.response.exit(403, { code: PETA_DENIED, reason: decision.get(reason) }) ctx.ctx.set_header(X-User-Id, user.sub)这里有一个实操细节插件里不能用Peta的返回结果去覆盖原始请求身份。即使Peta放行后端MCP Server也只能信任Kong注入的X-User-Id而不是信任请求里可能被伪造的user_id字段。网关侧需要在转发前把请求里的可疑身份字段清洗掉。5.4 参数计算限流、超时与配额怎么定参数不是拍脑袋定的要基于业务量估一个数。以订单查询场景为例假设客服团队200人每人每分钟最多发起5次Agent工具调用峰值就是1000 QPS。再考虑Agent内部可能有批量任务并发调用我们把Kong路由级限流设为1500 QPS留出50%余量。Peta的决策服务超时设为50毫秒MCP Server业务接口的SLA是3秒Kong给Agent的总体超时是5秒Agent侧工具调用的总超时是10秒。这么设计的原因是LLM的工具调用耐心极其有限超过10秒模型就会判定工具失败并开始写“抱歉暂时查询不到”。与其等一个慢吞吞的响应不如让系统在5秒内快速失败把“查询超时”这句话完整还给用户体验反而更稳定。配额计算则要在Peta层按用户维度做二次控制。普通坐席每天累计查询量上限300次批量任务每天上限1000次。这个值来自历史日志的P99分析如果某个用户日常调用量只到100次设300就是合理的。6. 常见问题与排查技巧实录6.1 高频问题速查表把我们在实际落地中遇到的高频问题整理成一张速查表排查时可以直接对照症状可能原因排查方向解决/预防Agent反复提示“找不到工具”注册表索引未刷新或description表述不匹配查看ES同步延迟检查注册表搜索日志给工具补充同义词标签缩短索引同步周期多实例部署后会话上下文丢失Session存在MCP Server本地内存检查日志里sessionId对应实例是否漂移会话上下文迁到Redis开启Kong粘性会话工具调用成功率低下游出现死锁MCP Server多线程并发更新同一订单记录看DB死锁日志和慢查询缩短事务时间订单更新增加乐观锁查到的订单状态与实际不一致多级缓存未失效订单状态版本未更新对比DB和缓存中的订单状态支付回调后主动失效缓存状态加版本号Agent请求量大时MCP Server被打满网关缺少限流和熔断Agent自动重试形成风暴查Kong access log中的5xx分布启用Kong rate-limitingPeta配额动态下调服务已下线网关仍往死实例转发注册表健康检查周期太长upstream缓存旧实例查看Kong upstream target状态缩短健康检查间隔开启passive健康检查无法定位谁调用了高敏工具审计只记了状态码没有主体和参数摘要检查审计平台日志完整性在Kong插件侧统一记录主体、工具、参数摘要、决策结果6.2 案例一工具超时背后的“版本漂移”有段时间order_query工具时不时超时大概一半请求会失败。起初怀疑是MCP Server性能问题看监控CPU和内存都正常。后来抓请求日志发现失败的请求都指向同一个旧实例而这个实例的TLS证书已经过期。为什么Agent会频繁选到旧实例因为注册表里同时存在两个order_query条目version分别是1.4.1和1.4.2都是online状态。而Agent在部分会话上下文中缓存了旧版本的信息直接绕过注册表查询流程发起了调用。网关按path路由到旧实例旧实例证书过期导致TLS握手卡住最终超时。解决方式是给注册表加了版本规则Agent默认只发现stable版本beta和旧版本不参与工具搜索同时给Kong的upstream配置了主动健康检查证书过期这类问题能在几次失败内自动摘除实例。踩过这次坑后我们对“下线工具”和“旧版本清理”的态度严格了很多宁可多一步人工确认也不能让Model带着旧地址到处跑。6.3 案例二策略引擎超时导致的连锁故障第二次教训来自Peta自己。刚开始接入Peta时我们把超时设得比较宽松觉得策略判断这种逻辑最多几毫秒结果某个下午订单服务慢查询Peta里一个条件需要实时查用户配额表查询变慢后Peta线程池被占满。Kong插件等不到Peta响应大量请求堆积在网关整个AI助手接口全部超时。这次故障让团队彻底认识到安全组件自身也需要治理。我们在Peta外层套了熔断器Peta连续失败超过阈值后直接跳闸后续请求走fallback策略而不是无限等待。同时把Peta的依赖降级为本地缓存加异步刷新配额数据提前加载到内存决策时不再实时查询数据库。经过优化后Peta的P99延迟稳定在10毫秒左右。6.4 案例三订单状态过期与多级缓存不一致Agent场景里也有“订单过期了怎么办”这类经典问题。比如用户下单后订单服务写库并更新Redis但支付回调处理异常导致缓存里的状态还是“待支付”Agent查询时返回给用户一个已经过期的信息。用户满心欢喜以为支付成功了结果发现没付款成功体验极差。排查时先看缓存和数据库的订单状态是否一致再看支付回调日志是不是被MCP Server的限流挡掉了。最后我们定了两条规矩一是所有订单状态变更必须主动失效缓存下一次查询强制回源数据库二是订单状态带版本号Agent读取到旧版本时会自动触发一次刷新而不是直接返回。这套逻辑和传统接口的缓存一致性治理完全一样只是在AI链路里多了一个“模型可能把旧数据当成最终结果”的副作用所以更需要谨慎。7. 落地顺序与个人体会如果团队还没开始做这件事我建议不要一上来就把三个组件全部铺开步子太大容易扯到蛋。先花一周把现有工具清理成一份字段规范的清单哪怕先用Excel记录也比没有元数据强。第二步把所有Agent调用都切到Kong网关先把统一入口立住。第三步再挑一个只读的敏感工具接入Peta做策略阻断跑通后再逐步扩展到写操作和高危工具。我在实际操作中最深的一点体会是真正决定这套架构上限的不是Kong也不是Peta而是注册表里的元数据模型。description写得好不好tags标得准不准read_only标记对不对直接决定了Agent能不能选对工具、Peta能不能定出合理策略。工具少的时候可以靠人肉维护工具多了以后元数据质量就是整个系统安全与效率的基石。最后再分享一个小细节策略即代码的理念一定要坚持。Peta里的每一条策略都放进Git仓库走评审和测试流程不要让人直接在线上改配置。我们曾经为了图方便手动改过一条策略结果忘了备份后来想回滚只能靠记忆。过程非常痛苦。现在所有策略变更都走CI十秒钟就能恢复到一个历史版本。安全策略本身也需要用工程化的方式去保护。