AI Agent 如何为企业上云按下”加速键” —— CRM系统迁移实战

摘要：本文以一套典型的 IDC 三层 CRM 系统迁移到亚马逊云科技为例，对比了 “传统手工操作” 与 “AI Agent 辅助” 两种迁移方式。在本案例场景下，端到端迁移耗时从约 218 分钟压缩至约 55 分钟，工程师的实际动手时间从全程参与降至约 15 分钟。本文将详细拆解测试流程、技术细节与适用边界，供读者判断 AI Agent 在自身迁移场景中的适用性。

01 一、引⾔：上云的”最后⼀公⾥”为什么慢？

02 二、迁移对象：⼀套典型的 IDC 三层架构

03 三、⽬标架构与关键差异

04 四、⽅式⼀：控制台⼿动迁移——218 分钟的”时间⿊洞”

05 五、⽅式⼆：Kiro 辅助迁移——55 分钟，⼈⼯仅 15 分钟

06 六、效率对⽐：数据说话

07 七、关键技术细节

08 八、落地思考：从⼀次实验到企业实践

09 九、总结：从”操作员”到”决策者”

一、引⾔：上云的”最后⼀公⾥”为什么慢？

随着企业数字化转型的深⼊，本地数据中⼼⾯临着硬件运维成本攀升、弹性扩展受限等挑战，将⼯作负载迁移上云已成为越来越多企业的选择。

然⽽，⼀个常被忽视的现实是：迁移本身的⼯程量，往往⽐想象中⼤得多。⼀套看似简单的三层应⽤，⼿动迁移到亚⻢逊云科技通常需要经过近⼗个步骤，创建和配置数⼗项云资源。任何⼀个参数的疏忽都可能导致服务启动失败，甚⾄业务中断。

⼤语⾔模型驱动的 AI Agent 的出现，为这⼀痛点带来了全新的解决思路：通过⾃然语⾔交互、⾃动化命令编排和模板⽣成，AI Agent 可以⼤幅缩短迁移周期、降低⼈为失误⻛险，让⼯程师能够将精⼒聚焦在架构决策和业务验证等更⾼价值的⼯作上。

本⽂将以⼀套部署在本地 IDC 机房中的 CRM 系统为例，采⽤控制台⼿动操作和AI Agent（Kiro）辅助迁移两种⽅式完成同⼀任务，并对迁移耗时与⼈⼯介⼊程度进⾏量化对⽐。

二、迁移对象：⼀套典型的 IDC 三层架构

本次迁移的对象是⼀套部署在企业⾃建 IDC 机房中的 CRM 客户关系管理系统，采⽤经典的三层架构，各组件以容器化⽅式运⾏在虚拟机上：

流量⼊⼝层：⽤户通过浏览器访问系统，请求⾸先到达⼀台独⽴的 Nginx 反向代理服务器，承担负载均衡和请求分发的职责。
应⽤服务层：反向代理将请求转发⾄应⽤服务器集群。前端容器托管静态⻚⾯资源，并将 API 请求转发给后端容器处理业务逻辑。两个容器分别运⾏在独⽴的虚拟机上，镜像统⼀从内部的 Docker Hub 镜像仓库拉取。
数据与存储层：后端通过 JDBC 连接部署在独⽴虚拟机上的 MySQL 数据库，存储客户、订单等核⼼业务数据。同时，⽂件类数据通过 NFS/SAN 共享存储进⾏读写。

具体规模上：MySQL 8.0 承载了约 10,000 条客户记录和 12,000 条订单数据，Spring Boot 提供后端 API，Nginx 负责前端⻚⾯与反向代理。

这是⼀套在中⼩企业中⾮常典型的应⽤部署模式——组件不多，但涉及⽹络代理、容器编排、数据库、共享存储和镜像管理等多个层⾯。

[图1]

三、⽬标架构与关键差异

3.1 亚⻢逊云科技⽬标架构

