跳到主要内容

长期记忆

1. 定义与边界​

长期记忆（Long-term Memory）是在多个会话、多个任务或较长时间范围内保留的信息。它可以是用户偏好、组织规则、项目约束、成功经验、失败教训或 Agent 自身的工作流程。

长期记忆不是原始日志归档。原始日志用于审计和回放，长期记忆用于未来任务的行为改进。

2. 为什么重要​

长期记忆适合解决：

  • 用户不想重复说明偏好和背景。
  • Agent 需要复用项目结构、工具习惯、已验证命令。
  • 团队级规则需要跨会话持续生效。
  • 系统需要从历史失败中减少重复试错。

3. 核心机制​

长期记忆的关键不是“存得多”，而是“可控地写入、准确地召回、及时地遗忘”。

4. 架构模式​

模式适用场景风险
Profile JSON用户画像、组织配置、稳定偏好profile 过大后难合并、难解释
Document collection多条独立偏好、经验、事实去重和冲突处理复杂
Vector memory语义召回经验片段相似度不等于适用性
Filesystem memoryAgent 技能、项目笔记、可读规则并发写入和权限控制要额外设计
Relational memory强一致、审计、权限、删除语义检索能力需另建索引

5. 工程实现​

推荐使用“双存储”：

  • 主存储：PostgreSQL / 文档库，保存结构化记录、权限、审计。
  • 检索索引：向量库或全文索引，保存可搜索字段。
create table agent_memory (
  id text primary key,
  tenant_id text not null,
  namespace text[] not null,
  memory_type text not null,
  key text not null,
  value jsonb not null,
  source jsonb not null,
  confidence numeric not null,
  sensitivity text not null,
  expires_at timestamptz,
  created_at timestamptz not null,
  updated_at timestamptz not null,
  deleted_at timestamptz
);

写入流程：

def commit_long_term_memory(candidate, policy, store):
    if not policy.allowed_namespace(candidate.namespace):
        return "reject: namespace"
    if policy.is_sensitive(candidate) and not candidate.user_confirmed:
        return "needs_confirmation"
    existing = store.find_conflicts(candidate)
    merged = merge_or_supersede(existing, candidate)
    store.upsert(merged)
    store.audit("memory_upsert", merged)
    return "ok"

6. 生产实践​

  • 按 tenant_id/user_id/project_id/agent_id 分区，不做全局默认召回。
  • 为每条长期记忆保留来源证据，方便用户质疑时回放。
  • 使用置信度、更新时间和最近验证时间控制召回优先级。
  • 将写入分为自动写入、需用户确认写入、禁止写入。
  • 建立后台 consolidation 任务，去重、合并、降权、过期。
  • 高价值长期记忆可以生成自然语言版本和结构化版本，分别服务检索与执行。

7. 常见反模式​

  • 把长期记忆当“永久真理”，不处理过期和冲突。
  • 用单个全局 profile 保存所有用户信息。
  • 不记录来源，导致错误记忆无法解释。
  • 用向量相似度直接决定行为，缺少权限和类型过滤。
  • 把机密、凭证、临时授权写成长久记忆。

8. 评测方法​

  • 长期偏好遵循率：在新会话是否正确应用已确认偏好。
  • 跨会话任务效率：启用记忆后是否减少澄清轮次和工具探索。
  • 冲突处理准确率：新偏好覆盖旧偏好时是否正确更新。
  • 误用率：不相关、过期或越权记忆进入上下文的比例。
  • 用户编辑率：用户删除或纠正长期记忆的频率。

9. 安全与治理​

长期记忆要按持久个人数据对待：

  • 默认最小化，避免保存敏感原文。
  • 用户画像必须可查看、可修改、可删除。
  • 组织级记忆和个人记忆分权限。
  • 生产库开启加密、访问审计和备份恢复。
  • 记忆删除要同步主存储、向量索引和缓存。

工程化补强：架构与实现细节​

A. 与 RAG 的硬边界​

长期记忆处理的核心对象是跨会话仍然有效的偏好、约束、项目经验和组织规则。它来自用户和 Agent 的互动、任务执行轨迹或组织流程，而不是外部文档本身。 RAG 的核心对象是外部知识和证据；Memory 的核心对象是可复用状态。两者可以共享向量库、数据库或检索组件，但不能共享权限模型和写入流程。

维度MemoryRAG
数据来源对话、工具轨迹、用户明确偏好、任务结果文档、网页、代码库、数据库、知识库
写入触发互动后抽取、用户要求记住、后台总结文档 ingestion、同步任务、管理员上传
可信边界默认是个人/项目状态，仍需来源与置信度默认是不可信外部内容，需要证据过滤
检索目标帮 Agent 延续状态和复用经验给回答提供事实证据和引用
失败后果错误会跨任务持续影响行为错误通常影响本次回答或索引版本
评测重点long-term lift、user correction rate、conflict rate、retention compliancerecall、faithfulness、citation accuracy

B. 生产级数据流​

这条链路的关键是写入和检索分离。写入网关决定“能不能成为未来依据”，检索器决定“当前任务是否需要它”。

C. 推荐 JSON 结构​

