Shiv Shankar

LLMs 是无状态的。这对代理记忆的实际意义是什么。

有一句话大多数 AI 代理教程都会跳过，而它解释了
为什么构建可靠的长期运行代理如此困难：

在 API 调用之间，模型一无所知。

你见过的每一个“记忆功能”——ChatGPT 的记忆、Claude 的 Projects、
LangMem、Mem0——都是由人类编写的系统，在调用模型前准备文本并注入上下文窗口。模型本身没有持久状态。

人们忽略的含义

如果 LLM 是无状态的，那么长期运行代理的智能完全
存在于管理注入什么、丢弃什么的 harness 中。

这不是局限，而是设计原则。

研究界已开始明确这样对待它：

  • MemGPT (2023) 引入了“LLM 即操作系统”的类比：模型是 CPU，
    外部记忆是磁盘，harness 管理查询时哪些页面在 RAM 中。

  • StateFlow (2024) 更进一步：代理是一个有限状态机。
    LLM 仅在状态转换时被调用，不负责状态本身。

  • ClawVM (2026) 将其形式化为虚拟内存层：harness 在每个生命周期边界
    强制执行确定性、经过验证的写回。
    LLM 输出原始思考；harness 决定提交什么。

对记忆设计的后果

如果 LLM 纯粹是一个处理单元，那么代理记忆的质量
完全取决于你的harness——决定存储哪些事实、有效期多长、何时应被取代的系统。

存储平面嵌入并按相似度检索的 harness 只能给你一个
平庸的代理。而存储时间断言并确定性解决冲突的 harness 才能给你一个可靠的代理。

“时间断言”在实践中的含义

时间断言是带有生命周期的事实：

subject:   user_project
predicate: uses_language  
object:    Python
valid_from: 2025-01-10
valid_to:   2025-06-15   ← closed when user switched to TypeScript

Enter fullscreen mode Exit fullscreen mode

harness 存储它，而不是 LLM。一旦设置了 valid_to，LLM 就再也看不到旧事实。活动状态是 WHERE valid_to IS NULL。

这就是 Smriti 背后的模型——一个开源的
时间记忆引擎，专门作为无状态 LLM 的可靠 harness 构建。

LLM 不是代理。harness 才是代理。构建好 harness。

MIT license. PostgreSQL-backed. Open source.