产品经理的 Agent 入门
上下文、会话与记忆
分清 Context、Session、Memory 和业务事实，理解 Agent 应该保存什么、何时召回以及怎样纠错。
「产品经理的 Agent 入门」之四
上一篇：Agent 的运行过程 · 系列入口 · 下一篇：Agent、Skill、Tool 与 MCP
“让 Agent 记住用户的一切”听起来像能力，实际更像一个没有边界的数据需求。它没有说明记住什么、保存多久、何时使用、如何纠错，也没有区分对话历史、业务事实和用户偏好。
Context、Session 和 Memory 不是一件事
- Context：模型在当前一次调用中实际看到的内容；
- Session：一次任务发生过的消息、工具、审批和状态轨迹；
- Memory：从历史中筛选出来、未来仍值得复用的信息。
模型不会因为上次聊过，就在下次自动记得。应用必须把信息保存在模型之外，再选择性放回 Context。
Session 保存发生过什么，Memory 保存以后还值得用什么，Context 只装现在需要什么。
Context 是工作台，不是仓库
Context 有容量、成本和注意力限制。把全部历史都装进去，会让噪声遮蔽重点，增加延迟，使旧信息冲突，并扩大敏感信息暴露范围。
所以产品不能只写“接入知识库”，还要定义检索范围、来源优先级、更新时间、冲突处理和引用方式。
Memory 应该分层
| 类型 | 适合保存 | 不应该保存 |
|---|---|---|
| User Profile | 经确认的稳定偏好和角色 | 一次性情绪和模型猜测 |
| Project Rules | 架构、验收标准和稳定边界 | 临时任务细节 |
| Working Memory | 当前目标、阶段和决策 | 全部聊天原文 |
| Semantic Memory | 有来源的知识片段 | 无来源的自动总结 |
| Episodic Memory | 过去任务、决策和结果 | 每次无意义交互 |
| Skills | 可复用的方法与脚本 | 客户、订单和正式业务状态 |
客户资料、PRD 版本、审批状态和权限应该存在业务数据库。Memory 可以辅助判断，不应成为唯一事实源。
从对话到长期记忆需要提升链
原始 Session → 摘要 → Memory Candidate
→ 去重、查证、标注来源 → Confirmed Memory → 按需召回重要记忆至少应带来源、置信度、状态、适用范围和复核时间。它还必须允许更新、降权、废弃和删除。永不遗忘不是智能，而是风险持续累积。
本篇小结
- Context 是模型这一次看到的工作材料，Session 是任务轨迹，Memory 是未来仍值得复用的信息。
- 业务对象、正式状态、权限和版本属于业务数据库，不能只保存在聊天或模型记忆里。
- 一条长期记忆至少需要来源、适用范围、更新时间和删除机制；未经确认的模型推断不应自动升级为用户事实。
Agent 记忆的目标不是保存更多，而是让少量可信信息在正确的任务、用户和时间里被正确使用。