一、在 AI 驱动应用中，把智能 Agent 与工具/数据可靠且安全地连接起来，是关键挑战
在 AI 驱动的应用世界里，把智能 Agent 与工具和数据可靠、安全地连接起来，是一个关键挑战。两种新兴方案分别从这个问题的不同侧面切入：Kong MCP Registry 侧重于 AI 工具的服务注册与发现，而 Peta 则在这些工具被实际使用时提供运行时控制、可观测性与安全能力。本文将介绍并分析 Kong MCP Registry 在基于 Model Context Protocol（MCP）的架构中的角色，并与 Peta 的运行时治理方式进行对比。理解二者之后，我们会看到它们如何互补，从而支持可扩展、安全的 Agent 系统。

二、MCP 架构中的服务注册与发现
现代微服务架构长期以来依赖服务注册表与服务发现机制，把客户端与服务连接起来。类似地，AI Agent 也需要一种方式，去找到并访问提供外部上下文或动作的 MCP Server（工具 API）。MCP——由 Anthropic 于 2024 年末提出的开放标准——定义了一种通用接口，让 AI 模型可以接入数据库、API、文件系统以及其他服务。它经常被形容为 AI 应用的“USB-C 接口”——一个统一、标准化的协议，使任何 AI 助手都能在无需定制集成的情况下连接任何工具。MCP 的客户端—服务器设计意味着：每个 MCP Server 在统一的、基于 JSON 的接口背后提供一组特定能力（例如文件操作、邮件 API、数据库查询）。但 Agent 如何知道有哪些服务器可用？

在早期阶段，开发者会硬编码工具连接，或手动为 Agent 配置 MCP Server 的端点。这种直连方式适合小规模实验，但无法扩展。一旦 API 端点变化，就必须更新每个 Agent 的配置；新增工具也需要改代码。MCP 本身通过握手机制提供了部分解决方案：一个知道服务器地址的 Agent 可以连接上去，而服务器会在 “list tools” 响应中公布其所有可用工具。这个标准的 MCP 客户端—服务器发现流程，使 Agent 无需提前知道每个工具的细节——它只要知道服务器 URL，就能获得能力菜单。但仍然存在一个关键限制：Agent 依然必须事先知道每个服务器及其地址。跨多个 MCP Server 没有一个全局目录或搜索能力。

服务注册表正是用来填补这个空缺的，它相当于 MCP 的“黄页”。与其把服务器端点散落在配置或代码中，不如用一个集中式注册表让多个 Agent 动态发现多个服务器。一个 MCP Registry 本质上是一个目录：MCP Server 在其中注册自己的能力与端点，Agent 可以在运行时查询或搜索所需工具。这种企业级的发现机制使组织能够在不依赖脆弱的手动配置的情况下，在全公司范围内扩展 AI Agent 工具使用。官方 MCP 社区甚至已经推出了一个开放 MCP Registry，作为公开可用服务器的主要事实来源。然而，企业通常需要私有或定制的子注册表，以纳入内部工具并执行内部治理。这正是 Kong 方案进入的地方。

三、Kong MCP Registry：面向 AI 工具的统一目录
Kong MCP Registry 是 Kong Konnect（Kong 的 API 与连接平台）中的一项新能力，用作 AI Agent 发现 MCP 兼容服务与工具的中心目录。从本质上看，它同时扮演了面向 AI/MCP 的 Service Catalog 和 Developer Portal。Registry 为每个工具提供丰富元数据、API 端点和能力定义，描述 AI Agent（通常是大语言模型）应如何调用该服务。例如，Registry 中的一条记录可能代表一个内部数据库查询工具或第三方 SaaS 集成，并附带 Agent 调用它所需的 JSON Schema 或 API 规范。AI Agent 通过在运行时查询 Registry，就可以动态找到合适工具来完成任务，而不必依赖硬编码知识。

Kong 的方法将 AI 工具目录与其既有 API 管理生态紧密结合。按 Kong 的说法，MCP Registry 作为 Kong Konnect Service Catalog 的扩展来构建，而后者本就是企业 API 的系统记录（system of record）。这一架构选择意味着：MCP Server 与传统 REST/GraphQL 服务一样，被视为一等公民。组织不仅能在一个地方列出所有经批准的 AI 工具，每个 MCP Service 条目还可以关联到底层 API 依赖、所有权信息以及来自 API 世界的治理策略。换句话说，如果某个 MCP Server 封装了一组内部 API，Registry 可以将它们关联起来，让运维方能看到 AI 工具与既有基础设施之间的关系。Kong 平台因此让企业能以与关键 API 同样的严谨度和上下文来管理 AI 服务。相较于一个独立的注册表，这带来显著增值：更深的可见性（工具如何构建、影响范围“blast radius”）、统一访问控制，以及继承自 API 治理框架的一致策略执行。

