上个月帮业务团队收拾一个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注册表 | 服务发现与元数据层 | 工具注册、描述管理、健康检查、版本与标签、按语义搜索 |
| Kong | API网关与流量治理层 | 统一入口、路由转发、身份校验、限流熔断、审计日志 |
| 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. Kong：MCP流量的统一入口与治理
3.1 网关层到底解决了哪些单点拦截问题
在引入Kong之前，每个MCP Server都要在自己的代码里实现鉴权、审计和限流。这些逻辑散落各处，重复不说，还经常漏。比如订单查询服务校验了JWT，库存查询服务却只校验了一个写死的Token；有的服务有审计日志，有的服务连访问记录都不留。出安全问题后想定位“谁在什么时候用哪个工具查了哪些数据”，根本无从下手。
Kong把所有Agent调用统一收口后，单点拦截就变成了现实。身份认证、限流、熔断、审计、协议转换全部放到网关层，MCP Server不再关心“谁在调”，只关心“业务逻辑怎么处理”。团队新上一个工具时，接入Kong后自动获得整套治理能力，不需要再重复写一遍安全代码。
当然，网关层只解决了“入口统一”的问题，细粒度的权限判断还需要交给Peta做。我的经验是：网关管“你是谁、能不能进、进来多少流量”，策略引擎管“你进来了能不能干这件事”，两者配合才能兼顾效率和安全。
3.2 路由模型：把MCP工具映射成Kong Service/Route
Kong的配置模型是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按consumer+route做限流，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 嵌入调用链的两种姿势：网关插件与Sidecar
Peta的接入方式直接决定了它能拦截到什么程度。我最推荐的方式是做成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和调用上下文发给Peta，Peta判断该用户是否有权查询该订单、当天配额是否耗尽。
- Peta返回allow，Kong把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, }, timeout=0.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-limiting，Peta配额动态下调 |
| 服务已下线，网关仍往死实例转发 | 注册表健康检查周期太长，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，十秒钟就能恢复到一个历史版本。安全策略本身，也需要用工程化的方式去保护。
