OpenChronicle / Calvin 访谈：把 AI 记忆从产品功能变成本地基建

大意

「赛博禅心」公众号 4/26 长访谈（约 2 万字），对话清华 00 后 Calvin（Vida 团队，主攻 Proactive Agent）。背景是 OpenAI 在 4/21 给 Codex 上线了记忆功能 Chronicle（仅 Pro 订阅 + mac），Calvin 团队 4/22 把开源对应物 OpenChronicle 丢到 GitHub（github.com/Einsia/OpenChronicle）。技术上他们走 AX Tree 优先 + 截图兜底：AX Tree 是 macOS 给残障辅助用的老接口，能直接拿屏幕的结构化文本（当前 app、焦点输入框、URL、按钮文字），比 OCR 便宜也更准；飞书/Word 这类自渲染应用读不到，才退回截图，且截图基于光标/滚动/切换触发器。轻度工作 50¢/天，重度 3-5 美元/天，电脑够强可以跑 gpt-oss-120b 全本地。

核心叙事不是”又一个记忆产品”，而是把 Memory 定义为设备级基建——本地 Markdown 池按 7 个分类（人/项目/工具/话题/联系人/组织/事件）扁平存，对外通过 MCP 协议暴露，Claude Code / Claude Desktop / Codex / OpenCode 都能一键接。Calvin 的判断是：今天市面上 AI 产品的记忆量不缺，缺的是跨产品连贯——你在 Cursor 做的设计决策、飞书讨论的架构、Slack 收的需求，应该能在另一个 Agent 里被直接承接。

8 个核心观点（含原文摘录）

1. 现在做记忆的时机判断

“以前模型能力太差，记不记得住影响都不大。但现在，随着 OpenAI、Claude 新一代模型的发布，乃至国内开源模型的追赶，模型之间的差距逐步缩小，真正影响用户使用体验的将是模型拥有的关于用户的记忆与 Context 多少”

三层意思堆在一起：模型能力差距收敛是前提；收敛之后差异化的位置会搬家——从模型本身搬到模型对你的认知；所以”怎样记，记什么”才成了真问题。

紧接着他做了一个用户分群：

“我们关心的不只是怎么让现在这些擅长使用 LLM，擅长写 Prompt 人群用的更”爽”；我们还关心怎样让那些描述不清楚需求，不擅长使用 LLM 的群体用的更”轻松”。”

藏了真正的目标用户假设——记忆是给”说不清楚需求”的人用的辅助轮。会写 prompt 的人靠 prompt 工程补 context，不会写的人只能靠系统主动观察、主动记录。这跟”记忆 = 个性化”的常见叙事不同，他把记忆当成”降低使用门槛”的杠杆。

最后概括：

“记忆，让人与 AI 的交互，从无状态变成有状态，从有负担变成无负担”

“无负担”是他的关键词，不是”个性化”也不是”准确”。

2. AX Tree 优先：算账后的技术选择

承认主流路径是截图 + OCR + RAG（包括 OpenAI Chronicle）：

“我的第一反应是「截图保存 & OCR & RAG」，毕竟很多项目，包括 OpenAI 的，都是这么做的”

但切到 AX Tree：

“AX Tree 是 macOS 系统层的一个老接口，本来给残障辅助技术读屏用，把屏幕上的内容，做成一棵结构化的树状描述当前打开的是哪个应用、焦点在哪个输入框、你正在编辑什么文字、网页 URL 是什么、按钮上写着什么字，AX Tree 直接给文本，不用走视觉”

“我们也想过纯走视觉，但算账之后还是觉得 AX Tree 这条路更扎实”

三条理由：(1) 便宜——文本处理成本远低于图片；(2) 更准——对意图信号的识别比 OCR 强很多；(3) 结构化轻量——存储和检索都更方便。

主动指出短板：

“AX Tree 在 Word、飞书这类应用里，由于内部的渲染绕开了系统辅助通道，所以通常只能读到顶栏菜单和文档标题”

最终方案是混合：AX Tree 优先，截图兜底。截图也不是 5 秒一张：

“OpenChronicle 的截图基于触发器，光标运动、页面滚动、应用切换才会触发处理。如果你打开 macOS 什么都不动，记忆系统不会每 5 秒拍一张图回去喂模型。避免你在看电影这种场景下，记忆频繁触发导致 Token 过量消耗与记忆污染”

