本地优先知识产品的架构演进

更新于 2026-06-25

本地优先知识产品的架构演进

# 本地优先知识产品的架构演进

结论

从本地单机 App 走向多端成熟产品，关键不是「要不要服务器」，而是把边界划成 云端加工厂 + 本地主仓库；并且从第一天就把 AI 执行层抽成可替换的接口， 产品形态改在前端，数据模型改在后端。

一、Agent 先变成可执行入口，再动数据模型

原状态：侧边栏四个功能入口（订阅 / 笔记 / 剪藏 / 沉淀），AIPanel 已有对话， 但工具只能读（读笔记、读剪藏、搜索），不能创建和整理。

演进顺序：

阶段内容是否动数据模型
P0把 createNote / saveClip / addSubscription 暴露给 AI tools，让对话能创建笔记、存剪藏、加订阅、搜索后整理成新笔记否（改 AIPanel 与 tools 的接线）
P1侧边栏信息架构改成 Agent / Inbox / 知识库 / 订阅否（前端结构）
P2剪藏、RSS 新文章、临时笔记统一进 Inbox先不做底层合并
P3RSS 每篇总结是（给 feed_entries 加字段）

两个关键取舍：

  • Inbox 第一版做「虚拟 Inbox」：前端把 clips / feed entries / 未整理 notes 混合展示， 每个 item 标来源类型；点「整理到知识库」时生成或更新一条 note。 统一字段（inbox_status、output_note_id、ai_tags、processed_at）等跑通后再补。 理由是直接合成一张大表会牵动 Rust、迁移、搜索、列表、阅读器，成本远大于收益。
  • RSS 总结不要一刷新就全量跑：慢、贵、失败难处理。先做「打开文章时可生成」， 并给每个 AI 任务留状态字段（summary_status / summarized_at）。

判据：用户能体验到的能力先上线，迁移成本后置；能让前端解决的就不要先动表结构。

二、Agent 是侧边栏主入口，不是独立窗口

用户问「是否要单独一个 agent 窗口」，收敛结论是不要。

  • 独立 Agent 窗口很容易变成「又一个 ChatGPT 窗口」，和知识库本体割裂， 用户会困惑：我到底是在用知识库，还是在和一个机器人聊天。
  • 正确形态是贴着用户正在看的内容工作：
    • 侧边栏 Agent = 工作台 / 起点（主区域首页 + 大输入框 + 当前可执行动作 + 最近的 Inbox / 待处理）
    • 右侧 AI Panel = 当前内容的上下文助手（看文章时总结/整理/解释名词，写笔记时润色/扩写/找关联）
  • 整体结构：左侧选工作区，中间放知识内容与任务，右侧浮层是上下文 AI，Agent 作为第一入口而不是独立 app。

判据同族：新增一个独立入口，必须回答「去掉它用户会损失什么能力」（见 容器要有超出文件夹的意义才值得独立入口）。

三、AI 调用要抽成可替换的执行层

什么时候才真的需要独立 AI server —— 不是「AI 更耗性能」，而是这些需求出现时：

  1. 用户关闭 App 后仍要自动刷新 RSS、自动总结、发日报
  2. 不想让用户自己填 API key，由你统一提供 AI 能力
  3. 邮件推送、通知推送、定时日报
  4. 多设备同步
  5. 统一的成本控制、限流、缓存、失败重试
  6. 更复杂的 Agent 任务队列（每天处理大量订阅源）
  7. 账号体系、会员、用量统计

当前该怎么做：本地跑 AI，但按「未来可替换为 server」的方式写 ——

ai/summarizeFeedEntry()
ai/generateNote()
ai/classifyContent()

现在内部调本地 API，将来只把实现换成 call('/api/ai/summarize-feed-entry')， UI 和业务流程不用大改。要点：不要把 OpenAI 调用散落在 React 组件里， prompt 与 JSON schema 独立成模块，总结结果落 SQLite 并给每个 AI 任务留状态字段。

分层边界：

