龙虾下半场（一）：沙箱不难，把"恢复沙箱"做到Anthropic的水准才难

很多事情，认知不够，

就想当然地想得简单。

这是Agent火起来之后，

我的一个心得。

但是，Agent有件事被忽视了，

因为业界讨论AI的声音，

主要来自做模型的人，

不来自做Agent基础设施的人。

让Agent任务跑得好，

听上去，一句话，轻飘飘，

背后是越深入，越复杂。

说人话就是，Agent用起来的标志，

就是上规模。

好消息是，

既然大而全的讨论难周全，

我们就分几篇；

《龙虾下半场》系列之：

沙箱不难，

把"恢复沙箱"做到Anthropic的水准才难。

这里的恢复是精确恢复，

还有好消息是，

有Anthropic的Claude Managed Agent，

可以对标。

那开始吧，

这种"能跑，且给少量人用"的沙箱，

差不多3个月3个人够了，

大神速度另行讨论。

像北美E2B公司，AI创业公司的内部沙箱，

都是轻量级起家，

早期像Modal公司这种（通用云函数平台），

都被用来搭沙箱，

要求不高的话，可凑活玩，

要求高的话，就不合适了。

比如，Agent之前调用过『发邮件』工具。

恢复时，如果重复再做一遍，

邮件被发出两次。

所以，恢复必须知道，

"哪些已经做过，哪些没做过"，

精确从中断点继续。

这事做好牵扯到，

一件事不在一台机器上完成，

而是，拆给多台机器同时做，

这些机器还得互相配合，保持一致。

而且，Agent这件事天生大规模：

一家企业有1000员工同时用Agent，

每个跑在自己的沙箱里，

这就是1000个沙箱同时存在，

每个沙箱的状态，

计费，监控，安全要被精确管理。

我把『恢复沙箱，继续跑』，这件事拆开，

咱们一起感受一下工程量。

也就是它的分量。

这件事值不值钱，

没做过工程的人也有判断的价值——

因为它最终决定了Agent时代，

哪些公司能站住，哪些站不住。

由于细节过多，

我会大量使用数字标号，

前方高能预警。

话说，Agent在沙箱里跑到一半，

沙箱销毁了，下次用要恢复，

且"恢复到完全一样的状态" 。

意味着什么?

也就是，沙箱销毁那一瞬间，有哪些东西？

或者说，有哪些东西『同时存在』？

1.内存里的变量值

2.已经写到磁盘的文件

3.正在执行的进程

4.已发起但还没收到响应的网络请求

5.浏览器的当前页面，cookies，缓存

6.数据库连接

7.已持有但还没释放的锁

8.临时文件

9.环境变量

恢复时，这些东西全部要『复原』，

且要复原到精确，不多不少，不能错位。

这就是真正的难点。

再看，CMA这种；

1.真正的多租户隔离

（几千用户互不影响）；

2.精确的状态恢复

（从中断点继续，不是从头重来）；

3.完整的可观测性，安全防护，合规审计；

4.99.9%以上SLA

（每年宕机小时数个位数）；

5.自动故障转移；

『恢复沙箱』真是表面简单，

上手一做，甩出泪来。

很棘手的问题很多：

比如，保存什么？何时保存？

每一步决策，需要资深架构师推敲很久。

第一个工程难点：保存什么？

不是所有状态都能保存，

也不是所有都需要保存，精细的取舍。

这里就可以分三类，

第一类，最好保存的;

1.『恢复沙箱』文件系统快照

（让重启后文件结构一致）

2.内存中的临时计算结果

第二类，必须保存的;

做错任何一个选择，

要么数据丢失，要么存储爆炸。

第二个工程难点：何时保存？

不能等沙箱销毁时才保存，

那时候可能已经来不及了（宕机）。

保存必须是"持续的"，这又分好几种方法。

猛一听，选择很多，可惜，每种都有代价，

是单机数据库，还是分布式存储，

读写比例是多少，

高峰流量是平均流量的几倍。

每一个变量都会改变最优答案。

