问题
企业在大规模云迁移（300+ 应用）中，AWS 的托管迁移服务（AWS Transform、AWS DMS）只覆盖标准迁移路径，无法处理组织特定需求——比如组合内部安全审批过的 IaC 模块库、以及 cutover 后的运维。结果是工程团队只能手工编写 IaC 组合，再交安全办公室审查。信号中的内部跟踪数据显示：单个应用需要 3-4 周，一个 300+ 应用的组合折算下来是数年的工程工作量。痛点真实且量化清晰，但注意：两条信号均来自 AWS 自己的机器学习博客，属于厂商发布的能力展示与内部实践案例，而非社区中自发讨论的用户抱怨，需求面证据偏薄。
目标用户
正在执行大规模云迁移的企业平台工程/云迁移团队，尤其是已建有自己的安全审批 IaC 模块库的大型企业。市场定性偏窄：这是全球大型企业迁移项目中的痛点，客户数量有限但单个合同价值高，典型的大 B 少客户型市场。
解决方案
围绕"用多智能体把手工 IaC 组合自动化"构建：
- Intake 智能体：从 Confluence/Jira 等源拉取应用迁移评估信息
- IaC 智能体：检索并组合客户内部安全审批过的模块库，生成 IaC 代码，而非从零生成
- Governance 智能体：自动对照内部安全规范做预审查，产出供安全办公室复核的 diff
- MCP 工具层：通过 MCP 接入 AWS Transform / DMS 与客户内部系统
- AI 的角色：多智能体分工处理评估信息抽取、模块检索组合、合规预检三个原本高度依赖资深工程师的环节
为什么是现在
信号显示两项使能条件刚刚成熟：一是 Strands Agents SDK、Amazon Bedrock AgentCore 和 MCP 工具协议让"多智能体 + 外部工具接入"的架构成为可复用的官方路径；二是 AWS 官方明确指出其托管服务（AWS Transform、DMS）不覆盖组织特定需求（内部模块组合、cutover 后运维），留出了组合层的空白。但信号中没有模型能力、成本或监管层面的明确变化证据，此字段置信度中等。
MVP 范围
第一版只做一件事：接入客户的内部 IaC 模块库（如 Terraform Module Registry 或内部 Git 仓库），根据应用迁移评估结果（Intake 数据）自动生成符合内部规范的 IaC 组合，并输出给安全办公室审批的 diff 报告。不做数据库迁移本身（交给 AWS DMS / Transform）、不做 cutover 后的运维（SRE 阶段）、不做多客户通用的治理规则引擎（先用每个客户自己的规则文件）。前 2-3 个客户以人工配置接入的方式交付。
风险
平台依赖：方案深度绑定 AWS 生态（Bedrock AgentCore、Strands SDK、AWS Transform 的 MCP 接口），AWS 随时可能把这部分能力吸收进官方产品，直接消灭第三方空间。证据风险：全部信号来自 AWS 官方博客，本质是营销内容，真实付费需求未经社区验证。企业销售门槛：目标客户是大型企业迁移团队，销售周期长，1-3 人团队很难触达和承接。准确性风险：IaC 生成错误会导致基础设施事故，容错要求极高，需要人工审批环节兜底。
已有产品
| 产品 | 定位 | 价格 |
|---|---|---|
| AWS Transform | 覆盖标准迁移路径，但不支持组合客户内部安全审批过的 IaC 模块库 | — |
| AgentCore Gateway | AWS 官方网关组件，用于将企业内部工具接入智能体 | — |
| Amazon Bedrock AgentCore | 官方多智能体托管平台，信号中的四智能体方案即构建于其上 | — |
| Strands Agents SDK | AWS 开源智能体框架，是信号方案中构建四个专用智能体的基础 | — |
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
AWS Machine Learning Blog10月1日新能力
“Writing that composition by hand took 3 to 4 weeks per application, which across a 300+ application portfolio translates to years of engineering effort.”
AWS managed migration services cover standard migration paths but not organization-specific requirements like composing approved internal IaC modules or post-cutover operations.原文
AWS Machine Learning Blog10月1日增长数据隐含付费意愿
“The four-agent pattern in this post reduced infrastructure as code (IaC) development time from 3 to 4 weeks per application to minutes, based on internal project tracking data.”
An enterprise migration program reduced infrastructure-as-code development time from 3-4 weeks per application to minutes using a four-agent AI pattern across 300+ applications.原文