Agent 项目面试里，很多候选人会说“我们给 Agent 加了记忆”。这句话听起来先进，但很容易被追问：记忆存什么？什么时候用？用户能不能删除？不同用户之间如何隔离？错误记忆会不会影响后续决策？
记忆不是把聊天记录无限保存，也不是每次把历史都塞进上下文。真正可上线的 Agent，需要把状态、偏好、事实和权限分开管理。否则记忆越多，越可能带来隐私风险、幻觉放大和回答跑偏。
先分清三种信息
第一类是当前任务状态，比如用户正在让 Agent 修改简历、生成日报、查询订单。这类信息生命周期很短，任务结束后就应该归档或清理，不能长期影响用户的其他请求。
第二类是长期偏好，比如用户喜欢简洁回答、常用技术栈、默认城市、语言风格。这些可以提升体验，但必须允许用户查看、修改和删除。
第三类是事实和权限，比如用户身份、组织角色、可访问的数据范围。这类信息不能由模型自己记忆和判断，必须来自业务系统。Agent 可以使用它，但不能绕过权限系统。
记忆写入要比读取更谨慎
很多系统的问题不是不会读取记忆，而是写入太随意。用户随口说一句“我可能想去上海”，不代表长期偏好就是上海；一次临时任务里的项目名称，也不一定应该成为长期记忆。
更稳的做法是：只有稳定偏好、明确确认的信息、反复出现的行为模式才进入长期记忆；敏感信息、临时任务内容、高风险业务状态不写入长期记忆。必要时让用户确认：“是否以后默认按这个方向处理？”
记忆要有权限和遗忘机制
Agent 记忆一旦参与决策，就必须可审计。系统应该知道某条记忆从哪里来、什么时候写入、被哪些任务使用过。用户要求删除时，不应该只是在界面上隐藏，而要让后续召回不再使用它。
如果是企业场景，还要考虑组织边界。个人偏好不能泄露给团队，团队知识不能泄露给无权限用户，离职或角色变化后权限要重新计算。这里不能依赖模型“自觉遵守”，必须由检索和业务层做过滤。
面试里可以讲一个失败例子
比如简历 Agent 曾经记住用户“想投后端”，后来用户临时准备产品岗，系统仍然按后端角度给建议。这不是模型能力差，而是记忆没有区分长期偏好和当前任务。修复方式不是删掉所有记忆，而是给记忆加类型、置信度、更新时间和适用场景。
这种例子很有面试价值，因为它说明你知道 Agent 质量问题不只来自模型，也来自状态管理。
一个成熟的回答
可以这样总结：我不会把 Agent 记忆设计成无限聊天记录，而会拆成短期任务状态、长期用户偏好和业务权限事实。写入记忆要有确认和过滤，读取记忆要按场景和权限召回，用户可以查看和删除，系统记录记忆来源和使用情况。这样 Agent 才不会因为“记得太多”变得不可控。