企业做出十个Agent之后，新的问题往往不是“还缺哪个模型”，而是没人说得清已有多少工具、谁在维护、是否通过安全审查、另一个团队能不能直接复用。8月31日，AWS Agent Registry结束预览并正式可用，把Agent、MCP服务器、工具、Skill和自定义资源放进一个受管目录，让人和Agent都能搜索、申请并调用经过批准的能力。

目录不是资产清单，而是一条可执行的审批链

Agent Registry把治理面和发现面分开。管理员看到组织范围内完整资源，配置谁可以发布、谁负责审批、何时弃用；普通开发者和业务Agent只搜索自己有权访问、已经进入可发现状态的能力。语义检索可以按意图寻找“工单路由工具”，关键词检索则用于精确名称，两者共同减少重复建设。

每条记录需要描述类型、端点、所有者、版本、状态和访问策略。MCP记录可包含工具、资源与提示词，Agent记录采用A2A Agent Card，Skill则由Markdown定义并关联代码包。管理员可以用角色指定审批人，把安全、合规或业务评审接入状态转换；CloudTrail保存对目录执行的操作，弃用也成为显式生命周期，而不是悄悄让旧端点继续运行。

从控制台到MCP端点，发现能力不必离开工作流

目录可以通过AWS控制台、CLI和SDK管理，搜索API同时暴露为原生MCP端点，因此Agent能像开发者一样按任务需要寻找获批工具。资源还可以在Amazon Bedrock AgentCore、Amazon Quick和Kiro IDE中发现，减少为了查目录频繁切换系统的摩擦。

正式版新增了CloudFormation、Terraform和CDK基础设施即代码支持，也能用标签分类资源，并通过AWS Resource Access Manager跨账户共享。组织管理员可一次启用端点检测，让Registry自动发现不同账户中运行于AgentCore Runtime和Gateway的Agent与MCP服务器。对平台团队而言，这比要求每个项目手工填表更接近真实资产治理。

不过，“自动发现”目前有明确边界：官方说明首先覆盖AgentCore Runtime和Gateway。运行在EC2、EKS、ECS、其他云或本地环境的能力，未来计划通过更广的自动检测和联邦合作纳入；这些属于路线图，不能当作已交付功能。

一套目录能减少重复，但不能替代运行时控制

Southwest Airlines、PepsiCo、Syngenta和Amdocs在正式发布材料中给出采用或评估反馈。Southwest称其从分散在多个技术团队的Agent与工具转向统一目录，Syngenta则把登记、评审和批准作为共享前提。这些具名案例证明问题真实存在，但没有公开任务完成率、节省工时、故障率或成本基线，不能据此量化投资回报。

更要警惕把“已批准”误读成“每次调用都安全”。目录负责描述、发现和生命周期，运行时仍要验证调用者身份、工具参数、数据范围与输出去向；敏感动作还需要人工批准、预算限制、策略网关和故障回退。一个获批工具更新版本后，也必须重新验证依赖它的Agent，否则统一目录只会把错误更快传播到更多团队。

小编判断：Agent规模化的第一步，是先回答“我们有什么”

Agent Registry的重要性不在于AWS又多一个入口，而在于企业AI开始出现类似软件包仓库和服务目录的基础设施。FDE完成一次客户交付后，可以把稳定工具、Agent卡和操作Skill登记为可复用资产；下一支团队先搜索、再组合，而不是从Prompt和连接器重新开始。

落地时应先定义最小登记规范：所有者、用途、输入输出、数据级别、版本、审批人、回滚方式和停用日期缺一不可。随后再追踪搜索命中率、重复建设减少量、审批周期、失效端点比例和真实调用量。若目录只有数量没有使用和退役纪律，它很快会变成新的资产坟场；只有把登记、运行策略和反馈闭环连接起来，统一目录才会真正降低Agent扩张的治理成本。