为什么云端 Agent 基建这么难？_tag2

大多数人接触 AI Agent 都是从桌面端开始的。

一个用户、一台电脑、一个进程。Agent 只在笔记本电脑打开时运行，读写本地文件，API 密钥直接塞在环境变量里，终端一关它就挂了。出问题了就手动重试，缺依赖了就 pip install，环境、密钥、生命周期全都封装在同一个可信任的边界内。

这一切在云端都不成立。

云端 Agent 跑在一个每次启动都"从零开始"的沙盒里，硬件与你毫无关系，触发者可能是你从未谋面的定时任务、HTTP 请求，或是另一个 Agent。用户可能在睡梦中，而代码正在运行。沙盒里的代码可能是恶意的，文件系统需要在多次部署中活下来，密钥绝不能跟 Agent 放在同一个地方。

桌面上唾手可得的便利——持久化、身份认证、网络信任、自动重试——在云端都需要重新构建为显式的系统能力。

过去几个月，我们在 CREAO 做的就是这件事。今天分享两条最深刻的体会。如果你曾经跑通过桌面 Agent，又好奇搬到云端会发生什么变化，这篇文章就是为你写的。

教训一：把"变化慢"和"变化快"的东西拆开

在桌面上，用户环境和 Agent 的运行时是同一个东西，比如你的 Python 环境既装了 numpy，也装了 Agent 框架。更新节奏一致，管理的人也是同一个。

云端完全不同。

Agent 应用会在平台侧积累状态。比如一位股票分析师安装了 matplotlib，下载了市场数据，写了绘图脚本。这个环境就是 Agent 的"肌肉记忆"。

我们的做法是：用户满意的那一瞬间，就把整个环境冻结成沙盒快照。 每一次运行都从同一个镜像启动，包版本一致，文件一致，脚本一致。周一的运行和周五的运行行为完全一致，因为底层没有漂移。

这是桌面框架给不了你的保证。今天 pip install 和六个月前的结果不同，而云端的快照永远指向相同的字节。

但耦合问题随之而来。

同一个快照里既冻结了用户环境，又包含了我们开发的 Runner 代码——也就是每次 Agent 运行时负责调度的那个小核心。用户希望环境固定不变，但我们每天可能要部署十几遍 Runner。一份产物，两个截然相反的需求。

第一个解决方案很粗暴：启动时检查快照里的 Runner 版本是否匹配最新版，不匹配就扔掉快照、从干净模板重新启动。

这招能跑，用户也没抱怨。但代价只在每次部署后的首次运行时体现出来。

真正致命的是无人值守场景。定时任务早上 9 点触发，结果你 8:55 刚部署完——用户的 Agent 环境就这样被扔了，仅仅因为我们在尝试升级几个内部文件。这破坏了一条隐含的契约：用户的环境应该冻结，直到用户自己决定改变它。

我们花了比预期更长的时间才看清问题本质：用户环境和 Runner 代码的变化节奏完全不同。 用户按自己的时间表编辑 Agent，平台一天部署多次。把它们当作同一个产物，每次部署都迫使你在"保留陈旧的 Runner"和"销毁用户明确要求冻结的环境"之间强行二选一。

最终方案借鉴了操作系统的更新思路：内核可以换，但个人数据不动。你不会为了打补丁就格式化硬盘。

我们也沿用了类似的边界。沙盒从用户冻结的快照启动，原封不动。然后我们只做一件事：热替换 Runner。

具体步骤是这样的：

