AWS Agent Registry 运行时发现：工具上百以后，不要再把整个目录塞进 Prompt
2026 年 10 月 20 日，AWS 发布基于 AWS Agent Registry 的运行时能力发现实践。它针对一个必然出现的规模问题：工具从几个增长到几百个后，硬编码会迫使 Orchestrator 每新增能力就改代码、重新部署；把完整 schema 全塞进 Prompt 又浪费 token，并降低工具选择精度。
Registry 将 MCP Server、A2A Agent 和 Skills 作为带版本、描述、协议 descriptor 与审批状态的记录。运行时执行 Discover → Instantiate → Execute：先语义/关键词检索少量候选，再根据 descriptor 创建客户端，只将候选能力交给请求级内部 Agent，完成后销毁。
Registry 返回连接元数据，不返回调用凭证；发现与授权必须是两条独立链路。
注册记录是可治理的软件资产
记录不应只有名字和 URL。MCP descriptor 保存服务与工具 schema，A2A descriptor 保存 Agent Card；description 使用用户意图语言区分相邻能力。
record = registry.create_registry_record(
registryId=registry_id,
name="customer-support-agent",
description="处理退货、退款、投诉和升级，不负责价格优惠",
recordType="AGENT",
descriptors={
"a2aAgentCard": {
"data": json.dumps(agent_card),
"dataSchemaVersion": "0.3",
}
},
recordVersion="1.0",
)
发布生命周期采用 DRAFT → PENDING_APPROVAL → APPROVED。Publisher 与 Approver 使用不同 IAM 权限；只有已批准记录进入可发现数据面。审批应附带契约测试、安全扫描、owner 和过期时间。
Discover：检索的是候选，不是最终授权
records = registry_dp.search_discoverable_registry_records(
registryIds=[registry_arn],
searchQuery=user_request,
maxResults=5,
).get("registryRecords", [])
检索质量取决于描述、查询重写、过滤和 catalog 分布。企业需要离线 query–capability 基准，测 Recall@K、错误候选率和无匹配拒绝率。目录变大不会自动提高召回；同义能力过多会让排名恶化。
在搜索前用租户、环境、风险等级、数据域和地区做硬过滤。不能先返回全公司候选，再让模型决定自己是否有权使用。
Instantiate：按协议创建短期客户端
def instantiate(record, ctx):
meta = parse_descriptor(record)
if meta.protocol == "MCP":
token = credential_broker.issue(
principal=ctx.agent_id,
audience=meta.endpoint,
scopes=meta.required_scopes,
ttl=300,
)
return MCPClient(meta.endpoint, token=token)
if meta.protocol == "A2A":
return A2AClient(meta.agent_card, signer=ctx.workload_signer)
raise UnsupportedProtocol(meta.protocol)
凭证 broker 依据 Agent、用户、任务和目标单独签发，不从 Registry 搜索结果读取秘密。客户端与一次请求绑定，结束即关闭，避免连接池或 token 跨租户复用。
Execute：内部 Agent 只看到最小能力集
async with AsyncExitStack() as stack:
clients = [await stack.enter_async_context(instantiate(r, ctx)) for r in records]
tools = [tool for c in clients for tool in await c.list_tools()]
inner = Agent(model=model, tools=tools, system_prompt=task_policy)
return await inner.run(user_request)
执行前再次进行工具级策略判定。发现“退款 Agent”不代表它能对当前客户执行写操作。对多个候选设置总工具数、schema token 和并发预算；失败时返回可解释的无能力或无权限，而不是扩大全局搜索直到命中危险工具。
运行时发现不是所有场景的答案
小而稳定的工具集继续显式绑定更简单；固定顺序的合规流程应使用确定性图，不必每次检索。Registry 适合能力多、团队独立发布、请求组合变化大的平台。
生产观测应记录 search query 摘要、候选 record/version、排名、实例化失败、最终选择、授权决策和调用结果。只有能回答“为什么发现了它、为什么允许调用、当时是哪一版”，动态 Agent 平台才不会从代码耦合变成目录黑箱。