一句话：agent 不是在写业务文案，而是在搬真正的工程
2026 年 10 月 8 日，高端运动品牌 On 与 Google Cloud 联合宣布，用一套多智能体架构把 24 个核心服务迁移到 Google Cloud，单服务迁移周期从传统方式下的约 3 个月压到约 2 周。一个不大的内部工程团队完成了 15 次完全自主的迁移，单次生产切点停机控制在 5 分钟以内。最刺眼的一个对照是：一家外部集成商曾对其中一小部分微服务报价 50 万美元，而 On 用内部团队把更大的盘子更快做完了。这不是一次营销话术，而是 agent 进入「硬工程执行层」的少见样本。
怎么做：把迁移拆成四段，人只批切点
具体打法上，On 的多智能体系统把迁移拆成几个专门步骤：代码库分析、基础设施配置生成、翻译管线创建、测试验证。工程师负责审阅 agent 生成的代码、实际执行基础设施变更、并授权生产切点；agent 拿到的是边界清晰的子任务与明确检查点，真正有后果的动作仍留在人手里批。官方强调，这种做法把配置脚本编写、数据复制、环境校验这类机械活甩给 agent，既保护了产品工程路线图，也去掉了对外部实施团队的依赖。
为什么值得注意：基础设施迁移是更高难度的场景
过去企业落地 agent 的故事多集中在写文案、做客服、跑报表这类相对可控的环节。云迁移则不同：它直接动生产环境，错一步就是停机与数据风险。On 的价值在于证明了 agent 可以进入这类高风险工程，而且把停机窗口压到分钟级。它也顺势把 Gemini Enterprise 铺到了每一位员工，让非技术同事也能搭无代码 agent 处理经营报告、市场调研、排程与入职等日常。迁移只是开头，统一的数据、算力与 AI 底座才是后续规模化的前提。
辩证看：外部报价对比有营销色彩，边界仍在
需要打折看的地方有两点。其一，那个 50 万美元的对比来自厂商口径，且只覆盖迁移的一小部分，作为成本参照要谨慎；其二，agent 在 On 的方案里仍受人工批切点约束，关键决策没有放手给模型，这说明真正规模化的前提是治理与审批链路到位，而不是模型自己跑完全程。至于更广泛的行业可复制性，还要看更多企业在类似迁移里的独立验证。
行业含义：agentic 转型的可复用蓝图
把 On 与今年的企业 agent 部署放在一起看，差异很明显：Orange Spain 走的是公民开发者造上千个业务 agent，福建移动与金龙走的是运营商交钥匙方案，而 On 走的是「先把数据与算力底座统一，再用 agent 跑具体工程」的路线。后者给了一个可复用蓝图——agent 不一定要先去替代人，也可以先把最耗时的工程搬运活接管掉，再用省下的时间做更高价值的决策。
结语
On 用多智能体把单服务迁移从约 3 个月压到约 2 周，是 agent 进入真实工程执行层的一次硬样本。它的参考价值不在某个百分数，而在那条路径：统一底座、拆分机械活、把切点审批留给人。至于这套路径能否在更多行业的迁移与运维里复制，仍要看后续落地与独立核验。