AI Agent 调用数据库时，降低误写风险要从权限、动作和提交过程同时入手。查询任务使用只读身份；写入动作收窄到固定表、固定字段和参数化操作；批量修改、删除与关键状态变更进入审批；执行过程保留任务编号、操作者、输入参数、影响行数和结果。模型负责判断意图，数据库权限与业务接口负责守住最终边界。

误写很少只由一句回答造成。真实链路通常包含用户输入、检索资料、模型生成参数、工具调用和数据库提交。任何一层把模糊内容直接传给下一层，都可能扩大影响范围。检查重点应落在数据库真正收到的身份、语句和参数上。

概念示意图：模型提出操作后，权限、参数、审批和事务共同控制数据库写入。

先把读取和写入拆开​

知识查询、报表生成和订单检索通常只需要 SELECT 权限。给这类任务配置独立的只读账号，可以直接挡住 INSERT、UPDATE、DELETE 和 TRUNCATE。读写共用高权限账号会让一次普通查询拥有额外能力，提示词中的限制无法替代数据库自身的授权。​

确实需要写入时，也不宜把通用 SQL 执行器直接交给模型。更稳妥的做法是提供范围较窄的动作，例如“更新指定工单的备注”或“把审核状态改为待复核”。动作参数采用明确字段，服务端再次检查工单范围、状态迁移和当前用户权限。​

把高影响操作停在提交之前​

模型生成的参数可以先形成变更预览，列出目标对象、修改前后值和预计影响数量。金额、权限、库存、合同状态以及批量数据变更进入人工审批。审批人看到的内容需要接近最终写入请求，只有一句“是否继续”无法帮助判断后果。

让错误有明确的退路​

能够回滚的修改应放进事务，执行失败时撤销尚未提交的变更。批量任务可以先试运行，只返回预计影响范围；正式执行时限制单批数量，并使用幂等键避免重试产生重复写入。删除类操作优先采用可恢复标记，恢复方案要在上线前实际演练。​

日志也需要覆盖数据库之外的上下文。只保存 SQL 很难解释模型为什么发起动作，只有聊天记录又无法确认数据库执行了什么。一次任务最好用统一编号关联用户请求、模型产生的结构化参数、审批结果、数据库返回和最终业务状态。​

ZGI 这类可自托管 Agent Runtime 可以把 Agent 绑定到经过批准的数据库、Skills 和工作流。ZGI 的可执行工作流支持数据库操作和审批节点，运行日志用于追踪发布后的任务；Skills 可在隔离运行环境中承接受控工具能力。配置时仍要在数据库和业务服务端设置最小权限，不能把边界只留在模型提示词里。​

上线前选十条真实写入任务，加入重复提交、越权对象、空字段、异常金额、批量范围过大和审批拒绝等样本。逐条核对数据库是否拒绝越界动作、事务能否恢复、日志能否还原过程。测试对象越接近真实写入请求，发现的问题越有用。​

GitHub：https://github.com/zgiai/zgi​

Gitee：https://gitee.com/zgiai/zgi