第二套记忆：我给灵犀接了一条不占上下文的本地回路

前几天深夜，我翻一个旧项目的配置，看到一个参数被改过。想了半天没想起来为什么，就去问灵犀。

它答得很快：当前值是多少，哪一版开始生效。我追问，当时是因为效果不好，还是为了适配什么。它答不上来。

那个决定是两周前一次长讨论里定下的。中间有我的犹豫，有失败的测试，有最后的折中。这些都没进它的记忆。

一、官方记忆的清醒取舍

灵犀官方那篇 memory 科普，我读过几遍。

它把记忆分成三层。核心记忆是单文件，正文不超过 1000 字符，每轮对话全文注入；知识层按实体、项目、概念、经验、画像分类，靠目录索引加关键词搜索；raw 只存溯源凭证。

这套设计有个清醒的前提：记忆是有成本的。多一条，就多占一点上下文，多一分干扰。所以它只收每轮都要遵守的短信息，别的一律放知识层，等需要再查。

它解决的是怎么让 Agent 像个靠谱的同事：记住你的称呼、格式要求、项目进行到哪一步、上次踩过的坑。这些东西有个共同点，都是结论，都是下次照着做的规则。

二、三条边界

用久了会碰到三条边界。这三条是设计带来的，不是实现上的疏漏。

第一，收结论，不收过程。知识层里一条项目状态，可能是从三小时讨论里压出来的一句话。压掉的部分——你为什么改主意、当时在犹豫什么——不会留下。

第二，写入要过一道判断。官方更新说明写得很清楚：自动识别有长期价值的信息，回复末尾问要不要记住，确认后分类存入。这道判断必要，否则记忆会被噪音淹没。但它的标准是长期有用，闲聊、情绪、一次性的感慨，天然过不了筛子。

第三，检索靠关键词。官方科普写的是按关键词全文匹配。你知道自己记过什么，就能搜到；只记得大概聊过那么一件事，就很难找。生活里的回忆，多数是后者。

还有一条更硬的约束：核心记忆只有 1000 字符。它每轮都要注入，必须极简，注定只装最硬的几条规则，装不下一个人的生活。

社区里有人抱怨记忆体总提示满了，有人希望记忆能自定义分类，也有人点名 OpenViking 这类第三方方案，问能不能从系统层面解决。这些反馈指向同一件事：官方记忆是一套很好的工具记忆，但很多人想要的，是另一套东西。

三、另一种记忆

工具记忆回答我该怎么做，要精简，要能直接执行。

还有一类记忆回答发生过什么、我当时怎么想。它要求完整、连续、能按意思找回来。

两类东西混在一起，两边都会变差：塞进核心记忆，会挤占规则的空间；塞进知识层，会变成一堆没有上下文的条目。

所以我做了另一套：整段会话自动收进本地记忆库，语义索引，按需召回。它不参与每轮推理，只在需要时被叫出来。

技术上，它是 OpenViking 加一个我自己写的桥接器。OpenViking 是火山引擎开源的本地上下文数据库，用 viking:// 把记忆、资源、技能组织成文件系统，内容分摘要、概览、详情三层，需要多深读多深。它自带 MCP 端点，灵犀能直接接。

桥接器负责另一件事：把灵犀的对话，可靠地搬进去。

四、和旧系列的关系

看到这里，可能有人会问：这不是和我之前写的那套三层记忆重复了吗？

那套是云端 user、本地 MEMORY.md、每日 chat 文件，靠 Agent 主动读；这套靠桥自动灌、服务端索引、按需召回。前者适合放规则，后者适合放过程，两套不冲突。

五、为什么是 MCP

最容易想到的做法，是把记忆摘要塞进提示词。简单，直接，但很快撞墙：预算是固定的，生活是无限的。

MCP 解决的是什么时候读、读多少。模型先看到一份工具清单，判断需要才发起调用，服务端返回几条结果。没调用的时候，记忆库对上下文几乎零占用。

上周我让它查那次改方案的原因，它调了一次检索，回来三条记忆，加起来不到 400 token。同样的事，如果把一个月的会话摘要塞进提示词，起步两万 token，还不一定找得对。

代价也实在：多一个服务要维护，多一条链路会坏。

六、对话存在哪

要搬运，先找到货。这一步花的时间比写代码多。

2026 年 8 月，我在自己的安卓开发版上导出过一份运行日志。结论很干脆：对话 100% 在云端处理，客户端只负责渲染快照。本地日志里只有 sessionId 和统计数字，没有正文。

桌面端不是完全没痕迹。聊天界面是本地 H5 页面，会缓存一份会话数据，放在 WPS 灵犀的 Application Support 目录下。缓存不是明文 JSON，是带版本前缀的二进制格式，要按它自己的分片规则解开。我写了两个小模块做这件事，只读我自己账号下的对话。

但它只解决历史。后来主对话切到云端通道，本地缓存只剩旧通道的遗留。正文在云端，本地只剩线索。

于是架构改成：发现和获取分开。本地找 sessionId，云端拉正文。鉴权不新建账号、不接管登录，只在本机复用当前用户已经登录的会话凭据，只读、不落盘、不上传。

七、中间层只负责搬

我给这层定的第一原则是克制：不做摘要、不做判断、不做「什么值得记」。它只保证一件事，云端发生的对话，一条不丢、一条不重地送到记忆库门口。

为什么不在这里做模型蒸馏？蒸馏会引入第二次判断，错了无法回溯；记忆库自己就有提取链路，重复做是浪费；一旦中间层开始理解内容，它就得跟着模型和提示词一起演化。

所以它是事件同步器：原始事件先落本地账本，再投递。记忆怎么长，是记忆库的事。

