AI Agent 的 Markdown 上下文为何昂贵？Native 用 SQLite 做了什么
把知识库交给 AI Agent，常见做法是让它搜索 Markdown 文件，再把命中的内容塞进上下文。这个方案简单、可移植，却可能在资料规模增长后付出高昂的检索成本。Native 团队近期公开了一项研究预览：将 Markdown 内容包装进 SQLite，并通过 MCP 提供检索，声称在其特定评测任务中，正确回答所需 token 比直接使用 Markdown 少约 40 倍。
这个数字值得关注，但不能脱离评测条件理解。它不是“所有 Markdown 知识库都能省 40 倍”，更不是 SQLite 天生比文件快 40 倍；它描述的是 Native 在一组任务、数据和检索架构下测得的结果。对工程团队而言，更有价值的问题是：这个思路改变了什么，如何验证它是否适合自己的 Agent？
核心思路：Markdown 仍是内容，SQLite 成为检索层
Native 的研究文章把 Markdown 文件视为人类可读、可编辑的知识源，同时使用 SQLite 组织检索，让 Agent 不必反复扫描大量文本。SQLite 的全文检索、结构化查询和索引能力，可以帮助系统先缩小候选范围，再将相关片段交给模型。通过 MCP 接入后，兼容 MCP 的客户端可以把检索能力当作工具调用，而不必把整个知识库预先塞进提示词。
这并不意味着 Markdown 被数据库取代。更合理的理解是分层：文件继续承担可编辑、易迁移的内容格式；数据库承担索引、查询和协作运行所需的结构。Native 文章还展示了 Markdown 与 SQLite 组合的评测，并讨论了本地优先与上下文自主权等设计目标。
“40 倍”具体代表什么
Native 公布的摘要数据包括：其 SQLite MCP 方案每个正确答案约消耗 172k tokens；Native-to-Markdown 方案约 653k；Markdown 加 wikilinks 方案约 7.5M。文章据此报告 SQLite MCP 相对 Markdown 基线约 43.5 倍的 token 差异，并称在固定 1M 输入 token 预算下失败试验减少 97%。文中也给出中位回答时间比较，称其方案约为 Markdown 检索的六分之一。
这些是发布方在特定基准中的结果，不是独立复现结论。评测数据、问题类型、索引实现、模型、缓存与“正确答案”的判定方式都会影响数字。落地前应查看原文的图表与方法，尤其注意比较对象：摘要同时列出 SQLite MCP、Native-to-Markdown 和 Markdown 加 wikilinks，不应把所有方案都简化成“普通 Markdown 文件”。
适合什么场景，何时不值得迁移
当 Agent 需要从大量长期积累的笔记、项目文档或团队知识中反复找依据时，数据库检索可能降低重复上下文开销，也能为检索范围提供更明确的边界。MCP 接口还让同一知识服务有机会被不同客户端复用。
反过来，如果知识库很小、查询很少，或者团队更重视零服务依赖与纯文件工作流，SQLite 检索层未必值得引入。数据库也带来索引更新、冲突处理、备份与权限边界等工程责任。对敏感资料，不能只因内容存储在本地就默认安全；仍需明确哪些文件进入索引、哪些 Agent 可以查询，以及日志是否包含原文。
一个可执行的验证流程
Native 的研究文章提供项目仓库入口和评测材料；在采用前，建议先在自己的语料上做小规模对照，而不是直接把摘要数字当作采购或架构依据：
- 选取一组真实问题，并由人工标注答案依据，避免只评估“看起来相关”的检索结果。
- 固定模型、提示词和预算，比较当前文件搜索方案与 SQLite/MCP 方案。
- 同时记录正确率、输入 token、回答延迟和失败类型；不要只优化 token 数。
- 检查引用是否能回到原始 Markdown 文件及段落，避免检索压缩后失去可审计性。
- 加入更新与删除测试，确认文件改动后索引不会长期保留过期内容。
需要注意，本文不提供 Native 未在研究页面明确给出的安装命令或配置字段；这类细节应以仓库当前 README 和项目文档为准。项目 GitHub API 当前将仓库许可证标记为 NOASSERTION，因此这里不把它描述为某种特定开源许可证。
结语
SQLite 为 Markdown 知识库增加了结构化检索通道，可能帮助 Agent 少读无关上下文，但收益取决于语料、任务与实现。Native 的 40× 数据是一个值得复测的研究结果，不应被当作普遍保证。最稳妥的做法，是保留人可读的 Markdown 源文件，在自己的问题集上对比准确率、成本与维护负担，再决定是否增加数据库和 MCP 这一层。