AI Agent 删库事件频发：你的数据库该如何防御？
上周一条推文在 HN 上炸了 700+ 赞：「An AI agent deleted our production database」。一个 AI Agent 在自主执行任务时，误判了 DROP TABLE 的语义，直接把生产库干掉了。
这不是段子，是正在发生的现实。
四十年的隐性契约被打破了
Arpit Bhayani 在最近的文章中指出了一个被忽视的根本问题：数据库架构的所有设计假设，都建立在「调用者是人类编写的确定性代码」这个前提上。
这个契约包括：
- 查询是开发者写的、review 过的、可预测的
- 写入是有意为之的
- 连接是短暂的
- 出问题时，有人会注意到
AI Agent 同时违反了以上所有假设。
Agent 查询的不可预测性
传统应用的 SQL 是固定的模板 + 参数绑定。你的索引覆盖了这些已知路径，连接池也是按已知并发量配的。
但 Agent 不一样 — 它「推理」出查询。不同的推理路径产生完全不同的 SQL。一个做客户分析的 Agent 可能临时构造一个五表 JOIN，这条查询从未出现在你的索引统计里。然后它在「思考」结果的时候，还占着连接不放。
这不是 bug，是 Agent 的工作方式。
防御性数据库设计模式
几个立即可用的防御手段：
1. Role 级别的 Statement Timeout
1
2
3
CREATE ROLE agent_worker;
ALTER ROLE agent_worker SET statement_timeout = '5s';
ALTER ROLE agent_worker SET idle_in_transaction_session_timeout = '10s';
5 秒超时对人类应用可能太紧，但对 Agent 来说是合理的安全阀。
2. 写权限的最小化
Agent 的数据库 Role 默认只给 SELECT。需要写入时走审批队列（write queue），由确定性代码执行实际写入。Agent 提交「写入意图」，不是直接执行 SQL。
3. 查询白名单 / 复杂度上限
用 pg_stat_statements 监控 Agent 产生的查询模式。设置 JOIN 表数上限、结果集大小限制。超出阈值的查询直接拒绝。
4. 审计日志 + 回滚能力
每次 Agent 写入都记录完整的 before/after 快照。出问题时能精确回滚，而不是只能从备份恢复。
这不是数据库的问题，是架构的问题
本质上，我们需要在 Agent 和数据库之间加一层「意图验证层」。Agent 表达它想做什么，系统验证这个意图是否合理，然后由受控代码执行。
这和微服务架构中 API Gateway 的角色类似 — 你不会让外部请求直接打到数据库，Agent 也不应该。
当你的系统中同时跑着多个 Agent、每个都在用不同模型推理时，数据库层面的防御就更加关键。像 OfoxAI（ofox.ai）这样的多模型聚合平台让开发者可以快速切换模型来测试 Agent 行为差异，但无论用哪个模型，底层的数据库防御策略都不能省。
结论
AI Agent 时代的数据库设计需要一个范式转移：从信任调用者，到零信任调用者。
不是 Agent 变坏了，是我们的基础设施还没跟上 Agent 的工作方式。现在修，比删库之后修，便宜得多。
参考：Databases Were Not Designed For This by Arpit Bhayani