AI Agent 面试题深度解析（二）：Agent Memory 篇

核心答案#

短期记忆和长期记忆的区别，本质是”信息的生命周期和服务对象不同”。

短期记忆是当前任务执行期间必须保留的状态信息。它保存在 Agent 的运行上下文里，会随着任务结束而被清理或归档。短期记忆通常包括：当前任务的目标与子目标、已经执行过的步骤、工具调用的输入输出、中间结论、用户在本轮对话里的临时偏好等。短期记忆的特点是密集、临时、上下文敏感，它的存在是为了让 Agent 在一次任务里保持”知道自己在做什么”。

长期记忆是跨任务、跨会话沉淀下来的信息。它独立于具体任务，保存在持久化存储里，能被未来的 Agent 调用。长期记忆通常包括：用户画像与偏好、团队规则与项目约定、历史决策与经验教训、专业知识库、操作风格习惯等。长期记忆的特点是稀疏、持久、可被检索，它的存在是为了让 Agent 在面对新任务时”记得你是谁、过去怎么做的”。

两者最关键的差异在五个维度：

第一，作用范围。短期记忆服务于当前任务，长期记忆服务于 Agent 整体。

第二，存储位置。短期记忆在 State 对象和上下文窗口里，长期记忆在外部存储（数据库、向量库、文件系统、Git 仓库）。

第三，读写频率。短期记忆读写极频繁，贯穿整个 Loop；长期记忆写入稀疏，读取按需检索。

第四，生命周期。短期记忆随任务结束清理；长期记忆需要过期、压缩、归档等治理机制。

第五，质量要求。短期记忆只要不影响当前任务即可；长期记忆一旦写入错误会持续影响未来所有任务，所以对准确性、可审计性的要求高得多。

面试时还有一个常见追问：“工作记忆是不是第三种？” 严格说，工作记忆是短期记忆里更细的子集——它指的是”在多步任务中临时存在、但比单步状态更结构化”的内容，比如 Planner 已经规划好的步骤表、Reflection 模式里的自评历史。它仍然是短期记忆的一部分，只是需要单独设计存取方式。

关键要点#

• 短期记忆服务当前任务，长期记忆服务 Agent 整体。
• 两者在存储、生命周期、质量要求上完全不同。
• 长期记忆的治理（写入控制、过期、冲突处理）才是记忆系统的难点。

容易踩的坑#

• 把短期记忆和长期记忆混为一谈，统称”记忆”。
• 没区分两者的存储位置和生命周期。
• 误以为”长期记忆”就是把聊天记录存起来。

示范话术#

短期记忆和长期记忆的区别，我会从五个维度讲：作用范围——短期记忆服务当前任务，长期记忆服务 Agent 整体；存储位置——短期记忆在 State 和上下文窗口，长期记忆在外部存储；读写频率——短期读写密集，长期写入稀疏、按需读取；生命周期——短期随任务结束清理，长期需要治理；质量要求——短期只要不影响当前任务就行，长期写入错了会持续污染未来所有任务，所以更看重准确性和可审计性。讲这一题我特别想强调，长期记忆的治理才是难点——什么时候写入、什么时候过期、冲突怎么处理——这些比”有没有记忆”重要得多。

核心答案#

一个生产可用的记忆系统要解决的问题，可以总结成八个：写入控制、读取策略、压缩机制、过期机制、冲突处理、安全隔离、可观测性、跨 Agent/跨会话共享。

写入控制解决”什么信息允许进入记忆”。不是所有信息都该被记下来——闲聊、临时指令、敏感数据都不该自动写入。写入控制通常包含来源校验、敏感信息过滤、置信度评估、写入策略分级。

读取策略解决”什么时机召回哪些记忆”。读取不是全量注入，而是按当前任务检索相关记忆。读取策略的关键是召回质量、相关性排序、上下文窗口预算控制。

