云端 Agent 基础设施：跟桌面有什么不同，我们学到了什么

这篇文章回答的问题：把一个桌面 Agent 搬到云端运行，基础设施层面到底哪些东西会彻底改变，以及 CREAO 是怎么一个个解决的？

这篇文章应该回答但没回答的问题：snapshot 存储成本多少？热交换失败重试时用户状态怎么办？API bridge 成为单点故障怎么兜底？在多 region 场景下 snapshot 一致性如何保证？

🧠 运行时模型：这篇文章里的东西到底跑在哪里？

Peter Pang 描述的系统有三个明确的进程/信任边界，搞清楚它们各自在哪里运行，才能理解整个设计的意图：

🏗️ 核心架构拆解：两个 Lesson 的工程实现

Lesson 1：慢变快分离 — Sandbox Snapshot + Runner 热交换

问题的本质是变更频率不匹配。用户环境（pip install 的包、下载的数据、写的脚本）变更频率低（用户主动触发），平台 Runner 代码变更频率高（一天部署多次）。如果打包成一个 artifact，每次 Runner 更新都要重建 snapshot，用户环境就被破坏了。

Peter Pang 用了一个精妙的操作系统类比：

内核会更新。你的 home 目录不会。你不会为了装一个安全补丁就把硬盘格了。

The kernel changes. Your home directory does not. You do not wipe the disk to install a security patch.

热交换的 5 步序列（300ms 完成）：

Lesson 2：凭证外置 — API Bridge 模式

安全模型的核心假设：sandbox 内的代码已经被攻破了。不是"可能被攻破"，是"已经攻破了"。在这个假设下设计。

🔧 代码级细节：如果你要自己实现

Runner 热交换的核心代码逻辑（伪代码，基于原文描述推断）：

# 热交换 Runner — 300ms 完成的原子操作
function hotSwapRunner(sandbox, newRunnerPath):
    # Step 1: 拷贝到临时位置
    tmpPath = sandbox.fs.tempDir() + "/runner_new.js"
    sandbox.fs.copy(newRunnerPath, tmpPath)

    # Step 2: 语法校验
    exitCode = sandbox.exec("node --check " + tmpPath)
    if exitCode != 0:
        killSandbox(sandbox)  # fail-fast
        return BOOT_FRESH

    # Step 3: 原子交换
    sandbox.exec("chattr -i /opt/runner/runner.js")     # 解锁旧文件
    sandbox.exec(f"cp {tmpPath} /opt/runner/runner.js")  # 覆盖
    sandbox.exec("chattr +i /opt/runner/runner.js")     # 重新锁定
    sandbox.exec("rm /usr/bin/chattr")                  # 隐藏工具本身

    # Step 4: 清除 V8 编译缓存
    sandbox.exec("rm -rf /home/user/.cache/v8-compile-cache/*")

    # Step 5: 验证成功 → 运行结束后 re-snapshot
    return SWAP_SUCCESS  # 触发 re-snapshot

API Bridge 的 JWT 签发与验证：

# Control Plane: 签发 per-run JWT
function mintRunToken(run):
    return jwt.sign({
        sub: run.userId,
        app: run.appId,
        session: run.sessionId,
        exp: now() + run.maxDuration  # 仅覆盖运行窗口
    }, PLATFORM_SECRET)

# API Bridge: 验证并注入凭证
bridge.handleRequest = async (req) => {
    # 第一层：网络层 — 非内网 IP 直接丢弃
    if not isInternalIP(req.sourceIP):
        return 403

    # 第二层：JWT 验证
    claims = jwt.verify(req.headers["X-Run-Token"], PLATFORM_SECRET)
    if claims.exp < now():
        return 401

    # 从 vault 解析该用户的 OAuth token（sandbox 永远看不到）
    userToken = await vault.resolve(claims.sub, req.targetService)

    # 注入 token，转发请求
    response = await fetch(req.targetUrl, {
        headers: { Authorization: `Bearer ${userToken}` }
    })

    # 返回 response body（不含 token）
    return response.body
}

⚖️ DIY 对比：手搓版 vs CREAO 官方版

🎯 选型决策框架：什么时候该考虑这种架构？

🚫 诚实限制：这篇文章没告诉你的

💬 金句

Cloud agent infrastructure has none of those luxuries.

云端 Agent 基础设施没有这些奢侈品。

The security model has to assume the code inside the sandbox is already compromised, not hope against it.

安全模型必须假设 sandbox 内的代码已经被攻破了，而不是祈祷不会。

An agent on a laptop is bound to the laptop. An agent in the cloud is a function the rest of your stack can call.

笔记本上的 Agent 绑定在笔记本上。云端的 Agent 是你的技术栈可以调用的一个函数。