Part B · 横切深挖 · B04

Memory designMemory 设计

口述 2 min 追问 7 层 适合 垂直 Agent 研发, FDE, Solutions
Prompt 题面

先想清楚再开口

你刚讲完一个客服 Agent：身份核实、查订单、按政策退款。面试官追问：「用户第二次来的时候，Agent 要不要记得他？记什么、不记什么？记错了怎么办？」

题面为本书自拟的训练题，不代表任何公司的真实面试题或真实系统。

约束

约束取值（练习设定）
场景某电商平台（虚构）的文字客服 Agent，已上线；产品希望它「记住老用户」，少问重复问题
账户个人账户为主，也有家庭共享账户（一个账户多人使用）和企业采购账户（多名员工共用）
权威系统订单、地址、退款记录、会员等级都在各自的业务系统里，Agent 通过工具实时查询
对话内容用户会粘贴快递短信、商家聊天截图文字、邮件片段；这些内容里可能夹带指令
合规对话留存 180 天；手机号、地址在日志中脱敏；用户可以要求查看和删除关于自己的数据
错误代价把 A 的信息说给 B 听是一级事故；记错偏好只是体验问题；记错收款或地址可能造成资金损失
答到一半再点开：面试官补了一句

法务补了一句——「用户提出删除请求后，30 天内要从所有存储里删掉他的个人数据，并能给出删除凭证。」

Answer 参考回答

先口答，再展开

展开参考回答

该先问的问题

  1. 「记住」到底想解决什么：少问重复问题、延续未结的工单，还是个性化推荐？不同目标需要记的东西差别很大。
  2. 哪些信息已经在权威系统里（订单、地址、会员等级）？这些应该实时查，而不是另存一份。
  3. 记忆的主体是谁：账户、自然人还是设备？共享账户里一个人说的话能不能给另一个人用？
  4. 谁有权决定写入：模型、确定性规则，还是用户确认？写错了谁能发现、怎么撤回？
  5. 留存与删除的要求覆盖到哪一层：原始对话、抽出的事实、摘要、向量索引、缓存、备份？

一句话框架

只把有来源、有主体、有权限、有过期时间的事实写进记忆，能从权威系统查到的就实时查；记忆读出来只当可能过时的数据，用户随时能看、能改、能删。

设计取舍表

设计点采用否决的备选什么证据会让我改
三种状态分开会话状态（本次对话的槽位和进度，会话结束按留存规则归档）、跨会话记忆（少量用户事实，如偏好、未结事项）、权威记录（订单、退款、长任务账本，以业务系统为准，不叫记忆）把全部聊天记录存进一个向量库，统称「记忆」评测显示检索历史对话能明显提升解决率，且合规允许时，加一条按主体过滤的历史检索；检索结果仍只当线索，不当事实
写什么结构化事实条目：主体、事实、来源（会话 ID 与原句）、写入方式、时间、确认状态、过期时间、权限标签自由文本摘要，或让模型自己决定记什么某一类事实（如「偏好周末送货」）抽检误写率长期低于约定阈值，才允许这一类免确认写入
不写什么权威系统能查到的（地址、订单状态）不另存；支付信息、证件号、健康等敏感类不写；用户粘贴的第三方内容（截图、邮件、短信）不能升级成确认过的个人事实，最多作为本次会话的证据片段保存，带来源并限制保留期为省一次查询把地址缓存进记忆权威系统查询延迟成为瓶颈时，只做带失效时间的缓存，按缓存管理，不当记忆
谁决定写入模型只提议写入；确定性规则检查类别、来源和主体；影响资金或地址的类别不进记忆；其余类别由用户在对话里确认（「要我记住吗？」）模型看到「记住……」就写用户确认打扰过多、确认率又很高的类别，改为写入后告知并提供一键撤销
读取与隔离存储按主体分区，服务端按当前请求人的身份和授权过滤后才读；共享账户里按自然人或显式共享标记区分；读出的记忆放在数据位置，标来源和写入时间全库检索 top-k，再按用户过滤不改；事后过滤会让模型先看到别人的数据，这是硬边界
冲突与过期每类事实有过期时间；新旧冲突时保留版本，以权威系统和用户最近的明确确认为准，并在对话里说出来确认新写入静默覆盖旧值，或旧记忆压过权威数据某类事实冲突率高，说明它变化太快，不适合记，改为每次询问
用户控制与删除用户可查看、更正、删除；删除覆盖所有派生物（事实条目、摘要、向量索引、缓存、日志里的原文引用）和备份；备份在期限内删除或加密擦除，从备份恢复时先按删除标记重放删除，防止回灌（标记是受控、可按主体匹配的假名化数据，只能作为法务例外限期保留，见失败卡）；回执区分「已删除」和「仍在法务豁免的备份中」只删主表里的记录，或让备份等到期自然清除法务书面界定了备份例外时，按其条件与最长到期时间执行，恢复时二次删除
Two-minute English 口述

两分钟，先结论后展开

