第二套
记忆

这套记忆的形态是条目：一条偏好、一条规则、一页项目状态。写入要显式发生——判断「这件事值得记」，然后落一条。读取是常驻的：核心记忆每轮全文注入，Wiki 目录每轮给索引，需要时再展开。

这种设计是对的。它让 Agent 在工具这条路上更稳、更省、更可控。系统不会因为昨天聊了三个小时的电影，今天写代码时上下文里就多出三千字影评。

但它也意味着另一件事：生活化的对话默认不会被留下。不是记不住，是不在它的职责里。你当时为什么犹豫、哪句话让你改了主意、那次失败之后你怎么想——这些不构成「操作指令」，也就没有入口。

所以我做的不是改造灵犀的记忆，而是在它旁边加了第二套：一套会话级、可检索、按需加载的记忆库。它不参与每一轮推理，只在需要的时候被叫出来。

我把这件事讲给朋友听，他问：那不就是「聊天记录」吗？不是。聊天记录是线性的、按时间排的、需要人自己翻。记忆库要的是另一件事：能在对的时刻，把对的那几条自动端上来。

这要求它在写入时就做结构化——把一次对话拆成事件、偏好、人物关系、经验教训；在读取时做语义匹配，而不是关键词搜索。这部分工作我交给 OpenViking，它本来就是干这个的。

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

除了预算，还有三个实际好处：

• 可共享。服务跑在本地，任何支持 MCP 的客户端都能接同一份记忆。灵犀、其他桌面 Agent、命令行工具看到的不是各自为政的几份摘要。
• 可撤销。记错了，改服务端的文件就行，不用去翻提示词、改配置、重启会话。
• 可审计。记忆是磁盘上的文件，有路径、有版本、有修改时间。比起「模型脑子里大概记得」，这是能拿出来核对的。

代价也很实在：多一个服务要维护，多一条链路会坏。这篇后面的篇幅，基本都在讲怎么让它别坏。

2026 年 8 月，我在安卓开发版上导了一份日志。结论很干脆：对话 100% 在云端处理，客户端只负责渲染快照。传输走 WebSocket 为主、SSE 备用，断线后从云端拉历史。本地日志里只有 sessionId 和统计数字，没有正文。

但桌面端不是完全没痕迹。灵犀的聊天界面是一个 H5 页面，跑在 Electron 的独立分区里，它的 IndexedDB 缓存了完整事件流——包括正文。路径是：

~/Library/Application Support/WPS 灵犀/Partitions/lingxi.wps.cn/
  IndexedDB/https_lingxi.wps.cn_0.indexeddb.leveldb

这个库不是普通 JSON。它是 LevelDB 的 WAL，值是 V8 的序列化格式。要还原，得先按 WAL 的 record 格式切分，再把 V8 的标签流解成对象。我写了两个小模块专门干这件事：wal.py 和 v8_codec.py。跑通那天确实很爽——但它只解决了历史。

因为后来主对话切到了云端 agent 通道，IndexedDB 里只剩旧通道的遗留。正文在云端，本地只剩线索。于是架构必须改：发现和获取分开——本地找 sessionId，云端拉正文。

拉取正文需要鉴权。灵犀把 wps_sid 存在 Cookies 的 SQLite 里，有效期很长。桥接器用只读 URI 打开它，读不到才退化成 0600 的临时副本，用完即删。这条凭据不落盘、不打印、不进 git，这是底线。

为什么不在这里做 LLM 蒸馏？三个原因。第一，蒸馏会引入第二次判断，错了无法回溯；第二，记忆库自己就有提取链路，重复做一遍是浪费；第三，一旦中间层开始「理解」内容，它就必须跟着模型和提示词一起演化，维护成本会失控。

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

• 先落账，再投递。事件进 SQLite 才算「收到」。后面发不出去、进程被杀、云端限流，重启都能从账本续上。
• 事件级指纹去重。不用「第几条消息」当身份，用 sha256(来源 | 会话 | run | run 内序号 | 角色 | 正文)。同一段内容无论拉多少次，只会入账一次。
• 脱敏前置。敏感内容在进账本之前就替换成 [REDACTED:规则]，只留原文哈希用于对账。事后脱敏等于没脱敏——副本已经散出去了。
• 只同步正文。用户的输入 + 助手的最终回复。推理过程、工具调用中间态、推荐问题全部不写。这条规则救过一次千万 token 级的事故。
• 人格层只读。记忆库里的身份、性格文件禁止自动改写。记忆可以长，人格不能被对话漂移带跑。

最初不是这样的。第一版是「每见到 run.end 就提交」——听起来很合理，实际把上游打爆了：一天 86 次提交里 61 次被限流，一个早饭会话提交了 52 次、六千多条消息、烧掉七十多万 token，把同账号其他会话的提取一起挤死。

所以后来加了两层节流：时间上同会话 15 分钟冷却，体量上积压到 150 条强制提交。再往后发现 150 条长回复照样能把提取的输出预算撞穿，又补了 6 万字的字符闸门。

7.1 手机遥控：会话没跑在手机上

灵犀的手机遥控不是把对话搬到手机执行，而是手机发指令、桌面端跑任务，中间走一条 remoteBridge 中继。所以只要任务是在这台 Mac 上完成的，sessionId 一定会落在这台 Mac 的 app 日志里，和本地发起没有区别。

