从鸭哥的洞察说起
2026 年 3 月，鸭哥（grapeot）发了一篇文章，用一个实验证明了一件反直觉的事：决定 AI 产出质量的不是模型智能，而是 context。
两个人用了同级别的模型、同样的工具、同样的 prompt 做同一个调研。唯一的区别是背后的 context——一个有一年积累的判断框架，一个没有。结果一个输出了 checklist（正确但没用），一个输出了 insight（有立场的判断）。
他把这个称为 consensus 天花板：LLM 被训练的方式决定了它的默认输出是共识。换更好的模型、改更复杂的 prompt 都无法突破——你需要用足够密度的个人认知 context 压过训练时的 consensus prior。
鸭哥随后开源了一套 context infrastructure 系统，包含三层记忆（观察 → 反思 → 公理）、skill 库、和按需加载机制。这套系统运行了一年，积累了 43 条判断公理。
我尝试复现这套系统时，撞上了一个他没有遇到的问题。
光谱：同一个大脑，不同的身体
鸭哥的工作流是以 Claude Code（以及 OpenCode）为中心的——思考和执行都在终端里完成。但我不是。我更习惯在 claude.ai 的聊天界面里思考和反思，而把 Claude Code 当做执行工具。
这就引出了一个被忽略的事实：claude.ai 和 Claude Code 虽然用的是同一个 Opus 4.6，但它们是完全不同的 agent。
差异不在模型权重，在 scaffold（脚手架）。SWE-Bench Pro 的数据很说明问题：同一个模型在不同 scaffold 下的表现差异可达 22 个百分点，而不同模型之间的差异在前沿水平只有约 1 个百分点。Scaffold 比模型重要一个数量级。
具体来说，claude.ai 和 Claude Code 的 scaffold 优化方向完全不同：
三者位于同一光谱的不同位置，但互相隔离，没有共享状态
左端是 claude.ai——对话质量最好，有跨 session 的 memory 系统，擅长反思、蒸馏、push back。但它碰不到你的本地文件系统。它的 memory 停在事实层（"你住在 Bay Area""你在做 GTM"），达不到鸭哥说的判断原则层。
右端是 Claude Code——执行能力最强，有 CLAUDE.md 层级、auto memory、auto dream。但它的对话深度不够，不适合做深度反思和认知蒸馏。它的 auto memory 停在操作层（"build command 是 pnpm""测试在 __tests__/ 下"）。
中间是深度记忆——鸭哥说的判断原则层。"评估技术方案时怎么权衡可维护性和性能""面对不确定性时你倾向于先行动还是先分析"。这些两边都做不到，也没有归属。
这就是 核心问题：聊天入口、深度记忆、执行层——三者割裂，没有共享状态。你跟 claude.ai 说的它记得，但 Claude Code 不知道。Claude Code 积累的操作经验，claude.ai 看不到。而真正有价值的判断原则，夹在两者之间无处安放。
试过的死路
在找到解法之前，我试了几条路。每条都有各自的理由走不通：
MCP：唯一的双向通道
MCP（Model Context Protocol）是 Anthropic 推出的开放协议，让 AI 能调用外部工具和数据源。claude.ai 支持添加自定义的远程 MCP server 作为 connector。关键是：MCP tool call 天然支持双向操作——读和写都是 tool 调用。
方案很简单：在本地跑一个 MCP server，通过 Cloudflare Tunnel 暴露到公网，加到 claude.ai 的 connectors 里。
MCP server 暴露五个 tools：读文件、写文件、追加文件、列目录、执行 bash 命令。这意味着 claude.ai 不只是能读写记忆文件——它能操作你本地的一切。
安全模型
认证不用 OAuth（太复杂），用 URL secret path：在 URL 路径里嵌入一个 43+ 位的随机字符串。不知道完整路径就调不通，暴力扫描的组合数约 10⁷⁷——跟猜中一个原子差不多。
额外的物理安全层：电脑关了，Cloudflare Tunnel 就断了。不用的时候天然不可访问。
持久化
用 Cloudflare Named Tunnel 而不是临时 tunnel——URL 固定不变，claude.ai connector 配一次永远不改。macOS launchd 管理进程，开机自启、挂了自重启。网络切换时 cloudflared 自动重连。
最终架构
claude.ai 是大脑——负责思考、对话、蒸馏判断原则。MCP Server + Cloudflare Tunnel 是神经——把远程的大脑和本地的双手连起来。本地文件系统是共享认知底座——两个 agent 都能读写。Claude Code 是双手——负责执行、编码、构建。
两个 Agent 的分工
| claude.ai | Claude Code | |
|---|---|---|
| 擅长 | 对话、反思、蒸馏、判断 | 执行、编码、文件操作、调试 |
| 记忆系统 | 跨 session memory + memory edit | CLAUDE.md + auto memory + auto dream |
| 记忆维度 | 认知层（判断原则、偏好、模式） | 操作层（架构偏好、代码规范、工具链） |
| 共享状态 | 通过 MCP 读写 memory/ 目录 | 直接读写 memory/ 目录 |
这比单一记忆系统更强。两个 agent 各自在自己擅长的维度积累 context，通过共享文件层同步关键认知。
大脑指挥双手：tmux 模式
MCP 打通了读写管道，但 run_command 有 120 秒超时限制。简单的 bash 命令没问题，复杂任务（部署、重构、多步骤工作流）会超时。
解法是通过 tmux 启动一个持久的 Claude Code 交互 session。claude.ai 用 tmux send-keys 发指令，用 tmux capture-pane 读输出，异步监控进度。不受超时限制，Claude Code 可以自主处理错误（比如 git conflict）并持续推进。
这意味着 claude.ai 可以在对话中直接完成这样的操作链：启动 tmux session，打开 Claude Code，发送任务，每 15 秒检查进度，Claude Code 遇到 merge conflict 自行解决，部署完成，返回 URL。全程你只需要在聊天里说一句话。
| 模式 | 适用场景 | 超时 |
|---|---|---|
| run_command | 简单 bash（ls, cat, git status） | 120s |
| claude -p | 中等复杂度、一次完成的任务 | 120s |
| tmux 持久 session | 复杂多步骤、需要错误处理的任务 | 无限制 |
这是大脑指挥双手的完整形态：你在 claude.ai 里说一句话，claude.ai 通过 MCP 调度 Claude Code 去执行一切。你不需要打开终端、不需要切换工具、不需要手动同步。聊天就是唯一的入口。
记忆系统：从观察到公理
记忆系统的设计直接采用鸭哥的三层蒸馏模型（详见他的开源实现）：
L1 Observer（日常观察）→ 对话中识别有意义的观察，追加到 observations.md
L2 Reflector（定期整理）→ 每 2-3 周扫描 observations，合并重复，识别跨场景的稳定模式
L3 Axiom（判断原则）→ 从稳定模式中蒸馏决策原则，写入 axioms.md
蒸馏的标准是 稳定性——一个判断如果跨场景、跨时间反复出现并保持一致，它大概率是你认知结构的一部分。不稳定的是情境反应，稳定的才是你自己。
区别在于蒸馏引擎：鸭哥用 Python 脚本 + cron 自动化执行。本系统用 claude.ai 本身作为蒸馏引擎——在对话中主动识别、提炼、写入。你只需要在它提出"这条值得落盘"时说一个字："好"。
诚实的部分：触发不是确定性的
管道搭通了，记忆模型设计好了。但有一个必须正面承认的事实：让 claude.ai 记得使用这套系统，完全依赖软指令，没有任何一层能保证 100% 执行。
claude.ai 的工具机制（什么时候加载 MCP、什么时候调用 tool）是 Anthropic 平台层定义的。你不能给 MCP 加 "auto-load on session start" 的 hook，不能修改工具的触发逻辑。你能做的只是通过文本指令告诉 Claude "记得做这件事"——它可能记得，也可能忘了。
目前的触发机制有两层：
Skill（主力）
claude.ai 原生的 Skill 系统。创建一个 context-memory skill，description 里写清楚触发条件——故意写得很激进，几乎所有非闲聊话题都匹配。Skill 被触发后，文件里详细写了每一步：先加载 MCP tools，然后拉取 memory，然后在对话中识别落盘时机。这是触发率最高的一层。
Memory Edit（兜底）
claude.ai 的 memory_user_edits——一个跨所有对话自动注入的持久记事本。在里面写一条规则："对话涉及工作/决策时，先加载 Wayne MCP"。每次对话 Claude 都会看到这条文本——但"看到"不等于"一定执行"。它是一个软指令，跟你跟同事说"记得每天早上先看邮件"一样。
人肉兜底
如果重要对话发现 Claude 没有自动加载 MCP，说一句"先加载记忆"。四个字，最后一道防线。
这三层全是概率性的，不是确定性的。优化方向是堆冗余 + 降低每层失败率，而不是追求完美自动化。随着 Anthropic 平台迭代（未来可能支持 MCP auto-load 或硬性触发规则），这个问题会逐步改善。但现在，接受它。
值得注意的是，Claude Code 侧没有这个问题。Claude Code 的 CLAUDE.md 每次 session 自动加载——这是它的原生机制，不是软指令。所以 Claude Code 读取 memory 文件是高度可靠的，不确定性只存在于 claude.ai 这一端。
跟鸭哥的关系
| 鸭哥的系统 | 本系统 | |
|---|---|---|
| 解决的问题 | Context 怎么积累和蒸馏 | Context 怎么在割裂的工具间流动 |
| 聊天入口 | Claude Code / OpenCode（终端） | claude.ai（网页，对话质量更高） |
| 蒸馏引擎 | Python 脚本 + cron | claude.ai 对话中主动触发 |
| 连接方式 | 全在本地，无需桥接 | MCP + Cloudflare Tunnel 桥接远程和本地 |
| 维护成本 | 需要 cron + 脚本维护 | 几乎零维护，claude.ai 主动驱动 |
| 适合谁 | 有开发经验，习惯终端 | 偏好聊天界面，不想碰终端 |
两个系统不是替代关系。鸭哥解决了 "context 怎么积累"——三层蒸馏模型、稳定性筛选标准、axiom 和 skill 的结构。这是认知基础设施的理论基础，本系统完全采用。
本系统解决的是 "context 怎么在割裂的工具间流动"——当你的思考发生在 claude.ai、记忆存储在本地文件、执行发生在 Claude Code 时，怎么让它们共享同一个认知底座。
开始搭建
整套系统打包成了一个 claude.ai Skill（context-memory），包含：
SKILL.md（日常使用）：claude.ai 端的完整运行流程（加载 MCP → 拉取 memory → 识别落盘 → reflector）、Claude Code 端的触发行为和协作规则、两端分工对比、记忆系统的三层蒸馏模型。
references/setup.md（一次性配置）：MCP Server 搭建、Cloudflare Named Tunnel、macOS launchd 持久化、CLAUDE.md 配置、claude.ai connector 和 memory edit 设置。
记忆系统的理论基础直接采用鸭哥的三层蒸馏模型，详见他的文章和开源实现。
AI 变得更聪明，并不自动让它变得更深刻。更聪明的共识依然是共识。突破天花板的路径只有一条：注入非共识的视角——你的。