夜雨聆风我给AI助手装了"第二大脑"
SQLite + FTS5 零依赖方案，每次对话省下几千 Token
2026-07-25 · 实践记录 · 约 3500 字
一、问题：AI 助手的"记忆碎片化"
我日常用一个 AI Agent 帮我做各种事——写材料、记日记、管公众号、做调研。时间长了，一个问题越来越突出：它记不住自己的数据放哪了。
比如每天的工作流程跑完，Agent 在不同环节产出数据——调研笔记、任务日志、知识库卡片——分别散落在笔记文件、Markdown 文件、不同的目录里。第二天对话一恢复，它得重新读一堆文件才能进入状态。
这是典型的"记忆碎片化"问题：
MEMORY.md 越写越长（164 行，7.7KB）——每次对话都要全文读
每日笔记一个文件一天，散落在目录里
调研笔记、任务日志、知识库卡片各用一种格式
cron 定时任务产出的数据，写完文件就丢在那
最直接的后果：每次对话启动，Agent 要读好几个文件才能搞清楚"我是谁，我的数据在哪"。这些文件内容占用了大量上下文窗口——明明大部分信息这一轮根本用不上。
二、先看传统方案为什么太重
解决"Agent 记忆"问题，市面上常见的方案有几类：
方案A：向量数据库
Chromadb / Milvus / Qdrant 这些，适合大规模语义搜索。但为了一个个人 Agent 专门搭一套向量数据库，有点杀鸡用牛刀：
要装服务、配 embedding 模型、管索引
Agent 的数据量级（几十条任务、几百条笔记）对向量数据库来说是大炮打蚊子
每次写入要过 embedding，多了一层网络延迟
方案B：全部写文件，每次对话全读
这是大多数个人用户的做法。MEMORY.md 越长，对话越慢。而且文件读多了，Agent 容易"眼花"——从几百行里翻自己需要的那条信息，准确率并不高。
我们需要的是：零额外依赖、写入快、查询准、Agent 自己就能管。说白了，就是给 Agent 装个"本地数据库"。
三、方案：SQLite + FTS5
SQLite 是 Python 自带的标准库，import sqlite3 就能用，什么也不用装。FTS5 是 SQLite 内置的全文搜索引擎，同样是零依赖。
整套方案就一个文件：data_platform.py（约 400 行），封装了所有读写操作。Agent 通过 CLI 命令操作，不需要写 SQL。
数据模型
5 个核心表，涵盖 Agent 日常产出的主要数据类型：
表 用途 数据量
task_logs 任务执行日志 持续增长
daily_notes 每日笔记 37 天
memories 关键记忆（带 FTS5） 30 条
resources 知识库资源（带 FTS5） 51 条
english_exercises 英语练习记录 按需
FTS5 实现精准搜索
resources 表和 memories 表都挂了 FTS5 虚拟表，支持 BM25 排序的全文搜索。Agent 查资料时直接跑搜索，不用 grep 翻文件：
# 改前：翻文件
read_file MEMORY.md
grep "某个关键词" memory/*.md
# 改后：精准查询
python3 scripts/data_platform.py resource-search --query "关键词"
python3 scripts/data_platform.py memory-search --query "关键词"
四、Token 到底省在哪
这不是数学游戏，是实打实的上下文优化。来算一笔账：
改造前，每次对话启动：
读 MEMORY.md ≈ 1600 tokens（7.7KB）
读今日笔记 ≈ 600-1500 tokens
读任务日志 ≈ 400 tokens
合计：≈ 2600-3500 tokens
这些是每次对话无论用不用都得加载的上下文。而且随着时间推移，MEMORY.md 越长、笔记越多，消耗越大。
改造后，启动注入：
startup 命令输出 ≈ 400 tokens（精选的关键信息）
按需查询 ≈ 100-300 tokens/次
合计：≈ 400 tokens
每次对话省下 2200-3100 tokens。
按一天 50 次对话算，就是 12 万-16 万 tokens/day。一个月下来节省的上下文空间相当可观。
但这还不是全部。真正的"省 token"发生在精准度上——
旧方式：把一整份 MEMORY.md 塞进上下文，模型得自己翻找需要的信息，翻不到就胡说
新方式：模型直接问数据库要精确数据，不给上下文塞无关内容，生成的回答也更准
省 token 的终点不是省钱，是让模型把有限的上下文窗口，花在真正重要的事情上。
五、怎么接入 cron 自动化
这套方案另一个关键设计：cron 定时任务直接写库。
以前 cron 跑完把结果写成文件，Agent 下次对话时翻。现在 cron 跑完一步到位写进 SQLite：
# cron 任务结束时
python3 scripts/data_platform.py task-log 工作材料采集 success \
--detail "采集28篇，来源8个公众号"
python3 scripts/data_platform.py note-write --append \
"【工作材料采集】今日采集28篇，新增术语7条"
第二天对话启动，startup 自动拉出昨天的采集摘要。全过程零人工干预，不产生新的文件要读。
六、效果：不只是省 Token
上线跑了一周，几个直观变化：
对话启动快了 — 以前要等 Agent 读完 MEMORY.md 才能进入正题，现在秒回
数据不会丢 — 写到 SQLite，有事务保障，不像写文件可能因为权限/路径问题失败
查询更可靠 — "上周调研了哪些课题"这类问题，Agent 直接查表返回，不会从笔记里"猜"
历史好追溯 — 一个数据库文件全搞定，备份也简单
一个小插曲：建库后的第一次 cron 自动运行，采集了 28 篇文章，成功写入了 SQLite。我甚至没注意到它已经跑完了——直到去查数据库，发现记录在那里躺着。这就是"默默工作了"的理想状态。
七、适用边界
这套方案不是万能的。它适合的场景：
✅ 个人/小团队 Agent（数据量 < 10 万条）
✅ 结构化数据为主（任务日志、笔记、知识库资源）
✅ 需要 cron 自动写入、Agent 自动读取
✅ 不想引入额外基础设施
它不适合：
❌ 大规模语义搜索（那是向量数据库的领域）
❌ 非结构化文档全文检索为主的场景（FTS5 中文分词有限）
❌ 需要多 Agent 高并发写入（SQLite 写锁是单线程的）
八、从问题到方案的时间线
这不是一步到位的设计，是迭代出来的：
阶段 做法 问题
第一阶段 全写 MEMORY.md 越来越长，启动越来越慢
第二阶段 拆成每日笔记文件 文件太多，查询靠 grep
第三阶段 加上 JSON 配置文件 格式不统一，管理混乱
第四阶段（现在） SQLite + FTS5 统一、快速、零依赖
每个阶段都是在解决上一个阶段暴露的问题。没有一开始就设计"完美的架构"，而是方案跟着需求长。
九、技术栈一览
Python 标准库 · sqlite3 + FTS5
单文件 CLI：data_platform.py（约 400 行）
数据库文件：data_platform.db（约 560KB）
集成方式：Agent startup 流程 + cron 任务直接调用
依赖情况：零外部依赖（Python 自带）
十、即用方案：Skill 化
这套数据平台已经打包成 QwenPaw 的独立 Skill：sqlite-fts5-data-platform。
安装后在 Agent 的启动流程中调用 startup 注入上下文，cron 任务末尾直接写库，不需要改框架代码。
Skill 包含：
完整 SKILL.md 文档（命令参考、集成模式）
data_platform.py 脚本（单文件，约 400 行，Python 标准库零依赖）
5 张基础表 + 2 个 FTS5 索引，开箱即用
想用这套方案又不想自己从头搭的，直接把 Skill 拉到本地就能跑。
📦 GitHub 仓库： lt91888/sqlite-fts5-data-platform
包含 SKILL.md 完整文档 + data_platform.py 脚本，clone 即用。
后记
这篇文章记录的不是一个完美的方案，而是一个在实践中长出来的方案。如果你也在折腾 Agent 记忆问题，希望这些经验能让你少踩几个坑。
最想传达的就一句话：别一上来就上重武器。先用 SQLite + 一个脚本跑起来，觉得不够了再升级——大概率你会发现，SQLite 撑到 10 万条数据都没问题。
代码片段和数据均来自实际运行环境。文中提到的 Agent 基于 QwenPaw 框架运行。
数据量统计截止 2026-07-25。