“记忆污染”是他用的词——不相关屏幕内容（看电影、刷视频）混进记忆池会污染后续检索质量。所以触发器既省钱也保住记忆池信噪比。

Token 账：轻度（8 小时静默不主动调用）50¢/天；重度 3-5 美元/天。逃生出口：本地模型——

“在笔记本上，部署 gpt-oss-120b 模型”

3. 跨产品连贯才是真痛点

作者直接问”OpenChronicle 跟现在市面上 AI 产品已有的 Memory 功能，差在哪？“，Calvin 的判断不绕：

“今天市面上 AI 产品的 Memory 量已经不缺，缺的是跨产品的连贯，上下文全靠手动维护，换个项目就要重新跟 AI 解释一遍你是谁、你在做什么、你之前的判断是怎么形成的”

OpenChronicle 把存储和暴露都从产品里剥出来。存储是 7 个扁平 Markdown 分类：

“把 mac 所有上的应用操作都进同一个本地记忆池，按 7 个分类扁平存成 Markdown 文件，分别对应你这个人、你的项目、你常用的工具、你关心的话题、你联系的人、你工作的组织、你经历的事件”

注意这 7 类是事物本体（人、项目、工具、话题、联系人、组织、事件）而不是按”应用”或”时间”分。暴露通过 MCP：

“对外通过 MCP 这个标准协议暴露成工具调用，Memory Layer 不再绑在某个产品里”

“Claude Code、Claude Desktop、Codex、OpenCode 都已经有一键集成的配置示例。意思是，你在 Cursor 里做的设计决策、在飞书里跟同事讨论的架构方向、在 Slack 里收到的需求反馈，可以在另一个对话窗口里被 Claude Desktop 直接承接”

记忆产生在工具里、消费在 chat agent 里——是”多对多”而不是”对称”的拓扑。

4. 认知层 vs 行动层

“记住你说过什么，是 AI 的认知层，而记住你想怎么做事，是 AI 的行动层，需要理解你在不同场景下的偏好、惯性、潜规则，要难得多”

“比如，当你跟 AI 说「加个日程」的时候，这个日程是被放在飞书日程里，还是放在 Apple Calendar？”

拆开看：认知层对应今天市面上几乎所有的 memory 实现，是陈述性知识；行动层是过程性知识——同一个指令在不同 context 下应该怎么落地。后者难，是因为它不是用户主动告诉你的，需要从行为中推断；而且没有显式正确答案——飞书还是 Apple Calendar，取决于这个日程是工作还是私人。

这跟点 1 那个”无负担”目标连通——会写 prompt 的人可以把行动层信息显式塞进 prompt（“放飞书日程”），不会写的人需要系统自己推。所以行动层记忆才是”降低使用门槛”杠杆的真正落点。

Calvin 没说 OpenChronicle 现在就解决了行动层——他把它指出来当作 Proactive Agent 的真问题。

5. 开源是”掀桌子”

作者问尖问题：

“今年许多团队，都在讲记忆叙事，然后去融资，那么你们为啥选择把这个东西开源？”

Calvin 的回答只有一句：

“掀桌子……然后看看谁能在场景里给出 Best Practice”

可以拆三层：(1) “掀桌子”是动机——他承认这是对抗性姿态；(2) “看看谁能在场景里”暗示真正的护城河——基础设施层会被开源平推，差异化只会留在应用场景的 best practice 里；(3) 所以他不在基建上抢，他在应用层抢。

文章末尾把价值主张重新包了一遍：

“Agent 应该服务于人，去放大人的能力，不能让你变成各家厂商手里的资产，被争夺上下文，被争夺注意力”

“各家大模型厂商都在争夺用户的上下文，毕竟用户用得越多，Memory 越完整，迁移到别家的成本越高”

“OpenChronicle 这种本地优先、模型无关的开源路径，是希望记忆属于用户、可以接到任何 Agent 或者设备上”

注意论证逻辑：他不是说”开源记忆比闭源记忆好用”，而是说”闭源记忆 = 把用户当资产 = 厂商利益和用户利益不一致”。这是个伦理论证而不是性能论证。

