AWS Agent Registry正式可用：编排器可在运行时检索并调用MCP服务器与A2A智能体
AWS机器学习博客介绍了一项托管服务，可对MCP服务器、智能体和智能体技能进行编目与检索；编排器在每轮请求中按语义搜索发现能力，再单独获取凭据完成调用，请求结束后即销毁临时客户端。
AI解读：读者最需要弄清的是：这套机制解决的是“工具目录膨胀后如何让编排器找到该用哪个工具”，而不是替应用完成鉴权。按AWS博客的描述，编排器把用户请求转成一句自然语言查询发给Registry数据面，返回的是记录标识、名称、描述、类型、状态、版本和协议描述符，明确不含调用凭据。
适用边界由来源给出：小且稳定的能力集、固定顺序的流水线，仍可能更适合显式的构建期接线，可省去额外一次发现请求。博客同时强调，语义检索的命中质量取决于描述与描述符质量、查询设计和评测，目录变大并不自动意味着排序变好，文中“退货退款”命中客服智能体只被当作演示结果。
凭据需要走另一条受信路径：示例中MCP服务器经AgentCore Gateway调用，用从Cognito配置和Secrets Manager取得的OAuth令牌建立客户端；A2A记录通过boto3数据面客户端调用AgentCore runtime，由调用方AWS凭据签名。注册记录经DRAFT→PENDING_APPROVAL→APPROVED的人工审批后才可被发现，IAM权限可分离发布者与审批者。
AWS机器学习博客于近日发布文章《Discover tools at runtime with AWS Agent Registry》，作者Vibhu Pareek介绍了一种让AI编排器在运行时发现并调用工具的做法。文章称AWS Agent Registry已正式可用（generally available），是一项用于编目和发现Model Context Protocol（MCP）服务器、智能体（agents）和智能体技能的托管服务。
文章给出的问题是：硬编码工具在只有几个工具时可用，扩展到几十个开始退化，再多就难以管理；企业系统对外暴露数百个内部API（定价、客服、订单、库存、客户数据）时，模型可能把更多token花在分辨工具名上，而每加一项能力都要改编排器代码、重新部署并跨团队协调发布。
文章演示了“发现→实例化→执行”的循环：编排器本身不含任何工具知识，它把请求作为查询发给Registry数据面，拿到匹配记录后按描述符类型构造客户端，再用只含这些动态发现工具的内层智能体完成本轮请求，结束后销毁客户端。
发现、实例化、执行各自返回什么
在“发现”阶段，编排器向AWS Agent Registry数据面发送自然语言查询，响应包含记录标识、名称、描述、记录类型、状态、版本，以及MCP服务器元数据或A2A智能体卡这类协议描述符。文章明确：响应不包含调用凭据，应用必须通过单独的受信配置路径获取并应用凭据。
在“实例化”阶段，示例中的MCP服务器先被添加为Amazon Bedrock AgentCore Gateway的目标，因此MCP描述符指向Gateway端点；编排器另行从Cognito获取OAuth访问令牌，用于创建MCPClient。A2A记录含智能体卡，其URL指向AgentCore runtime端点，包装层通过boto3数据面客户端调用，并以调用方AWS凭据签名请求。
在“执行”阶段，系统为每个请求构建只含已发现工具的内层智能体，由大模型选择工具并把结果汇总返回用户；本轮结束后内层智能体及其客户端被拆除，下一次请求重新搜索、重新获取工具集。
- 记录创建时recordType必填：示例中MCP服务器用 "MCP"，A2A智能体用 "AGENT"。
- 示例的MCP描述符dataSchemaVersion为 "2025-12-11"，工具描述为 "2025-06-18"；A2A智能体卡为 "0.3"。
- 审批生命周期为DRAFT→PENDING_APPROVAL→APPROVED，只有已批准记录会由可发现的数据面返回。
- 检索调用为search_discoverable_registry_records，支持关键词与语义混合搜索，示例中maxResults取 3 或 5。
示例部署与三个演示场景
文章描述的参考架构包含AWS Agent Registry、Amazon Bedrock AgentCore Gateway、Amazon Bedrock AgentCore runtime、Amazon Bedrock、Amazon Cognito、AWS Lambda和AWS Secrets Manager。示例用部署脚本创建并填充Registry、验证发现、部署编排器并运行三个演示，另有清理脚本。编排器是一个部署在AgentCore runtime上的Strands智能体，暴露discover_and_execute工具函数。
示例当前配置一个Anthropic Claude Sonnet模型，通过跨区域模型ID调用，文章提示参见Bedrock的各区域支持模型列表。三个演示分别覆盖：仅MCP的订单状态查询；“订单 123 有两件单价 99.98 美元的Widget Pro，有何折扣档或优惠码”这类MCP加A2A的组合调用；以及“想退订单 789（Premium Headphones，3 月 10 日送达），是否符合退货条件、退款多少”这类意图词不出现在任何工具名中的语义匹配。
文章对第三个演示的归因是："return refund" 并未出现在客服智能体的注册名称里，混合搜索因其描述覆盖该意图而将其排在前面。作者随即限定，这只是演示结果，不能据此声称目录变大就会让排序变好。示例还会为提升召回而向多个查询扇出并对记录去重，文章说明这是示例自身的编排选择，并非Registry的要求。
- 示例的MCP调用链：Gateway入站配置Cognito JWT授权，并用Gateway的IAM角色调用Lambda目标。
- A2A调用链：AgentCore runtime上的智能体通过IAM授权的boto3调用。
- 可观测性方面，示例仅授予CloudWatch Logs权限，未创建自定义指标或仪表盘；文章建议生产团队自行定义追踪、日志与告警，并称生产部署应对智能体回复应用Bedrock Guardrails。
文章界定的收益与不适用情形
文章将收益限定在“发现循环就位之后”：团队可独立部署并注册自己的MCP服务器、智能体和技能，由审批策略决定记录何时对消费者可见；新增一条兼容且已批准的记录，不需要在编排器中新增工具特定的导入或端点。文章同时说明，协议、鉴权设置或编排策略的变更仍可能需要改代码或配置。
文章还列举了“何时不该用运行时发现”：能力集小且很少变化时，显式构建期接线可能更简单，也省去一次发现请求；能力总以固定顺序运行时，实现为确定性流程更直接，追踪也更集中。
对于正式可用版本，文章提到超出单账号示例的能力：通过AWS Organizations和共享机制实现组织级发现与跨账号共享；从URL自动同步能力描述符，同步请求上的凭据提供方配置仅用于抓取描述符内容，不会作为调用凭据返回给运行时消费者；审批工作流可通过Registry状态API和IAM权限接入CI检查、安全评审或人工审批；并支持标签、CloudFormation与基础设施即代码模式。
- 文章建议用有代表性的查询评测检索质量与调用行为，可先运行示例再注册一个自己的兼容MCP服务器或智能体。
- Registry授权可用IAM或自定义JWT；能力调用的鉴权与之分离，搜索结果不返回这些凭据。
- 文章未给出生产环境的检索准确率、延迟或成本数据。