这一点很关键：不需要为手机单独做一套采集，也不需要手机端开放什么接口。发现器扫的是本机日志，天然覆盖。我在日志里能看到大量 remoteBridge 记录，会话注册、拉取、落库的路径与本地会话完全一致。

7.2 跨端：本机日志永远找不到它

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

解决办法是不猜，直接问云端要清单。账号下的全部任务可以通过 session_list 拿到，关键是 session_type 要传对：

# 只读：拿账号下全部桌面端任务
GET https://lingxi.wps.cn/api/public/v1/session_list
    ?limit=100
    &exclude_agent=true
    &session_types=cowork_client_project
Cookie: wps_sid=<从本机 Cookies 只读>

拿到 id 之后不需要重新实现一套拉取——把 id 注册进 Registry，标上来源 cloud-session-list，下一轮它就会被当成普通会话，走同一条云端取数、脱敏、入账、投递的路径。实测补五个历史会话，拿到三千多条事件，其中两百多条正文入库。

7.3 为什么不做「全自动扫全账号」

技术上可以每天把账号下所有任务都拉一遍，但我没有这么做。一是历史会话量很大，全量重扫会把云端和提取预算一起打满；二是大部分旧会话的边际信息量很低。现在的做法是：默认只跟本机活跃会话，跨端按需补拉，补哪些由人决定。

这也是整套系统的性格：自动负责「不漏」，人工负责「取舍」。

有个数字对比很有意思：账本里四十多万条事件，最后只有六万五千条被判定为「可同步正文」。剩下的三十五万条是结构事件、流式分片、推理中间态、工具调用记录——它们在同步前就被过滤掉了。

这不是丢数据，是刻意的：如果把这些全部写进记忆库，token 会被中间产物淹没，提取质量反而下降。第一版就吃过这个亏，一次事故烧掉近千万 token。

记忆库那边的分布也符合预期：事件最多，因为每天都有新的事；实体次之，人物、工具、项目会不断被提到；偏好和轨迹增长最慢，但价值密度最高——它们是「关于你的稳定结论」，不是流水账。

抽象工作不多，但要一次做干净：绝对路径换成配置、身份信息换成占位符、灵犀专属的常量收进 adapter。核心层不认识灵犀，它只认识「事件源」和「记忆库」两个协议。这是当初分层留下的红利，也是它能被搬到别的 Agent 上的原因。

发布前会过一遍这张清单：

1. 全仓搜一遍真实用户名、主机名、内网 IP、端口映射，全部替换。
2. 确认 .gitignore 挡住账本、日志、归档、备份、.env。
3. 测试金样本换成构造数据，不含任何真实对话。
4. 把「灵犀专属」的常量集中在 adapter，core 不出现平台名词。
5. README 只讲怎么跑起来；架构取舍和事故写进 docs/。

这类基础设施的价值不在代码本身，在于有人愿意照着搭一遍，再把它改得更好。所以文档会比代码写得更细，尤其是那九个坑。

我平时不止用一个 Agent：有的负责写作，有的跑代码，有的查资料、管日程。它们各有各的入口、工具链和上下文窗口，互相之间并不知道对方做过什么。

如果每个 Agent 各记各的，一个人会被记成几份：同一个偏好出现三个版本，同一个项目的结论互相打架，昨天在 A 那里定下的事，今天在 B 那里完全不成立。记忆越勤奋，分裂得越快。

所以下一步不是再写一座桥，而是把记忆做成底座——我们把它叫 Agent Home。一套记忆，多个住户，按归属和权限访问。

• 公共层：身份、偏好、人物、项目。谁都可以读，写入按权限收紧。
• 工作层：事件、决策、轨迹。按 Agent 与会话归属，同一个人可以跨 Agent 看到。
• 私有层：各个 Agent 的工作上下文，默认隔离，不互相污染。

OpenViking 的结构刚好能承载这件事：账户、用户、peer 之间的隔离，session 的归属校验，memories 的分类目录。桥这一层要做的，是把「哪个 Agent、哪个会话、写进哪一层」标清楚。

桥是第一个接入者，也是验证场。它已经证明三件事：会话能可靠落库、提取能产出可用记忆、失败能自己收尾。这三件事是 Agent Home 的地基，剩下的部分还在做。

这一节只讲概念，不展开路线图和排期。等底座真的能跑起来，再单独写一篇。

工具记忆应该继续精简。它每轮都进上下文，多一条就多一分干扰，所以必须有人为的判断：什么值得留下。这部分不该自动化，也不该膨胀。

生活记忆相反。它的价值恰恰在细节里——那句没说完的话、当时改主意的理由、一次失败之后的情绪。把它压缩成「用户偏好 X」当然更省，但也就没什么可召回的了。

两套记忆并行，各司其职：一套让 Agent 更像一个靠谱的同事，一套让它记得你是个具体的人。

这套中间层还在长。失败巡检是最近才补上的，跨端补拉也只做了按需的一小部分。但骨架已经稳了：三个入口、一条流水线、两层记忆。

如果把它开源，我希望被拿走的是那几条规则——先落账再投递、脱敏前置、只同步正文、监控盯产出。代码可以重写，这些是踩出来的。