# In 6 months, you'll either have an AI second brain or wish you did (a full setup to start today)
**作者**: Avi Chawla
**日期**: 2026-05-07T09:57:35.000Z
**来源**: [https://x.com/_avichawla/status/2052326975034048754](https://x.com/_avichawla/status/2052326975034048754)
---
Karpathy, Garry Tan, and the best builders in tech are all converging on AI second brains. The article covers a full 100% local setup guide. This is moving faster than most people realize. In 6 months, this will be the default.
Karpathy's LLM Wiki compiles raw sources into a persistent Markdown wiki with backlinks and cross-references.
The LLM reads papers, extracts concepts, writes encyclopedia-style articles, and maintains an index. The knowledge is compiled once and kept current, so the LLM never re-derives context from scratch at query time.
This works because research is mostly about concepts and their relationships, which are relatively stable.
But this pattern breaks when you apply it to actual work, where context evolves across conversations constantly.
A compiled wiki would have a page about a project, but it wouldn't track that a deadline agreed in one email thread and moved to a later date in another thread, while the team still assumed the original date.
A wiki doesn't track ground truth effectively.
I wrote about this recently, and Karpathy liked it:
Tracking this requires a different data structure altogether. Not a wiki of summaries, but a knowledge graph of typed entities where people, decisions, commitments, and deadlines are separate nodes linked across conversations.
Rowboat (GitHub Repo) is an open-source implementation of exactly this, built on the same Markdown-and-Obsidian foundation that Karpathy uses, but extended into a work context.
The way it works is that it ingests conversations from Gmail, Granola, and Fireflies, and instead of writing a summary page per topic, it extracts each decision, commitment, and deadline as its own Markdown file with backlinks to the people and projects involved.
That's structurally different from a wiki because:
- A wiki page about "Project X" gives you a summary of what was discussed.
- But a knowledge graph gives you every decision made, who made it, what was promised, when it was promised, and whether anything has shifted since.
Next, let's set up Rowboat from scratch, walk through what the knowledge graph looks like on disk, and see what happens once the graph is live.
# Setup
Rowboat is a local desktop app (Mac, Windows, Linux) that runs entirely on your machine and lets you bring your own model from Ollama, LM Studio, or any hosted API.
It stores everything in ~/.rowboat/ as plain Markdown files in an Obsidian-compatible vault. If you already use Obsidian for notes, you can point it at the same vault and browse Rowboat's knowledge graph alongside your own files.
If you don't use Obsidian, the Markdown files are still readable in any editor.
To start, download the app here: rowboatlabs.com/downloads
Next, open ~/.rowboat/config/models.json and point it at whatever you're running.
For a hosted provider, you can specify:
```
{
"provider": {
"flavor": "openai",
"apiKey": "sk-..."
},
"model": "gpt-4o"
}
```
Anthropic, Google, and OpenRouter use the same structure, so you can just swap the `flavor` property above. If you want inference fully on your machine, Ollama works too:
```
{
"provider": {
"flavor": "ollama",
"baseURL": "http://localhost:11434"
},
"model": "llama3.2"
}
```
Lastly, you can also set the preferred LLM providers using their respective API Keys from the UI itself. Visit Settings → Models:
Once a model is connected, Rowboat wraps it with system prompts that make the LLM aware of your knowledge graph structure.
The model knows about the knowledge/ directory, understands the entity types (People, Projects, Organizations, Topics), can traverse backlinks between notes, and can read Today(.)md for current context before responding.
It's effectively a work-oriented system prompt layer on top of whatever model you chose, so the LLM operates as a context-aware copilot rather than a blank chat session.
Moving on, you'll need your own Google Cloud project with OAuth credentials so that you can invoke Gmail, Calendar, and Drive directly from your machine using those credentials.
The full walkthrough is in google-setup MD file in the Rowboat GitHub repo. The core flow is this:
- Create a project at console. cloud. google. com
- Enable Gmail, Calendar, and Drive APIs
- Set up an OAuth consent screen (Testing mode works)
- Add your email as a test user
- Create an OAuth Client ID (type: Web application)
- Set redirect URI to http://localhost:8080/oauth/callback
- Paste your Client ID and Secret into Rowboat when prompted
Once connected, the first sync kicks off, and the graph starts building.
If you use Fireflies or Granola, you can add your API keys here:
```
// ~/.rowboat/config/fireflies.json # Fireflies meeting transcripts
{
"apiKey": "<your-fireflies-api-key>"
}
// ~/.rowboat/config/granola.json # Granola meeting notes
{
"apiKey": "<your-granola-api-key>"
}
```
The transcripts get pulled into the Meetings/ folder automatically, with decisions and action items extracted into the knowledge graph.
Additionally, you can add other integrations if needed based on what fits your workflow.
```
~/.rowboat/config/deepgram.json # voice input and notes
~/.rowboat/config/elevenlabs.json # voice output
~/.rowboat/config/exa-search.json # web research via Exa
~/.rowboat/config/composio.json # external tools
~/.rowboat/config/mcp.json # other MCP tools
```
Once the first sync completes, the graph is ready to query.
# The vault structure on disk
After the first sync, your ~/.rowboat/ directory is live.
- The config/ folder has all your API keys and model config
- The gmail_sync/ and calendar_sync/ folder has synced data before it gets processed into the graph
- The events/ folder contains the background agent activity, split into done/ and pending/ folders.
- Anything in the sites/ folder gets served at http://localhost:3210/sites/<slug>/ and can be embedded as a live iframe in any note.
- The logs/ and runs/ folders contain the operation history and agent run records.
The more interesting part of the structure is inside knowledge/.
This is what it holds:
- Agent Notes/ is Rowboat's memory layer, written from your behavior and writing patterns over time.
- Meetings/ contains processed transcripts from Fireflies or Granola, with decisions and action items extracted.
- Notes/ is for your own Markdown files.
- Today(.)md is the file Rowboat reads first before answering anything. It aggregates recent emails, meeting notes, and drafts into a single entry point for every query.
In addition to this, there are also People/, Organizations/, Projects/, and Topics/ folders.
They all start empty and populate as the signal accumulates. The Rowboat Agent only creates an entity file once there's enough evidence across emails, meetings, and decisions to justify it.
This is a deliberate design choice because premature entity creation from noisy data (spam senders, marketing emails) would pollute the graph.
Rowboat doesn't load the full vault on every query. It reads Today(.)md first, then pulls only the entity files relevant to your request. The graph can grow to hundreds of notes while the query cost stays flat.
# Querying the graph
Once sync completes, here's a useful first query you can ask:
```
Prep me for my 2pm meeting with Sarah Chen
```
This depicts the result:
Under the hood, the Rowboat Agent traversed Sarah's entity node and its backlinks.
- Her role and firm came from email signatures and meeting attendees.
- Your interaction history was reconstructed from calendar events and threads.
- Open items were extracted from past meeting transcripts.
- And talking points come from related entities in the graph.
Any [[entity]] reference in the brief is a live backlink that you can click through:
This will show the full entity node, so additional context for any account, person, or project becomes visible in just one hop:
Here's another query:
```
Create a voice summary of my day ahead
```
This depicts the result:
In this case, the Agent pulled today's meetings from your calendar, gathered context on attendees from the graph, generated a script grounded in your priorities, and handed the audio back as an MP3.
> This requires the ElevenLabs or Deepgram integration discussed above for the audio part specifically.
For ongoing tracking, tagging `@ rowboat` on any note turns it into a live note. Rowboat keeps it updated automatically as new relevant information comes in from connected sources.
For instance, if you're tracking a deal, a project, or an account across multiple conversations, the note stays current without manual upkeep.
Finally, you can also spin up agents that run on a schedule independently of your queries. You control what runs, when it runs, and what gets written back to the vault.
# Knowledge graph evolution over time
As expected, the knowledge graph gets denser with every email and meeting. New signals attach to existing entity nodes rather than creating isolated files.
Imagine that Sarah was in the Series B intro call 3 weeks back. That link already exists from day one.
But when she emails term sheet feedback now, that update attaches to the same node as a new line in her activity log.
The graph doesn't create a second "Sarah Chen" file. It extends the existing one.
At month 2, when you query "what has Sarah committed to this quarter," the Agent traverses connected context across every interaction, not individual threads sitting in separate inboxes.
If you set a live note set on a deal in week one, it stays current because the Agent keeps pulling new relevant context into it automatically.
So you set it once and the graph maintains it.
This is the structural difference from Karpathy's wiki pattern. A wiki compiles concepts into pages. A knowledge graph tracks state across conversations, and that state compounds as new interactions link back to existing entities
Rowboat takes the compounding knowledge base Karpathy’s pattern describes and makes it work for the context that actually changes day to day.
It stores everything as plain Markdown in ~/.rowboat/ so nothing is locked into a proprietary format.
Model calls go to wherever you pointed models. json.
- With Ollama, the entire pipeline runs on your hardware.
- With a hosted API key, your prompts go directly to that provider under your own account's terms.
Rowboat doesn't proxy or intercept model calls.
OAuth credentials for Gmail, Calendar, and Drive live in ~/.rowboat/config/ and call Google's API directly from your machine. Every integration follows the same architecture, i.e., they are invoked locally and outputs are written to the local vault.
The repo is Apache-2.0 licensed.
GitHub repo here (13k+ stars): github.com/rowboatlabs/rowboat (don't forget to star it 🌟)
That's a wrap!
If you enjoyed this tutorial:
Find me → @_avichawla
Every day, I share tutorials and insights on DS, ML, LLMs, and RAGs.
## 相关链接
- [Avi Chawla](https://x.com/_avichawla)
- [@_avichawla](https://x.com/_avichawla)
- [5.8K](https://x.com/_avichawla/status/2052326975034048754/analytics)
- [GitHub Repo](https://github.com/rowboatlabs/rowboat)
- [rowboatlabs.com/downloads](https://rowboatlabs.com/downloads)
- [Rowboat GitHub repo](https://github.com/rowboatlabs/rowboat)
- [github.com/rowboatlabs/rowboat](https://github.com/rowboatlabs/rowboat)
- [@_avichawla](https://x.com/@_avichawla)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [5:57 PM · May 7, 2026](https://x.com/_avichawla/status/2052326975034048754)
- [5,868 Views](https://x.com/_avichawla/status/2052326975034048754/analytics)
- [View quotes](https://x.com/_avichawla/status/2052326975034048754/quotes)
---
*导出时间: 2026/5/7 21:37:02*
---
## 中文翻译
# 6个月后，你要么拥有一个AI第二大脑，要么后悔没有（一个可从今天开始的完整搭建指南）
**作者**: Avi Chawla
**日期**: 2026-05-07T09:57:35.000Z
**来源**: [https://x.com/_avichawla/status/2052326975034048754](https://x.com/_avichawla/status/2052326975034048754)
---
Karpathy、Garry Tan 以及科技界最优秀的开发者们都在向着 AI 第二大脑的方向汇聚。这篇文章涵盖了一份完整的 100% 本地化搭建指南。这一趋势的发展速度超出了大多数人的认知。6 个月后，这将成为标配。
Karpathy 的 LLM Wiki 将原始来源编译成一个带有反向链接和交叉引用的持久化 Markdown 维基。
LLM 阅读论文，提取概念，撰写百科全书式的文章，并维护一个索引。知识只编译一次并保持最新，因此 LLM 在查询时无需从头开始重新推导上下文。
这种方法行之有效，是因为研究主要涉及概念及其关系，而这些相对稳定。
但当你将其应用到实际工作中时，这种模式就会失效，因为实际工作中的上下文是在对话中不断演变的。
一个编译好的维基可能会有关于某个项目的页面，但它无法追踪这样一个事实：在一个邮件线程中商定的截止日期，在另一个线程中被推迟了，而团队仍然认为是原定日期。
维基无法有效地追踪“事实真相”。
我最近写过关于这个问题的文章，Karpathy 也表示赞同：
追踪这些信息需要完全不同的数据结构。不是摘要组成的维基，而是由类型化实体构成的知识图谱，其中人员、决策、承诺和截止日期是跨越对话链接的独立节点。
Rowboat (GitHub 仓库) 正是这一理念的开源实现，它建立在 Karpathy 使用的相同 Markdown 和 Obsidian 基础之上，但扩展到了工作场景中。
其工作原理是，它从 Gmail、Granola 和 Fireflies 摄取对话，它不是为每个主题撰写一个摘要页面，而是将每个决策、承诺和截止日期提取为独立的 Markdown 文件，并带有指向相关人员和项目的反向链接。
这在结构上与维基不同，因为：
- 关于“项目 X”的维基页面会给你一个关于讨论内容的摘要。
- 但知识图谱会给你每一个决策的细节：谁做的决策，承诺了什么，何时承诺的，以及此后是否发生了变化。
接下来，让我们从零开始搭建 Rowboat，浏览一下知识图谱在磁盘上的样子，并看看图谱上线后会发生什么。
# 搭建
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 Keys 来设置首选的 LLM 提供商。访问 设置 → 模型：
一旦连接了模型，Rowboat 会使用系统提示将其包装，使 LLM 意识到你的知识图谱结构。
模型知道 knowledge/ 目录，理解实体类型（人员、项目、组织、主题），可以遍历笔记之间的反向链接，并且可以在响应前阅读 Today(.)md 以获取当前上下文。
这实际上是在你选择的任何模型之上的一个面向工作的系统提示层，因此 LLM 作为一个上下文感知的副驾驶运行，而不是一个空白的聊天会话。
接下来，你需要拥有自己的 Google Cloud 项目和 OAuth 凭据，以便你可以使用这些凭据直接从你的机器调用 Gmail、日历和云端硬盘。
完整的演练指南在 Rowboat GitHub 仓库中的 google-setup MD 文件里。核心流程如下：
- 在 console.cloud.google.com 创建一个项目
- 启用 Gmail、Calendar 和 Drive API
- 设置 OAuth 同意屏幕（测试模式即可）
- 将你的电子邮件添加为测试用户
- 创建 OAuth 客户端 ID（类型：Web 应用程序）
- 将重定向 URI 设置为 http://localhost:8080/oauth/callback
- 当提示时，将你的客户端 ID 和密钥粘贴到 Rowboat 中
连接后，首次同步开始启动，图谱开始构建。
如果你使用 Fireflies 或 Granola，你可以在此处添加你的 API 密钥：
```
// ~/.rowboat/config/fireflies.json # Fireflies 会议记录
{
"apiKey": "<your-fireflies-api-key>"
}
// ~/.rowboat/config/granola.json # Granola 会议笔记
{
"apiKey": "<your-granola-api-key>"
}
```
会议记录会自动被拉取到 Meetings/ 文件夹中，决策和行动项会被提取到知识图谱中。
此外，如果需要，你可以根据适合你的工作流程添加其他集成。
```
~/.rowboat/config/deepgram.json # 语音输入和笔记
~/.rowboat/config/elevenlabs.json # 语音输出
~/.rowboat/config/exa-search.json # 通过 Exa 进行网络研究
~/.rowboat/config/composio.json # 外部工具
~/.rowboat/config/mcp.json # 其他 MCP 工具
```
首次同步完成后，图谱就准备好接受查询了。
# 磁盘上的库结构
首次同步后，你的 ~/.rowboat/ 目录就激活了。
- config/ 文件夹包含你所有的 API 密钥和模型配置
- gmail_sync/ 和 calendar_sync/ 文件夹包含在处理到图谱之前的同步数据
- events/ 文件夹包含后台代理活动，分为 done/ 和 pending/ 文件夹。
- sites/ 文件夹中的任何内容都会在 http://localhost:3210/sites/<slug>/ 上提供，并可以作为实时 iframe 嵌入到任何笔记中。
- logs/ 和 runs/ 文件夹包含操作历史和代理运行记录。
结构中更有趣的部分在 knowledge/ 里面。
这是它包含的内容：
- Agent Notes/ 是 Rowboat 的记忆层，根据你的行为和写作模式随时间撰写。
- Meetings/ 包含来自 Fireflies 或 Granola 的处理后记录，提取了决策和行动项。
- Notes/ 用于你自己的 Markdown 文件。
- Today(.)md 是 Rowboat 在回答任何问题之前首先读取的文件。它将最近的电子邮件、会议笔记和草稿聚合到每个查询的单一入口点。
除此之外，还有 People/、Organizations/、Projects/ 和 Topics/ 文件夹。
它们开始时都是空的，随着信号的积累而填充。Rowboat 代理只有在跨电子邮件、会议和决策有足够的证据证明合理时，才会创建实体文件。
这是一个深思熟虑的设计选择，因为从噪声数据（垃圾邮件发送者、营销电子邮件）中过早创建实体会污染图谱。
Rowboat 不会在每次查询时加载整个库。它首先读取 Today(.)md，然后仅提取与你请求相关的实体文件。图谱可以增长到数百个笔记，而查询成本保持平稳。
# 查询图谱
同步完成后，你可以问一个有用的首个查询：
```
Prep me for my 2pm meeting with Sarah Chen
```
（帮我准备下午2点与 Sarah Chen 的会议）
结果如图所示：
在底层，Rowboat 代理遍历了 Sarah 的实体节点及其反向链接。
- 她的角色和公司来自电子邮件签名和会议参与者。
- 你的互动历史是从日历事件和线程中重建的。
- 未完成的事项是从过去的会议记录中提取的。
- 谈话要点来自图谱中的相关实体。
简报中的任何 [[实体]] 引用都是一个实时的反向链接，你可以点击查看：
这将显示完整的实体节点，因此任何账户、人员或项目的额外上下文只需一次点击即可可见：
这是另一个查询：
```
Create a voice summary of my day ahead
```
（为我的一天创建一个语音摘要）
结果如图所示：
在这种情况下，代理从你的日历中提取了今天的会议，从图谱中收集了参与者的上下文，根据你的优先级生成了脚本，并将音频作为 MP3 返回。
> 这需要上文讨论的 ElevenLabs 或 Deepgram 集成，特别是针对音频部分。
对于持续跟踪，在任何笔记上标记 `@ rowboat` 会将其变成一个动态笔记。Rowboat 会随着来自连接源的新相关信息到来而自动保持更新。
例如，如果你在多个对话中跟踪一笔交易、一个项目或一个账户，该笔记会保持最新，无需手动维护。
最后，你还可以启动按计划运行的代理，独立于你的查询。你可以控制运行什么、何时运行以及写回库的内容。
# 知识图谱随时间的演变
正如预期的那样，知识图谱会随着每一封邮件和每一次会议变得更加密集。新信号会附加到现有的实体节点上，而不是创建孤立的文件。
想象一下，Sarah 在 3 周前参加了 B 轮融资介绍电话。该链接从第一天起就已存在。
但现在当她发送条款清单反馈邮件时，该更新会作为其活动日志中的新行附加到同一节点上。
图谱不会创建第二个“Sarah Chen”文件。它扩展现有的那个。
在第 2 个月，当你查询“Sarah 本季度承诺了什么”时，代理会遍历每个互动中连接的上下文，而不是位于不同收件箱中的单独线程。
如果你在第一周为一个交易设置了一个动态笔记，它会保持最新，因为代理会不断自动提取新的相关上下文。
所以你只需设置一次，图谱就会维护它。
这就是与 Karpathy 的维基模式在结构上的区别。维基将概念编译成页面。知识图谱跨越对话跟踪状态，随着新的互动链接回现有实体，这种状态会不断复合。
Rowboat 采纳了 Karpathy 模式所描述的复合知识库，并使其适用于真正每天都在变化的上下文。
它将所有内容作为纯 Markdown 存储在 ~/.rowboat/ 中，因此没有任何内容被锁定在专有格式中。
模型调用会发送到你在 models.json 中指向的任何位置。
- 使用 Ollama，整个管道都在你的硬件上运行。
- 使用托管 API 密钥，你的提示会根据你自己账户的条款直接发送给该提供商。
Rowboat 不会代理或拦截模型调用。
Gmail、Calendar 和 Drive 的 OAuth 凭据位于 ~/.rowboat/config/ 中，并直接从你的机器调用 Google 的 API。每个集成都遵循相同的架构，即它们在本地调用，输出被写入本地库。
该仓库采用 Apache-2.0 许可证。
GitHub 仓库在这里（13k+ stars）：github.com/rowboatlabs/rowboat（别忘了点个星 🌟）
这就完事了！
如果你喜欢这个教程：
Find me → @_avichawla
我每天都会分享关于 DS、ML、LLMs 和 RAGs 的教程和见解。