AWS Agent Registry基于开放规范ARD,为企业组织提供跨环境统一的Agent、工具和技能目录与治理能力。
随着组织规模扩大 AI Agent 和工具的使用,找到合适的资源变得越来越困难。团队构建 Model Context Protocol(MCP)服务器、部署 Agent、创建专用工具,但如果没有集中目录,这些资源就会陷入孤岛。开发者需要手动定位资源、审查资源、连接资源并维护连接。更糟糕的是,为一个 AI 客户端配置的 Agent 无法被另一个客户端使用。
当团队只连接少数几个工具时,这还算可控。但面对数量不断增长的 Agent、MCP 服务器、技能和 API,它们分散在公共注册中心和私有企业环境中,这种方式就难以为继了。
AWS Agent Registry 为组织提供了一个集中式目录,用于管理 Agent、MCP 服务器、工具、Agent 技能和自定义资源。它围绕两个核心概念构建:
注册中心(Registry)。注册中心是您在 AWS 账户中创建的目录,拥有自己的授权配置和审批设置。您可以运行一个全组织范围的注册中心,也可以按资源类型、阶段或团队创建独立的注册中心。通过跨账户共享,一个注册中心可以为整个 AWS Organization 服务。
注册记录(Registry Record)。每条记录代表一个单独的资源,包含描述其是什么、做什么以及如何访问的元数据。
创建注册中心:管理员创建注册中心、配置审批设置,并使用 AWS Identity and Access Management(IAM)或企业身份提供商的 JSON Web Token(JWT)设置授权。
发布记录:发布者将 MCP 服务器、Agent 或工具描述为记录并提交审批。
审核记录并批准:审核者审查待处理的记录,批准或拒绝它们,并弃用不再使用的记录。
发现已批准的资源:消费者(无论是人类用户还是 AI Agent)从注册中心搜索所需的资源。
审核机制:审批工作流确保只有符合安全、合规和质量标准的记录才能被发现的。管理员可以随时将记录从发现列表中移除。
混合搜索:结合语义理解和关键词匹配,使自然语言查询和精确名称查找都能返回相关结果。
原生 MCP 支持:注册中心以远程 MCP 端点的形式提供,任何兼容 MCP 的客户端都可以直接搜索和使用它。
灵活的授权机制:通过 IAM 凭证或企业身份提供商的 JWT 来控制访问。
AWS Agent Registry 解决了 AWS 环境内的发现问题。但大多数企业并非只在一个地方运营。Agent 和工具部署在多个云、本地基础设施、SaaS 平台和企业应用中,每个环境都有自己的注册中心、命名约定和元数据模式。
当每个环境使用各自的格式描述 Agent 资源时,将它们整合在一起需要为每一对需要互操作的注册中心构建定制连接器。一个共享规范改变了这个等式:如果每个注册中心都使用相同的格式描述资源,并通过通用协议暴露发现功能,那么发布者只需描述一次,消费者就可以在任何地方发现资源。
ARD 是一个开放标准,而不是产品或单一注册中心。它在 Apache License 2.0 下发布,托管于 agenticresourcediscovery.org 和 GitHub。AWS 在规范制定过程中贡献了反馈。
可以把 ARD 想象为实现跨注册中心联邦的机制,类似于 DNS 如何实现跨网络的名字解析。组织可以跨环境部署 Agent,每个环境的目录以通用协议、表面化这些资源并在其后暴露一个端点。对于联合发现,任何注册中心都可以使用对共享通用协议的理解来跨它们建立索引。因此,本地注册中心可以通过 ARD 进行联邦,无需双边协议或专有连接器。
我们将 ARD 视为 AWS Agent Registry 模型的自然补充:
无需迁移即可联邦:在云、本地和 SaaS 上分散部署了 Agent 基础设施的组织可以用一种一致的格式暴露这些资源。我们期望 ARD 能够实现跨环境发现,同时保持本地控制。
全局发现,本地控制:ARD 的设计与 AWS 客户期望的控制模型一致:发布目录的组织控制其中的内容、谁可以看到它以及何时撤销访问。我们期望 AWS Agent Registry 现有的访问控制保持在执行点,ARD 作为互操作层。
启用公共发现:通过 ARD 作为共享协议,任何组织都可以在自己的域上发布目录,使其可以被任何 ARD 兼容的客户端发现。我们期望 ARD 为 Agent Registry 客户开辟跨组织发现路径。
阅读 ARD 规范以了解目录和注册中心模型。
探索 GitHub 上的参考实现。
查看 AWS Agent Registry 文档。
阅读 AWS Agent Registry 预览发布的更多内容。
这只是开始。随着 AWS Agent Registry 和我们对开放发现标准的支持不断演进,我们非常期待您的反馈。