压缩机制解决”信息量超过窗口时怎么办”。短期记忆膨胀会迅速吃掉上下文窗口，所以需要定期做摘要、结构化、抽取关键事实。压缩不是简单截断，而是要保留关键决策、关键参数、关键状态。

过期机制解决”过时的记忆如何处理”。用户偏好可能改变、项目可能结束、规则可能更新，过期机制通过时间戳、TTL、人工审核来决定哪些记忆该下线。

冲突处理解决”新旧记忆矛盾怎么办”。比如同一用户过去喜欢 A，现在喜欢 B；同一条规则在 v1 和 v2 里定义不同。冲突处理需要版本号、优先级、人工介入策略。

安全隔离解决”谁能读写哪些记忆”。用户级、团队级、项目级记忆需要隔离，避免 A 用户的偏好污染 B 用户的体验，也避免团队 A 的规则泄漏到团队 B。

可观测性解决”记忆系统怎么排查问题”。需要记录每次写入的来源、时间、置信度；记录每次读取的召回命中和排序依据；记录压缩、过期、冲突的处理日志。

跨 Agent 共享解决”多 Agent 协作时如何共享上下文”。可以走共享 State、共享 Memory Store，也可以走消息传递。共享机制要避免重复存储和版本错乱。

把这八个问题答出来，面试官通常就会觉得你对记忆系统的工程复杂度有真实认知。

关键要点#

• 记忆系统不是”存起来”那么简单，而是要解决”写什么、怎么读、怎么压、怎么过期、冲突怎么办”。
• 安全隔离和可观测性是生产级系统逃不掉的话题。
• 跨 Agent 共享是 Multi-Agent 系统特有的难点。

容易踩的坑#

• 把”记忆”讲成”数据库”或”聊天记录存档”。
• 只讲写入不讲治理（过期、冲突、压缩）。
• 忽略安全隔离和可观测性。

示范话术#

我会把记忆系统的问题拆成八块：写入控制、读取策略、压缩机制、过期机制、冲突处理、安全隔离、可观测性、跨 Agent 共享。写入控制解决”什么允许记”，读取策略解决”什么时候召回什么”，压缩机制解决”窗口快满了怎么办”，过期机制解决”过时记忆怎么清理”，冲突处理解决”新旧记忆打架”，安全隔离解决”谁能看哪些”，可观测性解决”出问题怎么排查”，跨 Agent 共享解决”多 Agent 时怎么共用”。我特别想强调：记忆系统的难度不在”存”，而在”治理”。很多团队把记忆系统做成一个 Vector Store 就觉得完事了，真正上线后被各种过期、冲突、污染问题打脸。

核心答案#

向量记忆和 Markdown 记忆是两种最常见的长期记忆实现方式，它们的设计哲学、适用场景和工程开销完全不同。

向量记忆把信息编码成高维向量，存进向量数据库，召回时按相似度检索。它的核心优势是语义检索——用户问”我之前喜欢什么颜色”，即使记忆原文是”用户偏好极简风格，常用黑白色调”，也能被检索到。这种”意思相近就能命中”的能力，让向量记忆非常适合事实、经验、案例、参考资料这类语义密度高、结构化程度低的信息。

Markdown 记忆把信息以人类可读的结构化文本形式保存，比如 YAML front matter + Markdown body。它的核心优势是可读、可审、可版本管理——可以直接打开看、写、复制粘贴，团队成员不需要懂向量数据库就能读懂、修改、Review。Markdown 记忆非常适合规则、偏好、约束、流程、约定这类需要高保真、需要审计、需要团队共识的信息。

两者的选择可以按三个维度判断：

第一，信息是否需要语义检索。需要——向量；不需要但需要精确匹配——Markdown。

第二，信息是否需要人审。需要——Markdown；不需要——向量。

第三，信息是否高频更新且需要版本管理。需要——Markdown（可以走 Git）；不需要——向量。

生产里两者经常组合使用。比如团队约定走 Markdown 记忆，存进 Git 仓库，CI 流水线里同步到向量索引；个人偏好走向量记忆，按相似度检索；项目事实、代码片段走向量；操作规范、流程约束走 Markdown。

