Oracle 26.10 把 agent 运行时放进数据库：Deep NL2SQL 如何解决口径歧义

2026 年 10 月 26 日，Oracle Database Insider 官方博客在同一天署名发布了 16 条更新，横跨 agent 运行时、语义与知识、湖仓数据与安全密码学四层。这不是一次常规季度更新：数据库厂商正在把「谁定义业务语义」和「谁执行 agent 工作流」这两件事一起收进数据库内部。

最有代表性的两条是 Oracle AI Database Agent Engine 的正式可用与 Private Agent Factory 26.10 引入的 Deep NL2SQL。前者让 agent 工作流直接跑在数据库里，工作流状态也由数据库维护；后者用 Business Knowledge Graph 承载业务口径，让「哪些订单算卖出」这类问题先被澄清，再生成 SQL。湖仓侧同时补上业务语义层与 Business Simulation Engine，安全侧则一次性更新了传输加密与密码学基线。

一、16 条更新分布在四层能力上

把 10 月 26 日这批官方博客条目按能力归位，会得到一张比单条产品公告更有用的地图。最上层是 agent 运行时：Agent Engine、Private Agent Factory，以及一条讲如何用 Agent Engine 拦截营收与服务异常的实践文章。第二层是语义与知识：Deep NL2SQL 及其解释文章、湖仓业务语义层。第三层是数据与湖仓：Autonomous AI Lakehouse 扩大 Apache Iceberg 支持、新增 Business Simulation Engine。第四层是安全与密码学：ezTLS、19c 采纳 TLS 1.3 与后量子密码、Deep Data Security 授权扩展、Data Safe 数据子集化，以及一份 Deep Trust AI 架构说明。

这个分布本身就说明了 Oracle 的判断：agent 能力不是孤立的 AI 功能，而是压在语义、湖仓、密码学三层之上的东西。少了语义层，agent 生成的 SQL 只是「大概率能跑」；少了密码学与授权层，把工作流放进数据库就等于把风险也放进了数据库。

二、Agent Engine：工作流在库内跑，状态也由库管

Agent Engine 在 Oracle AI Database 26ai 中正式可用，定位是定义、执行、记忆和治理 agent 的框架，核心是一个库内 agent 执行运行时。它跑的是声明式工作流，支持 ReAct、Sequential、Parallel、Orchestrator、Router、Loop 六种模式，也可以挂人工审批节点。

几个设计决定值得单独拿出来看：

1. 状态与数据放在同一个事务边界里。工作流状态由数据库维护，工具调用与数据操作可以在同一事务语义下推进，避免了「agent 编排层和数据层各提交一半」的经典问题。
2. 确定性工作交给 SQL 和 PL/SQL。连接、计算、规则判断由数据库语句完成，模型只在需要语义解释的环节被调用，这直接压低了模型调用次数与成本。
3. 模型看到的是被裁剪过的输入。每次模型调用拿到的是按步骤授权的结构化输入，而不是数据库连接或全表访问权限。
4. 最小信息披露。涉及敏感信息的计算留在可信的数据库操作内部，只把结果契约里允许的部分交给后续步骤与模型。
5. 人工审批是一等步骤。工作流可以自主运行，但在任何有后果的动作前暂停，交给既有的应用审批流程。
6. 全链路留痕。每一次工具调用、模型调用与决策都连同输入与来源一起记录，审计可以复盘整次运行。
7. 框架基于 Open Agent Specification，工作流因此可以在兼容实现之间迁移，而不是绑死在单一运行时上。

三、Deep NL2SQL：先澄清口径，再生成 SQL

Oracle 在解释文章里把 NL2SQL 在真实企业里做不稳的原因拆成了五类，并且每一类都对应一个工程做法，而不是一句「需要更好的提示词」。

第一类是语言歧义。「top selling」到底按件数、订单额、利润还是收入算，时间窗口取年初至今、上一个季度还是去年，每种口径都合理。Deep NL2SQL 的做法是让 agent 在生成 SQL 之前识别歧义并向用户反问。

第二类是术语黑话。电商里的「L2 offerables」这种词不在通用语言里，模型只能猜。第三类是指标定义。利润、收入这些度量常常只写在应用文档里，没有沉淀进 schema。第四类是业务规则。比如「卖出」要求商品未退货且退款窗口已过，这类规则同样不在 schema 里。

第五类是反馈。一次性糟糕的回答不会给系统任何学习机会，用户说了什么、哪里错了、更好的答案长什么样，都需要被结构化地收集起来。

对应的工程结构是 Business Knowledge Graph：把相关表、业务定义、指标、规则、文档与示例问答按 topic 组织起来，agent 先定位与问题相关的 topic，再据此规划并生成 SQL。官方示例图给出的规模是财务域 350 张表与视图、供应链计划与履约域 386 张表与视图——这已经超出人手工维护 schema 说明的范围，也超出让模型「读一遍文档库再猜」的做法能覆盖的范围。

