没有免费的简单，只有换人付账的简单

一条把复杂度账算得很清楚的架构观察：Agent 设计基本两种范式——要么 Agent 整体跑在沙箱里，要么 Agent 在外、只有工具在沙箱里执行。

作者的观察很实在：不少大厂偏爱前者（Agent、文件系统、开发工具全在同一环境）——隔离直观、做起来省心，而且这未必只是不差钱，是拿资源开销换工程上的简单。他更关注后者：把 Agent 和执行环境的生命周期解耦——Agent 持续存在，沙箱按需创建、复用、回收；代价是复杂度转移到了平台层：状态协调、工作区持久化、故障恢复、多用户的数据权限隔离，一样都不能少。

他点名在看的三个项目（celld、Rivet、LayerFS）恰好对应三个切面：运行时、状态管理、文件系统。

为什么这篇值得发？因为它给前两天那篇 DSec 论文补上了"为什么"。DeepSeek 的沙箱底座每秒新建 5000 个、单单元 160 节点、带状态持久化与故障恢复——这些听着炫的指标，全是范式②强加给平台层的功课；换到范式①（agent 随环境起落），这些活大部分不需要做。

所以架构选型的本质从来不是哪个更先进，而是你把复杂度放在哪里：放环境里，钱替你扛；放平台层，工程替你扛——没有免费的简单，只有换人付账的简单。

留一格清楚的边界：范式①听着粗放，其实隔离更彻底（agent 折腾不出环境）；范式②听着优雅，每处状态都可能丢（这正是"agent 死法"清单里的头号病）。两条路的适用场景不同：沙箱便宜、任务短命走①；任务贵、环境贱才值得上②——判断标准还是那句话：哪半更容易被搞砸。

给要选这条路线的人一句落地的：先答一个问题——你的团队更擅长养 agent 还是养平台。会管状态、会做持久化、会扛故障恢复，②的红利才是你的；否则先用①上线（大厂的答案有大厂的理由），等你被环境重建坑够了三次，再考虑解耦——架构的功夫，一半是提前想清楚，一半是承认现在还没到那一步。