[!info] related notes

• 相关主题: Coding Agent Memory Landscape
• 相关概念: AI Agent Memory Layer
• 相近工具: Roo Code Memory Bank, Mem0

agent-memory

简介

agent-memory 的方向很清楚：不是把 session 日志无限堆起来，而是把记忆做成一个逐步整理、压缩和再表达的系统。

适用平台

• CLI-first coding agent
• 多 harness 或多运行时协作
• 想把 session 经验沉淀成始终在上下文里的规则层

特点

• capture：先抓取运行过程中的原始材料
• consolidation：把原始材料整理成更稳定的记忆
• defrag：持续压缩、去重和收敛
• AGENTS.md generation：把整理后的结果回写成显式规则层

使用边界

• 这个方向很对，但仍偏早期
• 它更像“memory 整理器 + 指令层生成器”，而不是成熟托管平台

最短记忆方式

agent-memory 的重点不是“多记一点”，而是“把 session 经验逐步整理成 agent 真正会长期使用的分层记忆”。

Related notes

• Agent MOC
• Agentic Systems
• Agent 执行闭环

不要把聊天历史当作 Agent 状态存储

简短结论：聊天记录是展示层，不应作为后端状态存储。把 messages 当作 source-of-truth 会导致状态漂移、恢复困难与审计盲区（示例：购物车移除未写回，模型基于过期上下文重复推荐）。

要点：

• 聊天界面 != 后端：业务状态应结构化并持久化（用户、购物车、订单、锁定资源等）。
• 工具调用按语义分类：
  • Read（只读）：可缓存。结构示例：{ kind: “read”, tool, args, result, cachedAt }
  • Write（变更）：必须服务端持久化与审计，并使用幂等键。结构示例：{ kind: “write”, tool, args, idempotencyKey, executedAt, result }
  • Hybrid（预占/有副作用）：需要补偿动作（Saga）。结构示例：{ kind: “hybrid”, tool, args, compensateAction, result }
• 持久化执行（durable execution）：把 LLM 当作决策/路由节点，工作流引擎（如 Temporal）负责 checkpoint、重试与恢复。遇到外部调用失败，应重试该调用而不是重新 prompt 模型。

工程建议（摘要）：

• 不要把 messages 当数据库；把关键写操作写入服务端审计日志并记录幂等键。
• 为读调用建立短期缓存与过期策略，不把大量 JSON 长期塞入聊天记录。
• 为混合调用设计补偿流程（reserve -> confirm -> release）。
• 把长流程建模为状态机/DAG，必要时用 durable workflow 引擎管理等待点与重试。
• 把 LLM 限定为语义层（意图识别、抽取、决策建议），避免让它承担控制流、恢复策略与事务性决定。

相关行动：建议在 Agent 执行闭环 与 Tool use in agents 中引用本节并添加轻量链接。