datasette-agent 0.2a0：Agent 会写 SQL 不稀奇，会停下来问人才稀奇

一个 Agent 会写 SQL，现在已经不算新鲜。

更值得看的，是它写完之后能不能停一下。尤其在保存查询、改数据库状态、触发外部动作之前，系统有没有机会把控制权还给人。

Simon Willison 发布了 datasette-agent 0.2a0。版本号还是 alpha，功能也不大，但方向很准：工具可以在执行中向用户提问并暂停；新增的 save_query 工具可以保存 Agent 写出的 SQL，但必须用户确认。

这一步的价值，不在“Agent 更自动”，而在“Agent 更能被打断”。

datasette-agent 0.2a0 改了什么

这次更新主要有两块：ask_user() 和 save_query。

最后一行最容易被忽略。

它不是从暂停点继续执行。用户回答后，工具会重新跑一遍，只是之前回答过的问题会被自动回放。

所以作者明确提醒：ask_user() 要放在副作用之前。保存、写入、删除、发请求，这些动作不能先做完再问。

save_query 则更具体。Agent 可以把自己写出的 SQL 保存成 Datasette stored query。保存前，界面会展示完整 SQL、拟定名称、数据库和可见性。用户必须点击 Yes，才会真正保存。

还有一个背景点要讲清：作者说，ask_user() 这个能力由他前一天借助 Claude Fable 5 构建的新 LLM alpha 支撑。这里不能读成“Claude Fable 5 独立完成了开发”，也不能读成 datasette-agent 已经有完整企业审批流。

目前能看到的，只是一个 alpha 版本里的关键产品动作。

真受影响的是写 Agent 工具的人

如果你只是看 AI 新闻，这个版本很小。

如果你在做 Agent 工具链，尤其是让模型接数据库、文件系统、内部 API，这个变化就很实在。

最相关的两类人：

• Datasette 用户和插件开发者：可以开始考虑把确认点放进工具调用链，而不是让 Agent 一路自动跑到底。
• 做数据库自动化的团队.如果要试用这类能力，更适合先放在开发环境、内部工具或低风险数据上，不适合直接当生产审批系统用。

动作也很明确。

开发者应该检查自己的工具：哪些步骤会产生副作用？哪些地方必须先问人？ask_user() 应该放在这些动作之前，而不是作为事后补救。

采用方则要克制一点。0.2a0 是 alpha。它没有宣称企业级权限治理，没有复杂审批链，也没有完整审计报表。把它当成方向样板可以，把它当成生产安全边界就太急。

这个限制反而重要。

因为 Agent 接上真实工具后，风险不再只是“模型答错”。更麻烦的是：模型答错之后，系统还真的替它执行了。

我更在意这道刹车

很多 Agent 产品喜欢展示连续执行：规划、调用工具、生成结果，一气呵成。

演示时很好看。放到数据库、运维脚本、业务后台里，就开始变味。

SQL 本身不神秘。真正危险的是它被包装成一句轻飘飘的“Agent 已经帮你处理好了”。用户看不到中间判断，也来不及拦住副作用。

datasette-agent 这次的小更新，至少把一个正确问题摆上了台面：人机协作不是让人消失，而是让人在关键节点回来。

《孙子兵法》里有一句，“善战者，先为不可胜”。放在 Agent 产品里也合适。别先急着证明模型能冲多远，先把不可逆错误挡住。

这和早期铁路有点像，但不能类比过头。火车跑得快当然重要，可没有信号、调度和刹车，速度越快，事故半径越大。Agent 也一样。模型能力越强，产品越需要把确认、暂停、记录这些土办法做扎实。

save_query 的确认框看起来很普通：展示 SQL、名称、数据库、可见性，然后让用户点 Yes。

但很多可靠系统，起点就是这种普通动作。它不炫技，却把责任边界切出来了：机器可以建议，人来批准；系统可以执行，但要留下可理解的上下文。

接下来我会看三个变量：

• ask_user() 能不能被更多工具稳定复用，而不是只服务少数演示场景。
• 保存、写入、删除这类副作用操作，能不能形成更清楚的默认约束。
• Datasette 后续是否会补上更细的权限、记录和恢复机制。

现在还看不清这些会走到哪一步。

但这次更新至少说明一件事：Agent 产品的分水岭，不是会不会写一段 SQL，而是能不能在执行前把风险摊开，让人有机会说“不”。

模型看着更强，产品反而更需要克制。datasette-agent 0.2a0 的看点，就在这点克制里。