Amazon Web Services 已将其原始的 Amazon Bedrock 托管代理服务置于维护模式以供新的采用。 该服务以前称为 Amazon Bedrock Agents，现在记录为 Amazon Bedrock Agents Classic，AWS 表示，从 2026 年 7 月 30 日开始，该服务不再向新客户开放。

这并不意味着现有部署停止工作。 AWS 表示，当前客户可以继续使用 Bedrock Agents Classic，并单独声明 Amazon Bedrock 模型、知识库和 Guardrails 不会受到此次更改的影响。 但新代理工作负载的方向很明确：AWS 建议使用 Amazon Bedrock AgentCore 作为新的或迁移的代理应用程序的类似路径。

对于在 Bedrock 上构建的团队来说，这不仅仅是服务名称的更改。 它将 AWS 托管代理的默认架构从旧的 Bedrock Agents 界面转移到以 AgentCore 为中心的更新的运行时和工具堆栈。 对于提供 AI API 网关、LLM 路由层或企业代理基础设施的平台，这种中断会产生与普通模型选择并存的兼容性和迁移问题。

7 月 30 日发生的变化

AWS 文档现在将 Amazon Bedrock Agents 标识为 Amazon Bedrock Agents Classic。 同样的维护模式指南表示，Bedrock Agents Classic 从 2026 年 7 月 30 日起不再对新客户开放，而现有客户可以继续使用它。

实际意义取决于客户的 AWS 账户和当前使用情况。 基于 Classic 构建的现有生产系统不应仅根据公共维护通知就立即关闭。 但是，新团队、新客户和标准化未来代理基础设施的组织应将 Classic 视为传统路径，而不是默认的 Bedrock 代理服务。

AWS 将新客户和迁移客户指向 Bedrock AgentCore。 该公司将 AgentCore 描述为支持托管编排和更广泛的生产代理功能，包括通过模型上下文协议、内存、身份、可观察性和跟踪进行工具公开。 这些功能表明 AWS 正在从更窄的托管代理构建器转向更通用的代理运行时，以支持长期使用的工具应用程序。

一个边界也很重要：这一变化是关于 Bedrock 的托管代理编排层，而不是整个 Bedrock 平台。 AWS 表示 Bedrock 模型、知识库和 Guardrails 不受影响。 即使团队需要重新访问围绕它们的代理编排服务，团队仍然可以使用 Bedrock 模型推理或检索和安全组件。

为什么这对代理构建者很重要

代理基础设施变得越来越难以被视为模型调用的薄包装器。 生产代理通常需要工具权限、内存规则、身份映射、日志记录、评估和成本归因。 当托管编排层发生变化时，开发人员可能需要检查如何将提示、工具架构、检索、护栏和监控连接在一起。

对于采用 Bedrock Agents Classic 作为构建自己的编排的托管替代方案的企业来说尤其如此。 如果这些公司现在创建额外的环境、加入新的业务部门或在新的 AWS 账户中重建，他们可能会遇到与现有部署所使用的可用性和推荐架构不同的情况。

这种中断还会影响将 Bedrock 抽象为统一接口的供应商和内部平台团队。 多云或多模型平台不能简单地将其视为“通往 AWS 模型的路径”。它可能需要知道客户是否正在调用简单模型推理、知识库工作流程、Guardrails 策略、Classic 代理或 AgentCore 托管的工作负载。 这些是不同的操作界面，具有不同的迁移风险。

对于 Model Gate 用户和类似的网关客户来说，教训是 LLM API 路由不再仅仅与价格、延迟和模型质量有关。 代理安置也很重要。 网关可以帮助集中 API 密钥管理、使用情况分析、团队控制和支出可见性，但它仍然必须尊重底层提供商服务的功能和生命周期状态。

谁受到影响

最直接受影响的群体是计划在 Bedrock 上构建新托管代理的 AWS 客户。 如果他们之前没有使用过 Bedrock Agents Classic，他们应该期望 AgentCore 成为推荐路径。 根据 AWS 的说法，已经运行经典代理的团队可以继续使用它们，但在制定长期路线图决策时应该规划服务的维护状态。

云架构师会受到影响，因为参考架构可能需要更新。应根据 AgentCore 的 API、身份模型、可观察性功能和操作要求检查假设 Bedrock Agents Classic 作为标准托管代理层的文档、Terraform 模块、内部黄金路径和安全审查。

安全和治理团队也在范围内。 AgentCore 对身份、工具公开、可观察性和跟踪的重视反映了企业现在试图解决的问题：哪个用户或服务正在执行操作、代理可以调用​​哪些工具、可以检索哪些数据、如何审核决策以及如何检测失控的工具循环或昂贵的模型调用。

在 Bedrock 上构建的软件供应商可能需要双支持期。 现有客户可能仍使用 Classic，而新客户可能需要 AgentCore。 这可能意味着额外的测试、功能标记、客户特定的部署逻辑以及有关支持哪个 Bedrock 代理路径的更清晰的文档。

实际后果和开放性问题

第一个实际步骤是库存。 团队应确定他们是否使用 Bedrock Agents Classic、普通 Bedrock 模型 API、知识库、Guardrails 或 Bedrock 之外的自定义编排。 维护模式通知对这些类别的影响不同。

第二步是映射迁移依赖项，而不是假设直接直接迁移。 代理工作负载可能取决于工具定义、检索配置、提示模板、IAM 权限、审核日志和特定于应用程序的错误处理。 迁移到 AgentCore 可能是提高可观察性和身份控制的机会，但仍然需要集成工作。

第三步是成本和治理审查。 新的代理运行时通常可以更轻松地连接更多工具并运行更多自主工作流程。 这增加了使用分析、请求级归因和预算控制的价值。 在网关环境中，团队应决定哪些调用流经中央策略层，哪些保留在 AWS 管理的编排内。

一些细节仍然是特定于帐户的。 独立评论表明，资格可能取决于之前的帐户使用情况，并且一些新发布的截止后模型可能无法通过经典版获得。 在将这些要点视为策略之前，应根据客户自己的 AWS 账户和 AWS 当前的维护模式文档进行验证。

更大的信号非常明确：AWS 不会退出 Bedrock 代理，但它正在将新的代理工作从原始的 Bedrock Agents 界面中移走。 对于开发人员和平台团队来说，安全的假设是未来的 AWS 代理投资将集中在 AgentCore 周围，而 Bedrock Agents Classic 会成为现有部署的兼容性问题。