企业数据智能体真正困难的地方，从来不是“让大模型写出一条 SQL”，而是让它在表很多、口径复杂、权限严格、数据持续变化的环境里，稳定找对表、理解业务语义、生成可验证的查询，并且在犯错时能够被发现。

OpenAI 在 2026 年公开了内部数据智能体的工程实践：数据平台服务 3,500 多名内部用户，覆盖 70,000 个数据集和超过 600PB 数据。它由 GPT-5.2 驱动，结合 Codex、Embeddings API、Evals API、MCP 与多层企业上下文，把原本需要数天的数据探索压缩到数分钟。本文不复述新闻，而是把这套方案还原成一套可以迁移到企业数据平台的工程蓝图。

说明：文中的规模、分层和产品名称来自 OpenAI 官方工程文章；架构图、伪代码与落地建议是基于官方信息做的工程化归纳，不代表 OpenAI 未公开的内部实现。

一、为什么 Text-to-SQL 只是最表面的一层

在演示环境里，Text-to-SQL 往往只有几张结构清晰的表。生产环境却完全不同：同一个“活跃用户”可能有多套口径；一张表可能包含注销用户，另一张表排除了他们；两个字段同名，却分别代表事件发生时间和数据入仓时间；历史查询还能带来错误示范。

因此，数据智能体面对的是一个组合问题，而不是一个翻译问题：

• 发现：在数万张表里找到候选数据集；
• 理解：还原字段、粒度、血缘、刷新频率和业务口径；
• 规划：把开放式问题拆成可执行的探索步骤；
• 执行：生成 SQL、运行查询、检查中间结果并调整；
• 验证：证明查询结果在语义和数据上都成立；
• 治理：始终服从现有权限、审计和成本边界。

如果只把表结构塞进提示词，模型最多知道“数据长什么样”，却不知道“数据为什么这样生成、什么时候可用、适合回答什么问题”。这正是很多企业级数据助手准确率停滞的根因。

二、600PB 规模带来的三个硬约束

OpenAI 披露的规模包括 3,500 多名内部用户、70,000 个数据集和 600PB 以上数据。这个量级会直接改变系统设计。

约束	直接后果	工程应对
上下文装不下	不能把全部 schema、日志和文档塞进一次请求	离线归一化、向量化，在线只检索最相关片段
语义持续变化	静态知识库很快过期	每日增强流水线 + 运行时实时探查
错误代价很高	语法正确不等于业务正确	结果级 Evals、权限透传、证据链接与持续回归

这意味着系统不能是“一个大提示词 + 一个 SQL 工具”，而应该是上下文平台、智能体运行时、数据执行层、验证系统和治理层共同组成的产品。

三、总体架构：离线增强与在线推理分离

可以把整套系统分成两条链路。离线链路负责把分散、异构、昂贵的知识整理成可检索资产；在线链路负责围绕用户问题按需取用最小上下文，并在执行过程中补充实时证据。

离线链路
表使用记录 + 人工注释 + 血缘 + 代码仓库 + 企业文档
          │
          ▼
归一化 / Codex 代码增强 / 权限元数据绑定
          │
          ▼
Embedding + 检索索引 + 可版本化知识快照

在线链路
用户问题 → 意图与权限 → RAG 检索 → 计划 → SQL/工具执行
                                     ↑          │
                                     └─ 结果检查与自我修正
                                                │
                              答案 + 假设 + 查询结果 + 证据链接

这种分离有两个好处。第一，在线请求不需要扫描原始元数据和海量历史日志，延迟更可控；第二，离线知识可以被版本化、评估和回滚，避免“知识库悄悄变了，但没人知道质量为什么下降”。

四、六层上下文：从表结构一直到实时数据

OpenAI 把上下文分成六层。它们不是简单堆叠，而是逐层弥补上一层无法表达的语义。

第 1 层：表使用情况

基础层包含列名、类型、上下游血缘、历史查询和常见联表关系。它回答“这张表长什么样、通常怎样被使用”。历史查询可以提供联表模式，但必须做质量过滤，不能把错误 SQL 当成最佳实践。

第 2 层：人工注释

领域专家补充表和字段的意图、业务定义、已知陷阱和适用范围。例如“收入按支付成功时间计算”“实验分析必须排除内部账号”。这些信息通常无法从 schema 推断，却决定最终结果是否可信。

第 3 层：Codex 代码增强

真正的语义常常藏在生成数据的代码里。Codex 可以沿着 Spark、Python、SQL 模型和任务配置追踪表的生成逻辑，推断粒度、唯一性、刷新频率、过滤条件和数据范围。相比只看仓库元数据，代码能解释“为什么这张表只包含第一方流量”“为什么某字段在特定日期前为空”。

