行业参考 · 零售 · IT · 证据 E1
On用多agent架构完成24个核心服务云迁移并全员部署Gemini Enterprise
这是公开报道的其他企业案例，不是 Alan 交付的项目。内容由 AI 收集整理，以原文为准。
企业遇到的问题
企业全球扩展时基础设施碎片化，复杂微服务迁移到云成本高、周期长、易影响零售运营，同时需要统一数据与AI底座以支撑增长。
概要
瑞士运动品牌On使用多agent架构将24个核心服务迁移到Google Cloud，迁移时间从每服务3个月降至2周，15次迁移完全由内部工程师in-house完成，每次计划停机<5分钟；外部供应商曾对一小部分微服务报价50万美元，内部团队用agent完成更大范围且无需外部实施资源；随后全员部署Gemini Enterprise，员工构建自定义no-code agents用于高管报告、市场研究、排期、入职等。
原文写明的事实
- On是高端运动品牌，面临将24个核心服务迁移到Google Cloud的挑战
- 采用多agent架构，迁移时间从每服务3个月降至2周
- 内部工程师使用agentic工作流在数小时内映射20多个代码仓库中复杂不一致的部署模式
- 15次迁移完全由内部工程师in-house完成，每次计划停机<5分钟
- 外部供应商曾对迁移一小部分微服务报价50万美元
- 随后全员部署Gemini Enterprise，员工构建自定义no-code agents（高管报告、市场研究、排期、入职等）
- 迁移中agent负责配置脚本、数据复制、环境验证等机械任务，工程师审查生成代码并授权生产切换
怎么做的
- 输入：代码库、基础设施配置、云迁移任务、员工需求
- 处理：多agent系统分步完成代码库分析、基础设施配置生成、翻译管道创建和测试验证，人工审查后切换
- 数据：20多个代码仓库、部署模式、云环境配置、员工业务数据
- 动作：映射部署、生成配置、复制数据、验证环境、自动执行员工自定义agent任务
- 输出：云迁移完成、日常员工agent（高管报告、市场研究、排期、入职）
如果你也想做：复制评估
AI 初评，供参考。具体能不能做，要看你企业的数据、流程和人。
- 难度：高（需要配置 Skill / Connector）
- 需要的能力：基础设施配置生成Skill、代码迁移Skill、员工报告生成Skill
- 需要接的数据/系统：云平台API、代码仓库、企业SaaS
- 仍需人工的环节：工程师审查生成代码；人工授权生产切换
- 风险：云迁移错误导致生产停机；AI生成基础设施配置的安全合规风险；外包替代项目中的责任归属
- 原文没披露的：依赖Google Cloud平台；移动云迁移技术门槛高；内部员工no-code agent建设效果未量化
云迁移任务分解、代码生成和环境验证有真实案例，但属技术门槛高的项目，复制需云平台集成和人工把关。
来源
证据说明：Google Cloud官方新闻稿，数据由企业提供