关键要点#

• 向量记忆擅长语义检索，Markdown 记忆擅长可读可审。
• 选哪种方式，要看信息”需不需要被检索”和”需不需要被人读”。
• 真实项目里两者经常组合使用。

容易踩的坑#

• 把所有信息都塞进向量库，忽视可读性和可审性。
• 把规则类信息也写成 Markdown 但又不走版本管理，规则变更无法回滚。
• 没意识到”语义检索”和”精确匹配”是两种能力。

示范话术#

向量记忆和 Markdown 记忆我会按三问来选。需要语义检索吗？需要——向量；不需要——Markdown。需要人审吗？需要——Markdown；不需要——向量。需要版本管理和回滚吗？需要——Markdown，可以走 Git。落到具体场景：经验、事实、参考资料走向量；规则、偏好、流程、约束走 Markdown。真实项目里我经常组合用——团队约定走 Markdown 存 Git，CI 同步到向量索引；个人偏好和经验走纯向量。讲这一题我会特别强调一点：把规则类信息塞进向量库是个常见错误，规则需要可读可审，依赖相似度检索非常危险——你不会希望”安全策略”是靠相似度匹配上的。

核心答案#

Auto Memory 是一种让 Agent 在完成任务后自动判断哪些信息值得写入长期记忆的机制。它的工作方式通常是：在任务关键节点或结束后，让 LLM 充当”记忆策展人”，从任务轨迹里抽取值得长期保留的事实、偏好、规则，然后写入记忆系统。

Auto Memory 的价值在于降低用户和工程团队的手工负担。如果每次都让用户主动说”记住这个”，那记忆系统几乎不会被使用；但如果完全不自动，记忆又难以积累。所以 Auto Memory 是真实记忆系统的标配。

但 Auto Memory 不能无限自动写入，原因有五个：

第一，质量不可控。LLM 抽取的”值得记住”和真正值得记住之间有偏差。闲聊、临时指令、过期信息、敏感数据都可能被误写入。错误信息一旦进入长期记忆，会持续影响未来所有任务。

第二，数量爆炸。每次任务都自动写入，长期记忆会迅速膨胀，检索质量反而下降（信号噪声比降低），并且消耗存储和检索成本。

第三，污染风险。恶意输入或 Prompt 注入可能让 Agent 把错误信息写入长期记忆，影响后续所有任务。这是安全层面的重大隐患。

第四，冲突难以发现。自动写入的记忆容易和已有记忆冲突，没有人工把关的话，冲突处理逻辑会非常复杂。

第五，敏感信息泄露。自动写入的信息可能包含不该持久化的内容，比如 API Key、用户隐私、内部机密。

所以生产级 Auto Memory 通常要配四个机制：写入门槛（什么级别的信息才允许写入，比如”用户明确偏好”才能写入，临时信息不能）、置信度评估（写入时记录来源和置信度，低置信度的标记待审核）、人工 Review 通道（重要类目需要人工确认才能正式生效）、可回滚机制（写错的记忆可以撤销）。

关键要点#

• Auto Memory 是真实记忆系统的标配，但必须有”刹车”。
• 写入门槛、置信度评估、人工 Review、可回滚是四个必备机制。
• 无限自动写入会让记忆系统从资产变成负债。

容易踩的坑#

• 把 Auto Memory 想得太美好，忽略质量、数量、安全问题。
• 没有写入门槛，Agent 什么信息都往记忆里塞。
• 没有 Review 通道，让错误信息污染长期记忆。

示范话术#

