前言
你和 ChatGPT 聊了两个小时，终于把一个问题理清楚了。
关掉窗口，满意地去睡觉。
有一天突然想起找回来。滚动历史列表，全是自动生成的模糊标题。
搜关键词，答非所问。
半小时后，你放弃了——那段灵光，就这样消失在几百条对话的海里。
这不是最糟的。
更糟的是：账号被封了（点名 A 社）—— 那些沉淀了你大量的对话，永远消失了。
我是多 AI 重度用户。
ChatGPT、Claude、Gemini、DeepSeek，同时开好几个，重要问题会交叉验证。
这个工作流有个越来越明显的摩擦：对话数据散落在各家公司的服务器上，我没有副本，没有索引，没有导出。
为了解决这个问题，我做了两个工具。
第一个叫 anyChat，是一个 7MB 的多 AI 聚合壳——把所有 AI 网页装进一个窗口里，键盘切换，干净利落。它解决的是"切换"的问题。
第二个叫 AmberKeeper，是一个会"记住"的壳——在你正常聊天的同时，静默地把每一轮对话落到你自己的电脑上。它解决的是"留住"的问题。
它们不是替代关系，是互补的。
一、anyChat：7MB 的壳
anyChat 是我在 2025 年做的第一个工具，基于 Tauri 2 + React 19，macOS 安装包只有 7MB。
当时频繁使用各家模型，当时频繁使用各家模型，日常的工作和学习已经离不开它们了。
为什么做这个
在浏览器里同时用多个 AI 不是很方便：
一堆标签页都开着，来回切换不方便：GPT 作为常规使用，gemini 生图，国内一些模型翻译和 OCR 还有其他等等
我需要一个独立的、干净的入口，把所有 AI 聚在一起，低干扰。
为什么是 Tauri
当时也考虑过 Electron，但 Electron 必须打包一个完整的 Chromium 内核，安装包 80-150MB，启动也慢。
我这时的想法是方便使用、追求轻量、低内存占用，不满足这些条件，那就和在浏览器中使用也没区别了。
Tauri 的思路不同——它用操作系统自带的 WebView（macOS 上是 WKWebView，Windows 上是 WebView2），只打包前端代码和一个小的 Rust 宿主程序，结果就是 7MB。代价是：你没有"自己的浏览器内核"，只能依赖系统 WebView 的能力。但对这个需求来说，完全够用。
iframe 为什么不行
直觉上，嵌入 AI 网页用 iframe 不就行了？
不行。
各家 AI 站点都设置了 X-Frame-Options: SAMEORIGIN 或 CSP 安全策略，iframe 嵌入会被浏览器直接拒绝。
正确的方式是原生多 WebView：在主窗口内创建多个独立的 WebView 实例，每个加载一个 AI 站点，通过显示/隐藏来模拟标签页。每个实例有独立的 session，登录态互不干扰。
它的边界
anyChat 现在支持 12 个内建 AI 服务，用户也可以自定义添加。我自己用了将近半年，日常多 AI 切换完全满足。
但它有一个做不到的事情：它记不住你的对话。聊天结束，对话就留在那家公司的服务器上了。
这个"记不住"，用了几个月之后，从痒变成了痛。
二、从壳到记忆：痛点的演变
痛点具体有四个：
散落。
ChatGPT 的历史在 ChatGPT，Claude 的历史在 Claude。想找一个话题之前和哪个 AI 聊过，只能逐个去翻。
脆弱。
OpenAI 封号不是新鲜事，几百小时的对话史一夜清零。产品停服、被收购、下线——你的数据怎么办？
不可带走。
各家对数据导出的支持参差不齐，即便有也是一次性手动操作，不是持续备份。
沉没的价值。
和 AI 的深聊不是消遣，是你真实的思考过程——你提出的问题、推翻的假设、最终的结论。这些东西是你的，但你拿不走。
我想到的解法：在聊天的同时，把每一轮对话实时、静默、自动地落到本地。用户体验不变，照常在官方网页聊，但数据同步沉淀在自己的电脑上。
然后我去 anyChat 里试了试。
三、Tauri 上能做到吗？
试过，放弃了。
Tauri 的系统 WebView 没有 Electron 那样的请求拦截 API，也没有 Chrome DevTools Protocol（CDP）这种调试器级别的能力，你能做的只有在页面里注入 JavaScript。
我试过注入 fetch hook 拦截网络请求，但 AI 站点的 CSP 和同源策略处处设防。方案越做越复杂——注入脚本、本地 HTTP 中继、自定义协议接收器——每一段都是临时补丁，整体维护成本极高。而且各家 AI 站点的前端一改，采集逻辑就可能失效。
结论很清晰：Tauri 缺一个稳定的"响应体级请求拦截"能力。 系统 WebView 没有提供这个原语，靠注入 JS 补不了。
要么接受这个边界，要么换工具。
我选了换工具。
anyChat 回归了它本来的定位——一个轻量、干净的多 AI 切换壳。
四、AmberKeeper：会记住的壳
AmberKeeper 是独立于 anyChat 的 Electron 应用。
不夸 Electron——安装包 80-150MB，比 anyChat 大了 20 倍。接受这个代价，是因为 Electron 给了两个 Tauri 给不了的能力：
- WebContentsView：基于完整 Chromium 内核的多实例嵌入
- CDP（Chrome DevTools Protocol）：调试器级别的网络拦截
CDP 才是关键
这里值得多说几句，因为这是 AmberKeeper 在技术上最核心的设计决策。
浏览器开发者工具里的网络面板，背后就是 CDP。
它能看到浏览器发出的每一个请求、收到的每一个响应——包括完整的响应体。
Electron 提供了 webContents.debugger.attach API，允许程序直接 attach 到某个页面的调试器上，监听这些事件。
关键在于：CDP 是浏览器内核层的能力，完全不受页面 CSP 的限制。 页面的 CSP 是告诉"这个页面能加载什么资源"，不是告诉"调试器能看什么"。调试器有更高的权限层级。
用一个类比：CSP 相当于房间的窗帘——它能挡住外面人的视线，但挡不住持有钥匙的管理员。
CDP 就是那把钥匙。
这意味着：不需要在页面里注入任何 hook，不需要绕任何 CSP，不会随 AI 站点的前端改动而失效。只要它的 API 接口没变，采集就一直有效。
多 WebView 架构
每个 AI 对应一个独立的 WebContentsView，各自有独立的 session partition（可以理解为独立的 cookie 空间）。
ChatGPT 的登录态不会和 Claude 相互影响。
partition 的命名沿用了 anyChat 的旧格式——从 anyChat 迁移过来的用户不需要重新登录每个 AI 站点，登录态自动继承。
切换 AI 时不会销毁和重建 view，保证了快捷的即时切换。
数据落库
捕获到的对话最终落到本地 SQLite，三层结构：
- 业务层：对话元数据 + 每条消息，基于内容哈希自动去重
- 证据层：原始事件 payload，用于调试和回放——如果某个 AI 站点的适配有 bug，可以用历史数据在本地重跑解析
- 诊断层：记录每次采集尝试的结果，包括失败的——这样你能知道"这段对话没被采集到，是为什么"
数据导出支持 JSON（程序处理）和 Markdown（阅读检索）两种格式。
AmberKeeper 没有云同步，也没有计划做。 这是 local-first 的刻意选择——你的对话在你自己的硬盘上，不在任何人的服务器上。
9 个 AI，9 个独立适配
AmberKeeper 内建支持 9 个 AI 站点，每个站点对应一个独立的适配包——只负责一件事：把这个 AI 的网络数据翻译成统一的对话格式。它不碰 Electron，不碰数据库，只做翻译。
好处是隔离。ChatGPT 改了接口，只更新 ChatGPT 的包，其他 8 个完全不受影响。
后续如果考虑新增其他模型 chat，也是非常方便，只需要适配该 chat 的 provider 即可。
五、一个窗口，还是一个记忆
它们不是替代关系，是互补的。
| anyChat | AmberKeeper | |
|---|---|---|
| 定位 | 多 AI 聚合壳 | 多 AI 聚合 + 数据采集 |
| 体积 | ~7MB | 80-150MB |
| 框架 | Tauri | Electron |
| 数据采集 | 无 | 有，本地 SQLite |
| 适合谁 | 只想在一个窗口切 AI 的人 | 想把对话留在自己手里的人 |
什么时候用 anyChat？ 你只是想在一个窗口里切换几个 AI 网站，不需要数据采集，那 7MB 的壳就是正确选择。
什么时候用 AmberKeeper？ 你和 AI 的对话里有值得沉淀的东西——思考过程、决策记录、灵感火花——你希望它们留在自己手里，那 20 倍的体积代价是值得的。
结语
Amber 是树脂的结晶。一滴松脂落下，裹住一片叶子，在地底沉睡千万年，挖出来时依然晶莹剔透。
Keeper 是留存的人，守住那些本来会流走的东西。
我们和 AI 的每次深聊，本来都会随风消散。这个工具想做的，就是像松脂落下一样，静静地，把它们封住。
项目地址
欢迎 Star 和反馈。如果你想试试，这里是入口：
