当然，用于启动 OpenClaw 主模型的 OAuth 还是需要的，不过，如何发挥出 OAuth 订阅天然更高性价比的优势，对于控制成本支出，尤其是个人部署 Agent 方面，依然有一些设计可以考量
有一天我在给 OpenClaw 配第三个 API key，突然停下来想——我到底在干什么？
我已经订了 Claude Max，200 刀/月，等价于约 3000 刀的 API 用量。但我的工具链里，OpenClaw 要一个 API key，记忆系统要一个 API key，搜索工具要一个 API key。每多一个，就是一个新账号、一份新账单、一个万一哪天 API key 失效了要去排查的潜在麻烦。
我决定把这件事理清楚。
第一步：让引擎用上 OAuth
OpenClaw 是我的 AI 网关，负责把 Telegram、WebChat 这些渠道接进来，管理 skill、plugin、heartbeat 一整套体系。但它需要 API key。
解决方法是 CLIProxyAPI——一个本地跑的小代理，把 OpenAI-compatible 的调用替换为 Claude OAuth，直接用我的 Max 订阅。
Telegram / WebChat
↓
OpenClaw Gateway (:18789)
↓
CLIProxyAPI (:3456)
↓
OAuth 注入 ← OAuth，Max 订阅
brew install cliproxyapi
npm install -g openclaw
cliproxyapi # 首次跑，OAuth 登录
openclaw.json 里 baseUrl 改成 http://127.0.0.1:3456/v1，搞定。
如果你用的不是 Claude 而是 MiniMax 或 Qwen，这两个模型本身就支持 OAuth 直接接入 OpenClaw，连代理都省了。
到这一步，整个工具链里已经没有一个需要单独管理的 API key 了。
注意：在 anthropic 近期发布声明后，这类使用 oauth 验证第三方服务使用订阅模型的行为，原则上会被列入违反 tos，不过目前还未能被检测。如果希望服务稳定，可以更多使用qwen等官方支持 oauth 接入 openclaw 的模型作为日常使用，然后尝试让 openclaw 更多拉起 agent coding skill 来解决除编程之外的问题，它会拉起原生的 claude code cli 来访问订阅的anthropic账户。由于直接使用了官方途径进行访问，类似 nanoclaw，这种方式相对是安全的。
然后问题来了
助手跑起来之后大概第二周，我第四次向它解释「我们上次决定用 SQLite 是因为……」
我意识到这件事很荒唐。我已经有一个一直在线的 AI 助手了，但它每次会话都是全新的。它不记得我的偏好，不记得我们做过的决定，不记得任何项目上下文。每次都要重新建立这些背景，就像跟一个永远失忆的人合作。
自然的想法是：去找一个记忆系统。
Mem0、Letta、各种 MCP 记忆服务——全都需要 API key。
它们的逻辑我理解：判断「这件事值不值得记」需要语义理解，所以它们自己调一个 LLM 来做这件事。
但这正是让我不舒服的地方。我刚把引擎层的 API key 干掉，记忆层立刻带来了新的。更糟的是，负责做判断的是一个比我已有引擎更差的小模型——我用 Opus 做推理，用 mini 管记忆，本末倒置。
想清楚了一件事
我坐下来想：记忆系统究竟在做什么？
分开看，其实是两类工作：
代码就能做好的：把内容写入数据库、建索引、按查询意图检索、管理生命周期。这些都是确定性计算，没有歧义，算法比模型做得又快又准。
需要真正理解的：这件事值不值得记？这两条记忆之间有没有因果关系？新的信息和旧的记忆是否冲突？这些问题没有标准答案，需要语义判断。
按这个分法，答案显而易见：代码做存取，模型做判断——用我已经有的那个模型。
记忆组件本身不需要任何 LLM。它只需要把接口暴露清楚，让外部的 Claude 来调用它、督导它。这就是 LLM-Supervised 的思路：模型在管道外面，不是嵌在里面的。
我按照这个思路自己写了一个：mnemon——一个以 skill 方式接入 OpenClaw 的图记忆引擎，单 Go 二进制 + 本地 SQLite，零外部依赖，不调任何 API。
对比一下：
- Mem0 / Letta（LLM-Embedded）：记忆组件内置一个模型，自己做判断，需要独立 API key
- mnemon（LLM-Supervised）：记忆组件只管存取，判断权完全交给外部已有的引擎，零额外 API 依赖
调用方式是这样的：
Claude（通过 OpenClaw / CLIProxyAPI）
↓
mnemon recall "上次的架构决策"
↓ 返回候选
Claude 评估，决定怎么用
工作做完后：
↓
mnemon remember "决定用 SQLite，因为团队熟悉度高" --cat decision --imp 5
↓ 返回关联候选
Claude 判断是否建立因果边
模型是主体，不是被动接收内容的终端。它决定什么时候查、存什么、怎么关联——记忆系统只是它手里的工具。
这个分法还有一个好处
模型会换。Anthropic 每年出新版本，说不定明年又来一个全新的玩家。
如果记忆系统和某个特定模型耦合，每次模型升级都要重新适配、重新调参、重新测试。
但 mnemon 是纯工程的——它只管存取，不依赖任何特定模型。模型换了，记忆组件一行代码不改，多年积累的记忆数据完整保留，新模型直接接手，而且因为模型更强了，对这些记忆的利用能力也跟着提升。
这其实是 OpenClaw 的 gateway 哲学做到底：工程层和模型层完全解耦，两侧各自演进，互不干扰。
不只是 OpenClaw
我同时也把 mnemon 接进了 Claude Code，协助写代码时积累技术决策和项目上下文。跨会话的记忆让它在长期项目里越来越顺手——不用反复解释背景，它知道这个项目的取舍逻辑。
它不绑定任何特定工具。只要支持 skill 文件和 hook 注入——Gemini CLI、Qwen Coder、或者其他任何 LLM CLI——配置好 prompt 注入就能接进来。接入之后，记忆系统的所有判断都由你的主引擎来做，不引入任何新的 API key，也不改变你的模型调度策略。
你用什么引擎，记忆就用什么智能。
补上最后一块拼图：切换场景时丢失的上下文
OpenClaw 有一个很实用的能力：遇到复杂编程任务时，它会原生拉起 Claude Code CLI，让专门的编程代理去处理。
但这里有一个天然的断层。
OpenClaw 和 Claude Code 是两个独立的进程，各自维护各自的会话。当 OpenClaw 把任务交给 Claude Code 时，能传过去的只有当次的任务描述——你和 OpenClaw 之间积累的所有背景：项目选型的理由、之前踩过的坑、你偏好的代码风格、上周讨论的架构变更，这些都传不过去。
添加图片注释，不超过 140 字（可选）
结果就是：Claude Code 做出来的东西，技术上没问题，但不符合你的意图。用了你明确说过不想用的方案，或者重复了一个上周刚踩过的坑。然后你又要花时间解释、返工。
mnemon 补上了这个断层。
因为它的存储层是统一的本地 SQLite——和上层的引擎完全无关——OpenClaw 写入的记忆，Claude Code 可以直接读取。
添加图片注释，不超过 140 字（可选）
现在的流程变了：
添加图片注释，不超过 140 字（可选）
这不是刻意设计的功能，而是架构选择的自然结果。当记忆层是纯工程组件、不绑定任何特定引擎时，它天然就能被所有引擎共享。OpenClaw 用它，Claude Code 用它，换成 Gemini CLI 或者其他任何支持 skill 注入的工具，记忆依然在那里。
更有意思的是反向流动：Claude Code 在编码过程中积累的踩坑记录和技术细节，也会写回 mnemon。下次你在 OpenClaw 里讨论项目时，这些代码层面的上下文也能被检索到。记忆在两个工具之间双向流通，越用越厚。
现在的状态
整个工具链是这样的：
Telegram / WebChat / TUI ...
↓
OpenClaw Gateway / LLM CLI / ...
↓
CLIProxyAPI / OAuth 大模型
↓
mnemon（本地 SQLite，零 API 依赖）
接入只需要两步：
# OpenClaw
brew install mnemon-dev/tap/mnemon
mnemon setup --target openclaw --yes
# Claude Code
mnemon setup
我自己跑了一段时间，记忆图里现在有 87 条 insight、2150 条边。最明显的变化是：我不再需要每次会话都重新建立背景了。
现在是 v0.1.1，还早期。如果你也在用 OpenClaw 或者 Claude Code，欢迎试试。如果觉得有用，请给个Star🌟支持。
GitHub：github.com/mnemon-dev/…
