Cross-Session Memory: Explicit Memory, Automatic Memory, and Three Criteria for Retrieval Injection

Interview questions

• What problem does an agent's memory solve, versus conversation history and project instruction files?Agent 的记忆和会话历史、项目指令文件分别解决什么问题？

  Common in ChinaCommon overseasBasic#agent-memory#context-design

  How to reason about it · think before answering

  1. This tests whether you have actually built a memory system. Saying memory lets it remember things is empty — all three let it remember things. The signal is an operational classification rule, not three separate definitions.
  2. How to break it down: give the one-line split first — one stores facts, one stores process, one states rules. Memory holds facts that still hold across sessions (which command this repo's tests need); the session event log holds the process of this particular run, used for resume and fork; the project instruction file holds the rules, is committed, and applies to everyone. Their lifecycles differ completely: memory is long-lived but expires, a log is one per session and append-only, instruction files travel with the code.
  3. The more interesting difference is how each is consumed. Instruction files go into the system prompt in full every round, so they need a hard budget and truncation. The session log is replayed only on resume. Memory is the only one of the three that is retrieved by relevance and injected a few entries at a time — because it grows forever and most of it is irrelevant to the sentence in front of you. That retrievability is the essential difference.
  4. Then offer three tests to show you can actually sort things: will this still be true next time (if not it is process, and belongs in the log); is this learned or mandated (mandated goes in the instruction file, learned goes in memory); could you learn it by reading the code once (if so it is not worth remembering — memory should hold traps you hit, verbal conventions, approaches you tried that failed, and user preferences).
  5. Be concrete about the cost of mixing them. Put process in memory and three days later the model carries a long-dead now into the context without being able to say when that now was. Put learned guesses into the instruction file and an unreviewed assumption starts governing the whole team. Conversely, keep a real rule only in local memory and it vanishes on the next machine.
  6. Likely follow-up: should the memory directory be committed? My answer is no — it may contain things that should not be shared, and more fundamentally a fact that can influence everyone without review is dangerous. Experience worth sharing should be moved into the instruction file by a human and go through code review. Implementations differ here, so the point is articulating the tradeoff rather than reciting one product's behavior.

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

  1. 这题在考「你有没有真做过一个记忆系统」。答「记忆让它记住东西」是空话——三样东西都让它记住东西。区分度在于你能不能给出一条可操作的分类判据，而不是三段各自的定义。
  2. 怎么拆：先给一句话的分工——**一个记事实，一个记过程，一个是规定。** 记忆存的是跨会话还成立的事实（这个仓库的测试得用哪条命令）；会话事件日志存的是这一次干活的过程，用来恢复与分叉；项目指令文件存的是规矩，进版本库、对所有人生效。它们的生命周期完全不同：记忆长期保留但会过期，日志一条会话一份且只追加不改写，指令文件跟着代码走。
  3. 更值得说的是**用法不同**：指令文件每一轮全量进系统提示（所以它有硬预算，一超就得截断）；会话日志只在恢复的时候整段重放；记忆是三者里唯一**按相关性检索、只注入几条**的——因为它会一直长，而它绝大多数条目和眼前这句话无关。**能不能按需检索，才是记忆和另两者最本质的差别。**
  4. 然后给三条判据证明你分得清：①「这句话下次还成立吗」不成立的是过程，归日志（「刚才那次测试是红的」不该进记忆）；②「这是学到的还是规定的」规定的进指令文件，学到的进记忆；③「读一次代码能知道吗」能知道的不必记——记忆该存的是踩过的坑、口头约定、试过但不行的做法、用户的偏好。
  5. 混在一起的代价要具体：把过程写进记忆，三天后模型带着一条早就不成立的「现在」进上下文，而它自己说不清那是什么时候的现在；把学到的东西写进指令文件，等于让一条没人评审的猜测对全组生效；反过来把规矩只记在本机记忆里，换台机器就没了。
  6. 可预期的追问：记忆目录该不该进版本库？我的答案是不该——它可能含有不该共享的东西，而更根本的是**一条没经过评审就能影响所有人的「事实」很危险**。值得全组共享的经验应该被人手动搬进指令文件、走一次代码评审。（这一条各家实现不一样，重点是能说出取舍，而不是背某个产品的行为。）

  Key points

  • One line: memory holds facts, the session log holds process, instruction files state rules
  • The essential difference is consumption: only memory is retrieved by relevance a few entries at a time
  • Three sorting tests: still true next time / learned or mandated / knowable by reading the code once
  • Concrete cost of mixing: process in memory carries a stale now; guesses in instruction files skip review
  • Memory is not committed: an unreviewed fact that governs everyone is dangerous; promote it to instructions

  答题要点

  • 一句话分工：记忆记事实、会话日志记过程、指令文件是规定
  • 最本质的差别是用法：只有记忆按相关性检索、只注入几条；另两者一个全量进提示、一个整段重放
  • 三条分类判据：下次还成立吗 / 学到的还是规定的 / 读一次代码能知道吗
  • 混起来的具体代价：过程进记忆会带着过期的「现在」；猜测进指令文件会没评审就影响全组
  • 记忆不进版本库：没经过评审就能影响所有人的事实很危险，要共享就搬进指令文件
• How do you retrieve memories so that only the relevant ones get injected, and how would you define relevance?记忆怎么检索才能只注入相关的？相关性判据你会怎么定？

  Common in ChinaCommon overseasIntermediate#memory-retrieval#context-injection

  How to reason about it · think before answering

  1. The easy answer is put it in a vector store and do semantic search. That is not wrong, but it moves the problem: a vector store solves ranking, while the hard parts here are how much you inject after ranking and how the user finds out what was injected. Those two are the signal.
  2. How to break it down: set the default first — the default is not to inject, not to inject everything. Fully injecting a directory of three hundred entries turns memory into a second system prompt, and two hundred ninety of them are unrelated to this sentence; they not only waste budget, they pull the model off course. So anything scoring zero gets in at all: prefer missing one over blurring everything. That sentence is the first dividing line.
  3. Then give the criteria, ordered by reliability. I use three: path hits (the file named in this sentence is exactly the file a memory is attached to — highest weight, because paths are exact and do not collide the way words do), keyword hits (score per hit, but with a mandatory cap), and source weighting (on a tie, what the user wrote by hand beats what the model sedimented). The third is not because humans are always right; it is accountability — the user remembers and can delete his own entry, while nobody owns the model's.
  4. The keyword cap is the second dividing line, because you only learn it by getting burned: without it, a memory with many keywords beats a memory with an exact path hit just by colliding on seven or eight words. That is not relevance, it is keyword stuffing — and the stuffing comes either from your fallback extractor (Chinese has no spaces, so without a tokenizer you slice adjacent character pairs and one sentence yields a dozen) or from the model itself, which will cheerfully hand you twelve keywords.
  5. You need both limits: a count limit against blur and a character limit against budget. The count should be counterintuitively small — two or three — because injected value falls with each extra entry while interference rises. How much of the total budget this lane deserves is a separate question about overall context allocation; this layer only needs to report how many characters and roughly how many tokens it took.
  6. The real deep end: hit reasons must be shown to the user and must not be sent to the model. Memory is the only context the user never mentioned that still shapes this answer — when it is wrong, the symptom is the model inexplicably insisting on something untrue, and the user has nothing to inspect. Printing this entry scored N because of path A and keyword B turns guessing into looking. The model does not need the scores; those are for a human decision. And when nothing matches, print a line saying so — it proves that not injecting was a decision, not a broken feature.
  7. Likely follow-up: when should you move to vector retrieval? Once you have thousands of entries and the user's phrasing often misses the memory's wording — synonyms, cross-language. But settle two things first: an embedding model is a new external dependency and a new cost, and semantic similarity is a continuous value, so you still have to pick your own threshold and count limit. Neither limit here goes away; only the ranking layer changes implementation.

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

  1. 这题最容易答成「上向量库做语义检索」。那不是错，但它把问题换了个地方放：向量库解决的是「怎么排序」，而这题真正的难点是**排完之后注入多少、以及注入之后用户怎么知道注了什么**。区分度就在这两处。
  2. 怎么拆：先立默认值——**默认是不注入，不是全注入。** 一个记了三百条的目录全量注入等于把记忆变成第二份系统提示，而其中两百九十条和这句话无关；它们不只浪费额度，还会把模型带偏。所以打分为零的一条都不进，**宁可漏也不要糊**。这一句是这题的第一个分水岭。
  3. 然后给判据，并按可靠性排序。我用三个：**路径命中**（这句话里提到的文件正好是某条记忆挂着的文件，权重最高——路径是精确的，不像词那样撞车）、**关键词命中**（命中几个算几分，但**必须有上限**）、**来源加权**（同分时用户亲手写下的压过模型自动沉淀的）。第三条的理由不是「人一定对」，是责任：用户写的那条他自己记得、能自己删，模型沉淀的那条没人认领。
  4. 关键词上限那条是第二个分水岭，因为它是只有踩过才知道的：**少了它，一条关键词写得多的记忆只要撞上七八个词就能压过一条路径精确命中的记忆。** 那不叫相关，那叫关键词堆砌——而堆砌它的既可能是兜底的抽词器（中文没有空格，不引分词表就只能切相邻两字组合，一句话能切出十几个），也可能是模型自己：让它给关键词，它会很热心地给十二个。
  5. 两个上限都要有：**条数管「别糊」，字符管「别把额度吃光」**。条数要小得反直觉（一次两三条），因为注入的价值随条数递减而干扰随条数递增。至于这一路总共该占多少额度，那属于上下文总预算的分配，是另一个题目；这一层只需要报出「我占了多少字符、约多少 token」。
  6. 最后是这题真正的深水区：**命中原因必须打给用户看，而且不发给模型。** 记忆是唯一一种「用户没提、却影响了这一轮回答」的上下文——它错了的表现是「模型莫名其妙地坚持一件不成立的事」，而用户手里没有任何东西可查。打出「这条命中几分、因为路径 A 与关键词 B」，问题就从猜变成看一眼。至于模型，它不需要知道分数，那是给人做决策用的。**而且一条都没命中的时候也要打一行「没命中」**：它证明「没注入」是判断的结果，不是功能坏了。
  7. 可预期的追问：什么时候该上向量检索？条目上千、且用户的说法和记忆的措辞经常对不上（同义词、跨语言）的时候。但换之前先想清楚两件事：嵌入模型是新的外部依赖与新的一笔成本，而且**语义相似度是个连续值，你仍然要自己定阈值与条数上限**——这题里的两个上限一个都省不掉，只有排序的那一层换了实现。

  Key points

  • Default to not injecting: anything scoring zero stays out; prefer missing one over blurring everything
  • Three criteria by reliability: exact path hits, keyword hits scored per hit, and source weighting
  • Keyword hits need a cap, or keyword stuffing outranks an exact path match
  • Both limits matter: count against blur, characters against budget; the count should be small
  • Show hit reasons to the user, not the model; print an explicit no-match line when nothing hits
  • Vector retrieval only replaces the ranking layer — the limits and the hit reporting still apply

  答题要点

  • 默认不注入：0 分的一条都不进上下文，宁可漏也不要糊
  • 三个判据按可靠性排：路径命中最硬、关键词命中按个数计分、来源加权（用户写下的压过模型沉淀的）
  • 关键词必须有命中上限，否则关键词堆砌能压过路径精确命中
  • 两个上限都要：条数管别糊、字符管别把额度吃光；条数要小得反直觉
  • 命中原因打给用户不发给模型；一条都没命中也要明确说「没命中」
  • 上向量检索只换掉排序那一层，两个上限与命中原因该打给谁一个都省不掉
• What must never go into long-term memory, and how do you detect that a memory has gone stale?哪些内容绝不该写进长期记忆？记忆过期了怎么发现？

  Common in ChinaCommon overseasDeep dive#memory-hygiene#secret-redaction

  How to reason about it · think before answering

  1. Two parts. The first is easy — everyone knows not to store secrets. The second is where the signal is: most implementations never handle memory going stale at all, and those that do often implement it as automatic deletion. Part one needs concrete implementation details to prove you built the gate; part two needs a verifiable mechanism.
  2. How to break part one down: three classes, and their natures differ completely, so the handling differs too. Secrets are a security problem: the memory directory is plaintext, resident, and sent to the model every round, so one remembered secret is copied into every request — gate it hardest. Transient conclusions are a classification problem: that test is red right now is process, not fact, and belongs in the session log; store it and three days later it carries a long-dead now into the context without being able to say when that now was. Things already written in the code are a budget problem: not wrong, just not worth it — something you learn by reading a file once occupies resident budget and is resent every round.
  3. The secret class has three details only a builder would mention. Gate by shape, not by variable name: in my key is sk plus a long string, the long string is the target, while credentials belong in environment variables, never hardcoded is a good memory. Never echo a single character of the blocked value in the rejection message — copying it into an error writes it into another log: terminal scrollback, the session log, CI output. And saying you cannot store this is not enough: that credential already appeared in this input, so tell the user to rotate it. Add an honest boundary too: blocking the write is not the whole job, since the tool-call card and approval prompt may still echo it, and stopping that needs a second redaction in the render layer.
  4. The other two classes share a property: they will produce false positives, so the rejection must offer a fix. This repo is still on CommonJS right now is actually a decent memory that merely carries a time word; tell the user to drop the time word and rewrite it and he will, whereas a flat refusal makes him abandon the feature. The already-in-the-code gate has a trickier knob: too small a minimum fragment length causes wide false positives (at four characters, tests must use node --test gets matched by test inside package.json), and you must only read a file when the sentence actually names it — full-repo search hits so often that the gate degrades into nothing may be remembered.
  5. All three gates belong in the write layer, not duplicated at each entry point. The explicit command and the model tool both funnel into one write function, because invariants belong to the data: miss one place and that place is the hole — and here the hole leaks secrets. The rejection reason is fed back to the model verbatim, and it corrects itself, replacing the secret with the name of the environment variable.
  6. Part two: give every memory a verifiable anchor. A memory saying tests need the built-in runner should be able to point at go look at package.json, that command is written there — and you check it before injecting. That yields three states: verified, so inject; anchor broken (file gone, or the string no longer present), so do not inject but list it in the terminal; no anchor, so fall back to age — lacking an anchor does not mean it expired, only that nobody can judge whether it did.
  7. The deep end has two counterintuitive rules. First, do not auto-delete on failure: a broken anchor does not mean the memory is wrong, perhaps the file was just renamed, and deletion is irreversible while the test is a single substring check. Second, not injecting must be announced: stay silent and the user assumes it is still in effect, so the next time the model is wrong he checks the directory and the memory is plainly still there — silent failure is harder to debug than failure. The same applies to deletion: report it when the id you were told to delete does not exist.
  8. Likely follow-up: what about memories with neither an anchor nor an expiry rule? Three fallbacks: always keep the write time and the source (when something goes wrong you need to know who wrote it), stamp written N days ago onto the injection, and provide one command that shows every memory with its verification status. Maintainability of a memory system lives on the can I see it and delete it side, not on the write side.

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

  1. 这题两问，前一问容易答（谁都知道别记密钥），后一问才是区分度所在——**「记忆会过期」这件事绝大多数实现根本没做，做了的也常常做成自动删。** 前一问要靠具体的实现细节证明你真做过闸，后一问要靠一条可核对的机制。
  2. 第一问怎么拆：三类，而且三类的**性质完全不同**，所以处理方式也不一样。① **密钥类，安全问题**：记忆目录是明文的、常驻的、每一轮都往模型发一遍，一条记住的密钥等于抄进了每一次请求，拦得最死。② **临时结论，分类问题**：「现在那个用例是红的」是过程不是事实，属于会话日志；写进记忆的后果是三天后它带着一条早就不成立的「现在」进上下文，而它自己说不清那是什么时候的现在。③ **代码里已经写着的事，预算问题**：这一类不是错的，是不值得——读一次文件就知道的事占着常驻额度每一轮重发。
  3. 密钥那一类有三个只有做过才说得出的细节：**按形状拦不按变量名拦**（「我的 key 是 sk 加一长串」里那个长串才是要拦的，而「凭据要放进环境变量不要写死」是条好记忆）；**拒绝话术里一个字的原文都不许回显**（把它抄进错误信息，等于把它写进了另一份日志——终端历史、会话日志、CI 输出）；**只说不能记是没尽到责任的**，那个凭据已经出现在这次输入里了，要提醒用户去轮换。再加一句诚实的边界：拦住写入不等于万事大吉，模型请求的工具卡片与审批提示可能还在回显它，真要挡住得在渲染层再脱敏一次。
  4. 后两类的共同点是**一定会误杀**，所以拒绝话术必须给出改法。「这个仓库现在还在用 CommonJS」其实是条不错的记忆，只是带了个时间词；告诉用户「去掉时间词重写一遍就能记」，他就会改，只说「不许记」他会直接放弃这个功能。而「代码里已经写着」这条闸的旋钮更刁：判断片段的长度下限给小了会大面积误杀（给四个字符，「测试只能用 node --test」会被 test 命中 package.json），而且**必须只在这句话点了某个文件名时才去读那个文件**——全仓库搜索的命中率高得离谱，那条闸会直接变成「什么都不许记」。
  5. 三类都要拦在**写入那一层**，不是在两个入口各写一遍。显式命令与模型工具都汇到同一个写入函数，理由是不变量属于数据：少写一处，那一处就是漏洞——而这里漏掉的是密钥。拒绝的理由则原样回灌给模型，它读了理由自己就会改（把密钥改成记住那个环境变量名）。
  6. 第二问：**给每条记忆一个可核对的锚点。** 一条记忆说「测试要用内置运行器」，那它就该能指出「去看 package.json，里面写着那条命令」；注入之前去核对一眼。于是有三种状态：核对通过就注入；锚点失效（文件没了、那段字不在了）**不注入，但要在终端列出来**；没有锚点的只能靠年龄提醒——没有锚点不代表它过期了，只代表没人能替你判断它过没过期。
  7. 最后是这题真正的深水区，两条都反直觉。一、**失效了不要自动删**：锚点失效不等于这条记忆错了，也可能只是文件改了名，而**自动删是不可逆的，判据却只是一次字符串包含检查**。二、**不注入必须说出来**：悄悄不注入的话，用户会以为它还在生效，下次模型答错时他去查记忆目录，那条记忆明明还在文件里——**静默失效比失效更难查。** 同一条道理适用于删除：删了个不存在的编号也要报出来。
  8. 可预期的追问：那没有锚点又没过期机制的记忆怎么办？靠三件事兜底——写下时间和来源永远保留（出问题时你要知道是谁写的）、注入时带上「写于多久之前」、以及一条能让用户一眼看完全部记忆与核对状态的命令。**记忆系统的可维护性不在写入侧，在「能不能看见并且删掉」这一侧。**

  Key points

  • Three classes, three natures: secrets are security, transient conclusions are classification, already-in-code is budget
  • Gate secrets by shape, never echo the value, and tell the user to rotate it; admit the render layer may still echo
  • The latter two will misfire, so rejections must offer a fix; keep both the length floor and the named-file-only rule
  • All three gates live in the single write function; the reason is fed back so the model corrects itself
  • Staleness needs a verifiable anchor: verified injects, broken does not inject but is listed, no anchor falls back to age
  • Never auto-delete on a broken anchor, and always announce a non-injection — silent failure is the harder bug

  答题要点

  • 三类各有不同性质：密钥是安全问题、临时结论是分类问题、代码里已有的是预算问题
  • 密钥按形状拦不按变量名拦；拒绝话术不回显原文，还要提醒轮换；并承认渲染层可能仍在回显
  • 后两类必然误杀，所以拒绝必须给出改法；「代码里已有」的长度下限与「只读被点名的文件」两条都不能省
  • 三类都拦在唯一的写入函数里，理由原样回灌给模型让它自己改
  • 过期靠锚点核对：通过则注入、失效则不注入但要列出来、没锚点的靠年龄提醒
  • 失效不自动删（不可逆，而判据只是一次包含检查）；不注入必须说出来，静默失效比失效更难查

Comments