这种模式在解决什么问题
大型企业云迁移项目中，最容易被低估的是基础设施代码（IaC）的编写成本。在一个覆盖 300 多个应用、且必须在固定财年内完成的项目里，每个应用的 IaC 需要 3 到 4 周手工编写，最终的工程量会按年计算。重复出现的不是迁移动作本身，而是把安全标准、网络规范、组织内部模块库反复拼装到每一个应用上的过程。
基于 Amazon Bedrock AgentCore 构建的多智能体框架，正是把这一段最耗时、最容易出错的拼装工作交给一组专门的智能体来处理。配合 Amazon Bedrock 基础模型进行推理，借助 Strands Agents SDK 编排，通过 AgentCore Gateway 暴露的 MCP 工具触达组织内部的源系统，最终把单个应用的 IaC 交付时间从以周计压缩到分钟级。这种改造的直接价值不在炫技，而在把迁移项目从“卡在代码上”解放出来，让团队把时间花在架构决策、风险治理和业务切换上。
适合谁：三个同时成立的前置条件
这套模式不是通用方案，它依赖三个条件同时具备，否则效果会打折，甚至不如直接用托管服务。
第一，迁移的输入与输出必须通过 MCP 工具触达。系统侧的 wiki、工单平台、协作工具、内部配置 API 都需要由交付团队构建并维护成 MCP 接口，否则智能体拿不到正确的输入，也写不出符合规范的输出。
第二，组织内部存在必须遵循的 IaC 模块库。安全办公室、网络团队会维护一组经过评审的内部模块，所有生成的 IaC 都必须组合这些模块，而不是直接写出原始资源。如果安全规范只到文档层面，没有编码到模块库里，智能体就只能做参考，无法做执行。
第三，项目范围覆盖到割接之后的运维。模式中包含一个 SRE 智能体，负责割接后的监控与自动化修复。如果项目只关心迁移、不关心稳定运行，这一半价值就拿不到。
选择标准：什么时候用它，什么时候不用
在动手评估之前，先回答一个问题：迁移路径上是否已经有托管服务可以覆盖。AWS Transform 覆盖服务器、网络、大型机、.NET 和应用代码工作负载的发现、波次规划、着陆区创建与现代化；AWS Database Migration Service 覆盖数据库层的迁移与割接。这两部分没有必要自建智能体替代。
只有在上述托管服务留下空白的部分，才考虑自建智能体来补齐。具体来说，是以下三类缺口：迁移输入来自组织内多个文档与协作系统，需要被自动读取和结构化；IaC 必须组合内部模块库才能通过合规评审；割接之后还要把监控和修复纳入同一套治理框架。
如果缺口不属于这三类，那么引入智能体框架的成本和复杂度得不偿失，托管服务或简单脚本就够了。
四智能体的分工与衔接
模式由四个智能体组成，分属迁移与运维两条线。
迁移线包含三个智能体。Intake 智能体通过 MCP 工具读取架构文档、应用清单、问卷与依赖记录，输出目标架构、合规校验报告与迁移策略建议。IaC 智能体接收 Intake 的输出，按波次读取安全办公室签发的策略集，组合内部模块库生成 IaC，并把策略集版本随产物一并返回，使审阅者可以追溯到具体规则。Migration Intelligence 与 Governance 智能体对接 Jira、Confluence、Webex 等内部协作工具，提供组合层面的自动化报告、架构最佳实践评估和治理视图。
运维线由 SRE 智能体承担割接后的监控与自动化修复，承接迁移线的最终交付。所有智能体共享 AgentCore Memory 中的会话状态和上下文，Intake 完成发现后把目标架构写入共享上下文，IaC 智能体直接读取，从而省去人工交接。
落地路径与上手步骤
第一步，准备运行环境和接入凭证。需要在 AWS 账户中开通 Amazon Bedrock AgentCore 与 Amazon Bedrock 基础模型的访问权限，熟悉 Strands Agents SDK 与 MCP 服务端模式，并准备好组织内部使用的 IaC 工具链，例如 Terraform 或 AWS CDK。
第二步，构建 MCP 工具。把内部 wiki、工单系统、协作平台、内部配置 API 通过 AgentCore Gateway 暴露为 MCP 工具。安全相关的策略集由一个 Lambda 函数承载，并通过 Gateway 注册为 get_policies 工具，供 IaC 智能体按资源类型与波次按需拉取。
第三步，定义每个智能体。每个智能体在代码里由三部分构成：基础模型、系统提示词与工具集合。基础模型通过 Amazon Bedrock 调用，并附加 Bedrock Guardrails 策略；工具集合指向 AgentCore Gateway 暴露的 MCP 工具；身份与权限由 AgentCore Identity 通过限定范围的 IAM 角色签发，确保密钥不出现在智能体上下文中。
第四步，运行治理与可观测。所有工具调用在执行前由 AgentCore Policy 中的 Cedar 规则评估，限制单次操作的影响范围；每次调用都会写入 AgentCore Observability 与 AWS CloudTrail 组成的不可变审计链路，便于事后追溯。
第五步，按波次推进并收集反馈。先在一个小波次上端到端跑通 Intak、IaC 与 SRE 的协同，再把策略集、模块库与提示词根据实际偏差迭代。
成本与落地建议
成本主要来自四个部分，按可预测性从高到低排列。一是 Amazon Bedrock 基础模型的推理调用，按 token 计费，是模型调用次数和上下文长度的直接结果，建议在试点阶段就建立单应用平均成本基线。二是 AgentCore 运行时与 Gateway 的使用费用，按智能体实例与请求量计费，规模化之后才会显著。三是构建和维护 MCP 工具的一次性投入，包括把内部系统封装为 API、加鉴权、加审计，这一部分往往被低估，但它是模式成立的前提。四是策略集与模块库的治理成本，策略需要签发、版本化、按波次覆盖，模块需要持续更新。
落地建议有三。其一，先从一个高重复、低风险的波次切入，把端到端链路打通，而不是一上来就铺到全部应用。其二，把策略治理和模块库治理的责任与流程写清楚，策略的签发人、版本、豁免条件与过期时间都要可追溯，这是模式能省下审阅时间的真正原因。其三，把割接后的监控和修复一并纳入项目范围，否则只拿到一半价值。
对于正在进行大规模云迁移的团队，这套模式的价值在于把“写代码”这种重复劳动从项目关键路径上拿掉，让人和资金集中在架构、合规与业务切换上。对于规模较小、规范统一的迁移，直接使用托管服务即可，自建智能体框架的复杂度与收益不匹配。