AI Agent 面试题第二弹：Memory、RAG 检索、长上下文工程 13 题

老王这次换了副金丝眼镜，像极了某个互联网大厂的 CTO，眼神犀利但嘴角带笑，看起来今天心情不错。

老王翻了翻我的简历，“你这个 PaiCLI 写了三层记忆架构、RAG 向量检索、长上下文自适应，挺能吹的啊。”

（内心 OS：王哥你别说吹，这些我一行一行码出来的😤）

我说：“王哥，这几块确实是 PaiCLI 的核心。记忆系统做了三期，第 3 期做 Memory、第 4 期做 RAG 代码库理解、第 12 期做长上下文工程。最近还做了两个升级——长期记忆加了项目级隔离，代码检索从 RAG 一把梭改成了精确搜索优先、RAG 语义兜底。”

老王露出感兴趣的表情：“行，那就从记忆系统开始聊。”

content

01、Agent 的记忆系统分哪几层

老王问：“先说说整体架构，你们的记忆系统是怎么分层的？”

我说：“三层。短期记忆、长期记忆、外部记忆。”

短期记忆就是当前对话的消息历史——用户输入、模型回复、工具调用和结果，每一轮都在追加。生命周期是一次会话，关掉终端就没了。

长期记忆是跨会话持久的。

用户说“记一下这个项目用 Java 17”，Agent 就把这条事实写到本地 JSON 文件里。下次开新会话，Agent 从文件里检索和当前对话相关的条目，注入到上下文中。这样跨会话 Agent 也能“记住”用户的偏好和项目背景。

外部记忆就是通过检索访问的外部知识库，不在对话历史里常驻，需要的时候按需查。

PaiCLI 的外部记忆有两条路：

一条是精确搜索，按关键字或正则实时扫描项目文件树；
另一条是 RAG 向量语义检索，从预建的 Embedding 索引里找相关代码段。

Agent 优先走精确搜索，只有查询太模糊、关键词难确定的时候才走 RAG。

老王追问：“三层之间怎么协调？”

我说：“有一个统一的管理者负责协调。每轮请求模型之前，它会做三件事：从长期记忆里检索相关条目，从外部记忆拿到检索结果，然后把这些和短期记忆里的对话历史一起拼装成完整的 prompt 发给模型。三层各司其职，管理者负责‘调度’。”

02、短期记忆会溢出吗

老王问：“对话聊久了，短期记忆会不会撑爆上下文窗口？”

我说：“会。”

模型有上下文窗口限制，GLM-5.1 是 200k token，DeepSeek V4 是 1M。

看起来很大，但对话历史不管理的话，几十轮下来就可能满了。特别是工具调用的结果——读一个大文件可能就是好几千 token，命令行输出如果不截断也是灾难级别的。

PaiCLI 的做法是实时跟踪当前对话占用的 token 数。当占用接近窗口的 90%，自动触发摘要压缩。

老王追问：“压缩具体怎么做？”

我说：“第一套是 Memory 系统里的短期记忆压缩，用的是 Map-Reduce 摘要：旧消息先按片段生成摘要，再把多段摘要合并，最后把摘要写回短期记忆。”

“第二套是 conversationHistory 压缩，压的是 Agent 真正发给 LLM 的消息列表。它不是 Map-Reduce，而是在调用 LLM 前检查 token，达到阈值后，把 system 后面、最近 3 个 user 轮次之前的旧消息交给 LLM 总结成一段摘要，再重建消息列表。”

原始 history:
[system, user1, assistant1(tool_call), tool1, ..., user20, assistant20]

压缩后:
[system,
 user("[已压缩的历史对话摘要]\n" + summary),
 assistant("好的，我已了解之前的上下文，请继续。"),
 最近 3 个 user 轮次开始的尾部消息]

关键是分割点必须落在 user message 边界，不能切断 assistant tool_call 和 tool result 的配对关系。否则 OpenAI-compatible API 会发现 tool_call_id 找不到对应 tool 消息，轻则模型理解混乱，重则直接 400。