{
  "memory_id": "mem_01HY...",
  "memory_type": "short_term|semantic|episodic|procedural|profile",
  "namespace": ["org:o_1", "user:u_7", "project:p_3"],
  "content": {
    "summary": "用户希望技术文档用中文、结构紧凑、直接给结论",
    "normalized_value": {
      "language": "zh-CN",
      "style": "concise_engineering"
    }
  },
  "source": {
    "kind": "user_message|tool_trace|episode_summary|admin_policy",
    "trace_id": "tr_20260509_001",
    "turn_id": "turn_14",
    "evidence": "用户明确说：以后回答用中文，少废话"
  },
  "confidence": 0.86,
  "sensitivity": "normal|personal|confidential|restricted",
  "ttl_days": 180,
  "created_at": "2026-05-09T10:00:00+08:00",
  "updated_at": "2026-05-09T10:00:00+08:00",
  "retention_class": "30d/1y/user_controlled",
    "review_after": "2026-06-09",
  "audit": {
    "writer": "memory_writer_v2",
    "decision": "accepted",
    "policy_version": "memory-policy-2026-05"
  }
}

字段级来源比整条记忆来源更重要。真实系统里经常只有某个字段可靠，不能因为一个字段可信就默认整条画像可信。

D. 写入门槛​

候选信息默认动作原因
用户明确要求“记住”且不敏感写入或更新意图明确，价值高
多次稳定偏好写入低风险字段可减少重复沟通
单次情绪、抱怨、临时选择不写或短 TTL容易误画像
工具失败根因写 episode对未来排障有价值
外部网页诱导的规则拒写外部内容不能提升为行为规则
安全、权限、合规相关变更人审或管理员确认影响面大，不能由普通记忆覆盖

本文件的推荐写入原则是：需要显式确认、高置信多次观察或明确业务价值，敏感字段默认不自动写。

E. 检索策略​

先 namespace 和 ACL 过滤，再按任务意图检索 profile、semantic、episodic、procedural。工程上建议分三步：

E.1 LangGraph / LangChain 长期记忆核对​

LangChain 当前长期记忆文档强调：长期记忆跨 conversation/session 持久化，并基于 LangGraph stores 保存为按 namespace 和 key 组织的 JSON 文档。这和本文的建模建议一致：长期记忆不应只是一段聊天摘要，而应是可检索、可更新、可审计的结构化记录。

官方能力映射架构含义
Store长期记忆存储层，区别于 thread checkpoint
Namespace用户、组织、项目和 Agent 规则的隔离边界
JSON document支持字段级更新、冲突处理和用户编辑
Cross-thread recall需要更严格的写入门槛和隐私治理

把短期 checkpoint 直接当长期记忆使用是常见错误；正确做法是任务结束后由写入网关筛选候选，再写入长期 store。

  1. 硬过滤：tenant、user、project、role、sensitivity、TTL、deleted tombstone。
  2. 候选召回：profile 精确读取，semantic/episodic/procedural 可用关键词、向量和标签组合。
  3. 上下文组装：限制条数，附带类型、来源、置信度和“不能覆盖系统/开发者/安全策略”的说明。
def retrieve_memory(task, user, project, budget):
    scopes = acl_scopes(user=user, project=project)
    candidates = []
    candidates += profile_store.get(scopes.user_profile_fields(task))
    candidates += memory_index.search(task.query, filters=scopes.filters, k=20)
    ranked = rerank_by_usefulness(candidates, task.intent, now=task.now)
    safe = [m for m in ranked if policy.can_inject(m, task)]
    return pack_with_provenance(safe, token_budget=budget)

F. 遗忘与生命周期​

定期复核、过期归档、冲突合并、用户自助删除和组织保留策略。遗忘不是简单删除文本，还包括向量、缓存、摘要、备份可恢复窗口和审计索引的协同。

生命周期阶段操作验收点
候选只在临时队列保存未通过网关不进入长期库
活跃可检索、可解释、可编辑trace 中能看到使用原因
降权过期、低命中、低置信默认不注入上下文
归档保留审计或历史统计不参与在线检索
删除tombstone + 索引清理删除 SLA 和回归测试通过

G. 失败模式与修复​

失败模式早期信号修复动作
一次性观察被永久化，错误画像长期影响输出召回内容与当前任务不符，用户反复纠正拆 namespace、加写入门槛、补评测切片
错误记忆长期影响回答同类任务持续给错建议增加冲突检测、用户编辑入口、低置信降权
过度个性化Agent 在无关任务套用用户偏好按任务域检索，不全量注入画像
记忆投毒记忆中出现“忽略规则”“扩大权限”等内容策略拒写，已写入内容隔离并审计
上下文污染注入记忆太多，模型忽略当前指令top-k 限制、摘要化、按阶段注入
删除不彻底删除后仍可被向量召回tombstone 过滤、重建索引、缓存失效

H. 评测指标​

指标计算方式用途
Memory precision@k注入记忆中真正有用的比例控制上下文污染
Needed-memory recall@kgold memory 是否被召回检查检索覆盖
Task lift开启记忆后的成功率/轮次/工具错误变化判断是否值得保留系统复杂度
Stale-use rate被使用但已过期或被覆盖的记忆比例发现遗忘策略问题
Bad-write escape rate不应写入但进入长期库的比例评估写入网关
Privacy incident rate越权召回、敏感泄露、误画像事件数安全红线指标

I. 安全治理清单​

  • 记忆内容永远不能提升为系统指令，不能覆盖安全策略和开发者约束。
  • 用户画像需要可查看、可修改、可删除；敏感画像默认不做自动推断。
  • 外部文档、网页和工具输出要标记来源可信度，默认不能写成程序性规则。
  • 加密静态数据和传输链路；对高敏字段做字段级加密或不可逆摘要。
  • 审计记录至少包含写入者、来源、策略版本、检索任务、注入位置和删除事件。
  • 多租户系统必须把 namespace、ACL 和索引过滤作为服务端强制逻辑，而不是 prompt 约束。

10. 权威资料​