在 AI 助手层出不穷的今天，定位差异正成为技术选型的关键因素。Rowboat 明确将自己定义为「AI coworker」而非「AI agent」，这一命名背后折射出截然不同的设计哲学：它不追求单一任务的自主完成，而是强调与用户建立长期的协作关系，在持续的交互中积累、理解和复用上下文。本文将从知识图谱架构、持久化内存设计、数据源整合三个维度，系统解析 Rowboat 如何实现跨会话的长期上下文保持。

从会话级到持久级：记忆范式的根本转变

传统对话式 AI 依赖会话级别的上下文窗口，每次交互都需要重新加载历史记录。这种「每次从头」的模式在处理简单问答时尚可接受，但当用户期望 AI 理解「我上周与 Alex 讨论的项目决策」这类跨会话信息时，立即暴露 出根本缺陷 —— 模型无法主动维护和检索历史上下文。

Rowboat 采用了截然不同的策略：构建一个长期存活的知识图谱（Knowledge Graph），将用户的每一次交互、每一封邮件、每一次会议记录转化为图中的节点与边，形成可累积、可查询、可编辑的记忆系统。该知识图谱以 Markdown 文件的形式持久化存储在本地磁盘，兼容 Obsidian 的双向链接（backlinks）机制。这意味着用户可以随时打开任意一条笔记，查看它与其他笔记之间的关联关系，就像在阅读一份「可交互的工作日志」。

这种设计带来了三个核心优势：上下文随时间自动累积而非每次重建；关系明确且可追溯；记忆对用户完全可见而非隐藏在模型黑箱中。用户不仅是被动的信息接收者，更是记忆的管理者 —— 可以直接编辑 Markdown 文件来修正错误、补充上下文或调整知识结构。这种「记忆主权归用户」的理念，是 Rowboat 与大多数闭源 AI 助手最根本的差异。

知识图谱架构：节点、边与本地存储

Rowboat 的知识图谱以实体（Entity）为核心节点类型，主要包括四类：人物（People）、项目（Projects）、决策（Decisions）和承诺（Commitments）。每类实体对应独立的 Markdown 文件，文件内部以结构化字段记录关键属性。例如，一个「人物」节点可能包含姓名、角色、关联项目、往来邮件摘要、关键决策等字段；一个「决策」节点则可能记录决策内容、参与者、时间戳、后续行动项等。

节点之间的关系通过双向链接实现。当用户在会议记录中提及某个人物或项目时，Rowboat 自动创建指向对应节点的反向链接。这种机制效仿了 Roam Research 和 Obsidian 的双向链接设计，使得查询任意节点时都能快速追溯其关联上下文。随着使用时间增长，图谱的自然生长呈现出「复利」效应 —— 早期的一次会议记录可能与半年后的多个决策、多个项目形成关联，形成越用越丰富的知识网络。

在存储层面，Rowboat 选择本地文件系统作为持久化介质。所有数据以 Markdown 格式存储在用户本地的 Vault 目录中，默认路径为 ~/.rowboat/vault/。这种本地优先（Local-first）的架构直接回应了企业用户对数据隐私的关切 —— 敏感的工作邮件、会议内容、决策记录不需要上传至第三方云服务，完全保留在用户机器上。Vault 目录支持标准的 Git 版本控制，用户可以像管理代码仓库一样管理自己的记忆库，实现历史版本的回溯与备份。

跨会话状态管理：记忆的累积与检索机制

Rowboat 的跨会话状态管理可以概括为「写入 — 关联 — 检索」三阶段流程。在写入阶段，系统从多个数据源（ Gmail、Google Calendar、Fireflies 会议记录等）提取关键信息，将非结构化文本转化为结构化的实体节点。这一过程涉及实体识别、关系抽取和摘要生成三个关键步骤。Rowboat 内置了针对邮件和会议记录优化的提示词模板，引导大模型提取「谁」「做了什么决定」「下一步需要谁负责」等核心要素。

