Agent 主导的云迁移：On 如何用几周、而不是几个季度迁完 24 个服务

2026 年 10 月 8 日，Google Cloud 与运动品牌 On 联合发布了一份迁移公告。数字本身就是故事：On 用 AI Agent 把 24 个核心服务迁到 Google Cloud，单服务迁移时间从三个月压缩到两周；一支规模很小的内部工程团队完全靠这套 Agent 主导的方法自跑了 15 次迁移，每个服务的计划停机时间不到 5 分钟。On 的 CTO Narek Verdian 说得很直：AI 改变的是执行的「经济学」。这句话值得慢慢读——因为真正变便宜的是执行，不是判断。

24 个核心服务、每服务不到 5 分钟计划停机

数字为什么值得看

「AI 提效」这种说法人人会讲，但这份公告给的是可核对的数字：24 个核心服务、单服务三个月到两周、15 次内部自跑、每服务不到 5 分钟计划停机、20 多个代码仓库的部署模式在几小时内而非几天内被梳理清楚。另外还有一个反面对照——外部供应商报价 50 万美元，只为迁移其中一小部分微服务。当执行成本下降一个数量级，项目边界的算法就变了：以前「不值得做的迁移」现在可能值得做，以前必须外包的活现在可以自己吞下。还有一个二阶效应值得点明。当执行的边际成本降到这个程度，正确的问题就不再是「这次迁移值不值得做」，而变成「下一次该迁哪个」。按固定工时排预算的团队，会持续低估刚刚变便宜的那类工作；而重新给执行定价的团队，会发现一个此前「不经济」的积压任务清单。真正的约束从人力转向判断力：一周之内，人类能够有意义地评审并批准多少变更。

# The migration was not one clever prompt. It was four specialised
# agents with narrow, checkable jobs and a human gate at the end.
MIGRATION_AGENTS = {
    "analyzer":  "read every repo, map inconsistent deploy patterns",
    "generator": "produce infrastructure config + translation pipeline",
    "validator": "run tests and environment validation before cutover",
    "runner":    "apply infra changes, then stop for human approval",
}

# Key property: every agent hands its output to the next as an
# artifact a human can read, not as an opaque side effect.

四类 Agent 与一条流水线

这套系统不是一个聪明的提示词，而是四个职责很窄、产出可核对的 Agent：analyzer 读遍仓库、理清彼此矛盾的部署模式；generator 产出基础设施配置与转换管道；validator 在切换前跑测试与环境校验；runner 应用基础设施变更，然后在人类批准处停下。关键在于每一环交出去的都是「人能读懂的产物」，而不是一个不透明的副作用——这正是它可审计的原因。

# Step one: analysis at a scale a person cannot match by hand.
# On's engineers mapped deployment patterns across 20+ repositories
# in hours instead of days - that compression is the whole point.
def analyze(repos):
    manifest = []
    for repo in repos:                       # 20+ of them
        manifest.append({
            "repo": repo.name,
            "runtime": repo.detect_runtime(),
            "deploy_pattern": repo.infer_deploy_pattern(),
            "stateful": repo.has_persistent_state(),
            "cutover_risk": repo.estimate_cutover_risk(),
        })
    return manifest           # the input for everything downstream

Agent 负责机械步骤，人类负责不可逆的决定

有界执行：把 Agent 的权限画在一条线上

公告里最关键的设计词是「有界执行」。Agent 拿到的任务是预先定义过的、带有明确检查的；一旦触及后果性变更，流程必须停下来等人批准。工程师负责复核生成的代码、执行基础设施变更、授权生产切换。这不是「AI 自己发布上线」，而是「AI 把机械步骤做到底，人只做那几件不可逆的决定」。这条边界画得越清楚，Agent 能安全接管的面就越大。

# Step two: generate the boring, mechanical parts. Config
# scripting, data replication and environment validation are
# exactly the work agents are reliable at - and exactly the work
# that eats a migration budget.
def generate(entry):
    return {
        "iac":            gen_terraform(entry),      # infra as code
        "replication":    gen_data_replication(entry),
        "env_validation": gen_env_checks(entry),
        "translation":    gen_pipeline(entry),       # legacy -> target
    }

