Agent 记忆落地：持久化、少存与过期

文档转 Markdown 的 API 跑久了，最容易暴露的问题可能不是转换能力，而是该记住什么、什么时候忘掉。作者运营这类服务数月后，踩过三类坑：把进程缓存当记忆、为排障保存全部请求、让旧转换结果长期有效。

他的结论很朴素：记忆需要持久化、精简和过期机制。这篇没有复杂架构，也没有性能对照数据，但对正在给 AI 工具或转换服务补状态管理的开发者，很有参考价值。

进程重启之后，还应该记得什么

作者最初把状态缓存在进程里。服务一重启，缓存就消失。用户重试同一个 URL，却可能得到不同结果，故障看起来像随机发生。

后来，他把状态迁到进程之外的持久化存储，描述中的不稳定现象随之消失。

这里要区分两个问题：数据当前能不能读到，以及下次启动还能不能读到。进程内缓存解决前者，持久化存储才负责后者。对需要跨请求延续行为的服务，只考虑当前进程是不够的。

是否需要持久化，取决于这份状态丢失后，会不会改变用户预期的行为。

不过，原文没有交代具体保存了哪些状态，也没有解释缓存清空为什么会改变转换结果。因此，可以接受作者报告的修复效果，却不能据此认定：所有同 URL 返回不一致的问题，都能靠持久化解决。

记得越多，排障就越容易吗

作者早期为调试记录了完整请求体。几周后，存储成本和隐私暴露面反而成了主要问题。

他的调整是只保留标识符、哈希和处理结果，留下足以回溯事件的线索，不再保留内容本身。

这组取舍有明确目的：标识符帮助关联请求，哈希帮助核对内容是否一致，处理结果说明当时发生了什么。但它也有边界。哈希不能还原原文，精简日志能支持事件追踪，却未必足以复现依赖具体文档内容的解析错误。原文没有说明这类故障后来如何排查。

另一个容易漏掉的点是：即使缓存需要保留转换内容，调试日志也未必需要复制一份完整内容。两者承担的任务不同，保存范围应当分别决定。

作者最后建议，对不适合长期保存的信息做摘要。不过，摘要如何生成、保留哪些字段，他没有展开。

为什么缓存既要过期，也要主动失效

作者给转换缓存设置了 TTL，也就是存活时间；修改解析器行为时，还会显式让相关缓存失效。

这两个动作解决的是不同问题：

• TTL 限制结果最多保存多久，避免旧数据无限累积。
• 显式失效处理规则变化，避免解析器已经更新，接口仍返回旧规则生成的结果。

对于转换 API，同一个 URL 并不保证旧结果一直适用。即使输入没变，解析行为变了，预期输出也可能随之改变。此时只等 TTL 到期，用户仍可能在一段时间内拿到旧结果。

缓存有没有命中，与命中的结果是否仍然有效，是两件事。

原文没有给出 TTL 的具体时长，也没有说明失效操作如何实现。它提供的是设计原则，不能直接当成可照抄的缓存配置。

我的判断

我认同作者把「记忆」拆成存储位置、保留内容和删除时机。这比只讨论选哪种记忆组件，更贴近服务上线后真正要处理的问题。

但标题用了 agent，正文提供的经验主要来自文档转换 API。它能支持对缓存、日志和持久状态的讨论，还不足以证明对话摘要、长期偏好等其他 agent 记忆也适用同一套实现。

作者报告了迁出进程后故障消失，以及保存完整请求体带来的成本和隐私问题；没有提供故障率、存储用量或方案对照。这是一份生产经验记录，不是经过量化验证的最佳方案。

与全部保留相比，精简记录能减少保存负担，也会损失部分复现材料。与只设 TTL 相比，主动失效更能响应解析规则变化，但需要团队把它纳入变更流程。具体取舍仍要看服务需要保留什么证据、允许结果陈旧多久。

能拿来做什么

• 给 Node 转换服务梳理一次状态：哪些数据重启后丢失会影响用户行为，就为它安排持久化存储。
• 检查调试日志是否保存了完整请求体，并逐项判断标识符、哈希和处理结果能否满足排障需要。
• 为转换缓存明确 TTL，同时把缓存失效加入解析器行为变更的发布步骤。
• 如果 AI 编程工具会保存文档转换结果，先写清保存范围、有效期和删除条件，再决定具体使用什么存储组件。