四、面向发现与治理的能力侧重
Kong MCP Registry 的核心关注点，是让 AI 工具的发现更容易、更安全、且可治理。借助它，Kong Konnect 变成一个统一平台：API 与 AI 工具都能在同一目录中被编目与控制。主要能力与收益包括：

1、动态、自助式发现
MCP Server 会在中心 Konnect Catalog 中注册自身及其能力。AI Agent 随后可以在运行时查询 Registry 来找到可用工具，而无需硬编码地址。这加速了开发：团队新增 MCP Service 后，Agent 可以自动“看到”并使用。Kong 还提供 MCP Server Generator，用来从既有 API 定义自动生成并填充 Registry，从而用最小成本启动目录建设。

2、仅限已批准工具
Kong MCP Registry 被设计为“受授权的目录”——只有经过审查和批准的 MCP Server 才会被列出供发现。这确保 AI Agent 不会偶然发现流氓或未经审查的工具。每个条目可携带诸如 owner、版本、合规标签等元数据，管理员可以控制哪些客户端或团队能看到哪些工具。通过与企业认证集成（Kong 平台支持 RBAC 和个人访问 token），Registry 甚至可以按权限过滤返回结果，使 Agent 只看到被允许使用的工具。

3、企业治理与标准
Kong MCP Registry 旨在符合新兴行业标准，以支持 AI Agent 互操作性。它遵循 Agentic AI Alliance 的 AAIF 标准（面向 MCP），确保与更广泛的 MCP 生态以及围绕开放规范构建的工具兼容。这种对开放标准的对齐意味着企业可以在不担心锁定的情况下采用 Kong Registry——它能与官方 MCP Registry 及其他子注册表协作。Kong 还计划与其 Developer Portal 打通，让内部开发者像发现 REST API 一样发现 AI 工具与文档。

4、可观测性与审计线索
虽然主要是发现服务，Kong 的 Registry 也通过集中使用数据来辅助可观测性。它会跟踪工具被谁使用、使用频率等信息。这些洞察有助于监测健康与成本：例如发现某个 MCP Server 很少被用（可能可以下线），或识别某个工具调用经常失败。Kong 还提到其平台可以监测“context bloat”（当 Agent 使用工具导致上下文尺寸或成本过高），从而优化 LLM 使用。此外，统一 Registry 及其审计日志也能支持合规：企业可以向监管展示已批准 AI 工具清单与使用审计线索，以满足 GDPR、HIPAA 或 EU AI Act 等要求。

总之，Kong MCP Registry 把 AI Agent 的服务发现从分散、手工的工作，变成集中、可治理的服务。它在接入 MCP 生态的同时利用 Kong 成熟的 API 管理基础，确保 AI Agent 可以在企业护栏内安全地、规模化地发现并使用正确工具。这解决了企业 AI 的“Day 2”问题：超越原型之后，你需要可靠方式来管理几十个 Agent 工具、保持安全、并理解其使用方式。Kong 的重点明确落在 Registry 与发现层：让 Agent 在企业 IT 护栏内尽可能容易地找到所需服务。

五、Kong 方法的架构选择与生态价值
Kong 的 MCP Registry 实现包含一些刻意的架构选择，从而提升其在 AI 生态中的价值。首先，它建立在 Kong Konnect 之上，因此不是一个孤立的“目录孤岛”，而是更广泛连接平台的一部分。这意味着已经用 Kong 做 API Gateway、Service Mesh 或 API Catalog 的组织，可以把同样的工作流扩展到 AI Agent。将 API 与 AI 服务管理统一，是一个战略选择：它把 AI 工具纳入 API 项目多年打磨出的设计、编目、治理与监控生命周期之中。对大型企业而言，这避免了为“AI 相关工作”建立一套平行流程——AI 端点与 REST 端点一起被管理，并共享治理机制。

另一个显著选择是对开放标准的合规。Kong MCP Registry 与 AAIF MCP 标准对齐，该标准由 Linux Foundation 的 Agentic AI 计划推动，并由行业参与者支持以实现互操作。通过支持 AAIF 与官方 MCP Schema，Kong 确保其 Registry 条目可与其他 MCP 客户端与注册表互操作。在快速演进的 AI 工具生态里，这一点很重要——它避免碎片化。AI Agent 可以把 Kong Registry 作为工具事实来源，而不需要 Kong 专用客户端；交互通过标准 MCP 协议与数据模型完成。Kong 实际上是在围绕开放标准提供企业级基础设施，从而推动 MCP 生态增长，而不是创建一个专有替代方案。

