为什么 MyOpenClaw 迟早要认真做 Sandbox

我最近越来越觉得，MyOpenClaw 迟早要认真做 sandbox。

这件事一开始并没有那么强烈。因为如果只是把一个本地 Agent demo 跑起来，很多问题确实可以先不处理得太重。尤其在项目早期，你最在意的往往不是边界是不是已经足够清晰明确，而是它到底能不能先工作起来。

我现在回头看 MyOpenClaw，很大程度上也属于这种状态。

到目前为止，我们确实做过一些比较简单的工具限制，主要还是围绕访问范围和路径约束这类比较基础的东西。它们能避免最明显的误操作，但严格意义上说，这还远远谈不上真正意义上的 sandbox。它更像是 demo 阶段为了方便探索而加上的轻量限制，而不是一个已经被认真设计过的系统边界。

这在当前阶段并不奇怪。因为如果一上来就把权限、隔离、网络、凭据、执行环境这些东西都限制得很明确，很多探索会立刻变得很笨重。你会先被护栏困住，而不是先看清楚 Agent 到底应该怎么工作：上下文怎么组织，session 怎么管理，工具怎么接，skill 怎么沉淀，长期记忆应该放在哪一层。

所以如果只问一句：“为什么 MyOpenClaw 现在还没有认真做 sandbox？”
我的回答其实很简单：因为它到现在为止，仍然处在一个偏 demo、偏探索的阶段。

真正让我没法继续把这件事往后放的，是项目目标变了

如果 MyOpenClaw 只是一个我本地拿来试模型、试工具、试上下文管理思路的项目，那么 sandbox 当然可以先往后放一放。因为那时它更像一个实验台，而不是一个真正意义上的 runtime。

可我现在对它的定位，已经越来越不是这样了。

我更想把 MyOpenClaw 做成一种 Agent runtime。也就是说，当某个地方需要 Agent 能力的时候，我希望不是从头拼 prompt、拼工具、拼上下文，而是可以直接基于这套 runtime 去 new 一个 Agent，把能力接进去就能工作。

一旦换成这个视角，问题的性质就不一样了。

因为这时你讨论的，已经不再只是“这个 Agent 能不能帮我调一下工具”，而会慢慢变成下面这些更基础的问题：

• 它默认能拿到哪些能力
• 它和宿主环境之间的边界是什么
• 它能不能被长期运行
• 它能不能被复用到别的地方
• 它出了问题以后，影响范围会扩散到哪里
• 它的权限模型到底是怎么设计的

到了这一步，sandbox 就不再像一个以后可以再补的安全问题，而会开始变成 runtime 本身的一部分。

更让我在意的是，我想要的能力并不只是“调工具”

如果只是一个比较克制的 Agent，其实很多风险都还只是局部的。比如它读几个文件，写几个文件，调几个工具，最多也就是边界松一点，失误成本高一点。

但我对 Agent 的想法并不只停在这里。

我前面几篇博客其实一直在反复想一件事：Agent 到底能不能逐步进化？

这里说的“进化”当然不是什么玄学意义上的自我意识，而是一种更工程化的能力积累机制。比如像 OpenClaw 那样，用户可以教它记住一些东西，让它沉淀某些做事方法；或者像 Hermes 那样，系统自己回看对话，判断哪些模式值得被提炼成 skill；再或者像一些 coding agent 会做的那样，在空闲的时候整理 session，学习用户偏好、常用工具、任务习惯和工作风格。

这些方向我都觉得很重要，而且也基本代表了这一轮 Agent 产品里最值得看的那部分演化路径。

但如果只停在这里，我还是觉得不够。

我更感兴趣的，是另一层更彻底的“进化”

很多今天被叫做“自进化”的 Agent，本质上做的仍然是外围增强。它们会总结，会归档，会提炼，会推荐，会创建新的 skill，会调整 prompt，会记录用户偏好。这些当然已经很有价值，但它们大多还没有真正碰到系统自身的实现层。

而我真正好奇的是另一种可能：

Agent 不只是能记住东西、生成 skill、复用经验，它还应该有机会在受控条件下修改自己的代码、工具和能力结构。

