跳转至

云端 Agent 基础设施两条硬经验：CreaoAI 状态/代码解耦 + 凭据隔离

Ch04.098 云端 Agent 基础设施两条硬经验：CreaoAI 状态/代码解耦 + 凭据隔离

📊 Level ⭐⭐ | 15.9KB | entities/ai-techliwen-creaoai-cloud-agent-infrastructure-two-lessons-20260606.md

云端 Agent 基础设施两条硬经验：CreaoAI 状态/代码解耦 + 凭据隔离

Source: AI 技术立文 WeChat MP, 翻译 CreaoAI 联合创始人, 2026-06-06. URL: https://mp.weixin.qq.com/s/dz7bA_0Ki--izCUKp_krUw

→ 原文存档

摘要

CreaoAI 联合创始人在 2026 年 6 月分享了云端 Agent 基础设施的两条硬经验：① 把变化慢的和变化快的分开——用户环境（包、文件、配置）冻结到用户主动改变为止，平台 Runner 代码则通过 hot-swap 热替换不依赖状态；② 把凭据隔离在执行边界之外——长生命周期凭据绝不进入沙箱，沙箱通过 API bridge 桥接层 + IP 白名单 + 短期 JWT 三层校验发起外部调用。这两条经验的核心是判断标准：对于云平台上持久化的每一样东西，都要问清楚「谁控制它的变更节奏」。

