106 天了，复盘一下 yoyo 的 harness 为什么简单有效，和对未来“持久化状态 harness”的思考

长时运行的 agent 真正缺的不是更聪明的模型，而是持久化的状态。

yoyo 已经自我演进了一百多天。每隔 8 小时，GitHub Action 就会把它唤醒。它读取自己的源码，决定怎么改造自己，改造测试完成，然后回去睡觉。没有任何人类修改它的代码。这里有趣的是不在于“LLM 居然能写 Rust”，而在于：为什么偏偏是这个 loop 没有像大多数自主 agent 项目那样，在一周之内就偏移、或者悄无声息地卡死。

答案很简单，一个被贯彻到底的设计巧思：让智能体保持无状态、可丢弃，让状态保持稳健、可持久。每一个棘手的 agent 难题（记忆、上下文、长时程、反馈、验证），yoyo 都没有用花里胡哨的 agent 专用技术栈来解决，而是用早就有的、朴素的系统构件去解决：文件、进程、退出码、cron 和 git。模型被当作一个不可靠的子进程，塞进一条可靠的工作流 loop 里。下面逐步拆解介绍一下。

记忆：强制写进 git 仓库

yoyo 没有向量数据库，也没有加载记忆服务。它的记忆就是几个 markdown 文件（JOURNAL.md、LEARNINGS.md、SOCIAL_LEARNINGS.md），和代码一起提交进同一个仓库。在 yoyo 这里行之有效是因为：第一，记忆是在写入时被提炼的，而不是在读取时被检索的。每次会话结束时，yoyo 都会把这次发生的事浓缩成几句话，于是存储的记忆小到可以一次性整个加载进来。第二，写入是强制性的。Harness 会检查日志条目是否存在。如果 yoyo 偷懒没写，harness 就用一个专门为此准备的 prompt 再跑一次。要是还失败，一个兜底机制会直接从 commit log 里生成一条最简记录。规则定义在 harness 里，而不是寄望于模型的“良好意愿”。一个 agent 会忘记去用的记忆系统，算不上记忆系统。

事实证明，git 是个绝佳的记忆容器：基本只追加、有版本、可审计，而且免费。一百天的“身份认同”，就是一条 git log。

上下文：每次现搭

大多数 agent 都死于上下文。对话不断膨胀，直到模型在自己历史织成的迷雾里推理。yoyo 从设计上避开了这一点：它每次都现搭上下文，而不是任由其堆积膨胀。每一次运行都是一个新进程，配一个新搭好的 context。把身份、语气和提炼过的经验缝合在一起，harness 恰好加上一个任务，任务做完进程就退出。除了被刻意写进文件的东西，什么都不会带到下一次。yoyo 有自动压缩上下文的机制，但基本用不着它，因为没有哪个单独的任务会跑得久到把窗口填满。身份每次都被逐字重新注入，这也是为什么一百天的会话都保持了 yoyo 的语气。人格漂移是上下文堆积的症状，而每次从零重建的上下文，根本无从漂移。

长时运行：许多短进程，一个仓库

yoyo 的 harness 从不让任何东西跑很久。规划阶段有超时，每个实现任务限十五分钟，修复限五分钟,写日志限两分钟。所谓“长时运行”，是来自把一连串短命进程串起来，而它们之间唯一共享的只有文件系统。一次挂起，顶多损失一个任务。一次崩溃，损失的都是无关紧要的东西。一个 API 错误会干净利落地中止本次运行，交给 Action 重试。这一百多天的时程，既不住在某个上下文窗口里，也不住在某个进程里，它住在 git 仓库里。cron 让意图存活，日志让故事存活，而每次会话只承担一件有界的事。所谓长时程，无非就是持久化状态加一个调度器，这两样，都不是模型。

反馈：环境就是那个批判者

整个反馈回路里没有人的存在。harness 里面有三种不同速度的反馈回路。在一个任务内部，编译错误和测试错误会逐字直接回灌给 yoyo agent。Rust 那著名详细的报错信息，在这里变成了一个免费、精确、永不疲倦的批判者。在一次会话内部，收尾阶段会跑最多三轮完整的验证修复。在会话之间，harness 会拉取上一次运行的 CI 结果，把失败日志喂进下一次的规划 prompt 里面，也会引入来自社区的 issue（每一条都必须给出答复：实现、不修、或部分处理)，并强制把一轮反思写进 LEARNINGS.md。yoyo 从不给自己打分。是环境在给他打分，而 harness 确保这个分数真实可用。

验证：检查至关重要

任何结果想幸存被留下来，都必须通过测试。验证失败的自动修复是分不同层次且诚实地进行的。先做廉价的确定性修复（cargo fmt 自动修，不牵涉模型），然后把错误摆在 agent 面前让它重跑，最多三次，再不行就回滚到会话开始前的那个 commit。而且这次回滚本身也会被提交。于是失败留在历史里清晰可见，而不是凭空消失。更重要的一点是：agent 会进行“这玩意儿到底行不行”的检验。代码之所以是自主 agent 最容易搞定的领域，正因为通过和失败都是实打实的，还附带详尽的信息。yoyo 的 harness 之所以有效，是因为它从不越过一个自己还没检查过的步骤。

展望：持久化状态 harness

yoyo 最初只是一个 200 多行的简单 agent：一种语言、一套测试、按计划运行。但它一百多天没散架，说明 harness 才是让 agent 长时稳健运行的重要武器。可靠性是在 harness 里面搭建起来的，不是在模型里。而可靠性，正是一个 demo 和一个你真能放手不管的东西之间的分界线。

今天的 harness 只是暂时的，一个足够强的未来模型可以把它替代掉。

这话有一部分是对的。harness 里的那些判断，确实会随时间挪进模型里：怎么把问题拆开、何时该重试何时该升级、一个任务该多大。yoyo 的规划器正是这种意义上的权宜之计，随着模型能力增强，应该会越来越薄。但有些东西本来就不归模型所有。比如验证回滚就属于环境。持久化状态，按定义就在模型之外。

最后这一点，正是未来所指的方向。一个上下文窗口，无论多大，进程一死它就没了。可验证的记忆、身份、试过些什么的记录，所有这些都必须住在模型之外的某个地方，否则它撑不过一次崩溃、一次重启、一次模型升级。所以能留下来的 harness，不是规划器也不是执行器，而是可以被模型用来使用的一个持久化状态层。模型越强，围着它的脚手架越薄，但它们赖以运行的持久底座只会愈发居于中心。智能体会变得越来越聪明。而状态会比它活得更久。这才是真正值得构建的部分。