Amazon Bedrock Agents 已更名为 Bedrock Agents Classic，并从 2026 年 7 月 30 日起停止向新客户开放。现有 Agent 不会因此立即下线，但新账号可能在 CreateAgent 或 InvokeInlineAgent 收到 403，Classic 的模型目录也会冻结。可靠的应对方式不是匆忙重写，而是先盘点账号资格，再按能力差异选择 AgentCore harness 或 code-defined runtime，并用可回放评测验证行为。

这次变化会影响哪些团队？

AWS 官方维护模式说明给出了很窄但很重要的边界：过去 12 个月有 Bedrock Agents 活动的账号会被加入许可名单；没有历史使用记录的账号调用 CreateAgent 或 InvokeInlineAgent 时会收到 AccessDeniedException，HTTP 状态码为 403。这个资格按 AWS 账号计算，不会自动从 Organization、付款账号或生产账号继承。

因此，最先出问题的往往不是正在运行的生产环境，而是低频 staging、新客户隔离账号、灾备账号和由 Control Tower 新建的项目账号。同一份 IaC 在旧账号成功、在新账号失败，并不自动说明 IAM policy 有误。

维护模式也不等于 EOL。官方目前没有给出迁移截止日期或计划中的终止日期；InvokeAgent、更新、查询、别名、action group 和 Knowledge Base 等既有能力继续可用。另一方面，Classic 的模型目录冻结在生效日，之后的新模型只通过 AgentCore 提供。Amazon Bedrock 的模型推理、Knowledge Bases 与 Guardrails 本身不受这一冻结影响。

场景 近期风险 应对优先级
存量生产账号持续调用 Classic 运行不因公告自动中断 先建立季度复查与回退计划
长期闲置的 staging 或灾备账号 12 个月活动窗口可能带来不确定性 尽快做只读盘点与受控探测
新客户或新项目账号 创建与 inline 调用可能直接 403 在开户流水线前置验证
需要 7 月 30 日之后的新模型 Classic 编排层无法选择 评估 AgentCore 迁移

如何在不误伤生产的前提下盘点？

第一步是建立账号矩阵，而不是立即运行创建命令。至少记录账号、区域、现有 Agent、最近一次已确认活动、IaC 所有者、业务等级和可接受停机窗口。CloudTrail 的默认事件历史未必覆盖完整的 12 个月，因此“没有查到事件”不能证明账号一定不在许可名单。

第二步，在每个账号中调用只读的 ListAgents，确认是否存在存量资源。下面只是命令形态示例，本文没有实际访问任何 AWS 账号：

aws bedrock-agent list-agents \
  --region us-west-2 \
  --max-results 20

第三步，把真正的准入探测限制在专用沙箱。CreateAgent 会创建持久资源；InvokeInlineAgent 不会留下 Agent 资源，但仍可能触发模型调用、权限检查和费用。探测必须使用明确的预算、区域、模型与清理策略，不能在生产账号中批量盲测。

第四步，把结果分成“已确认可创建”“已确认被限制”“仅有历史线索”“尚未验证”四类。不要把 AccessDeniedException 一概归因于维护模式：模型权限、区域支持、SCP、IAM 和请求参数也可能返回授权类错误。只有错误码、消息与官方描述一致，才应标记为维护模式限制。

如果你需要先完善 Agent 的安全基线，可以配合现有的 MCP Server 安全清单检查工具审批、最小权限和审计边界；迁移过程中则应把准入探测与真正的业务流量隔离。

AgentCore harness 与 code-defined runtime 怎么选？

迁移前先按行为而不是资源名称做清单。Classic 的 action group、Knowledge Base、session、memory、guardrail、code interpreter、prompt override、自定义 orchestrator 和多 Agent 协作，不能简单视为一组等名配置。

AgentCore harness 适合希望保留声明式托管体验、Agent loop 相对标准、愿意用 system prompt 和显式工具表达行为的团队。code-defined runtime 更适合已经拥有自定义编排、阶段级 prompt、复杂 supervisor/router、多模型路由或框架专属控制面的团队。

Classic 依赖 迁移判断 推荐落点
简单 action group 先把输入输出定义成平台无关 schema Gateway 暴露的工具或代码工具
Knowledge Base 保留检索契约与引用语义 Gateway 前置或代码级检索工具
AMAZON.UserInput 自动追问不应隐式消失 显式 inline function tool，由客户端接回控制权
四阶段 prompt override 单一 system prompt 未必等价 code-defined agent 或显式阶段函数
supervisor / router agent-as-tool 只能覆盖部分模式 复杂路由进入自定义编排
自定义 orchestrator 不要强塞进声明式 harness AgentCore runtime

这里最重要的不是选哪个 SDK，而是把业务约束留在自己控制的层。业务任务、工具 schema、幂等语义、失败分类、知识检索契约和评测集不应直接依赖平台对象；具体厂商 SDK 只出现在适配层。已有的 A2A 1.0 迁移指南同样强调协议对象与业务状态分离，这个原则也适用于托管 Agent 迁移。

如何设计一条可回退的迁移路径？

1. 冻结基线，而不是冻结开发

从真实但脱敏的任务中选出一组评测样本，固定输入、允许使用的工具、期望的业务结果、必须拒绝的动作和人工复核规则。不要只保存最终文本；还要保存工具调用序列、参数、权限决策、引用和终止原因。

2. 建立平台无关的运行协议

下面的骨架只是设计示例，不代表可直接运行的 AWS 实现：

