你以为「AI第二大脑」就是让模型帮你记笔记、写摘要，其实那只解决了最不重要的10%。真正难的是：在混乱的邮件、会议和文档里，持续追踪谁答应了什么、什么时候改了口、现在到底算不算爽约。大部分工具都停在「好看却不好用」的维基阶段，而Rowboat试图把这件事做完整——而且全部在你自己的电脑上完成。
Karpathy 的 LLM Wiki 把原始资料整理成一个持久的 Markdown 维基，带有反向链接和交叉引用。LLM 负责读论文、抽概念、写成百科式条目，再维护索引。知识只编译一次，之后增量更新，查询时模型不必每次从零推理上下文。研究场景里，这种模式非常优雅，因为概念及其关系相对稳定，不会每天翻天覆地变化。
一旦落到真实工作场景，问题就暴露出来了。项目的上下文在对话中不断演变：一个截止日期在这封邮件里敲定，在另一封邮件里被悄悄推迟，Slack 里又有人说「先按原计划走」。维基也许有一页叫「项目 X」，但它不会自动跟踪这些细碎又关键的状态变化，更不会告诉你「团队口头上默认的日期」和「最新邮件里的日期」已经不一致。结果就是：维基看起来很完整，现实却一团糟。
有用户反馈，他们团队在一个融资项目上，光是「到底谁答应在什么时候发材料」这个问题，就在三条不同邮件线程里出现了四个版本，没人说得清哪一个才算数。
我们之前写过一篇关于「为什么维基追不上现实工作流」的文章，Karpathy 也转发表示认同。那篇文章的核心观点是：要追踪真实世界的承诺和状态，靠摘要页面远远不够，需要的是一种更接近数据库和图结构的东西。不是「项目 X 的介绍页」，而是「每一个决策、每一次承诺、每一个截止日期」都作为独立节点存在，并且跨对话、跨工具互相连起来。
从维基到知识图谱：第二大脑的结构升级
维基为什么追不上你的真实工作
传统的 LLM+维基模式，本质上是「摘要引擎」：把一堆原始材料压缩成一页页主题页面。研究型工作里，这很有用，因为你关心的是「这篇论文讲了什么」「这个概念和哪些概念相关」。但在项目推进里，你更关心的是「谁在什么时候答应了什么」「后来有没有改」「现在的状态到底是啥」。
维基页面「项目 X」会给你一个看起来很完整的故事，却很难精确回答「上周三那次电话里，客户有没有明确说要在月底前签字」。而且，一旦团队成员在不同渠道里做了相互矛盾的更新，维基不会自动帮你发现冲突。说实话，这也是我自己踩过的坑：看着维基以为一切按计划推进，结果客户在一封我没看到的邮件里早就改了时间。
据一份 2024 年的远程协作调查显示，超过 62% 的团队承认「关键决策散落在不同聊天和邮件里，事后很难完整还原」。
所以，问题不在于「有没有好用的笔记工具」，而在于数据结构本身不适合追踪状态。维基擅长讲故事，却不擅长记账。你需要的是一个能像会计账本那样严谨记录「谁、在什么时候、做了什么决定」的系统，而不是一篇篇「项目回顾」。
知识图谱：把人、决策和承诺拆成节点
要解决这个问题，Rowboat 采用的是知识图谱思路：不是写一页「项目 X 总结」，而是把人、组织、项目、会议、决策、承诺、截止日期都拆成独立实体。每个实体是一个 Markdown 文件，通过反向链接和元数据互相连接。
Rowboat 的开源实现（GitHub 上 13k+ 星标）基于 Karpathy 的 Markdown + Obsidian 模式，但把它扩展到了真实工作流：从 Gmail、Granola、Fireflies 等来源摄取对话，不是生成一页「会议摘要」，而是把每个决策、每个行动项、每个截止日期拆出来，单独存成 Markdown 文件，并自动挂上相关人员和项目的反向链接。这样一来，你问「这个季度 Sarah 承诺了什么」时，模型查的是一串结构化节点，而不是在一堆长篇摘要里瞎翻。
如果用一句话对比：
- 维基页面「项目 X」：告诉你大家大概聊了什么、目标是什么。
- 知识图谱「项目 X」：告诉你每个决策是谁拍板的、每个承诺的原话是什么、什么时候改过、现在状态是 open 还是 done。
我也不太确定这个比喻是不是完美，但可以把维基想成「项目宣传册」，知识图谱更像「项目台账」。前者好看，后者能救命。
从零搭建本地 Rowboat：模型与数据接入
安装与模型配置：让LLM先懂你的世界
Rowboat 是一款本地桌面应用，支持 Mac、Windows、Linux，所有逻辑都在你的机器上跑。你可以接入 Ollama、LM Studio，或者任何提供 API 的托管模型服务。所有内容都以纯 Markdown 文件形式存储在 ~/.rowboat/ 目录下，天然兼容 Obsidian。如果你本来就在用 Obsidian 做笔记，可以直接指向同一个库，把 Rowboat 生成的知识图谱和你自己的笔记混在一起浏览。
即便你不用 Obsidian，这些 Markdown 文件也能被任何编辑器打开。安装步骤很直接：
- 访问下载页面：rowboatlabs.com/downloads
- 根据系统下载对应安装包
- 安装后启动应用
接下来，打开 ~/.rowboat/config/models.json，指向你要用的模型。比如托管服务：
{ "provider": { "flavor": "openai", "apiKey": "sk-..." }, "model": "gpt-4o" }
Anthropic、Google、OpenRouter 等都用同样结构，只要改 flavor 即可。如果你想完全本地推理，用 Ollama：
{ "provider": { "flavor": "ollama", "baseURL": "http://localhost:11434" }, "model": "llama3.2" }
你也可以在 UI 里通过「设置 → 模型」配置各家 API Key。界面会引导你选择默认模型和备选模型。
连接好模型后，Rowboat 会自动用一段系统提示把它「包起来」，让 LLM 先理解你的知识图谱结构。模型知道 knowledge/ 目录的存在，理解实体类型（人员、项目、组织、主题），会沿着反向链接遍历相关笔记，并在回答前优先读取 Today.md 获取当天上下文。换句话说，你不是在和一个「空白聊天机器人」对话，而是在和一个已经熟悉你工作现场的助手说话。
接入 Gmail、日历和会议：让图谱有真实信号
要让 Rowboat 真正有用，你需要给它接入真实数据源。核心是一个 Google Cloud 项目和 OAuth 凭据，让 Rowboat 能从你的电脑直接调用 Gmail、Calendar 和 Drive。完整流程在 GitHub 仓库里的 google-setup.md，大致步骤是：
- 在 console.cloud.google.com 创建一个项目
- 启用 Gmail、Calendar、Drive API
- 配置 OAuth 同意屏幕（测试模式就够用）
- 把你的邮箱加到测试用户里
- 创建 OAuth 客户端 ID（类型选 Web 应用）
- 把重定向 URI 设为
http://localhost:8080/oauth/callback - Rowboat 提示时，粘贴客户端 ID 和密钥
连接完成后，Rowboat 会启动第一次同步，开始构建图谱。如果你用 Fireflies 或 Granola 记录会议，可以在本地配置 API Key：
// ~/.rowboat/config/fireflies.json # Fireflies 会议记录
{ "apiKey": "" }
// ~/.rowboat/config/granola.json # Granola 会议笔记
{ "apiKey": "" }
会议记录会自动导入到 Meetings/ 文件夹，Rowboat 会从中提取决策和行动项，挂到对应的项目和人物节点下。除此之外，你还可以按需接入：
~/.rowboat/config/deepgram.json：语音输入和语音笔记~/.rowboat/config/elevenlabs.json：语音输出合成~/.rowboat/config/exa-search.json：通过 Exa 做网络调研~/.rowboat/config/composio.json：外部工具调用~/.rowboat/config/mcp.json：其他 MCP 工具
等首次同步跑完，你就可以开始查询图谱了。
磁盘上的第二大脑：Rowboat 文件结构
~/.rowboat：一个可见、可控的AI大脑
同步完成后，~/.rowboat/ 目录就「活」起来了。你可以直接用文件管理器或编辑器打开它，看到这个 AI 第二大脑的全部内部结构。
常见子目录包括：
config/：所有 API 密钥和模型配置gmail_sync/、calendar_sync/：原始同步数据，等待处理进图谱events/：后台代理活动日志，分done/和pending/sites/：可通过http://localhost:3210/sites//提供服务，把任意笔记嵌成实时页面logs/、runs/：操作历史和代理运行记录
更有意思的是 knowledge/ 文件夹，这里才是你的第二大脑真正落地的地方。
它大致包含：
Agent Notes/：Rowboat 自己的「记忆层」，根据你的行为和写作模式逐步生成Meetings/：Fireflies 或 Granola 处理过的会议记录，附带提取出的决策和行动项Notes/：你手动写的 Markdown 笔记Today.md：Rowboat 回答任何问题前必读的入口文件，聚合近期邮件、会议笔记和草稿
除此之外，还有：
People/：人物实体Organizations/：组织实体Projects/：项目实体Topics/：主题实体
这些文件夹一开始是空的，随着信号积累才会逐渐填充。Rowboat 的代理只有在邮件、会议和决策中看到足够证据时，才会创建一个实体文件。这是刻意设计，用来避免垃圾邮件、营销邮件之类的噪声过早污染图谱。
Rowboat 查询时不会把整个知识库一股脑塞给模型，而是先读 Today.md，再按需拉取与你问题相关的实体文件。哪怕图谱扩展到几百上千条笔记，查询成本也比较稳定。这一点在实际使用中非常关键——有用户反馈，自己手动维护的 Obsidian 库一旦超过几千条笔记，传统 RAG 检索就开始明显变慢，而 Rowboat 这种「按实体精确拉取」的方式要轻盈很多。
用自然语言驱动第二大脑：查询与自动更新
典型查询：从「帮我准备会议」开始
同步完成后，你可以直接用自然语言和 Rowboat 对话。比如输入：
Prep me for my 2pm meeting with Sarah Chen
Rowboat 会给出一份结构化的会前简报：
底层发生的事情是：代理遍历了 Sarah 这个实体节点及其所有反向链接：
- 她的职位和公司来自邮件签名和会议参与者列表
- 你们的互动历史由日历事件和邮件线程重建
- 未完成事项从过去会议记录中提取
- 推荐讨论要点则来自图谱中与她相关的项目和主题
简报里的 [[entity]] 引用都是可点击的实时反向链接：
点进去就能看到完整的实体节点，任何账户、人物或项目的额外上下文都只隔一跳。和传统「在邮箱里翻历史记录」相比，这种体验差别非常明显——一位朋友用了一周之后说，自己终于不用在会议前花十几分钟翻邮件找「上次说到哪了」。
另一个常用查询是：
Create a voice summary of my day ahead
Rowboat 会：
- 从日历拉取当天会议
- 收集与会者的上下文
- 根据你的优先级生成一份口播脚本
- 调用语音服务生成 MP3 音频
语音部分需要前面提到的 ElevenLabs 或 Deepgram 集成，配置好 API Key 后就能直接用。
实时笔记与定时代理：让图谱自己长大
如果你想让某个笔记自动保持最新，只要在笔记里标记 @rowboat，它就会变成一条「实时笔记」。Rowboat 会持续监听相关邮件、会议和文档更新，把新的上下文写回这条笔记。比如你在多次对话中跟踪一个交易或大客户账户，这条笔记会自动补充最新进展，而不需要你手动复制粘贴。
你还可以启动定时运行的代理任务，让它在后台周期性执行一些工作：
- 每天早上 8 点生成「今日简报」写入
Today.md - 每周五整理「本周关键决策清单」
- 每次有新会议记录时自动提取行动项并分配到对应项目
这些代理独立于即时查询运行，你可以精细控制它们的触发时间、读取范围和写回策略。风险点也要说清楚：如果你一口气开了太多自动任务，又不给它们设好边界，知识库可能会被「过度热心」的代理写满噪声信息，后期清理会比较麻烦。
知识图谱的时间维度：从一次性记录到持续追踪
一个具体案例：Sarah 的承诺是如何被追踪的
想象这样一个场景：三周前，Sarah 参加了一次 B 轮融资的介绍电话。那次会议结束后，Rowboat 在图谱里建立了一个「Sarah Chen」节点，并挂上了「参与 B 轮介绍电话」这条活动记录。三周后，她发来一封邮件，反馈条款细节。Rowboat 不会新建一个「Sarah Chen 2」文件，而是把这封邮件解析成一条新的活动，附加到同一个节点上。
到了第二个月，你问：「What has Sarah committed to this quarter?」代理会遍历她所有交互的相关上下文，而不是在几十封邮件里逐条搜索。更妙的是，如果你在第一周就为这笔交易创建了一条实时笔记，后续所有相关更新都会自动汇总进去，你不需要再手动维护「项目进展」文档。
这就是 Rowboat 和 Karpathy 式维基的结构性差异：维基把概念编译成页面，适合做「知识百科」；知识图谱跨对话追踪状态，适合做「现实世界的状态机」。Rowboat 把 Karpathy 描述的「累积知识库」模式，延伸成一个能跟上日常工作节奏的实用工具。
隐私与控制：真正属于你的第二大脑
Rowboat 把所有内容都以纯 Markdown 形式存储在 ~/.rowboat/，没有任何专有格式锁定。模型调用则发送到你在 models.json 里指定的位置：
- 如果用 Ollama，整个流程都在你的硬件上完成，不出本机。
- 如果用托管 API Key，提示会直接发给对应提供商，遵循你和那家服务的条款。
Rowboat 本身不代理、不中转模型调用。Gmail、Calendar、Drive 的 OAuth 凭据保存在 ~/.rowboat/config/，调用 Google API 也是从你的机器直接发起，所有集成都遵循同样架构：本地调用，输出写入本地知识库。项目采用 Apache-2.0 许可证，开源透明，你可以随时审查或二次开发。
当然，这套系统也不是没有代价：
- 初次配置 Google 项目和各类 API Key 需要一点耐心
- 本地模型推理对硬件有要求，老机器可能会吃力
- 图谱越大，越需要你有意识地设计命名和结构，否则会变成「更高级的杂乱」
但对那些每天被邮件和会议淹没的人来说，这点投入往往是值得的。有用户分享，他在接入 Rowboat 三周后，能明显感觉到「脑子里要记的东西变少了」，更多精力可以放在真正需要思考的决策上。
GitHub 仓库地址：github.com/rowboatlabs/rowboat
如果你打算认真搭一套自己的第二大脑，这个项目值得你点开、Fork、甚至贡献一两个 PR。
在你下一次被一堆邮件和会议追着跑之前，把这套搭建方法先收进工具箱。等真的需要的时候，它会比问十个同事「上次谁说了啥」更靠谱。
常见问题
Q：Rowboat 会不会把我的邮件和文档上传到第三方服务器？
A：默认情况下，Rowboat 不会把你的邮件和文档上传到它自己的服务器，所有数据都存放在本地的 ~/.rowboat/ 目录中。唯一可能出站的是你配置的 LLM 提示：如果你使用 OpenAI、Anthropic 等托管模型，相关上下文会按提示的一部分发送给这些服务。判断依据是：模型调用的目标地址完全由 models.json 决定，Rowboat 不中转、不代理。操作建议是：如果你对隐私极度敏感，可以优先使用 Ollama 等本地模型；如果必须用云端模型，建议在模型侧关闭训练数据采集，并避免在查询中包含极度敏感的原文内容。
Q：硬件配置一般的电脑能顺畅跑 Rowboat 吗？
A：Rowboat 本身对硬件要求不高，关键在于你选择的模型。如果用云端模型（如 gpt-4o），本地只负责组织上下文和存储 Markdown，普通办公本就足够；如果用本地大模型，显卡显存和内存就会成为瓶颈。判断标准是：看你平时跑 Ollama 或 LM Studio 的体验，如果推理延迟在可接受范围内，Rowboat 叠加的开销不会太大。建议做法是：先用云端模型验证工作流是否适合自己，再根据需要逐步迁移到本地模型，或者选择参数量更小、推理更快的模型版本。
Q：知识图谱会不会越用越乱，最后变成「更高级的垃圾堆」？
A：如果完全不管结构，任何笔记系统都会走向混乱，Rowboat 也不例外。好消息是，它通过实体类型和延迟创建策略，在一定程度上减缓了这个问题：只有当邮件、会议中出现足够信号时才创建实体，能过滤掉大量噪声。判断图谱是否健康，可以看两个信号：一是同一个人或项目是否被拆成多个文件，二是查询结果是否经常出现无关实体。实用建议：给项目和人物设定统一命名规则，定期用查询找出重复实体并合并，必要时可以在 Notes/ 里写一份「图谱使用约定」当作团队规范。
Q：和直接用 Obsidian + ChatGPT 相比，Rowboat 的优势在哪里？
A：Obsidian + ChatGPT 组合更像是「手工笔记 + 通用问答」，而 Rowboat 更偏向「自动化知识图谱 + 上下文感知代理」。关键差异在于：Rowboat 会自动从 Gmail、日历、会议记录中抽取结构化实体和关系，并在查询时按实体精确拉取上下文，而不是简单做全文检索。判断依据是：当你问「这个季度某个客户承诺了什么」时，Rowboat 能直接给出按时间线整理的承诺列表，而不是一堆包含关键词的段落。建议做法：如果你主要是个人知识管理，Obsidian + ChatGPT 已经够用；一旦你的问题开始变成「跨项目、跨人物的状态追踪」，可以考虑引入 Rowboat 做底层图谱。
Q：初次搭建 Rowboat 时，最容易踩的坑有哪些？
A：常见坑有三类：一是 Google Cloud 配置出错，导致 Gmail/Calendar 无法正常同步；二是模型配置不当，比如 API Key 权限不足或模型名称写错；三是一次性导入过多历史数据，导致首次同步时间过长。判断是否踩坑，可以看 Rowboat 的 logs/ 和 runs/ 目录，里面会记录具体错误信息。操作建议：先只同步最近 1-3 个月的数据，确认工作流顺畅后再逐步扩展；Google 项目配置时严格对照官方文档一步步来，必要时可以在测试环境多试几次；模型侧则建议先用官方推荐的默认模型，等稳定运行后再尝试切换到更便宜或更快的替代方案。
有时候，一个真正好用的第二大脑，不是多记了多少东西，而是帮你少记了多少。等你第一次在混乱项目里用它一键拉出「谁在什么时候答应了什么」的时间线，大概就会明白这套系统为什么值得折腾。
