Agent Registry 目前在五个 AWS 区域开放预览，包括美东（弗吉尼亚北部）、美西（俄勒冈）、亚太（悉尼）、亚太（东京）和欧洲（爱尔兰）。如果你的组织已经在为 Agent 治理头疼，无论选 AWS 还是 Nacos，现在都到了该认真评估的时候。​

企业里的 AI Agent 数量正在悄悄失控。

没人说得清究竟有多少个 Agent 在跑、谁是 Owner、是不是合规、有没有重复造轮子。隔壁组刚上线的工具，可能正是你这周准备开发的功能。

Agent 越多，盘子越乱，治理债越积越厚。

为了应对这个局面，AWS 在四月推出了 Agent Registry 公测版本，作为 Amazon Bedrock AgentCore 的一部分，给企业提供一个集中式的目录，用于发现、共享和治理组织内的 AI Agent、Tool、MCP Server 和 Agent Skill。无论这些资产跑在 AWS 上、其他云上，还是在自建机房里，都可以纳入索引。

Agent 蔓延，是个绕不开的问题

任何观察过组织内 Agent 数量增长的平台团队，应该对这种局面都不陌生：没人知道有什么、属于谁、是否经过审批、是否有人已经做过同样的事。Agent 数量一旦失控，蔓延速度极快。合规缺口随之而来，研发资源被消耗在重复劳动上。

Southwest Airlines 的 AI 与智能平台副总裁 Justin Bundick 在发布通稿中谈到了这一痛点：

AgentCore 中的 AWS Agent Registry 解决的是关键的可发现性问题，让团队能够找到并复用已有的 Agent，而不是从零重建能力。通过跨平台的统一治理，每一个 Agent 都带着标准化的归属元数据，并接受策略约束。

早期采用者 Zuora 是另一个例子。

这家公司在销售、财务、产品和研发团队中部署了 50 个 Agent。其首席产品与技术官 Pete Hirsch 表示，注册中心给首席架构师们提供了统一视图，能够发现、管理和编目所有正在使用的 Agent、Tool 和 Skill，并通过标准化元数据保证归属信息和能力描述在整个生态中保持一致。

AWS Agent Registry 怎么用

注册一条记录有两种方式。团队可以通过 Console、SDK 或 API 手动填写元数据，指定 Owner、能力描述和合规状态。也可以直接指向一个 MCP 或 A2A 端点，让注册中心自动抓取详细信息。每条记录都会捕获发布者、所遵循的协议、暴露了什么、以及如何调用。

在搜索这件事上，AWS 用的是关键词加语义混合检索。搜索"payment processing"时，被打成"billing"或"invoicing"标签的工具也能被找到，名字不一样也无所谓。

注册中心本身既能通过 AgentCore Console 和 API 访问，也能作为 MCP Server 暴露出去——任何兼容 MCP 的客户端，包括 Kiro 和 Claude Code，都可以直接查询。对于使用自定义身份系统的组织，还可以走 OAuth 鉴权，自建发现界面而不必依赖 IAM 凭证。

治理这一面，记录会走一套审批流。从 Draft 起步，进入 Pending Approval，审批通过后才会变成可被发现的状态。管理员通过 IAM 策略控制谁能注册、谁能发现。版本管理记录变更历史，不再使用的记录可以下线。自定义元数据字段允许团队挂上成本中心、部署环境、安全分级等业务信息。

实测中的几处粗糙边

解决方案架构师 Shinya Tahara 把 Agent Registry 拿来动手测了一遍，发现了几个值得提前知道的细节。

语义搜索在英文查询下表现良好，但用日文查询英文元数据时表现不佳——三个日文测试问题里有一个返回零结果。补充双语描述可以解决这个问题，这对计划全球化推广的组织是个有用的提醒。

Tahara 还发现，把过滤条件混在自然语言查询里会显著降低精度，可能返回所有注册记录而不是预期目标。

另外，任何记录的更新都会把状态重置为 DRAFT，意味着重新提交、重新审批。Agent 更新频繁的团队需要把这层摩擦提前考虑进工作流。

不止 AWS：Agent 注册中心赛道挤满了玩家

AWS 不是唯一一家做 Agent 注册中心的超大规模厂商。

