Agent 读语义文件，App 读结构化存储

更新于 2026-06-15

**知识库不该让 agent 直连数据库：SQLite 是导航系统，Markdown 才是知识本体。** App 用它做检索 / 排序 / 状态，agent 用语义文件做理解 / 改写 / 迁移；两边不是二选一，而是分工。

一、两者定位不同

SQLite（结构化记录）Markdown（语义文件）
agent 读到的东西表、字段、行（需要先懂 schema、写 SQL）标题、正文、frontmatter、链接、路径
强项快、可筛选、可排序、可聚合（万篇级仍稳）语义自明、人和外部工具都能直接消费
弱项语义弱，对人和外部 agent 不透明大规模查询不如 DB

关键差别不在「能不能读」，而在读到的信息里有没有上下文线索。Markdown 的路径、标题层级、frontmatter、双链天然就是语义；SQLite 的一行只是字段集合。

二、为什么不让 agent 直连 DB

  1. 耦合内部实现 —— schema 一改，skill / prompt 全要跟着改。
  2. 容易读到衍生数据 —— FTS 表、缓存表、状态表不是用户知识本身。
  3. 不利于外部工具 —— 不是每个 agent 环境都方便开 SQLite，但几乎都能读一个 Markdown 目录。
  4. 上下文质量更差 —— 行数据缺语义线索，agent 更容易误把索引当主数据。

三、推荐分工

Agent 要理解 / 改内容   → 读写 Markdown
App 要检索 / 排序 / 状态 → 读 SQLite
SQLite 坏了             → 从 Markdown 重建
Markdown 坏了           → 那才是真数据损坏

即：Markdown 是唯一真源，SQLite 是可重建的派生层。

四、两者组合的最佳路径：先筛选，再读全文

不要「全扫文件」，也不要「只信 DB 里的摘要」：

SQLite FTS / metadata 找候选（如最近 30 天的 iOS 笔记 → 20 篇）
    → agent 读这 20 篇 Markdown 全文
    → 总结 / 回答

DB 只负责把候选范围缩小，召回质量仍由正文（Markdown）承担 —— 这也解释了为什么检索的改进重点在正文入索引而不是把 DB 字段做多。

相关