【AI Agent 打破四十年数据库契约，数据库防御改造迫在眉睫】
快速阅读：目前的数据库架构建立在“调用者是人类编写的确定性代码”这一假设之上，而 AI Agent 的加入彻底打破了这一契约。要让 Agent 安全落地，必须将数据库从单纯的存储层转变为具备防御能力的“免疫系统”。
给 Agent 直接的数据库写权限简直是疯了。
过去四十年的数据库设计逻辑其实藏着一个默认的契约：调用者是人类写的代码，逻辑是确定的，查询是可预测的，写操作是经过审核的，连接是短暂的。当这个契约被 AI Agent 撕碎时，整个系统就会面临崩溃。
Agent 的逻辑不是线性的。它会根据推理结果实时生成 SQL，这意味着你原本为“快乐路径”设计的索引和连接池，在 Agent 随机的、复杂的 Join 查询面前可能瞬间瘫痪。更有意思的是，Agent 极其擅长“重试”。如果一个 API 返回了空结果，Agent 可能会以为“没问题”，然后基于错误的前提继续执行后续操作。
有网友提到，这就像是让一个随时可能发疯的实习生直接拿着手术刀进手术室。
要解决这个问题，不能靠祈祷 Agent 变聪明，得靠防御性设计。
首先，把写操作从“直接修改”变成“追加记录”。用 Append-only 的事件日志代替简单的 UPDATE，配合 Idempotency Key（幂等键）来防止 Agent 因为重试而导致的数据重复。
其次，别让 Agent 碰原始表。给它们一层视图（View），把那些像 `stat_cd` 这种只有老工程师才懂的晦涩字段，翻译成 `fulfillment_status` 这种人类和模型都能读懂的自然语言。把 Schema 当作给 LLM 写的文档，而不是给编译器看的指令。
最后，必须控制爆炸半径。每个类型的 Agent 都应该有独立的数据库角色，权限要缩减到极致。
这种转变很痛苦，因为那些以前被视为“最佳实践”的方案，比如软删除、最小权限原则、查询标签，现在变成了维持系统生存的“承重墙”。
如果一个 Agent 决定删库跑路，你现在的系统能反应过来吗？
arpitbhayani.me/blogs/defensive-databases/