聊天窗口能回答问题，不等于看懂当前数据页；Agent 能生成界面，也不等于能替用户改数据。Datasette Agent 0.5a0 与 Apps 0.3a0 把聊天、数据页面和生成的应用放在同一处，并用查询权限限制应用的数据入口。
已有 Datasette 数据、想试做内部查询界面的团队可以先用它做原型。这组插件仍处于 alpha 阶段，试用重点是核对页面、查询权限和写入批准。
聊天离开数据页，问题容易变成猜测
聊天入口若要人复制表名、字段或 SQL，再回到页面核对，Agent 可能引用同名表，用户也难辨它回答的是哪次查询。Datasette Agent 0.5a0 的 panel 把对话和 Datasette 页面放在一起：Agent 可用 show_in_panel 打开表、查询结果或行页面；对话中指向同一 Datasette 实例的链接也会在侧边页面打开。用户继续在 panel 内点选页面，下一条消息会把页面变化告知 Agent，于是“这张表”有了页面指向。
这里的“同屏”有边界。show_in_panel 只接受当前 Datasette 实例的路径，并检查页面对当前用户是否可呈现；窄屏会在 Chat 与 Panel 间切换，拒绝被嵌入的页面会显示错误并提供新标签页链接。它方便核对页面，但不会验证 SQL 的业务口径。Datasette Agent 0.5a0 发布说明与项目文档分别说明了交互和限制。
应用生成之后，还要划清数据入口
Datasette Apps 可在 Datasette 内托管 HTML 与 JavaScript 应用。与 Agent 合用时，可以在对话里提出页面需求，让 Agent 创建应用，再把应用放进 panel 查看和修改。Simon Willison 的演示展示了这个组合的用法，但生成应用仍需验收。
Apps 0.3a0 增加了三层衔接。输入 # 可以引用当前用户有权查看的应用；app_add_stored_queries() 和 app_remove_stored_queries() 可以调整应用获准调用的存储查询；app_create() 在创建时会检查请求的查询是否存在、用户是否有权查看。工具结果还返回应用的相对路径，Agent 可以使用真实路径给出链接。这样“改这个应用”有了具体对象，数据入口也成了可检查的清单。Apps 0.3a0 发布说明列出了这些行为。
但 # 引用只帮助定位和提供上下文。项目文档明确说，引用应用时不会把 HTML 源码直接塞进模型上下文；Agent 要读源码还需通过要求 edit-app 权限的 app_view。引用成功不代表已获准改应用或调用查询。Datasette Apps 文档给出了这条界线。
写查询的批准发生在哪一步
存储查询是应用访问数据的受控入口。Apps 文档说明，托管的 HTML 应用通过 datasette.query() 或 datasette.storedQuery() 请求数据；应用有数据库和存储查询允许清单，请求随后仍以当前用户身份经过 Datasette 自身的查询权限检查。应用被允许调用某条查询，并不等于所有打开应用的人都能执行它。
0.3a0 对写查询加了显式批准：Agent 给应用新增写入型存储查询时，先请用户批准；创建应用时若请求的查询属于写查询，也会先询问。另一条路径是 Datasette Agent 自带的 execute_write_sql，它会展示 SQL、参数和所需权限，获得聊天中的明确批准后才通过 Datasette 写入接口执行。前者批准应用取得写查询入口，后者批准 Agent 当下执行写 SQL；两者仍受数据库写权限约束。Agent 写入文档和Apps 发布说明可对照阅读。
还要注意批准的后果。Agent 文档指出，多条写 SQL 按顺序执行，某条失败后会跳过后续语句，先前成功的语句不会自动回滚。审批前核对 SQL、参数和目标库，执行后核对实际数据。
团队怎样做一次可复核的试用
先选一份可替换的测试数据，给试用账号配置 datasette-agent，只开放需要查看的数据库、表和查询。按两个插件的安装说明装入同一个 Datasette 环境，并为 Agent 配置可用模型。版本应对照各自发布说明核对：Agent 0.5a0 和 Apps 0.3a0 都要求 Datasette 至少为 1.0a41。
接着在表或查询页面提出一个窄需求，例如“基于当前订单查询做一个按状态筛选的页面”。让 Agent 在 panel 展示它选用的表、SQL 结果与生成的应用，核对字段、筛选条件和空值处理。再用 # 引用刚生成的应用，要求增加一个只读的存储查询，查看应用获准调用的清单，并用无权访问该查询的账号验证拒绝行为。
最后才测试写入：用隔离数据和最小权限账号，请 Agent 为应用请求一条写查询，检查批准提示里的目标、SQL 与参数，拒绝一次，确认应用未获得该入口；重新发起并批准后，检查实际数据及应用访问记录。无需写入时，不开放相关权限。Apps 的沙箱还限制外部网络访问；若确需外联，应单独核查允许的来源，避免查询结果从应用流出。Apps 数据访问与沙箱文档说明了这些控制点。
真正的坑是把界面顺畅当作权限正确
同屏容易让人信任“这就是当前数据”，但页面指向正确，不保证字段口径、联接方式和聚合结果正确。表多且业务定义复杂时，还要先解决Agent 对字段与指标口径的理解。生成前保留已认可的查询和样本；生成后用同一输入核对结果。涉及金额、权限或状态变更时，审查 SQL 比审查聊天措辞更重要。
另一个坑是把应用的沙箱当成完整隔离。Apps 文档区分插件托管的沙箱 HTML 应用与其他插件提供的外部应用；两者运行限制不同。试用时要记录应用类型、可访问的数据库和查询、外联来源，以及查看者和编辑者的身份。
结论：把 Agent 的产物当成待验收的应用
Datasette 的这次组合解决了一个具体问题：Agent 生成数据应用时，使用者能同时看着数据页面和应用，并在查询授权、写入执行处停下来判断。它缩短了从问题到原型的距离，也把权限边界放在可见位置。
团队试用时，先从只读、可复算的查询开始；确认页面结果和权限清单，再考虑写入。真正可控的标准不是应用能被聊天生成，而是每个数据入口都能说清来源、权限和复核方法。
HiFox