核心要点

  • 桌面 vs 云端 Agent 的根本差异：桌面端一个用户一台机器一个进程，状态、密钥、生命周期都在同一受信边界里；云端 Agent 跑在每次全新启动的沙箱里，底下多租户共享硬件，触发源可能是定时任务/HTTP 请求/另一个 Agent，用户多半不在线。
  • 沙箱快照（sandbox snapshot）解决可复现性：用户满意环境后冻结成快照，每次运行都从同一份快照启动，桌面框架做不到（pip install 装的版本六个月后不同）。
  • 第一版方案的失败：把 Runner 代码（管理 Agent 的运行时库）也打包进快照镜像，用户不动 Runner 也要跟着发版，第一版方案是「启动时检查 Runner 版本不一致就丢快照重建」，代价是每次部署后第一次运行要重建环境——但这违背了「环境会保持冻结直到你主动改」的隐含约定。
  • 教训一：按所有权解耦。借鉴操作系统「内核升级不影响 home 目录」的思路，在沙箱上画同样的线：用户环境从冻结快照加载 + 单独 hot-swap Runner。
  • Hot-swap 流程（5 步约 300ms）：
  • 把新版 Runner 放到沙箱内临时目录
  • 用 node --check 做语法校验
  • 原子替换：解锁旧 Runner 不可变标志 + 复制新文件 + chattr +i 锁上 + 把 chattr 命令本身藏起来防止沙箱代码反向解锁
  • 清掉 V8 编译缓存（/home/user/.cache/v8-compile-cache/*）
  • 任一步出错直接杀掉沙箱换新重试，不允许半升级状态

运行成功后重新生成快照把更新后的代码固化到用户镜像，后续运行不再需要替换。 - 教训二：凭据在宿主侧，永不进 Agent。沙箱内的代码已经不可信（LLM 根据可能带恶意的 prompt 生成），长生命周期凭据绝不进沙箱；Agent 需要调用外部认证服务（Slack/GitHub/用户 API）时，向沙箱外的 API bridge 桥接层发本地 HTTP 请求，桥接层在宿主侧挂上 OAuth 令牌再转发。 - 桥接层两层校验： - IP 白名单：桥接层只接受沙箱宿主所在内网网段，外部拿到地址也没用 - 短期 JWT：沙箱启动时平台签发专属于本次运行的令牌（限定用户/应用/会话/有效期），每次调用桥接层都要出示，攻击者拿到的也只是随运行结束即失效的令牌

即使沙箱被劫持，没有长期凭据可以泄露。 - Prompt Injection 失败场景的具体分析：假设明天 prompt injection 成功让 Agent 把 process.env 发到外部 webhook，攻击者拿到的也只是一个短期 JWT（只在内网有效、运行结束即作废）。这个性质是能在共享基础设施上放心跑不可信代码的底气。 - 底层设计模式四条原则： 1. 状态在沙箱里，冻结到用户主动改变为止 2. 代码可热替换，不依赖状态 3. 凭据在宿主侧，永远不进 Agent 4. 同一执行管道服务所有调用方（UI 触发/定时触发/API 调用走同一 executeAgent 函数） - 统一 executeAgent 函数的设计价值：UI 点击/定时触发/API 调用走同一套逻辑，计费、额度扣减、日志、可观测性信号不管谁触发走同一套；新增触发方式只是加一条路由。Agent 本身不知道、也不需要知道是谁启动了它。 - 核心判断框架：「Agent 本质上是一个带自然语言接口的函数。实现归用户，触发面/运行时/安全边界归平台。关键在于把这些层建好，让每一层按自己的节奏演进，并且赶在别人之前找到层与层之间的缝隙。」

深度分析

1. 桌面 → 云端 Agent 的信任模型差异

桌面端 Agent 的信任模型是「用户的机器 = 受信边界」，密钥在环境变量里、文件写在本地、终端一关进程就死。 这一切在云端被反转：多租户共享硬件 + 沙箱每次全新启动 + 触发源不一定是人 + 沙箱内代码由 LLM 根据可能带恶意的 prompt 生成。 这个差异的本质是 信任锚点变了：桌面端信任「用户」和「用户机器」，云端必须假设「沙箱内一切默认不可信」。给做云端 Agent 系统的架构师的具体含义是：所有在桌面端可以省略的「可信边界检查」在云端都必须显式建模——凭据隔离、API bridge、IP 白名单、JWT 校验都不是可选项而是默认配置。

2. 第一版失败的根本原因是「变更节奏冲突」

CreaoAI 第一版方案失败的根本原因不是技术问题，而是「用户不动 vs 平台每天发版」这两个变更节奏冲突。 当两个不同主体（用户 vs 平台）控制同一制品（沙箱镜像）时，每次部署都陷入两难选择：要么容忍过时的 Runner，要么毁掉用户辛苦搭建的环境。给做多租户系统的架构师的核心启示是：识别「变更所有权冲突」比识别「技术 bug」更重要。第一版方案的修复方式（启动时检查版本不一致就丢快照重建）表面上能工作，但破坏了隐含的产品契约——「你的环境会保持冻结直到你主动改」。这种契约破坏比技术错误更危险，因为它会持续累积用户的不信任。

3. 借鉴操作系统「内核 vs 用户态」分离的工程价值

CreaoAI 借鉴了操作系统的「内核升级不影响 home 目录，打安全补丁不需要格式化硬盘」思路。 这个类比不只是命名上的优雅，而是揭示了「内核 vs 用户态」分离的工程价值：内核（平台控制、变更频繁、不能影响用户态）和用户态（用户控制、变更稀疏、必须被保护）在同一个进程空间但通过权限边界隔离。Hot-swap 设计就是把这条原则应用到云端 Agent——用户环境从冻结快照加载（user space），单独 hot-swap Runner（kernel space），两者通过文件系统不可变标志（chattr +i）+ 命令本身藏起来防止反向解锁来强制隔离。 给做云端系统的启示是：借鉴成熟系统的隔离原则比从零设计新边界更可靠。

4. 凭据隔离的「不可信代码 + 短期凭据」组合

CreaoAI 的凭据隔离设计有一个非常硬的安全特性：即使 prompt injection 成功让 Agent 把 process.env 发到外部 webhook，攻击者拿到的也只是一个短期 JWT——只在内网有效、运行结束即作废。 这是个非常重要的安全模型设计：传统桌面 Agent 一旦被攻破，攻击者能拿到所有长期凭据（环境变量里的 API key、token 等）造成持续性损害；CreaoAI 设计下被攻破只能拿到当次运行的临时凭证，运行结束攻击链自动断裂。给做多租户 Agent 系统的启示是：把凭据生命周期跟 Agent 运行生命周期绑定——运行启动时签发短期 JWT、运行结束 JWT 自动失效，这是「不可信代码 + 短期凭据」组合的根本安全价值。

5. IP 白名单 + JWT 双层校验的纵深防御

桥接层用了两层校验：① IP 白名单（仅沙箱宿主内网）做网络层隔离；② 每次运行的短期 JWT 做应用层身份校验。 两层校验的纵深防御价值在于：① 攻击者必须同时突破网络层（拿到内网 IP）和应用层（伪造 JWT 签名）才能成功调用桥接层；② 即使一层被突破，另一层仍能防御；③ 两层在物理层面绑定——IP 白名单把桥接层绑定到特定物理基础设施，外部拿到地址也没用。这条线连到 Harness Engineering 强调的「多层 control plane」设计——Context/Permission/Runtime/Verification/Audit 各层独立、相互验证。

6. 统一 executeAgent 函数是触发面抽象的关键

CreaoAI 设计的最后一条原则是「同一执行管道服务所有调用方」——executeAgent 函数同时处理 UI 点击、定时触发、API 调用。 这个抽象的关键价值是：计费、额度扣减、日志、可观测性信号不管谁触发走同一套。新增一种触发方式只是加一条路由，不涉及架构改动。给做多触发面 Agent 系统的启示是：触发面应该是路由而不是分支——把所有触发源（UI/定时/API/事件总线）收敛到同一个执行函数，让横切关注点（计费/审计/可观测）有统一入口。这是「Agent 本质上是带自然语言接口的函数」这一核心判断的实现路径。

7. 「按所有权边界拆开制品」是可推广的设计原则

CreaoAI 给出的可推广设计原则是：「对于云平台上持久化的每一样东西，都要问清楚，谁控制它的变更节奏？如果用户和平台都要改同一个制品，迟早会出问题。按所有权边界把它拆开，让各自按自己的节奏演进。」 这条原则不只是云端 Agent 系统的——它是通用的多租户系统设计原则。给做 SaaS / 多租户系统架构师的启示是：在设计阶段就建立「变更所有权」清单，明确每个持久化制品（用户数据、平台配置、共享资源、配置元数据）的「变更主体」和「变更节奏」。当发现两个不同主体控制同一制品时，要么用强约束隔离（像 CreaoAI 的 chattr +i），要么重新设计归属。

实践启示

  1. 云端 Agent 的信任锚点是「沙箱内一切不可信」：所有桌面端可以省略的可信边界检查在云端都必须显式建模。凭据隔离、API bridge、IP 白名单、JWT 校验不是可选项而是默认配置。
  2. 识别「变更所有权冲突」比识别技术 bug 更重要：当两个不同主体（用户 vs 平台）控制同一制品时，部署会持续陷入两难选择。按所有权边界拆开制品，让各自按自己节奏演进。
  3. 借鉴成熟系统的隔离原则：CreaoAI 借鉴「内核 vs 用户态」分离解决 Runner 升级不毁掉用户环境的问题。给做云端系统的启示是借鉴操作系统/数据库/编译器等成熟系统的隔离原则，比从零设计新边界更可靠。
  4. 凭据生命周期跟 Agent 运行生命周期绑定：运行启动时签发短期 JWT、运行结束 JWT 自动失效——「不可信代码 + 短期凭据」组合让攻击者即使拿到凭据也只能影响当次运行，运行结束攻击链自动断裂。
  5. 多层校验的纵深防御：IP 白名单（网络层）+ 短期 JWT（应用层）双层校验，两层独立、相互验证、且在物理层面绑定（IP 把桥接层绑定到特定基础设施）。
  6. 触发面应该是路由而不是分支：把所有触发源（UI/定时/API/事件总线）收敛到同一个 executeAgent 函数，让横切关注点（计费/审计/可观测）有统一入口。新增触发方式只是加路由不涉及架构改动。
  7. Hot-swap 设计的三道防线：语法校验（node --check）+ 原子替换（chattr +i + 命令藏起来）+ 缓存清理（V8 compile cache）。任一步失败直接杀掉沙箱重来，不允许半升级状态。

相关实体