Murmell 对比 Devin

Devin 是一个自主的工程师,你把一个任务交给它,回来时看到一个 pull request。Murmell 是一块画布,你在一个项目上打开多个代理,看着真实的终端一边工作一边输出。

两种提速方式

Devin 靠隔离来扩展规模。任务一大,它就把活儿分给其他 Devin,每个都在自己的隔离机器里,一个协调会话负责拆分再汇总。这很干净,也不需要任何仲裁:两个互不共享任何东西的代理不可能互相打扰。

Murmell 靠共享来扩展规模。一个目录,多个代理,一条由服务器强制执行的写入规则。结尾不需要汇总什么,因为从头到尾就只有一个状态。

隔离的代价在缝合:代理越多,需要拼在一起的结果就越多,不兼容的问题往往到很晚才暴露。共享的代价在等待:一个代理想要的文件被另一个占着,它就得等,而这个等待在屏幕上是看得见的。

看得见的等待是两种问题里更好的那一种。解法是立刻给卡住的代理换一件事做,而不是一小时后才发现冲突。

想把一个任务交出去、回来看结果时,选 Devin。想全程在场、让多个代理在同一份代码上工作、还有人在旁观时,选 Murmell。查看多个代理如何共用同一个仓库。。

	Devin	Murmell
第二个代理在哪里工作	一个完整的 Devin,在自己的虚拟机里,有自己的终端和浏览器	共享目录,写入前先占用要动的路径
谁能旁观	结果汇总之后的协调会话	拿到链接的任何人,实时查看,每个光标都带名字
工作产物落在哪里	这次会话带回来的结果	项目的私有仓库,随工作进度不断推送

两个 Devin 能在同一个目录里工作吗?

不能。Cognition 的说明是,每个受管理的 Devin 都是一个完整的 Devin,运行在自己隔离的虚拟机里,有自己的终端、浏览器和开发环境。协调会话之后再汇总结果。

在 Murmell 的画布上,是什么防止两个代理互相覆盖?

代理会先占用自己要动的路径。看板为每个路径记录一个持有者,拒绝所有其他人,直到它被释放,这条规则由服务器强制执行,而不是提示模型自觉遵守。