迁移的⽬标是在亚⻢逊云科技上利⽤托管服务重新构建这套 CRM 系统，⽤云原⽣组件替代 IDC 中的每⼀层基础设施：

流量⼊⼝层：由 Application Load Balancer（ALB）跨多可⽤区接收并转发请求，替代 IDC 中单点的 Nginx 反向代理。
应⽤服务层：前端容器和后端容器运⾏在 ECS Fargate 上，按容器粒度弹性伸缩；容器镜像存储在 ECR 私有仓库。后端服务通过亚⻢逊云科技 Cloud Map 实现服务注册与发现，替代 IDC 中依赖 Docker Compose ⽹络的服务发现⽅式。
数据与存储层：MySQL 迁移⾄ Amazon RDS，获得⾃动备份、故障切换等托管能⼒；⽂件存储从 NFS/SAN 切换到 Amazon S3。
运维与可观测性：容器⽇志⾃动输出到 CloudWatch Logs，通过EC2跳板机和 SSM 隧道实现安全的内⽹访问。

[图2]

3.2 关键差异：不只是”搬家”

IDC 到亚⻢逊云科技的迁移并⾮简单地将容器原样搬运到云端，两套环境在多个维度上存在本质差异，每⼀项都需要在迁移过程中针对性处理：

	维度	IDC	AWS
1	数据库地址	mysql:3306	RDS Endpoint:3306
2	Nginx DNS 解析	Docker 内部 DNS	AWS Cloud Map
3	服务发现	Docker Compose ⽹络	AWS Cloud Map
4	⽂件存储	NFS / SAN	Amazon S3
5	镜像仓库	内部 Docker Hub	Amazon ECR
6	⽇志收集	⼿动搭建	CloudWatch Logs

正是这些差异，决定了迁移不是⼀次简单的复制粘贴，⽽是⼀次需要理解两套架构语义的”翻译”⼯作。这也是 AI Agent 能够发挥价值的空间

四、⽅式⼀：控制台⼿动迁移——218 分钟的”时间⿊洞”

⼿动迁移需要按照严格的依赖顺序，在亚⻢逊云科技控制台上逐步完成以下⼗个步骤：

1. ⽹络基础 — 确认 VPC、⼦⽹，创建4个安全组及其互相引⽤关系

2. 镜像迁移 — 从 IDC 镜像仓库拉取镜像，重新打标签后推送到 ECR

3. 存储迁移 — 将 NAS ⽂件同步到 S3

4. 数据库迁移 — mysqldump 全量导⼊，配合 DMS CDC 增量追平

5. 服务发现 — 创建 Cloud Map 命名空间和服务注册

6. ECS 部署 — 编写 Task Definition，创建 Service 并关联服务发现

7. 负载均衡 — 创建 Target Group、ALB 及 Listener 配置

8. 验证测试 — 逐项检查健康状态、⽇志输出、功能可⽤性

9. DNS 切换 — 降低 TTL，将域名解析指向新环境

10. 清理旧环境 — 确认稳定后关闭 IDC 服务

每⼀步都需要在控制台上⼿动操作，填写⼤量参数。仅安全组配置就涉及 4 个安全组、多条⼊站规则和互相引⽤关系；ECS Task Definition 需要逐⼀填写镜像地址、环境变量、⽇志配置等⼗余个字段，任何⼀处填错都可能导致服务启动失败。

关于 IaC 基线：经验丰富的团队通常会使⽤ Terraform / CDK / CloudFormation 等基础设施即代码（IaC）⼯具来替代纯控制台操作，这确实能显著缩短重复部署的时间。但在⾸次迁移场景下，⼯程师仍需花费⼤量时间编写和调试模板——这恰恰是 AI Agent 可以⼤幅提效的环节。本⽂后续对⽐中，我们会看到 AI Agent 在”模板⽣成”本身的效率优势。