Auto Memory 是真实系统里必备的能力——如果每次都要用户主动说”记住这个”，记忆系统基本不会被用上。但 Auto Memory 不能无限自动写入，原因是质量不可控、数量会爆炸、可能写入 Prompt 注入的恶意信息、冲突难以发现、还可能泄漏敏感信息。所以我设计 Auto Memory 一定会配四件事：写入门槛、置信度评估、人工 Review 通道、可回滚机制。比如我会把记忆分成”自动可写""待 Review""禁止写入”三档：用户明确偏好的事实可以自动写，临时信息标记待 Review，敏感数据、API Key、Prompt 注入相关的内容直接禁写。讲这一题我会强调一点：记忆系统一旦污染，影响的是未来所有任务，所以 Auto Memory 的”刹车”比”油门”更重要。

核心答案#

团队共享记忆走 Git 和 Code Review，本质上是把”记忆”当作”代码”来管理——用代码领域成熟的工程实践解决记忆治理的难题。

走 Git 的好处有四个：

第一，可审计。每次记忆变更都有 diff、author、commit message，可以追溯”谁在什么时候改了什么、为什么改”。

第二，可回滚。写错的记忆直接 revert 即可，不会因为数据存储缺乏版本管理而无法恢复。

第三，可分支和合并。不同团队可以基于自己的分支维护记忆，再通过 PR 合并到主干，解决”个人偏好 vs 团队共识”的冲突。

第四，可触发 CI 流程。记忆变更可以触发校验、构建、同步到向量库、推送到生产环境，整个流程可以自动化。

Code Review 的好处也有四个：

第一，质量把关。让团队成员在合并前对记忆内容做审核，避免错误信息、低质量信息混入。

第二，共识形成。Review 过程本身就是团队对”哪些是必须遵守的规则”形成共识的过程，比管理员单方面修改更容易被接受。

第三，知识传播。Review 过程让团队成员互相了解”现在沉淀了哪些规则”，避免重复探索。

第四，责任明确。Reviewer 签字的记忆意味着团队为它背书，使用时可以更放心。

需要注意的是，不是所有记忆都适合走 Git。团队级、跨项目、规则类、需要高保真和审计的记忆适合；个人级、临时性、频率极高的记忆反而会增加 Review 负担。常见做法是：把记忆分成多个文件——CLAUDE.md 走团队核心规则、AGENTS.md 走 Agent 配置、领域子目录走模块规则，PR 时按敏感度分级 Review。

关键要点#

• 团队记忆用 Git + Code Review，本质是复用代码工程实践。
• 可审计、可回滚、可分支、可触发 CI 是 Git 的四个核心价值。
• 记忆分层管理，避免所有变更都走 Review 通道。

容易踩的坑#

• 把所有记忆都走 Git，导致 Review 负担过重。
• 没有给记忆做分层，规则类和个人偏好混在一起。
• 不写 commit message，事后无法追溯变更原因。

示范话术#

团队共享记忆走 Git 和 Code Review，本质是把记忆当代码管——复用代码工程里已经成熟的实践。具体来说，Git 提供四件事：可审计，每次变更都有 diff 和 author；可回滚，写错了 revert 即可；可分支，个人偏好和团队规则可以分开演进；可触发 CI，记忆变更可以自动同步到向量库或推生产。Code Review 提供四件事：质量把关、共识形成、知识传播、责任明确。但不是所有记忆都适合走 Git，我会做分层——团队核心规则走 CLAUDE.md，模块规则走子目录，个人偏好和临时记忆不进 Git，只走纯向量。讲这一题我会强调：记忆分层比记忆存储更重要，全塞进 Git 反而让 Review 变成负担。

核心答案#

记忆压缩、过期、冲突是记忆治理的三个核心问题，处理它们的思路分别如下。

记忆压缩解决”信息量超过窗口或存储上限”。处理方式有三种：

第一，摘要压缩。把长文本浓缩成关键事实，比如把一段对话压成”用户希望报告用 Markdown 格式，篇幅控制在 500 字以内”。摘要可以用 LLM 自动生成，但要保留关键参数、关键决策、关键结论。

第二，结构化压缩。把非结构化文本转成结构化字段，比如把”用户上次说他们公司是做 SaaS 的，主要服务零售客户”压成 {industry: "SaaS", customer_segment: "零售"}。结构化存储更省空间也更易检索。

