Kong MCP注册表与Peta：在人工智能系统中连接服务发现与运行时安全

1. 为什么 MCP 服务一多Agent 就开始“找不到北”如果你正在把 AI Agent 接进公司内部系统大概率会遇到这样一个阶段一开始只接一两个 MCP Server硬编码地址就能跑等到工具涨到十几个每个 Agent 的配置文件里都散落着不同的 endpoint改一个地址要翻五六个仓库某个工具下线了没人知道某个实验性 Agent 悄悄连上了生产库也没人发现。这就是 MCP 服务发现和运行时安全同时失控的典型症状。Model Context ProtocolMCP解决的是“AI 模型怎么用统一接口调工具”的问题它像 AI 应用的 USB-C让任何助手都能接数据库、API、文件系统。但 MCP 本身只定义了客户端和服务器之间的握手与工具列表它没有回答两个更工程化的问题第一Agent 怎么知道当前有哪些 MCP Server 可用、哪个是经过批准的第二Agent 真正发起调用时谁在什么条件下调用了什么凭证有没有暴露高风险动作要不要拦。Kong MCP Registry 和 Peta 正好从这两侧切入。前者是面向 AI 工具的集中式目录让 MCP Server 注册自己的能力与端点Agent 在运行时查询发现后者是 MCP 交互的运行时控制平面在调用真正到达工具之前做身份校验、凭证托管、策略执行和审计记录。这篇内容面向需要统一管理 MCP 服务注册、发现与安全策略的开发者我会给出一套可以在本地或测试环境跑通的注册表配置骨架、Peta 策略接入步骤和验证动作帮你把“发现”和“运行时安全”这两段接起来。需要先说明的是下面所有配置都以测试环境为目标生产落地时你要根据自己的网络、认证体系和合规要求做替换。另外如果你在接入过程中需要统一管理模型调用凭证可以顺带了解 TaoToken 的 API Keys 管理方式它和 MCP 的凭证托管是两件不同层面的事但思路可以互相参照。2. 前置准备TaoToken 与 MCP 工具链的定位在动手写注册表配置之前先把几个概念和前置条件理清楚不然后面容易混。MCP Server 是实际提供工具能力的一方比如一个封装了内部订单查询 API 的 Server它会在list tools响应里公布自己能做什么。MCP Client 通常是 AI Agent 或宿主应用它需要知道 Server 的地址才能连接。Kong MCP Registry 扮演的是“黄页”角色Server 把能力和端点注册进去Client 在运行时查询 Registry 来发现可用工具而不是把地址写死在代码里。Peta 则位于 Client 和 Server 之间作为 MCP Gateway 调解每一次交互。如果你在测试环境里还没有稳定的模型调用入口可以先用 TaoToken 的模型对话能力验证 Agent 侧的连通性它的接入文档里有标准的请求示例。这一步不是必须的但能让你的验证链路更完整Agent 能正常对话再去接 MCP 工具问题定位会清晰很多。前置条件清单如下你可以对照检查一个可运行的 MCP Server至少暴露一个工具本地用 stdio 或 HTTP 传输都可以Kong Konnect 测试实例或者本地可用的 Registry 兼容服务Peta 测试账号或本地部署实例用于运行时策略验证一个能发起 MCP 调用的客户端比如支持 MCP 的 Agent 框架或命令行工具如果涉及模型调用准备好 TaoToken 的 API Key放在环境变量里不要写进代码。注意测试环境里也尽量不要把真实生产凭证直接交给 Agent。Peta 的零信任模型核心就是让 Agent 拿短期 token真实 secret 存在服务端 Vault 里。这个习惯从测试阶段就养成后面迁移会省很多事。3. 可复制配置Kong MCP Registry 注册骨架这一节给出注册表配置的骨架。不同版本的 Kong Konnect 和 MCP Registry 实现字段名可能有差异你要以自己环境的 schema 为准但整体结构是通用的一个 MCP Service 条目包含标识、端点、能力定义、所有权和治理标签。先看一个最小可用的注册条目用 YAML 表示mcp_service: name: order-query-tool version: 1.0.0 description: 内部订单查询 MCP Server提供只读订单状态查询 transport: http endpoint: http://127.0.0.1:8081/mcp owner: team: platform-ai contact: ai-platformexample.com capabilities: - name: query_order_status description: 根据订单号查询当前状态 input_schema: type: object properties: order_id: type: string required: [order_id] governance: approved: true environment: test compliance_tags: [internal-only]这个条目的关键点在于capabilities里的input_schema它描述 Agent 应该怎么调用这个工具。Registry 不只是存地址它还要让 Agent 知道参数结构所以 schema 要写清楚。governance.approved标记这个工具是否经过审查只有 approved 为 true 的条目才会被 Agent 发现这是“仅限已批准工具”的基础。接下来是注册动作。如果你用的是 Kong Konnect 的 API可以用类似下面的请求把条目推上去curl -X POST https://your-konnect-host/v1/mcp-services \ -H Authorization: Bearer $KONNECT_TOKEN \ -H Content-Type: application/json \ -d mcp-service.json对应的mcp-service.json就是把上面的 YAML 转成 JSON。执行成功后会返回条目 ID记下来后面验证发现流程要用。如果你希望从既有 API 定义自动生成注册条目Kong 提供了 MCP Server Generator 的思路把 OpenAPI 规范喂进去生成对应的 MCP Service 条目。测试阶段你可以先手工写一条确认流程通了再考虑自动化。Peta 侧的接入是另一段配置。Peta 作为 MCP Gateway需要知道它要代理哪些 MCP Server。一个简化的策略配置骨架如下peta_gateway: upstreams: - name: order-query-tool endpoint: http://127.0.0.1:8081/mcp policies: - name: allow-read-only match: tool: query_order_status effect: allow conditions: agent_role: reader - name: require-approval-for-write match: tool: * action: write effect: require_approval credentials: vault_ref: vault://mcp/order-query token_ttl_seconds: 300这段配置做了三件事声明上游 MCP Server、定义策略只读放行、写操作需要人工审批、把真实凭证放进 Vault 并设置短期 token 有效期。Agent 连接的是 Peta 的地址不是直接连 MCP Server这样每次调用都会经过策略检查。提示token_ttl_seconds不要设太长测试环境 300 秒足够。短期 token 即使泄露离开 Peta 语境也很快失效这是零信任模型的关键。4. 验证请求确认发现与运行时安全都生效配置写完不算完要验证两件事Agent 能不能通过 Registry 发现工具以及调用经过 Peta 时策略有没有生效。先验证发现流程。用一个 MCP 客户端查询 Registry看返回的工具列表里有没有你注册的条目curl -X GET https://your-konnect-host/v1/mcp-services?approvedtrue \ -H Authorization: Bearer $KONNECT_TOKEN预期结果是返回一个列表包含order-query-tool并且capabilities里有query_order_status。如果列表为空先检查approved字段和认证 token 的权限范围。再验证运行时调用。让 Agent 通过 Peta 的地址发起一次工具调用curl -X POST http://127.0.0.1:9090/mcp \ -H Authorization: Bearer $PETA_AGENT_TOKEN \ -H Content-Type: application/json \ -d { tool: query_order_status, arguments: {order_id: TEST-1001} }如果策略配置正确这次调用应该成功返回订单状态同时 Peta 的日志里会记录一条审计条目哪个 Agent、什么时间、调用了哪个工具、参数是什么、结果如何。你可以去 Peta 的控制台确认这条记录存在。然后测试策略拦截。把请求里的工具换成一个写操作或者用一个没有reader角色的 Agent token 发起调用curl -X POST http://127.0.0.1:9090/mcp \ -H Authorization: Bearer $PETA_UNAUTHORIZED_TOKEN \ -H Content-Type: application/json \ -d { tool: query_order_status, arguments: {order_id: TEST-1001} }预期结果是返回拒绝或需要审批的响应而不是直接执行。如果它仍然成功说明策略匹配规则没生效回去检查match条件和 Agent 角色映射。最后确认凭证没有暴露。在 Peta 的审计日志里你应该看不到真实的 API Key 或数据库密码只能看到短期 token 的标识。如果你在日志里看到了真实 secret说明凭证注入环节配置有问题需要检查 Vault 引用是否正确。5. 本篇常见错排查接入过程中有几类错误出现频率很高我按现象、原因、处理方式列出来方便你对照。现象一Agent 查询 Registry 返回空列表。最常见原因是注册条目的approved字段为 false或者查询时带了approvedtrue过滤但条目没标记。另一个原因是认证 token 的 RBAC 权限不够看不到该条目。处理方式是先去掉过滤条件查全量确认条目存在再检查 token 权限。现象二调用返回 401 或 403。这通常是 Peta 侧的身份校验没过。检查 Agent token 是否有效、是否过期以及策略里agent_role和 token 携带的角色是否匹配。如果用的是短期 token注意token_ttl_seconds到期后需要重新获取。现象三策略配置了 require_approval 但调用直接执行了。这多半是match规则写得太窄或太宽。比如action: write需要 MCP Server 在工具定义里正确标注了 action 类型如果 Server 没标注Peta 无法识别策略就不会触发。处理方式是先在 Peta 日志里确认这次调用被识别成了什么 action再调整匹配规则。现象四审计日志里出现真实凭证。这说明凭证注入没有走 Vault而是把原始 secret 传给了 Agent。检查 Peta 的credentials.vault_ref是否指向了正确的 Vault 路径以及 MCP Server 是否被配置为从 Peta 注入的短期 token 换取真实凭证而不是直接接收 secret。现象五MCP Server 频繁重启或响应慢。如果每个 Agent 各自拉起 Server 进程会出现 server sprawl。Peta 的受管 MCP Server 运维可以懒启动、连接池复用、自动扩容。检查你是否让 Agent 直连了 Server 而不是经过 Peta直连会绕过这些运维能力。注意排障时优先看 Peta 的审计日志和 Kong Registry 的条目状态这两个地方能覆盖大部分问题。不要一上来就改代码。6. 把发现和运行时安全接起来之后走到这里你应该已经在测试环境里跑通了这样一条链路MCP Server 注册到 Kong MCP RegistryAgent 通过 Registry 发现经过批准的工具调用经过 Peta 网关时完成身份校验、凭证托管、策略执行和审计记录。Kong 负责“让 Agent 找到正确工具”Peta 负责“让调用安全可追踪”两者互补覆盖了 MCP 架构里发现和运行时治理两段。如果你后续要把这套链路接到真实的模型调用上Agent 侧的凭证管理可以单独用 TaoToken 的 API Keys 来管和 Peta 的 MCP 凭证托管分开职责更清晰。长期做编码类 Agent 的话Coding Plan 那种按周期管理额度的方式也值得了解一下避免测试阶段就把额度跑超。最后留一个实用建议测试环境里先把approved和策略审批流程跑顺再考虑批量导入工具。很多团队一上来就注册几十个 MCP Server结果策略没配好审计日志一团乱反而更难排查。先跑通一条再复制比一次铺开稳得多。