北京
一个企业级迁移项目，覆盖300多个应用，截止日期卡死在财年之内。按传统做法，光是给每个应用手写基础设施代码（IaC），就要花掉3到4周。300个应用乘下来，是数年的工程量。
但项目组用一套四智能体模式，把单应用的IaC开发时间从3到4周压到了几分钟。这个数据来自项目内部的追踪记录。
这套模式跑在 Amazon Bedrock AgentCore 上，用 Strands Agents SDK 构建，和 AWS Transform 并行使用，而不是替代它。
先问一句：托管服务覆盖到哪了
这套模式的前提，是先把边界划清楚。哪些活该交给托管服务，哪些必须自己写自动化？
AWS Transform 负责迁移和现代化改造，覆盖服务器、网络、大型机、.NET 和应用代码等工作负载。AWS Database Migration Service（AWS DMS）负责数据库层，提供生成式AI辅助的架构转换和自动化切换。
这套四智能体模式补的是托管服务覆盖不到的那部分——组织特有的需求。它有一个硬性前提：源系统和目标系统都要通过组织自己搭建和维护的 Model Context Protocol（MCP）工具来访问。
三个条件同时成立，这套模式才适用
在这个项目里，三个条件缺一不可：
- MCP连接的源和目标：存放迁移输入的系统、接收输出的系统，都通过交付团队自建自维护的MCP工具访问。包括存安全标准的内部wiki、工单系统、协作平台，以及一套自研的资源配置API。
- 组织特有的IaC组合：生成的代码必须组合内部模块库，而这个库由安全办公室审核批准。手写这套组合，单应用3到4周。
- 切换之后还要继续跑：项目范围包含交接后的运维，这部分不在迁移服务的覆盖范围内。
四个智能体，两条旅程
整套架构把智能体分成两条线。迁移旅程负责从发现到部署，运维旅程负责迁移后的监控。
迁移旅程有三个智能体。Intake Agent 在阶段一，通过MCP工具读取架构文档、问卷和依赖记录，然后定义目标状态架构。IaC Agent 在阶段二，为每个应用生成组合了已批准内部模块的基础设施代码。Migration Intelligence and Governance Agent 负责自动化组合报告、well-architected 评估，以及在 Jira、Confluence、Webex 上的治理。
运维旅程只有一个：SRE Agent，在阶段三提供切换后的监控和自动化修复。
运行时怎么连起来
每个智能体都是一个 Strands agent，由基础模型、系统提示词和一组工具定义。Amazon Bedrock AgentCore 的运行时把它们托管在无服务器环境里，提供会话隔离和多智能体编排。
Amazon Bedrock 的基础模型负责推理——解读文档、生成代码、驱动多步工作流。每个智能体通过 AgentCore Gateway 调用限定在自己职能范围内的MCP工具。这个网关把组织的API、AWS Lambda 函数和现有服务转换成MCP兼容的工具。
每一次调用，都由 AgentCore Identity 通过限定范围的 AWS Identity and Access Management（IAM）角色和组织的身份提供商完成认证。
要跟着搭一遍，需要一个能访问 Amazon Bedrock AgentCore 和 Amazon Bedrock 基础模型的 AWS 账号，还需要熟悉 Strands Agents SDK、MCP 服务器模式，以及组织自己在用的 IaC 工具。
动手之前，先确认一件事：现有的 AWS 托管服务是不是已经覆盖了你的迁移路径。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
