# 数据库没为 AI 代理这波操作做过设计

> 原标题：Databases Were Not Designed for This

- 来源：Hacker News 首页
- 发布时间：2026-04-24T23:41:38.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/10037
- 原文：https://arpitbhayani.me/blogs/defensive-databases/

## 摘要

Arpit Bhayani 指出，让 AI 代理直接操作数据库，会同时打破我们过去四十年默认的四条规矩：查询是写死的、写入是有人审核过的、连接是短暂的、出问题有人盯着。他给 PostgreSQL 开了几剂具体药方：给代理用的数据库角色加上 5 秒语句超时和 10 秒事务空闲超时；全面改用软删除，并记录是谁删的、为什么删；对关键数据只追加不修改，靠事件日...

## 推荐理由

我会先打个折，这篇文章不是模型发布或产品更新，属于工程评论，所以分数放在 72–77 这个区间合理。但它的切入角度很刁，把数据库的老规矩和智能体的新行为直接对撞，而且给了能落地的 Postgres 防护参数，对正在让智能体进业务流程的团队来说，这些坑和补丁比泛泛而谈的安全建议有用得多。正文没给出大规模压测数据，所以别指望它能证明这些配置在生产环境扛不扛得住，但作为一份“把 agent_worker 当不可信调用方”的实操清单，价值够了。

## 锐评

Arpit Bhayani 这篇文章点破了一个很多人还没意识到的问题：我们过去设计数据库时，默认调用方是写死的代码、有人审核、有人盯着。但 AI 代理会自己推理出各种没见过的查询，可能卡着连接发呆，也可能因为一次空返回就误判并批量写入错误数据。这个前提一变，很多老规矩都得重写。

他给 PostgreSQL 开的药方很具体：给代理用的数据库角色加上 5 秒语句超时和 10 秒事务空闲超时，防止代理占着连接不动；全面改用软删除，并记录是谁删的、为什么删；对关键数据只追加不修改，靠事件日志还原状态。这些做法把代理当成不可信的调用方来防，而不是像以前那样按人类应用的并发量去调连接池。

文章举了一个真实故障案例：代理调用旧 API 拿到空结果，误以为没问题，直接批了 500 笔交易，日志里全是“已批准”。这个例子把风险讲得很透。不过正文没给出这些方案在生产环境跑了多久、性能开销多大，也没提除了 PostgreSQL 之外其他数据库怎么适配。如果要在自己系统里落地，还得补上压测数据和回滚策略。