开源开发者 Simon Willison 在 2026 年 10 月 18 日发布了补丁版本 llm-tools-datasette 0.1.1。从版本号上看，这只是一次微不足道的故障修复，用来恢复 Datasette 实例作为 Tool 暴露给大语言模型的能力。
然而，这场中断并非单纯的代码疏漏，而是 Python AI 基础设施底层网络库急剧更迭所引发的连锁反应。当整个生态向更严格的网络栈迁移时，脆弱的插件依赖链与大模型调用数据库时虚幻的只读安全假象，都被这颗小小的螺丝钉彻底起获。
隐式依赖的代价：基础网络库大换血的震荡
事情的直接起因在于 LLM 0.33 将内部网络请求库全面迁移到了 httpx2。这次变更的源头是整个社区追随 OpenAI Python 3.x 体系对底层传输层的技术重组。在过往的 Python 打包体系中，主框架通常会附带安装通用库，很多轻量级插件便图省事，没有在自身的依赖清单里显式写明需求，而是坐享宿主环境带来的传递依赖。
这种默契在基础设施断代时瞬间崩塌。LLM 0.33 抛弃旧网络栈后，未将 httpx 声明为直接依赖的插件立刻在运行时遭遇类库缺失错误，llm-tools-datasette 随即陷入瘫痪。
在补丁版本 0.1.1 中，开发者将运行时依赖正式更新为 llm>=0.36 与 httpx2，并且完全剥离了对旧版 httpx 的直接声明。值得玩味的是，Simon Willison 在博客中将断裂归因于 0.33 版本的切换，但在发布包的配置文件中，却将门槛径直拉高到了 0.36，环境更严格要求 Python >=3.11。这种依赖版本的跨步升级，凸显出 Agent 插件生态在追求小巧轻便的同时，严重缺乏环境隔离与兼容缓冲。
- 风险.轻量插件过度依附宿主运行时的隐式依赖，一旦骨干网络库发生断代演进，整个 Tool 链路将面临不可预测的级联失效。
协议注解与提示词：防君子不防小人的假安全
解决加载报错只是工程维护的第一步，更严峻的命题在于工具接通之后的数据边界。在 Agent 架构与函数调用体系中，Datasette 或 SQLite 工具最核心的卖点是将结构化查询权交给模型。为了防止模型胡作非为，开发者往往会在 Prompt 里写明仅允许使用 SELECT 语句，或者依赖规范协议。
新兴的 MCP（Model Context Protocol）在行业内被寄予厚望，其中设立的 readOnlyHint 注解更是被诸多团队直接当作只读防护策略。但这本质上只是一种元数据描述，对大模型和恶意输入毫无实质拦截力。
Datasette 官方的安全机制早已给出明确警告：仅在产品界面限制表的可视性（table visibility），根本无法阻止任意 SQL 查询访问该表。只要允许模型拼接执行非受限的 SQL，哪怕给接口打上只读标签，也等同于将整座数据库完全裸露在执行上下文中。
依赖大模型的道德自律和描述性协议维持安全，无异于开门揖盗。
间接提示注入：即便完全只读，数据库依然会被掏空
许多工程团队误以为，只要在底层把数据库连接死死焊在 SQLite mode=ro 上，确保不发生写入和篡改，系统便高枕无忧。这种认知忽略了基于数据内容的被动泄露通道。
当 Agent 拥有查询数据库的能力，且同时配备了网络通信或外部 API 工具时，一种基于检索结果的间接提示注入攻击便悄然成形。
攻击者不需要任何写入权限。他们只需预先在公共留言、评论区或受信任的数据来源中埋入恶意指令文本，当模型通过 Datasette 的只读接口将这些文本检索出来并解析为上下文时，隐藏指令就会诱导模型调用其他具有联网能力的工具，将整库的敏感数据打包外发。在整个盗取过程中，数据库系统严格遵守了只读规则，但机密数据已经荡然无存。
- 建议.对暴露给 Agent 的数据源必须实施物理分库，绝不能让公开检索与机密信息共处一室；同时必须在运行时严格隔离查询工具与外发工具的联动权限。
修补一个名为 llm-tools-datasette 0.1.1 的依赖错误只需要几行配置文件，但摆在开发者面前的课题远未结束。随着 Python AI 底层库的持续更迭，以及 Agent 权限边界的日益模糊，如果开发者仍将安全寄托于模型的规矩或者协议的提示注解，那么数据防线终将被一次看似平常的查询轻易穿透。