深度解读 · 约 4 分钟阅读
AWS Agent Registry 运行时发现：找到工具与获得调用权限是两件事
AWS 技术指南以获批的 MCP、A2A 记录构建“发现—实例化—执行”循环，搜索结果不负责下发调用凭据。
- 原文发布
- 本站发布
- 核实时间
AWS 于 10 月 20 日发布教程，展示编排代理如何在运行时发现能力，而不是在构建时逐一导入所有工具。订单管理案例将 AgentCore Gateway 暴露的 MCP 服务与定价、客服 A2A 代理组合起来。新增信息是一套可检查的连接模式，不能据此声称目录越大，代理决策就越准确。
听读资讯
朗读当前文章，或连续收听资讯。
正在准备听读…
设备语音
朗读由浏览器或设备处理，AISubHub 不向音频 API 发送文本。可用语音及锁屏播放能力因设备而异。
继续播放时可能重复一小段。
一分钟速览
- 人工审批让记录依次经过 DRAFT、PENDING_APPROVAL、APPROVED；只有获批记录进入所配置数据面的可发现范围。
- 搜索返回描述符、端点及记录元数据，不返回调用凭据；示例分别用 Cognito OAuth 调用 Gateway，用 IAM 签名调用 A2A 运行时。
可搜索记录先是一份连接契约
发布方提供面向用户的描述以及协议专用描述符。MCP 记录包含服务元数据和工具定义，代理记录包含 A2A agent card。记录生命周期由控制面管理，运行时发现走数据面。启用人工审批时，发布动作本身不会立即让能力可见，还须完成所配置的审核状态转换；IAM 权限可以分离发布者与审批者。这为检查端点身份和操作范围提供了位置，但获批不等于每个用户未来的每次调用都合理。描述还应使用真实用户的语言，区分用途相近的能力，避免所有工具都被笼统描述成“处理客户问题”。
每次请求组装一个范围更小的工作代理
外层编排器将请求转换成关键词与语义混合搜索，解析返回的描述符，并建立相应客户端；随后创建只装载本次发现工具的内层代理。模型在候选集中选择工具、生成答复，轮次结束后销毁客户端；下一次请求重新发现。示例对订单领域采用多查询展开并去重，这是编排器的选择，不是 Registry 强制行为。小候选集可以避免把整个目录塞进提示词，但如果检索遗漏正确工具，后续模型就无从选择。因此少装载工具和正确选中工具，是必须分别验证的两个问题。
发现过程不传递业务调用权
MCP 描述符指向 Gateway 端点；应用从可信 Cognito 配置和 Secrets Manager 路径另取 OAuth 访问令牌。A2A 包装器通过 Boto3，以调用者 AWS 凭据对 AgentCore runtime 请求签名；Registry 本身又有独立访问授权。AISubHub 分析：只把发现的 URL 填进客户端远远不够，还要知道可信认证路径和允许的操作。自动同步描述符时可以配置取元数据的凭据，但指南明确说明，这些凭据不会作为运行时消费者的调用认证返回。目录因此既不是秘密分发器，也不代表获得一切操作的通行证。
把检索和执行一起验收
三种演示分别覆盖仅用 MCP 查订单、MCP 加 A2A 查询价格优惠，以及通过客服代理描述语义匹配退货退款意图。最后一种只展示一个语义命中，不是整个目录的准确率。可用的验收集应包含模糊请求、不支持的意图、权限拒绝和错误描述符，并记录选中的记录 ID 与下游结果。示例授予 CloudWatch 日志权限，但没有创建自定义指标和仪表盘，生产团队仍须定义追踪及告警。指南也承认替代方案：工具少而稳定时显式绑定更简单；同一组能力总按固定顺序运行时，确定性流程通常更清晰。
有什么影响
AISubHub 分析：采用兼容协议的团队可发布新获批能力，而无需在编排器增加某个工具的导入代码；协议变化、认证配置和编排策略仍可能需要更新。
限制与可用性
本文依据参考实现说明和三种演示，原文没有提供通用检索基准。本站没有部署、测量成本或独立验证生产可靠性。指南称 Registry 已正式可用，具体功能及地区是否适合部署仍需另行核对。
来源与证据
原文发布: 2026年10月20日 · 核实时间: 2026年10月21日
AI 辅助采编，依据所列一手来源核实。厂商自报结论注明归属，收录不代表背书。