6. 对 OpenAI Chronicle 的判断：“干净 vs 凌乱”

“Calvin 说，第一秒确实有点慌，怕 OpenAI 一口气把所有场景都吃下来。但仔细看完文档和实测之后，发现 Codex 这种相对干净的环境里效果可以，到日常 Workflow 那种凌乱环境就还有距离”

关键词是干净 vs 凌乱：

• 干净环境 = Codex 这种单一应用、目标明确的 IDE/coding 场景。状态空间小、信号清晰、AX Tree 也好读
• 凌乱环境 = 你日常的 mac——同时开着 Slack / 飞书 / 邮件 / 浏览器 / Notion / Cursor，跨应用切换。状态空间大、信号噪比低

接着是访谈作者自己对行业的判断：

“记忆正在从「某个产品的差异化功能」逐渐变成「Agent 时代的基础设施」，Cursor 的记忆、Claude 的记忆、ChatGPT 的记忆，都按各自产品视角组织。OpenAI Chronicle 把这件事往前推了一大步，但是碍于商业却仍将记忆圈在自己的应用里”

帮 Calvin 说他不方便明说的话——OpenAI 看到了基建机会，但商业模式让他们不能真做基建。

7. 自己的使用习惯（暴露隐性约束）

闲聊段，但是 OpenChronicle 设计的真实痛点来源：

“他是 ChatGPT Pro 200 美金套餐的常年用户，平时把 Session Memory 全关了，因为 GPT 用着用着经常跨话题串台”

“Claude 的记忆在 General 层次上管得最稳，基本不会互相串台，但 Claude 的 Memory 也就只在 Claude 里有效”

反推 OpenChronicle 的两个核心设计约束：(1) 不串台 → 选 7 分类扁平本体而不是按”会话/时间”流式存（会话流式最容易跨话题污染），也解释了截图触发器避免”记忆污染”；(2) 跨产品有效 → 选 MCP + 本地池而不是云端。

OpenChronicle 的两个核心设计选择，本质是 Calvin 拿自己当 dogfood 用户、把 ChatGPT 和 Claude 各踩到的坑反过来设计的。

8. Proactive Agent 才是终点

文章后段把镜头从 OpenChronicle 拉回真正在做的事：

“聊完工程细节和行业判断，话题滑回到 Calvin 自己，他所带领的 Vida 团队真正在研究的，是基于这套基础设施之上的主动式 Agent”

“现在大部分 Agent 是 reactive 的，你不问它就不动。主动式 Agent，能根据你的 context 主动判断、主动建议、主动行动”

具体场景四个：

“代码中断后恢复、跨文档协作、设计稿修改延续、长期个人知识沉淀。Agent 真正进入你的日常作息，需要的就是「我知道你怎么做事」这一层支撑”

四个场景的共同点——都是跨时间 / 跨应用 / 跨会话的连续性问题，今天 reactive Agent 解决不了的。这跟点 4 的”行动层”连通：知道你怎么做事，才能在你没问的时候主动做对。

文末服务对象：

“如果有了 Proactive Agent，它能服务谁？……所有人。”

“打通世界的记忆、同步现实的节律，让人更自由的去创造”

最后一句明显是宣传话术，但前半句”所有人”对应了点 1 那个分群——proactive 这个特性恰好是给不会写 prompt 的人最大的解放：你不用学怎么提需求，系统主动观察、主动建议。

整体叙事结构

把 8 个点串起来看 Calvin 的整套叙事：

• 现在做的时机 = 模型趋同，差异搬到 context（点 1）
• 怎么收集 context = AX Tree 优先 + 截图兜底 + 触发器（点 2）
• 怎么组织 context = 7 分类本体 + 本地池 + MCP（点 3）
• 怎么用 context 的两层目标 = 认知层 → 行动层（点 4）
• 商业占位 = 基建开源掀桌子（点 5）
• 竞争占位 = OpenAI 守干净、我守凌乱（点 6）
• 设计来源 = 自己 dogfood 重度用户的坑（点 7）
• 终极产品形态 = Proactive Agent，服务”所有人”（点 8）

这是一套自洽的、从底到顶的叙事——基建、商业、竞争、产品都对得上，没有明显空洞或矛盾。

