AI Agent 访问生产数据的治理模式

# 你会让 AI Agent 查询生产环境吗？

有人问一个 Agent，下季度在亚太地区应该给多少折扣。它思考片刻后回答：25%。

你会把这个答案直接用于决策吗？

这才是当你让 AI Agent 接触生产数据时真正需要回答的问题。可怕的失败不是 SQL 语句报错——SQL 报错至少会抛出异常。真正可怕的失败是：一条合法的 SQL 返回了一个看似自信、实则错误的数字，然后这个数字被写进了定价文档、业务预测或客户对话中。

**难点在于信任，而非语法**

模型可以检查数据库结构，找到看起来合理的表，自行拼出一个 join，并生成一条能够正常执行的查询。但它也可能把"月份"理解为"自首次购买起的三十天"，而非自然月。明天再问一次，它可能走另一条路径。

这种不确定性用于探索性分析尚可接受，但作为生产决策的基础则相当脆弱。在 BIRD 文本转 SQL 基准测试中，截至 2026 年 8 月 21 日，最优模型的执行准确率为 80.04%，而人类为 92.96%。排行榜会不断更新，但架构层面的问题始终存在：一条查询可以成功执行，却依然是错误的。

**更好的模式：将可信查询发布为工具**

大多数企业已经拥有能够回答关键问题的报表。这些 SQL 经过编写、审查、讨论，最终被财务、销售或运营团队认可并信任。那么，为什么还要让模型每次都重新推导这套逻辑呢？

更好的做法是：将经过审批的报表封装为受治理的 MCP 工具。为其定义清晰的名称、描述，以及类型化的输入参数（如季度、地区、业务单元），并配置访问控制。Agent 选择正确的工具并填入参数，它永远不会编写底层 SQL。(https://docs.oracle.com/en-us/iaas/database-tools/doc/database-tools-sql-reports.html?source=:so:tw:or:awr:odv:::Xarticle&SC=:so:tw:or:awr:odv:::Xarticle&pcode=)

这样一来，Agent 的职责就从"足够聪明地推导出正确查询"变成了"足够聪明地选择正确的报表"。问题相同，查询路径可信。如果答案发生变化，那是数据变了——而不是模型换了一种表达方式。

**将 Agent 视为应用程序，而非超级用户**

第二个设计问题是身份。Agent 在访问任何数据之前，都应当证明自己的身份。它应当通过企业身份系统代表某个具体用户行事，并继承该用户的权限——没有永久性的超级凭证，也不会因为请求来自模型就悄悄扩大访问范围。

策略的执行应当发生在数据所在的位置。行级、列级和单元格级别的访问控制，无论调用方是人还是 Agent，行为应当保持一致。两名员工可以提出相同的问题，却得到不同的答案——因为每个人只能看到自己有权限查看的内容。

这并不能让提示注入攻击彻底消失，但能够限制出错时的影响范围——而这正是安全团队真正需要的控制能力。

**别忘了记忆**

Agent 本身是无状态的，除非我们为其提供持久化存储上下文的地方。一旦这些记忆中包含了真实的企业信息，就需要与其他生产数据一样，配备同样基础但不可或缺的保护措施：访问规则、备份、审计和生命周期管控。

换句话说，Agent 的记忆不只是一个提示工程特性，它是一个数据架构决策。

**生产环境检查清单**

- 将持久化的 Agent 记忆存储在受治理的数据存储中。
- 对于业务关键型问题，优先使用预审报表或预定义查询路径。
- 将这些路径封装为描述清晰、带有类型化输入的工具。
- 让 Agent 继承请求用户的身份和权限。

- 在数据库中强制执行行、列和单元格策略，然后审计每一次调用。(https://www.oracle.com/security/database-security/features/deep-data-security/?source=:so:tw:or:awr:odv:::Xarticle&SC=:so:tw:or:awr:odv:::Xarticle&pcode=)

- 假设提示注入随时可能发生，并据此设计可访问数据的边界。

自然语言转 SQL 仍有其用武之地，它在探索发现、原型开发和低风险工作流中颇具价值。但对于涉及资金流动、暴露敏感记录或向业务提交关键数字的决策而言，可信查询路径才是更为稳健的默认选择。

生产环境中真正的问题不是"智能体能否查询数据库？"，而是"我们能否清楚地说明它使用了哪条路径、继承了谁的权限，以及哪些数据是可访问的？"

这就是一个炫酷演示与一个真正可以上线交付的智能体之间的本质区别。

阅读完整博客了解更多：https://social.ora.cl/6004BG6ybC