现在有不少 AI 工作台，似乎很自然地都把信息扔在了云端。
我们在 ChatGPT、Claude、Notion AI 或其它在线工具里聊天、上传文件、连接邮箱，然后期待 AI 可以慢慢理解我们的工作。
但是，当一个 AI 真正开始接触邮件、会议、项目和联系人时，另一个问题就浮现了出来：这些逐渐积累起来的工作记忆，到底属于谁？ （下图为 ChatGPT memory）
如果换一个模型、取消订阅，或者某个产品突然调整方向，AI 对我们的了解还能不能一起带走？
我个人更倾向于上下文都囤积在本地，AI 模型只是一个可选供应商的模式。我用 Codex 就是这样做的，至少理论上，就算 Codex 不存在了，换上 OpenCode 也可以继续工作，就是界面会略有不同。
但这不是全部，很多日常工作并不是完全基于本地 Codex 的，还是将大量上下文托付给了云端，确切地说是绑定了 AI 供应商。
最近在 Hacker News 和 GitHub 上火起来的 Rowboat，给出了一个很有意思的答案：AI 可以调用云端模型，也可以在本地运行，但它的长期记忆不必锁在某个厂商的数据库里，而是可以写回我们自己电脑上的 Markdown 文件。
截至我写这篇文章时，Rowboat 的 GitHub 项目已经超过 1.6 万颗 Star。它是 Y Combinator 项目，采用 Apache-2.0 许可证，支持 Windows、macOS 和 Linux。2026 年 7 月，它又以「开源、本地优先的 Claude Desktop 替代品」登上了 Hacker News 首页。
不过，我觉得如果仅仅把它说成 Claude Desktop、Codex 的替代品，反而低估了它真正有意思的地方。
Rowboat 不只是另一个 AI 聊天框
Rowboat 把自己称作一个「有工作记忆的 AI coworker」。它不是只提供一个聊天窗口，而是试图把我们日常工作中的几个主要界面放到一起，包括：
- 邮件客户端
- 会议记录
- Markdown 笔记
- 内置浏览器
- Code Mode
- 后台 Agent
- 可以自己生成的工作 App
这些界面背后共用同一个被称为 Brain 的知识层。邮件、会议、Slack 对话以及和 AI 的聊天，会被整理为人物、公司、项目和主题等节点，再通过双向链接连接起来。
最近比较火的另一个产品 Scape，也是类似的风格，将邮件收件箱、会议记录和待办事项融为一体，成为一个新的工作平台入口。
举个例子，某个客户在邮件里提出了一个改功能的要求，几天后的会议又修改了优先级。Rowboat 的目标不是把两份原始内容随便塞进什么 RAG 向量数据库，等我们下次提问时再抠字眼、做向量搜索，而是持续更新这个客户和项目对应的笔记，把当前状态、历史决定、承诺和待办事项保留下来。
下一次再让 AI 准备会议材料、起草回复或者制作路线图，它不必等我们重新解释一遍背景。
这听起来似乎只是「更强的 RAG」，但两者的重心不太一样。传统 RAG 更像临时检索：提出一个问题，系统去一堆资料里寻找可能相关的片段。Rowboat 更像让 AI 平时就整理工作，把散落的信息压缩成一批持续更新的主题笔记。前者关心「这次找到了什么」，后者更关心「关于这个人和项目，我们现在知道什么」。
当然，这也是 Rowboat 最需要经过长期检验的地方。邮件中的同名人物能不能准确合并？项目改名之后会不会产生重复节点？一封营销邮件会不会污染联系人图谱？旧信息和新信息冲突时，AI 会不会悄悄覆盖掉重要背景？
我个人觉得这是另一种形式的「记忆」，最早是纯文本存储，然后是向量化存储，现在则按照语义上下文进行整合后存储。
最有意思的是 Markdown
如果 Rowboat 只是把这些信息保存在自己的本地数据库里，我觉得它的吸引力会小很多。大家知道我最不喜欢那种封闭结构。我喜欢直接可以打开的 txt、markdown、json、html 这类，PDF 在我这里都要打个折扣了。
真正让我感兴趣的是，它把知识图谱中的节点保存为普通 Markdown 文件，并且使用类似 Obsidian 的双向链接。我们可以在 Rowboat 里浏览和修改，也可以直接把这个目录当作 Obsidian Vault 打开。
这意味着，AI 的长期记忆第一次变成了一批我们可以直接阅读的文件。
AI 要是误解了一个出现人物的身份，我们可以打开笔记直接改掉。要是项目状态过期了，我可以手工修正。要想知道它最近改了什么，可以用 Git 查看差异；想备份，可以使用 Dropbox、Syncthing、NAS 或任何习惯的工具；以后不再使用 Rowboat，这些 Markdown 文件也仍然存在。
这整个风格和我现在的其他工作流（主要是基于 Obsidian + 文件同步）非常接近了。
很多 AI 产品都在宣传「Memory」，但这些 Memory 通常更像产品内部的一种能力。我们很难完整看到 AI 记住了什么，也不知道它在什么时间修改过，更难把这些记忆交给另一个工具继续使用。
而 Markdown 把记忆从某个 App 的功能，变成了用户拥有的数据。它不保证 AI 一定记得正确，却至少允许我们检查、纠正、备份和迁移。相比一个号称无所不知、实际上完全看不见的黑盒，我反而更信任这种有点笨、但可以打开查看的方式。
工作界面，比一个万能聊天框更合理
Rowboat 最近加入的 Work Surfaces，也很符合我对 AI 工作台的理解。
邮件就应该在邮件界面里处理，会议就应该在会议界面里记录，网页研究最好发生在浏览器里，代码则应该留在代码工程和版本差异中。聊天可以用来表达意图，但没有必要承载所有的工作。
Rowboat 的邮件界面可以区分重要邮件，并结合长期上下文生成回复草稿；会议记录工具会读取电脑的麦克风和扬声器，不需要让一个机器人加入会议，结束后再把摘要和行动项写回 Markdown；内置浏览器与日常浏览器隔离，只登录我们愿意交给 Agent 操作的账号；Code Mode 则可以调用 Claude Code 或 Codex，让编码 Agent 使用会议和项目中的背景信息。
更进一步，我们还可以让它根据需求生成一个小型工作 App。比如，把邮件、会议和 Slack 里的功能要求收集起来，做成一个排序面板，再让编码 Agent 根据排在前面的需求准备实现方案。
这和单纯让 AI「帮我做个网页」不太一样。小 App 不是一次性的展示结果，而是连接在同一个工作记忆上，可以继续被后台 Agent 更新。
我一直觉得，让 AI 发生在上下文里，比在任何地方都弹出一个聊天框更加自然。Rowboat 在产品结构上好像理解了这一点。
本地优先，并不等于完全离线
不过，看到「local-first」时，还是需要保持一点警惕。
Rowboat 的 Markdown Vault 的确保存在本机，应用也不必依赖 Rowboat 自己的服务器。模型可以选择 Ollama 或 LM Studio，在电脑上本地运行；也可以使用 OpenAI、Anthropic 等托管模型。（说实话，本地运行现在还是比较吃力的，而且成本也惊人。）
但只要选择在线的 AI 模型，发送给模型的上下文仍然会离开电脑。类似地，语音转文字可以使用 Deepgram，语音输出可以使用 ElevenLabs，网页搜索可以接入 Exa，其它外部工具还可能通过 MCP 或 Composio 连接。
所以，Rowboat 更准确的说法应该是：数据的主副本和长期记忆可以放在本地，但实际计算和外部动作是否留在本地，取决于我们的配置。**我不想让人产生一切都是「本地的」的误解。
本地 Markdown 解决了数据所有权和迁移问题，却不会自动解决隐私、安全和合规问题。如果我们把整套公司邮箱交给云端模型处理，文件最后保存在本机，并不代表中间的数据从未出门。
另外，本地文件本身也需要保护。邮件、会议和联系人被整理成可读的 Markdown 后，一旦电脑或同步目录泄露，别人甚至不需要懂某种专有数据库格式就可以直接阅读。因此，备份、同步范围和账号权限，反而比以前更值得认真设置。
另外 Rowboat 虽然是开源的，但也不等于绝对安全。它只是让代码可以被检查，并不代表真的已经有人替我们完成了完整的安全审计。
评价不错，但也有争议
Rowboat 最近的热度不低，支持者最喜欢的部分也很一致：开源、模型无关、Markdown 可读，以及不必把长期记忆押在一个云端厂商身上。
我看了一圈，有人认为它塞进了邮件、浏览器、笔记和编码等太多功能，自己真正需要的只是一个安静运行、可以通过 Git 审阅结果的 Agent；也有人担心，AI 工具不断生成摘要、邮件和报告，最后不是减少工作，而是制造更多需要人阅读和验证的内容，这对用户也是一种负担。考虑到有些用户想要的是放弃自己思考的所谓「第二大脑」，自然这种需要亲力亲为的工具就不受待见。
另外，一些功能的成熟度仍然有限。目前邮件重点仍然是 Gmail，非 Google 邮箱用户并不方便；知识图谱我个人觉得很鸡肋，Obsidian 也一样，我从来不用。
还有，各位自己用了就知道了，这类工具都要自己配置的，一堆 API 配置，权限管理也远比普通笔记软件复杂。什么「开箱即用」那是做梦了，至少要有折腾复杂配置的觉悟。
Rowboat 现在更适合愿意尝试前沿 AI 工作流、能够理解模型和权限边界的个人用户或小团队。对于需要多人协作、严格合规、成熟管理后台和稳定技术支持的企业来说，它肯定不是一个可以直接全面部署的成品。
而且，如果我们的工作主要是临时问答、翻译和偶尔写一篇文章，根本没有多少跨越数周和数月的项目上下文，那么这套长期记忆系统很可能显得过重。这就是我前面说的，对我而言 Codex 以外还有很多工作其实没有本地记忆。
AI 记忆只有不断积累时才有价值。如果没有长期稳定的工作线索，知识图谱就只是一个更加复杂的空文件夹。
最后
那么我们回到开头的问题：AI 工作台一定要住在云端吗？
我的答案是：不一定。
真正需要区分的，是 AI 工作台的每一层到底放在哪里：
- 工作文件和长期记忆由谁保存？
- 模型在哪里计算？
- 外部工具通过什么权限连接？
- Agent 的操作能不能被看见和撤销？
- 换掉 App 或模型之后，数据还能不能继续使用？
未来一段时间比较现实的方案，很可能不是完全本地，也不是完全云端，而是一套「混合架构」。强大的在线模型继续负责复杂推理，而本地模型处理敏感或简单任务，用户自己的文件系统保存长期记忆。
在这样的架构里，模型是可以替换的计算资源，App 是可以替换的操作界面，Markdown 才是长期留下来的数据层。
这也是我觉得 Rowboat 最值得关注的原因。它今天未必已经是最成熟、最好用的 AI 工作台，甚至有可能因为功能铺得太开，走上一条很难维护的路。但它至少提出了一个正确的问题：
AI 可以越来越了解我们，但这种了解不应该只能存在于某个公司的云端。
效率火箭，火箭君的新博客 