Agent的记忆怎么设计？上下文窗口满了怎么办？

# 上下文组装：按优先级装填，超预算就降级
def build_context(task, budget=60_000):
    parts = [system_prompt(), task.goal]                 # 必须保留
    parts += task.state.summary()                         # 任务状态摘要（计划/进度）
    parts += retrieve_memory(task.user, task.goal, k=5)    # 长期记忆按需检索
    recent = task.history[-6:]                            # 最近几轮保留原文
    older = task.history[:-6]
    if older:
        parts.append(summarize(older))                    # 早期对话滚动摘要
    for msg in recent:
        if msg.is_tool_result and tokens(msg) > 2_000:
            ref = offload_to_file(msg)                    # 大结果外置
            msg = f"[结果已保存到 {ref}，摘要：{preview(msg)}]"
        parts.append(msg)
    assert tokens(parts) <= budget, "仍超预算则继续压缩摘要"
    return parts

这里有一个经常被追问的点：为什么不直接用超长上下文模型，把所有东西都放进去？ 答案是三个字：贵、慢、乱。成本和延迟随 Token 线性甚至更快增长；而且研究和实践都发现，信息放在长上下文的中间位置时，模型利用它的效果会变差。

展开三：长期记忆的数据模型

长期记忆千万不要只存一堆向量。我会把它设计成一张有结构的表，向量只是其中一个检索字段：

-- 长期记忆表：每条记忆可追溯、可更新、可失效
CREATE TABLE agent_memory (
  memory_id     STRING,      -- 主键
  user_id       STRING,      -- 归属用户（权限隔离）
  memory_type   STRING,      -- preference / fact / experience
  subject_key   STRING,      -- 主题键，如 'report.timezone'，用于冲突覆盖
  content       STRING,      -- 记忆内容
  embedding     ARRAY<FLOAT>,-- 语义检索用
  source        STRING,      -- 来源：哪次会话、哪条消息
  confidence    DOUBLE,      -- 置信度：用户明确说的 > 模型推断的
  valid_from    TIMESTAMP,
  valid_to      TIMESTAMP,   -- 失效时间，NULL 表示当前有效
  last_used_at  TIMESTAMP    -- 用于冷数据淘汰
);

这个设计借鉴了数仓里的拉链表思路：用户说“以后报表都按北京时间”，过了一个月又说“改成按 UTC”，不能两条都留着让模型自己猜，而是用 subject_key 找到旧记忆，把它的 valid_to 置为当前时间，再插入新记忆。检索时只取有效记忆。

记忆写入：不是什么都值得记

类型	举例	要不要记	原因
明确的长期偏好	“周报都按 UTC 时区出”	要	稳定、可复用、用户明确表达
稳定的事实	“我负责广告归因这块数据”	要	影响后续回答方式
一次性的任务细节	“这次只看上周的数据”	不要进长期记忆	只在当前任务有效
模型自己的推断	“用户可能是新人”	谨慎，低置信度	容易形成偏见，且难以纠正
敏感信息	身份证号、密码、薪资	不要	合规风险，必须过滤

典型场景：Agent 记住了过期口径

想象一个问数 Agent：某次对话里业务方说“GMV 不含退款”，Agent 把这句话写进了长期记忆。三个月后公司统一口径，GMV 改为含退款，指标平台已经更新，但 Agent 的长期记忆里还躺着旧说法，于是它每次都优先相信“记忆”，给出和看板对不上的数字。

这个问题的根因是：业务口径这种有权威来源的信息，不应该进 Agent 的个人记忆，而应该每次从指标平台实时读取。记忆只存“用户偏好”和“个人上下文”，组织级的事实以权威系统为准。这个原则和数仓里“单一可信源（Single Source of Truth）”是一回事。

追问链

追问一：长任务跑到一半进程挂了，怎么恢复？

要把任务状态显式持久化，而不是只存在对话历史里。状态里包括：任务目标、计划步骤、每一步的完成情况和产出位置、关键中间结论。每完成一步就写一次，类似 Checkpoint。恢复时从状态表重建一个精简上下文，而不是把几百轮对话原样重放。

另外，有副作用的步骤（比如重跑任务、写表）要记录幂等键，恢复后不会重复执行。

追问二：滚动摘要会不会丢信息？怎么控制？

会，所以摘要要结构化而不是自由文本：固定包含目标、约束条件、已确认事实、已做决定、未解决问题这几项。对于用户明确给出的约束（比如“不要动生产表”），要单独提取出来放在一个不会被压缩的区域。另外原始对话要完整落库，摘要出问题时可以回溯。

追问三：多个用户共享一个 Agent，记忆怎么隔离？

长期记忆表必须带 user_id 或 tenant_id，检索时作为强制过滤条件，而不是检索完再过滤。团队级共享的知识（比如团队规范）单独存一份，和个人记忆分开，权限分开管理。这和多租户数仓的隔离思路完全一致。

加分说法 vs 减分说法

✔ 加分说法	✘ 减分说法
记忆分层：工作上下文 / 短期 / 任务状态 / 长期	上下文不够就换更长窗口的模型
大工具结果外置，上下文只放摘要和引用	长期记忆就是把对话存进向量库
长期记忆要有来源、置信度、有效期，像拉链表	满了就把前面的截断
组织级事实以权威系统为准，不进个人记忆	所有对话内容都记下来
长任务状态要像 Checkpoint 一样持久化	不考虑记忆过期和冲突

怎么挂到你的项目上

话术模板：“我会用数据工程的思路设计 Agent 记忆：上下文是内存，长期记忆是存储，中间要有加载、淘汰和失效机制。长期记忆我参考了拉链表的设计，每条记忆有主题键和有效期，新信息覆盖旧信息，而不是两条并存让模型去猜。”

这个回答的好处是：把你熟悉的数仓经验（缓存、拉链表、Checkpoint、单一可信源）自然迁移到 Agent 场景，面试官会觉得你的底子扎实。

总结

Agent 记忆本质是一个分层存储 + 缓存淘汰 + 数据版本管理问题。答题时先分层，再讲上下文压缩的四个手段，最后落到“长期记忆要可更新、可失效”。用拉链表、Checkpoint、单一可信源这些数据人熟悉的概念去类比，是数据开发答这道题最大的优势。

下一篇聊一个面试官很爱问的“关系题”：RAG 和 Agent 是什么关系？都有 Agent 了还需要 RAG 吗？

你用过的 AI 助手里，有没有被它“记错”坑过的经历？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长