AI 能独立完成“工程级”云迁移吗?我们用两个真实案例测了测豆包新模型

2026 年，大模型的能力边界正在被重新定义。

过去两年，从文案生成到代码补全，从会议纪要到数据分析，AI 助手已渗透进日常工作的毛细血管。但一个关键问题始终悬而未决：AI 能否独立承担一项真正复杂、长链路、高风险的“工程级”任务？

这里说的不是写一段代码，也不是生成一份报告草稿——而是像一名资深架构师那样：读代码、做评估、对产品、算成本、写方案、出交付物，全程自主闭环，最终产出一份可直接进入团队评审的生产级成果。

云迁移，恰好是这样一块“试金石”。

它够复杂：网络、计算、存储、数据库、缓存、负载均衡、安全组、IAM、DNS……一层漏掉，方案作废。
它要求绝对准确：规格映射不能错、可用区不能错、配额必须核实——编一个不存在的实例类型，整个方案就废了。
它需要工具调用：没有哪个模型能靠“记忆”记住所有云产品的实时规格、价格和配额，必须会查、会用、会基于查询结果调整决策。
它最终要交付代码：不是泛泛而谈的“建议”，而是可执行的 Terraform IaC，terraform plan 能跑通的那种。

换句话说：云迁移是一场“开卷考试”，但考题是一整座 AWS 仓库，考的是 AI 的长程推理、事实求真、工具调用、代码生成，以及在现实约束（配额不足、功能不支持）下自行修正方案的自适应能力。

2026 年 7 月 15 日，字节跳动豆包团队在火山方舟平台正式上线了 Doubao-Seed-Evolving——一款统一 Model ID、无感升级、1M 超长上下文、专为 Coding 和复杂 Agent 场景设计的推理模型。官方称它不是“又一个版本迭代”，而是一种“持续进化”的新范式。

那么，当它面对一套真实的 AWS Terraform 仓库，需要自主完成 “评估 → 对标 → TCO → 方案 → 实施 → 报告” 六阶段云迁移全流程时，它究竟能做到什么程度？

是只能生成一篇“看起来像那么回事”的文本方案，还是能像一名真正的云迁移专家那样——查规格、校配额、算价格、写 IaC、做割接方案，并在遇到配额不足时自己改方案？

如果让 Doubao-Seed-Evolving 在不使用预置 Skill 或专家经验库的情况下，仅依靠模型自身的推理和任务执行能力，能否自主完成一次数据库跨云迁移？

为了回答上述问题，我们设计并执行了两个实测案例。以下是完整测评实录。

评测对象

Doubao-Seed-Evolving（ReAct Agent + Function Calling）

评测任务

案例一：将一个真实 AWS Terraform 仓库整体迁移至火山引擎，覆盖评估、对标、TCO、方案、实施、报告全流程；规格/可用区/库存/价格全部通过火山引擎官方 OpenAPI 实时查询，全程 trace 可审计。
案例二：将一个真实的阿里云 RDS PostgreSQL 实例迁移至腾讯云，Agent 直接调用云厂商 CLI，完成创建实例、创建 DTS 任务、跑预检查、启动全量迁移、执行数据校验，全程在真实账号中产生真实资源。

核心结论

上述两个案例测评显示，Seed-Evolving 能像云迁移专家一样：

调官方接口查规格、核验真实在售库存、当场纠正不存在的实例类型、写可执行 IaC、产出割接方案；

在无任何额外提示的情况下，成功完成数据库跨云厂商迁移。

但同时，模型面对无法获取的信息（如计费、密钥、网络等问题）尚无法自主处理，仍需人工介入判断。

一、为什么说云迁移对模型是一次更为硬核的测评

云迁移是检验 Agent 工程能力的绝佳场景，因为它具备四个硬约束，任何一项靠“猜”都会导致任务失败：

事实准确性：规格映射、可用区、库存、价格都不能编。编一个不存在的规格，terraform apply 就会失败。
工具调用：模型不可能记住所有云产品的实时规格与库存，必须会查官方接口。
代码生成：最终产出必须是可执行的 Terraform，而非泛泛的架构描述。
长程任务约束：模型需调用真实云账号接口，获取资源列表并规划迁移步骤，直接操作源端和目标端，并进行数据校验，中间任一环节出错即失败。

维度	案例一：AWS → 火山引擎	案例二：阿里云 → 腾讯云
任务性质	规划、对标、TCO、IaC 与割接方案	真实创建实例、配置 DTS、全量迁移、校验
是否操作云环境	否，只读查询与产出物	是，创建按量计费 PostgreSQL 与 DTS 任务
核心考点	事实准确性、抗幻觉、规格自修正	端到端执行、报错修复、数据一致性、边界诚实
工具方式	封装工具调用火山引擎 OpenAPI	直接使用腾讯云 `tccli`
验证方式	trace 审计 + 客观评分器	DTS 状态、数据库列表、独立校验任务

二、评测环境准备

此次测评，我们选择的工具是字节的coding agent TRAE，并在其中配置了 doubao-seed-evoliving模型的API。

2.1 开通 Agent Plan

字节火山方舟开通Agent Plan，并获取到对应的密钥；

2.2 配置TRAE模型

点击“配置”-“模型”，选择服务商，然后填写模型ID，API密钥

配置完成后，在TRAE的模型选项中，看到seed-evolving模型，即做好了准备工作。

三、案例1 AWS Terraform仓库迁移到火山引擎

