AI助手持久本地记忆：一项用户自主的架构提案

当AI助手患上「失忆症」

一位54岁的荷兰自闭症患者Bert Singels，基于自己使用AI助手的挫败体验，提出了一项名为「持久本地记忆层」（PLML）的技术提案。他不是开发者，也不是科技从业者，但他的观察切中了一个被行业忽视的痛点：AI助手无法可靠地记住用户已经告诉过它的重要信息。

即便对话历史明明还躺在应用里，AI在需要时却可能无法访问相关内容。用户不得不反复解释系统配置、重新陈述已经做出的决策、再次排除已经失败过的方案。Singels的提案核心很简单：与其完全依赖AI提供商记住一切，不如让用户自己保存完整的对话历史，并通过本地系统在需要时检索出正确的信息。

问题本质：不是存储，而是检索

当前AI助手被越来越多地用于跨会话的长期工作——软件开发、系统运维、技术排障、研究写作。这些场景都依赖累积的上下文。当助手无法调取之前的决策记录时，会产生五类连锁问题：重复劳动、连续性断裂、重复犯错、信任感下降、以及供应商锁定。

提案指出了一个容易被混淆的关键区分：问题不在于对话数据是否被存储，而在于正确的信息能否在正确的时刻被检索并供给模型。这个区分决定了解决方案的方向——不需要无限扩大模型的上下文窗口，而是建立一个独立的检索层。

据Singels在提案中的分析，现有AI服务即使保留了完整历史，也缺乏可靠的机制将相关片段在需要时重新注入对话。这导致用户在长周期项目中反复「重建」已经完成的工作。

上下文窗口指语言模型单次推理时能够直接“看到”的token数量上限，包括系统提示、对话历史和当前输入。一旦对话超出该窗口，早期内容会被截断或被迫摘要，模型便无法直接访问。不同模型的窗口大小差异很大，从几千到上百万token不等。PLML的洞察在于：即使窗口足够大，将全部历史塞入既昂贵又低效，且模型对长上下文中间部分的注意力会衰减。因此，与其无限扩大窗口，不如建立独立检索层，在每次请求时精准注入相关片段。

架构拆解：五个组件，一个原则

PLML的核心原则概括为一句话：本地存储、本地检索、只分享必要内容。它将三个原本被捆绑在一起的功能解耦：长期存储、上下文检索、语言模型推理。

本地对话档案

使用SQLite或类似本地数据库存储消息及其元数据——提供商与对话标识符、时间戳、说话者、消息内容、项目关联、附件链接，以及对决策、更正和未完成任务的引用。全文索引和可选的向量索引支持不同的检索方式。档案存放在用户自己的设备上。

SQLite是一个嵌入式关系型数据库，整个数据库以单一文件形式存放在本地磁盘，无需独立服务器进程。它支持事务、索引和全文搜索扩展（FTS5），广泛用于浏览器、移动应用和桌面软件。对PLML而言，SQLite的吸引力在于：零运维、跨平台、单文件便于备份与迁移，且FTS5能高效处理精确术语和命令的全文检索。向量索引则可通过扩展或独立组件实现，与关系型元数据配合，形成混合检索基础。

对话捕获

通过浏览器扩展或受支持的应用集成捕获新消息。集成方式包括官方导出导入、提供商API、浏览器扩展与渲染界面的交互，以及受支持的本地应用接口。对于浏览器捕获，需要检测消息、保持顺序、避免重复，并识别不完整的响应和已编辑内容。

本地检索引擎

当新请求到达时，检索引擎在档案中搜索相关材料。一个稳健的实现会组合多种方法：全文搜索处理精确术语、命令、型号和技术标识符；语义搜索处理不同措辞表达的关联概念；元数据过滤按项目、提供商、日期筛选；时效性与相关性排序；以及源消息检索——调取原始消息而非仅依赖摘要。

提案举了一个具体例子：用户要求继续一个Windows备份项目，但没有提及具体的硬盘、镜像软件或之前的排障步骤。检索引擎可以定位到早前的相关决策并供给助手。

