关掉终端再打开，Claude Code不会凭空知道你上周改到哪，也不知道最后一次调试停在哪里。AtomGit AI社区在2026年5月2日发布的文章用了类似场景：连续工作一周，终端重开，一切又从零开始。
真正丢掉的不是几轮聊天，而是“当前任务处于什么状态”。如果最近对话、执行进度和长期偏好都塞在同一条记忆链路里，Agent重启后只能靠相似片段猜现场。
《向量数据库真的能满足所有AI Agent的记忆需求吗？》在2025年1月指出，向量数据库能够处理对话记忆，却难以覆盖Agent执行长期任务时的多样化需求。一篇长期记忆研究综述也提到，许多Agent的长期记忆仍以向量数据库为主，难点在于如何平衡记忆完整性和检索效率。
问题不只是“能不能搜到”，还包括搜到的记录是否有效、是否属于当前任务，以及是否已经被新信息替代。
先别谈长期记忆，把三类信息分开
工程上没必要照搬生物学术语。更实用的划分标准是：一条信息要活多久，由谁更新，什么时候删除。
| 记忆层 | 保存什么 | 常用载体 | 过期方式 |
|---|---|---|---|
| 会话工作区 | 最近指令、工具返回、当前追问 | 上下文窗口、滑动摘要 | 会话结束或窗口淘汰 |
| 任务状态 | 当前步骤、阻塞原因、已完成动作 | LangGraph状态、Redis、SQLite | 任务完成、取消或归档 |
| 长期记忆 | 稳定偏好、领域知识、可复用流程 | 向量数据库、知识图谱、经验库 | 被新记录覆盖、主动删除或失效 |
三层可以互相引用，但不该共用一套无差别的读写规则。一次临时选择不能直接升级为永久偏好；已经废弃的方案，也不该因为语义相似而再次进入Prompt。
上下文窗口只负责眼前
上下文窗口适合保存当前会话的前N轮内容：刚收到的指令、最近一次工具调用结果，以及尚未解决的指代关系。N取决于模型窗口和调用成本，不需要设成固定的行业标准。
较早的对话可以压缩成滑动摘要，但摘要依然属于会话工作区。它解决的是“这轮对话说到哪了”，不是“这个跨天任务做到哪了”。
在LangGraph一类框架中，会话通常与session_id或thread_id绑定。会话过期后，原始内容可以按产品策略清理。确实需要跨会话保留的信息，应先经过筛选，再写入任务状态或长期记忆，而不是把整段聊天永久存下去。
跨天任务需要状态机接力
用户问过什么，不等于任务进行到哪。Agent需要一个机器可读的状态对象，明确记录当前步骤、阻塞条件和最近一次成功动作。
{
"task_id": "audit_q2_risk",
"current_step": "data_extraction",
"status": "blocked",
"blocked_by": "missing_permission_erp",
"last_successful_action": "query_logs_20260715",
"context_snapshot": {}
}
遇到报错后，Agent应先读这个对象。看到blocked_by指向ERP权限缺失，就进入追问、申请权限或等待分支，而不是先去向量库搜索一批相似报错。
在LangGraph中，这些字段可以放进graph state，并在关键节点保存checkpoint。Redis或SQLite负责持久化，具体选哪个取决于部署方式。状态对象要短、稳定、可判断，不要把整段聊天摘要塞进current_step。
这里保存的是任务进度。任务结束后提炼出的通用处理流程，才适合进入程序性长期记忆。两者混用，容易让一次性的异常处理变成后续任务的默认动作。
向量库最容易捞回“旧答案”
把用户偏好、代码Bug和项目里程碑全部写进同一个Milvus或Qdrant索引，查询很方便，返回结果却未必可靠。
相似度不负责判断一条记录是否已经作废。“昨天讨论过但已经否决的方案”可能比当前方案更接近查询词，于是再次被召回。向量库也能记住“用户喜欢Python”，却不会自动推导出“用户正在用Python写异步爬虫，并卡在协程调度上”。后一句属于持续变化的任务状态。
长期记忆至少要带上这些元数据：
user_id与project_id：限制记忆的作用范围；memory_type：区分事实、偏好、流程和任务记录；status：标记有效、废弃或已被替代；updated_at：处理偏好变化和版本冲突；source：记录信息来自用户、工具还是Agent推断。
检索时，先按项目、状态和权限过滤，再计算语义相似度。废弃记录可以为审计保留，但不应继续进入当前Prompt。
不是所有内容都值得长期保存
事实性、语义性和程序性记忆可以作为工程标签，存储方式不必强行统一。
事实性记忆适合保存用户明确确认的偏好或稳定事实，例如“后端项目优先使用Rust”。短文本可以进入向量数据库，用户、项目、来源和有效期则应放在结构化字段中。
语义性记忆关注实体和概念之间的关系。涉及Rust借用规则、Python GIL等概念及其关联时，知识图谱比一组相似片段更容易表达关系；需要补充原文细节，再调用向量检索。这也是GraphRAG常见的组合方式。
程序性记忆保存可复用的处理方法，例如“遇到并发死锁时先检查锁粒度”。这类记录最好带上触发条件、前置要求、执行步骤和结果，做成经验库或操作手册。一次成功交互只能成为候选经验，不能立刻升级为通用规则。
对于原稿提到的BIGAI通通4.0 LTUM，这里不做性能判断：现有可引用素材不足以核验其内部实现和效果。评估这类方案时，更值得核对的是四件事：能否拆分会话、任务与长期记忆；能否覆盖旧记录；是否保留来源；是否支持删除和审计。架构名称相近，实际读写规则可能完全不同。
读写顺序比存储选型更关键
记忆路由器不是把所有历史都交给LLM，而是决定这次请求究竟需要哪些信息。
一条指令进来后，可以按这个顺序处理：
- 先按
task_id读取任务状态，确认当前步骤和阻塞点； - 再加载当前会话的最近内容，补齐代词、工具结果和临时约束；
- 只有涉及跨会话偏好、历史项目或领域知识时，才查询长期记忆；
- 关系型问题先查知识图谱，文本细节再交给向量数据库；
- 召回后继续过滤，排除已关闭的Bug、被替代的偏好和其他项目的记录。
最终送给模型的内容，只要足够支撑当前步骤即可。材料更多，不代表判断一定更准。
写入同样要经过路由：
- 最近对话追加到会话工作区；
- 步骤变化、工具结果和错误现场更新到任务状态；
- 用户明确确认的偏好进入长期记忆候选区；
- 任务结束后，反思Agent可以生成程序性记忆候选，但不能直接覆盖正式经验库。
候选记录通过验证后，再做记忆巩固：合并重复片段、标记冲突，用新记录替代旧记录。只追加、不覆盖的记忆库，运行时间越长，噪声通常越多。
真正容易出事的是覆盖、权限和验收
偏好会变。用户今天要求回答简洁，下次可能需要完整推导。长期记忆要带时间、来源和状态；收到新指令时，应优先覆盖旧偏好，而不是让两条冲突记录同时参与检索。
Embedding也不等于自动脱敏。敏感原文、元数据和访问权限都要单独管理。长期用户画像应遵循最小化存储原则，并提供删除入口；确实需要保留的敏感信息，应放在本地或受控的加密环境中。
验收时也别只盯着一组基准数字。《2026年Agent记忆系统方案横评与选型指南》提到，不同评测方法和版本变化会造成结果分歧。更可靠的做法，是重放自己的跨会话任务：
- 进程重启后，能否恢复到原来的步骤；
- 已经作废的方案，是否还会被召回；
- 用户纠正偏好后，旧记录会不会再次出现。
判断分层是否真正生效，有个朴素标准：Agent恢复任务时，先看到状态机，再按需读取长期记忆，最后只把当前步骤需要的信息装进上下文。如果每次重启仍从全量向量搜索开始，这套分层就还没有真正工作。
