(一)

很多事认知不够,就会想当然地以为简单。 这是 Agent 火起来之后,我反复有的一个心得。

而这件事被严重低估了。 不是因为它不重要, 是因为业界讨论 AI 的声音, 主要来自做模型的人, 不来自做 Agent 基础设施的人。

让 Agent 任务跑得好, 听上去一句话,轻飘飘, 背后越深入,越复杂。

我用一句话先抛个判断:

从技术角度,Agent 这件事,把分布式系统所有难题召唤回来了。

说人话就是——Agent 一旦真用起来,就是大规模的。 而大规模一上来, 分布式系统过去 30 年没解决干净的所有难题, 全在 Agent 时代新一轮被翻出来, 而且变得更复杂。

好消息是,大而全的讨论难周全, 我们分几篇讲。 今天这篇是《龙虾这死亡率这么高,下半场怎么玩?》系列之——『恢复沙箱』背后多少复杂工程量?

这里的恢复是精确恢复—— "恢复到完全一样的状态,继续跑"。

还有个好消息—— 我们有 Anthropic 的 CMA(Claude Managed Agents)可以对标。

(二)

那开始吧。

"能跑、能给少数人用"的沙箱, 3 个月 3 个人差不多够了(大神速度另算)。 像北美的 E2B、各种 AI 创业公司的内部沙箱, 都是这么轻量级起家的; Modal 这种通用云函数平台, 也常被早期玩家拿来搭沙箱。

要求不高,可凑活玩。 要求高,就完全不合适了。

举一个具体场景: Agent 之前调用过『发邮件』工具。 沙箱崩了要恢复—— 如果重放这个操作, 邮件会被发出两次。 所以恢复必须知道: "哪些已经做过,哪些没做过", 精确从中断点继续。

这件事做好,牵扯到一个事实: 一件工作不在一台机器上完成, 而是拆给多台机器同时做, 这些机器还得互相配合、保持一致。 这就是分布式系统。

而且,Agent 这件事天生大规模: 一家企业 1000 个员工同时用 Agent, 每个跑在自己的沙箱里—— 这就是 1000 个沙箱同时存在。 每个沙箱的状态、计费、监控、安全 都要被精确管理。

我下面把"恢复沙箱、继续跑"这件事拆开讲—— 不是想让你成为工程师, 是想让你大致感受这件事的工程量, 也就是它的分量。

这件事值不值钱、重不重要, 没做过工程的人也有判断的价值—— 因为它最终决定了 Agent 时代, 哪些公司能站住、哪些站不住。

由于细节过多, 我会大量使用数字标号, 前方高能预警。

(三)恢复沙箱,到底要恢复什么

Agent 在沙箱里跑到一半,沙箱销毁了, 下次要"恢复到完全一样的状态"—— 意味着什么?

沙箱销毁那一瞬间,有这些东西同时存在:

内存里的变量值已经写到磁盘的文件正在执行的进程已发起但还没收到响应的网络请求浏览器的当前页面、cookies、缓存数据库连接已持有但还没释放的锁临时文件环境变量

恢复时,这些东西全部要『复原』, 而且要复原到精确—— 不多不少、不能错位。 这就是真正的难点。

再看 CMA 这种生产级平台, 要求是这样的:

真正的多租户隔离(几千用户互不影响)精确的状态恢复(从中断点继续,不是从头重来)完整的可观测性、安全防护、合规审计高可用 SLA(每年宕机小时数个位数)自动故障转移

『恢复沙箱』不是"加个按钮"那么简单。

(四)这件事到底难在哪

光列要求没用,我们看几个真实的工程难点。

难点一:保存什么

不是所有状态都能保存, 也不是所有都需要保存。 得做精细的取舍。

第一类,必须保存的:

Session 的事件日志(每一步发生了什么)Agent 的当前推理上下文用户的代码、文档、数据关键中间结果

第二类,最好保存的:

文件系统快照(让重启后文件结构一致)内存中的临时计算结果

做错任何一个选择—— 要么数据丢失,要么存储爆炸。 这一步取舍本身,资深架构师就要推敲很久。

