当组织里的智能体、工具和技能不断增加，真正困难的问题往往不再是“能不能调用”，而是“有哪些资源可用、谁负责、能否跨环境发现，以及是否符合治理要求”。AWS Agent Registry 提供集中化、可搜索的资源目录，并结合开放的 Agentic Resource Discovery（ARD）标准，让智能体资源发现从团队内部约定，逐步变成可跨环境协作的统一能力。
从“知道地址”到“能够发现”
传统集成通常依赖静态配置：开发者在代码、环境变量或文档中写入某个智能体或工具的名称与地址。规模较小时问题不明显，但资源一多，就会出现几类实际障碍：
- 团队不知道已有资源，重复开发相同能力。
- 测试、预发布和生产环境中的资源名称或版本不一致。
- 调用方无法快速判断某个智能体是否经过审核，或者由哪个团队负责。
- 资源迁移后，多个调用方仍然持有旧地址。
ARD 的核心价值可以理解为一套开放的资源发现约定：调用方根据能力、名称或其他元数据查找资源，再决定如何连接和调用。它把“资源在哪里”的问题从业务代码中抽离出来，也为跨环境发现提供了共同语言。
这里的资源不只包括完整的 agent，还可以包括工具和 skills。一个面向客服的智能体可能依赖订单查询工具、退款处理工具和知识库检索技能。将这些资源统一纳入目录后，搜索、所有权、版本和治理就能放在同一个视图中管理。
AWS Agent Registry 解决什么问题
AWS Agent Registry 可以作为组织级的集中目录，用于登记和搜索 agents、tools 与 skills。结合 ARD 后，目录不只是一个人工维护的网页或文档，而可以成为不同环境、不同团队和不同运行时之间的发现入口。
可以把这套组合拆成三层：
- 资源登记：记录资源名称、能力描述、版本、所属团队和运行环境。
- 资源发现：调用方按能力或元数据搜索，而不是硬编码某个具体实现。
- 治理控制：在资源被发现和接入时，检查状态、负责人、环境边界和使用策略。
这并不意味着注册表会自动解决所有运行时问题。发现到资源之后，仍然需要处理身份认证、网络连通性、权限授权、协议兼容、超时和版本升级。注册表负责让资源“可见、可查、可管理”，而不是替代完整的服务治理体系。
一个可改造的资源描述示例
下面是一个示意性的 ARD 风格 YAML，用于展示目录条目可以包含哪些信息。字段名称和具体接口应以实际采用的 ARD 实现及 AWS 环境为准；它可以作为设计内部资源元数据模型的起点。
将下面内容保存为 agent-resource.yaml，然后根据组织的注册接口或导入工具进行改造：
apiVersion: discovery.example/v1
kind: AgentResource
metadata:
name: order-support-agent
version: 1.3.0
owner: commerce-platform
environment: production
spec:
type: agent
description: "处理订单状态查询和退款政策问答"
capabilities:
- order-status.lookup
- refund-policy.answer
interfaces:
- protocol: https
endpoint: https://agents.example.internal/order-support
dependencies:
- name: order-query-tool
version: ">=2.1.0 <3.0.0"
governance:
lifecycle: active
dataClassification: internal
reviewRequired: true
auditContact: commerce-platform@example.com
这个示例中有几个字段值得保留：capabilities 让调用方可以按能力搜索；owner 和 auditContact 让问题能够回到明确的责任团队；environment 避免测试调用误连生产资源；dependencies 帮助评估版本兼容性；governance 则为审核、数据分类和生命周期管理提供入口。
如果组织需要自动发现，建议让 CI/CD 在部署或发布阶段同步资源元数据，而不是要求开发者手工修改目录。删除或下线资源时也应同步更新状态，避免目录中出现无法调用的“幽灵条目”。
搜索与接入流程可以这样设计
一个较稳妥的接入流程通常包括以下步骤：
- 资源团队提交 agent、tool 或 skill 的元数据。
- 注册表校验必填字段、版本格式和所属环境。
- 治理流程检查负责人、数据级别、权限和审核状态。
- 资源进入可搜索目录。
- 调用方按能力查询资源，并在本地执行权限和兼容性检查。
- 运行时通过目录返回的连接信息访问目标资源。
下面的 Python 示例不依赖 AWS SDK，演示调用方如何从一个本地目录中按能力选择资源。它适合先验证搜索逻辑；接入真实注册表时，只需把 resources 替换为 ARD 或 Agent Registry 的查询结果，并补充认证与网络策略。
from typing import Any
resources: list[dict[str, Any]] = [
{
"name": "order-support-agent",
"type": "agent",
"environment": "production",
"lifecycle": "active",
"capabilities": ["order-status.lookup", "refund-policy.answer"],
"endpoint": "https://agents.example.internal/order-support",
},
{
"name": "order-query-tool",
"type": "tool",
"environment": "production",
"lifecycle": "active",
"capabilities": ["order-status.lookup"],
"endpoint": "https://tools.example.internal/order-query",
},
]
def discover(capability: str, resource_type: str, environment: str) -> list[dict[str, Any]]:
return [
resource
for resource in resources
if resource["type"] == resource_type
and resource["environment"] == environment
and resource["lifecycle"] == "active"
and capability in resource["capabilities"]
]
matches = discover("order-status.lookup", "agent", "production")
if not matches:
raise RuntimeError("没有找到符合条件的生产环境 agent")
selected = matches[0]
print(f"使用资源: {selected['name']}")
print(f"调用地址: {selected['endpoint']}")
生产环境中不要仅凭搜索结果直接调用。调用方至少还应验证资源的审核状态、允许的数据范围、调用身份和目标环境。搜索结果可以缩小候选集合，但不能代替授权决定。
落地时要盯住的边界
目录新鲜度。 资源版本、端点和生命周期都可能变化。应定义注册、更新、下线的责任与自动化机制，并为过期条目设置告警或拒绝策略。
跨环境隔离。 “可发现”不等于“可调用”。开发环境可以发现测试资源，但不应因为目录暴露了生产端点就获得生产访问权限。
最小权限。 目录元数据本身也可能泄露内部能力、数据类型或服务拓扑。应控制谁可以搜索哪些字段，谁可以读取连接信息。
版本兼容。 发现机制只能找到候选资源，不能保证提示词、输入输出 schema 或依赖工具完全兼容。建议为能力定义稳定契约，并在注册阶段记录兼容版本。
责任归属。 没有 owner 的资源很快会变成无法维护的目录噪音。注册表条目应绑定团队、联系人、SLA 或生命周期状态。
采用清单
可以按以下顺序推进：
- 先盘点现有 agents、tools 和 skills，统一资源命名与能力标签。
- 为每个资源补齐 owner、环境、版本、端点和生命周期状态。
- 用 ARD 兼容的元数据模型定义组织内部的最小字段集合。
- 将发布、回滚和下线流程接入 CI/CD 或资源管理流程。
- 让调用方优先按能力发现，再进行权限、环境和版本校验。
- 记录发现结果与实际调用结果，定期清理不可用或无人负责的资源。
ARD 提供跨环境发现的开放基础，AWS Agent Registry 则可以承担组织级目录和治理入口。两者结合后的关键收益，不是多了一份资源清单，而是让智能体生态具备可搜索、可负责、可审计和可演进的管理边界。对于刚开始建设 agent 平台的团队，先把资源元数据和生命周期管理做扎实，再逐步扩大自动发现与跨环境接入范围，通常更容易控制复杂度。