层职责
UI 组件展示、按钮、状态
业务服务层summarizeEntry / createNoteFromEntry / addSubscription
Tauri/RustSQLite、RSS fetch、本地文件、系统能力
AI Client模型调用、prompt、JSON schema、错误处理

四、云端加工厂 + 本地主仓库

用户提出的方案：本地把订阅源列表给云端 → 云端抓 RSS → 云端 AI 总结 → 结果回本地 → 本地保存。

这比「纯本地抓 RSS」更适合多端：

  • 移动端后台任务限制多，本地 App 不一定能稳定定时抓；云端不受设备限制
  • 多端体验一致，不会出现某台设备有新文章、另一台没有
  • AI pipeline 更自然：云端抓到就总结，客户端只拿「标题 + 正文/摘要 + 总结 + 标签 + 名词解释」
  • 日报天然适合云端生成

代价是隐私边界改变：云端至少会接触用户订阅了哪些源、文章标题/链接、正文或摘要、总结结果。 产品定义要跟着改成：

本地保存知识库主数据，云端负责订阅抓取和 AI 加工，可短期缓存处理结果。

要配的产品承诺：云端只存订阅任务与近期处理结果、本地才是长期知识库、用户可清除云端缓存、 可选「本地抓取 / 云端抓取」。云端的角色是待同步结果池，不是永久知识库。

结果怎么回本地：

方式特点
本地主动拉取（App 打开时问「有没有新处理好的」→ 下载 → 写入 → 回执）第一版选它：最简单稳定；代价是不打开 App 本地就没有最新数据
云端推送（push / websocket）体验更好但复杂，Mac/Win/iOS/Android 推送体系各不相同

五、多端共享的是服务，不是 UI

目标若是 Mac / Windows / iOS / Android / iPad 的成熟产品，架构必须改： 数据不能只存在某一台电脑，RSS 也不能依赖用户打开某个设备才刷新。

客户端（只负责展示、编辑、缓存）
  → 统一服务器
  → 账号 / 数据同步 / RSS 抓取 / AI 总结 / 日报 / 知识库数据
  • 4G 内存服务器够第一版（只要不在服务器跑本地大模型）；真正的成本是 AI API 费用、并发与数据库设计
  • 客户端选型：Mac/Windows 继续 Tauri，Web 保留一套，移动端可评估 Tauri mobile，但更稳的路线通常是 RN/Expo
  • 原 Tauri 代码不废：本地 SQLite 从「唯一数据库」降级为「缓存」，RSS 抓取迁服务器，前端 AI 调用改成请求自己的服务器

判据：不要追求「一份 UI 跑所有端」，要追求「一套后端数据和 AI 能力，多端共用同一套服务」。

六、云端版先做骨架，Agent 面板先留位

从本地 Tauri App 迈向云端产品时，第一步不是「把 Agent 接上」，而是先把云端骨架搭出来：

  • 新开独立云端项目（如 mewmo-cloud），不要塞进本地 Tauri App —— 它是新云端产品，不是「本地知识库 2.0」
  • 技术选型偏云端能力：Next.js + TypeScript + Tailwind，后续 Postgres、cron/队列
  • 首页只表达三件事：这是什么产品、它能做什么、怎么开始；主按钮进静态 demo dashboard
  • 右侧 Agent 面板先留空占位（「将在这里读取当前页面上下文并对话」），不接模型、不接数据库、不接登录

理由：用户此时还不熟 Web Agent 的交互与技术架构，先验证「云端 mewmo 应该长什么样」的页面结构是否成立。Agent 后续分三层接：前端聊天 UI → 网站后端 API（读云端数据再调模型）→ Agent 工具层（search_notes / read_note / write_note / list_clips）。编排层选择见 Agent编排层薄自建优先于重型框架。

完整蓝图（Web / Mac / iOS / iPad / 扩展 / Agent / Admin / 同步 / 支付）要保留全量，但按阶段落地：见 完整蓝图不等于同阶段交付、数据权威模型要先于同步与迁移确定。

相关