此外，Kong 的 Registry 也并非只是被动列表，它位于更完整的 AI 连接架构之中。Kong Inc. 已推出 AI Gateway 等组件来处理 AI 相关流量。实际落地中，Kong MCP Registry 可以与 Kong AI Gateway 协同：Registry 告诉 Agent 有哪些服务存在；Gateway 则通过安全、可管理的层把调用路由到这些服务。把发现与网关执行连接起来，Kong 提供了端到端方案——发现、路由、认证、治理协同工作。这种协同效应是 Kong 所说的从“碎片化 AI 实验”走向“可投入生产、可治理的 AI 系统”的路径。生态价值在于：企业获得一个平台来处理从 LLM 连接工具、对连接执行策略、监控使用，甚至（如需要）对 API/工具进行商业化等全链路能力。

Kong 的重点仍然是 Registry 与发现。它提供目录与“发现阶段”的治理：让 Agent 找到并获得访问许可。一旦 Agent 通过 Kong MCP Registry 发现了目标 MCP Server，它就会发起连接（通常经由 Kong AI Gateway 或直接通过 MCP）。此时另一类挑战出现：确保实际工具调用在运行时是安全、可审计、可控的。对于这部分问题，我们转向 Peta。

六、Peta：运行时的可观测性、策略执行与安全
如果 Kong MCP Registry 回答的是“如何找到正确的 AI 工具或服务？”，那么 Peta 回答的就是后续问题：“工具找到了之后，运行时是谁在什么条件下调用了什么？”Peta 专注于 MCP 交互的运行时控制平面（runtime control plane）。换句话说，Peta 在“发现结束之后”接管：当 AI Agent 真正调用 MCP Server 时，Peta 确保调用以安全、可监控、可治理的方式执行。

（Peta 界面截图说明：展示用于 MCP 的安全运行时控制。Peta 作为网关，所有 AI 工具调用都会被认证、记录，并受策略约束。）

Kong 让 Agent 更容易发现 MCP Server，而 Peta 管理“发现之后发生的事”。Peta 的设计承认：缺少控制层时，让 AI Agent 调用工具会变成黑箱——你可能不知道哪个 Agent 何时、为何使用了哪个工具。早期的 Agent 部署常见问题之一就是缺少遥测与请求历史，导致无法追踪行为或调试。Peta 通过在运行时插入治理层来解决：它作为 MCP Gateway（类似 API Gateway 但面向 AI），位于 AI 客户端与 MCP Server 之间，调解每一次交互。

七、面向 MCP 的运行时控制平面
Peta 的核心提供一个受管 MCP Runtime 和一个零信任网关。与其让 Agent 直接连接每个 MCP Server，不如让 Agent 连接 Peta。Peta 的网关在执行检查后再路由或拉起对应 MCP Server，从而带来多重收益：

1、身份与访问控制执行
每个来自 AI Agent 的调用都携带身份（哪个 Agent/哪个用户），并在到达工具之前对照策略检查。Peta 验证 Agent 凭证，确保其被授权执行特定工具与动作；未知 Agent 或不允许动作会在网关层被拦截。这避免了例如实验性 Agent 意外访问生产数据库工具的情况。权限粒度甚至可以细到“Agent X 可以调用 Tool Y，但只能读不能写”。

2、安全凭证管理
Peta 常被称为“AI Agent 的 1Password”，强调其 secret 管理。它不会把原始 API Key 或数据库密码直接给 AI Agent（否则可能泄露到日志或模型上下文）。Peta 把所有敏感凭证存放在服务端加密 Vault 中。Agent 使用短期 token 向 Peta 认证，而不是使用真实 secret。一旦请求通过审批，Peta 会在恰当时间把所需凭证注入对 MCP Server 的调用中，而 AI Agent 永远看不到真实 secret。这种“零 secret 暴露”模型显著降低风险——即使 AI 模型泄露全部记忆，其中也不会有真实密码或 Key，只有在 Peta 语境外无效的短期 token。

3、审计线索与可观测性
Peta 会记录所有经过它的工具调用，形成完整审计线索。例如 Agent 通过 MCP 工具查询客户数据库时，Peta 的日志会记录哪个 Agent 在什么时间以什么参数调用、结果如何。这对可追溯性非常关键：让团队能回答“谁在运行时调用了什么”。在实践中，这意味着更快调试、更容易做根因分析，也能支持合规提问，如“上周哪些 Agent 访问了这份敏感报告？”Peta 的集中日志还能集成到 SIEM，或用于证明合规（平台也会强调 SOC2-ready、HIPAA/GDPR 友好等）。

