用 SQLite 混合检索构建代理记忆

给 Agent 做持久记忆，是否一开始就要引入独立向量数据库？作者给出的答案是：先用 SQLite 保存结构化记录，用 FTS5 检索关键词，再通过 LibSQL 扩展到云端同步。理由很直接：查交易哈希、区块号和执行记录，往往比寻找语义相似的内容更重要。

这个思路适合用来重新审视 AI 应用的存储选型。不过，原文展示的是一段链上资金监控代码，向量检索并未落地，性能数据也缺少测试过程。值得带走的是设计顺序，而不是照单全收它的性能结论。

Agent 的记忆，先分清查事实还是找相似内容

作者讨论的场景是运行在 Base L2 上的自治 Agent。它需要回答的问题包括：执行交易前还剩多少 gas 阈值、Base 的区块 21440000 上哪笔交易失败、上次流动性再平衡发生在什么时候。

这些问题并不都适合交给 embedding。

交易哈希、十六进制地址、ABI selector 都是标识符。两个地址看起来相似，不代表它们指向同一个账户。作者认为，通用 embedding 模型会把这类字符串拆成缺少业务意义的子词，单靠余弦相似度难以可靠找回目标记录。

这里需要进一步分工：

• 交易哈希、区块号等明确字段，适合用结构化条件查询。
• 日志中的关键词和上下文，可以交给全文检索。
• 意图相近、措辞不同的任务描述，才更适合语义检索。

作者提出的组合是 SQLite FTS5 的 BM25 检索，加上浮点数组点积计算语义相似度。但正文代码只实现了前者，没有展示向量生成、存储、相似度计算，也没有展示两路结果如何合并。

标题里的向量化记忆，在示例中仍是设计方向。

本地查询加云端同步，解决了哪部分问题

原文给出的路径是：Agent 读写本地 LibSQL Embedded，本地保存 FTS5 索引和向量 BLOB，再通过 HTTP/WS 同步到 Turso / LibSQL Cloud。

LibSQL 是 SQLite 的开源分支。作者看重的是 embedded replica：读操作可以在本地文件或内存完成，同时通过云端同步管理状态。

示例使用 Python 的 libsql_experimental 和 web3，通过 LIBSQL_URL、LIBSQL_AUTH_TOKEN 配置连接，本地文件是 agent_memory.db，并显式调用 conn.sync()。

业务部分连接 https://mainnet.base.org，监控 Base Mainnet 上的 treasury，CHAIN_ID = 8453。每次读取余额与当前区块号后，把地址、区块号、JSON 载荷和文字上下文写入 tx_log，再把对应文本写入 tx_fts。

这条路线减少了为检索单独访问远端服务的需要。但状态复制不等于整个 Agent 已经具备故障接管能力。私钥如何保护、多实例如何避免重复执行交易、同步失败后如何恢复，原文都没有展开。

作者称它是生产运行时实现，读者仍应把展示出来的部分当作示例审查。

FTS5 能搜到关键词，但不等于精确匹配

原文最能体现检索方式的是这段函数，它把全文搜索结果关联回业务记录：

def recall_exact_context(conn, search_term: str):
    cur = conn.cursor()
    # 使用 BM25 FTS5 进行确定性检索
    cur.execute("""
        SELECT t.block_number, t.raw_context
        FROM tx_log t
        JOIN tx_fts f ON t.id = f.rowid
        WHERE tx_fts MATCH ?
        ORDER BY rank
        LIMIT 5;
    """, (search_term,))
    return cur.fetchall()

要看的是 WHERE tx_fts MATCH ?：这里执行的是全文查询，随后按 rank 排序，最多返回 5 条。函数名虽然叫 recall_exact_context，它也没有执行字段相等判断。

因此，如果已经拿到完整交易哈希，更直接的办法仍是查询 tx_log.tx_hash。参数化传入 search_term 也不代表搜索内容失去了 FTS 查询语法，调用方仍需明确允许用户输入什么。

示例还有一个具体问题：tx_fts 使用 content='tx_log' 的外部内容表配置，但写入业务表时没有填 tx_hash，写入全文索引时却把这个字段设为 block-{block_number}。索引内容与业务表对应字段并不一致，后续读取和维护索引时需要处理。

此外，代码手动向两张表插入数据，没有展示更新、删除时的索引维护。这个细节比选了哪家数据库更影响记忆是否可靠。

我的判断

我赞同作者先识别查询类型、再决定是否需要独立向量数据库的顺序。对大量依赖标识符和运行日志的 Agent，结构化查询与全文检索应该占有明确位置。

但作者关于「数十万次交互不需要 Pinecone 或 Milvus」的判断，没有配套的容量、并发和检索质量对照数据。它是选型经验，不能直接当作通用规模边界。

性能部分也需要保留问号。原文假设云端向量查询耗时 400ms，并称 Base L2 的交易最终性约为 1 至 2 秒，随后给出本地读取 0.05 ms。然而文章在这里截断，没有测试环境、数据量或延迟分布，也没有澄清最终性的具体口径。

本地读取可能缩短查询路径，但不能据此推导整个 Agent 循环快了多少。

和独立向量数据库相比，这套方案值得验证的优势是组件更少、数据与索引更靠近。是否足够用，还得看真实查询、同步要求，以及团队愿意承担多少索引维护工作。

能拿来做什么

• 给日常 AI 编程助手保存运行记录时，先把文件路径、提交标识、任务状态等独立成字段，再决定哪些文字需要全文搜索，避免所有内容都塞进 embedding。
• 在 Node 服务接入记忆检索前，整理一批真实问题，分别验证字段查询、FTS5 和语义检索能否找回正确记录，再决定是否增加向量服务。
• 如果采用外部内容表，明确插入、更新、删除如何同步索引，并检查索引字段与原表是否一致，尤其不要直接照搬示例里的 tx_hash 写法。
• 评估 embedded replica 时，同时测量本地检索、同步和整个任务循环的耗时，并验证同步失败后的行为；单次本地读取延迟不足以支撑上线判断。