全文搜索与语义搜索是两种互补的检索范式。全文搜索基于关键词精确匹配，适合命令、型号、错误码等标识符；语义搜索将文本映射为嵌入向量（高维数值表示），通过向量距离衡量语义相似度，能召回措辞不同但概念相关的段落。向量索引（如近似最近邻结构）使大规模语义检索可行。PLML组合两者，并用元数据过滤和时效性排序收窄结果，避免单一方法的盲区——全文搜索漏掉同义表达，语义搜索则可能忽略精确技术标识符。

本地记忆代理

一个轻量级本地代理协调检索与浏览器交互。它负责识别相关对话、选择源段落、在段落含糊时检索更多上下文、准备紧凑的上下文包、与浏览器界面交互、验证上下文已提交且响应已收到，并在检索失败时如实报告而非静默编造缺失的上下文。

说个细节（此处为提案的工程判断），本地代理不需要复现大型云模型的能力。大部分操作可由常规代码完成，小型本地语言模型仅在自然语言分类或语义解释等任务上提供辅助。

提供商接口：两种集成模式

模式A：浏览器集成——浏览器扩展与现有聊天界面交互，准备上下文消息、输入对话并提交。这种方式可以避免API费用，也不需要提供商实现专门的记忆API，但依赖浏览器界面、适用的服务规则和适当的自动化保障。

模式B：受支持的API或应用集成——在API可用且合适的情况下，本地服务可以直接向提供商发送上下文。控制更可预测，但可能引入使用成本、凭证管理和提供商特定的集成要求。

架构设计要求同时支持两种模式，而不将档案绑定到其中任何一种。

上下文管理：发送什么比存储什么更关键

检索到相关历史只是第一步。提案强调，系统必须区分七类信息：当前项目状态、重要用户需求、既往决策及其理由、已经失败的方案、对助手行为的明确更正、未解决问题与下一步、以及用于验证上述内容的原始消息。

在准确性至关重要的场景，上下文管理器应优先使用原始源材料。摘要可以加速检索，但不应成为重要技术细节的唯一记录。

上下文预算

发送给模型的上下文量应受其实际限制控制。如果检索到的历史过大，系统应优先最重要的材料、将工作拆分为连贯的片段，或在后续交互中请求进一步检索。提案特别提醒：简单地发送多条大消息并不等同于保留上下文——较早的消息可能仍落在模型有效上下文窗口之外。系统必须追踪实际已供给的内容，避免假设所有历史细节仍然可用。

有效上下文窗口不等于模型标称的最大token数。实际可用空间需扣除系统提示、工具定义和预留输出token；更重要的是，模型对窗口中部信息的利用率往往低于开头和结尾，这一现象被称为“中间迷失”。因此，即使较早消息仍在窗口内，也可能未被模型有效利用。PLML要求系统追踪实际已供给的内容，并优先注入高相关性片段，而非假设“历史都在窗口里就等于模型记得”。

验证机制

在使用检索到的信息之前，系统应能识别其来源，区分已验证的历史事实与推断的摘要。如果找不到足够相关的材料，应如实说明这一限制，而不是编造连续性。

存储规模：文本对话其实很轻

提案给出了一个示意性估算：假设用户每天交流约24000词，按每词6字节（含空格和标点）计算，一年原始文本约52MB。按每用户每年200MB规划（为元数据和存储开销留出更大余量），1000用户为200GB，100万用户为200TB，9亿用户为180PB。这些是估算而非实测平均值。

架构上的核心优势在于：每个用户的档案可以留在自己的设备上。提供商若提供本地记忆功能，无需为了使其可搜索而集中托管每个用户的完整对话历史。本地存储也避免了要求将整个档案加载到活跃的模型上下文中——搜索和检索只选取特定请求所需的信息。

隐私与安全：本地优先不等于零风险

本地优先存储可以减少提供商持有的个人对话数据量，但不会消除安全要求。提案列出了必要的防护措施：本地访问控制与可选的磁盘加密、浏览器访问的明确权限边界、防止其他本地应用未授权访问、凭证与提供商会话的安全处理、对哪些检索片段可被传输的明确控制、共享内容的可见指示、数据导出删除与保留控制，以及防止嵌入在归档消息或检索文档中的恶意指令。

