--- layout: post.njk source: https://yage.ai/share/ai-chat-history-simple-wins-20260927.html speaker: yage.ai title: AI 的聊天记录：存下有没有，检索用不用 date: '2026-09-27' summary: 文章探讨AI智能体会话记忆的存储与检索价值，指出本地日志默认清理导致数据流失。通过对比开源项目与商业案例，论证了将历史数据注入工作流以产生复利的逻辑，并强调在实现简单检索的同时，需重点解决凭据泄漏与记忆污染等治理难题。 area: PAI category: ai-memory tags: - agent-memory - context-injection - local-storage - data-governance - workflow-automation people: - thedotmack companies_orgs: - hugging-face - anthropic - openai - github - microsoft products_models: - claude-mem - claude-code - funes - deja-vu - mem0 - gong - glean media_books: [] draft: true status: evergreen --- 2025 年 8 月底，独立开发者 thedotmack 在 GitHub 上发了一个开源项目 claude-mem。它的逻辑其实只有一句话：顺手抓下 coding agent 在当前会话里的动作，压缩成结构化记录，等下次开新会话时再把相关的上下文塞回去。这个项目没有融过资，也没有专职团队在打理。截至 2026 年 9 月 23 日，它已经在 GitHub 上攒下了约 9.4 万颗星，五个月内增加了近 4.8 万颗星，稳稳排在整个 agent 记忆赛道的第一位，超过了所有获得风险投资的团队。 很多开发者往往等到本地数据真丢了，才突然意识到这类工具的用处。Claude Code 平时会在本地磁盘记下每次会话的 JSONL 日志，但默认只保留 30 天。客户端每次启动都会自动清理满一个月的记录，既没有提供图形界面开关，删之前没有任何预警，删掉后也没有内置恢复途径，GitHub 上的社区讨论直接指出了这一困扰。这份默认清理的语料，恰恰是软件历史上反复跑通的一条商业路子：把本来就存在的数据，变成可检索、可注入的资产。 ## 一个比 AI 更老的模式 Zoom 早就免费替企业存着销售通话录音，Git 也常年在大家的个人电脑里完整记录每一次代码提交。存这些东西其实不怎么花钱，很多平台干脆免费就存了。但光躺在磁盘上的录音和提交记录，本身并不会自己变成一个软件产品。这里面真正的商业转折点，是把这些沉默的数据拉进每天都在跑的高频工作流，在具体动作发生的瞬间重新调用它们。 过去二十年里，这套模式在各个业务场景中反复跑通过。Gong 切入销售情报赛道时，从来不向客户收取音频存储费用。他们把通话语音转录为可检索、可分析的文本语料，从中提取交易线索，并直接注入销售人员日常使用的客户关系管理系统与沟通辅导流程。销售对话转化为可检索资产后，Gong 在 2024 年的年度经常性收入达到约 2.98 亿美元，根据公司公开数据，截至 2025 年 1 月的年度经常性收入突破 3 亿美元，2025 年 11 月的老股转让二级市场交易给出了 45 亿美元的估值。 做企业搜索的 Glean 走的也是同一条路。公司里的资料总是散落在各处，Slack 里的讨论、Confluence 里的文档、堆积的邮件还有代码库，找起来非常费劲。Glean 把这些散乱的内容聚拢起来，搭了一层统一的企业级检索层，再把上下文顺畅输出给日常办公和各种智能体环境。把分散的历史重新送进工作流，直接带动了商业增长：2025 年 6 月 Glean 的融资估值达到 72 亿美元；到了 2025 年 12 月，其年度经常性收入提升至 2 亿美元，仅用九个月便实现了翻倍增长。 法律服务和代码基础设施领域，同样把沉睡历史做成了巨大的生意。在法律行业，企业因诉讼保全义务长期冻结并保存海量内部通信与电子文档，平时谁也不会多看这些冰封的文件，到了诉讼审查关头，Relativity 等厂商将这些文件转化为可精确检索与打标的语料资产，支撑起 2024 年规模超过 151 亿美元的全球电子数据发现市场。在程序员熟悉的开源软件生态中，Git 协议本身是免费且分布式的，开发者在本地持续产生提交与分支，GitHub 则将这些本地记录汇聚为可全局搜索与团队协作的枢纽，凭借对代码历史的集中检索与协作能力，微软在 2018 年以 75 亿美元完成了对其的收购。 技术问答和家谱档案领域，也遵循着同样的变现逻辑。Stack Overflow 积累了开发者在上千个技术标签下的问答历史，到 2021 年沉淀了超过 5200 万条记录。他们商业化最核心的支柱之一，就是通过企业版把历史问答沉淀为内部知识库，再用接口形式直接注入工程师的日常开发环境，Prosus 在 2021 年 6 月宣布以约 18 亿美元将其收购。在消费级市场，Ancestry 跑去把公共档案馆里的人口普查与生卒档案数字化，整理成超过 650 亿条可查询的家谱语料。高密度的历史档案检索支撑起相当稳定的订阅收入，黑石集团在 2020 年以 47 亿美元将其私有化；路透社在 2025 年 9 月报道其年营收超过 10 亿美元，付费订阅用户突破 300 万。 把这些成功先例放在一起看，底层的商业齿轮其实咬合得一模一样。首先，数据都是平时干活自然生成的副产物，压根不需要为了做产品刻意采集。其次，大家对查这些历史有着持续的高频需求，而且检索质量直接关乎一单交易能不能谈成、一场诉讼能不能打赢、或者一次研发排查能不能搞定。更关键的一点，是系统必须有一条顺畅的通道，能把查到的历史准确送达下一次具体操作之中。销售人员需要在跟进电话前调出客户上个月的原话，诉讼律师需要在庭审审查中定位邮件原文，工程师则需要在排查故障时回溯前人的提交逻辑。三项要素齐备之后，工作流复利驱动的产品往往由最终注入的流程深度决定其价值上限，而合规驱动的产品则由沉淀的数据体量与案件规模决定其市场边界。 这套模式的边界在哪里，看几个反面例子就更清楚了。全球电子病历系统在 2024 年的市场规模超过 330 亿美元，病历记录的数据价值与信息密度都很高，但行业内并未分化出独立的病历检索层公司。病历数据始终停留在医院自身的录入、问诊与医保结算闭环内，缺乏能够自由注入的外部高频工作流。另一个典型案例是工程团队的故障复盘。许多优秀的技术组织都建立了规范的事故复盘文化，沉淀了详尽的高质量分析文档，但重大事故本身属于低频事件，团队内部对复盘报告的调阅频次无法支撑起独立的商业订阅软件，在组织外部也缺乏付费买家。 归结起来其实就三句话：存储解决有没有，检索解决用不用，注入解决复利。只有当数据越过基础存储阶段，在需要时能低成本召回，还能顺畅向操作端持续输出上下文，原始记录的价值才真正开始复利累积。 存数据只回答有没有，检索才回答用不用，注入才让历史产生复利 ## 最密集的语料，最脆弱的存放 如果在终端里仔细盯过一次复杂的开发任务，就会发现屏幕上刷刷滚过去的，几乎全是整个推导过程：模型发起的十几轮文件搜索、尝试安装后报错的第三方依赖、反复修改的配置参数，以及中途推翻重来的设计尝试。日常代码仓库里的提交信息与代码审查摘要，往往只保留了最终证明有效的结果，至于通往这个结果所经历的曲折推导、碰壁记录与决策原因，全都在交代码那一刻给压缩抹去了。 2026 年 5 月，Hugging Face 在 Funes 发布前发表的博客文章里，直接点破了这种缺失：“Everything else has a home. Code is in git, docs in Notion, issues in Linear, chats in Slack. Agent traces don’t have one.”在现代软件工程中，承接代码重构、缺陷修复与日常巡检任务的主体，除了人类开发者之外，正在迅速加入各类自动化智能体。面对接手复杂项目的智能体，了解前人为什么刻意回避了某种看似优雅的实现方案，往往比直接阅读现有代码更为关键。 然而回到现实的工具链中，这部分宝贵语料的保存呈现出明显的两层断裂。第一层是原始会话记录本身。主流本地命令行智能体在运行过程中，都会在用户的本地磁盘上留下完整的文本日志，这属于客户端执行命令时的工程副产物，工具厂商并未刻意设置加密封锁。Claude Code 会将所有交互保存为本地项目目录下的 JSONL 文件，Codex 会将每次运行保存在用户配置目录的日志文件中，Cursor 依赖本地的 SQLite 数据库存储每个工作区的会话状态，Grok、Gemini CLI 与 Antigravity 同样会在本地写入纯文本或结构化数据。这一层语料人人都有，但它们只是孤立散落在各自的文件系统深处，缺乏跨项目的统一索引，无法跨设备平滑迁移，也缺乏任何长期的持久性保证。 第二层是各家厂商相继推出的官方记忆功能，这一层目前普遍做得又封闭、作用域又受限。OpenAI 在官方支持文档中说明其记忆功能依赖云端托管，用户只能在设置界面中逐条查看、纠正或删除记忆条目，官方文档未提供批量导出接口；GitHub Copilot 在 2026 年 1 月上线并在 3 月默认面向付费用户开启的代码仓库记忆功能，由微软云端服务端集中托管，并且设置了 28 天的硬性有效期限。在五家主流工具厂商中，只有 Claude Code 将自动生成的记忆固化为本地纯文本文件，保存在具体项目路径下的特定目录中，允许开发者直接用文本编辑器查看并纳入版本控制。即便做到这一步，Anthropic 官方文档依然明确强调这项记忆属于本机环境，无法在多台机器或云端环境之间自动共享。跨设备与跨智能体之间的上下文复用，成了官方生态中普遍悬空的功能空白。 更为让人头疼的，是基础语料随时都在悄悄蒸发。Claude Code 在其本地配置文件中默认只保留 30 天，客户端在每次启动时会自动扫描并静默删除本地存储中超过一个月的会话日志。这一清理过程没有在图形界面中提供管理开关，执行前没有任何确认预警，删除后也没有任何内置恢复途径，GitHub 上的社区讨论详细记录了这一设计给开发者带来的困扰。在工程实践中，开发者往往隔开数周需要回溯某次重构决策，才发现当时的完整交互细节早已经不复存在。这份语料完全符合成功先例的各项要求：数据在本地自然沉淀，新会话频繁依赖历史经验，注入目标就是下一个终端提示词，但在默认状态下，运行环境会定期把它清理掉。 ## 市场已经回答，但信号要打折 在厂商给出完整的跨环境记忆方案之前，开源社区的开发者已经通过实际行动表明了需求。claude-mem 在 2025 年 8 月建仓之后，关注度在一年内迅速攀升至 9.4 万颗星。2026 年 7 月上线的 deja-vu 采用纯 Go 语言编写，仅靠本地关键词检索管理各主流智能体的会话记录，在两个月内也获得了 930 颗星的关注。从 2025 年下半年到 2026 年秋季，多位互不相识的独立开发者在几乎相同的时间窗口内，同时收敛到了同一个核心设计上：把散落在本地磁盘上的执行轨迹捕获下来，建立索引，并在新会话启动时精准注入上下文。 风险投资机构同样关注到了上下文持久化这一方向，但在资金投入上表现得相对克制。从 2024 年 9 月到 2025 年 10 月的 13 个月内，赛道头部的四家初创企业累计融资约 4000 万美元。其中，源自加利福尼亚大学伯克利分校 MemGPT 项目的 Letta 于 2024 年 9 月完成 1000 万美元种子轮融资；到了 2025 年 10 月，专注于可插拔记忆中间件的 Mem0 与聚焦通用记忆接口的 supermemory 分别完成 2400 万美元融资与 260 万美元种子轮投资；开发时序知识图谱的 Zep 也完成了数百万美元的早期融资。整个领域至今没有出现单笔超过 1 亿美元的大额轮次，资金主要来自早期孵化器网络与专注开发者生态的垂直基金。 平台级厂商则把会话记忆视为自身基础设施生态的黏性飞轮。Hugging Face 在 2026 年 5 月抛出理念后，依托自身的数据集与存储基础设施，在 9 月初推出了本地检索工具 Funes，随后又在三周后的 9 月 21 日发布了针对代码仓库记忆的开源方案 relore。平台并不把售卖独立检索软件作为战略重心，其目标是让开发者的会话数据留存在自身平台上，作为数据集与存储分发载体，为整个开源社区生态构筑护城河。 面对这些数字，需要把社区关注度与真实的商业转化区分开来。GitHub 上的关注度与实际收入之间没有必然关系，这个品类里同样如此。将 claude-mem 的 9.4 万颗星与 Mem0 的 6.6 万颗星直接对比，确实能够证明开发者对本地会话捕获与注入这一操作单元有着强烈的有机关注，但并不能由此推导社区开源项目在商业规模上超越了融资团队。两者的设计目标并不完全一致：claude-mem 专门服务于本地终端会话的捕获与注入，而 Mem0 试图为广泛的智能体应用提供统一的记忆抽象层。此外，Mem0 在业务通报中公布了商业指标，自述其在 2025 年第三季度的接口调用量达到 1.86 亿次，并自述成为亚马逊智能体开发工具包的记忆供应商，而未查到 claude-mem 有任何公开商业化记录。 完全基于本地优先的会话记忆方案，商业化路径依然不够明朗。行业内真正产生持续收入信号的，依旧是提供托管环境与云端接口的服务商。关于这一市场规模的可行性论证，目前主要依靠 Gong、Glean 等相邻先例的历史对账；在原生人工智能智能体领域，开发者的真实需求已经得到确认，但收入闭环尚未完全兑现。社区自发的演进速度明显快于资本的催熟节奏。这里其实透露出一个反直觉但反复出现的规律：最管用的方法往往就是最简单的方法。AI 的存储与记忆层表面上看起来技术竞争激烈、路线五花八门，从向量库到时序知识图谱再到各种重排模型，但 GitHub 上拿到 9.4 万颗星的工具，走的恰恰是不带任何花哨组件的最简实现。对构建本地工具而言，托管 memory 的融资构不成威胁，真正要抢的位置属于社区惯例本身。 社区有机信号热烈但收入未兑现，资本信号小而早期：市场已经回答，但信号要打折 ## 最容易的实现：我们每天在跑的东西 想把会话历史留存下来并随时唤醒，并不需要等待大厂给出最终方案，也不需要引入沉重的基础设施。在我们的实际工作流中，一套由单人维护、完全基于标准库与本地定时调度的自动化管线，已经持续稳定地运转了很久。 整套系统的架构保持着最小化的设计。最前端是一个用 Python 编写的开源导出脚本，GitHub 上的 ai_session_export，完全依赖标准库实现，不引入任何第三方包。针对日常使用的 9 个不同工具，系统分别配置了轻量的读取适配层，覆盖 OpenCode 与 Cursor 的 SQLite 本地数据库、Claude Code 与 Codex 的 JSONL 运行日志、DeepSeek Harness 的压缩文件，以及 Antigravity、Gemini CLI、Grok Build 与早期的 Second Mind 记录。导出的目标是统一的 Markdown 文本，每一个会话对应一个独立文件，文档头部通过标准元数据记录来源工具、会话标识、标题、生成日期、对话轮数、关联的项目目录以及使用的模型版本。每天凌晨，系统的定时任务会自动触发增量导出，只处理新产生的对话，并将所有新生成的 Markdown 文件归档到由 Git 管理的目录树中。 在检索端，我们采用了文本检索优先、语义检索兜底的双层策略。面对日常开发中最常见的特定函数名、配置项或具体报错堆栈，系统直接调用命令行工具 ripgrep 进行毫秒级的精确字面匹配；搜索意图属于模糊概念、回忆不起具体措辞，才调用自托管的向量模型端点进行语义补充。查找到相关片段后，系统将历史经验注入当前会话的上下文，完成对过去认知的调用。此前我们在关于智能体经验落点的讨论中（four-lanes 已发布文章），曾把外部记忆划分为系统架构中的第二层；这一篇所呈现的，正是这一层为什么具备独立的实用价值，以及它的工程落地有多么轻便。 九个来源的本地会话记录，经统一归档与每日增量，由词法优先加语义兜底的检索注入未来会话 一次耗时 29 秒的索引构建过程，直观说明了为什么我们在日常排查中坚持文本检索优先于复杂的向量数据库。deja-vu 维护者在 Hugging Face 的 Funes 发布博客评论区做过一组单方对比测试。在本地 Mac 上，面对 19,195 个会话、30 万文本切片与 100 个问题的基准测试，纯 BM25 词法索引仅耗时 29 秒就完成了全部索引建立，单次查询延迟仅为 24 毫秒，首位命中率达到了 18%。BM25 是一种基于关键词词频的全文检索算法，不需要模型参与。相比之下，依赖向量模型与交叉编码重排的 Funes 在相同语料上建立了 2 小时 3 分钟的索引，单次查询需要 6.3 秒，默认设置下的首位命中率仅为 9%，即使关闭 30 天时间半衰期衰减后命中率也仅为 19%。Funes 的作者随后在讨论中承认，如果答案明确落在某个特定会话，BM25 词法匹配已经足够好用，并表示“funes shines when the information is actually difficult to find”。基准测试跑出的这组 29 秒方案再次印证了那个经验：最管用的方法往往就是最简单的方法，对于日常编码而言，快速、透明且低资源消耗的文本搜索是更合理的起点。 一个在测试中从未到达终点的开发任务，解释了为什么归档系统必须保留原始交互记录，而不能依赖语言模型提炼的摘要。在 Funes 作者公开的基准里，测试对比了默认上下文压缩机制、书面交接文档与检索原始会话的执行效率。在设定的两个复杂任务中，直接检索原始记录所消耗的加权令牌数量，分别只有书面交接文档的八分之一和四分之一。更为关键的是，模型生成的摘要破坏了排查链条的完整性，导致测试中的一个任务完全无法推进到底；总结虽然精简了字数，却压平了决定排错走向的关键技术细节。因此在我们的输出规则中，系统展示给模型的永远是带有时间戳与会话来源的可核对原文摘录，坚持不用二次生成的总结来替代原始证据。 换嵌入模型只需重新扫描目录，这种省心的体验确认了把索引视为可丢弃副产物的合理性。向量索引与专用检索数据库会随着嵌入模型权重的升级、文本分块切分规则的调整而面临整体重建，但磁盘上的 Markdown 原始文件永远是人类可读、可平滑迁移、可由版本控制系统托管的。只要基础语料的文本文件完整保留在本地，升级底层检索技术可以直接清空缓存、重新解析，没有任何历史沉淀绑定在私有数据库格式里。 ## 难的不是检索，是治理 把会话历史保存下来并在本地检索出来，在工程实现上相对直接；真正让这套体系产生摩擦与复杂度的，是语料持久化之后带来的治理挑战。零散的调试记录一旦集中索引并在工作流中流转，原本停留在单次调试中的边界问题就会全面放大。 首先浮现的是凭据泄漏风险。在编码智能体的交互轨迹中，不可避免地包含着临时生成的测试密钥、数据库连接串、未脱敏的代码片段与内部网络地址。在单次会话运行期间，这些敏感信息原本只停留在本地的独立日志中；一旦对历史记录建立全局索引甚至尝试在多台设备之间同步，泄漏面从单次会话扩大到持久、可检索的存储。Hugging Face 在 Funes 的安全设计中设立了三道防线：在解析会话建立索引时执行初始脱敏；在发布共享数据时强制运行专门的密钥扫描工具 trufflehog，并严格执行扫描失败即阻断的防御原则，只要扫描工具缺失或进程崩溃就立刻终止外发。trufflehog 是一种针对代码与日志中高熵字符串和特定格式凭据的自动化扫描工具。此外，系统还提供专门的清理命令，用于从本地已有的索引记录中剥离凭据信息。若团队计划在多位开发者或多台设备之间流转记忆资产，这道针对凭据的安全防线是必选项。 更为隐蔽的威胁来自长期记忆污染与指令注入攻击。Dong 等人 2025 年发表的论文（arXiv:2503.03704）提出了针对智能体记忆系统的 MINJA 攻击框架，证明外部攻击者不需要攻破宿主环境的执行权限，只需像正常用户一样发送一组看似合法的对话输入，就能诱导智能体将恶意指令持久写入长期记忆，进而在未来的独立会话中篡改系统的操作逻辑。Chen 等人关于 AgentPoison 的研究（arXiv:2407.12784，NeurIPS 2024）同样揭示了通过向检索知识库注入隐蔽后门、在特定触发条件满足后劫持模型行为的路径。Funes 的安全指南明确提醒，来自任何第三方的共享记忆文件都属于不可信输入，很有可能内嵌针对智能体的恶意提示词注入。一个能够长期保留历史经验的智能体，客观上也对外暴露了一个持续存在的受攻击面。 检索机制本身与大语言模型的注意力机制也存在着天然的物理约束。在 deja-vu 维护者运行的基准测试中，开启默认的 30 天时间半衰期衰减后，一个月前历史记录的首位召回命中率直接从 19% 跌落到了 9%，而开发者磁盘上的大量有效经验往往沉淀在数月之前。此外，Liu 等人的研究（arXiv:2307.03172，TACL 2023）系统指出了长文本中普遍存在的中间遗忘效应，模型在处理长上下文时往往优先关注头部与尾部的内容，检索模块召回的相关片段一旦落在提示词的中间槽位，模型对这部分信息的利用效率会显著下降。检索准确召回历史，并不自动等同于模型在实际决策中能够正确吸收并执行。 这些工程层面的摩擦表明，检索算法从来不是这个产品栈里最稀缺的壁垒。操作权限的设计此前文章讨论过，而对于会话记忆而言，数据的最终归属权、凭据的自动脱敏、历史经验的失效判定与撤回机制，才是决定一套系统究竟是临时实验品还是可靠基础设施的分水岭。 将沉默的会话记录重新接入工作流，并不依赖复杂的宏大叙事。从本地日志的规范留存，到日常开发中的平滑召回，整个机制始终遵循着那个反复出现的规律：存储解决有没有，检索解决用不用，注入解决复利。 你的智能体已经在本地磁盘上写下了最密集的决策记录，默认三十天后它们就会在静默中消失，而我们能做的，正是其中门槛最低也最确定的那一步。