五、⽅式⼆：Kiro 辅助迁移——55 分钟，⼈⼯仅 15 分钟

Kiro 是⼀款 AI 原⽣ IDE，不仅能编写代码，还能直接执⾏亚⻢逊云科技 CLI 命令、⽣成 CloudFormation 模板、⾃动化部署并验证结果在 Kiro 的辅助下，⼗个⼿动步骤被压缩为七步：

1. 分析现有架构 — Kiro 读取 docker-compose.yml 和架构描述⽂档，⾃动梳理所需亚⻢逊云科技资源清单

2. ⽣成 CloudFormation 模板 — 基于分析结果，⾃动⽣成包含全部资源的 YAML 模板

3. 数据库迁移 — ⾃动配置 DMS 全量加载与 CDC 增量同步

4. 镜像迁移 — ⾃动执⾏拉取、打标签、推送到 ECR 的完整流程

5. ⼀键部署 — ⼀条命令部署 CloudFormation 模板，创建全部基础设施

6. ⾃动验证 — 逐项检查所有资源健康状态，汇报结果

7. 清理旧环境 — 确认后关闭 IDC 旧服务

⼯程师只需在三个关键节点介⼊：确认 CloudFormation 模板内容、确认数据库追平后执⾏切换、确认关闭旧服务。其余全部由 Kiro ⾃主完成。

5.1 Kiro 在迁移场景中的关键能⼒

架构⾃动分析：读取配置⽂件或架构⽂档，⾃动梳理所需亚⻢逊云科技资源及其依赖关系
动态引⽤⽣成：RDS Endpoint 等运⾏时才确定的值，通过 CloudFormation 内置函数动态注⼊，⽆需⼿动填写
区域⾃动适配：ECR 镜像地址、⽇志区域等参数⾃动匹配⽬标区域，避免跨区域迁移时的遗漏
敏感信息保护：数据库密码等参数⾃动设置为 NoEcho，不在⽇志中明⽂输出
部署后⾃动验证：逐⼀检查 ECS 服务、RDS 连通性、ALB ⽬标健康状态，全部通过才视为部署成功

5.2 ⼀个重要优势：可观测性

Kiro 的每⼀步执⾏状态和模型推理过程都清晰可⻅，运维⼈员可以实时监控 Agent 的决策链路。这种透明度对企业运维场景尤为重要：出了问题能快速定位，关键操作前能⼈⼯把关。

⼀段典型的交互示例：

⼯程师：帮我把 ./docker-compose.yml ⾥的服务迁移到亚⻢逊云科技美东区域，
数据库⽤ RDS，容器⽤ Fargate。
Kiro：已分析架构，识别到以下资源需求：
1 个 VPC（复⽤现有 vpc-xxx）
4 个安全组（ALB / Web / Backend / RDS）
1 个 RDS MySQL 8.0 实例
2 个 ECS Service（web、backend）
1 个 ALB + 2 个 Target Group
1 个 Cloud Map 命名空间
已⽣成 CloudFormation 模板 crm-migration.yaml（共 412 ⾏）。是否审核后部署？

六、效率对⽐：数据说话

两种⽅式完成同⼀迁移任务的耗时与⼈⼯介⼊程度对⽐如下*：

	阶段	⼿动迁移	Kiro 辅助
1	资源盘点 + 模板编写	40 分钟	23 分钟
2	镜像迁移	13 分钟	5 分钟
3	数据库迁移	23 分钟	10 分钟
4	基础设施部署	105 分钟	11 分钟
5	验证	17 分钟	3 分钟
6	旧环境清理	20 分钟	3 分钟
7	合计	218 分钟	~55 分钟（⼈⼯ ~15 分钟）

⼏个值得关注的数据点：