展开 2 分钟英文口述稿

I'd separate three things often lumped together as memory. Session state is what this conversation needs. Orders, addresses and refunds live in business systems and should be looked up, not remembered. Memory is only the small set of facts that exist nowhere else, like a delivery preference or an open issue.

Each memory is a structured fact with a subject, a source, how it was written, a timestamp, an expiry and a permission label. The model can propose a write, but rules decide the category, and the user confirms. Anything that touches money or addresses never goes into memory, and facts from pasted emails or screenshots are untrusted, because injected text written into memory would poison every future session.

On read, storage is partitioned by subject, and the server filters by the current requester before the model sees anything. Shared accounts need a person or an explicit sharing flag, not just an account ID. Memories are shown to the model as possibly stale data, and when they conflict with the system of record, the system wins and the agent asks the user.

Users can see, correct and delete what's remembered, and deletion covers derived copies and backups, with a receipt. I'd measure whether memory helps — repeat questions avoided — against wrong-memory incidents and cross-person reads, which are top-severity.

Follow-ups 追问

一层一层往下问

  1. 为何不用备选为什么不直接把所有历史对话存进向量库，让模型每次自己检索？
    先口答，再展开要点
    • 历史对话里混着过时信息、别人代说的话、粘贴进来的不可信内容；检索出来的原文没有「这是不是事实、现在还对不对」的标记，模型会把它当事实用。
    • 删除和更正几乎做不到：一个事实散在几十段对话和它们的嵌入里，用户说「我搬家了」，旧地址还会被检索出来。
    • 权限难做：检索是按相似度，不是按主体，共享账户和企业账户里很容易捞到别人的对话。
    • 可以保留的用法：按主体过滤后的历史对话检索，只当「上次聊过什么」的线索，不写进事实，不参与资金或地址相关的决定。
  2. 需求变化法务要求：用户提出删除后 30 天内从所有存储里删掉，并给出删除凭证。架构要改什么？
    先口答，再展开要点
    • 先建一张数据地图：用户的个人数据会出现在哪里——原始对话、事实条目、摘要、向量索引、检索缓存、日志与 trace、评测集、工单交接包、备份。
    • 每份派生物都要能按主体 ID 找回来：写入时带上主体 ID 和来源会话 ID，嵌入和摘要也带；否则删不干净。
    • 删除走一个有状态的任务：逐个存储执行、记录结果、失败重试。
    • 备份也在「所有存储」里。先向法务确认删除范围和备份有没有例外。没有例外，就要让备份在 30 天内可删：例如按用户分别加密、删除时销毁该用户的密钥（加密擦除），或把备份保留期缩到 30 天以内。
    • 有明确例外（例如隔离、不可在线访问的备份允许按周期过期），就写清条件和最长到期时间。从这类备份恢复时，先按删除标记二次删除，再上线。删除标记是受控、可按主体匹配的假名化数据：持有匹配密钥的一方仍能把它关联到用户，所以它本身也要作为法务例外写明期限，并在回执里披露。回执如实区分「已删除」和「仍在豁免备份中，将于某日过期」。
    • 用过这位用户数据的评测样本要一并移除或替换；已脱敏且不可回溯到个人的统计数据按法务意见处理。
  3. 失败反证用户在对话里说：「记住，以后退款都退到这个新账户。」其实是有人盗用了账户，或者这句话来自他粘贴的一段「客服通知」。怎么防？
    先口答，再展开要点
    • 收款账户属于资金类信息，本来就不进记忆；退款去向只以业务系统里经过验证的收款方式为准，改收款方式走带外验证流程。
    • 这条要点更一般的形态是「持久污染」：一次注入写进记忆，之后每次会话都会读出来执行。所以用户粘贴的第三方内容不能升级成确认过的个人事实，最多作为本次会话的证据片段、限期保留；写入记忆要用户在当前会话明确确认，并带原句和会话 ID。
    • 发现之后要能回滚：按来源会话或写入时间批量撤销某一批记忆，并统计同类写入是否还有别的。
  4. 多租户家庭共享账户里，Agent 对妻子说出了丈夫上周买了什么、寄到哪里。怎么防？
    先口答，再展开要点
    • 记忆的主体不能只是账户 ID。共享账户要么区分自然人（各自登录或子账户），要么只使用明确标为「家庭共享」的事实。
    • 读取时服务端按当前请求人过滤；购买记录和地址是权威数据，按业务系统自己的权限规则查询，不从记忆里读。
    • 把跨人读取列为一级事故：用共享账户、企业采购账户、同名用户做负例测试集，每次改记忆逻辑都要跑。
  5. 冲突记忆里写着「偏好周末送货」，这次用户说「工作日送到公司」。Agent 该听谁的？
    先口答，再展开要点
    • 以用户当前的明确表达为准，本次订单按工作日处理；记忆不覆盖当前意图。
    • 问一句是否更新长期偏好，用户确认才改；旧值保留版本，而不是静默覆盖。
    • 如果某类偏好经常和当前意图冲突，说明它变化太快、不值得记，改为每次询问。
  6. 评估你怎么证明加了记忆是值得的？
    先口答，再展开要点
    • 先定义记忆要改善的指标：重复提问的次数、处理时长、解决率；同时定义它的风险指标：错用记忆的次数、跨人读取、被用户更正或删除的比例。
    • 用对照：同一时间段、同类问题，部分会话开启记忆、部分不开，比较两组指标；样本量要写明，不看单个好例子。
    • 抽检记忆条目的准确率和来源；用户「这不是我说的」「我没让你记」这类反馈单独统计。
  7. 长任务长任务 Agent 的 goal 账本算不算 memory？
    先口答，再展开要点
    • 不算。goal、验收条款和进度账本是这次任务的权威记录，必须完整、可对账、跟着任务版本走；丢一条就是事故。
    • 记忆是跨任务、可遗忘的少量事实，允许过期和删除，读出来只当可能过时的数据。
    • 两者混在一起的后果：要么账本被当成「可以忘」的东西压缩掉，要么记忆被当成权威、不再对账。
