---
title: "云端 Agent 基础设施两条硬经验：CreaoAI 联合创始人的状态/代码解耦 + 凭据隔离"
created: "2026-06-06"
updated: "2026-06-06"
type: raw
source_url: "https://mp.weixin.qq.com/s/dz7bA_0Ki--izCUKp_krUw"
source_name: "AI 技术立文 WeChat MP (翻译 CreaoAI 联合创始人)"
author: "AI 技术立文 / CreaoAI co-founder"
ingested: "2026-06-06"
sha256: "024557fff7680dbc557db7783c6993ecfe4ac919882261ad3c87bb716a1a12ae"
char_count: 3227
tags: [cloud-agent, sandbox, creaoai, infrastructure, snapshot, hot-swap, jwt, api-bridge, credential-isolation, execution-boundary, zero-trust, runner-code, multi-tenant, security]
sources: []
review_value: 8
review_confidence: 8
review_recommendation: strong
review_stars: 4
---
ps: 本文来自
CreaoAI 的联合创始人.
今天大部分 Agent 
框架的设计前提是桌面环境。一个用户、一台机器、一个进程。Agent 跟着笔记本电
脑一起活，写本地文件系统，API 密钥放在环境变量里，终端一关进程就没了。出了问题用户自己重试，缺个包就 pip install 装进本地 Python。状态、密钥、生命周期全在同一个受信边界里，不需要额外操心。
云端完全是另一回事。
Agent 跑在每次全新启动的沙箱（sandbox）里，底下是多租户共享的硬件，触发它的可能是一个定时任务、一个 HTTP 请求、甚至另一个 Agent。运行的时候用户多半不在线。沙箱里的代码不一定可信。文件系统要扛得住反复部署。凭据不能跟 Agent 放在一起。桌面端那些理所当然的东西，持久化、身份、网络信任、重试，到了云上全得自己建。
过去几个月我们在 CREAO 集中解决了这一层的问题，总结出两条核心经验。如果你做过桌面端 Agent，想知道搬到云上到底变了什么，这篇文章就是答案。
教训一：把变化慢的和变化快的分开
桌面端的用户环境和 Agent 运行时是同一个东西，同一个人维护，同一个节奏更新。云端不是这样。
Agent 应用会在平台侧积累状态。比如一个股票分析师装了 matplotlib，下载了行情数据，写了绘图脚本。这些就是这个 Agent 的工作环境。用户觉得满意了，我们就把它冻结成沙箱快照（sandbox snapshot），此后每次运行都从这份快照启动，直到用户主动修改。同样的包、同样的文件、同样的版本，周一跑出来的结果和周五一样，因为底层没有任何变化。
桌面框架做不到这一点。六个月前 pip install 装的版本，今天再装就不一样了。云端快照能保证永远解析出同样的字节。可复现性是平台对用户的承诺，冻结快照是最简单的兑现方式。
但耦合问题随之而来。
冻结用户环境的那份镜像里同时包含 Runner 代码（runner code），也就是我们写的、负责在每次运行中管理 Agent 的小型运行时库。用户希望环境不要动，我们希望 Runner 一天能发好几次。同一个制品承担了两个方向相反的需求。
第一版方案很简单粗暴：启动时检查快照里的 Runner 版本是否和最新部署一致，不一致就丢掉快照、从干净模板重建。确实能用，也没人投诉，代价只是每次部署后第一次运行要重建环境。
无人值守运行（unattended runs）暴露了这个方案的问题。周一早上 9 点的定时任务不应该因为我们 8:55 做了一次部署就把用户环境搞丢。我们实际上一直在违背一个隐含的约定：「你的环境会保持冻结，直到你自己去改它。」
回过头看，答案其实很明显，只是我们花了不少时间才意识到。用户环境和 Runner 代码的变更频率完全不同。用户自己决定什么时候改环境，我们每天要部署平台好多次。把两者打包在一起，每次部署都得做一个两难选择：要么容忍过时的 Runner，要么毁掉用户辛苦搭建的环境。
最后我们借鉴了操作系统的做法。内核升级不影响用户的 home 目录，打安全补丁不需要格式化硬盘。
我们在沙箱上画了同样的线。启动时照常从用户的冻结快照加载，不做任何修改。然后单独热替换（hot-swap）Runner，具体步骤：
把新版 Runner 放到沙箱内的临时目录。
用 
node --check
 做语法校验，保证在触碰运行中的代码之前就能发现问题。
原子替换：先解锁旧 Runner 的不可变标志，把新文件复制过去，再用 
chattr +i
 锁上，最后把 
chattr
 这个命令本身藏起来，防止沙箱内的代码反向解锁。