1. 基础设施部署是最⼤的效率瓶颈。⼿动迁移中，这⼀阶段耗费 105 分钟，接近总时⻓的⼀半——⼯程师需要在控制台上逐个创建安全组、服务发现、ECS 服务、负载均衡等资源，每个资源都有⼗余个参数需要填写。Kiro 通过⾃动⽣成 CloudFormation 模板并⼀键部署，将这个阶段压缩到 11 分钟，其中⼈⼯仅需 5 分钟审核模板内容。

2. 镜像迁移和数据库迁移的瓶颈在⽹络传输，⽽⾮⼈⼯操作。 AI Agent 的提速主要来⾃⾃动化命令编排——省去了⼿动拼接 ECR地址、配置 DMS 端点等繁琐步骤，但数据传输本身的耗时⽆法压缩。

3. ⼈⼯介⼊时间的下降最为显著。从⼿动迁移的 218 分钟全程操作，到 Kiro 的 15 分钟关键节点确认——⼯程师的⻆⾊从”执⾏者”转变为”决策者”，释放出的时间可以投⼊到架构优化、安全审计等更⾼价值的⼯作中。

七、关键技术细节

AI Agent 能⼤幅提升效率的核⼼，在于将原本需要逐个⼿动创建的亚⻢逊云科技资源，⾃动合并到⼀个 CloudFormation 模板中⼀次性部署。

7.1 模板⾃动⽣成的关键能⼒

资源间依赖关系。 CloudFormation 要求正确声明资源之间的依赖顺序。例如，ECS Web Service 必须在 ALB Listener 创建完成后才能启动，否则⽬标注册会失败。Agent ⾃动分析整套架构的依赖链，⽣成正确的 DependsOn声明，避免了⼿动梳理依赖时容易出现的遗漏。

运⾏时值的动态引⽤。 RDS 的 Endpoint 地址在实例创建完成前是未知的，⼿动操作时需要等待创建完成、复制地址、再粘贴到ECS 配置中。Agent 使⽤ !GetAtt 等 CloudFormation 内置函数⾃动处理这⼀问题，将数据库地址动态注⼊到后端服务的环境变量中：

Environment:
- Name: DB_HOST
Value: !GetAtt RDSInstance.Endpoint.Address
- Name: DB_PORT
Value: !GetAtt RDSInstance.Endpoint.Port

安全组的链式引⽤。本次迁移涉及 4 个安全组，它们之间存在链式引⽤关系：ALB SG → Web SG → Backend SG → RDS SG。⼿动创建时需要仔细规划创建顺序，先创建被引⽤的安全组，再回头补充引⽤规则。Agent 在模板中通过 !Ref 自动处理了这些引用，CloudFormation 会自行解析依赖顺序，一次性创建全部安全组及其规则。

7.2 数据库迁移：DMS CDC 实现近零停机

对于有持续业务写⼊的场景，简单的 mysqldump 导⼊会导致切换期间的数据丢失。Agent ⾃动配置了亚⻢逊云科技 DMS（Database Migration Service）来解决这⼀问题，实现增量同步：

1. 先通过 mysqldump 完成全量数据导⼊，建⽴基线

2. 配置 DMS CDC，从 IDC MySQL 的 binlog 持续追平增量数据

3. 实时监控 CDC 延迟，等待延迟降⾄秒级

4. 执⾏切换——停⽌ IDC 写⼊，确认数据完全追平，启动亚⻢逊云科技端服务

通过这⼀流程，实际停机窗⼝被压缩到分钟级。DMS 本身是临时性的迁移⼯具，切换完成后即可删除复制实例和迁移任务，不会增加⻓期运维负担。本次迁移中，约 22,000 条业务数据实现了⽆缝迁移，切换前后数据完全⼀致。

八、落地思考：从⼀次实验到企业实践

本次 CRM 迁移是⼀次相对理想的实验场景——架构清晰、数据量可控、⽆历史包袱。但要把 AI Agent 真正推⼴到企业的⽇常迁移⼯作中，还有⼏个问题值得进⼀步探讨：不同 Agent ⼯具该怎么选？哪些场景适合优先落地？⼯程师应当如何与 Agent 建⽴信任关系？以下是笔者在实践中的⼏点思考。

