Rowboat 开源 AI coworker 的持久记忆架构工程实践

当你每天在不同的 AI 工具之间切换时，是否曾感到这些助手总是在 "重新认识" 你？每次开启新对话，模型都需要重新加载上下文，历史信息像沙子一样从指缝间溜走。Rowboat 项目尝试解决的核心问题正是这个：让 AI coworker 拥有持久、可检验、可编辑的记忆，而不是每次都从零开始。

记忆架构的核心设计理念

Rowboat 的记忆系统建立在三个关键原则之上：长期性、可检验性和本地化。与传统 RAG 系统在每次查询时临时检索文档不同，Rowboat 维护的是一个持续生长的知识图谱。这个图谱以本地 Markdown 文件的形式存储在一个 Obsidian 兼容的 Vault 中，所有数据都保存在用户的机器上，而非云端服务器。

当你使用 Rowboat 处理邮件、会议记录或日常笔记时，系统会自动从中提取实体信息 —— 人名、项目、决策结论、待办事项、开放问题 —— 并将它们以双向链接的方式编织进知识图谱。这意味着当你两周后需要回顾与某个客户的沟通历史时，系统不再需要重新扫描所有原始文档，而是直接查询已经结构化的知识网络。

本地优先的设计带来了隐私与性能的双重收益。数据永远不会离开你的设备，即使在没有网络连接的环境下，AI coworker 依然可以正常运行并访问历史上下文。同时，由于知识图谱以人类可读的 Markdown 格式存储，用户可以随时打开文件进行人工审核、编辑或删除，完全掌控自己的数据。

知识图谱的构建与更新机制

Rowboat 的知识图谱并非静态快照，而是一个持续更新的活系统。当用户授权接入 Gmail 或日历服务后，系统会在后台持续监听新内容。每次处理新邮件或会议记录时，AI 会分析文本内容，识别其中涉及的人物、项目和关键事件，然后将这些信息追加到相应的笔记中，同时建立与已有笔记的双向链接。

Live Notes 功能是这一机制的具体应用。用户可以在任意笔记中输入 @rowboat 来创建一个持续追踪的笔记，系统会自动监控指定的人、项目或话题，并在 Vault 中更新相关内容。例如，创建一个追踪竞争对手动态的 Live Note，系统会定期搜索网络和社交媒体，将最新进展写入本地笔记，同时保留与已有信息的关联。这种机制确保了知识图谱不是一次性构建后就停滞不前，而是随着时间推移不断积累和深化。

系统还支持从多种来源导入数据。Rowboat 原生的会议记录功能可以直接录制并转录音频，而对于已经使用其他工具的用户，项目也支持从 Fireflies 等主流会议助手导入数据。这种灵活性使得用户无需改变现有工作流程，即可将历史数据纳入知识图谱。

上下文持久化的工程实现

从工程角度来看，Rowboat 的持久记忆实现涉及几个关键组件的协作。核心是一个基于文件系统的知识存储层，它将结构化的实体关系映射为目录结构和 Markdown 文件。每一条笔记对应一个 .md 文件，文件内部通过标准化的内部链接语法（类似 Obsidian 的 [[双链]]）来表达实体之间的关系。

当用户在对话中向 Rowboat 提问或请求帮助时，系统首先会检索相关的笔记文件，将其中的上下文注入到当前对话的 Prompt 中。这个过程比传统的向量检索更加确定性 —— 因为知识图谱的结构是由明确的实体和关系定义的，查询时可以基于语义标签和链接关系进行精确匹配，而非依赖 embedding 相似度的模糊排序。

上下文快照机制是另一个重要设计。当用户开始一个重要任务（如准备客户会议或撰写项目文档）时，Rowboat 可以生成当前知识图谱状态的快照，确保在整个任务执行期间上下文保持稳定。这避免了这样一个常见问题：用户在准备演示文稿的过程中收到新邮件，导致 AI 的上下文被悄然更新，引用了尚未讨论的结论。

可扩展性与工具集成

Rowboat 通过 Model Context Protocol（MCP）实现了良好的可扩展性。MCP 是一个开放标准，允许 AI 系统连接外部工具和数据源。Rowboat 原生支持集成 Exa（网络搜索）、Twitter/X、Slack、Linear、Jira、GitHub 等常用工具，同时也支持接入任何实现了 MCP 协议的第三方服务。

这种架构使得 Rowboat 的记忆系统可以不断扩展。用户既可以让 AI 追踪项目管理工具中的任务状态变化，也可以在 CRM 中维护客户关系的历史脉络。所有这些外部数据都可以被整合进本地知识图谱，形成一个统一的工作记忆视图。

对于模型选择，Rowboat 同样保持了灵活性。系统支持本地部署的模型（如 Ollama 或 LM Studio），也接受用户接入自己的 API 密钥使用托管模型。这个设计确保了知识图谱本身与具体的 LLM 实现解耦，用户可以根据隐私需求和成本考量选择合适的模型，而无需担心数据被发送到第三方。

与传统方案的对比

目前主流的 AI 助手大多采用即时检索模式：在每次对话时，通过向量搜索从文档库中召回相关片段作为上下文。这种方式的优势是实现简单、无需维护长期状态，但缺陷同样明显 —— 每次检索都是相对独立的，知识无法跨会话积累；检索结果的质量依赖 embedding 模型和索引策略，语义偏差可能导致遗漏关键信息；用户也无法直接审查和修改 AI 的 "记忆" 内容。

Rowboat 的方案则将记忆从运行时上下文提升为持久存储。知识图谱一旦构建，就会持续存在于文件系统上，即使关闭应用程序也不会丢失。这使得 AI 可以真正理解用户工作的演进轨迹，而不仅仅是当前会话的片段信息。系统记录的不只是 "用户问过什么问题"，而是 "用户在项目中做了哪些决策、涉及哪些人、有哪些待解决的分歧"。

从实际使用角度看，这种设计更适合知识工作者的高频场景。律师可以追踪案件相关的所有沟通和文件，产品经理可以维护需求决策的历史脉络，销售人员可以建立客户关系的多维度视图 —— 这些都是临时上下文无法胜任的任务。

资料来源：

• Rowboat GitHub 仓库：https://github.com/rowboatlabs/rowboat
• Rowboat 官方演示：https://www.youtube.com/watch?v=7xTpciZCfpw

ai-systems