Datasette Apps 0.3a0：让LLM在数据平台内安全搭建HTML应用

当数据平台开始「长出」应用

Datasette 一直是个偏「数据层」的工具：把 SQLite 数据库变成可浏览、可查询的 Web 界面。而 Datasette Apps 这个插件试图往上再走一层——允许用户在 Datasette 内部托管并编辑自定义 HTML 应用。

0.3a0 这个 alpha 版本并没有加入颠覆性的新能力，它的价值在于把「用 LLM 生成应用」这条路径打磨得更安全、更顺手。官方说明里写得很直接：应用可以手工编写，但通过 Datasette Agent 配合 LLM 来创建会更容易。这一版改的正是这个集成环节。

Datasette 是由 Simon Willison 开发的开源数据工具，核心思路是把 SQLite 数据库文件直接发布为可浏览、可查询、可 API 访问的 Web 界面，常用于数据新闻、开放数据发布和内部数据探索。它本身不做数据处理，而是充当「数据库之上的发布层」。Datasette Agent 则是同一生态中的对话式扩展，允许用户通过自然语言与数据库交互，并调用各类工具完成任务。插件（plugin） 是 Datasette 的扩展机制，社区和官方通过插件为其添加导出、认证、可视化等能力，Datasette Apps 正是其中之一。理解这层生态，才能看清本文所述改动为何都围绕「Agent 调用工具」展开。

从 # 开始：应用引用变成对话的一部分

最直观的变化是聊天输入框里的 # 符号。用户在 Datasette Agent 的对话中键入 #，就会触发应用名的自动补全，候选项来自当前用户有权限查看的应用。

这个设计的意义不只是省几次敲键盘。它把「应用」提升为对话里的一等公民——用户可以像 @ 某人一样引用某个应用，让 Agent 明确知道上下文指向哪个对象。补全范围受权限约束，也避免了用户看到不该看到的应用名。

配套的细节是：Agent 工具显示的「View app」按钮，以及 # 引用生成的链接，现在都会在 Datasette Agent 面板中以全屏方式打开应用。应用不再是需要跳转页面才能查看的附属品，而是嵌在工作流里的一个视图。

存储查询的授权：把权限判断交给工具

这一版真正的重头戏在权限模型上。新增的 app_add_stored_queries() 和 app_remove_stored_queries() 两个工具，让 Agent 能够管理某个应用被允许调用哪些存储查询（stored queries）。

关键约束在于：授予写查询必须先获得用户批准。读查询相对宽松，写操作则要人工点头。这是一个务实的分层——LLM 可以自由组合只读数据，但一旦涉及修改数据，人类必须介入。

app_create() 的行为也同步收紧了。现在它会在创建应用前检查两件事：每个请求的存储查询是否真实存在，以及当前用户是否有权查看它。如果涉及写查询，创建流程会先要求用户批准，然后才真正生成应用。

这套机制解决的是一个很容易被忽视的问题：LLM 生成应用时，常常会「顺手」引用一些查询，如果这些查询不存在或用户无权访问，应用运行起来就会报错甚至越权。把校验前移到创建阶段，失败得更早，也更可控。

存储查询（stored queries） 是 Datasette 中预先定义并命名的 SQL 查询，通过 datasette.yaml 等配置声明，可以带参数并以只读方式暴露为页面或 API 端点。它的关键价值在于：调用方只能执行被明确写好的 SQL，而无法拼接任意语句，因此天然适合作为应用读取数据的受控接口。同时，Datasette 的权限系统可以针对单个存储查询设置可见性，例如仅允许特定角色访问。正因如此，「应用被允许调用哪些存储查询」才成为一个需要授权的安全边界——授予写查询相当于给了应用修改数据的能力，这也是本版要求人工批准的根本原因。

为什么这些改动值得关注

把这三处更新放在一起看，能读出 Datasette 团队对「LLM 生成应用」这件事的判断：能力扩张必须和权限收缩同步进行。

一方面，Agent 能做的事变多了——可以增删应用的存储查询授权，可以创建应用，可以通过 # 被精确引用。另一方面，每一步涉及数据写入的操作都被要求人工确认，查询的存在性和可见性也在创建时被验证。这种「先放开、再设闸」的思路，比单纯限制 Agent 的能力更可持续。

对于在数据平台上构建内部工具的场景，这个方向有参考价值。让 LLM 快速生成应用原型很诱人，但如果它背后连着真实的数据库和写权限，缺乏审批环节就是隐患。Datasette Apps 的做法是把审批嵌入到创建和授权流程里，而不是事后审计。

版本定位与现实限制

需要明确的是，0.3a0 是 alpha 版本，功能仍在快速迭代中，接口和行为都可能变化。它目前的核心场景是「在 Datasette 内部托管自定义 HTML 应用」，而不是一个通用的应用开发平台；离开 Datasette 的数据和权限体系，这些能力并不成立。

另外，这次更新高度依赖 Datasette Agent。如果用户不使用 Agent 对话来创建或管理应用，那么 # 补全、查询授权工具带来的收益会大打折扣——手工创建应用仍然是可行路径，只是享受不到这些集成优化。

对于已经在用 Datasette 管理 SQLite 数据、并想让 LLM 帮忙搭轻量前端的人来说，这个版本值得跟进；对于只把 Datasette 当数据库浏览器用的用户，可以继续观望后续稳定版。