第 4 层：机构知识

产品发布、事故复盘、内部代号、指标规范可能散落在 Slack、Google Docs、Notion 等系统。系统对这些文档做采集、嵌入和权限绑定，在运行时通过检索服务返回用户有权看到的片段。重点不是“接入更多数据源”，而是让文档权限与查询权限保持一致。

第 5 层：记忆

当用户纠正口径，或智能体发现一个不易从其他层推断的约束时，可以把它保存为记忆。记忆既可以有全局范围，也可以有个人范围。它适合保存稳定、可复用、可验证的事实，而不应成为无审查的聊天记录仓库。

第 6 层：运行时上下文

如果现有上下文缺失或可能过期，智能体会实时查询数据仓库，并与元数据服务、Airflow、Spark 等系统交互，检查 schema、数据新鲜度和样本分布。运行时探查是最后一道“以事实为准”的防线。

五、为什么代码增强比更多文档更重要

数据目录通常描述结果，代码则记录过程。一个 ETL 任务里的过滤、去重、窗口函数、回填逻辑和延迟容忍度，会直接决定表的真实语义。只增加文档数量，可能让检索结果更多，却不一定更正确。

生产系统可以为每张高价值表生成一份“机器可读的数据契约”，并标注证据来源：

dataset: analytics.active_users_daily
grain: one_row_per_user_per_day
primary_key: [event_date, user_id]
freshness_sla: "T+1 08:00 UTC"
exclusions:
  - internal_accounts
  - deleted_users
derived_from:
  - repo://pipelines/active_users.py#L40-L116
confidence:
  grain: high
  exclusions: high
last_enriched_at: "2026-11-09T00:00:00Z"

关键点是保留证据位置、生成时间和置信度。这样当代码更新后，可以精确判断哪些数据契约需要重算，而不是全量重建知识库。

六、智能体循环：异常结果必须触发重新规划

开放式分析很少能一次完成。智能体需要保留完整会话上下文，允许用户中途打断，并根据中间结果动态调整路径。比如联表后突然变成 0 行，系统不应直接回答“没有数据”，而应检查连接键、过滤条件、日期边界和权限裁剪。

def answer(question, user):
    context = retrieve_context(question, permissions=user.permissions)
    plan = planner.create(question, context)

    for step in plan.steps:
        result = tools.execute(step, user=user)
        evidence = validate_shape_and_semantics(result, step)

        if evidence.is_suspicious:
            context += inspect_runtime_metadata(step, user=user)
            plan = planner.revise(plan, evidence, context)
            continue

    return compose_answer(
        results=plan.results,
        assumptions=plan.assumptions,
        evidence_links=plan.evidence_links,
    )

这里的“自我修正”不能只依赖模型自信度。更可靠的做法是使用确定性信号，例如行数突变、连接放大倍数、空值比例、时间覆盖范围、总量守恒和指标上下界。

七、离线 RAG：只检索与当前问题最相关的上下文

官方方案会每日聚合表使用、人工注释和 Codex 派生增强信息，归一化后生成 Embedding，并在查询时通过 RAG 只提取最相关上下文。这比扫描原始元数据和日志更快，也更容易控制延迟。

企业落地时，建议检索键至少包含四类信号：自然语言语义、表/字段精确匹配、数据血缘邻近度、用户或团队的使用先验。最终排序不应只看向量相似度，还要惩罚过期知识、低置信度推断和越权内容。

候选上下文	适合的排序信号	常见风险
Schema 与血缘	字段命中、上下游距离、使用频次	只有结构，没有业务口径
历史 SQL	复用次数、执行成功率、所有者信誉	复制了历史错误
代码增强	证据文件、更新时间、置信度	分支或版本与生产不一致
文档与记忆	权限、时效、适用范围	口径冲突和隐式越权

八、记忆系统：保存约束，而不是保存一切

一个可控的记忆对象至少要包含内容、作用域、来源、创建者、有效期、证据和撤销机制。个人偏好与企业事实必须分开：前者可以影响展示方式，后者会影响数据口径，风险等级不同。

推荐采用“提议—确认—生效”流程。智能体先提出候选记忆，例如“实验 X 只统计门控字符串匹配的样本”；用户或数据所有者确认后才进入共享范围。对于会改变指标口径的记忆，还应触发回归评估。

九、权限模型：智能体不能获得额外数据权限

OpenAI 的智能体作为界面层接入既有安全和访问控制模型，采用权限透传：用户只能查询自己原本有权访问的表。缺少权限时，系统应明确提示，或回退到用户有权使用的替代数据集。

