Personal Agent 记忆系统

Personal Agent 记忆系统：偏好、事实、事件与时间更新

作者: DeepSeekAgent.io 编辑部
发布: 2026年10月22日
更新: 2026年10月22日

Personal Agent 的记忆不是把所有聊天永久塞进上下文。可靠的记忆系统必须回答四个问题：记住了什么、从哪里得知、现在是否仍然有效、用户如何修改或删除。缺少这四项，更多历史只会带来更高成本和更隐蔽的错误。

本文给出一套可以直接放进 DSH 工作区的记忆结构，并说明写入、检索、冲突、过期和删除规则。

四类记忆不能混在一起

类型	内容	示例	默认寿命
偏好记忆	用户希望系统如何工作	中文回答、发布前确认	直到用户修改
事实记忆	相对稳定的个人或项目事实	时区、项目路径、设备名称	定期复核
事件记忆	发生过什么及其结果	上周发布了一篇文章	按时间归档
工作记忆	当前任务的临时状态	正在核对第 3 个来源	当前 Session

工作记忆留在 Session，事件进入按日期记录，偏好和事实进入用户可编辑文件。这样可以避免一次任务里的临时要求意外变成永久 Persona。

一套最小目录

memory/
├── profile.md
├── preferences.md
├── facts.md
├── sources.md
├── events/
│   ├── 2026-10.md
│   └── 2026-11.md
└── checkpoints/
    └── daily-intelligence.md

文件名称按语义划分，不要按模型或聊天编号划分。换模型以后，记忆仍然保持同一含义。

每条长期记忆都带元数据

一条长期记录至少包含内容、来源、确认状态和更新时间：

## Publishing approval

- Value: Publishing always requires explicit confirmation.
- Source: User instruction in Session 2026-10-22.
- Status: confirmed
- Updated: 2026-10-22
- Scope: all website publishing tasks

“模型从对话推断”与“用户明确确认”不是同一可信度。推断内容先标记为候选，不应直接控制高风险操作。

写入规则比检索算法更重要

Personal Agent 每轮都可以产生大量信息，但只有少数值得长期保存。建议只在以下情况写入：

用户明确要求以后沿用；
某事实会影响多个未来任务；
已完成事件需要支持恢复或审计；
用户确认模型提出的候选记忆。

不要保存密码、完整凭据、一次性验证码和无关私人材料。账号密钥应由专门的凭据系统管理，记忆只记录“使用哪个连接”以及权限范围。

如何处理冲突与时间变化

当新信息与旧记忆冲突时，不能简单按检索相似度选择。采用以下顺序：

明确的新指令
  > 同一范围内更新时间更晚的确认记录
  > 用户确认的稳定偏好
  > 模型推断的候选信息

旧值不要直接消失。把它标记为 superseded，并记录替代关系；这样能解释为什么今天的行为与上周不同。涉及日程、地址、项目状态和订阅等时间敏感事实，还应设置复核日期。

检索时只拿任务所需的最小集合

每次把整个 memory/ 注入上下文既浪费 Token，也会让无关偏好干扰任务。先按任务确定范围，再加载相关片段：

写文章：语言、编辑规则、目标站点和近期选题事件；
处理日历：时区、工作时间和指定日历；
起草邮件：称呼、语气和当前联系人，不加载全部项目历史；
运行代码：项目路径、测试与发布边界，不加载私人行程。

检索结果应保留来源和更新时间，模型输出重要决定时可以说明依据。

Session 压缩后的恢复点

长 Session 会压缩，工具消息也可能触及 Provider 限制。不要依赖聊天历史保存唯一进度。在 checkpoints/ 中记录：

# Daily intelligence checkpoint

- Last successful date: 2026-10-22
- Output: reports/daily/2026-10-22.md
- Sources processed: 18
- Pending: verify one Gemini release date
- Next safe action: verify pending item; do not publish

恢复时先读取检查点，再读取必要事件；不需要重放全部聊天。任务完成后更新检查点，并保留旧产物供审计。

用 DSH 落地写入审批

在 AGENTS.md 中定义：

- 读取 memory 文件可以自动执行。
- 修改候选事实时，先把 proposed change 展示给用户。
- 用户明确确认后才能把 status 改为 confirmed。
- 删除记忆时同时说明会影响哪些定时任务和工作流。
- 发布、发送、付款和账号修改不能由记忆中的旧授权自动批准。

模型可以建议记忆，但长期写入由明确规则控制。对外动作仍需要当次授权，不能因为记忆中存在“用户通常会同意”就跳过审批。

每月做一次记忆维护

维护不只是删除旧内容。建议按下面的顺序：

找出超过复核日期的事实；
合并重复但来源不同的记录；
检查已被替代的偏好是否仍被检索；
删除不再需要的事件明细，只保留必要摘要；
验证关联 Schedule、Plugin 和工作区是否仍存在；
抽样测试换模型后是否做出相同权限判断。

用户还应能要求导出和清空记忆。删除范围必须同时覆盖索引、摘要和派生缓存，而不只是原始 Markdown 文件。

评测记忆是否可靠

可以构造五类测试：偏好变化后下一次任务是否采用新值；临时要求是否错误写成永久规则；冲突事实能否指出来源；过期信息是否触发复核；删除后是否还会从摘要中返回。

Personal Agent 研究开始关注时间干预和用户条件化评测，就是因为静态 Persona 很容易在一次测试中显得准确，却无法适应真实用户的变化。一个好的记忆系统不会“什么都记住”，它会让正确的信息在正确时间、正确范围内被使用。