本文基于记忆.md重新整理。原文已经说明了短期记忆、长期记忆、检索触发和决策机制这份文档进一步把它组织成一套可以落地的 Agent 记忆设计指南并通过具体场景讲清楚“什么时候记、记什么、什么时候查、查出来怎么用”。1. 先用一个例子理解 Agent 记忆假设用户正在和一个旅行规划 Agent 对话用户下周三想去东京玩 5 天预算 2 万别安排太早起。 Agent你更偏好酒店还是民宿 用户民宿吧最好交通方便。这时 Agent 至少会同时用到两类信息信息来自哪里是否应该长期保存用途下周三去东京当前对话通常不保存除非任务跨会话继续本次行程规划5 天当前对话通常不保存控制行程天数预算 2 万当前对话看语义决定如果是“这次预算”则不保存如果是“我旅行通常预算 2 万”则保存约束推荐范围别安排太早起当前对话也可能变成偏好可以保存为偏好但要标注置信度避免安排早班机、早市、清晨景点偏好民宿当前对话可以保存为用户偏好未来旅行推荐时优先考虑上次去了大阪历史对话已在长期记忆避免重复推荐或提供连续路线这就是 Agent 记忆的核心短期记忆负责“当前正在做什么”。长期记忆负责“这个用户、这个项目、这个世界过去有哪些可复用信息”。记忆调度器负责判断“现在要不要查长期记忆要不要把当前信息写进去”。如果只靠短期记忆Agent 只能在本轮对话里连贯如果长期记忆随便注入又会把无关、过时甚至错误的信息带进回答。真正可用的记忆系统不是“记得越多越好”而是“该记的记该忘的忘该查的时候查查到后谨慎使用”。2. 原文核心观点重组原文可以提炼成四个工程问题记忆分层短期记忆和长期记忆分别承担什么职责写入策略哪些信息值得进入长期记忆哪些只应该留在当前上下文检索策略什么时候需要从长期记忆中取信息由谁决定用什么算法决定治理策略如何处理上下文腐烂、信息冲突、隐私风险和成本失控这四个问题对应一套完整闭环用户输入 - 更新短期记忆 - 判断是否检索长期记忆 - 召回、排序、过滤相关记忆 - 注入当前上下文 - 生成回答或执行动作 - 提取值得保存的信息 - 去重、冲突检查、写入长期记忆注意这里有两条路径读路径从长期记忆检索信息帮助当前回答。写路径从当前对话提取信息沉淀为未来可用的长期记忆。很多 Agent 记忆设计失败不是因为没有向量数据库而是只做了“存”和“查”没有认真设计读写时机、记忆质量、冲突规则和验证机制。3. 记忆分层不要把所有信息塞进一个篮子3.1 短期记忆当前任务的工作台短期记忆是 Agent 处理当前任务时可直接看到的信息通常由以下内容组成系统指令和开发者约束。当前用户请求。本轮或最近多轮对话历史。工具调用结果。当前任务计划、已完成步骤和中间产物。它的特点是强相关主要服务当前任务。高时效当前轮次结束后价值快速下降。容量有限受上下文窗口限制。容易污染塞太多无关内容会降低模型注意力质量。例子代码修复 Agent 正在处理一个测试失败。短期记忆中应保留 - 用户要求修复登录接口 500 错误。 - 当前报错TypeError: cannot read property id of undefined。 - 已读文件auth_controller.ts、session_service.ts。 - 已尝试方案补充空值判断但单测仍失败。 - 下一步计划检查 middleware 是否注入 user。这些信息不一定适合长期保存因为它们大多只对当前修复任务有意义。3.2 长期记忆跨会话可复用的经验库长期记忆是外部持久化存储中的信息不会天然出现在模型上下文里需要按需检索。它通常存储在普通文件或 Markdown 笔记。关系型数据库或键值数据库。向量数据库。知识图谱。事件日志和摘要库。长期记忆适合保存类型例子使用价值用户偏好用户喜欢 Python、回答要直接、不要太多概念个性化输出项目事实项目使用 FastAPI、数据库是 PostgreSQL降低重复询问历史决策上次已决定不用 Redis原因是部署复杂避免反复讨论经验教训某接口超时通常是供应商 API 慢加速排障摘要记忆某次长会话的目标、结论、待办支撑跨会话任务领域知识公司报销规则、内部命名规范提高一致性例子一个长期协作的编程 Agent 可以记住{type:project_fact,scope:project:CheckMCP,content:该项目的文档主要放在 book/cn 目录中文长文倾向使用章节式标题和表格对比。,source:用户历史任务和文件结构,confidence:0.82,updated_at:2026-08-26}这条记忆对未来写同类文档有价值但不应该每次都注入只有当用户要求整理该项目文档时才检索。3.3 中间层记忆摘要、缓存和元记忆实际工程中不建议只分“短期”和“长期”两层。更实用的分层是层级名称生命周期典型内容L0当前上下文当前请求用户输入、工具结果、当前计划L1会话摘要当前会话本次会话的压缩进展L2近期缓存最近几次会话最近任务标签、常用实体、未完成事项L3长期记忆长期保存用户偏好、项目事实、历史决策L4元记忆长期保存哪些记忆可信、哪些记忆常被误用、哪些信息需要确认例子用户说“继续上次那个 MCP 文档”。合理的检索顺序不是直接查全量长期记忆而是1. 查 L1当前会话是否已经有“上次 MCP 文档”的摘要 2. 查 L2最近几次会话是否有 MCP 文档任务标签 3. 查 L3长期记忆里是否有项目文档结构、用户写作偏好、历史决策 4. 查 L4是否存在“这个用户不喜欢纯概念说明偏好实例”的元偏好这样可以降低成本也能减少无关记忆污染。4. 写入策略什么时候应该记住写入长期记忆的关键不是“能不能存”而是“值得不值得存”。可以把每条候选信息问五个问题未来是否会复用是否足够稳定是否与用户、项目、任务或领域有关是否已经存在同类记忆是否涉及隐私、敏感信息或用户不希望保存的内容4.1 应该保存的信息下面这些信息通常值得进入长期记忆候选信息是否保存原因“以后回答我尽量多举例不要只讲概念。”保存明确、稳定、未来高频复用“这个项目的中文文档要用章节式结构。”保存项目级风格偏好“我们决定用 SQLite 做本地缓存不引入 Redis。”保存重要历史决策未来可能影响设计“用户正在写 Agent 相关教程。”可保存如果未来持续相关可作为任务背景“上次线上故障是 Nginx 超时配置导致。”保存可复用的排障经验4.2 不应该保存的信息下面这些信息不应直接长期保存候选信息不保存原因更好的处理“今天心情不好。”可能只是短期状态仅用于当前对话语气调整“这次旅行预算 500 美元。”单次任务约束不一定是长期偏好保留在任务状态中“我的银行卡号是…”高敏感信息不保存必要时提醒安全风险“我可能喜欢 Go。”不确定、低置信度暂存为低置信候选后续确认“随便吧。”没有稳定语义不保存4.3 写入流程示例用户说以后帮我写技术文档时尽量先给真实场景再解释概念。记忆系统不应该直接把整句话塞进数据库而应提取成结构化记忆{type:user_preference,scope:user,key:technical_writing_style,value:技术文档应先给真实场景或案例再解释概念。,evidence:用户明确要求以后帮我写技术文档时尽量先给真实场景再解释概念。,confidence:0.95,policy:inject_when_task_is_technical_writing,updated_at:2026-08-26}这样做有三个好处未来检索更准确。可以处理冲突更新。注入上下文时更短、更清晰。4.4 写入不是立即永久保存比较稳妥的工程做法是把写入分成三段原始对话 - 候选记忆 - 经过过滤和确认的长期记忆例子用户我最近都在写 Python感觉 TS 太麻烦。候选记忆可以是{type:candidate_preference,content:用户近期更偏好 Python对 TypeScript 有一定抵触。,confidence:0.55,ttl:30d}但不应立刻升级为“用户长期偏好 Python不喜欢 TypeScript”。因为这句话可能只是某个项目中的临时情绪。后续如果用户多次表达类似偏好或者明确说“以后默认用 Python”才适合升级为长期偏好。5. 读取策略什么时候应该检索长期记忆长期记忆不应该每次都查也不应该查了就全塞进提示词。读取策略要解决两个问题是否需要查查到哪些内容应该注入5.1 触发检索的典型信号信号用户表达或系统状态例子应对显式回忆用户提到“上次”“之前”“还记得”“按上次的结构继续写。”检索相关历史摘要个性化需求用户要求“按我的习惯”“按我喜欢的风格改。”检索用户偏好项目上下文缺口当前任务依赖项目背景“继续整理这个文档体系。”检索项目事实和历史决策任务跨阶段多步任务进入新阶段从调研进入写报告检索目标、约束和已完成内容上下文窗口将满token 占用达到阈值长对话超过 70% 到 80% 水位压缩摘要替换低价值历史事实缺口当前上下文缺少必要事实“公司内部报销规则是什么”检索知识库或外部事实源5.2 由谁决定是否检索一个成熟系统通常不是让 LLM 单独决定而是多层共同判断。层级决策主体适合做什么底层系统钩子规则、向量相似度、关键词检测低成本预检、主动预取中层编排器Router、Orchestrator、LangGraph 条件边根据任务状态强制检索或跳过顶层 AgentLLM 自主推理、工具调用处理复杂语义、模糊请求和特殊场景例子用户说“按照我上次喜欢的方式写一个 README”。底层钩子检测到“上次”“喜欢的方式”命中回忆信号。 中层编排器当前任务类型是文档写作决定检索 writing_style 相关记忆。 顶层 Agent判断还需要项目 README 历史结构于是调用 search_memory(README 文档风格 项目结构)。5.3 怎么决定四种常用机制机制一语义路由把用户输入转成向量与长期记忆索引做相似度计算。if max_similarity(user_query, memory_index) 0.75: retrieve_top_k_memories() else: skip_memory_retrieval()例子用户这篇文档还是按我喜欢的那种写法来。可能召回用户偏好技术文档应先给真实场景再解释概念。 用户偏好希望回答更详细但不要堆概念。机制二规则和水位线规则适合处理确定性强的场景。if token_usage 0.8 * context_window: summarize_old_messages() if user_query contains [上次, 之前, 继续, 按我的习惯]: retrieve_user_or_project_memory()例子长文档写作对话已经进行了 60 轮这时继续把所有历史消息塞进上下文会造成上下文腐烂。更好的做法是保留- 当前目标。 - 已确认的大纲。 - 用户明确修改意见。 - 未完成章节。 - 关键术语和风格要求。低价值内容比如寒暄、已废弃方案、重复解释可以被摘要替换。机制三LLM 自反判断把“是否需要记忆”交给 LLM 做二分类判断。输入 - 当前用户问题 - 当前上下文摘要 - 可用记忆类型列表 输出 - need_memory: true/false - memory_scope: user/project/domain/task - query: 用于检索的短查询 - reason: 为什么需要例子用户帮我继续昨天那份市场报告把风险部分补上。LLM 可能输出{need_memory:true,memory_scope:task,query:昨天 市场报告 风险部分 大纲 结论,reason:当前请求依赖历史任务状态当前上下文没有报告内容。}这种方式更聪明但成本更高适合复杂任务或高价值任务。机制四缓存漏斗不要一上来就查全量向量库。可以按成本从低到高逐级扩大L1 当前会话摘要 - L2 最近任务标签 - L3 用户画像和项目记忆 - L4 全量向量库或知识图谱例子用户说“继续刚才那个”。如果 L1 已经知道“刚才那个”是Agent 记忆设计文档就不需要查长期库。如果 L1 不知道但 L2 最近任务标签有记忆.md 重构再查对应摘要。如果 L2 也没有再查 L3/L4。这比每次都做全量检索更便宜也更不容易召回无关记忆。6. 检索出来后怎么用检索不是结束真正影响效果的是注入方式。一个常见错误是把 Top-K 结果原样塞进 prompt导致上下文臃肿甚至互相矛盾。6.1 推荐使用“记忆卡片”把检索结果整理为短小、可审计的记忆卡片相关记忆 1. [用户偏好][高置信] 用户希望技术文档多用实例不要只讲概念。 2. [项目事实][中置信] 当前项目文档多采用“章节标题 表格 示例”的中文教程风格。 3. [历史决策][高置信] 本次任务目标是把 book/记忆.md 重构为 Agent记忆设计.md。 使用要求 - 只使用与当前文档重构直接相关的记忆。 - 如果记忆与用户当前明确要求冲突以当前要求为准。这种形式比原始日志更适合放进上下文因为它短、结构清晰、置信度明确。6.2 注入时要区分事实、偏好和建议例子检索到三条记忆。A. 用户喜欢 Python。 B. 用户正在写 Agent 文档。 C. 建议使用向量数据库。它们不能被同等对待A 是用户偏好影响示例语言选择。B 是任务背景影响上下文理解。C 只是历史建议不一定仍然成立不能当作硬约束。因此注入时应标明类型[偏好] 用户偏好 Python 示例。 [任务背景] 用户近期在整理 Agent 文档。 [历史建议] 曾讨论过向量数据库但当前任务未确认采用。6.3 记忆不能覆盖当前用户指令如果长期记忆说“用户喜欢详细解释”但当前用户说“这次只给简短结论”应优先当前指令。推荐优先级当前用户明确指令 当前任务约束 项目级规则 用户长期偏好 历史建议或低置信记忆例子长期记忆用户喜欢详细讲解。 当前请求只要一个 5 行总结。 正确行为输出 5 行总结而不是展开长篇说明。7. 冲突处理记忆会过期也会互相打架长期记忆如果没有治理很快会变成“错误长期保存系统”。7.1 典型冲突类型冲突类型例子处理方式用户偏好更新原来喜欢 Java现在明确说以后默认 Python更新主记忆保留历史变更记录任务约束变化预算从 500 美元改为 800 美元当前任务状态中覆盖旧值项目事实变化项目从 Flask 迁移到 FastAPI标记旧记忆过期写入新事实低置信误判系统误以为用户讨厌 TypeScript降低置信度或删除当前指令冲突长期偏好详细当前要求简短当前指令优先7.2 预算更新例子错误做法长期记忆 1用户东京旅行预算 500 美元。 长期记忆 2用户东京旅行预算 800 美元。这会让后续 Agent 不知道该相信哪一个。更好的做法{type:task_state,key:tokyo_trip_budget,value:800 USD,previous_value:500 USD,change_reason:用户在当前会话中更新预算,valid_for:current_trip_planning_task,updated_at:2026-08-26}如果用户说的是“以后我旅行预算通常按 800 美元算”才适合进入长期偏好。7.3 用户偏好变化例子用户过去多次说喜欢 Python今天说这个项目以后全部用 TypeScript不要再给 Python 示例。正确处理不是删除“用户喜欢 Python”而是加上作用域{type:project_preference,scope:project:current,content:当前项目默认使用 TypeScript 示例不使用 Python 示例。,overrides:user_preference:python_examples,confidence:0.96}这样未来在当前项目中优先使用 TypeScript在其他泛化场景仍可参考用户的 Python 偏好。8. 记忆系统的推荐架构一个可落地的 Agent 记忆系统可以拆成七个模块。输入流 - Memory Collector 收集对话、工具结果、任务状态 - Memory Extractor 提取候选记忆 - Memory Validator 去重、过滤、权限和敏感性检查 - Memory Store 持久化存储 - Memory Retriever 按需检索 - Memory Ranker 相关性、时效性、置信度排序 - Memory Injector 把记忆压缩成可用上下文 - Agent Response/Action 生成回答或执行动作8.1 Memory Collector收集原始材料收集内容包括用户消息。Agent 输出。工具调用和结果。任务状态变更。用户确认或否定。例子用户说“对这个结构就按这个版本定稿”。Collector 应捕获这是一个确认信号而不是普通闲聊。8.2 Memory Extractor提取候选记忆Extractor 把原始文本变成结构化候选。原始文本以后写这种 Agent 文档最好先讲真实例子再讲架构。 候选记忆 - 类型用户偏好 - 范围技术文档写作 - 内容先用真实例子引入再讲架构和概念 - 置信度高8.3 Memory Validator判断能不能存Validator 需要回答是否重复是否冲突是否敏感是否需要用户确认是否只是当前任务状态例子用户这次就写详细点。这不应该升级成“用户永远喜欢详细文档”。Validator 应把它标为当前任务约束。8.4 Memory Store选择合适存储存储适合内容不适合内容JSON/Profile用户偏好、项目配置大量非结构化日志SQL结构化事实、任务状态、审计记录语义模糊的长文本检索向量数据库摘要、片段、经验、非结构化知识强一致更新和精确约束知识图谱实体关系、组织结构、依赖关系简单偏好和临时状态文件/Markdown人可读项目记忆、设计记录高频实时更新一个实用 MVP 可以从“JSON 用户画像 Markdown 项目记忆 向量摘要库”开始不必一开始就上复杂知识图谱。8.5 Memory Retriever 和 Ranker召回后还要排序排序可以综合四类分数final_score semantic_similarity recency_weight frequency_weight confidence_weight - sensitivity_penalty - staleness_penalty例子同样都命中“文档风格”下面哪条更应注入A. 2 年前用户喜欢非常长的解释。 B. 今天用户要求这篇 Agent 记忆文档多举实例。 C. 上周用户希望技术文档按章节和表格组织。对于当前任务排序应是 B、C、A。因为 B 最新且最具体C 与任务相关A 太泛且可能过期。8.6 Memory Injector只注入必要内容Injector 的目标不是“把检索结果放进去”而是“把当前任务真正需要的记忆压缩成清晰约束”。例子当前任务相关记忆 - 用户要求本次文档多举实例避免纯概念说明。 - 原文重点包括短期记忆、长期记忆、检索触发、Router/LLM/Hook 三层决策。 - 周边文档风格偏章节式教程适合加入表格和案例。这比塞入三段历史聊天记录更有效。9. 三个完整案例9.1 案例一旅行规划 Agent场景用户希望规划东京旅行。用户下周三去东京5 天预算 2 万别太累。短期记忆{destination:东京,start_date:下周三,duration_days:5,budget:2 万,pace:不要太累}长期记忆检索触发原因旅行规划高度依赖用户偏好。可能召回- 用户偏好民宿。 - 用户讨厌早起。 - 用户上次去大阪时喜欢本地小店不喜欢网红打卡点。最终使用Agent 不应说“我记得你讨厌早起所以绝不安排上午活动。”因为这可能太绝对。更稳妥的回答是我会按轻松节奏安排上午不放太早的活动住宿优先考虑交通方便的民宿。第一天建议只安排抵达和附近用餐第二天再开始主景点。写入长期记忆如果用户后续确认对我旅行一直不喜欢早起住宿也更喜欢民宿。则可以写入[{type:user_preference,scope:travel,content:用户旅行时不喜欢早起。,confidence:0.95},{type:user_preference,scope:travel,content:用户旅行住宿更偏好民宿。,confidence:0.95}]9.2 案例二编程 Agent场景用户说继续修昨天那个登录接口的问题。当前上下文没有“昨天那个问题”的细节因此应触发长期记忆检索。检索查询query 昨天 登录接口 问题 报错 修复进展 scope project recent_task召回记忆- 昨天定位到登录接口 500 错误与 session middleware 未注入 user 有关。 - 已尝试在 controller 层加空值判断但单测仍失败。 - 下一步计划是检查 auth middleware 的执行顺序。 - 项目使用 TypeScript Express测试命令为 npm test。注入上下文任务恢复摘要 用户要继续修复登录接口 500 错误。上次进展显示 controller 层空值判断不是根因下一步应检查 auth middleware 是否在路由前执行。项目使用 TypeScript Express验证命令是 npm test。为什么这样设计如果没有记忆Agent 可能重新读一遍所有文件浪费时间如果注入完整昨天聊天记录又会浪费上下文。摘要式任务恢复最合适。写入长期记忆修复完成后值得保存的是“经验教训”不是所有调试日志。{type:debug_lesson,scope:project:login,content:登录接口 500 错误曾由 auth middleware 执行顺序错误导致排查时应先检查路由注册顺序和 user 注入。,confidence:0.9}9.3 案例三客服 Agent场景用户再次咨询 SaaS 产品的账单问题用户为什么这个月又多扣了一笔需要的记忆客服场景不能只靠用户偏好还要检索历史工单、订阅状态和账单事实。短期记忆用户当前询问本月多扣款。 长期记忆上月用户曾升级团队套餐享受过 14 天试用。 外部事实账单系统显示本月从试用转为正式订阅。正确回答方式我查到你上月把账号升级为团队套餐当时有 14 天试用。本月这笔费用是试用结束后的正式订阅扣款。我可以继续帮你核对扣款日期和套餐人数如果人数不对再进一步处理退款或调整。记忆治理重点客服 Agent 的记忆需要更严格账单事实必须来自可信系统不应仅凭历史对话。敏感信息不应直接写入长期记忆。用户争议和投诉要保存审计记录但回答时要避免泄露内部备注。10. 常见误区10.1 误区一上下文窗口就是记忆上下文窗口只是短期记忆的载体。它能让模型看到当前材料但不能天然跨会话持久化也不能自己决定什么值得保存。10.2 误区二有向量数据库就有记忆向量数据库只是存储和检索工具不等于记忆系统。完整记忆系统还需要信息提取。语义去重。冲突更新。置信度管理。权限控制。注入策略。评估指标。10.3 误区三记忆越多越智能记忆过多会导致检索噪声变大。上下文成本升高。过时信息污染回答。用户隐私风险增加。好的 Agent 应该像一个靠谱助手不是什么都记而是知道哪些信息会影响未来决策。10.4 误区四摘要一定安全摘要会压缩上下文但也可能丢掉关键细节。例子原文用户不喜欢早起但如果是筑地市场这种特殊体验可以接受 7 点以后。 错误摘要用户不喜欢早起。错误摘要会让 Agent 永远不安排上午活动。更好的摘要是用户一般不喜欢早起旅行中可接受少量 7 点以后的特殊体验但不应连续安排早起。11. 最小可用方案从简单系统开始如果要从 0 到 1 搭建 Agent 记忆不建议一开始做很复杂。可以先实现一个 MVP。11.1 MVP 架构短期记忆当前 messages task_state 会话摘要每 10 到 20 轮压缩一次 长期记忆user_profile.json project_memory.md vector_summaries 检索触发关键词规则 相似度阈值 注入策略最多注入 3 到 5 条记忆卡片 写入策略只保存明确偏好、项目事实、历史决策和任务摘要11.2 MVP 数据结构{id:mem_001,type:user_preference,scope:technical_writing,content:用户希望技术文档多用真实案例不要只讲概念。,tags:[writing,agent,examples],confidence:0.95,source:explicit_user_instruction,created_at:2026-08-26,updated_at:2026-08-26,ttl:null}11.3 MVP 检索规则触发检索如果满足任一条件 1. 用户输入包含“上次、之前、继续、按我的习惯、记得”。 2. 当前任务类型属于长任务写报告、写代码、调试、研究、规划。 3. 当前上下文 token 水位超过 80%需要摘要替换。 4. 当前问题与某条记忆向量相似度超过 0.75。11.4 MVP 写入规则允许写入 - 用户明确表达的长期偏好。 - 项目中已确认的技术事实。 - 跨会话任务的阶段性摘要。 - 经过验证的问题原因和解决方案。 禁止写入 - 敏感凭据。 - 单次闲聊情绪。 - 未确认的猜测。 - 与当前用户指令无关的原始对话全文。12. 评估记忆系统是否好用记忆系统必须评估否则很容易“看起来聪明实际上乱记”。12.1 读路径指标指标问题示例召回率该查的有没有查到用户说“继续上次报告”是否找到报告摘要精确率查到的是不是相关是否把旅行偏好注入到代码任务里新鲜度是否用了过时信息是否仍使用旧预算、旧技术栈成本检索和注入是否过多每轮都注入 20 条记忆就是危险信号延迟记忆检索是否拖慢响应是否需要预取或缓存12.2 写路径指标指标问题示例写入质量保存的信息是否结构化、可复用“用户喜欢例子”比整段原话更好去重能力是否重复保存相同偏好同一偏好不应出现 10 个版本冲突处理新旧信息冲突时是否更新预算从 500 改 800 是否覆盖隐私合规是否保存了不该保存的信息密码、银行卡、身份证号不应入库可解释性能否说明为什么使用这条记忆回答可追溯到来源和置信度12.3 测试用例示例可以为记忆系统设计测试集用例 1用户明确说“以后文档多举例”。 期望写入用户偏好未来写文档时召回。 用例 2用户说“这次预算 500等等改成 800”。 期望当前任务状态更新为 800不生成两条互相冲突的长期偏好。 用例 3用户问“继续昨天的登录 bug”。 期望召回最近任务摘要而不是全量用户画像。 用例 4用户当前要求“只给简短答案”。 期望即使长期偏好是详细解释也应服从当前指令。 用例 5用户输入银行卡号。 期望不写入长期记忆必要时提示敏感信息风险。13. 设计检查清单在实现 Agent 记忆前可以用下面的清单快速检查方案是否完整。13.1 写入检查是否区分了短期任务状态和长期偏好是否有候选记忆到正式记忆的过滤流程是否处理重复、冲突和过期是否对敏感信息默认不保存是否记录来源、时间、置信度和作用域13.2 读取检查是否只在需要时检索是否有关键词、相似度、任务状态等触发规则是否限制注入数量和长度是否区分事实、偏好、历史建议和低置信信息是否让当前用户指令优先于长期记忆13.3 治理检查用户能否查看、修改或删除记忆系统能否解释为什么使用某条记忆是否有定期清理低价值记忆的机制是否有评估数据集验证召回准确率是否监控 token 成本、延迟和错误注入14. 总结Agent 记忆不是单纯的“把聊天记录存起来”而是一套围绕任务连续性、个性化和可靠性设计的工程系统。最核心的设计原则可以概括为短期记忆管当前任务长期记忆管可复用经验。写入前先判断价值、稳定性、作用域和风险。读取时先低成本预检再按需召回和压缩注入。记忆必须有来源、时间、置信度和冲突处理规则。当前用户指令永远优先于长期记忆。如果要做一个稳妥的第一版可以从最小闭环开始会话摘要 用户偏好 JSON 项目记忆 Markdown 向量摘要检索 记忆卡片注入等读写策略、评估指标和冲突治理跑稳后再扩展到更复杂的知识图谱、主动预取、多级缓存和元记忆体系。