新智元報導
編輯：peter 東
【新智元導讀】2026 年初，當大多數企業還在仰賴資料分析師手動撰寫 SQL 查表時，OpenAI 內部曝光的一款能自主思考、推理甚至自我進化的資料分析智能體，已將資料查詢時間從「天」縮短至「分鐘」等級。
為什麼資料團隊總是在「同一個坑裡跌倒」？
答案往往不是運算力不足，而是資料表太多、定義太雜、經驗太分散：
同樣叫做「活躍用戶」，不同資料表的口徑可能完全不同；即便選對表格，也要寫出上百行 SQL 才能跑出結果，只要一個連接條件出錯，就前功盡棄。
在內部，OpenAI 做了一件更激進的事：讓由 Codex 驅動的資料智能體接管「找表—懂表—寫 SQL—校驗結果」的完整流程，透過一套六層上下文架構，補齊資料語意、接入組織知識、沉澱經驗記憶，讓工程師用「提問」取代「搬磚」。
資料查詢不再需要手動查表
「我們有大量結構相似的資料表，我花了很多時間試圖搞清楚它們之間的區別以及該使用哪一個。」一位 OpenAI 工程師的日常抱怨，道出了資料工作者的共同困境。
OpenAI 內部資料平台擁有 600PB 的資料，分布在 7 萬個資料集中。想像一下：當 OpenAI 的工程師需要分析 ChatGPT 用戶增長時，面對數十個相似的用戶表，每個表都宣稱記錄「用戶活躍度」，但定義卻各不相同。
選錯表意味著數天的努力付諸東流，更糟糕的是可能基於錯誤資料做出關鍵決策。
更令人頭疼的是，即使選對了表格，要生成正確結果也充滿挑戰。
下圖展示了一個多達 180 行的 SQL 語句，像一座難以逾越的大山——複雜的表連接、聚合操作，任何一個細微錯誤都可能導致整個分析失效。
而現在，有了由 Codex 驅動、具備自主學習能力的智能體，工程師不必再寫上百行的 SQL 查詢語句，只需要提問就能從資料海洋中找到所需資訊，例如下圖查詢中要求對比兩個時間點的活躍用戶數。
六層架構的「資料大腦」
將自然語言轉換成 SQL 語句的工具很多，但 OpenAI 內部使用的資料智能體，其核心創新在於其多層上下文架構。
最底層的基礎後設資料（Metadata）包括表結構、欄位類型等基礎資訊，為智能體提供資料圖譜的骨架。
在其上一層是人工標註，由領域專家精心編寫的表和欄位描述，捕捉意圖、語意、業務含義以及無法從模式或歷史查詢中輕鬆推斷的已知注意事項。這一層相當於給智能體對每個表的資訊進行了基礎培訓。
之後的Codex 增強層透過推導表的程式碼級定義，讓智能體能夠更深入地理解資料實際內容。這一層提供了關於值唯一性、表資料更新頻率、資料範圍等關鍵資訊。這一層的引入，讓智能體能夠明白不同表在構建、更新上的差異。
再往上的機構知識層，智能體可以存取 Slack、Google Docs 和 Notion，取得關鍵的公司背景資訊，如產品發布、可靠性事件、內部代號和工具，以及關鍵指標的規範定義和計算邏輯。
有了透過外在文本取得的背景資訊，智能體就不會犯下常識性錯誤。
例如，當用戶詢問「12 月連接器使用量為何大幅下降」時，智能體沒有簡單地報告數字下降，而是透過機構知識發現這主要是測量／日誌記錄問題，而非真正的使用量崩潰，與 ChatGPT 5.1 發布導致的資料收集變化相關。
而最關鍵的第五層學習進化，讓智能體擁有持久的記憶。當它從用戶那裡獲得糾正，或發現資料問題的細微差別時，能夠保存這些經驗供下次使用。記憶也可以由用戶手動建立和編輯。可以全局適用，也可以是只獨屬於某個使用者。
而最上一層的執行時期上下文，能夠讓智能體在沒有現有上下文或現有資訊過時時，透過即時查詢資料倉儲，直接檢查和查詢表。它還能夠與其他資料平台系統（後設資料服務、Airflow、Spark）通訊以取得更廣泛的資料上下文。
離線檢索與線上查詢間的動態切換
上述 6 層系統，是如何協同工作的？
具體可分為離線和在線兩步。
每天凌晨，智能體會系統性地掃描昨天成千上萬張資料表的實際用法與呼叫軌跡，汲取資料專家們留下的註解與洞察，並呼叫 Codex 來解讀程式碼深處的邏輯，衍生出表格背後更豐富的業務語意。所有這些散落的「知識碎片」被融合成一個統一、標準化的「知識圖譜」。
隨後，透過 OpenAI 的嵌入模型，被轉化、壓縮為一組組向量嵌入，存入高速檢索庫中。至此，一個為 AI 智能體準備的、立即可用的「資料記憶宮殿」便鑄造完成。
當用戶的一個問題抵達時，智能體不再需要像人類分析師那樣，一頭扎入後設資料的汪洋大海進行耗時的手工打撈。而是透過檢索增強生成技術（RAG），精準定位並提取出與當前問題最相關的資料表。這個過程快速、可擴展，且延遲極低。
而對於那些需要最新資料的請求，智能體則同步啟動即時查詢通道，直接向資料倉儲發起查詢請求，由此既實現了執行時期上下文的即時性，又能做到與離線知識的深度結合。於是，一個複雜的業務問題，便在離線記憶的「閃電檢索」與即時資料的「精確制導」協同下，化為秒級可得的清晰洞察。
從靜態工具到動態隊友的典範轉移
這個智能體最令人驚嘆的，不是它的技術複雜度，而是它如何融入日常工作流程，成為真正的「隊友」。與傳統的「一問一答」式工具不同，OpenAI 內部使用的資料分析智能體被設計為「可以與之推理的隊友」。它是對話式的、始終在線的，既能處理快速答案，也能處理迭代探索。
想像這樣一個場景：一個產品經理的提問不明確或不完整時，智能體會主動提出澄清問題。如果沒有回應，它會應用合理的預設值來推進工作。例如，如果用戶詢問關於業務增長但沒有指定日期範圍，它可能會假設最近七天或三十天。這讓智能體能夠一邊回覆，一邊與用戶合作得到更準確的結果。
而為了避免不斷進化的智能體在學習過程中跑偏，OpenAI 團隊利用Evals API為智能體配備了一位嚴格的監管者。
Evals API每個重要問題都配有手動編寫的，可作為「黃金標準」查詢語句，智能體的表現被持續監控和評分。
這些評估不僅檢查 SQL 語法正確性，還比較結果資料的準確性。當智能體「學壞」時，系統會立即發出警報，確保問題在影響用戶前被發現和修復。
而在資料安全方面，該智能體規定用戶只能查詢他們已經有權存取的表。當存取權限缺失時，它會標記這一點或回退到用戶被授權使用的替代資料集。
而為了確保資料分析的過程透明，智能體會在各個答案旁邊總結假設和執行步驟來暴露其推理過程。當查詢被執行時，它直接連結到底層結果，允許用戶檢查原始資料並驗證分析的每個步驟。
怎麼搭建一個資料分析智能體
OpenAI 的上述資料分析智能體，並沒有開源，不過若想手搓一個類似的智能體，OpenAI 的工程師也給出了其中踩過的坑。
最初，智能體能存取到完整的資料集，但這很快讓智能體迷失在功能重疊資料表中。為了減少歧義並提高可靠性，開發者不得不對智能體能存取的資料表進行了限制，由此減少歧義，提高查詢的可靠性。
另一個坑來自開發者給出的高度規範的系統提示詞。雖然許多問題共享類似的分析形狀，但細節變化足夠大，以至於僵化的指令會適得其反。當關注點轉向真實使用時的效果時，將如何實現交由智能體而非系統級提示詞決定，會讓智能體變得更加穩健，產生更好的結果。
而最关键的一点，是意识到相比专家对数据表给出标注，数据的真正意义存在于代码中。查询历史更精准地描述表的形状和用法，能捕获了从未在 SQL 或元数据中浮现的假设与业务意图。通过使用 Codex 爬取代码库，智能体能理解数据集实际如何构建，并能够更好地推理每个表实际包含的内容。与仅从数据仓库中获取信息相比，构建数据的代码能更准确地回答「这表里有什么」和「我何时可以使用它」。
随着企业数据环境日益复杂，类似 OpenAI 数据智能体的工具可能成为未来企业数据分析的标准配置，推动整个行业向更高效、更智能的数据驱动决策范式转变。
这些智能体的目标不是替代数据分析师，而是增强其能力，将数据分析师从繁琐的查询编写和调试中解放出来，专注于更高级别的定义指标、验证假设和制定数据驱动决策。
参考资料：
https://openai.com/index/inside-our-in-house-data-agent/
https://x.com/OpenAIDevs/status/2016943147239329872