讨论补充（2026-04-27）

跟 Justin 自己 memory 体系的本体论对照

精读到点 3 的 7 分类本体时，Justin 直接说”跟我的实践很像啊”——他指自己的 ~/.claude/memory/ 系统。把两边并排放：

Justin 的体系比 Calvin 多两层他根本没提的东西：

• procedures.md —— SOP / 步骤 / 1→2→3 的过程性知识。这正是 Calvin 说的”行动层”——他指出来当 roadmap，Justin 早就在做了
• mental-models.md —— 跨 case 复用的判断框架。这是抽象层，比”事件”更高一阶。Calvin 7 分类里完全没这个维度

反过来 Justin 少了 Calvin 有的：人 / 组织 两个关系网络维度。这两个对工程师 / 个人知识工作者来说不重要，但对销售、PM、CEO 这种关系密集的角色就是核心。

洞察：Calvin 的 7 分类是个”通用白领”本体，Justin 的本体是”工程师 + 学习者”本体。两套都不是中性的——本体论选择本身就嵌入了目标用户假设。Calvin 嘴上说”服务所有人”，分类却暴露他想象的用户是 prompt-savvy 的工作者，而不是真的”不会写 prompt 的人”——后者反而需要更多关系/情绪/灵感这种软性维度。

更重要的一条——Justin 已经在做 Calvin 说的 roadmap。OpenChronicle 现在是认知层基建，行动层（procedures）Calvin 还没做；抽象层（mental-models）Calvin 没意识到要做。Justin 这套虽然是个人系统不是产品，但本体设计上比他超前一步。

自动升级到讨论后被 Justin 跳过的 4 个方向

讨论模块抛出 4 个开放问题，Justin 选择不展开。留作 followups：

A. 行动层”潜规则”怎么学？ Calvin 举”飞书 vs Apple Calendar”那个例子是个天坑——用户从来没显式告诉过系统这个规则。三个候选路径：(1) 从历史行为反推；(2) 从 context 推断；(3) 主动追问一次然后记住。每条都有大坑：路径 1 冷启动没数据，路径 2 容易误判，路径 3 体验差。Calvin 在文章里把行动层定位成”难得多”就停了，没给方案。

B. 7 分类本体的边界 灵感、情绪、焦虑、卡住的问题、未成形的想法——这些放哪类？Calvin 7 类没覆盖”内部状态”。这对工程任务影响小，但对 Proactive Agent 真要做”主动建议”，缺这块就只能基于行为信号，没有情绪/动机信号。可能是 v1 故意省了，也可能是设计盲区。

C. 跟 horizontal harness 三控制点心智模型的关系 Justin mental-models.md 里的 Horizontal Harness 三控制点（模型能力 / 协议 / 分发）——OpenChronicle 在三个维度上几乎都不占（依赖外部 LLM、用 Anthropic 的 MCP 协议、靠 GitHub 开源传播）。这意味着它在 horizontal harness 维度跟 OpenClaw 处在同一种生存空间——三控制点都没占住，靠场景 best practice 找缝隙。

D. “无负担”目标 vs 开源叙事的张力 Calvin 强调”服务说不清需求的人”，但 OpenChronicle 的实际安装/配置门槛对非技术用户很高（git clone / 装 Python / 配 MCP / 接 Claude Desktop）。“无负担”这个目标和开源 + 命令行 + macOS-only 的实现路径之间有距离。这个距离要么靠 Vida 自己做产品化的 Einsia 之类弥补，要么留给生态里别人填。

Open Questions

• 行动层”潜规则”的工程方案 Calvin 是否藏起来不说，还是真没方案
• 7 分类本体在情绪/灵感/动机这种”内部状态”维度上的扩展计划
• AX Tree 在 Linux / Windows 上的对应物（Windows UIA 已有 PR 在仓库，未合并）
• “记忆污染”的具体定义和度量——他怎么知道哪些信号属于污染
• 跟 mem0 / OpenMemory MCP / Letta / 官方 MCP memory server 的差异化点（这些都是同期开源 memory 项目）

sources

• 记忆，是 Agent 基建｜对话 Calvin@Vida（赛博禅心，2026-04-26）