Stanford 研究人员发布Shepherd 运行时层(copy-on-write fork 比 docker commit 快约 5 倍)

斯坦福的研究人员又搞出了新东西。他们刚刚做出了 agent 原生版的 Git。

当 agent 处理一个较长的任务时，运行过程中会积累大量状态。这包括被编辑/创建的文件、开发服务器、数据库、已安装的软件包、KV 缓存等。

假设 agent 进行到第 10 步时犯了个错误，比如它误读了回溯信息，重写了一个其实没问题的文件。测试开始失败，运行偏离了轨道，尽管到第 8 步为止一切都是正确的。

默认情况下，agent 会尝试修复，这会产生更多的编辑和工具调用。这会消耗更多 token，并使上下文不断膨胀。

其他选择是由人介入重新引导，或者从第一步重新开始整个运行。这很浪费，因为要为每一次模型/工具调用重新付费，还要重新预填充上下文。此外，由于 agent 的运行是非确定性的，它本来也无法重现相同的早期步骤。

之所以很难直接跳回之前某个正确的步骤并从那里恢复，是因为运行轨迹只是一个消息日志。它记录了 agent 说了什么、调用了哪些工具，但没有记录底层的实时状态。

这些状态包括内存、打开的文件句柄、子进程、已安装的软件包、/tmp 目录以及 KV 缓存。这些都不在日志中。

Git 可以对文件进行版本控制，但它不会对正在运行的进程或 KV 缓存进行快照。检出第 8 步会将文件回退，但进程仍然停留在第 10 步的内存状态，且缓存是冷的。

Shepherd 是斯坦福开发的一个运行时层，它将运行记录为类型化事件的轨迹，而不是一个扁平的日志。每次 agent 与环境的交互都会成为一次提交，类似于 Git，但它跟踪的是实时运行状态。

它的提交将 agent 进程和文件系统结合在一起，采用写时复制（copy-on-write）机制，因此分支携带的是实际状态，而不仅仅是文件。

回到之前的步骤只需一次调用，从该提交分叉，并从确切的状态继续。写时复制分叉比 docker commit 快约五倍，而且由于到第 8 步为止的提示前缀没有变化，重放时 KV 缓存的复用率超过 95%，因此早期步骤不会被重新处理。

一旦运行可以被分叉，一个元 agent 就可以在其上层进行操作。它监视轨迹，一旦发现异常就立即回退，赶在错误写入被提交之前。

实际上，这只是 Python 在轨迹上调用 fork、replay 和 revert，而不是一个连接到测试框架的独立控制平面。

不过，并非所有操作都是可逆的。文件和沙箱更改可以自动撤销，但数据库写入没有自动撤销功能，因此需要提前设置相应的撤销步骤。某些外部操作，比如发送的邮件或真实的扣款，是无法撤销的，所以监督者的工作是在这些操作发生之前将其捕获。

他们在几个公开基准测试上进行了测试。在 CooperBench 上，两个 agent 协作处理同一个代码库，加入实时监督后，结对编程的通过率从 28.8% 提升到了 54.7%。

这还只是早期阶段，