--- layout: post.njk source: https://yage.ai/share/turso-agent-database-product-bet-20260713.html speaker: yage.ai title: |- 从每个租户一库到每个 Agent 一库：Turso 的产品赌注与竞争版图 date: '2026-07-13' summary: 文章探讨了 Turso 如何通过将数据库的物理部署边界从租户级别扩展到每个智能体或任务级别的独立容器，实现‘Database for Agents’。核心思想是利用轻量级的 SQLite 兼容性、分支技术和新的 Rust 引擎（Turso Database）来解决 AI 系统中进度同步、状态管理和本地执行的瓶颈，从而构建一个可以随处移动、离线双向同步的状态容器。 area: tech-engineering category: ai-application tags: - agentic-workflow - database-for-agents - state-container - data-isolation people: [] companies_orgs: - Turso products_models: - Turso media_books: [] draft: true status: evergreen --- Turso 是一家围绕 SQLite 兼容数据库、边缘部署和高密度多数据库架构发展的平台。2023 年，它最初只为了解决网络延迟。他们把 SQLite 复制到边缘节点，让它离代码更近。但 SQLite 极其轻量，开发者很快发现这不仅能降延迟。我们可以用代码，给每个租户单独建一个物理隔离的数据库。到了后来，部署边界甚至缩短到了具体的一次任务。每当智能体调用一次工具，系统就为它临时克隆一个数据库分支。一旦任务失败，直接销毁该数据库，就能实现零碎片回滚。2026 年，Turso 将这一演进路线命名为 Database for Agents。 这一演进揭示了一个重要事实。“智能体数据库”并不是一种全新的数据库品类。它没有发明新的 SQL 语法，也没有重构底层存储模型。真正发生改变的，是数据库的物理部署边界。智能体、会话和任务，成了最核心的物理部署与权限边界。以前我们共用一个大数据库，依靠逻辑策略划分数据。现在，每个智能体都有一个自主掌控、随处移动的独立状态容器。 这种物理边界的跃迁，解决了 AI 系统的进度同步瓶颈。平时我们花了很多精力教 AI 怎么“回忆”。我们用向量检索和长期记忆，做“记忆召回”。但我们经常忘了教它怎么“记住当前的执行进度”。也就是管理其“执行状态”。在之前探讨智能体文件系统的文章里，我们提到过一个现象。AI 在调用各种工具时，会产生大量临时文件和运行路径。如果进度管不明白，系统很快就会乱成一团。 如果缺乏能隔离、同步任务状态的稳定底座，AI 任务极易卡住。即便它有完美的记忆检索，一旦崩溃，也无法安全恢复进度。当 AI 生命周期变长、行为边界变宽，传统框架就远远不够了。 ## 为什么单靠向量记忆和工作流数据库还不够？ 为了看清这背后的发展规律，我们可以把这个领域的演进过程拉出来看一看。 最开始，大模型一次能读的字数非常有限，多聊两句就会把前面的事忘了。所以大家当时最头疼的，是怎么往模型里塞更多的聊天背景。比如 2023 年很有名的 MemGPT 虚拟上下文管理机制，就是模仿电脑操作系统的虚拟内存，让大模型自己通过调用函数来管理内存。这个办法虽然让模型调配上下文更灵活了，但它底下用的依然是传统的数据库。它解决的是怎么帮 AI 找回记忆，至于 AI 任务跑到哪一步了，它根本管不着。 后来，大家开始做复杂的 AI 工作流和多智能体协作，AI 的生命周期变长了，不再是问一句答一句。这时候，各种开发框架开始引入类似“游戏存盘点”的设计。比如 LangGraph 的持久化设计，把数据分成了两类：一类叫“检查点”，另一类叫“跨线程存储”。检查点就像是游戏的自动存档，专门记录 AI 跑任务的每一步状态，这样哪怕出错，系统也能帮它恢复进度，或者让人类来审批；而跨线程存储则用来存用户的个人偏好这些长期不怎么变的数据。这时候的设计已经有点像数据库了，但它主要是在帮 AI 续上进度，还没办法把 AI 本地运行产生的那些临时文件和沙箱状态一并存下来。 因为 AI 跑任务的时候很忙。它不仅要查数据库表、记一些临时键值，还要不停地改沙箱里的本地文件，写工具调用的日志。如果存个文件要调用云端对象存储，存个状态要找 Redis，存个数据又要找 Postgres，AI 调一下工具就要在网络里来回跑好几趟，不仅慢，系统也复杂得要命。为了少花这些冤枉成本，大家开始把这些状态打包成一个轻量级的便携文件，让它跟着 AI 走。AI 运行到哪，这个文件就带到哪，里面既有文件路径，也有键值状态，还有审计日志。2025 年出来的 AgentFS 文件/键值/工具跟踪设计就是代表，把这些抽象全都塞进了一个物理容器里。 智能体持久化栈演进：从向量检索到独立状态容器 如果我们把 AI 的持久化方案画出来，不能只用“记忆”两个字来概括。整个结构其实可以分成四层： 最上面的一层是记忆策略层（如 Letta、Zep、Mem0），它们决定了什么记忆该留、什么该忘、怎么去组织长期记忆。 第二层是执行语义层（如 LangGraph），它们负责帮 AI 工作流打存档点，保证程序能接力往下跑。 第三层是检索索引层（如 pgvector），它们管的是向量检索和混合检索，让 AI 能快速翻箱倒柜找资料。 最下面的一层是状态底座层（如 SQLite、Postgres、Durable Objects，还有支持本地同步的 Electric/PGlite），它们提供最底层的物理存储和数据隔离。 在这四层里，Turso 的主要押注在最底下的状态底座层。它还想用 AgentFS 把上面的文件系统和键值状态也一并管理起来。所以，所谓的“智能体数据库”，并不是说要发明一种全新的 SQL 查询语言，而是要把数据库的物理部署方式和生命周期变小，让每一个 agent 都有自己独立的数据库。 ## 从物理距离到密度跃迁：Turso 产品的考古与演进 Turso 这家公司最开始的目的，根本不是做 AI 数据库。他们经历了几次转变，也把数据库的设计理念，从“每个租户一个库”进一步推向了“每个智能体甚至每个任务一个库”。 刚开始的时候，Turso 的前身是一家叫 ChiselStrike 的后端服务公司。他们当时推出的边缘数据库平台，主要是为了解决物理距离带来的网络延时。比如你的代码跑在离用户很近的边缘节点上，但你的数据库却在遥远的主服务器里，一来一回依然很慢。为了解决这个问题，他们发起并主导了开源的 libSQL 数据库分支。libSQL 和 SQLite 高度兼容，但自带原生复制功能。当时的 Turso Cloud，就是想让数据库离代码更近一些，把远程读取的延迟降到微秒级。 后来，他们发现 SQLite 的文件非常轻。传统的多租户方案是在同一个大数据库里用各种策略来隔离不同用户的数据，要是代码出个漏洞，很容易把别的数据漏出去。既然 SQLite 文件这么小，我们为什么不给每一个用户、每一个租户、甚至每一个临时任务，都单独建一个物理上完全隔离的数据库？于是 Turso 调整了商业方向，允许用户用代码去动态创建几万个独立的数据库。他们把数据库的使用思路，从“一个应用配一个大库”，变成了“每个租户都配一个独立的小库”。 做 AI 平台的开发者一看到这个方案，立刻兴奋了。他们开始用这种架构来隔离智能体的进度。比如在 Turso 托管的客户案例里，Adaptive Computer 团队在让 AI 跑代码生成和软件构建任务时，每当 AI 调一次工具或进一次沙箱，系统就会为它临时克隆一个分支数据库。AI 跑完了、没问题，就把数据合并回去；要是跑失败了，直接把这个数据库删掉。这种说用就用、说扔就扔的数据库，不仅提供了干净的隔离，还能实现零碎片的故障回滚。但当时这套办法也有个很大的缺陷，就是受限于 libSQL 的 Embedded Replicas 机制。在这种模式下，AI 虽然在本地读数据飞快，但只要一写数据，还是得通过网络发回到云端的主节点，根本做不到完全离线的本地写入。 为了打通本地能读又能写的最后一公里，Turso 团队直接重写了代码，推出了一个用 Rust 写的新引擎，叫 Turso Database。这个引擎支持异步 I/O，写并发的效率也更高，它是 Turso 新一代云平台（目前还是私有测试版，2026-04-08 发布）多项新功能的核心。在这个新架构里，他们同时推出了 AgentFS 和基于增量日志的同步机制。AgentFS 把文件系统、键值存储和 AI 工具审计日志全都封进了一个能在本地读写的 SQLite 文件里。同步层则允许这个文件在 AI 运行沙箱、浏览器和云端之间，通过显式的 push() 和 pull() 指令来回同步进度。他们在同步基准协议说明里也说，新项目不应该再用旧的 libSQL Embedded Replicas 了，应该改用这种新一代的同步架构，解决物理页同步时出问题。 把这段路连起来看，路线非常明确：最开始靠地理就近来降延迟；然后靠多库做租户隔离；接着用分支技术把生命周期缩短到每一次具体任务；最后靠新的 Rust 引擎、离线同步和 AgentFS 接口，把数据库变成了可以跟 AI 随处移动、本地执行、双向同步状态的状态容器。 不过，我们得清醒地给这些产品的成熟度划个界限。到今天为止，libSQL 引擎和现有的 Turso Cloud 已经在线上帮很多客户跑了很久，是成熟好用的产品。但是，代表未来智能体愿景的全新 Turso Database 引擎、Turso Sync 同步协议、AgentFS 接口以及新一代云平台，目前都还处于测试或私有测试阶段。它们可能还会遇到文件损坏、系统权限搞不定或者跟其它库不兼容的问题。如果把以前成熟云服务的成绩，硬套到这些还在测试的新技术上，是非常不严谨的。 ## 状态隔离与同步：谁在真正和 Turso 竞争？ 智能体数据库与持久化层竞争版图 我们没必要把所有能做向量检索、记聊天记录的 AI 工具都拉来做对比。这里最关键的区别在于：智能体数据库是把数据库的物理部署单位，直接缩小到了每一个智能体自己的私有容器里。顺着这个思路看，市场上其实有四种不一样的竞争路子。 第一种路子是 Cloudflare Durable Objects 架构。它把边缘计算和带强一致性的私有 SQLite 存储塞进了一个对象里。每个 AI 都可以有一个属于自己的对象 ID，借此动态创建并管理自己的私有状态，而且建多少个对象都没有限制。这种把计算和存储放在一起的做法，最接近 Turso 设想的“一个智能体配一个库”。但它的问题是深度绑定了 Cloudflare Workers 运行环境。你没办法把数据库文件直接下载到本地设备，或者丢进一个不受控制的第三方沙箱里跑，它没有那种能随时带走的离线双向同步功能。 第二种路子是 Neon 的云端多租户 Postgres 方案。Neon 采用计算和存储分离的架构，让你可以用代码在云端动态开辟一个个隔离的 Postgres 数据库，而且支持自动休眠和快速的数据克隆（分支）。如果你的 AI 系统要处理高并发、复杂的跨表查询，或者很依赖 Postgres 的成熟插件，Neon 绝对是个非常强大的云端后台。可它的局限也很明显：它完全跑在云端。如果 AI 跑在本地，它是拿不到本地数据库副本的，那些分支技术也只是云端的资源调度。 第三种路子是 Electric 配合 PGlite 的本地优先方案。PGlite 让你能在浏览器或者沙箱里，直接用 WASM 跑一个 Postgres。Electric 则像是一个同步水龙头，按照你设定的规则，把云端数据库里的一部分数据发给客户端。这种设计既能让本地读取飞快，又不用让每个 AI 都下载整张大表。但是，按照最新的 PGlite 同步插件已知限制来看，官方目前的同步插件还不支持把本地写的变动实时推回云端主库，也缺一套靠谱的冲突处理办法。所以，双向离线同步的闭环在这里其实还没有接上。 第四种路子是直接用最普通的原生 plain SQLite。如果你的 AI 只在单机或者单个沙箱里跑，根本不需要跟别的高级设备同步，也不需要提供远程 API 或者集中备份，那直接用一个本地 SQLite 文件就是最省钱、最干脆的办法。这种时候，去用任何托管的云端服务，都是在白白增加网络延时和运维成本。 看这些技术的时候，我们不妨多长个心眼，看看移动同步领域交过的学费。当年把客户端存储和云端同步服务绑得极深的 Realm 移动同步服务（后来被废弃了，大家可以看看当时的讨论）就给大家上过一课。在多个不同终端之间做双向实时同步，这背后的长期维护成本、多语言 SDK 的适配以及各种数据冲突的处理，难度极大。这些坑，是你在看一个完美的产品演示视频时根本想象不到的。 所以，选型时的核心问题其实只有一个：你的系统到底有多依赖双向实时同步？如果你的 AI 极大部分都跑在云端的 Workers 里，那 Cloudflare Durable Objects 就能给你提供一套非常干净完整的架构。如果你需要应付极复杂的 SQL 关联查询，或者需要和成熟的后端系统对接，那 Neon 配上云端安全隔离是更靠谱的工程决定。而 Turso 真正施展拳脚的地方，是那些要把私有 SQLite 文件直接丢进任意沙箱里、在网络时断时续的情况下在本地快速读写，等连上网后再手动把增量变动同步回云端的场景。在这个市场里，现在还没有一个能包治百病的万能解法，大家的竞争边界也都在不停地调整。 ## 选型与权衡：智能体数据库的边界与代价 单独给每个 AI 分配数据库的做法，确实解决了物理隔离和本地计算的痛点。但在实际做系统架构时，任何好处都是有代价的。其实对于绝大多数跑在云端的 AI 来说，用以前的老办法：在同一个 Postgres 数据库里用租户 ID 做逻辑隔离，再配合 Temporal 这种成熟的工作流系统，就已经足够好用、稳定了。要是你硬要在系统里塞进几十万个完全物理隔离的小数据库，很容易把原本简单的运行时问题，变成让人头疼的管理问题。 想象一下，当数据库的数量从几个暴增到几十万甚至上百万的时候，以前很简单的运维工作就变成了复杂的分布式治理噩梦。如果是单一的 Postgres 实例，改一下表结构就是一行命令、一次事务的事。但现在你有几十万个独立的 SQLite 文件，任何表结构的改动、字段的加减或索引的更新，你都得面对这海量文件怎么灰度发布、怎么保证一致、怎么回滚的难题。而且，现在的 SQLite 工具生态在面对这种“航空母舰舰队”一般的海量库时，其实还没准备好。比如开发者在工程中遇到的 tursogo 驱动迁移不兼容问题，就暴露了开源迁移库在面对底层驱动变动时的滞后和脆弱。 更重要的是，双向同步时产生的业务冲突，不可能靠底层的网络同步协议自动解决。Turso 的增量同步协议，确实能通过让你自己控制 push 和 pull 的时机，来巧妙避开网络底层的数据块冲突，但它根本不理解你的业务逻辑。如果两个 AI 分别在不同的沙箱里改了本地库的同一张订单，当你把这两个库往云端 push 合并时，云端服务器依然会面对业务逻辑上的冲突。这要求你的应用层必须自己去写数据所有权划分、乐观锁或者合并规则，底层的同步协议是帮不上忙的。 不过，给每个 AI 分配独立物理数据库的好处也实实在在。从安全性的角度来说，如果你的 AI 要去跑一些来路不明的第三方代码，直接用物理文件把数据库隔开，就能用极低的成本防止恶意代码跨账户去偷看或修改别的数据。这种纯粹以文件为物理边界的数据，不管是做打包存档、冷启动休眠，还是在不同的计算节点之间搬迁，都非常省事。而且，AI 在做本地 SQL 查询时，可以直接通过本地进程来调，完全不需要走网络，读写速度极快，特别适合 AI 在高频调工具时频繁读写数据的场景。 所以，我们在选型的时候，得想明白自己面对的实际约束。如果你的 AI 生命期很短，跑在边缘环境或者沙箱里，需要高频调用本地工具，而且需要独立的计算权限，那么用物理文件做隔离、再配合本地同步的 Turso 方案是非常契合的。但如果你做的是一个中心化的多智能体协作网络，大家需要高并发地共享和修改同一个全局事实，而且非常依赖数据库的强一致性事务，那么以前那种大家共用一个 Postgres 的老办法，依然是更可靠的选择。 ## 结语 所谓的智能体数据库，核心改变不在于查询语言的进化，而在于数据物理边界、生命周期与安全信任边界的全面收缩。在当前的工程选择中，基于 libSQL 引擎和传统 Turso Cloud 的多数据库隔离方案已经表现成熟。但在离线沙箱、双向同步等需要更强流动性的场景中，处于早期测试阶段的 Turso Database 新引擎、Turso Sync 同步协议和 AgentFS 仍需在实践中克服双向同步的业务冲突与分布式治理的复杂性。 面对新旧范式的过渡，架构设计的底层选择没有发生根本动摇。对于需要高并发全局共享、强一致性事务的中心化协作网络，共用关系数据库并采用逻辑隔离依然是最稳妥的技术选择。而对于那些追求物理隔离、高频本地工具调用且需要随身携带状态的边缘场景，便携式状态容器正在以更高的部署密度拓宽智能体系统的能力边界。