Simon Willison 这次发布的 Datasette Agent，看上去很小：给 Datasette 加了一个 AI 助手。

但小，恰好是重点。

现在很多 AI agent 都急着把自己包装成“什么都能干”。Datasette Agent 反着来：它只围着 Datasette 里的数据工作。用户用自然语言提问，模型生成 SQLite 查询，执行，再把结果说清楚。需要图表、图像、代码执行，就交给插件。

这不是 ChatGPT 替代品。它更像给结构化数据装了一个可扩展操作层。

这次发布到底是什么

Datasette 是 Simon Willison 长期维护的数据发布工具，常见用法是把 SQLite 数据库变成可浏览、可查询的网站。

LLM 是他维护了三年多的 Python 库，用来调用不同大模型、管理提示词和工具调用。

Datasette Agent 是这两条线正式接到一起。

关键信息这次发布的内容对读者的影响
核心能力用自然语言查询 Datasette 中的数据不用手写 SQL，也能先摸清数据
执行方式模型生成并执行 SQLite 查询结果可追溯，但也必须审 SQL
演示模型Gemini 3.1 Flash-Lite作者强调便宜、快，能写 SQLite
本地模型可通过 LM Studio 接 Gemma 等开放权重模型个人数据场景有机会少依赖云端
扩展方式沿用 Datasette 插件机制价值不只在聊天，还在工具生态

演示里，Simon 问了一个很具体的问题：他最近一次看到鹈鹕是什么时候？

Agent 生成 SQL，从他的博客备份数据库里查 sighting 类型记录，筛选标题或正文包含 pelican 的条目，按时间倒序取前几条。

最后回答：最近一次记录是 2026 年 5 月 20 日。

这个例子不宏大，也不玄学。它好就好在链路短：自然语言问题、SQL、数据库结果、回答。用户至少知道答案从哪里来。

首批插件也说明了方向：

  • datasette-agent-charts：用 Observable Plot 生成图表；
  • OpenAI 图像生成插件.接入 ChatGPT Images 2.0；
  • Fly Sprites 插件.在持久沙箱里执行代码。

开发者如果想试，门槛不算高。原文给了一个 uvx 命令，可以把 datasette-agent 和 llm-lmstudio 一起拉起来，用 LM Studio 里的 gemma-4-26b-a4b 跑本地模型。

这对两类人最直接。

一类是已经在用 Datasette、SQLite、自建数据工具的开发者。可以拿非敏感数据先试插件和查询链路。

另一类是想做个人数据助手的人。浏览记录、博客、笔记索引、账单、运动数据，这些东西适合被查询，但不适合一股脑扔给远端服务。本地模型路线至少给了一个可试的方向。

普通企业用户不用急。它现在还是首个版本，不是现成的 BI 替代品。

真正的价值在边界，不在聊天

AI agent 这一年讲得太满。

很多产品的问题不是模型弱，而是场景虚。给用户一个输入框，再承诺它会理解任务、拆解计划、自动执行。听起来先进，落地后经常变成不稳定的自动补全。

Datasette Agent 聪明的地方，是没有从“万能助手”出发。

它先承认一个现实：结构化数据查询本来就有边界。表在那里，字段在那里，SQL 语法在那里，结果能查，错误也更容易暴露。

让 agent 操作整个浏览器、邮箱、云盘，变量太多。让它先面对 SQLite，反而更诚实。

这有点像铁路早期。铁路厉害，不是因为“想去哪都能去”，而是因为轨道铺在哪里，车就能稳定跑到哪里。边界带来可靠性。

AI agent 也一样。先有轨道，再谈速度。

和传统 BI 或数据查询工具相比，Datasette Agent 的位置也要说清楚。

对比对象强项Datasette Agent 的差异限制
手写 SQL精确、可控、可审计降低提问门槛仍要有人能看懂 SQL
传统 BI仪表盘稳定，权限体系成熟更适合临时提问和探索还不是企业级治理方案
通用聊天机器人对话顺滑，覆盖面广数据边界更清楚，工具链更具体场景窄，不该拿来包办所有任务

我更看重本地模型这条线。

Simon 提到，过去半年开放权重模型在工具调用和 SQLite 能力上越来越能用。这个判断不等于“本地 agent 已经成熟”，但至少说明门槛在下降。

对开发者来说，动作很具体：别先做万能助理，先把数据整理成 SQLite 或类似的结构化格式，再让模型站在数据旁边工作。

对小团队来说，也别急着采购一套“AI 数据分析平台”。可以先观察两件事：模型写 SQL 的稳定性，以及权限边界能不能按表、按字段、按工具收紧。

问题不在有没有聊天框。问题在聊天框后面有没有轨道。

代价还没结算：SQL、权限、插件信任链

别把 Datasette Agent 吹成 BI 革命。

首个版本就是首个版本。演示顺，不等于日常可靠。

AI 生成 SQL，最麻烦的地方是错得很安静。字段理解错、过滤条件漏掉、时间排序写反、把空值当事实，答案仍然可能说得很笃定。

数据库场景尤其危险。因为查询结果看起来天然“有根据”。用户一旦信了，后面的分析、决策、图表都会跟着偏。

所以它真正要证明的不是 UI，而是四个工程问题：

  • 工具调用是否稳定；
  • SQL 是否可审计、可回放、可解释；
  • 权限边界是否默认保守；
  • 插件生态能不能长出可信组件。

插件机制是优势，也是风险。

图表插件相对简单。代码执行和图像生成就复杂得多。沙箱是否可靠、插件能访问哪些数据、第三方工具会不会形成信任链漏洞，都不能靠“模型会判断”来解决。

这也是接下来最该观察的地方。

不是看它能不能回答更花哨的问题，而是看它在真实数据里能不能少犯错、错了能不能被发现、权限能不能默认收紧。

后续路线也沿着这个方向走。原文提到，Datasette Agent 已经影响了 LLM 0.32a0 的重构；Simon 还在探索类似 Claude Artifacts 的插件、个人 AI 助手 Claw，以及 Datasette Cloud 集成。

这些方向都指向同一件事：把模型从云雾里拉回工具链。

“天下熙熙，皆为利来。”AI agent 叙事里，很多公司卖的是想象力。Datasette Agent 这种小而硬的项目，提醒人们看另一条路：能碰什么、不能碰什么，先写清楚。

开头那个鹈鹕问题很小。

小到不像一次发布。

但它正好说明了 agent 接下来的分水岭：少一点万能幻觉，多一点可验证的工具链。模型越强，产品越要知道边界在哪里。窄到能负责，才有资格变大。