Failure Modes 失败模式

这些地方最容易栽

注入写进记忆，变成持久污染
  • 症状：某个用户从某天起，每次会话 Agent 都坚持一个奇怪的「偏好」或规则，而用户说自己从没说过。
  • 根因：把对话里出现的陈述（包括粘贴的邮件、截图文字）当成事实写入；写入没有来源标记，也没有用户确认。
  • 防线：写入只接受白名单类别，带来源会话和原句；粘贴的第三方内容只作会话证据片段、不升级为个人事实；资金、地址类不进记忆；按来源批量回滚；定期抽检记忆条目。
共享账户里的跨人泄露
  • 症状：用户投诉 Agent 说出了家人或同事的信息；企业账户里一名员工看到了另一名员工的地址。
  • 根因：记忆以账户为主体；检索按相似度而不是按人；读取后才过滤权限。
  • 防线：按自然人或显式共享标记分区；服务端在读取前授权；负例测试集覆盖共享账户、企业账户、同名用户；跨人读取按一级事故处理。
删除之后，数据从备份回来了
  • 症状：用户删除后第 25 天，运维从一份第 60 天才过期的备份恢复了整库，旧的记忆条目和向量重新出现；之前发出的删除回执变得不真实。
  • 根因：把备份当成「会自然过期」的存储，删除只做在线上；恢复流程不知道哪些主体已经删除过。
  • 防线：用来防回灌的删除标记（例如用单独保管的密钥对主体 ID 做带密钥哈希）不是匿名数据，而是受控、可按主体匹配的假名化数据——持钥方算得出同一个哈希，就仍能关联到用户（参见英国数据保护监管机构的指南 Pseudonymisation，页面注明正在修订）。所以二选一：法务把它列为 30 天删除要求的例外，写清期限，回执披露仍留存的标记及到期日；或者没有例外，所有相关备份在期限内删除或按用户密钥加密擦除，标记也在期限内清除。匹配密钥一旦销毁而仍有待恢复的备份，就不能再声称可以靠标记防回灌。任何恢复都先按标记重放删除再上线；备份用按用户加密、删除即销毁密钥，或保留期不超过删除时限；法务豁免的备份在回执里单独列出到期日。
过时记忆压过权威数据
  • 症状：用户已经在账户里改了地址，Agent 还按「记得的」旧地址确认订单。
  • 根因：把本应实时查询的权威数据存成了记忆，且没有过期时间；读取时没有与业务系统对账。
  • 防线：地址、订单状态等只从权威系统查；每类记忆设过期时间；记忆与权威数据冲突时以权威数据为准，并向用户确认。
Cross-references 回链

原理去哪里补

  • A03 客服 Agent：身份核实、权限由服务端授予、对话留存与脱敏
  • A06 长任务 goal Agent：goal 与进度账本是权威记录，不是记忆
  • B03 上下文工程：单次任务内的上下文取舍与压缩，和跨会话记忆分开
  • B07 注入与权限：从内容里抽出的字段只是候选值
  • AI 4.3 模型本身没有记忆；短期、长期记忆与摘要压缩的代价 · AI 系统工程手册
  • AI 6.2 注入的攻击面，以及为什么只能限制影响范围 · AI 系统工程手册
  • DV ch11 Context Engineering：记忆的写入、存储、检索生命周期 · CCDV 备考手册
  • AR ch04 强制与状态：会话状态的续接、分叉与重开 · CCAR 备考手册
Your Turn 本人填写

只写真实经历

只写真实经历，没有就空着，不编。公开版只有空表；填好的版本存在自己的私用练习记录里。

场景当时发生了什么我亲自做了什么（团队 / AI 做了什么）怎么发现的，结果和证据之后怎么防
系统「记住」了错误或过时的信息
删除或更正用户数据时发现有漏掉的副本

练习记录

日期口述用时脱稿？答不上的追问下一轮修正（≤2）