面试题库

30 天从前端工程师到 Agent 工程师

D12 长期记忆：pgvector、embedding、chunking、memory_search 工具

• 为什么 Agent 需要额外的长期记忆，而不是把历史全部塞进上下文？Why does an agent need a separate long-term memory instead of stuffing all history into the context window?

  国内高频海外高频基础#long-term-memory#rag#cost

  分析过程 · 先想清楚再作答

  1. 这题最容易答成「因为窗口装不下」。那只答对了一半，而且是不值钱的那一半——窗口一年比一年大，光靠这条理由，面试官会追问「等窗口到一百万 token 呢」，你就没词了。
  2. 先把两个问题拆开：上下文压缩解决的是「同一次会话里这一轮塞不下」，长期记忆解决的是「上个月说过的事想不起来」。前者在组装请求时做减法，后者做加法，触发时机、数据去向、失败后果都不同。能主动区分这两件事，是这题最大的区分度。
  3. 然后给成本账：200 条记忆、每条约 400 token 就是 8 万 token，按输入价 0.15 美元每百万 token 算，每一轮多付 0.012 美元；一天 20 轮就是 0.24 美元一个用户。只检索最相关的 5 条是 2000 token、每轮 0.0003 美元，差 40 倍。而且这笔钱是每轮重复付的，不是一次性的。
  4. 再给比钱更硬的理由：无关信息会降低命中率。200 条里跟这一轮相关的可能只有 1 条，剩下 199 条是噪声，模型会被带偏去回答一个用户没问的问题。**所以哪怕窗口无限大、token 免费，也该检索而不是全塞。** 这一句是这题的最优解。
  5. 落到做法上：把跨会话的用户事实与偏好抽成陈述句存进向量库，每轮按语义检索最相关的三五条注入请求——这就是 RAG 最小的一环。
  6. 可以预期的追问：什么信息该进长期记忆？答三问——跨会话之后还需要吗、会不会随时间失效、能不能靠检索捞回来。「用户住上海」三条都满足，「把刚才那段改成三句话」一条都不满足。

  How to reason about it · think before answering

  1. The tempting answer is 'the window is too small'. That is half right and it is the cheap half — windows keep growing, and the interviewer will ask what you would do at a million tokens.
  2. Separate the two problems first: context compression solves 'this turn does not fit in one session', long-term memory solves 'I cannot recall what was said last month'. One subtracts at request-assembly time, the other adds. Naming that distinction unprompted is where the signal is.
  3. Then quantify: 200 memories at roughly 400 tokens each is 80k tokens; at 0.15 USD per million input tokens that is 0.012 USD every single turn, about 0.24 USD per user per day at 20 turns. Retrieving the top 5 is 2k tokens, 0.0003 USD per turn — a 40x gap, and it repeats every turn.
  4. Give the reason that beats cost: irrelevant context lowers accuracy. If one of 200 memories is relevant, the other 199 are noise that pull the model toward answering something nobody asked. So even with an infinite free window, you would still retrieve rather than dump.
  5. Land on practice: distil cross-session user facts and preferences into standalone statements, store them as vectors, and inject the three to five most relevant per turn — the minimal form of RAG.
  6. Expect the follow-up: what belongs in long-term memory? Three tests — is it still needed across sessions, does it expire, can retrieval find it again. 'Lives in Shanghai' passes all three; 'shorten that paragraph' passes none.

  答题要点

  • 压缩管「这一轮塞不下」，长期记忆管「上个月说过的事想不起来」，是两个问题、两套机制
  • 全塞的成本是每轮重复付的：200 条约 8 万 token，每轮多 0.012 美元；检索 5 条只要 0.0003 美元
  • 更硬的理由是准确率：无关记忆是噪声，会把模型带偏，所以窗口再大也该检索而不是全塞
  • 做法是把跨会话的事实抽成陈述句、向量化存储，每轮按语义检索最相关的三五条注入
  • 判断一条信息该不该进长期记忆：跨会话还需要吗、会不会失效、能不能被检索到

  Key points

  • Compression handles 'this turn does not fit'; long-term memory handles 'what did they say last month' — different problems, different machinery
  • Dumping everything costs on every turn: 200 memories is about 80k tokens and 0.012 USD per turn versus 0.0003 USD for five retrieved ones
  • The stronger reason is accuracy — irrelevant memories are noise, so you would retrieve even with an infinite window
  • Practice: distil cross-session facts into statements, embed them, inject the top three to five per turn
  • Admission test for a memory: still needed across sessions, does not expire, and is findable by retrieval
