很多人做 Agent第一个版本看起来都很聪明。用户问一句它能答一句 接一个工具它能调用 塞一点上下文它也能分析。但只要对话稍微长一点问题马上暴露前面刚说过的要求后面就忘了 用户已经确认过的结论下一轮又重新问 今天聊过的偏好明天打开又像第一次见面 历史信息越塞越多Prompt 越来越长效果反而越来越不稳定。这时候你会发现没有记忆系统的 Agent本质上只是一个“会调用工具的聊天窗口”。真正能落地的 Agent一定要解决一个核心问题Agent 到底应该记住什么 应该忘掉什么 什么时候用短期记忆 什么时候用长期记忆 记错了、记重了、记过期了又该怎么治理这也是大厂面试里非常高频的问题Agent 的记忆系统是什么短期记忆和长期记忆方案怎么设计一、先给面试官一个标准答案在工程落地里我通常会把 Agent 的记忆系统拆成两层第一层是短期记忆。短期记忆主要服务当前会话用来保证当前任务不断片。常见方案包括最近 N 轮对话窗口最近 N 个 token 截断滚动摘要当前任务状态缓存工具调用结果缓存它解决的是当前这轮对话里Agent 不要前言不搭后语。第二层是长期记忆。长期记忆主要服务跨会话、跨任务的历史信息复用。常见方案包括用户画像 / 偏好存储结构化数据库向量数据库文档记忆图谱记忆它解决的是用户下次再来Agent 不要像第一次见面。但真正的重点不在“存不存”而在什么内容值得存存成什么结构什么时候召回召回多少旧记忆和新记忆冲突怎么办用户要求删除怎么办一句话总结短期记忆解决当前会话连贯性长期记忆解决跨会话个性化和历史复用记忆治理决定这个系统能不能长期稳定运行。二、为什么 Agent 一定需要记忆系统很多人以为 Agent 只要有大模型、有工具调用、有工作流编排就够了。但真实业务里Agent 很少只是一次性问答。比如一个测试开发助手用户第一轮说这个项目是电商下单链路核心接口包括登录、商品查询、购物车、提交订单、支付回调和订单状态查询。 测试方案要按业务风险分层不要只按接口数量堆用例。第十轮用户说那你帮我把这套接口自动化方案整理成评审文档。如果没有记忆系统Agent 可能已经忘了项目是电商下单链路核心接口有哪些用户要求按业务风险分层前面已经确认过哪些高风险场景哪些方案已经被用户否定过自动化脚本需要考虑哪些环境约束最后生成的内容可能看起来很完整但完全不贴合当前任务。这就是很多 Agent Demo 能演示、难落地的原因。它不是不会回答而是不会持续记住上下文。三、Agent 记忆系统整体架构一个比较完整的 Agent 记忆系统可以抽象成下面这张图从工程视角看记忆系统不是简单地“保存聊天记录”。它至少包含五个模块模块作用核心问题短期记忆管理维护当前会话上下文怎么不超 Prompt 长度任务状态管理保存当前任务进度怎么避免任务断片长期记忆存储保存跨会话信息什么内容值得长期存记忆检索找到相关历史信息怎么召回准、不污染上下文记忆治理清理、合并、更新、删除怎么避免记忆库变脏面试时只说“用向量库存历史对话”是不够的。更好的回答是记忆系统本质上是围绕上下文生命周期设计的一套工程能力既要解决模型窗口限制也要解决跨会话信息复用还要考虑记忆准入、检索质量、冲突更新和用户可控。四、短期记忆方案一固定窗口截断最简单的短期记忆方案就是固定窗口截断。比如只保留最近 10 轮对话只保留最近 8000 个 token超出窗口的历史内容直接丢弃伪代码大概是这样def build_short_term_context(messages, max_rounds10): return messages[-max_rounds:]或者按 token 控制def truncate_by_token(messages, max_tokens): result [] total_tokens 0 for msg in reversed(messages): token_count count_tokens(msg[content]) if total_tokens token_count max_tokens: break result.insert(0, msg) total_tokens token_count return result这种方案非常常见尤其适合简单客服闲聊机器人单轮任务问答信息价值衰减很快的场景它的优点很明确优点说明实现简单不需要复杂架构成本低不需要额外模型调用长度稳定Prompt 可控响应快没有额外摘要和检索成本但它的问题也很明显固定窗口截断是一种“一刀切”的遗忘机制。如果早期对话里有关键约束被截掉之后Agent 就会突然失忆。比如用户一开始说这次接口自动化方案要优先覆盖订单主链路不要只测接口返回 200。如果对话很长这句话被截掉了Agent 后面可能又开始机械地罗列接口状态码校验。再比如用户前面已经否定过一个方案不要依赖线上真实支付渠道支付回调要用 Mock 服务模拟。如果这句话被截断Agent 后面又建议接入真实支付环境就会显得非常不专业。所以固定窗口截断适合简单场景但不适合长任务和复杂协作。五、短期记忆方案二滚动摘要滚动摘要是更适合长任务的方案。核心思路是当对话历史快要超出窗口时不直接丢掉早期内容而是先把它压缩成摘要再用摘要替代原始对话。流程如下为了避免这个例子太抽象我们用测试开发场景来看。假设一个 Agent 正在协助测试团队设计电商下单链路的接口自动化方案。这个任务不是一问一答就能完成的它会经历需求澄清、链路拆解、风险识别、用例设计、数据准备、脚本生成和结果复盘。如果没有短期记忆Agent 很容易在后续对话中忘记前面已经确认过的业务链路、风险优先级和测试约束。这时滚动摘要就可以把前面多轮对话压缩成一份结构化任务状态【任务目标】 用户正在让 Agent 协助设计一套电商下单流程的接口自动化测试方案。 【业务背景】 1. 核心链路包括登录、浏览商品、加入购物车、提交订单、支付回调、订单状态查询。 2. 当前优先保障主流程稳定性其次覆盖异常场景和边界条件。 3. 测试环境已经提供用户服务、商品服务、订单服务和支付模拟服务。 【用户要求】 1. 测试用例要按业务链路分层不要只罗列接口。 2. 优先覆盖高风险场景例如库存不足、重复下单、支付回调重复通知。 3. 输出内容要能直接给测试团队评审和落地执行。 4. 自动化脚本要考虑数据隔离、环境清理和接口依赖关系。 【已确认结论】 1. 下单主流程必须作为 P0 级用例优先覆盖。 2. 支付回调需要重点验证幂等性。 3. 库存扣减和订单状态流转属于高风险校验点。 4. 自动化执行前需要准备独立测试账号和测试商品数据。 【已否定方向】 1. 不要只测接口返回 200。 2. 不要把所有场景都堆在一个大用例里。 3. 不要依赖线上真实支付渠道。这样即使原始对话被压缩后续 Agent 仍然知道当前任务在做什么。滚动摘要的优点是优点说明适合长任务能保留关键上下文降低 token 压力历史内容被压缩减少注意力稀释无关细节被清理保留任务状态适合项目规划、测试方案设计、代码分析但它也有代价第一摘要需要额外模型调用会增加成本和延迟。 第二摘要质量会直接影响后续效果。 第三如果摘要总结错了后续模型会基于错误记忆继续推理。 第四摘要经过多轮压缩后可能出现信息损失和偏差累积。所以滚动摘要最好不要只生成一段自然语言而要尽量结构化。推荐摘要格式- 当前任务 - 业务背景 - 用户要求 - 关键约束 - 已确认结论 - 已否定方案 - 当前进度 - 后续待办这比一段泛泛而谈的总结更适合工程落地。六、短期记忆不只是聊天记录还包括任务状态很多人理解短期记忆时只想到多轮对话。但在 Agent 系统里短期记忆还包括任务状态。比如一个代码生成 Agent当前任务可能包含已读取哪些文件已修改哪些文件哪些测试已经运行哪些错误还没解决用户是否确认过某个方案当前执行到了哪个步骤下一步应该执行什么这类状态如果只靠自然语言对话保存很容易丢。更工程化的做法是把短期记忆拆成几类类型内容存储方式对话上下文用户和 Agent 的多轮交流messages任务状态当前目标、步骤、结果、约束state / JSON / Redis工具观察结果工具调用返回的信息tool observation临时计划当前任务拆解和执行路径plan / scratchpad例如{ task_goal: 设计电商下单链路接口自动化测试方案, business_flow: [ 登录, 商品查询, 加入购物车, 提交订单, 支付回调, 订单状态查询 ], risk_points: [ 库存不足, 重复下单, 支付回调重复通知, 订单状态流转异常, 优惠券核销失败 ], confirmed_points: [ 主流程作为 P0 用例优先覆盖, 支付回调必须验证幂等性, 自动化脚本必须考虑测试数据隔离 ], rejected_points: [ 不要只校验接口返回 200, 不要依赖线上真实支付渠道, 不要把所有场景堆到一个大用例里 ], next_action: 输出接口自动化测试方案评审稿 }这类结构化状态比自然语言更稳定也更方便程序读取。所以面试时可以补一句对复杂任务型 Agent 来说短期记忆不能只依赖聊天历史还要有结构化 task state用来保存当前任务目标、执行进度、工具结果和关键约束。这句话会比单纯讲“最近 N 轮对话”更工程化。七、长期记忆不是保存聊天记录而是构建可复用记忆资产短期记忆解决当前会话长期记忆解决跨会话。比如一个测试负责人多次要求我们团队设计自动化测试方案时优先按业务风险分层不要只按接口数量堆用例核心链路必须先保障稳定性再考虑低频边界场景。如果这是一个长期稳定的团队测试规范就值得写入长期记忆。下次用户再让 Agent 设计测试方案时Agent 不需要重新询问就能自动按照“业务风险优先、核心链路优先、用例可落地”的方式来组织方案。但长期记忆不是简单保存完整聊天记录。更准确的流程应该是这里要注意一点向量库是长期记忆的常见实现但不是唯一实现。不同类型的记忆适合不同存储方式。记忆类型示例推荐存储方式用户偏好测试方案优先按风险分层Profile / KV / 关系型数据库历史对话片段某次讨论过的接口测试细节向量数据库项目事实系统技术栈、接口范围、测试环境关系型数据库 / 文档库业务关系用户、订单、支付、库存之间的依赖关系图数据库长期任务文档测试计划、复盘报告、质量规范文件系统 / 文档库可复用经验某类故障对应的测试补强策略向量库 元数据所以长期记忆不是“把聊天记录向量化”这么简单。更好的做法是先抽取高价值记忆再根据记忆类型选择合适的存储方式。八、长期记忆到底应该存什么长期记忆最大的坑就是“什么都存”。如果把所有聊天记录、临时讨论、一次性任务细节全部写进去记忆库很快会变成垃圾场。真正值得长期保存的信息一般有四类。类型示例是否适合长期保存长期稳定偏好团队要求测试方案按业务风险分层适合任务核心目标团队正在建设接口自动化测试体系适合已确认事实订单系统采用支付 Mock 服务做回调测试适合可复用结论支付回调必须重点验证幂等性适合临时上下文今天下午临时评审某个测试用例不一定一次性草稿某次临时测试报告修改通常不适合敏感信息密码、Token、生产账号、隐私数据默认不应保存一个简单的准入判断可以这样设计def should_write_memory(info): if info.is_sensitive: returnFalse if info.is_temporary: returnFalse if info.confidence 0.8: returnFalse if info.type in [ long_term_preference, stable_fact, reusable_conclusion, project_goal ]: returnTrue returnFalse比如下面这条就比较适合写入长期记忆{ memory_type: team_testing_preference, content: 该测试团队设计自动化测试方案时优先按业务风险和核心链路分层而不是简单按接口数量堆用例。, source: conversation, created_at: 2026-06-27, confidence: 0.92 }面试里可以这样回答长期记忆不应该默认写入所有历史而应该通过记忆准入策略筛选只保存稳定、明确、可复用、低风险的信息。对于临时信息、低置信度信息、敏感信息默认不写入或者需要用户明确确认。这句话非常关键。因为它能体现你不是只会堆向量库而是考虑了真实系统里的数据质量和风险控制。九、长期记忆检索不能只讲 TopK很多人讲长期记忆会说用户提问后向量检索 TopK再塞回 Prompt。这个答案只能算入门。真实工程里长期记忆检索至少要考虑六个问题。1、相似度不等于相关性用户问帮我设计订单接口自动化测试方案。系统可能会召回很多历史接口文档、旧测试用例、缺陷记录。但真正有价值的不一定是所有历史材料本身而是和当前任务直接相关的测试规范、核心链路、历史高频缺陷和团队约定。例如系统可以召回团队要求测试方案优先按业务风险分层核心链路必须优先覆盖登录、下单、支付、订单状态流转支付回调需要重点验证幂等性自动化脚本必须考虑测试数据隔离和环境清理输出方案要能直接进入测试评审而不是停留在概念设计所以记忆需要分类preference团队偏好fact事实信息project项目背景decision历史决策constraint限制条件summary历史摘要检索时可以按类型加权score semantic_score * 0.6 type_weight * 0.2 recency_score * 0.1 confidence_score * 0.12、旧记忆可能已经过期比如早期记忆里记录的是下单接口只需要校验订单创建成功。后来团队在故障复盘中更新了要求下单接口除了校验订单创建成功还必须校验库存扣减、优惠券核销、订单状态流转和消息通知是否一致。如果长期记忆不更新Agent 后续仍然只生成“订单创建成功”的基础用例就会漏掉真正高风险的校验点。所以记忆需要版本、时间戳和状态{ content: 订单接口自动化测试需要同时校验订单创建、库存扣减、优惠券核销、订单状态流转和消息通知一致性。, status: active, created_at: 2026-06-27, replaces: [memory_1024] }3、记忆之间可能冲突例如旧记忆团队接口自动化只要求覆盖主流程新记忆团队现在要求主流程、异常流程、幂等场景和数据一致性一起覆盖系统不能简单都保留。更合理的方式是标记旧记忆失效或者把它限定到历史项目中避免后续生成测试方案时继续按旧标准输出。可以采用三种策略冲突类型处理方式新信息明确覆盖旧信息标记旧记忆失效新旧信息适用场景不同按场景拆分置信度不足让用户确认4、记忆需要权限过滤企业场景尤其要注意。比如一个企业 Agent 同时服务多个部门A 项目的测试策略不能被 B 项目随意召回管理层的复盘结论不能被普通成员看到用户个人偏好不能污染团队公共知识生产环境账号、Token、密钥不能进入长期记忆所以长期记忆检索前必须先做权限过滤。5、召回太多会污染上下文长期记忆不是越多越好。召回太多会导致Prompt 变长模型注意力分散无关历史干扰当前任务旧信息覆盖新信息更合理的流程是6、召回结果要可解释尤其是企业场景最好能知道这条记忆来自哪里什么时候写入为什么被召回当前是否仍然有效是否经过用户确认否则一旦 Agent 基于错误记忆做出错误判断很难排查问题。十、记忆治理长期记忆系统能不能跑稳关键看这里长期记忆不是一次写入就结束了。它更像一类动态数据资产需要持续治理。否则系统运行一段时间后会出现几个问题重复记忆越来越多过期信息没有清理测试规范相互冲突临时信息被错误保存召回结果越来越不准敏感信息带来安全风险所以一个成熟的记忆系统至少要设计四类策略。1、Write Policy什么内容可以写入写入前要判断是否长期稳定是否未来可复用是否已经明确确认是否涉及敏感信息是否已经存在相似记忆简单来说不是所有内容都值得成为长期记忆。比如下面这些内容可以考虑写入团队长期采用的测试分层规范项目的核心业务链路反复出现的高风险缺陷类型已确认的自动化环境约束稳定复用的测试数据准备方式但下面这些内容不建议默认写入一次性临时讨论未确认的猜测生产账号和密钥临时测试数据已经过期的接口文档结论2、Read Policy什么场景可以读取读取长期记忆时要判断当前问题是否需要历史记忆记忆是否和当前任务相关用户是否有权限访问记忆是否仍然有效召回数量是否会污染上下文比如用户只是问一个通用技术问题不一定需要读取团队历史记忆。但用户说按我们团队之前的规范帮我设计订单接口自动化测试方案。这就明显需要召回长期记忆。3、Update Policy新旧记忆冲突怎么办长期记忆必须支持更新。常见策略包括新记忆覆盖旧记忆按场景拆分记忆降低旧记忆权重标记旧记忆 inactive让用户确认冲突项例如{ old_memory: 订单接口自动化只需要覆盖下单成功主流程, new_memory: 订单接口自动化需要同时覆盖主流程、库存不足、重复提交、支付回调幂等和订单状态一致性, action: 标记旧记忆为过期新测试方案统一按高风险场景分层设计 }这样就不会粗暴地互相覆盖。4、Delete Policy什么内容应该删除长期记忆必须支持删除和清理。包括用户主动要求删除临时记忆过期低置信度记忆长期不用重复记忆合并后删除旧项敏感信息误存后立即清除尤其是用户可控非常重要。用户应该可以查看记忆修改记忆删除记忆关闭某类记忆清空全部记忆这不是产品细节而是生产级 Agent 的基本能力。面试里可以这样说长期记忆不是越多越好而是越干净越好。记忆系统要有准入、更新、清理、合并、删除机制否则后期检索质量会持续下降甚至让 Agent 产生错误个性化。十一、短期记忆和长期记忆怎么配合短期记忆和长期记忆不是互相替代而是分工协作。维度短期记忆长期记忆作用范围当前会话跨会话、跨任务保存内容最近上下文、任务状态、工具结果稳定偏好、重要事实、历史结论典型技术窗口截断、滚动摘要、状态缓存Profile、向量库、数据库、文档库生命周期会话级长期持续核心风险截断导致失忆脏数据导致错误召回设计重点控制 Prompt 长度控制记忆质量一个比较合理的上下文组装顺序是System Prompt ↓ 角色与安全约束 ↓ 相关长期记忆 ↓ 当前任务状态 ↓ 短期摘要 ↓ 最近几轮对话 ↓ 用户最新问题为什么长期记忆不建议随便放太多因为长期记忆一旦放入上下文就会影响模型判断。所以要遵循一个原则宁可少放几条高置信度记忆也不要塞一堆模糊相关的历史内容。十二、面试官可能继续追问什么追问 1长期记忆和 RAG 有什么区别可以这样回答RAG 通常面向外部知识库比如文档、规范、FAQ、代码库。 长期记忆更偏用户维度和交互历史比如团队偏好、历史决策、任务背景。两者技术上都可能用 Embedding 和向量数据库但数据来源和使用目标不同。对比项RAG 知识库长期记忆数据来源文档、网页、知识库对话、行为、用户反馈目标补充外部知识保持个性化和连续性更新方式批量导入、定期同步持续写入、动态更新核心风险文档过期、召回不准记忆污染、隐私风险一句话RAG 解决 Agent 知不知道长期记忆解决 Agent 记不记得当前用户、团队和任务背景。追问 2为什么不能把所有历史对话都放进 Prompt因为会带来三个问题。第一成本高。 Prompt 越长推理成本越高。第二效果不稳定。 长上下文会引入噪声模型注意力容易被稀释。第三有风险。 过期信息、敏感信息、无关信息都可能影响模型输出。所以正确做法不是全量塞上下文而是短期内容摘要压缩长期内容按需召回。追问 3如何判断一条记忆是否值得保存可以从四个维度判断维度判断问题稳定性这个信息未来还会成立吗复用性后续任务会多次用到吗置信度这个信息是否明确、已确认安全性是否涉及隐私或敏感信息只有同时满足“稳定、可复用、高置信、低风险”才适合写入长期记忆。追问 4记忆召回不准怎么办可以从六个方向优化记忆切片不要太碎也不要太长记忆要带类型、时间、来源、置信度检索前做权限过滤检索后做 rerank召回结果要去重对冲突记忆做版本管理追问 5长期记忆如何防止越用越脏核心是记忆治理写入前做准入判断写入时做结构化检索时做过滤和重排定期做合并和清理用户可以查看和删除敏感信息默认不保存这也是区分“Demo Agent”和“生产级 Agent”的关键点。十三、一个生产级记忆系统可以这样设计如果让我设计一个企业级 Agent 记忆系统我会拆成下面几层每层职责如下层级设计重点Session Memory保存当前会话最近上下文和滚动摘要Task State保存结构化任务状态避免任务断片Memory Retriever按当前问题召回相关长期记忆Context Builder控制放入 Prompt 的内容和顺序Memory Writer判断哪些信息值得长期保存Memory Governance清理、合并、更新、删除、审计User Control允许用户管理自己的长期记忆这套设计的核心思想是短期记忆负责“当前任务不断片”长期记忆负责“历史经验可复用”记忆治理负责“系统越用越干净”。十四、面试回答可以这样收尾如果面试官问Agent 的记忆系统怎么设计你可以这样回答在工程落地里我会把 Agent 记忆拆成短期记忆和长期记忆两层。短期记忆服务当前会话主要解决上下文连续性和 Prompt 长度控制。简单场景可以用最近 N 轮对话或 token 窗口截断复杂长任务可以用滚动摘要把早期对话压缩成结构化摘要同时保留最近几轮原始对话。如果是任务型 Agent还要把当前目标、已完成步骤、已确认约束、工具调用结果做成结构化 task state而不是完全依赖自然语言聊天记录。长期记忆服务跨会话场景通常会把用户偏好、重要事实、历史决策、可复用结论抽取成记忆片段。存储方式不一定只有向量库也可以结合用户画像、关系型数据库、文档库、图数据库等。用户新提问时系统先根据当前问题召回相关记忆再结合类型、时间、置信度、权限做过滤和重排最后只把少量高价值记忆放回上下文。但我不会默认把所有对话都写入长期记忆。长期记忆必须有准入条件只保存稳定、明确、可复用、低风险的信息。对于临时信息、敏感信息、低置信度信息默认不写入或者需要用户确认。另外长期记忆还需要治理机制包括过期清理、重复合并、冲突更新、用户查看和删除权限。否则记忆库越用越脏反而会影响 Agent 的输出质量。所以我理解的 Agent 记忆系统不只是保存历史记录而是一套围绕上下文生命周期设计的工程能力。短期记忆保证当前对话不断片长期记忆保证跨会话可复用记忆治理保证系统长期稳定。十五、最后总结Agent 的记忆系统不是一个可有可无的功能。它决定了 Agent 能不能从“一次性问答工具”变成真正能长期协作的智能助手。短期记忆解决的是这一轮对话里Agent 不能忘。长期记忆解决的是下一次再见面Agent 还记得关键背景。记忆治理解决的是Agent 不能什么都记更不能记错、记脏、记过期。很多 Agent Demo 看起来很惊艳但真正进入业务场景后很快会卡在记忆系统上。因为真实用户不会每次都从头解释背景真实任务也不会永远停留在单轮问答。尤其在测试开发场景里一个 Agent 如果记不住业务链路、测试约束、历史缺陷和团队规范就很难真正参与测试方案设计、用例生成、自动化脚本规划和质量复盘。能把短期记忆、长期记忆和记忆治理讲清楚基本就说明你已经不只是会用 Agent 框架而是开始理解 Agent 系统工程了。我是 霍格沃兹测试开发学社持续分享优质 Agent 开发面试题和工程落地经验。