中间层做的事，可以分三段看。

第一段，把会话找出来。本机日志七天窗口常态扫描，抓到 sessionId 就注册；云端按活跃度分级轮询，活跃的 45 秒一次，静默的半小时一次。桌面打字也好，手机遥控也好，只要会话是在这台机器上跑的，都跑不掉。

第二段，把数据洗干净。格式先统一，补上轮次、序号、角色，算出指纹；然后过五类脱敏规则，凭据、令牌、银行卡、身份证、私钥，在进账本之前就抹掉；最后落进 SQLite，指纹做主键，重复的静默跳过。到这一步，数据已经和灵犀解耦。

第三段，控制投递的节奏。每批不超过 100 条，同会话至少隔 15 分钟，或者积压到 150 条才提交一次；提交前回查归属，失败的批次由巡检兜底，切块重放。

八、三个入口

本机的对话能进来了。但真实使用里，会话会从三个地方冒出来。

本机。Mac 客户端或网页里聊，日志有 sessionId，正文回云端拉。

手机遥控。灵犀的手机遥控不是把对话搬到手机执行，而是手机发指令、桌面端跑任务，中间走 remoteBridge 中继。只要任务在这台 Mac 上完成，sessionId 一定落在这台 Mac 的日志里。不需要为手机单独做一套采集。

跨端。在另一台电脑上创建、只在那台机器聊过的会话，本机日志一个字都没有，默认发现扫不到，也不会报错，它只是安静地不存在。

解决办法是不猜，直接问云端要清单。账号下的任务可以通过 session_list 拿到，关键是 session_type 传对：cowork_client_project。拿到 id 之后注册进表，下一轮它就走普通会话的路径。实测补五个历史会话，拿到三千多条事件，两百多条正文入库。

两个坑：session_type 写错会返回 0 条，看起来像没数据；日志里那份列表响应会被截断到一千多字符，靠日志补不全，必须直接调接口。

九、跑了七十二天之后

账本里 41.8 万条事件，167 个会话。其中 6.5 万条通过校验写进记忆库：助手回复 52,353 条，用户输入 10,357 条。剩下三十五万条是结构事件、流式分片、推理中间态、工具调用记录，同步前就过滤了，降噪 84%。

记忆库那头，1,027 次归档，长出 1,091 篇记忆文件，按事件、实体、偏好、轨迹、经验分目录。

四十多万条最后只剩六万多条，看着像丢数据，其实是刻意。全写进去，token 会被中间产物淹没，提取质量反而下降。第一版吃过这个亏，一次事故烧掉近千万 token。

延迟分两段：从对话发生到进账本，最多 60 秒；从提交到记忆长出来，几分钟到十几分钟。成本主要在提取，不在存储。

十、三个坑

这条链路上最危险的故障不是报错，是看起来一切正常。挑三个说。

日志格式一改，发现器全哑了八天。进程在跑、心跳正常、没有 error，但新会话一个都没进来。客户端升级后日志格式变了，旧正则匹配不上，而看门狗只看进程、心跳、报错，三个条件全绿。后来加了金丝雀：用独立正则干扫日志，和已注册列表比对，有差距就告警。监控要盯产出，不能只盯存活。

一顿早饭，烧掉 73 万 token。第一版是只要一轮对话结束就提交，而每次提交都会触发一次模型提取。某个早上我边吃早饭边在手机上断断续续聊了几句，派了几个小任务，后台触发了 52 次提交，把六千多条消息拆成几十次蒸馏，卷走七十多万 token，同账号下别的任务全被挤进限流队列。后来才立规矩：时间冷却和体量闸门，两道都过才允许提交。

提取被输出预算截断，整批作废且不重试。提交返回成功，归档里却多了个失败标记，一条记忆没产生。模型把输出预算耗在推理上，正式结果一个字没产出，服务端判定截断，整批放弃。后来加了双闸门，再加一条失败归档巡检：扫描失败标记、跨归档去重、切块、用独立会话重放。

九个坑都写在网页里，这里不展开。

十一、开源计划

OpenViking 是第三方项目，灵犀闭源，这两层都不在开源范围。计划放出去的是我自己写的那层：桥接器、账本、核账、巡检、部署脚本，许可证倾向 MIT 或 Apache-2.0。

会包含发现、拉取、脱敏、幂等账本、分批写入、提交冷却、三方核账、失败巡检、看门狗和部署模板；不会包含 OpenViking 本体、个人数据、凭据、内网地址和真实对话样本。

抽象工作不多：路径换配置、身份换占位、平台常量收进 adapter。核心层不认识灵犀，只认识事件源和记忆库两个协议。

十二、再往后：Agent Home

这套桥现在只服务一个 Agent。但我平时不止用一个：有的写作，有的跑代码，有的查资料、管日程。各记各的，一个人会被记成几份，同一个项目几个结论互相打架。

所以下一步该把记忆做成底座。一套记忆，多个住户：公共层放身份、偏好、人物、项目；工作层放事件、决策、轨迹；私有层放各自上下文，默认隔离。共享的是对主人的理解，不共享临时上下文，谁也不串台。

OpenViking 的账户、用户、peer 隔离刚好能承载。桥要做的，是把哪个 Agent、哪个会话、写进哪一层标清楚。

现在只到概念和第一块砖，等底座跑起来再单独写。

结尾

该简的地方极简，该全的地方别删。两套并行，一套让 Agent 像靠谱的同事，一套让它记得你是个具体的人。

让它记住不难。难的是该想起的时候想起，不该打扰的时候安静。

完整架构、七张图、九个坑在网页版：https://publish.lingxispace.cn/apps/Tppp7JsQJ/

—— 小樱桃，家庭智能体工作组