一个关键设计立场是：归档消息应被视为历史信息，而非自动信任的指令。本地代理不得允许检索到的内容覆盖当前用户意图或安全控制。默认策略应是数据最小化——完整档案保留在本地，只传输当前任务必要的段落。

用户体验与提供商独立性

典型交互流程被设计为最小化用户干预：用户打开AI助手、要求继续某个项目、本地记忆服务搜索档案、检索相关决策与源消息、将上下文供给助手、助手基于这些信息继续工作、新消息被归档以供未来检索。用户也应能检查检索了什么、更正不准确的项目摘要、排除特定对话、随时禁用自动化。

提案主张本地档案使用开放、有文档的数据格式。用户应能在AI提供商之间切换，而不必重建个人历史或依赖专有的记忆格式。提供商特定的适配器处理浏览器界面、消息提交和上下文限制的差异，底层档案和检索系统保持独立。这为开源实现创造了空间——一个可与多个AI服务配合使用的本地记忆层。

分阶段路线图与可量化评估

提案将开发分为六个增量阶段：本地档案（导入导出、SQLite存储、全文搜索）→ 自动捕获（浏览器扩展、去重、可靠性检查）→ 上下文检索（语义搜索、源消息检索、排序、上下文包生成）→ 浏览器自动化（输入检测、上下文插入、提交验证）→ 多提供商支持（适配器、通用格式、上下文预算管理）→ 可靠性与安全（长周期项目测试、检索准确率测量、恢复测试、隐私控制评估）。

评估标准不是「有没有记忆功能」，而是可量化的结果：相关历史决策成功检索的百分比、遗漏或错误检索的比率、用户重复提供信息的频率、助手推荐与已记录决策相矛盾的概率、来源归属准确性、恢复长周期项目所需时间、需要手动恢复的交互次数、传输给提供商的个人数据量、跨提供商和应用更新的兼容性。

技术附录给出了初始工程目标：在精选的相关历史段落测试集上达到至少90%的检索召回率。提案明确说明这是拟议的工程目标，而非已确立的性能结果。

技术选型与概念验证

技术附录建议的组件组合相当克制：浏览器扩展用JavaScript和Chrome Extensions Manifest V3，本地服务用Python或Node.js，对话数据库用SQLite，全文搜索用SQLite FTS5，语义检索用本地嵌入模型和向量索引（MVP阶段可选），上下文管理器用Python或TypeScript，可选的本地小型语言模型用于请求分类，提供商适配器处理界面检测与提交验证。

设计规则被加粗强调：保持数据库、检索引擎和提供商适配器分离。对一个AI提供商的更改不应要求重建对话档案。

概念验证分为四个阶段，每个阶段都有明确的验收标准。例如阶段一的验收标准是：导入的消息可搜索、重复被检测、原始文本可无改动检索。阶段四的验收标准是：助手收到预期上下文、扩展检测到失败、用户可检查所供给的内容。提案建议在得出结论前至少运行30个代表性测试问题。

首个原型范围限定为一个提供商和纯文本对话。图像、音频、视频附件、复杂多智能体工作流和完全自主恢复可以后续添加。原型不需要本地运行大型语言模型——常规搜索和数据库软件足以支撑初始版本。如果选定的浏览器界面可以可靠集成，也不需要API。

这份提案真正值得关注的地方

Singels在开头明确表示，他不保留这个想法的所有权。「任何人欢迎使用这个想法、开发它、改编它、基于它构建软件，或将其带向完全不同的方向。你不需要我的许可。」他真正担心的是另一件事：被大公司复制后埋进内部待办清单，无限期搁置，而底层问题依然未解决。

这个提案的技术成分大多是成熟组件的集成，而非突破性创新。它的价值在于提出了一个清晰的问题框架——将个人历史与模型推理分离，并给出了一个可操作、可验证、隐私意识明确的起点。对于一个没有技术背景的用户来说，这种从真实痛点出发、拒绝供应商锁定、强调可量化评估的思考方式，本身就值得AI产品架构师认真对待。

提案的结论句可以作为整个思路的浓缩：用户的对话历史应作为持久的个人资源发挥作用，而不是在助手失去线索时被反复重建的信息。