难点二:何时保存

不能等沙箱销毁时才保存—— 那时候可能已经来不及了(比如机器突然宕机)。 保存必须是持续的。

听起来简单,做起来分几种策略,每种都有代价:

策略一:实时同步写入 每一步操作发生时,立刻写入外部存储。 代价:每一步都要等存储确认, 性能可能慢 5 到 10 倍。

策略二:批量异步写入 积攒几秒钟的操作,打包后批量写入。 代价:中间这几秒钟如果机器宕机, 这部分操作就丢了。

策略三:智能差异化写入 关键操作走实时同步,非关键操作走批量异步。 代价:要事先精确判断哪些算"关键"—— 该实时的没实时,数据丢; 不该实时的实时了,性能崩。

到底走哪种策略, 还要考虑底层存储是 SSD 还是机械盘、 是单机数据库还是分布式存储、 读写比例是多少、 高峰流量是平均流量的几倍。 每一个变量都会改变最优答案。

CMA 实际用的是某种混合策略, 具体是 Anthropic 的工程秘密。 可以肯定的是—— 调出这个平衡点的工程师团队, 不是想清楚就完了, 是上线后还要根据真实流量持续调整, 这种调整一调就是几年。

难点三:如何序列化

把活的内存状态变成可以存储的字节流—— 简单数据(数字、字符串)好办, 复杂活物(正在跑的进程、活的网络连接、活的数据库连接)极难。 这些不只是数据, 还有"和外界正在发生的关系"。

沙箱恢复时, 有的能用快照硬抠出来再还原, 有的只能放弃,重启后重建。 具体细节这里不展开, 每一项都是独立的工程难题。

难点四:如何精确恢复

恢复时,新启动的沙箱要精确达到原来的状态:

启动一个一模一样的容器加载存储的事件日志重放(replay)所有日志中的操作把序列化的数据反序列化回内存重建网络连接重建数据库连接把文件系统恢复到对应的快照让 Agent 知道"它现在在哪一步"

但最难的点是—— 某些操作不是『幂等』的。 意思是同一个操作做两次,结果会不一样。 比如发邮件,一次和两次效果完全不同。 所以重放日志时, 必须知道哪些操作做过、哪些没做过—— 这是分布式系统里著名的『精确一次』难题。

这些难点归纳起来都很头疼。 管理者不懂, 还非要逼技术团队加速交付, AI 送他的大礼,就是一堆屎山代码。 不过,反正最后有人背锅就行。 谁还不是职场高手。

(五)两条路:魔改 OpenClaw vs CMA 原生路线

讲完工程难点, 我们看看市场上的两种解决方案。

很多厂商把 OpenClaw『魔改』成团队版/企业版, 这条路和 CMA 的路完全不同,值得仔细对比。

路线一:『魔改』OpenClaw 成『团队版』

拿 OpenClaw 开源代码作为基础在上面补丁式加企业功能托管部署到自家云上贴品牌、加 UI,直接做成"团队版"上线

某 Agent 团队技术负责人告诉我:

"核心团队其实就几个人, 成本低,开发快,用户上手快—— OpenClaw 的核心代码不用自己写,改改就能上线。 群众基础好,学习曲线低。 差异化也容易—— 加点行业特色功能(医疗版、法律版), 或者直接上一体机。 缺点大家也都知道, 但是公司没有资源在这上面投入, 更愿意给模型团队。"

大家的共识是—— 本质上仍是 OpenClaw 架构, 核心问题动不了:

首先,OpenClaw 本来是单用户单机的, 改成多用户需要外挂数据库等"打补丁"方式。

再者,OpenClaw 的 agent『运行时』和『环境』 是耦合在一起的—— 要改成云上多租户沙箱, 需要把这两层拆开重新设计。 这相当于把核心架构重写。

还有,可扩展性差, 大规模并发就挂了。

路线二:走 CMA 这种原生路线

设计起点完全不同—— 不是先做出一个 agent,再考虑怎么扩展给企业用, 而是从第一天起,就为多用户、企业级、大规模设计。