# Nothing here is clever. That is the point: mechanical work should
# be expensive for nobody and identical every single time.

为什么机械工作最适合交给 Agent

公告点名了三类被卸载给 Agent 的活：配置脚本、数据复制、环境校验。这三件事的共同点是枯燥、重复、有明确正确答案——也恰恰是迁移预算最容易漏水的三个洞。把这类工作交给 Agent 的价值，不只是快，而是「每次都一模一样」：人写三十遍配置脚本会手抖，Agent 不会。至于「20 多个仓库的部署模式在几小时内理清」，那是人手工做不到的规模，不是人做慢一点的问题。审计这条论证常被低估。受监管环境很少只问「改动生效了吗」，它问的是谁改的、有什么证据支撑、几个月后你如何自证。一个每次都吐出同样形态产物的 Agent，比一个上季度用略不同方式解决类似问题的人类，要好审计得多。在这个语境下，输出标准化不是审美偏好，而是让审计轨迹可读的前提。

# Step three: validation runs before any production change.
# 'Bounded execution' means the agent's authority stops at a line
# the team drew in advance - and it stops there every time.
def validate(artifact):
    checks = {
        "unit_tests":   run_tests(artifact.repo),
        "integration":  run_integration_suite(artifact.repo),
        "env_parity":   compare_env(artifact.source, artifact.target),
        "data_sample":  verify_sample_rows(artifact.replication),
    }
    failed = [k for k, ok in checks.items() if not ok]
    if failed:
        raise ValidationFailed(failed)   # fix and re-run, never skip
    return True

先重想「工作怎么做」，而不是自动化已有的流程

先重想工作，再谈自动化

公告里有一句话容易被略过，但方向性最强：他们选择「从根上重想工作怎么做」，而不是「把一个已经存在的流程自动化」。差别很大。自动化的天花板是旧流程的效率，重想的起点才是新约束下的最优解。On 也把内部方法论外溢到了组织——向全体员工铺开 Gemini Enterprise，让团队自建用于高管汇报、市场调研、排期、入职的无代码 Agent。同一套能力，从基础设施迁移复用到内部流程。On 的做法还给出一条排序规则：不要从「你最想自动化」的流程开始，而要从「完成标准最精确」的那个开始。带测试套件的迁移步骤是好候选，因为 Agent 的产出可以被机械校验；依赖干系人审美的步骤则是最差的第一个候选，无论它多耗时。先用清晰的工作证明你管得住，再去换取自动化模糊工作的资格。

# Step four: the human gate. Engineers ran infrastructure changes
# and authorised production cutovers. Consequential changes stay
# with people; the agent never approves its own release.
CUTOVER = {
    "planned_downtime_budget_seconds": 300,   # under five minutes
    "requires_human_approval": True,
    "approver": "on_call_engineer",
    "rollback": {"automatic": True, "trigger": "health_check_fail"},
}

def cutover(service, approval):
    if not approval.signed_by_human:
        raise NeedsHuman("cutover approval missing")
    return service.promote(downtime_budget=CUTOVER["planned_downtime_budget_seconds"])

# The economics shift because *execution* got cheap, not because
# judgement got automated. Those are different claims.

一份可复用的迁移手册

如果你打算照做，按这个顺序推进比较稳。第一，先跑分析而不是先写代码：让 Agent 遍历所有仓库，产出运行时、部署模式、是否有持久化状态、切换风险的清单。第二，让 Agent 生成全部机械产物，人来评审。第三，把校验做成硬闸门——测试、集成分、环境一致性、数据抽样，失败就修、绝不跳过。第四，生产切换设在人工审批点之后，并预先定好停机预算与自动回滚触发条件。第五，把整套流程固化成蓝图，下一次迁移直接复用，而不是重新发明一遍。