关联阶段负责将新写入的节点与已有图谱建立连接。当一条会议记录被处理时，系统会检索 Vault 中是否存在与参会者、讨论主题相关的已有节点，如果存在则自动创建双向链接。链接的建立基于模糊匹配 —— 即使会议记录中的人名拼写略有差异（如「Alex」vs「Alexander」），系统也能通过上下文推断建立关联。这种设计避免了在小型图谱中因命名不严格导致的「信息孤岛」问题。

检索阶段则服务于用户的即时需求。当用户请求「帮我准备与 Alex 的会议」时，Rowboat 并不简单地将所有历史记录塞入 prompt，而是从图谱中定位 Alex 相关的所有节点，提取其中涉及决策、开放问题和待办事项，生成一份结构化的会议简报（brief）。这种检索增强生成（RAG）模式显著降低了单次请求的 token 消耗，同时提升了回答的准确性和上下文相关性。

值得注意的是，Rowboat 并不依赖向量相似度检索作为唯一的召回手段。双向链接和结构化字段查询提供了更精准的定向召回能力，向量检索则作为补充手段处理开放式的语义查询。这种「图结构 + 向量」的混合检索架构，在保持可解释性的同时兼顾了灵活性。

数据源集成与提取策略

Rowboat 支持三类核心数据源的集成，每类数据源对应不同的提取策略。Gmail 集成通过 Google API 拉取邮件内容，系统会自动提取邮件主题、发件人、收件人和正文关键句，将相关信息链接到对应的人物和项目节点。Google Calendar 集成则侧重于提取会议时间、参与者和会前已发送的议程材料，作为会议简报的输入来源。Fireflies 会议记录集成允许 Rowboat 直接消费转录文本，提取发言要点、决策片段和行动项并写入图谱。

所有数据源的提取过程均在本地执行，不涉及将原始邮件或会议录音上传至外部服务。API 密钥存储在 ~/.rowboat/config/ 目录下的独立 JSON 文件中，支持 Google、Deepgram（语音转写）、ElevenLabs（语音输出）和 Exa（网络搜索）等服务的配置。这种模块化的配置设计允许用户按需启用或禁用特定集成，保持系统资源的合理占用。

在工具扩展方面，Rowboat 通过 MCP（Model Context Protocol）协议连接外部工具。官方文档中提及的集成包括 Exa（网络搜索）、Twitter/X（社交监控）、Slack、Linear/Jira、GitHub 等。这意味着 Rowboat 不仅能从邮件和日历中构建记忆，还能从项目管理工具、代码仓库和即时通讯中持续吸收工作上下文，进一步扩展知识图谱的覆盖范围。

工程实现参数与可落地建议

对于计划在团队或个人场景中部署 Rowboat 的开发者，以下参数值得关注。Vault 目录建议使用支持双向链接的笔记应用（如 Obsidian 或 Logseq）进行管理，这样可以在 Rowboat 运行时直接通过第三方工具可视化图谱结构和编辑内容。实体命名应遵循统一的前缀或标签约定，例如使用 [Person:]、[Project:] 等前缀区分节点类型，这有助于在纯文本环境下进行快速筛选和脚本化处理。

在模型选择上，Rowboat 支持本地模型（通过 Ollama 或 LM Studio）和托管模型（OpenAI、Anthropic 等）两种模式。对于处理敏感工作内容的场景，推荐使用本地模型以确保数据不离开本地网络。模型上下文窗口应至少支持 32K token，以容纳单次大型会议记录的完整处理。提取任务与生成任务可以分配不同的模型 —— 使用较小的模型处理实体提取以降低成本，使用较强的模型生成会议简报以保证质量。

检索层面，建议为关键实体节点添加结构化的「最后更新时间」和「更新来源」字段，这有助于在图谱规模扩大后实现基于时间衰减的优先级排序。对于高价值的决策节点，可以在 Markdown 文件头部使用 YAML frontmatter 标记 priority: high 和 status: active，便于快速筛选需要持续跟进的条目。

Rowboat 的架构本质上将记忆从模型的「参数权重」中释放出来，存储为用户可读、可编辑、可版本化的结构化文本。这种设计既回应了 AI 隐私化的行业趋势，也为「人机协作」提供了更健康的权力边界 ——AI 不是代替用户记忆，而是帮助用户更好地管理和运用自己的知识资产。

参考资料