8.1 关于⼯具选型：不同 Agent 有不同侧重

在本次实践过程中，笔者除了 Kiro 之外，也测试了社区中其他⼏款 AI Agent ⼯具（如基于 IM 交互的 OpenClaw 等），它们在迁移任务中同样能够调⽤亚⻢逊云科技 API 完成资源创建和部署。横向对⽐下来，不同⼯具各有侧重，核⼼差异体现在三个维度：

	维度	IDE 型 Agent（如 Kiro）	IM 型 Agent（如 OpenClaw 等）
1	交互⽅式	IDE 内可视化，推理链路可⻅	即时通讯⼯具对话，轻量便捷
2	执⾏模式	关键节点暂停等待确认	偏向端到端⾃主执⾏
3	可观测性	每⼀步状态、模型思考过程完整可追溯	以结果汇报为主
4	⼈⼯介⼊粒度	细粒度，可在任意步骤接管	粗粒度，主要在任务起⽌点

对于企业⽣产场景，我们更倾向推荐 Kiro 这类具备⾼可观测性的⼯具，原因有三：

第⼀，企业迁移任务要求”可审计”⽽不仅是”可完成”。⽣产环境的基础设施变更往往需要留痕，供安全、合规、SRE 团队事后审计。Kiro 将每⼀次模型推理、每⼀条亚⻢逊云科技 CLI 调⽤、每⼀次资源变更都清晰记录在 IDE 中，与 CloudTrail ⽇志相互印证，形成完整的操作链路。相⽐之下，纯 IM 交互的 Agent 虽然便捷，但对话记录与底层操作之间的映射关系较弱，事后追溯成本更⾼。

第⼆，关键操作需要”⼈⼯把关”⽽不是”事后告知”。迁移过程中，诸如数据库切换、旧环境清理等操作⼀旦执⾏便难以回滚。Kiro默认在这些关键节点暂停、等待⼯程师确认，这种”⼈机协作”的边界设计更符合企业运维的⻛险偏好。过度追求端到端⾃动化的 Agent 在出错时，损失往往更难挽回。

第三，亚⻢逊云科技原⽣集成带来的⼀致性体验。 Kiro 对 CloudFormation、IAM、CloudTrail 等亚⻢逊云科技原⽣能⼒的理解更深⼊，⽣成的模板遵循亚⻢逊云科技 Well-Architected 最佳实践；在与 Identity Center、Organizations 等企业级治理组件协同时也更加顺畅。

简⽽⾔之：IM 型 Agent 在个⼈开发者的 POC 实验或开发环境快速搭建中体验⾜够流畅；但⼀旦涉及⽣产环境迁移、多⼈协作、合规审计，Kiro 的可观测性和可控性优势会显得更为重要。

8.2 适⽤场景的边界

AI Agent ⽬前最擅⻓的，是确定性⾼、有明确最佳实践的迁移场景——例如本⽂这类标准三层架构。对于以下场景，⼈⼯介⼊⽐例仍然较⾼：

架构复杂度极⾼的系统（如包含消息队列、⼤数据流⽔线、⾃研中间件）
合规要求严苛的⾏业（⾦融、医疗），需要⼈⼯逐项审计资源配置是否满⾜合规基线
有状态应⽤的深度改造（如需要重构数据模型、应⽤层代码改造才能上云的场景）

8.3 可靠性：从”能跑通”到”能放⼼⽤”

在本次实验中，当笔者提供了清晰的基础设施现状描述（docker-compose.yml、⽹络拓扑、⽬标区域等）之后，AI Agent的执⾏过程⼏乎是”⼀键完成”的——从模板⽣成、资源创建到部署验证，全程没有出现需要⼈⼯介⼊修复的报错。这个结果说明，在有明确输⼊和标准最佳实践的场景下，当前的 AI Agent 配合 CloudFormation 这类声明式⼯具，执⾏能⼒已经相当成熟。

