本机 .db 用着顺，换台机器想接着跑会话就卡壳了。给 Coding Agent 或小助手挂一块「记得住」的存储时，本地一个 .sqlite / .db 文件最省事：SQL 熟、依赖少、离线也能写。等要对账多机状态、会话快照、跨设备续跑，单文件就开始别扭——拷来拷去容易冲突，也没有现成的推拉模型。Turso 把自己摆在「AI 时代的小数据库」这条线上，和「单纯本地 SQLite 文件」差在哪，按官方介绍页把产品线名对齐一下。
官方现在怎么切产品线
Turso 文档 Introduction 把入口拆成几张卡片，入口卡片能核到的名字是：
- Turso Database (Embedded)：嵌入式引擎，可离线、浏览器或端上跑
- Turso Cloud：托管平台，面向 Turso / libSQL 库，带 branching、分析、备份等能力（以该页表述为准）
- AgentFS：给 AI Agent 用的文件系统与状态 SDK，强调可审计
页里还提示：若需要本地读写再和云端推拉同步，从 Turso Database 与 Turso Sync 起步。价格、配额这类数字，这次没有打开定价页核实，正文不写死套餐数字。
和「一个本地 SQLite 文件」差在哪
本地 SQLite 文件：进程直接打开路径，读写都在这一份文件上。适合单机工具、嵌入式、应用自己的文件格式——这也是 SQLite 官方《Appropriate Uses》里常见的划界（同批另有一篇专写「何时用 SQLite、何时倾向客户端-服务器」，这里不重复 checklist）。它不自带多机同步协议。你要同步，就得自己设计拷贝、备份或外挂复制方案。
Turso 文档强调的是在 SQLite 兼容方向上往前走：向量检索、异步原语、并发写等能力写在介绍页的特性卡上。对 Agent 场景更直观的差异，是 Embedded 引擎 +（可选）Cloud + Sync，以及专门的 AgentFS，而不是「换个文件后缀继续单机打开」。
Sync 用法页 把同步要素写得很具体：本地路径、远端 turso://… URL、鉴权 token。应用侧显式 push() / pull()。冲突策略文档写成 last push wins。也支持先离线写本地，连通后再推——和「永远只有一份无法同步的本地文件」不是同一类产品形态。首次连接要不要从远端 bootstrap，可用参数关掉，方便完全离线启动。
AgentFS 则偏文件系统抽象：copy-on-write 隔离、状态落在可移植的单一 SQLite 库、操作可审计，并可选择同步到 Turso Cloud。文档标明仍在 BETA，生产数据要谨慎、记得备份。它解决的是 Agent 改文件 / 留状态时的隔离与审计，不是「把任意业务库自动变成全球多活」的万能开关。
介绍页还把 Vector Search、更富的类型系统、开源贡献等写进特性卡。Agent 记忆、RAG 邻近检索一类需求，可以对照「本地文件 + 自接向量扩展」和「引擎自带向量能力」两条路，仍按当天文档卡片写，不在这里编未打开的子页细节。
选型时怎么想
- 只要本机 Agent 记笔记、缓存结构化结果，且从不同机器访问：本地 SQLite 文件往往够用
- 要多端或多人共用同一逻辑库、接受显式推拉与 Cloud 鉴权：看 Embedded + Sync + Cloud 这条路径
- 要给 Agent 包一层可回放、可隔离的文件状态：看 AgentFS，并留意 BETA 提示
合规上只谈产品能力边界：数据放哪、谁持有 token、出不出境，按你所在团队的制度和云厂商条款自己审。这里不写灰区跨境教程，也不假设某一地区的默认合规结论。
Turso 不是「把 SQLite 文件悄悄变成自动同步盘」的透明替换。它是一套以 SQLite 兼容为卖点、再叠嵌入式引擎、托管与同步、Agent 文件系统的产品组合。本地文件库简单直接。要同步和托管，就要按文档接 URL、token 和 push/pull，并接受 Cloud 侧那一层运维与权限模型。
你们给 Agent 挂存储时，现在是单机 SQLite，还是已经上了带同步的托管库？卡点更多在冲突，还是在鉴权与数据驻留策略？