亚马逊云科技近期在 Amazon Bedrock AgentCore 中以公开预览形式发布了 Agent Registry，为企业提供一个集中式目录，用于在组织内发现、共享并治理 AI Agent、工具、MCP 服务器以及 agent skills。该注册表可以索引运行在任何位置的 agent，无论是在 亚马逊云科技、其他云服务提供商，还是本地部署环境。
它所解决的问题，对于任何见过 agent 数量不断增长的平台团队来说都非常熟悉：没人知道都有哪些东西存在、谁在负责、是否已获批准，或者隔壁团队是否已经做过同样的事情。agent 的扩散会迅速叠加，随之而来的是合规漏洞，以及开发资源浪费在重复工作上。
记录的注册方式有两种。团队可以通过控制台、SDK 或 API 手动提供元数据，指定所有权、能力描述以及合规状态。也可以指向一个 MCP 或 A2A 端点，让注册表自动拉取相关细节。每条记录都会包含发布者信息、实现的协议、对外提供的能力，以及调用方式。
查找已有内容依赖于混合搜索机制，结合了关键词匹配与语义匹配。例如，对“payment processing”的搜索，即使名称不一致，也可能返回标记为“billing”或“invoicing”的工具。该注册表可通过 AgentCore 控制台、API 访问，同时自身也作为 MCP 服务器存在，因此任何兼容 MCP 的客户端（包括 Kiro 和 Claude Code）都可以直接查询。对于使用自定义身份提供方的组织，基于 OAuth 的访问方式允许团队在无需 IAM 凭证的情况下构建自己的发现界面。
在治理层面，记录遵循审批流程。它们从草稿状态开始，进入待审批状态，只有在通过审核后才会变为可被发现。管理员通过 IAM 策略控制谁可以注册以及谁可以发现内容。版本管理会追踪随时间的变更，组织也可以废弃不再需要的记录。自定义元数据字段允许团队附加诸如成本中心、部署环境或安全分类等信息。
解决方案架构师 Shinya Tahara 对该注册表进行了实际测试，并发现了一些值得注意的不足之处。语义搜索在英文查询下表现良好，但在仅有英文元数据的情况下处理日文查询时效果不佳。在三条日文测试查询中，有一条没有返回任何结果。增加双语描述后问题得到解决，这对计划在全球范围内部署的组织具有参考意义。Tahara 还发现，将过滤条件嵌入自然语言查询会显著降低精度，结果会返回所有已注册记录，而非目标对象。此外，任何记录更新都会将其状态重置为 DRAFT，这意味着需要重新提交并重新审批。频繁更新 agent 的团队需要在工作流程中考虑这一摩擦成本。
Southwest Airlines AI 与智能平台副总裁 Justin Bundick 在发布中描述了该注册表的价值：
AWS Agent Registry 在 AgentCore 中解决了关键的可发现性问题，使团队能够发现并复用已有 agent，而不是从头重建能力。通过跨多个平台的托管治理，每个 agent 都携带标准化的所有权元数据与策略执行信息。
Zuora 也是早期采用者之一。该公司在销售、财务、产品和开发团队中部署了 50 个 agent。Zuora 首席产品与技术官 Pete Hirsch 指出，该注册表为首席架构师提供了统一视图，用于发现、管理和编目所有正在使用的 agent、工具和技能，并通过标准化元数据确保整个生态中的所有权与能力信息一致。
展望未来，其路线图包括：在 agent 部署后立即自动索引、跨注册表联合（federation）以实现多注册表统一搜索、自定义分类与本体结构，以及将 AgentCore Observability 中的运行数据（包括调用次数、延迟、可用性和使用模式）直接集成到注册表记录中。此外，亚马逊云科技 还提到已有合作伙伴表达兴趣，希望连接外部目录，实现跨技术栈的集中发现。
亚马逊云科技并不是唯一提供 agent registry 解决方案的超大规模云厂商。例如，微软提供 Entra Agent Registry 和 Azure Agent Registry。此外，Google Cloud 也有自己的 Agent Registry，同时在协议层面也存在诸如 Agent Client Protocol（ACP）Registry 的相关工作。亚马逊云科技 方案的区别在于其提供了与厂商无关的索引能力，并原生支持 MCP 与 A2A 协议，使其能够编目构建在亚马逊云科技生态之外的 agent。
Agent Registry 当前已在五个亚马逊云科技 区域以预览版提供：美国东部（弗吉尼亚北部）、美国西部（俄勒冈）、亚太地区（悉尼）、亚太地区（东京）以及欧洲（爱尔兰）。
原文链接：
https://www.infoq.com/news/2026/04/aws-agent-registry-preview/