第三，分层压缩。把记忆分成”原始记忆、摘要记忆、关键事实”三层，按需召回最相关的一层。原始层只在最必要时调入上下文。

记忆过期解决”过时信息需要清理”。处理方式有四种：

第一，TTL 过期。每条记忆带过期时间，到期自动下线。适合用户偏好这类可能变化的信息。

第二，访问频率过期。长期不被访问的记忆被降级或清理。适合”曾经重要但现在不常用”的信息。

第三，显式失效。用户或管理员明确标记”这条记忆不再有效”，立即下线。

第四，基于事件的过期。当某事件发生时（如项目结束、规则更新），相关记忆批量过期。

记忆冲突解决”新旧记忆矛盾”。处理方式有四种：

第一，时间优先。新记忆覆盖旧记忆。简单粗暴，但可能丢失有价值的历史。

第二，置信度优先。带高置信度（来源更可靠、Review 过）的记忆覆盖低置信度。

第三，优先级分层。按”用户明确偏好 > 推断偏好 > 默认行为”分层，高优先级覆盖低优先级。

第四，人工介入。重要冲突标记出来让人决定，模型不擅自动手。

实际工程里，这三种治理通常组合使用——压缩按层做、过期按事件触发、冲突按置信度排序后再人工兜底。

关键要点#

• 压缩、过期、冲突是记忆治理的三大难题。
• 没有任何单一机制能解决全部问题，必须组合使用。
• 冲突处理尤其要避免”让模型自己挑”，重要决策需要人工介入。

容易踩的坑#

• 把压缩做成”截断”，丢失关键信息。
• 过期策略一刀切（比如统一 30 天过期），不符合实际。
• 冲突时让模型自动覆盖，丢失审计和可解释性。

示范话术#

记忆压缩、过期、冲突我会分开讲。压缩有三种思路：摘要压缩把长对话压成关键事实；结构化压缩把非结构化文本压成字段；分层压缩按”原始—摘要—事实”分层召回。过期有四种：TTL 过期、访问频率过期、显式失效、基于事件的过期。我会按信息类型选——用户偏好走 TTL，参考资料走访问频率，规则类走显式失效，项目级记忆走事件触发。冲突有四种处理：时间优先、置信度优先、优先级分层、人工介入。我会组合用——日常用置信度排序兜底，重要冲突标记出来让人决定。讲这一题我会强调：冲突处理绝不能让模型”自己挑”，记忆治理的可解释性比智能化更重要。

核心答案#

长期记忆污染上下文是 Agent 系统的常见问题——长期记忆里的低质量、过期、错误信息被召回，挤占了上下文窗口的宝贵预算，还可能误导模型产生错误输出。避免污染需要从”读取端”和”写入端”两侧同时治理。

写入端的治理是源头控制。具体做法有四种：

第一，写入门槛。把记忆按敏感度分级，只有”高质量”信息才能进库，比如用户明确偏好、Review 过的规则、置信度高的经验。闲聊、临时指令、敏感数据直接禁写。

第二，置信度标注。每条记忆写入时记录来源、置信度、Review 状态。低置信度记忆标记为”待审”，不直接进入主检索路径。

第三，定期 Review。建立定期审计机制，让团队成员或用户清理过期、错误、重复的记忆。

第四，可回滚。发现污染后能快速回滚，不让错误记忆持续影响 Agent。

读取端的治理是流量控制。具体做法有五种：

第一，按需检索。不是把所有长期记忆都塞进上下文，而是按当前任务做语义检索，只召回相关的若干条。

第二，相关性排序。召回后按相关性、置信度、时效性综合排序，截断低质量内容。

第三，预算控制。给记忆分配固定的 Token 预算，召回内容总长超过预算就压缩或截断。

第四，过期过滤。读取时过滤掉已过期或被标记失效的记忆。

第五，冲突屏蔽。读取时检测新召回的内容是否和已有强相关记忆冲突，冲突的内容不进上下文，而是标记让用户处理。