• 把记忆检索包装成 memory_search 这样的工具时，参数设计上要注意什么？What matters when designing the parameters of a retrieval tool such as memory_search?

  国内高频海外高频深入#tool-design#security#long-term-memory

  分析过程 · 先想清楚再作答

  1. 这题看着是接口设计题，真正的区分度在安全。多数人会答 query 和 limit，答完就停；能不能说出「哪些参数绝对不能给模型」，决定了这题的分数。
  2. 先说 query：描述里要写清它不是用户原话，而是模型自己组织的检索语句，并给一个合法示例。用户问「我有什么忌口」，模型应该用「用户的食物忌口」去检索——这是从 D5 那条「格式类字段要给合法示例」延续下来的。
  3. 再说 limit：可选、默认 5、上限 10。上限的理由不是防呆，是上下文预算——一条记忆约 400 token，10 条就是 4000 token 进请求。模型传 50 时按工具协议回一条可读错误让它改，而不是静默截断成 10，否则模型永远不知道自己传错了。
  4. 然后是关键的一条：**绝不给 user_id 这类身份参数**。用户身份只能来自会话上下文。做成参数等于把「查谁的记忆」交给一段概率生成的文本，配上一句提示词注入就是现成的越权读取漏洞。一句话收尾：提示词管意图，代码管权限。
  5. 返回格式同样要说：空结果必须显式返回一句「没有找到相关记忆，请不要凭空推测」，返回空串模型会当成没有约束然后自己编；把相似度分数一起返回，模型才能区分「你说过」和「我印象里你好像提过」；设一条相似度下限，宁可不返回也不要拿噪声污染上下文。
  6. 可以预期的追问：检索不到的时候该怎么办？答案是分两层——工具层如实返回空并禁止推测，提示词层要求模型转而向用户确认，而不是把「没检索到」当成「用户没有偏好」。

  How to reason about it · think before answering

  1. It looks like an API design question; the discriminating part is security. Most candidates name query and limit and stop. Saying which parameters must never be exposed to the model is what earns the point.
  2. On query: the description must state that it is a retrieval phrase the model composes, not the user's literal words, and give a concrete example. Asked 'what are my dietary restrictions', the model should search for 'the user's food allergies and restrictions'.
  3. On limit: optional, default 5, capped at 10. The cap is a context budget, not idiot-proofing — a memory is roughly 400 tokens, so ten of them put 4000 tokens into the request. When the model asks for 50, return a readable validation error naming the field, the valid range and an example, rather than silently clamping, or it never learns it was wrong.
  4. The critical rule: never expose an identity parameter such as user_id. Identity comes from the session. Making it a parameter hands 'whose memories to read' to probabilistically generated text, and one prompt injection turns it into a privilege-escalation read. Prompts govern intent; code governs permission.
  5. Cover the response shape too: an empty result must say so explicitly and forbid guessing, because an empty string reads to the model as 'no constraints' and invites fabrication; return similarity scores so the model can distinguish a firm memory from a vague one; and set a minimum score, since no result beats a noisy one.
  6. Expect: what should happen on a miss? Two layers — the tool returns empty honestly and forbids speculation, and the prompt instructs the model to ask the user instead of treating 'not found' as 'no preference'.

  答题要点

  • query 必填，描述里说明它是模型组织的检索语句而非用户原话，并给一个合法示例
  • limit 可选、默认 5、上限 10，上限的依据是上下文预算；超限按工具协议回可读错误让模型改，不要静默截断
  • 绝不把 user_id 这类身份参数交给模型，身份只能来自会话——否则一句提示词注入就是越权读取
  • 空结果要显式说「没找到，请不要凭空推测」，返回空串模型会自己编
  • 返回相似度分数并设下限，宁可不返回也不要用低相关记忆污染上下文

  Key points

  • query is required; document it as a model-composed retrieval phrase, not the user's literal words, with an example
  • limit is optional, defaults to 5 and caps at 10 on context-budget grounds; over the cap, return a readable validation error instead of silently clamping
  • Never expose user_id or any identity parameter — identity comes from the session, or prompt injection becomes a privilege-escalation read
  • An empty result must say so explicitly and forbid speculation, or the model fabricates
  • Return similarity scores and enforce a minimum, since no result beats a noisy one