1. 1. 把新 Runner 放到沙盒内的临时目录；
2. 2. 用 node --check 验证语法，确保没有问题再碰线上的；
3. 3. 原子化替换：先解除旧 Runner 的 immutable 标记，覆盖新代码，重新上锁（chattr +i），然后把 chattr 命令本身藏起来，防止沙盒里的代码反向解除锁定；
4. 4. 清理 V8 编译缓存（/home/user/.cache/v8-compile-cache/*），不然新文件可能被旧字节码覆盖；
5. 5. 任意一步失败就直接杀掉沙盒、另起新实例。不允许任何"半升级"的状态进入生产流程。

整个替换过程大约 300 毫秒。Runner 替换成功后，运行结束时会重新打快照，把更新后的 Runner 直接烘焙进用户镜像，下次启动时就能跳过替换步骤。

平台部署不再丢弃用户状态，而是把新 Runner 折叠进既有环境。用户的包、文件、自定义配置原样保留。

如果你只从这段经历中学到一件事，就是这个诊断问题：

对于云平台上任何持久化的东西，都先问一句：谁在控制这个东西的变更节奏？如果用户和平台共同拥有它，耦合的代价迟早会来。沿着所有权边界拆分产物，让双方各自按自己的时钟更新。

教训二：密钥绝对不能进执行边界

这条经验是云原生 Agent 架构区别于其他一切的核心差异。

桌面 Agent 以用户身份运行，用用户的密钥，在用户的机器上，访问用户的内网。而云端 Agent 以"无人"身份运行，在共享硬件上，面对开放互联网，执行的是 LLM 从 Prompt 里写出来的代码——而那个 Prompt 可能是被恶意注入的。

安全模型必须假设：沙盒里的代码已经被攻破，然后据此设计防御。

我们的铁律很简单：任何长生命周期凭证，绝不进沙盒。

当 Agent 需要调用受信服务（Slack、GitHub、用户自己的 API）时，它手里没有 Token。它只向沙盒外的一个 API Bridge 发送本地 HTTP 请求，Bridge 在主机侧附上 OAuth Token 后转发出去。响应回来时，Token 从未进入过沙盒的内存或环境变量。

更有趣的是 Bridge 如何确认这个沙盒"有权"请求。两层验证，每层都有用意。

第一层：IP 白名单。

Bridge 只接受来自内部网络区间的连接。外部请求——开发者的笔记本、泄露的 URL、公网流量——在到达应用层之前就被网络层丢弃。这就把 Bridge 绑定到特定的物理基础设施上，拿到外面毫无意义。

第二层：单次运行专属的短效 JWT。

沙盒启动时，平台为这个特定运行签发一个 JWT：绑定用户、绑定应用、绑定会话，有效期仅为运行窗口期。沙盒每次调用 Bridge 都携带这个 Token，Bridge 验证签名和有效期后才读取用户凭证并附加到请求中。

即便沙盒被劫持，攻击者拿到的也只是一个随运行结束而失效的短期 Token，且授权范围仅限于这一会话。没有主凭证可以偷。

Bridge 同时承载计费扣减、日志和指标输出，是唯二穿越沙盒边界的通道。沙盒内的其他一切，默认按已沦陷处理。

想象一下：明天的 Prompt 注入攻击诱导 Agent 把 process.env  dumps 到外部 Webhook，攻击者拿到的是一个只能在内网使用、而且运行结束就失效的短效 JWT。正是这个属性，让我们敢于在共享基础设施上跑不受信任的代码，并且能安心入睡。

底层模式

可靠的云原生 Agent 基础设施不是什么新发明，只是几条被无例外地坚持住的朴素原则：

• • 状态留在沙盒里，冻结到用户主动修改为止
• • 代码可随时热替换，与状态解耦
• • 凭证驻留在主机侧，绝不进入 Agent
• • 同一条执行流水线服务所有调用方——无论是人工点击、定时任务触发，还是 API 调用

最后一条是整个设计的点睛之笔。

同一个 executeAgent 函数处理 UI 点击、定时任务和 API 调用。计费、信用扣减日志、可观测信号——统统与触发方式无关。新增触发方式只是路由层面的改动，不是架构改动。Agent 不需要知道、也不关心是谁拉动了扳机。

这是桌面框架给不了你的，也是云原生版本值得被认真构建的原因。

笔记本电脑上的 Agent 被电脑绑定；云端 Agent 则是整个技术栈都可以调用的函数。用户只写一次，平台负责让它扛住部署、安全运行在多租户硬件上、接纳用户从未预料过的调用方。

Agent 是带有自然语言界面的函数。实现是属于用户的，触发面、运行时、安全边界属于平台。真正的功夫在于：把各层解藕到可以独立演进，然后花足够的时间去找到系统之间的裂缝——在被人利用之前。

这才是让下一个触发面既便宜又安全的秘诀。