让 Agent 记住“现在”：用 TenseMem 管理可纠正的状态记忆
向量检索擅长找相似内容，却不天然知道哪条事实已经过期。用户先说住在德里，后来搬到班加罗尔；如果两句话都被检索出来，Agent 还得自行判断当前值。TenseMem 尝试把这个判断从提示词中移到确定性状态层：模型提出结构化操作，解析器决定如何更新，事实保存在本地 SQLite 中。
不是把对话越存越长
TenseMem 的核心不是保存一份更大的聊天记录，而是把原始 episode（输入事件）作为可追溯日志，并维护一份可重建的事实投影。读取时可得到当前状态、历史事实以及新输入是否已完成处理等 freshness 信息。这样，系统可以区分“尚未应用的新消息”和“已经确认的当前事实”。
它也把记忆纠错当作一等操作：新城市可以取代旧城市，但旧值仍保留在历史中；若新值本身是误报，可以撤销对应事实并恢复被替代值。这个模型适用于用户偏好、项目配置、设备状态等会随时间变化的单值属性；它并非通用向量数据库，也不能替代需要复杂关系查询的图数据库。
几行代码体验状态变更
项目 README 展示了以下最小示例。FakeExtractor 是规则式测试提取器，不需要 API 密钥；接入真实模型时应按对应 extra 安装 provider，并将密钥放在运行进程的环境变量中。
pip install tensemem
from tensemem import FakeExtractor, Memory
mem = Memory(llm=FakeExtractor())
mem.register_predicate("lives_in")
mem.add("u1", "I live in Delhi")
mem.set(user_id="u1", predicate="lives_in", value="Bangalore")
print(mem.state("u1").values)
history = mem.history("u1", predicate="lives_in")
按照 README 的示例，当前状态会以 lives_in: Bangalore 为值，历史记录则保留 Delhi 为已被替代的事实。若错误地把迁居当成事实，可以从历史中取出 Bangalore 对应的事实 ID，再调用 mem.correct(fact_id) 撤销；示例中状态恢复为 Delhi。这里的 API 与结果来自项目当前 README，不应将它误解为完整业务应用：生产系统仍需定义用户隔离、数据保留、备份和授权策略。
设计关键：模型提议，程序裁决
TenseMem 将 LLM 限定为事实提取器：它提出带类型的操作，resolver 按规则裁决，存储层再写入 SQLite。未知谓词不会自动注册；读取出来的 context 会被标记为隔离内容，提取流程要求引用用户原文，避免 Agent 把自己先前生成的摘要再当作用户事实写回。该设计不能保证模型永不误提取，但能把写入边界做得更明确，也为纠错留下依据。
README 还明确说明，facts 是 append-only episode log 的可重建投影。它让开发者可以检查“输入事件—提取操作—当前事实”的链路，而不必只面对一段难以解释的摘要。项目目前标注为 0.1.0 alpha，默认单 SQLite 文件、单进程使用；README 明确指出尚未提供第二种 SQL 方言，也没有多租户托管 Studio。因此适合先在个人助手或内部原型中评估，不宜仅凭“持久记忆”描述就直接承担关键业务数据。
如何评估是否适合你的 Agent
- 先定义谓词和主体边界。 例如
lives_in只适合单一当前居住地；兴趣、多个项目成员等多值关系不能硬塞进单值槽位。 - 从 FakeExtractor 跑通状态生命周期。 验证新增、替代、历史读取和纠正行为，再接入真实模型。README 提供
tensemem bench，使用打包的 101 段对话做本地基准，无需网络；基准表是项目自测结果，不等于独立评测结论。 - 检查 freshness，而非盲信刚写入的值。 示例用
context(..., min_seq=added.seq, wait=1.5)等待至少处理到指定序号，并查看ctx.freshness.is_current。应用应明确处理仍 pending 的情况，不能把超时后的旧状态伪装成最新状态。 - 把密钥和存储当作应用责任。 Provider key 应只放在执行提取的进程环境中。SQLite 是本地文件，不代表自动加密；需自行控制文件权限、备份与清理。
TenseMem 的价值在于把时间顺序、可纠正性和新鲜度显式化，而不是承诺“记忆永远正确”。若你的痛点是旧值与新值混在检索结果中，它值得作为一个可运行的状态记忆方案试验；若核心需求是海量语义搜索、多租户服务或复杂关系分析，则应先核对其 alpha 阶段边界，再决定是否组合其他存储系统。