基于这⼀观察，我们对 AI Agent 在企业迁移场景中的落地持积极的态度。笔者推荐的实践范式可以概括为”审核 + 演练 + 放⼿执⾏“：

审核阶段：由架构师和安全团队对 Agent 产出的 CloudFormation 模板做⼀次审查，重点关注安全组、IAM 权限、加密和备份策略等关键项——这⼀步通常只需要⼏⼗分钟
演练阶段：在预发或沙箱环境让 Agent 完整⾛⼀遍迁移流程，验证模板质量、切换流程和业务可⽤性
执⾏阶段：⼀旦模板通过审核与演练，就可以信任 Agent 的执⾏能⼒，让它在⽣产环境中⼀键部署、甚⾄批量复制到其他区域或环境

这套范式的核⼼思路是：把⼈的精⼒集中在”判断”上，把 Agent 的能⼒⽤在”执⾏”上。前两步的投⼊是⼀次性的，⽽后续的执⾏阶段，Agent 可以反复被调⽤——每⼀次复⽤，都是纯粹的减负。

这种价值在多环境部署、灾备搭建、批量迁移等场景下会被进⼀步放⼤：同⼀套模板在 dev/staging/prod 环境各跑⼀次、在多个亚⻢逊云科技区域各部署⼀份、为数⼗个业务单元各搭建⼀套标准环境……这些过去需要⼯程师反复”复制粘贴式”操作数天甚⾄数周的⼯作，现在可以在⼏⼗分钟内由 Agent 完成。

8.4 权限与安全边界

最后⼀个不容忽视的环节是权限治理。Agent 调⽤亚⻢逊云科技 API 需要相应的 IAM 权限，⽣产环境建议遵循最⼩权限原则：

为 Agent 创建专⽤ IAM Role，仅授予本次迁移任务所需资源的操作权限，任务结束后及时回收
⾼危操作（如删除资源、修改安全组规则、变更 IAM 策略）建议保留⼈⼯审批节点
开启 CloudTrail 并配置 EventBridge 告警，对 Agent 的异常操作实时感知
对 Agent 的会话上下⽂做好隔离，避免跨项⽬、跨环境的指令串扰

这些治理措施并不会削弱 Agent 的效率优势——它们只是让”放⼿执⾏”这件事变得更有底⽓。

九、总结：从”操作员”到”决策者”

通过这次 CRM 系统的迁移实践，我们看到 AI Agent 在本案例场景下将端到端迁移耗时从 218 分钟压缩⾄ 55 分钟，⼯程师的实际操作时间从全程参与降⾄约 15 分钟，约 22,000 条业务数据借助 DMS CDC 实现了⽆缝迁移。

但⽐效率数字更值得关注的，是⼯程师⻆⾊的转变——从逐个填写参数的”操作员”，变为审核⽅案、确认切换的”决策者”。AI Agent 接管了那些确定性⾼、重复性强的基础设施操作，将⼈的精⼒释放到架构设计、安全审计、业务验证等真正需要判断⼒的环节。

这⼀思路并不局限于 IDC 上云迁移。多区域部署、灾备切换、蓝绿发布、批量环境搭建——任何涉及⼤量重复性基础设施操作的场景，都是 AI Agent 的⽤武之地。当基础设施操作不再是瓶颈，⼯程团队才能真正聚焦于业务本身。

*本⽂所述测试数据基于特定测试环境，实际迁移耗时会因架构复杂度、⽹络环境、⼯程师熟练度等因素⽽异。

➡️ 下一步行动：

相关产品：

Amazon CloudFormation — 基础设施即代码服务
Amazon RDS — 完全托管的关系数据库服务
Amazon ECS — 完全托管的容器编排服务
Amazon DMS — 数据库迁移服务
Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客