很多人说自己想要一个“记得我的 AI”，但真正开始记录之后，马上会遇到两个相反的问题：AI 什么都不记，下一次还要重复解释；AI 什么都记，几天后上下文里充满无关细节，真正重要的决定反而找不到。
解决办法不是简单地增加一个更大的聊天历史，而是给记忆分层。PAI 采用的思路可以概括为三层：热记忆处理当前会话和最近信号，温记忆保存正在形成的模式，冷记忆保留经过筛选的长期经验。
本文会把这套思路改写成一套不依赖特定产品的本地文件方案，重点说明什么该记、什么时候升级、如何防止错误记忆污染系统，以及怎样验证 AI 真的使用了记忆。
关于 API 调用的一个实用提示：这套记忆系统在运行中会频繁调用大模型完成摘要、升级判断和检索等任务。如果直接使用各厂商的官方 API，密钥管理、计费模式和接口差异会带来额外开销。一种常见的中立做法是通过4SAPI 中转站这类聚合接口统一接入多个模型，只需维护一个 API 地址和密钥，即可按需切换模型，同时利用中转站的用量聚合和成本优化功能降低长期运行费用。下文提到的所有 API 调用场景都适用这种接入方式，具体是否采用取决于你的实际需求和预算。
一、记忆不是聊天记录的备份
聊天记录记录的是“发生过什么”，记忆系统要回答的是“以后什么信息值得被使用”。两者的目标不同。
聊天记录通常有以下特点：
- 按时间排列，而不是按决策或主题排列；
- 临时想法和长期事实混在一起；
- 语气、上下文和重复内容很多；
- 很难知道某条信息是否已经失效；
- 很少记录结果和反馈。
如果把所有聊天原文都塞给 AI，它仍然需要自己完成筛选、归纳和判断，而且每次读取的成本都会增长。更稳的记忆系统应该记录结构化信号：什么决定被做出、为什么做、结果如何、以后是否要改变。
二、三层记忆分别解决什么问题
热记忆：保持当前任务连贯
热记忆的生命周期最短，主要服务当前会话或最近几次交互。它包括：
- 本次任务的目标和范围；
- 刚刚确认的格式、语气和优先级；
- 正在处理的文件和未完成事项；
- 用户刚给出的反馈；
- 当前不能忘记的临时约束。
热记忆可以直接放在当前工作目录或会话状态中：
# Hot Memory 更新时间：2026-07-30 ## 当前任务 把 PAI 素材拆成四篇可独立发布的中文技术文章。 ## 已确认约束 - 每篇只解决一个读者问题 - 标签 2 至 3 个 - 不使用品牌导流内容 - 需要写清来源、边界和验证方式 ## 未完成 - 检查官方仓库链接 - 跑文章格式测试热记忆的关键是短。它不是越详细越好，而是让下一步不丢上下文。任务完成后，大部分热记忆应该归档或删除，只有经过筛选的信息才进入更高层。
温记忆：识别最近形成的工作模式
温记忆保存几天到几周内反复出现的模式，例如：
- 你连续几次要求文章增加验证章节；
- 某类任务经常因为路径问题失败；
- 你最近把某种输出格式作为默认；
- 某个项目的优先级发生了变化；
- 一个新的工作流正在试用，但尚未成为长期标准。
温记忆适合写成“观察”，不要过早写成永久事实：
# Warm Memory ## 2026-07-30：文章交付模式 - 观察：最近几篇文章都需要独立阅读、官方来源和可验证步骤。 - 证据：连续 4 次写作任务都出现相同要求。 - 可能影响：文章模板可以默认包含限制、验证和参考资料。 - 状态：观察中，尚未升级为硬性规则。温记忆的作用是让 AI 看到趋势，但不让一次偶然反馈改变长期行为。
冷记忆：保存稳定且经过验证的经验
冷记忆保存长期有效的信息：已经反复验证的偏好、重大决策、长期项目历史和不会轻易改变的工作原则。
# Cold Memory ## 技术文章发布标准 - 来源：多次发布检查和人工修改记录 - 结论：文章应明确适用场景、前置条件、验证方法和限制 - 生效时间：2026-07 - 复核条件：平台规则或内容类型发生变化冷记忆不是“永远正确”。它只是比温记忆更稳定，仍然需要来源、时间和复核条件。
三、一个不依赖数据库的目录结构
第一版可以用 Markdown 和 JSONL 文件搭建：
USER/memory/ ├── hot.md ├── warm.md ├── cold.md ├── decisions.jsonl ├── feedback.jsonl ├── archive/ └── README.md每条 JSONL 记录使用固定字段，方便脚本处理：
{"id":"decision-20260730-001","layer":"warm","created_at":"2026-07-30","source":"conversation","topic":"article-format","signal":"每篇文章需要独立阅读","confidence":"medium","status":"observing","review_after":"2026-08-15"}字段不需要很多，但至少应该能回答：信息从哪里来、什么时候产生、当前可信度如何、什么时候复查。
四、哪些内容值得成为记忆
可以把交互信号分成五类：
明确偏好
例如用户明确说“以后默认使用 Markdown”。这种信息可以先进入热记忆，连续使用后再考虑进入温记忆。
重要决定
例如选择某种技术路线、暂停某个项目、改变发布标准。决定需要记录背景、选项、理由和复盘时间。
结果反馈
“这篇文章太短”“这个方案无法复现”都是反馈，但要进一步记录它对应的输出和改进动作，不能只保存情绪化原句。
重复行为
用户未必明确说过某个偏好，但在多次任务中持续做出相同选择。重复行为可以形成温记忆，不过要标为观察，不要立即当成硬规则。
事实变化
项目状态、工具版本、合作关系和当前目标都可能变化。事实类记忆必须带时间，否则旧信息会继续影响新决策。
五、记忆升级规则：从热到温，再到冷
分层不是把信息复制三份，而是设置升级门槛。
热记忆进入温记忆
满足以下任一条件时，可以提议升级：
- 同一信号在多个任务中出现；
- 它影响了不止一个工作流；
- 用户明确表示以后都按这个方式做；
- 忘记它会导致重复返工。
升级前要保留证据和置信度：
候选信息：文章默认需要“限制”章节 来源：最近 4 篇文章的修改意见 影响：写作交付和质量检查 置信度：中 动作：进入 warm.md，继续观察两周温记忆进入冷记忆
冷记忆的门槛应该更高。需要有持续证据、明确价值和复核条件。一次成功不能证明一条长期规则，连续几次结果稳定才有参考意义。
记忆降级或失效
如果新目标与旧目标冲突、用户明确改变偏好、工具发生重大变化，旧记忆不能直接删除后假装没发生。更好的处理方式是标记过期，并写明被什么新信息替代。
## 过期规则 - 原规则：所有文章都使用同一种开头 - 失效原因：新平台要求不同类型内容使用不同开头 - 替代规则：根据平台和文章类型选择开头 - 生效时间：2026-07-30六、用 Hooks 捕捉信号，而不是记录所有对话
事件钩子可以在几个固定时机做轻量处理：
会话开始 -> 加载当前目标、项目和未完成事项 任务开始 -> 创建 hot.md 的任务区块 工具执行后 -> 记录成功、失败和关键输出 用户反馈后 -> 提取候选信号，不直接写冷记忆 会话结束 -> 生成摘要，等待确认后更新 warm/cold钩子应该尽量小、快、可失败。不要让“记忆写入失败”阻塞正常工作，也不要在每个工具调用后都触发一次昂贵的总结。
一个会话结束摘要可以采用这样的格式：
# Session Summary ## 完成 - 完成了什么 - 输出文件在哪里 ## 重要信号 - 用户明确确认的偏好 - 新做出的决定 ## 候选记忆 - 建议层级：warm - 证据： - 需要用户确认：是/否 ## 未完成 - 阻塞原因 - 下一步注意“候选记忆”与“已写入记忆”必须区分。自动化系统最容易犯的错误，就是把模型猜测写成用户事实。
七、如何让 AI 使用记忆，而不是只加载记忆
把文件放进上下文并不等于模型真的使用了它。可以要求输出中显示依据：
请根据当前任务读取 hot.md、warm.md 和与项目相关的 cold.md。 输出建议时： 1. 标出使用了哪些记忆； 2. 区分当前事实、历史经验和推断； 3. 如果记忆互相冲突，先列出冲突； 4. 如果没有足够证据，不要补写成确定结论。验证时可以设计一个“记忆探针”：提出一个只有记忆文件中才有答案的问题，再检查回答是否引用了过期信息。例如把某个项目状态改成“暂停”，然后要求 AI 列出当前项目，确认它没有继续把旧状态当成进行中。
八、记忆系统最常见的失败
把每句话都记下来
结果是噪声不断增长，真正重要的信息很难检索。解决办法是只记录会改变未来决策的信号。
把猜测当成偏好
模型根据一次选择推断“用户永远喜欢这样”，会造成隐形误导。解决办法是增加confidence和status，低置信度内容只留在温记忆。
没有时间和来源
没有日期的目标、版本和项目状态很快会过期。没有来源的总结也无法复盘。
记忆不可删除
个人信息和错误判断都可能需要删除或修正。系统应提供按主题、日期和来源定位记录的方式，并在删除时检查导出、缓存和备份。
记忆写入影响主任务
如果每次记忆整理都占用大量时间，最终用户会关闭功能。记忆应当异步、分批、可跳过，并优先服务高价值任务。
九、如何用一个月验证系统有没有价值
不要凭感觉判断“AI 变聪明了”。可以记录三个指标：
重复解释次数
一个月内，用户为相同背景重复解释的次数是否下降。
记忆引用正确率
抽查 AI 使用的记忆，统计引用是否对应真实文件，是否使用了过期内容。
返工原因
把返工分成目标理解错误、背景缺失、记忆错误、工具执行错误和输出质量问题。只有知道返工原因，才知道应该改记忆、改流程还是换工具。
这些数据不需要复杂监控系统，用一个表格记录几十次任务就足够发现趋势。数据不足时不要宣布某种架构“更高效”。
十、隐私、备份和恢复
记忆系统的权限应小于或等于任务所需权限。对于私人文档，可以采用分层上下文：普通任务只读取摘要，涉及敏感内容时由用户手动提供原文。
同时做好三件事：
- 用版本控制保留记忆变更记录；
- 定期导出可读备份，并测试能否恢复；
- 从日志中清除密钥、令牌和不应长期保存的原文。
记忆系统越自动，越要能回答“这条信息什么时候被写入、根据什么写入、谁可以读取、如何撤销”。
结论
热记忆让当前任务不丢上下文，温记忆帮助发现近期模式，冷记忆保存经过筛选的长期经验。三层系统的价值不在于保存更多，而在于让信息有生命周期、有来源、有置信度、有升级和失效规则。
第一版不需要向量数据库。用三个 Markdown 文件、一个结构化日志、一个会话摘要模板和一套人工确认规则，就可以开始验证。等你确认哪些记忆真正有用，再考虑检索、自动归档和更复杂的存储。
在实现过程中，所有涉及模型调用的环节——比如生成会话摘要、判断记忆置信度、检索相关记忆等——都可以通过统一的 API 网关来处理。4SAPI 中转站提供了这种聚合能力，你可以用同一个接口访问多个主流模型，并根据任务复杂度选择更经济的模型（例如用小型模型做热记忆提取，用大型模型做冷记忆升级判断），从而在不牺牲功能的前提下控制成本。这种接入方式与本文的本地文件方案完全兼容，是否采用取决于你对密钥管理、成本优化和模型灵活切换的实际需要。
本文参考 Daniel Miessler 的 LifeOS 公开仓库 整理 PAI 的记忆分层思想；不同 Agent 工具的钩子和上下文机制可能不同，接入时应以实际能力和权限边界为准。