配套的工作台分工也很清楚：Knowledge Workbench 负责业务上下文的建设与维护，NL/SQL Collection 把自然语言问题与对应 SQL 并排放着供专家检查与复用，Memory 与 Annotation 工作台负责知识、记忆与批注的整理。评估工作流要求在发布知识变更之前，先用代表性问题与参考 SQL 做对比；用户反馈不会被直接写回共享知识库，必须经过专家复核。

这一条设计上的分水岭是：把「口径」当成需要版本管理、需要评估才能发布的数据资产，而不是聊天记录里的临时补充。

四、湖仓侧：业务语义层与模拟引擎

Autonomous AI Lakehouse 的业务语义层用三类材料构造可复用的数据模型：目录注解、从 Oracle AI Database 导入的 SQL 注解，以及 AI 建议的分析视图。这些模型承载维度、度量、层级、计算与 KPI，随后被 Select AI 等自然语言查询与分析能力复用，让不同入口的问答落在同一套定义上。Oracle 给出的时间口径是这批能力将在未来 12 个月内可用。

Business Simulation Engine 把 Essbase 纳入湖仓，支持回写、动态层级汇总、复杂计算与分摊，企业可以用自然语言提问、生成模拟报告，也可以对存放在 Oracle 数据库或对象存储里的数据做基于 Excel 的分析。Iceberg 侧也在扩大支持：可以用 SQL 对 Iceberg 表做增删改查，访问外部目录或 AI Data Catalog 时的性能与功能也在改进。

分析师视角里有一个可引用的量化点：一家咨询公司为一家全球制药客户做过类似的口径工程，建模 40 多个实体、标准化 85 多个 KPI，agent 上线后排查与对账所花的时间下降了约 70%。口径治理从「数据团队自己维护的文档」变成「平台上的标准件」之后，它的收益才开始可量化。

五、安全栈同日更新：ezTLS、后量子与 FIPS 140-3

同一天还落下一批安全条目，密度不低。

ezTLS 提供基于 TLS 的网络加密，且不需要客户自管证书，解决的是「想做传输加密但没有 PKI 能力」这一档客户。19c 开始采用 TLS 1.3、后量子密码学与 FIPS 140-3 模式，这是合规驱动的硬要求，而不是体验改进。Deep Data Security 把授权能力扩展到 Analytics、APEX、ORDS 与 AI agent 一侧，Data Safe 增加了数据子集化，Exadata Database Services 与 Data Safe 的集成也一并给出。

把这些放在一起看，密码学基线的推进速度已经超过大多数团队的安全评审节奏：TLS 1.3、后量子与 FIPS 140-3 模式是同时进入同一个版本的。

六、回到工程现场：这套东西落地要准备什么

如果要在一个真实环境里试这套能力，下面几件事是绕不开的：

1. 业务口径的归属与发布流程。谁有资格改 topic、评估工作流由谁跑、什么条件下才能发布，这套流程比工具本身更难建。
2. 审计留痕的落地方式。工具调用、模型调用与决策连同输入来源都要能复盘，事后补是补不上的。
3. 人工审批节点插在哪一步。写操作、对外发送、涉及金额的动作，需要先想清楚插入位置，而不是等出事了再加。
4. 模型调用成本与上下文边界。因为模型只在解释性环节被调用，成本与数据暴露面都比「全程把库交给 agent」要小，但前提是工作流里的确定性部分真的用 SQL 写掉。
5. 密码学基线的影响面。19c 切到 TLS 1.3 与 FIPS 140-3 模式之后，客户端、驱动、监控探针和中间设备的兼容性要一起验证。

参考链接

• Oracle：Introducing Oracle AI Database Agent Engine（2026-10-26） https://blogs.oracle.com/database/introducing-oracle-ai-database-agent-engine
• Oracle：Announcing Private Agent Factory 26.10, featuring Deep NL2SQL（2026-10-26） https://blogs.oracle.com/database/announcing-private-agent-factory-26-10-featuring-deep-nl2sql
• Oracle：Oracle Deep NL2SQL: Knowledge-Driven, Feedback-Improved SQL（2026-10-26） https://blogs.oracle.com/database/from-business-questions-to-trusted-sql-how-oracle-deep-nl2sql-works
• Oracle：What’s new in Oracle Autonomous AI Lakehouse（2026-10-26） https://blogs.oracle.com/database/your-data-stays-put-ai-comes-to-it-whats-new-in-oracle-autonomous-ai-lakehouse
• Oracle：Introducing Oracle Database ezTLS（2026-10-26） https://blogs.oracle.com/database/introducing-oracle-database-eztls
• InfoWorld：Oracle adds a semantic layer to ground AI agents in the business context（2026-10-26） https://www.infoworld.com/article/4240304/oracle-adds-a-semantic-layer-to-ground-ai-agents-in-the-business-context.html