AWS 正在进行兼容性更改，这对于在 Amazon Bedrock AgentCore 之上构建代理基础设施的团队来说非常重要。根据 AWS 文档，AWS Agent Registry 目前在 bedrock-agentcore 命名空间下提供公共预览版，但从 2026 年 8 月 6 日起，该服务将转移到 agent-registry 命名空间。

这不是新基础型号的发布，也不是定价公告。这是管道的改变。但对于操作代理、工具目录、模型上下文协议式集成或内部注册表的开发人员来说，管道更改通常是首先破坏生产脚本的更改。

AWS 表示，作为迁移的一部分，用户必须更新端点、IAM 策略、SDK 客户端、CLI 脚本和注册表数据。这使得这是一次真正的迁移事件，而不是表面上的重命名。任何直接调用旧命名空间、向其授予权限或通过命令行或 SDK 工作流程自动执行注册表操作的系统都可能需要进行更改，然后才能与新服务标识完美配合。

AWS 代理注册表发生了哪些变化

AWS Agent Registry 被记录为与 Amazon Bedrock AgentCore 关联的公共预览服务。该注册表旨在帮助团队管理和发现代理，包括代理卡和代理生态系统中使用的相关元数据。到目前为止，预览版一直位于 bedrock-agentcore 命名空间下。

8 月 6 日的更改将注册表分离到 agent-registry 命名空间中。实际上，这意味着集成应该停止假设注册表只是更广泛的 Bedrock AgentCore 命名空间的子部分。 AWS 文档指出了需要注意的几个领域：服务端点、身份和访问管理策略、SDK 客户端、CLI 脚本和注册表数据。

这些类别涵盖了代理基础设施变得棘手的大部分地方。端点可以嵌入到服务配置中。 IAM 权限可能由安全团队而不是应用程序开发人员管理。 SDK 客户端可能固定在内部库中。 CLI 脚本可能在 CI 管道或操作 Runbook 中运行。注册表数据可能需要迁移或重新注册，具体取决于团队如何使用预览服务。

为什么这对于代理和 MCP 工具很重要

这个时机值得注意，因为代理基础设施正在变得更加正式。市场上最近的变化促使开发人员远离一次性演示，转向受监管的系统：注册表、工具服务器、使用报告、访问控制和审计跟踪。在这种情况下，注册表命名空间更改表明 AWS 正在将代理发现和管理视为不同的基础设施表面。

对于尝试代理的团队来说，这可能是一项小型维护任务。对于围绕代理目录构建内部平台的公司来说，工作范围更广。注册表调用可能位于开发人员门户、安全审查系统、编排层、审批工作流或自动部署的后面。如果这些系统是在预览期间构建的，它们可能包含现在需要重新审视的假设。

此更改还与模型上下文协议部署和其他代理互操作性模式相关。代理注册表可以成为平台发现代理是什么、它可以使用什么工具、它公开什么端点以及应用什么信任边界的地方。如果网关、编排器或合作伙伴平台向客户公开 AWS 支持的代理，则它需要知道在过渡期间是否正在查看旧命名空间、新命名空间或两者。

谁受到影响

最直接受影响的用户是在公共预览期间已经使用 AWS Agent Registry 的开发人员和平台团队。他们应该审核引用bedrock-agentcore进行注册表操作的任何代码或基础设施。其中包括应用程序代码、基础设施即代码模板、IAM 策略、CI 作业、CLI 脚本、SDK 包装器、本地开发人员工具和支持团队使用的文档。

安全和云治理团队也受到影响。 IAM 更改可能比应用程序补丁需要更长的时间，因为它们通常需要审核、最低权限检查和批准工作流程。命名空间移动可能需要新的权限、更新的服务引用和刷新的策略模板。如果组织具有默认阻止未知服务命名空间的内部控制，则可能需要添加新的 agent-registry 命名空间，然后开发人员才能继续。

API 网关和自动化供应商有一个不同的问题：客户困惑。 AWS 最近还将 Bedrock Agents 移至新客户可用性的“经典”路径，将新工作转向 AgentCore。代理注册表命名空间迁移与早期的 Bedrock Agents Classic 截止是分开的，但这两个事件都会影响相同广泛类别的代理基础设施。文档、入职流程和支持响应应明确区分。

实际迁移步骤

团队应该从清单开始。在旧的 Bedrock AgentCore 命名空间下搜索与注册表相关的调用的存储库、部署清单、策略文件和 CI 脚本。然后确定哪些引用是运行时关键的，哪些只是文档或示例。

接下来，更新 IAM 策略并在非生产账户中测试它们。命名空间更改通常会暴露过于广泛的权限或隐藏的依赖关系。在生产代理或注册机构依赖新服务引用之前，受控测试可以显示新服务引用是否足够。

SDK 和 CLI 的使用情况应单独检查。部分团队通过官方SDK客户端调用云服务；其他人则在构建管道中执行 CLI 命令。两条路径可能会以不同的方式失败。 SDK客户端可能需要版本更新或新的服务构造函数。 CLI 脚本可能需要新的命令名称、端点标志或身份验证假设。

注册表数据应该有自己的迁移计划。 AWS 文档称，注册数据必须更新，但运营影响将取决于每个团队如何对代理、标识符和元数据进行建模。团队应验证代理记录、代理卡、版本或引用在迁移后是否保持稳定，以及下游系统是否缓存这些标识符。

对于使用多模型 API 或 AI API 网关的企业来说，更大的教训是代理基础架构现在需要与模型路由相同的变更管理规则。像 Model Gate 这样的网关可能不会直接参与 AWS Agent Registry 迁移，但操作模式很熟悉：提供商端 API 表面发生变化，团队需要集中配置、使用可见性、关键控制和明确的所有权，以避免分散的破坏。

仍不确定的事情

可用信息来自 AWS 文档，而不是单独的发布博客或更广泛的公告。这并不会降低更改的可操作性，但它确实限制了 AWS 注册表路线图的公共背景。文档确认了命名空间迁移和所需更新的类别；在检索到的材料中，它没有提供详细的市场定位解释或来自其他 AWS 来源的独立确认。

由于 AWS Agent Registry 处于公共预览版，因此团队还应该假设可以进行更多界面更改。预览服务对于早期采用很有用，但它们需要比成熟 API 更强的抽象边界。如果注册表操作分散在许多应用程序中，那么现在是将它们整合到内部库或平台服务后面的好时机，以便下一个更改更容易吸收。