3.1 评测目标

本案例为纯规划对标类，不实际创建云资源，重点考察模型的 事实准确性与抗幻觉能力。核心问题：一个会推理的 Agent，在“事实不能编”的工程任务面前，到底靠不靠谱？

3.2 评测设计

给定一个真实的 AWS Terraform 样例仓库，并刻意埋入以下“坑”：

NAT 单点
Redis 单节点
密码硬编码
IAM 权限过大

同时提供一份业务约束 brief（含 RTO/RPO/成本/P95/PIPL 等 15 项硬约束）。任务：将该仓库整体迁移至火山引擎，覆盖全流程。

3.3 评测过程及分析

全程任务链路分为六大步骤：

第 1 步：评估源端网络读取 AWS Terraform 文件与 MIGRATION_BRIEF，还原架构，盘点出 14 项兼容性问题与 8 项风险，并准确识别出源仓库中埋设的 NAT 单点、Redis 无高可用等问题。

优点：先读代码再下结论，不凭描述臆测；问题与风险结构化盘点（带溯源字段），并将业务硬约束纳入评估。不足：14 项兼容性问题未在评估阶段明确分级（严重程度、是否阻塞割接）。

第 2 步：产品对标（Product Mapping）调用 map_*（ECS/RDS/Redis/存储）、list_az、check_feature_support，将 AWS 服务逐一映射至火山产品，规格与 AZ 均经工具求证。

优点：规格全部查官方在售清单；主动核验 AZ 数量（源 3 AZ，目标北京区实际 4 AZ）；对 ACM、ElastiCache、S3 智能分层等特性判为“无完全对等”并提供替代方案。不足：曾误写规格 ecs.g3i.large，后在第 3 步被接口拦截；部分特性校验基于文档知识库而非结构化 API，存在推断误差；对 IAM、KMS、监控告警等细粒度权限模型映射深度不足。

第 3 步：配额与成本校验调用 check_quota、get_price、estimate_monthly_cost，遇到配额不足自动调整规格或分布，核算 TCO，未知价格如实标注。

优点：最关键的自修正发生在此步

ecs.g3i.large 被 DescribeAvailableResource 返回 InvalidInstanceType.NotFound，模型当场改为真实在售的 ecs.g3il.large，未硬写、未绕过；逐区查库存（a/b/c 全 Available），确认充足后才定稿；
价格诚实——RDS（3.25 元/小时）和云盘（0.0021 元/GB/小时）为真实刊例价，ECS/Redis 因 API 缺计费项编码，返回 pricing_available=false 并附官方计算器链接，未编造单价。

不足：TCO 的 2556.46 元/月仅为“可审计下限”，仅含 RDS+系统盘，ECS 作为成本大头未纳入，降本 25% 目标尚无法定论；网络流量、NAT/CLB、TOS 等成本项均跳过，完整度偏低。

第 4 步：方案设计基于对标与配额结果，输出迁移方案。

优点：围绕真实 4 AZ 设计跨可用区高可用，而非照搬源站 3 AZ；数据迁移路径明确（DTS 全量+增量），割接有明确窗口与回滚决策点；消除 NAT 单点、Redis 升级主备、密码改 Secrets Manager、IAM 最小权限。不足：RTO≤1h/RPO≤15min 为设计承诺，未经演练验证；双 AZ 方案未充分论证跨 AZ 延迟与故障切换检测时间是否能满足 P95<60ms；部分替代方案标注“需控制台操作/应用侧回归”，但未给出明确的人工动作清单与责任人。

第 5 步：实施交付（生成目标 Terraform）经五轮调研后，生成 target.tf 与割接 Runbook。

优点：IaC 分层完整（网络/计算/负载/数据/存储/身份/可观测/DNS），0 个 aws_ 残留；真正理解源仓库“坑”点，将 user_data 中的 S3 endpoint 改写为 tos-s3-cn-beijing.volces.com，AWS_REGION 改为 cn-beijing，非机械平移；Runbook 按预检/同步/割接/验证/回滚五阶段组织，并标注“工具验证”或“经验判断”。不足：“terraform plan/apply 可直接落地”未被真实验证——案例一全程未实际执行 apply，该结论为推断而非实证。

第 6 步：产出报告与客观打分模型生成结构化 JSON + Markdown + 可视化 HTML + 客观评分器自动校验，产出一份可进入团队评审的完整报告（含前后架构图/TCO/测试验证）。

优点：交付物为结构化数据（JSON）+ IaC + Runbook + trace，可审计、可复现；评分器从 6 个维度机器校验（结构/IaC/幻觉/约束/Runbook/自修正）；结果诚实——FAIL=0，15 项约束中 13 met / 2 partial，未将 partial 包装为 met。不足：评分器为“自评”，工具与标准均由同一方设计，缺少第三方/人工复核；“测试验证”在报告中仅为章节，实际未做端到端测试。

四、案例2 阿里云PostgreSQL 迁移至腾讯云 PostgreSQL

4.1 评测目标

考验模型端到端执行数据库迁移的能力。

4.2 评测设计

源端：阿里云 RDS PostgreSQL 17.0（2 核 4GB / 50GB），通过公网地址迁移 student1、student2 两个库。
目标端：腾讯云 TencentDB for PostgreSQL 17.10（pg.it.medium4 / 50GB CLOUD_SSD），内网连接。
迁移服务：腾讯云 DTS，全量模式，medium 规格。