Harness 里的记忆，为什么越来越像一份可编辑的 Markdown

最近一批开源 Harness 有个共同点：记忆不再只藏在向量库里，而是以 MEMORY.md、进度文件、甚至 soul.md / user.md 这种纯文本出现在工作区。OpenHarness 把 MEMORY.md 和会话恢复、自动压缩放在一起；个人 Agent 形态还会把人格、用户画像、bootstrap 写成可翻阅的文件。

这看起来像「退回文档时代」，其实是 Harness 工程成熟的信号：记忆首先要可干预，其次才谈召回漂亮。

一、黑盒记忆的真实成本

向量库很擅长相似检索，但生产排障时常常答不出三个问题：

第一，Agent 当前到底「相信」哪些事实？

第二，某条错误记忆是何时写入、被哪次工具结果污染的？

第三，人能不能一刀删掉或改掉它，而不用重训或清库？

答不出这三问，记忆系统就只是另一个会漂移的黑盒。长任务失败后，团队只能重启会话，等于承认记忆不可运维。

二、文件型记忆解决的是操作面

Markdown 记忆的价值不在格式优雅，而在操作面：

• 人和 Agent 看到的是同一份状态
• 可用 Git 做版本、diff、回滚
• 出问题时可以直接打开文件定位
• 压缩上下文时，可以把「热事实」留在 MEMORY.md，把完整轨迹外置

换句话说，文件是 harness 与人之间的共享工作区，不只是模型的私有草稿纸。

三、该写什么，不该写什么

适合进 MEMORY.md 的，通常是跨轮次仍成立的事实：项目约定、已确认的接口结论、用户偏好、禁止事项、未完成清单。

不适合直接塞进去的，是大段工具原始输出、一次性搜索结果、尚未验收的猜想。这些更适合进轨迹日志或可检索附件，需要时再引用。

一个实用规则：写进记忆的每条内容，最好能回答「如果这句话错了，人能不能一眼改对」。改不对的，就不要当长期记忆。

四、和压缩、验收怎么配合

自动压缩会丢掉对话细节，这时 MEMORY.md 承担的是「压缩后仍必须在场」的骨架。

验收也不该只读模型嘴上的总结，而应对照外置记忆与真实副作用：接口是否已改、测试是否已绿、禁止事项是否仍在。记忆文件提供的是可核对的断言来源，不是情绪化的「我觉得做完了」。

五、落地时的最小做法

不必一上来做复杂记忆图谱。先做到三件事就够：

1. 给每个长任务准备一份可编辑的 MEMORY 或进度文件
2. 规定写入时机：确认事实后写，猜测不写
3. 关键变更走 Git，错误记忆可回滚

向量检索可以后补，用来从冷存储里找历史材料；但「当前真相」应留在人能编辑的层。

结语

Harness 的记忆问题，本质不是「召回率够不够」，而是「错了能不能改、漂了能不能看见」。当记忆越来越像一份可编辑的 Markdown，说明行业正在从玩具 Agent 走向可运维 Agent：模型继续负责联想，文件负责承担责任。