CMA可能用的是某种混合策略，

这是Anthropic的工程秘密，

不过可以肯定的是，

调出这个平衡点的工程师团队，

不是想清楚就完了。

另外，还有『如何序列化』的难题，

把活的内存状态变成可存储的字节流，

简单数据好办，复杂活物极难，这里不展开。

这些每一个都是独立的工程难题。

沙箱恢复时，

这些复杂活物有的能用快照，

有的只能放弃，重启后重建，

所以，这事很难。

工程难点之三：如何精确恢复？

恢复时，要让新启动的沙箱，

精确达到原来的状态。

1.启动一个一模一样的容器

2.加载存储的事件日志

3.重放（replay）所有日志中的操作

4.把序列化的数据反序列化回内存

5.重建网络连接

6.重建数据库连接

7.把文件系统恢复到对应的快照

8.让Agent知道"它现在在哪一步"

好吧，某些操作还不是幂等的，

这是分布式系统里著名的『精确一次』难题，

重放可能产生副作用。

这些难点，归纳都很头疼。

管理者不懂，

还非要逼技术团队，

那AI送他的大礼，就是一堆屎山。

不过，有人背锅就行了，

谁还不是职场高手。

很多厂商，

把OpenClaw『魔改』成团队版/企业版，

这条路和CMA的路完全不同，

值得仔细对比。

『魔改』：

1.拿OpenClaw开源代码作为基础；

2.『补丁』企业功能；

3.托管部署到自家云上；

4.贴品牌，加UI；

直接做成『团队版』上线。

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

『核心团队其实就几个人，

成本低，开发快，用户上手快，

OpenClaw的核心代码不用自己写，

改改就能上线；

而且群众基础好，有学习曲线优势。

还有，差异化容易，

加点行业特色功能（医疗版），

或者直接上一体机。

缺点大家也都知道，

但是公司没有资源在此投入，

更愿意给模型团队。』

大家的共识是，

本质上，仍是OpenClaw架构，

首先，OpenClaw本来是单用户单机的，

改成多用户需要外挂数据库等"打补丁"方式，

再者，OpenClaw的『运行时』和『环境』，

是耦合在一起的，

要改成云上多租户沙箱，

需要把这两层拆开重新设计，

这相当于把核心架构重写；

还有，可扩展性不行，

大规模并发就挂了。

对比一下，走CMA这种路线，

体现出，Agent时代，

『工程』和『创新』边界模糊，相互交融；

CMA它的设计起点完全不同：

不是先做出一个Agent，

再考虑怎么扩展给企业用，

而是从第一天起，

就为多用户，企业级，大规模设计。

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

最上面一层，是抽象。

CMA 用四件套；

中间一层，是底层基础设施。

多租户，状态管理，

沙箱隔离，计费，可观测性；

这些不是后加的功能，

是从零设计时就考虑进去的能力。

最外面一层，是接口。

对外只暴露几个简洁，稳定的公开接口；

简洁，稳定都要能夸的点，

综合工程能力很强。

直接对比这两条路：

这两种路径不是对立的，

而是产业链的不同位置，

华为一个高管和我说，

魔改版这种级别的AI创新，

养活不了华为，

华为这种规模的企业，

肯定要Agent原生的基础设施。

而阿里云则在4月就推出，

企业级智能体构建平台，

JVS Crew。

我想试试，后面再写一篇，详细分析。

回到文章开头，

为什么说，

企业级Agent把分布式系统所有难题，

召唤回来了。

技术角度的回答是，

Agent是：

"长任务+有状态+大规模并发+多组件协作+成本敏感"，

这是五个buff，

是分布式系统最难处理的工况了。

这两条路会怎么演化？

我的判断，短期看，

中国市场，魔改版快速占领目标市场，

CMA理念这种的压倒性优势，体现不出来。

另一部分魔改版会找到自己的细分领域继续生存，

长期的话，基础设施层稳定在3家之内，

这是软件产业，过去30年，反复发生的剧本。

文章来自于"亲爱的数据"，作者 "亲爱的数据"。