微软有 Entra Agent Registry 和 Azure Agent Registry，谷歌云也有自己的 Agent Registry，协议层面还有 Agent Client Protocol（ACP）Registry 之类的努力。AWS 的差异化在于提供商无关的索引能力，叠加对 MCP 和 A2A 两种协议的原生支持，让它有能力编目 AWS 生态外构建的 Agent。

而在国内开源社区，这件事的解题思路并不一样。阿里开源的 Nacos 3.0 在 2025 年发布了 MCP Registry，把传统的微服务注册中心升级成了面向 AI 应用的服务注册与发现平台。两者解决的是相似的问题，但路径差异明显。

对比一下：AWS Agent Registry vs Nacos AI Registry

两边解的是同一个问题——Agent 蔓延和治理缺失，但路径差别很大。先用一张表把核心维度的差异拉出来：

对比维度	AWS Agent Registry	Nacos AI Registry（3.0）
产品定位	云厂商托管的企业 SaaS 治理产品	开源中间件，可自部署
注册方式	两种：Console/SDK/API 手动填写；指向 MCP/A2A 端点自动抓取	三种：业务 API 零代码转 MCP；新 MCP Server 直接注册；存量 MCP Server 代理
协议支持	原生支持 MCP + A2A	以 MCP 为主，配合 Higress 网关做协议转换
搜索能力	关键词 + 语义混合检索，偏目录式发现	Nacos-MCP-Router 语义搜索，带自动安装/注册，偏路由式分发
动态管理	版本化、审批状态机，更新会触发重新审批	工具描述热更新、Tools 动态开关、元数据实时同步
治理模型	Draft→Pending→Approved 审批流 + IAM 策略 + 自定义元数据（成本中心/安全分级）	默认鉴权 + 零信任方案，聚焦服务间调用可信
访问接口	AgentCore Console、API、MCP Server、OAuth；兼容 Kiro、Claude Code 等 MCP 客户端	Nacos Console、OpenAPI、SDK；通过 Router 暴露给 MCP 客户端
生态覆盖	跨云、provider-agnostic，托管在 AgentCore 平台上	开源可自部署，覆盖 Java（Spring AI）/Python/Go/Rust/TypeScript
目标用户	CIO / 合规团队 / 企业架构师	平台架构师 / 中间件团队 / 开源用户

表格里几个点值得单独说一下。注册方式上，Nacos 多出来的那一种"业务 API 零代码转 MCP"，直击国内企业的现实——大量存量 HTTP/RPC 服务不想重写，却又希望接入 AI 生态。这种"把现存资产纳进来"的能力，是 Nacos 区别于云厂商方案的一个重要切口。

动态管理上，两边选的是完全不同的优先级。AWS 认为 Agent 是一种企业资产，变更必须受控，所以更新后要回到 Draft 重新走审批，实测中 Tahara 也吐槽过这带来的摩擦。Nacos 继承了注册中心的基因，把"服务"的动态变更属性直接带到了 MCP 工具上——工具描述和开关状态都能在运行时修改，适合 Agent 能力快速迭代的团队。

一句话总结两种思路的差异：AWS 把 Agent Registry 当作一种企业 SaaS 治理产品来做，Nacos 把它当作一种开源中间件能力来做。谁更适合，取决于你的组织是更看重合规治理，还是更看重运行时灵活性和自主可控。

AWS 的下一步，以及行业方向

AWS 给出的路线图，展现了这个赛道接下来要解决的几个关键问题：Agent 部署后自动索引、跨注册中心联邦搜索（把多个 Registry 当作一个查）、自定义分类和分类法、把 AgentCore Observability 的运行数据（调用次数、延迟、可用率、使用模式）直接整合进注册中心记录。

AWS 还提到，已经有合作伙伴对接外部目录表达了兴趣，目标是在异构技术栈之间实现集中发现。

这其实和 Nacos 在 3.0 路线图里强调的方向有重合——动态发现、统一管理、协议代理、跨语言生态。两个方向、两套生态，正在分别从云端 SaaS 和开源中间件这两条路径，逼近同一个问题：如何在 Agent 数量爆炸的时代，让企业还能控制得住自己的 AI 资产。

Agent Registry 目前在五个 AWS 区域开放预览，包括美东（弗吉尼亚北部）、美西（俄勒冈）、亚太（悉尼）、亚太（东京）和欧洲（爱尔兰）。如果你的组织已经在为 Agent 治理头疼，无论选 AWS 还是 Nacos，现在都到了该认真评估的时候。