清掉 V8 编译缓存（
/home/user/.cache/v8-compile-cache/*
），确保加载的是新文件而不是旧字节码。
以上任何一步出错，直接杀掉沙箱换一个新的重试。不允许出现半升级的状态。
整个替换耗时约 300 毫秒。当一次运行中发生了 Runner 替换，运行成功后我们会重新生成快照，把更新后的代码固化到用户镜像中，后续运行就不再需要替换了。平台部署永远不会丢弃用户的状态，只是把新版 Runner 融合进去。用户的包、文件、定制化配置全部原样保留。
这个教训的核心是一个判断标准：
对于云平台上持久化的每一样东西，都要问清楚，谁控制它的变更节奏？
 如果用户和平台都要改同一个制品，迟早会出问题。按所有权边界把它拆开，让各自按自己的节奏演进。
教训二：把凭据隔离在执行边界之外
这条经验是云端 Agent 基础设施区别于其他所有架构的地方。
桌面 Agent 用用户的身份运行，用用户的密钥，在用户的机器上，访问用户的网络。云端 Agent 跑在共享硬件上，以无特权身份运行，面对的是开放互联网，执行的代码由 LLM 根据可能带有恶意的提示词生成。安全模型的前提必须是：沙箱内的代码已经不可信。
我们的原则很明确：
长生命周期的凭据绝不进入沙箱。
当 Agent 需要调用有认证要求的外部服务，比如 Slack、GitHub 或者用户自己的 API，它不持有令牌，而是向沙箱外部的 API 桥接层（API bridge）发一个本地 HTTP 请求。桥接层在宿主侧把 OAuth 令牌挂上去，再转发调用。响应返回的全程中，令牌从未进入过沙箱的内存或环境变量。
桥接层怎么判断某个沙箱有权发起请求？靠两层校验，刻意叠加。
第一层是 IP 白名单。
桥接层只接受沙箱宿主所在内网网段的连接，其他来源的请求在网络层就被丢掉了，不会走到应用代码。这等于把桥接层绑定在了特定的物理基础设施上，外部拿到地址也没用。
第二层是每次运行生成的短期 JWT。
沙箱启动时，平台签发一个专属于本次运行的令牌，限定了用户、应用、会话和有效期。沙箱在每次调用桥接层时都要出示这个令牌。桥接层验签、检查有效期，通过后才去查用户存储的凭据并在服务端附上。即使沙箱被劫持，攻击者拿到的也只是一个随运行结束即失效、且只对当前会话有效的令牌。没有长期凭据可以泄露。
同一个桥接层也承载计费扣款、日志和指标的传出，所以它是沙箱边界（execution boundary）上唯一的双向通道。沙箱内部的一切，默认视为已被攻破。
假设明天有一次提示词注入（prompt injection）成功让 Agent 把 
process.env
 发到外部 webhook，攻击者拿到的也只是一个短期 JWT，只在内网有效，运行结束即作废。这个性质是我们能在共享基础设施上放心跑不可信代码的底气。
底层的设计模式
可靠、安全的云端 Agent 基础设施不需要什么新发明，它就是几条严格执行的原则：
状态在沙箱里，冻结到用户主动改变为止。
代码可热替换，不依赖状态。
凭据在宿主侧，永远不进 Agent。
同一条执行管道服务所有调用方，不管触发源是人、调度器还是其他程序。
最后一条是整套设计里最值得说的。一个 
executeAgent
 函数同时处理 UI 点击、定时触发和 API 调用。计费、额度扣减日志、可观测性信号，不管谁触发的运行，走的都是同一套逻辑。新增一种触发方式只是加一条路由，不涉及架构改动。Agent 本身不知道、也不需要知道是谁启动了它。
这就是桌面框架做不到的事，也是云端版本值得建设的原因。笔记本上的 Agent 跟那台笔记本绑死了。云端的 Agent 是技术栈里其他系统可以随时调用的函数。用户只需要写一次，平台负责让它扛住部署、在共享硬件上安全运行、接纳用户没有预想过的调用方。
Agent 本质上是一个带自然语言接口的函数。实现归用户，触发面、运行时、安全边界归平台。关键在于把这些层建好，让每一层按自己的节奏演进，并且赶在别人之前找到层与层之间的缝隙。
这就是让下一个触发面能快速、安全上线的根本。

---
## 元信息
- **来源 URL**: https://mp.weixin.qq.com/s/dz7bA_0Ki--izCUKp_krUw
- **抓取时间**: 2026-06-06
- **抓取方式**: urllib + js_content 提取
- **作者**: AI 技术立文 (翻译 CreaoAI 联合创始人)
- **原始来源**: CreaoAI co-founder 总结 cloud Agent 基础设施的两条核心经验