class AgentRuntime(Protocol):
    def run(self, task: Task, tools: list[ToolSpec]) -> RunResult: ...

class ClassicAdapter:
    ...

class AgentCoreAdapter:
    ...

业务代码只依赖 AgentRuntime。工具定义独立保存，适配器负责把 schema 转换成 action group、MCP tool 或 framework tool。这样，迁移差异会集中在边界层，而不是扩散到每个业务用例。

3. 先迁低风险流量

先让 AgentCore 在影子模式读取相同输入，但禁止产生真实副作用。比较任务完成、工具选择、拒绝策略、延迟、token 消耗和错误类型。影子结果不能直接写回用户状态，也不能共享可能造成重复执行的幂等键。

4. 用显式门禁逐步放量

建议至少设定五类门禁：关键任务成功率不低于基线；禁止动作零突破；工具参数符合 schema；P95 延迟与成本在预算内；发生异常时能切回 Classic 或人工流程。所有阈值都应来自团队自己的验证，不能把厂商给出的迁移工时或演示结果当作生产基准。

5. 保持双写之外的单一执行权

Agent 迁移最危险的故障不是回答不同，而是两个运行时都执行了付款、发信、删除或部署。影子阶段只允许一个系统拥有副作用执行权；切流阶段使用统一的操作 ID 和下游幂等约束，避免双执行。

链路观测也必须随迁移一起完成。可以参考 FastAPI OpenTelemetry 生产链路追踪指南，把请求、Agent run、工具调用和下游任务串到同一 trace 中，但不要记录 prompt 中的凭据或用户敏感数据。

IaC 和多账号环境要改什么？

不要在模板中根据 403 临时放宽 IAM。更稳妥的做法是把“目标运行时”设为明确参数，并在部署前完成账号能力检查：

Parameters:
  AgentRuntimeMode:
    Type: String
    AllowedValues: [classic, agentcore]

Classic 只用于已确认具备资格的存量环境；新环境默认进入 AgentCore 路径。两条路径共享业务配置、工具 schema 和评测数据，但资源定义相互隔离。这样可以避免一个条件表达式在账号状态不明时创建半套资源。

还要逐组件检查区域，而不是只问“AgentCore 是否支持这个 Region”。AgentCore 官方区域表按 Runtime、Gateway、Identity、Memory、Observability、Evaluations 等能力列出覆盖；你的目标区域可能支持核心 runtime，却不支持迁移依赖的某个组件。

常见失败模式有哪些？

  • 把维护模式当成 IAM 故障。 结果是不断扩大权限，却没有改变账号资格。
  • 把“存量能跑”当成“灾备可恢复”。 灾备账号可能从未创建过 Agent，真正演练时才暴露限制。
  • 只迁资源，不迁行为。 prompt 阶段、追问、工具返回控制权和多 Agent 路由的差异会造成静默漂移。
  • 影子系统也执行副作用。 两套 runtime 同时调用工具，造成重复订单或重复通知。
  • 先删 Classic 再验证 AgentCore。 官方工具和迁移流程不应成为删除源系统的授权；切换完成前保留可回退路径。
  • 把厂商估计写进承诺。 “小时级”是特定简单配置的官方描述，不是你的真实工期。

AWS 提供的 agent toolkit for AWS可以用于发现和迁移辅助，但它仍应在代码审查、权限隔离和变更窗口内运行。任何自动化工具都不应直接获得删除源 Agent 或绕过审批的权限。

上线前检查清单

  • [ ] 已按账号和区域记录 Classic 使用与资格证据。
  • [ ] 新账号 IaC 不再默认创建 Classic Agent。
  • [ ] 已选择 harness 或 code-defined runtime，并记录选择理由。
  • [ ] 工具 schema、幂等、超时、重试与审批不依赖厂商 SDK。
  • [ ] 已覆盖 prompt override、用户追问、多 Agent 与自定义编排差异。
  • [ ] 影子阶段只有一个系统拥有副作用执行权。
  • [ ] 关键任务、拒绝动作、延迟、成本和可观测性通过自有门禁。
  • [ ] AgentCore 目标区域的每个必要组件均已核对。
  • [ ] Classic 回退路径仍可用，且没有提前删除源资源。

FAQ

现有 Bedrock Agent 会在 2026 年 7 月 30 日停止吗？

不会因该日期自动停止。官方描述是进入维护模式并关闭新客户入口，且目前没有计划中的 EOL 日期。但这不等于可以永远不评估：模型目录冻结、新账号限制和功能演进停止都会持续增加迁移压力。

可以通过修改 IAM 解决新账号的 403 吗？

如果错误确实来自维护模式许可名单，扩大 IAM 权限不会改变结果。应先核对错误消息、账号历史和官方规则，再排除 SCP、IAM、区域或模型访问等其他原因。

所有团队都应该立即迁移吗？

不一定。存量系统稳定、无需新模型、没有新账号扩展需求的团队可以先建立风险登记和周期复查；需要新账号、新模型或复杂持续演进的团队应把迁移提前。决定应由业务寿命、恢复目标和验证成本驱动，而不是公告情绪。

迁移完成等于可以删除 Classic 吗？

不等于。先完成真实流量灰度、回退演练和观察窗口，再通过独立变更审批删除源资源。迁移工具“不会修改源 Agent”的保证，也不等于你的部署脚本没有删除权限。

这次变化真正需要修复的不是一个 403，而是架构对托管编排层的隐式依赖。只要账号资格、工具契约、行为评测和回退权都可见，维护模式就能从突发事故变成一项可管理的迁移工作。