4、基于策略的控制与审批
Peta 内建策略引擎，不仅能执行复杂规则，还能对高风险动作引入人工审批。例如配置：当 AI Agent 尝试删除记录或通过 MCP 工具执行转账时，必须由人工审批后才能执行。Peta 提供开箱即用的细粒度策略与审批工作流：管理员可以设置哪些 Agent 在哪些环境（dev/staging/prod）可访问哪些工具，并标记某些操作需要人工批准。Peta Desk 提供专门界面供人工审核者实时批准/拒绝，并可通过 Slack/Teams 集成快速处理，不打断工作流。

5、受管 MCP Server 运维
Peta 不仅“管调用的安全”，也简化运行 MCP Server 的运维。在朴素方案中，每个 Agent 可能为某个工具各自拉起 MCP Server 进程，造成“server sprawl”和低效。Peta 管理 MCP Server 生命周期：需要时懒启动（lazy start）、负载上升时对实例池自动扩容、崩溃时自动重启/恢复。开发者不用“盯着”多个工具进程，可靠性更高。Agent 只管调用工具，Peta 保证对应 Server 存活且健康。这也通过连接池与复用避免频繁启动/停止带来的性能损耗。

八、Kong 与 Peta：在 MCP 生态中的互补角色
需要强调的是：Kong MCP Registry 与 Peta 是互补关系，而非竞争关系。它们覆盖 MCP 架构中的不同层：

1、Kong MCP Registry：发现与目录级治理
它擅长让 AI Agent 找到正确工具，并确保该工具是经过批准、有文档、可治理的服务。它为 Agent 提供可信的“电话簿”，并保证 Agent 只能看到符合组织标准的工具。这发生在 Agent 实际调用工具之前。

2、Peta：运行时控制、可观测性与安全
它不负责让 Agent 决定用哪个工具（那是 Registry 的工作）；它负责当 Agent 说“现在要调用 Tool X”时，确保调用安全且可追踪：检查授权、隐藏凭证、按策略放行或转审批、并记录全过程。

在实践中，组织可能会同时使用两者：用 Kong MCP Registry 维护一份经过筛选的内部与第三方 MCP Server 目录；再用 Peta 把所有实际交互汇入一个安全网关。在某种意义上，Kong 自身也会建议把 Registry 与其 AI Gateway 配合使用，以执行安全与采集遥测；而 Peta 可以被视为在该“网关层”提供更聚焦零信任与细粒度审计的专门方案。

通过把强发现机制（Kong MCP Registry）与强运行时控制平面（Peta 或类似 MCP Gateway）结合，企业就获得了 AI Agent—工具交互的端到端治理：Kong 确保 Agent 只看到并使用经批准工具，并让新工具能在组织内部更容易被发现与复用；Peta 确保工具一旦进入运行阶段，每个动作都有据可查、策略可执行、secret 可保护，从而回应安全团队与监管对“自治 Agent 拥有系统访问能力”的顾虑。

九、结论
Agentic AI 的兴起与 MCP 的采用，使服务注册表与网关成为 AI 基础设施的关键组件。Kong MCP Registry 代表了“服务发现”这一半：它提供可扩展、集中式方式，让 AI Agent 找到所需工具，并满足企业对治理与上下文的要求。通过把 Registry 嵌入既有 API 管理平台，Kong 复用成熟实践，并将 AI 工具与更广泛 IT 生态连接起来——这一架构选择在真实部署中带来显著价值。

另一方面，Peta 解决了工具进入运行时之后的控制与安全难题。它把零信任、细粒度策略执行与全栈可观测性带入 AI Agent 领域，让原本可能不透明、风险更高的 AI 操作变成透明且可控的流程：每个调用可追踪、每个 Agent 的权限可严格约束、secret 不会通过对话记忆泄露。

总之，当组织规模化使用 AI Agent 时，“发现”与“运行时治理”都不可或缺。Kong MCP Registry 与 Peta 分别从不同角度满足这些需求。它们共同展示了企业 AI 生态如何演进：借鉴并扩展传统服务架构概念（注册表、网关、审计日志）以适配 AI 驱动的自治动作世界。这样的平衡路径让企业能够更有信心地拥抱强大 AI 工具——从实验性试点走向既创新又可信的生产系统。