首先明确一个核心判断：datasette-agent 0.2a0 解决的根本痛点，并非“让 Agent 会写 SQL”，而是让 Agent 在执行工具调用中途能够暂停、等待人工响应、恢复流程，并将每次确认行为完整记录下来。对于正在开发数据库助手、内部查询系统或AI运维工具的团队而言，这种能力比对接更多模型更切实际——许多失败案例并非模型不懂得推理，而是系统默认用户已在一开始就交付了所有权限、参数和审批。
关键信息
- 项目入口：来自 Simon Willison 的 datasette-agent，0.2a0 为 GitHub pre-release 版本，仓库为 datasette/datasette-agent。
- 核心 API：工具声明
context参数后接收ToolContext，并通过await context.ask_user(...)发起确认。 - 支持的提问类型：支持 yes/no、多选
options=[...]和自由文本free_text=True。 - 中断恢复机制：用户未回答时当前 Agent 轮次挂起，问题表单写入内部数据库，服务重启后仍可恢复。
- 使用注意事项：用户回答后工具会从头重跑，因此
ask_user()必须放在任何副作用之前。
项目来源与核心问题
datasette-agent 是基于 Datasette 构建的 LLM 驱动 Agent，旨在让模型对数据集发起查询、解释结果，并进一步操控 Datasette 的功能。0.2a0 的发布说明虽简短，却精准抓住了 Agent 工具调用中一个常被低估的问题：真实世界的工具并非纯函数。保存 SQL、修改配置、查询敏感表、将结果分享给他人——这些操作都需要用户在关键节点补充信息或给予批准。
该版本将“询问用户”内化为工具执行的一部分，而非聊天层面的临时补丁。调用 ask_user() 后，聊天 UI 会渲染成表单；问题和状态持久化至内部数据库；用户回答后，工具从头执行，并重放之前保存的答案。这里的设计取舍十分清晰：牺牲一部分执行线性，换来了可暂停、可恢复、可审计的能力。
最小使用路径或操作步骤
原文未提供完整的安装命令或 API 示例，因此无法将缺失细节补充为完整教程。可按以下检查路径进行试用：
- 目标读者需先确认自己已在使用 Datasette，或至少有一个可测试的 Datasette 数据库；请勿直接连接生产库。
- 打开 GitHub 仓库
datasette/datasette-agent，查看 0.2a0 pre-release；注意该版本依赖llm>=0.32a3。 - 在测试环境中验证工具调用链：让一个工具声明
context参数，并在需要用户确认的位置调用ask_user()，提问类型可选 yes/no、options 或 free_text。 - 模拟一次未回答中断：触发问题后重启服务，检查聊天 UI 中的问题表单是否仍在，回答后工具是否从头重跑。
- 试用内置
save_query工具时，只允许它写入测试 Datasette stored query；检查界面是否展示完整 SQL、建议名称、数据库和可见性，并确认点击 Yes 前没有写入。
核心技术点或配置与权限
这次更新有几个关键点值得拆解。ToolContext 是工具与用户交互的桥梁；ask_user() 是暂停点；llm.PauseChain 与 chain resume 负责恢复链路；SSE 事件在恢复后的工具调用中保持与实时调用一致。0.2a0 还加入了 ask_user(html=...) 参数，用于在问题上方展示可信 HTML，save_query 就利用它把待批准的 SQL 原样呈现出来。
save_query 是该机制的示范用例。Agent 可将自己生成的 SQL 保存为 Datasette stored query，但保存动作始终需要人工批准。界面会展示完整 SQL、建议名称、目标数据库和 visibility；用户点击 Yes 之前不会执行写入。这并非炫技，而是将“写入型工具调用”的最小审批闭环做了出来。
权限边界也必须前置。能让 Agent 查询，不等于能让 Agent 保存查询；能保存到测试库，不等于能写到共享 Datasette 实例。接入时至少应划分出测试数据库、只读查询、stored query 写入权限、公开可见性这四个边界，否则人类确认只会沦为 UI 上的安慰剂。
验收与失败边界
- 验收指标：触发
ask_user()后，当前轮次应挂起；问题应在聊天 UI 中以表单形式出现；服务重启后仍可回答并恢复执行。 - 审批指标：
save_query在点击 Yes 前不得写入；审批界面必须展示完整 SQL、名称、数据库和 visibility。 - 权限与隐私边界：不要让 Agent 在同一权限下同时读取敏感表、生成 SQL、保存公开查询；测试阶段应使用隔离数据库。
- 失败条件：如果工具在
ask_user()之前已经执行写入、发邮件、改权限等副作用，恢复重跑可能导致重复操作。 - 不适合扩大使用的信号：若无法记录谁批准了什么、无法回放暂停状态、无法区分测试库和生产库，则不应接入真实数据流。
这事意味着什么
对开发者而言，datasette-agent 0.2a0 提供了一种可复用的 Agent 工程模式：工具调用不必假装自己能一次完成，完全可以将不确定性显式暴露给用户。审批、补充参数、选择范围、确认 SQL——这些都应成为工具协议的一部分，而不是让模型在提示词中“尽量小心”。
它也提醒小团队做 AI 数据工具时，不必急于堆砌复杂编排。一个能暂停、能恢复、能展示完整待执行内容的确认机制，往往比更大的上下文窗口更能减少事故。短期内真正值得尝试的点，是把 ask_user() 这类机制移植到自己的高风险工具里：保存查询、删除记录、发起外部 API 写入、导出敏感数据，都应先经过可记录的用户确认。
读者决策
今天可以试的人：已经在用 Datasette、正在做数据库 Agent 或内部 SQL 助手的开发者，可在测试库中验证
datasette-agent 0.2a0的ask_user()和save_query。应该先观望的人：需要稳定版本、完整权限审计、生产级数据治理，或没有 Datasette 基础设施的团队。试用时请紧盯 3 个指标：暂停状态能否跨重启恢复；审批前是否零写入；工具重跑时是否出现重复副作用。原文证据不足的部分在于未给出完整安装流程、生产部署建议和真实权限审计方案，因此它更像一个清晰的工程原型，而非可直接投入生产环境的成品功能。