机制端还要做可观测性。每次召回都要记录”召回了什么、为什么召回、用没用上”，事后回查时能定位污染源。

关键要点#

• 长期记忆污染要从写入端和读取端两侧同时治理。
• 写入端靠门槛、置信度、Review、回滚，读取端靠按需检索、排序、预算、过滤。
• 可观测性是治理闭环的关键。

容易踩的坑#

• 只在写入端把关，忽略读取时的质量控制。
• 召回时不过滤过期和低置信度内容，让垃圾信息进上下文。
• 没有可观测性，污染后无法定位来源。

示范话术#

长期记忆污染上下文，我会从两端同时治理。写入端做源头控制：写入门槛、置信度标注、定期 Review、可回滚——比如我把记忆分成”自动可写""待 Review""禁写”三档，低质量信息和敏感数据根本进不了库。读取端做流量控制：按需检索、相关性排序、Token 预算、过期过滤、冲突屏蔽——召回时不只是按相似度排，还要按置信度、时效性综合排，超预算就压缩或截断，冲突的内容不进上下文而标记出来让人处理。最后还要做可观测性，每次召回都记日志，事后能反查”为什么污染了”。讲这一题我会强调：记忆污染是 Agent 上线后最容易翻车的问题之一，必须在系统设计阶段就把治理机制建好，不能等出问题再补。

核心答案#

这道题是记忆篇的”总结题”——面试官问”你的 Agent 有记忆吗”，朴素回答”有，我把历史聊天记录都存下来了”会立刻被判定为”没真做过”。正确的回答方式是把”记忆”讲成”系统”，而不是”功能”。

可以从五个角度把”记忆”和”聊天记录”区分开：

第一，目的不同。聊天记录是”还原发生过什么”，记忆是”支持未来决策”。聊天记录只服务于”回看”，记忆服务于”影响 Agent 后续行为”。

第二，结构不同。聊天记录是按时间排列的对话流，记忆是按用途分层的结构化数据——有用户偏好、规则、事实、状态、经验等不同类型，每种类型有不同的存储和读取方式。

第三，治理不同。聊天记录只要存下来就行，记忆需要写入控制、读取策略、压缩、过期、冲突处理、Review、可回滚等治理机制。

第四，召回不同。聊天记录只能按时间或关键词检索，记忆可以按语义、置信度、时效性、相关性综合检索。

第五，质量要求不同。聊天记录可以”事无巨细都记”，记忆必须”有所选择地记”，因为错误记忆的影响是负向的。

讲”有记忆”时，建议用一句对比来收尾：聊天记录是”我发生过什么”，记忆是”我要成为什么”。前者是数据，后者是能力。能把这两者区分开，面试官立刻就能看出你对 Agent 记忆系统的理解深度。

关键要点#

• 记忆是系统，不是功能。
• 区分”聊天记录”和”记忆”的关键是目的、治理、召回、质量四个维度。
• 用一句对比句收尾，能让回答更有冲击力。

容易踩的坑#

• 把”我们把历史都存下来了”当成有记忆。
• 没说明记忆的结构和分层。
• 没讲治理和召回策略。

示范话术#

面试里被问”你的 Agent 有记忆吗”，我从来不会说”我把聊天记录都存了”——那不是记忆，那是日志。我会从五个维度把”记忆”和”聊天记录”区分开：目的——聊天记录是还原发生过什么，记忆是支持未来决策；结构——聊天记录是时间序列，记忆是按用途分层的结构化数据；治理——聊天记录只管存，记忆要做写入控制、读取策略、压缩、过期、冲突处理；召回——聊天记录只能按时间或关键词，记忆可以按语义、置信度、时效性综合检索；质量——聊天记录可以事无巨细，记忆必须有所选择，因为错误记忆影响的是负向的。我经常用一句话收尾：聊天记录是”我发生过什么”，记忆是”我要成为什么”。能把这两件事讲清楚，面试官基本就能判定你确实做过 Agent 记忆系统。