解析

代理运行所在的那台云端机器

每个 Murmell 项目运行在自己独立的机器上,和所有其他项目分开,只有一个工作目录,别无他物。它既没有数据库也没有解密密钥,所以一个万一逃出沙箱的代理找不到任何值得拿的东西。

为什么需要沙箱

大多数文档里也叫它 sandbox。

一个有用的代理会执行它自己写的命令:装一个包,跑一个脚本,打开一个端口。没有人会在这些命令执行前逐条审核,这意味着唯一靠得住的防护就是它们运行的地方。

由此得到这条规则:执行代码的机器上不放任何有价值的东西。没有数据库,没有解密密钥,没有别的客户的凭证。这台机器出了事,代价就只是这台机器。

它里面有什么

项目的目录,代理的各种 CLI,以及代理为了工作装进去的东西。你接入的凭证只在会话期间供代理使用,不会离开这个范围。

画布、房间和占用看板都活在别处。一个在自己磁盘上乱写的代理,没办法决定谁持有某个文件:仲裁权不在它能控制的这台机器上。

一个项目一台机器

项目之间的隔离不是一个开关,而是产品本身的形状。每块画布启动自己的机器,两个项目永远不会共用一个文件系统。这也是环境可复现的原因:每次都从同一份已知镜像启动。

最后,代码去了哪里

项目创建的同时会生成一个私有仓库,工作在会话过程中不断被推送进去,机器销毁前还会有最后一次推送。你最终留下的是一个普通仓库,在你自己手里,离开 Murmell 也能读。一次会话的完整过程

直接回答

多个项目会共用一台机器吗?

不会。一个项目,一台机器。两个客户的项目永远不会落在同一个文件系统上,一个翻遍磁盘的代理也只能看到自己项目的目录。

机器被销毁之后还剩下什么?

项目的私有仓库,在销毁之前已经推送完毕。机器按设计就是一次性的:任何需要留存的东西早就在一个属于你的仓库里了。

代理能从这台机器访问互联网吗?

能,不然它没法装依赖包,也没法和模型对话。也正因如此,这台机器不含任何基础设施层面的机密:它能看到的唯一敏感内容,就是当前项目的代码本身。