具体看,CMA 在三层都重新做了:

最上面一层,是抽象。 CMA 用四件套(Agent / Environment / Session / Events) 把 agent 这件事完整拆开, 边界清晰、不重不漏。 这是被业内反复称赞的概念创新—— 和 Unix 把计算资源抽象成"进程、文件、管道"是同一个级别。

中间一层,是底层基础设施。 多租户、状态管理、沙箱隔离、计费、可观测性—— 这些不是后加的功能, 是从零设计时就考虑进去的原生能力。

最外面一层,是接口。 对外只暴露几个简洁、稳定的公开接口。 简洁和稳定,都是要能撑住几年不变的硬指标—— 综合工程能力极强。

把两条路放一起对比:

维度

魔改 OpenClaw

CMA 原生路线

开发速度

眼前快,日后慢

眼前慢,日后快

架构

补丁式

从底层设计

多用户隔离

改装的

原生的

沙箱质量

改装的

原生的

状态管理

外挂数据库

append-only 日志

可观测性

改装的

原生的

接口稳定性

跟随 OpenClaw 上游

自己控制,长期稳定

成本

开发成本低

开发成本高,但单位运营成本低

(六)Agent 时代,『工程』和『创新』的边界模糊了

可能有人会说: "这些不就是工程吗,算什么创新?"

这个判断本身就是对创新的根本误解。

iPhone 没发明任何新技术, Tesla 没发明电池, Google 没发明搜索, AWS 没发明虚拟化—— 它们的创新全是工程创新: 把已有的东西, 以从未有人做到的方式, 精密整合到一起。

CMA 也是同样的逻辑。 从"把 agent 抽象成四件套", 到"sandbox 怎么按需启动、状态怎么精确恢复", 到"几万企业服务怎么不互相干扰", 每一层都是独创性的决策,不是教科书上现成的答案。

华为一个高管和我说:

"魔改版这种级别的 AI 创新,养活不了华为。 华为这种规模的企业, 肯定要 Agent 原生的基础设施。"

这两条路不是对立的,是产业链的不同位置。 魔改版在中小企业、垂直行业有它的价值; CMA 这种原生路线占住的是基础设施层。

(七)回到开头那个判断

回到文章开头那句话:

Agent 这件事,把分布式系统所有难题召唤回来了。

技术角度的完整回答是: Agent 是**"长任务 + 有状态 + 大规模并发 + 多组件协作 + 成本敏感"**—— 这五个 buff 叠加, 是分布式系统最难处理的工况。

很多人以为模型越聪明,基础设施挑战越小—— 这是个错觉。 模型变强不让 agent 变简单, 反而让 agent 能干更长、更复杂、更大规模的任务, 基础设施面临的工程挑战只会更大。

这两条路接下来怎么演化?

我的判断:

短期看(1-2 年)—— 中国市场,魔改版快速占领目标市场, CMA 这种理念的压倒性优势,体现不出来。

中期看(2-3 年)—— 魔改版的天花板会暴露, 一部分玩家会重写架构, 另一部分会退到细分领域继续生存。

长期看(5 年以上)—— 基础设施层稳定在 3 家之内。 这是软件产业过去 30 年反复发生的剧本—— 基础设施和应用层会分化, 基础设施层最赚钱, 应用层最热闹但单点公司难做大。

让 Agent 任务跑得好—— 听上去轻飘飘一句话, 有了足够认知才能理解它真正的难度。

这事不是不能做, 是做出来需要顶级团队 + 大量资源 + 长期纪律。

前两者好理解。 什么是『长期纪律』?—— 是几年时间里, 每个工程师每天每周都能克制住"走捷径"的冲动, 坚持把事情做正确,而不只求快。

每一次走捷径,看起来都是理性的—— 省两天时间、早点上线、避免被骂。 但几千次小捷径叠加在一起, 整个系统就烂了。

业内能做到这种长期纪律的公司极少—— AWS 早期、Google 基础设施团队、Anthropic 这种以研究文化立身的公司。 这才是 CMA 这种产品真正的护城河—— 不是技术领先,是工程纪律。