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

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

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

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

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

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

—— "恢复到完全一样的状态,继续跑"。

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

那开始吧。

"能跑、能给少数人用"的沙箱, 3 个月 3 个人差不多够了

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

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

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

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

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

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

前方高能预警。

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

1. 内存里的变量值
2. 已经写到磁盘的文件
3. 正在执行的进程
4. 浏览器的当前页面、cookies、缓存
5. 环境变量

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

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

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

。

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

不是所有状态都能保存, 也不是所有都需要保存。 。

1. Session 的日志(每一步发生了什么)
2. Agent 的当前推理上下文
3. 关键中间结果

:

1. 文件系统快照(让重启后文件结构一致)

做错任何一个选择—— 要么数据丢失,要么存储。 。

难点二:何时保存

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

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

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

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

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

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

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

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

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

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

1. 启动一个一模一样的容器
2. 加载存储的日志
3. 重放(replay)所有日志中的操作
4. 把序列化的数据反序列化回内存
5. 让 Agent 知道"它现在在哪一步"

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

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

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

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

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

1. 在上面补丁式加企业功能
2. 贴品牌、加 UI,直接做成"团队版"上线

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

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

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

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

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

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

设计起点完全不同—— 不是先做出一个 agent,再考虑怎么扩展给企业用, 而是。

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

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

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

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

把两条路放一起对比:

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

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

CMA 也是同样的逻辑。 从"把 agent 抽象成四件套", 到"sandbox 怎么按需启动、状态怎么恢复", 到"几万企业服务怎么不互相干扰", 。

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

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

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

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

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

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

我的判断:

—— 中国市场,魔改版快速占领目标市场, CMA 这种理念的压倒优势,体现不出来。

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

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

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

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

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

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

业内能做到这种长期纪律的公司少—— AWS 早期、Google 基础设施团队、Anthropic 这种以研究文化立身的公司。 。