为什么我们给每个智能体配了一台电脑
我们发布的每个智能体都跑在容器里。一开始这没什么问题，直到有人开始提出一些我们给不了的东西。
用容器本是顺理成章的选择（真的）
容器便宜、启动快、彼此隔离。每个智能体一个容器，由网关充当 Agents Vault 来管理密钥。智能体可以在里面执行命令、读写文件，使用我们为它接好的工具。
有一段时间，这样够用。
然后有人提出了更多需求，于是我们动手做了
有一个请求让问题一下子暴露了。一位工程师让他的智能体去拉取代码仓库、把整套服务跑起来（没错，包括数据库），然后判断某个功能到底能不能用。智能体克隆完代码就停住了。没有地方能启动 PostgreSQL 实例，没有环境运行应用，也没办法查看结果。
容器能跑一个进程，却不是能运行数据库这种完整应用的地方。没有浏览器，没有显示界面。那个请求最后和所有类似请求一样，智能体只能解释它"如果条件允许"会做什么，但实际活儿一点没干成。
我们最后为什么改用微型虚拟机（micro-VM）
我们想要三样东西，而且哪样都不想妥协：一个归智能体所有的文件系统、一个它能操作的浏览器，以及足够强的隔离，强到我们放心把它跑在客户的环境里。
前两样做起来不难。第三样才是我们不能走捷径的原因。智能体能做的事越多，就越要确保它的失误不会波及别处。
容器和宿主机共享一个内核。我们不愿意让这层共享成为智能体与机器上其他一切之间唯一的屏障。
所以我们就做了现在这套方案：在 OneCLI Cloud 上，每个智能体跑在一个独立的微型虚拟机里，置于沙箱之内。一个真正的浏览器、一个真正的文件系统，root 权限只在那台虚拟机上，不在你的机器上。它做的任何事都到不了另一个智能体、另一个员工或者你的系统。真要搞坏了什么，坏掉的也只是它自己的电脑。
当智能体拥有那台虚拟机之后
食品采购听起来很琐碎，但却是最直观的例子。你让智能体帮你下一单日常的 Instacart 订单，它会自己打开浏览器、把购物车装满，然后完成结账。而更进一步的版本，根本不需要你提供清单。对着冰箱拍一张照片，它会知道你平时怎么囤货；等需要补货时再拍一张，它就能算出缺了什么。如果燕麦奶没货了，它不会随便挑一个替代品赌你会接受，而是把最接近的选项拿给你看，等你确认后再完成下单。
另一个例子是我们自己的代码仓库。我们让智能体去加一个集成，它会克隆代码，用容器把 Postgres、Redis 和应用整套环境跑起来，然后写对接第三方服务的代码，搭好登录流程。接下来是关键一步：它会在自己的电脑上，拿真实的外部服务跑一遍这个流程，观察回调是否正常到达，然后修复任何出错的地方。
全部完成后，它会把结果写在 pull request 上，并更新对应的事务单。所以你拿到手的东西，已经跟真实环境验证过，而不仅仅是纸面上检查过。
写连接器这件事从来不是瓶颈。最花时间的一直是搭建一个能真正测试的环境，而这部分正是智能体替我们接管的地方。现在我们的集成就是这么上线的。
我们没改什么
能力越强，策略层的分量反而越重，而不是更轻。一个只能提建议的智能体，做不了什么破坏；而一个拥有浏览器和文件系统的智能体，破坏力就完全不同了。
计算机让智能体能够行动，策略层则决定它能走多远。发邮件、删记录、花钱——每一步都会停下来请求确认。这条规则是在智能体之外强制执行的，所以无论怎么用提示词绕，都绕不过去。
OneCLI Cloud 已经上线，云上的每个智能体都拥有一台自己的计算机。别再一步步描述任务了，把它直接交给你的个人智能体吧。
开源