生产实现中要同时约束检索和执行。只在 SQL 执行阶段鉴权还不够，因为检索到的文档片段、字段名、样例值和表描述本身就可能泄露信息。权限过滤必须发生在候选召回之前或召回阶段，并且每一次工具调用都携带最终用户身份。

十、Evals：不要比较 SQL 字符串，要比较结果和语义

同一个问题可以有多种正确 SQL。OpenAI 使用人工编写的黄金 SQL 生成预期结果，再把智能体生成的 SQL 及其执行结果一起交给评估器。这样可以容忍语法差异和无害的额外列，同时关注业务结果是否一致。

def grade_case(question, generated_sql, golden_sql, warehouse):
    actual = warehouse.run_readonly(generated_sql)
    expected = warehouse.run_readonly(golden_sql)

    signals = {
        "result_equivalence": compare_result_sets(actual, expected),
        "metric_consistency": compare_business_metrics(actual, expected),
        "sql_safety": inspect_sql_ast(generated_sql),
        "evidence_quality": check_sources_and_assumptions(),
    }
    return evals_grader(question=question, signals=signals)

评估集应覆盖：找错表、多对多联表、过滤下推错误、空值未处理、时区边界、延迟数据、权限不足和口径冲突。离线回归像单元测试，线上金丝雀则用来发现真实流量中的质量漂移。

十一、工具设计：少而清晰，比多而重叠更可靠

官方经验之一是“Less is More”。早期暴露完整工具集后，功能重叠会让智能体难以选择。生产环境应把底层系统能力收敛成少量语义清晰的工具，例如 discover_datasets、inspect_dataset、run_readonly_query、publish_notebook、save_memory。

每个工具需要明确输入、输出、权限、超时、成本和幂等性。对于 SQL 工具，默认只读、限制扫描量、设置超时、禁止多语句，并返回查询 ID、执行统计和可审计链接。不要让模型直接接触连接串、密钥或管理员凭据。

十二、提示词原则：描述目标和边界，不要写死路径

另一个关键经验是“Guide the Goal, Not the Path”。过度规定每一步，会让智能体在问题稍有变化时走进错误流程。更好的提示词应该定义成功标准、不可违反的约束、必须披露的假设，以及什么时候需要向用户追问。

例如，与其要求“先查 A 表，再连接 B 表”，不如要求“选择能覆盖注销用户处理规则的数据源；若候选表口径冲突，先列出差异并请求确认；任何结论必须附查询结果链接”。这能给推理留出空间，同时让风险边界保持确定。

十三、可复用的生产落地路线

1. 从 20—50 张高价值表和 30 个真实问题开始，不要一开始接全仓库。
2. 为每张表建立 owner、粒度、主键、新鲜度、适用口径和已知陷阱。
3. 接入代码仓库，生成带证据和版本的数据契约。
4. 将离线增强、Embedding 和索引构建做成可重放流水线。
5. 在线执行只开放只读工具，并实施扫描量、超时和并发配额。
6. 建立黄金问题、黄金 SQL 和结果级评估，发布前强制回归。
7. 最后再加入记忆、工作流模板和更多企业知识源。

这个顺序很重要。没有基线评估就加入记忆，会让质量变化难以归因；没有权限绑定就接更多文档，会扩大泄露面；没有数据契约就追求复杂 Agent Loop，最终只会更快地产生看似合理的错误答案。

十四、上线检查清单

• 正确性：是否同时验证 SQL、结果集、指标和数据覆盖范围？
• 安全性：检索、执行、缓存、记忆是否全部继承用户权限？
• 可解释性：答案是否列出假设、数据源、查询 ID 和证据链接？
• 新鲜度：知识快照是否标注版本，过期时是否触发实时探查？
• 成本：是否限制扫描量、超时、循环次数和并发？
• 可运营性：错误能否回放，记忆能否编辑、撤销和审计？
• 发布治理：模型、提示词、工具、索引任一变化是否触发回归？

十五、结论：可靠性来自上下文系统，而不只来自更强模型

OpenAI 内部数据智能体给出的最重要启示是：模型能力只是起点。企业数据问答的上限，取决于上下文是否丰富且可追溯、工具是否清晰且受控、权限是否端到端透传、评估是否贴近真实结果，以及系统能否把纠错沉淀成受治理的记忆。

六层上下文解决“模型凭什么理解数据”，Agent Loop 解决“遇到异常怎么办”，Evals 解决“我们如何知道它没有退化”，权限透传解决“它能看什么”。把这四件事闭环，数据智能体才可能从演示走向长期可靠的生产系统。

参考资料

• OpenAI：Inside OpenAI's in-house data agent
• OpenAI API：Evals 指南
• OpenAI API：Embeddings 指南
• OpenAI API：Tools 指南