把数据库工具直接跑在数据旁边,而不是装到每台工程师的笔记本上——这是开源 SQL IDE LibreDB Studio 0.15 最显眼的设计取向。MIT 协议的项目 9 月 8 日发布这个更新,把"LLM Agent 当成 SQL 工具一等公民"做成了一个可在生产环境使用的方案。
一个浏览器入口覆盖十六种引擎
LibreDB Studio 部署在容器、Helm Chart 或 OpenShift Operator 里,或用 npx @libredb/studio 一行命令起在服务器;浏览器、手机、Windows / macOS / Linux 桌面打开同一个界面。它覆盖十六种数据库引擎(PostgreSQL、MySQL、Oracle、SQL Server、SQLite、libSQL、DuckDB、MongoDB、Redis、Couchbase、ClickHouse、Apache Druid、Elasticsearch、OpenSearch、Apache Trino、Apache Cassandra),共享同一套 schema 浏览器、ER 图、schema 对比与监控面板。PostgreSQL 项目、Redis、ClickHouse、Trino 与 Apache Cloudberry 官方文档都把它列入推荐列表——对开源工具是不常见的信誉信号。
Agent 走的是受审计的只读管线
0.15 把 AI 从"查询旁的解释按钮"升级成"编辑器旁的 Agent 面板"。用户写下目标——"哪个部门员工最多?""这条查询为什么慢?"——按 Start,Agent 起草 SQL、读取结果,最后写一份带引用支撑的报告。
Agent 不靠解析 SQL 挡危险,而是把只读交还给数据库:PostgreSQL 走只读事务;SQLite 每条语句前重新声明 PRAGMA query_only;DuckDB 用 READ_ONLY 引擎句柄加 SQL 守卫。所有写入与 DDL 在到达驱动前即被拒;EXPLAIN ANALYZE 因会真执行而默认禁止。这条受审计管线是 Agent 独享的——用户在编辑器里直接跑 SQL 的路径不走它,也不产生审计事件。
模型支持范围写得明确:默认 Gemini 2.5 Flash,同样支持 OpenAI、Ollama 或任何兼容 OpenAI 的端点;Agent 模式要求模型具备工具调用能力,且 README 警告 Ollama 上要靠一次真实探测来确认。
只读档案只在三款数据库上存在
Agent 模式的只读执行档案由数据库原生提供,只在 PostgreSQL、SQLite 与 DuckDB 上存在;其他十三种引擎跑 Agent 模式会以 engine-unsupported 收尾。Plan 模式作为兜底,完全不使用工具、不访问数据,只把目标翻译成 SQL 草稿给用户自己跑;它的 schema grounding 在所有十六种引擎上都可用。每次 Agent 运行都有显式上限:最多 20 条语句、60 秒数据库时间、单次读取 200 行、整轮 5 分钟 deadline。
边界在哪里
开源 SQL 工具接 LLM Agent 不是新想法,但这条路线有几个取舍值得留意:把"工具去找数据"和"用户自己用工具"切成两条独立路径;把 Agent 模式的边界用数据库原生能力来表达,而不是项目方自己写 SQL parser——后者在生产里几乎都漏过;把协议选成 MIT 而非更严格的源码可用许可,因为"不能把按席位收费的工具放进每一个你拥有的环境"——这是项目方在 README 里写出来的明确立场。对需要在自己服务器上跑数据库工具、且希望用本地 LLM 保持数据不外流的团队,这是一个值得评估的选项,前提是接受 Agent 模式只在三种数据库上可用,把其他引擎交给 Plan 模式。