这件事听起来很激进，但我觉得它反而非常值得认真讨论。

因为如果再往前推一步，我真正想看的不是“它会不会越来越懂我”，而是：

• Agent 能不能拿到一个专门为“修改自己”设计的代码工具
• 能不能拥有自己的 git 工作流
• 能不能有一个对应的远程 GitHub 仓库
• 能不能在一定条件下自己开分支、修改工具、改写 skill、修补 runtime
• 能不能通过某种 supervisor 或热重载机制，把新版本重新接回运行时
• 能不能在失败的时候自动回滚，而不是把宿主环境直接拖坏

如果这套机制能成立，那 Agent 的“进化”就不再只是 prompt 层和记忆层的进化，而会开始触碰它真正的能力结构。

我觉得这才是更疯狂、但也更有价值的部分。

一旦走到这里，问题就已经不是“加几个权限开关”了

当这些设想开始变得具体之后，很多原来可以被模糊处理的问题就会立刻变得尖锐起来。

比如：

• 这个 Agent 到底能接触哪些文件
• 它能不能碰自己的源码
• 它能不能访问本地 shell
• 它能不能联网
• 它能不能拿到凭据
• 它能不能 push 到远程仓库
• 它能不能改动 skill、工具定义和配置
• 它能不能影响其他 agent
• 它改出来的新版本是怎么上线的
• 它出问题之后，谁来兜底，怎么回滚

写到这里，我反而越来越不想把这件事简单叫成“安全问题”了。

因为真正卡住系统往前走的，往往不是“有没有风险”这么抽象，而是：这些 authority 到底应该怎么被授予、怎么被中介、怎么被限制、怎么被审计。

说得更直接一点，问题已经不再是“我们要不要做几个护栏”，而是“我们到底怎么组织 Agent 和世界之间的权力关系”。

所以我现在对 sandbox 的理解，越来越不像一个附属安全功能

过去很容易把 sandbox 想成一个偏安全团队的话题：做隔离、做权限、做限制、做防护。

但如果把视角放到 Agent runtime 上，我现在更愿意把它理解成一种基础抽象。

因为只要你真的想做下面这些能力：

• 可复用的 Agent 实例化
• 更连续的自治执行
• 更强的工具链访问
• skill 的长期沉淀与演化
• session 驱动的模式提炼
• 自动创建和改写能力组件
• 甚至受控条件下的自修改

你最后都会回到同一个问题：

这个 runtime 能不能给 Agent 提供一个明确、稳定、可组合、可回滚的能力边界。

而这件事，本质上就是 sandbox 要解决的问题。

也正因为如此，我现在越来越觉得，sandbox 最重要的意义，并不是“把 Agent 关起来”，而是把它和外部世界之间的 authority 关系管理清楚。

从这个角度再回头看，MyOpenClaw 现在的状态其实很容易理解

MyOpenClaw 现在没有认真做 sandbox，这在当前阶段并不奇怪。因为它还在一个需要快速探索、快速试错的阶段，过重的边界反而会妨碍把问题看清楚。

但这并不意味着这件事可以一直不做。

因为只要我对它的定位不变，只要我还是想把它做成一个真正可复用的 Agent runtime，只要我还是想继续往自进化、自修改、能力结构演化这些方向推，那么 sandbox 就迟早会从一个“以后再补”的问题，变成必须先补的前提。

而且到了那时候，我们真正要补的，也不会只是一个安全模块。

我们真正要重写的，是这套 runtime 里 authority 的抽象方式：

• 什么能力能给
• 给到什么程度
• 在哪个边界里给
• 哪些副作用必须经过中介
• 哪些修改可以自动发生
• 哪些修改必须被审查
• 哪些环境是可销毁的
• 哪些状态是可回滚的

我越来越觉得，这才是 Agent runtime 真正难、也真正有意思的地方。

我现在的结论

如果要把我现在的想法压成一句话，那大概就是：

当 Agent 只是帮你调工具时，sandbox 还像是一个可以稍后再处理的问题；但当你开始想让它进化，甚至修改自己时，sandbox 就不再是护栏，而是能力成立的前提。