@akshay_pachaar：斯坦福大学的研究人员又做到了。他们刚刚构建了智能体原生的 Git 版本。当智能体在较长的任务上工作…

斯坦福大学的研究人员又做到了。 他们刚刚构建了智能体原生的 Git 版本。 当智能体在较长的任务上工作时，运行会积累大量状态。 这包括编辑/创建的文件、开发服务器、数据库、已安装的包、KV 缓存等。 假设智能体进行到第 10 步时犯了错误，比如它误读了 traceback，重写了一个实际上没有问题的文件。 测试开始失败，运行偏离了轨道，尽管到第 8 步为止一切都是正确的。 默认情况下，智能体只会尝试修复它，这会产生更多的编辑和工具调用。这会消耗更多 token，并让上下文不断膨胀。 其他选择是让人介入并重定向，或者从头开始重启整个运行。 这很浪费，因为要再次为每次模型/工具调用付费，并重新预填充上下文。而且，由于智能体的运行是非确定性的，它无论如何都不会重现相同的早期步骤。 难以准确定位回之前的正确步骤并从那里继续，原因是轨迹（trajectory）只是一个消息日志。 它记录了智能体说了什么、调用了哪些工具，但没有记录底层活动状态。 这些状态包括内存、打开的文件句柄、子进程、已安装的包、/tmp 和 KV 缓存。这些都不在日志中。 Git 可以对文件进行版本管理，但它不会快照运行中的进程或 KV 缓存。签出第 8 步会把文件回退，但进程仍然停留在第 10 步的内存中，并且缓存是冷的。 Shepherd 是斯坦福大学开发的一个运行时层，它将运行记录为类型化事件的轨迹，而不是扁平日志。 每次智能体与环境的交互都会变成一个 commit，类似于 Git，但它跟踪的是实时运行。 它的 commit 将智能体进程和文件系统一起包含进来，采用写时复制，因此分支承载的是实际状态，而不仅仅是文件。 回到之前的某一步，只需一次调用，从该 commit 分支出来，并从精确状态继续。 写时复制分支的速度大约是 docker commit 的五倍，而且因为到第 8 步的提示前缀未改变，KV 缓存在重放时的复用率超过 95%，因此早期步骤不会被重新处理。 一旦运行可以被分支，一个元智能体（meta-agent）就可以坐在上面操纵它。它会观察轨迹，一旦发现看起来不对，就会在坏写入被提交之前回滚。 实际上，就是 Python 在轨迹上调用 fork、replay 和 revert，而不是一个连接到 harness 的单独控制平面。 不过，并不是所有东西都可逆。 文件和沙箱更改可以自行撤销，但数据库写入没有自动撤销，因此需要预先设置匹配的撤销步骤。 外部事物（比如已发送的邮件或真实扣款）无法撤销，所以监督者（supervisor）的工作就是在它发生之前拦下。 他们在几个公开基准上测试了这一点。在 CooperBench 上，两个智能体在同一个代码库上工作，加入实时监督者将结对编程通过率从 28.8% 提升到 54.7%。 目前还为时过早，并标记为 alpha。收益主要体现在运行在沉重的沙箱状态下频繁分支时，而这正是重启最浪费 token 和时间的地方。 如果 Git 是为了让文件更改可逆，那么 Shepherd 就是在尝试对实时智能体运行做同样的事情。 Shepherd 仓库：https://github.com/shepherd-agents/shepherd… （别忘了点星标 ） 话虽如此，Shepherd 会回滚一次运行中的坏步骤。它周围的 harness——监督者依赖的提示、工具和检查——仍然会随着模型和依赖项的变化而在不同运行之间发生漂移。 我写过关于让这个 harness 自我修复的文章：失败的轨迹会被诊断，修复会针对失败的精确输入进行验证，并且失败会被锁定为回归测试，这样它就不会再次发生。 文章引用如下。