跳到主内容Agent 短任务和长任务怎么记？工作记忆、长期记忆与任务状态怎样分层 · AlgoMooc面试题 · Agent 项目面试题
Agent 短任务和长任务怎么记？工作记忆、长期记忆与任务状态怎样分层
短任务可以将这些内容保存在内存或会话存储，并随着每轮模型调用重新组装上下文。任务结束后，很多中间内容可以删除，不需要进入长期记忆。
工作记忆最重要的能力不是“存”，而是“选”。历史越长，全部塞给模型会遇到上下文上限，也会让旧信息干扰当前判断。常见策略有滑动窗口、摘要和相关性召回。
滑动窗口保留最近几轮，简单但可能丢掉较早的重要约束。摘要把旧对话压成更短内容，保留主要事实，但摘要过程可能遗漏细节。相关性召回从较早历史中找与当前问题相关片段，但会增加检索和权限复杂度。实际可以组合：最近窗口保证连贯，结构化约束永远保留，较早历史按相关性补充。
工作记忆里什么必须始终保留
系统指令与安全规则；用户明确目标；不可违反的约束；当前步骤和完成条件；高风险操作的审批状态；关键失败与停止原因。
这些内容不能仅依赖摘要。摘要模型可能把“不允许发送外部消息”压成一句模糊描述，后续 Agent 就有越界风险。硬约束应放结构化 State，并由程序执行。
工具原始大结果也不应全部长期留在 Messages。网页、文件和日志放工件存储，工作记忆只保留相关摘要、来源、版本和可回读引用。需要细节时再按权限读取。
第二层：任务状态
任务状态面向同一次多步执行。长任务可能暂停、进程重启、等待人工或跨越多个服务，因此不能只依赖内存。
它需要保存任务 ID、图与状态版本、计划、当前步骤、已完成动作、工具凭证、错误、剩余预算、待处理事件和工件引用。Checkpoint 是任务状态的稳定快照，用于从一致位置恢复。
任务状态与工作记忆有重叠，但用途不同。工作记忆为下一次模型推理组装上下文；任务状态为执行系统判断“接下来该跑哪个节点、哪些动作不能重复”。任务状态可以生成工作记忆，不能反过来只靠自然语言上下文还原精确执行位置。
长任务还需要压缩。搜索得到的大量页面、模型草稿和中间日志不能都放入 State。把大对象外置，State 保存工件 ID、摘要、来源和校验信息。恢复时先验证引用和版本，再按当前步骤加载必要内容。
Checkpoint 和长期记忆有什么区别
Checkpoint 保存同一次运行的执行状态，目标是中断后继续。长期记忆保存未来任务可能复用的信息，目标是跨会话召回。
某次工具调用失败的完整堆栈可能需要进入 Checkpoint 和 Trace，帮助恢复与排障，但通常不值得变成用户长期记忆。用户稳定偏好可能进入长期记忆，却不代表它是当前任务已经完成的执行凭证。
Checkpoint 读取强调精确、完整和版本兼容；长期记忆读取强调相关性、时效、权限和冲突。把两者都放进一个向量库，会让精确恢复依赖概率检索，也会把大量运行噪音污染长期记忆。
任务变长后，不是简单保留更多聊天，而是把执行状态和大工件持久化。
第三层：长期记忆
长期记忆跨会话存在。它可以包含用户明确偏好、稳定身份信息、经过确认的事实、历史任务摘要和可复用经验。
长期记忆不能见什么存什么。每次对话都有寒暄、临时目标、错误猜测和敏感内容。全部写入会让记忆库快速变脏，也增加隐私风险。
写入
判断一条信息是否值得长期保存，记录来源、主体、时间、有效期、权限和置信状态。高敏感信息需要明确授权，有些内容根本不应保存。
检索
新任务先按用户、租户、时间和类型过滤，再做关键词或语义检索。召回结果不是事实真理，需要检查来源与当前任务相关性。
更新
用户偏好会变化，业务事实会过期。新信息应覆盖、并存或形成版本，不能只追加两个互相矛盾的句子。
冲突处理
实时业务系统、版本化知识库和历史记忆冲突时，按来源权威、时间和业务规则处理。无法解决就明确不确定，不让模型随意合并。
遗忘
按有效期、时间衰减、访问和价值删除或归档。遗忘不是能力退化，而是维持相关性、控制成本和落实隐私的重要机制。
长期记忆可以按内容再分
语义记忆
稳定事实和概念，例如已经确认的用户偏好或领域知识。它适合结构化存储与语义检索，但必须有来源和时效。
情景记忆
具体任务和经历摘要，例如上次研究了什么、使用了哪些来源、哪里失败。保留高价值摘要，不必永久保存完整轨迹。
程序记忆
完成任务的方法、工具使用模式或流程模板。它更像系统级经验，不应因为一次模型自评就自动写入。需要离线评估或人工确认，避免把偶然错误沉淀为规则。
用户画像
用户偏好、表达方式和长期目标。画像必须可查看、可修改、可删除，并与业务知识和系统策略分开。用户偏好不能覆盖安全规则。
记忆条目至少需要哪些字段
{
"memory_id": "...",
"subject": "user_or_task",
"type": "preference",
"content": "...",
"source": "explicit_user_statement",
"created_at": "...",
"valid_from": "...",
"expires_at": null,
"confidence": "confirmed",
"visibility": "tenant_private",
"supersedes": null
}
这是教学示例，用于说明来源、时效、权限与更新关系，不是生产 Schema。
只保存文本和向量，无法知道这是谁的记忆、从哪里来、是否过期、能否被当前任务使用。元数据过滤通常应该先于语义检索。
重要性分数也不能成为永久真理。模型给出的重要性需要校准，系统还要看用户明确授权、业务规则和后续使用价值。
短任务和长任务怎样选择不同策略
短任务输入明确、步骤少、不会跨进程时，最近窗口加结构化目标可能足够。不要为了“有 Memory”接入复杂向量库。
多轮但单会话任务需要指代消解、窗口、摘要和相关历史选择。目标是保持连贯，同时防止旧内容淹没当前问题。
长时间多步骤任务需要任务状态、Checkpoint、工件存储和恢复。它主要解决执行连续性，不等于长期用户记忆。
跨会话个性化或经验复用才需要长期记忆。先明确什么值得写、用户能否控制、怎样更新和忘记，再选向量库、关系库或图存储。
会话上下文、运行进度和跨会话知识的读取要求完全不同。
存储怎么选
最近会话和短期状态可以使用内存或键值存储，按会话 ID 快速读取并设置生命周期。结构化任务状态、消息索引、工具调用和审计适合关系型存储，支持版本、条件更新和精确查询。
长文档与大工件放对象存储，State 只保存引用。长期语义记忆可以使用向量检索，但通常需要关系型元数据过滤；实体关系复杂时才考虑图结构。
不要根据技术名词反推需求。向量库适合模糊相似检索，不适合单独承担权限、事务、唯一约束和精确执行状态。关系库也不是所有文本都塞一张表，工件、索引和审计可以各自分层。
记忆检索怎样避免污染当前决策
先用用户、租户、类型、时间和有效状态过滤，再计算相关性。召回条目带来源、时间与置信状态进入上下文，而不是只给模型一段脱离来源的文本。
限制记忆数量和总长度。相似条目去重，冲突条目成组呈现，让系统裁决。不要让一个很相似但已过期的偏好挤掉用户本轮明确要求。
优先级通常是当前用户明确指令和实时业务状态，高于历史记忆。系统安全规则不受用户记忆覆盖。具体排序按业务定义，不能让模型临场决定所有权威关系。
检索失败也要可见。系统没有找到相关记忆时，应按当前输入继续，而不是编造“你以前说过”。
写入长期记忆怎样防止错误积累
可以把候选记忆与正式记忆分开。模型从对话提取候选，再由规则或用户确认。明确偏好和用户主动要求记住的信息更容易写入；模型推断的性格、身份和敏感属性不应静默保存。
写入前做去重和冲突检查。新条目与旧条目相同则更新访问或来源，不必重复；相互冲突则建立版本或请求确认。
任务成功不代表所有中间结论都值得记。错误工具结果和临时假设必须排除。程序记忆更需要通过多样任务评估，不能一次成功就升级为全局策略。
一条长期记忆写入流水线
长期记忆最好不要在生成最终答案的同一个模型调用里直接落库。可以先提取候选，再经过分类、敏感检查、去重、冲突判断和授权，最后写入。
候选提取说明模型认为哪些内容可能值得保存；分类决定是偏好、事实、任务摘要还是经验；敏感检查拦截不应存储的身份、密钥和推断属性；去重与冲突判断读取已有记忆；明确需要用户同意的内容进入确认；写入后返回稳定记忆 ID、版本和来源。
这样做的好处是写错时能定位到具体阶段。若模型提取错，修提取与样本；若旧记忆没被找出，修去重与检索；若权限错误，修授权。所有问题都压在一个“save_memory”工具里，会让错误无法解释。
写入流水线也要有无写入出口。一次普通寒暄、临时要求或无法确认的推断，正确结果可能就是不保存。记忆系统不是每轮都必须产出新条目。
什么时候记忆会让 Agent 变差
召回了与当前任务相似但主体不同的记忆；旧偏好覆盖用户本轮明确要求；摘要把否定和条件丢掉；多个冲突条目同时进入上下文；工具错误被当作经验保存；过多记忆占满上下文。
这些失败说明评估不能只测“该想起时想起”。还要测不该想起时能否保持安静。为每组正向样本配难负例，例如两个用户问相似问题、同一用户偏好已经更新、历史任务名称相似但数据域不同。
记忆注入上下文时应使用清楚边界，标明这是历史信息、来源和时间，不把它包装成系统规则。模型需要知道历史可能过期，并优先服从本轮用户和实时工具结果。
如果检索置信度低或冲突未解，可以不注入，或先向用户确认。错误记忆的破坏往往大于少一条记忆带来的不便。
长任务结束后，哪些内容可以沉淀
任务状态不能整体转成长期记忆。结束时可以做一次收尾筛选：用户确认的偏好、最终稳定结论、可复用方法和失败边界可能有价值；完整工具轨迹、重复日志、临时计划和过期中间结果通常只进入审计或按期限删除。
若用户只要求本次完成，不代表允许跨会话保存。产品要提供明确记忆开关、查看与删除入口。任务数据的业务留存和个性化记忆的用户授权，也不应混为同一件事。
记忆索引怎样保持一致
长期记忆可能同时有关系记录、向量索引和缓存。更新或删除主记录后，索引未同步，旧内容仍可能被召回。
写入流程需要记录索引状态和版本。检索结果回到主存储再次检查有效、权限和最新版本，不能直接把向量库中的旧文本交给模型。删除时同步处理索引与缓存，失败进入重试和审计。
向量模型升级也会改变检索空间。新旧向量要区分版本，并用固定任务验证迁移结果。没有真实测试时，不能声称支持无损升级。
摘要会丢什么
摘要能压缩历史，但可能丢掉否定、数字、时间、责任人和失败边界。安全约束、批准状态和精确工具凭证不要只存在摘要中。
摘要应带覆盖范围、生成版本和来源引用，必要时能回读原始工件。新摘要生成后，使用回归任务检查关键事实是否保留。
摘要也会累积偏差。反复对摘要再摘要，错误会被固化。可以周期性从原始结构化事件重新生成，或只对稳定旧阶段做一次压缩。
隐私和删除是记忆系统的一部分
长期记忆越强，越需要最小收集、用途限制、租户隔离、访问控制、保留期限和用户删除。不能以“提升体验”为理由永久保存所有对话。
用户删除一条记忆时，还要处理向量索引、关系记录、对象工件和缓存。只删主表但索引仍可召回，不算真正删除。
共享多 Agent 记忆要更谨慎。一个 Agent 有权看到的信息，不代表所有 Agent 都能读。写入与检索都带主体和角色权限。
审计日志与长期记忆也不同。审计因合规保留，不一定允许注入模型上下文；长期记忆用于任务决策，更应严格控制内容质量。
怎样评估记忆系统
短期记忆评估多轮指代、约束保持、历史选择和摘要保真。准备窗口内、窗口外但相关、窗口外无关和相互冲突的对话。
任务状态评估进度精确、暂停恢复、已完成动作不重复、工件引用可用和版本兼容。它更像状态系统测试。
长期记忆评估写入是否必要、召回是否相关、过期和冲突是否被处理、用户修改是否生效、删除后是否无法再召回。
还要设置无记忆基线和错误记忆样本。系统不应为了证明 Memory 有价值，强制每个问题都召回历史。错误记忆进入上下文时，系统能否以当前事实纠正，也是关键。
所有指标从真实标注和日志计算。没有运行证据时，只给测试集、判定规则和失败案例设计，不虚构记忆准确率、延迟或 Token 节省。
记忆质量不只看“能否想起来”，还要看是否记对、用对、改得掉和忘得掉。
面试官会怎样连续追问
追问一：为什么不把全部 Messages 存向量库
向量库适合相关性检索，不适合精确任务进度、事务、权限和版本。全部历史还会把临时假设和噪音写成长期记忆。
追问二：Checkpoint 和长期记忆有什么不同
Checkpoint 服务同一次运行恢复，强调精确状态和版本；长期记忆服务未来任务复用，强调相关性、来源、时效、权限和遗忘。
追问三：短期记忆用窗口还是摘要
窗口简单但会丢远处信息，摘要保留更多语义但有成本和失真。通常保留结构化硬约束、最近窗口，再对旧历史摘要或相关性召回。
追问四：长期记忆什么时候写
只写跨会话仍有价值、来源明确、允许保存的稳定信息。模型提取候选，规则或用户确认；临时假设、敏感推断和错误结果不自动写。
追问五：新旧偏好冲突怎么办
保留来源和时间，按用户当前明确声明更新旧值，建立版本或 supersedes 关系。无法确认时请求用户，不让模型自行混合。
追问六：怎样证明 Memory 真有用
用同一多轮和跨会话任务对照无记忆、窗口、摘要与检索方案，同时检查正确召回、错误污染、成本和删除，不只展示一个“它被补全”的例子。
三层记忆架构，面试时这样回答
我会把 Agent 的记忆分三层。工作记忆服务当前推理，保存目标、硬约束、最近对话、计划和关键 Observation，用窗口、摘要和相关性选择进入上下文；任务状态服务同一次长任务，结构化保存步骤、工具凭证、工件引用、错误、Checkpoint 和待办，保证暂停恢复不会靠概率检索；长期记忆跨会话保存经过筛选的偏好、稳定事实和可复用经验，具备写入、检索、更新、冲突和遗忘生命周期。三层使用不同存储和权限，当前明确指令与实时业务状态高于历史记忆。评估分别覆盖多轮连贯、任务恢复和跨会话召回，也检查错误记忆、过期、删除和隐私。不是任务越长就把更多消息塞给模型，而是把上下文、执行状态和长期知识分开管理。
三层记忆是否落地：回答前逐项核对
- 是否能区分上下文、工作记忆、任务状态和长期记忆。
- 硬约束和执行凭证是否独立于摘要与向量检索。
- 长期记忆是否记录来源、时间、权限、版本和失效条件。
- 是否有更新、冲突、遗忘、用户查看和删除机制。
- 当前明确输入与实时事实是否优先于历史记忆。
- 没有真实评估时，是否只讲设计，不报召回、延迟和节省数字。
衡量记忆系统时，存储条数没有决定性意义。真正重要的是能否在正确时间把正确信息交给正确任务，并在信息过期、冲突或用户要求时及时修改和忘记。
