ClawBoxLite：一行代码在本地通过 micro-VM 沙箱内启动 OpenClaw

sorry ，还得执行下

```
pip install greenlet
```

这是你的 project 的？

这和 firecracker 的 MicroVM 有什么区别呀？

@detached 向 firecracker 学习的，但主要目的不是用来跑 function ，而是 agent

@d0r1an （我没有恶意啊先说明）如果底层使用 firecracker ，然后写一部分胶水逻辑，应该也能达到同样的效果吧？

@detached 没事，正常讨论。没有用 firecracker ，做这个之前我深度研究了 firecracker 和相关 vmm 的代码，坑和细节比较多，很多设计决策和 bug 需要解决

@detached 没有胶水层那么简单，代码开源的，有兴趣可以一起深入讨论

@d0r1an 我看了一下文档，就我的理解是：使用 kvm （只讨论 Linux ）来进行 hardware isolation ，然后在 vm 里运行 container （？）来实现 OCI 兼容性？

@d0r1an 以我对 firecracker 的了解，是有项目让 Firecracker microvm / kata container 满足 oci 的，所以我实际上是没搞清楚你这么做的 motivation ，（当然个人项目想怎么做就怎么做）。

你
@detached 你现在在找沙箱解决方案吗？

@detached 我的出发点非常简单，agent 怎么快速的被开发出来，跑起来，又不会束手束脚还能保证尽可能安全。其他沙箱产品你可以试下体感

@detached 技术的差异需要在解决同样问题的语境里面容易讨论出来

@d0r1an 我在找我的（下一个） research project 的 idea 。

可以达成的共识应该是：sandox for agent 主要是为了解决 coding agent 在运行过程中有一个拥有所有权限环境。

这一点与 serverless function (firecracker microvm)比较接近，所以逻辑上讲可以启动一个 microvm ，并在里面运行 coding agent ，这样就完成了你的出发点：完整的环境、硬件隔离。

所以如果是站在 research/产品的角度，这个项目应该回答的问题是：boxlite 与 Firecracker 在解决这个问题上有什么差别？（ aws 已经有了基于 microvm 的 agentcore ）。

如果你的实现（最底层上）是启动一个 microvm （利用 kvm ），并且在里面运行一个 container 。这样的效率从逻辑上来讲是低于 kata container 的（ kata 是将 vm 包装成一个兼容 oci 的 container ，其实质上是 vm ）。


整个项目的逻辑可以二元的拆分为：sandox 以及为 agent 做的 protocol 。如果在 sandox 层面回答不了这个问题，这个项目的意义就只能落在后者：为 agent 部分做的修改。

@detached 你的分析很好，是逻辑很强，但是你上手用一下嘛，很快就能体验出区别😂

@d0r1an 祝你的项目成功:)

@d0r1an lz 你好，拜读了一下项目 website 和 firecracker 的对比，是否可以认为 boxlite 通过牺牲部分 vm 启动性能换来了更好的 toD 集成体验？比较好奇启动性能的差异来自于什么地方？是 libkrun 本身性能劣于 fc ，还是 oci 兼容层存在开销，亦或是其他我没考虑到的原因？我目前理解 agent 场景下沙箱启动性能是一个 critical 的点，不知道您怎么看。

@d0r1an 沙箱这块不太了解，我想请问个问题：比如我的服务代码是跑在 docker 容器内的，然后需要调用这个 boxlite sdk 这个来启动 sandbox ，可行么？就是 sdk 调用方只能在宿主机上，还是在 docker 内部也可以？

@SToPire Hi, 目前没有性能方面的损耗了

@runstone 可行的，但是需要把/dev/kvm 挂在给容器