Hex 怎麼做資料 Agent: 難的不是寫 SQL，是沒辦法驗證答案對不對

LangChain 開了一個新 podcast 叫 Max Agency，主持人是 LangChain CEO Harrison Chase，第一集找來 Hex 的 AI 工程師 Izzy Miller，聊他們怎麼做資料 Agent: How Hex builds AI agents that reason like human data analysts。

先介紹一下 Hex 這家公司。它做的是給資料團隊用的協作式 notebook: SQL、Python、文字、圖表混在一格一格的 cell 裡，做完的分析可以直接變成互動式的資料應用給別人用。他們在大家都還沒開始討論 agent 之前，就已經把資料 agent 做成產品上線了，Notebook Agent 是他們最主要的一個。

這集聊到: 哪些當年引以為傲的工程現在反而在拖累 agent、工具太多要怎麼收、不會 SQL 的商業使用者要怎麼驗證答案、使用者的 memory 為什麼會跟資料治理打架、為什麼公開的資料 benchmark 大多不能用、一個「所有模型都答錯」的 eval 題目長什麼樣、1M context 該多早壓縮，還有他自己做的一套 90 回合模擬 benchmark，測 agent 會不會越用越好。

以下是重點整理:

1. 從「一格 cell」到「一整本 notebook」

Hex 大概是第一個把 text-to-SQL 做進真實付費產品的公司，那時候底下跑的還是 GPT-3.5 turbo。但接下來一年多，他們的 AI 功能全部被限制在一個 cell 之內: 你打開一個 SQL cell，描述你要的查詢，查詢就出現，如此而已。

Izzy 說這種 single-shot 模式在資料分析「特別受詛咒」，因為資料工作本質上就是迭代的: 你拿到一個答案，第一反應通常不是結束，而是「喔有意思，那我想再看看另一個切面」。使用者心裡明明有一個很大的問題，卻只能拆成一小塊一小塊丟給 AI。

後來他們在 notebook 旁邊加了一個 sidebar，把使用者在 notebook 裡能做的事全部開放給 agent。改變的核心就是從「產生一格 cell」變成「一次產生一整串 cell」: 客戶說「我們剛上線一個新功能，幫我做一份報告看有存取權的使用者反應如何」，agent 工作 20 分鐘，交回來的不只是那個問題的答案，還包含一路上自己冒出來、也順手查完的子問題。

「內部一放出來，所有人都瘋了，大家心想: 天啊，就是這個。」

他們的目標從一開始就很明確: Hex 是一個複雜的專業工具，有上百個按鈕和功能，能不能什麼都不改、不加任何新功能，只是讓這一切都能透過自然語言存取?

2. 跟 coding agent 的差別: 資料工作沒有可驗證的獎勵

主持人問資料 agent 和 coding agent 有什麼異同，Izzy 講了兩件事。

第一是互動的節奏不一樣。現在寫程式越來越像「你先把計畫寫清楚，它去執行」: 你寫 spec、它建出來、你看結果，基本上就是 yes 或 no。但做資料分析的過程中有很多決策點，你在那些點上要說的不是「做得好/做不好」，而是「喔這有意思，要不要換個角度看?」「如果把這個維度拆開，趨勢會不會不一樣?」這種工作完全塞不進「提問、回答、結束」的框架裡。

第二是驗證。「寫程式越來越是一個可驗證的任務，這就是為什麼模型在這件事上進步這麼快，因為可以用可驗證的獎勵去訓練。」你說要一個有五個按鈕的 dashboard，它做了，五個按鈕都在、都能按，就算背後的程式碼是一堆爛東西，任務也算正確完成。

資料就沒這麼清楚。那些決策點的結果非常難驗證，光是「怎麼確認這個答案是對的」本身就是個大問題，然後才輪到「那你要怎麼訓練模型做好這件事、怎麼在 harness 裡用它」。他認為 agent 取代 single-shot 只解決了資料 AI 這個難題的前半段，驗證是還沒解開的後半段。

3. 五個 agent 長得越來越像: capabilities 是怎麼拆的

Hex 現在有好幾個 agent:

• Notebook Agent: 給技術使用者，直接在 notebook 裡寫 SQL / Python cell
• Threads: 給只想問一個問題、拿一個答案的自助使用者。介面比較像 ChatGPT 對話，程式碼被藏起來，但過程中一樣會冒出可以互動、可以往下探索的資料圖表。Izzy 說它的流程其實不是「問題、答案」，而是「問題、一大堆工作、可能還追問、岔出去探索、最後才是答案」
• 語意模型 agent: 幫你在 Hex 裡寫語意模型 (輸出是 YAML)。重點不在它會寫 YAML，而在它會去工作區裡到處翻: 讀別人的 notebook、讀別人的 Threads 對話，把大家實際在用的算法反過來補進語意模型
• 資料應用的問答 agent: 你用 notebook 做出來的資料應用，也能像 Threads 那樣對它問問題

一開始這幾個是各做各的獨立系統，於是使用者的抱怨就來了: 為什麼 Threads 不能寫 Python，但 Notebook Agent 可以? 為什麼語意模型 agent 可以讀我其他專案，Notebook Agent 不行? 既然介面看起來都差不多，使用者就預期能力也一樣。

所以他們現在在做的，是把這些能力拆成可以共用的模組，內部叫 capabilities。一個 capability 裡面打包了四樣東西:

1. 這個能力要用的工具
2. 相關的靜態 context (固定不變的說明、規範)
3. 相關的 prompt 片段
4. 一些很瑣碎但很難調的行為設定，例如「最後一輪該怎麼收尾」

用小編的話講，capability 就是一個可以掛上去的功能模組。要讓 Threads 也會寫 Python，就是把那個模組掛給它，而不是在 Threads 裡重寫一份。

那現在到底還有沒有分不同的 agent? 有。Izzy 說目前「不同的 agent 掛不同的 capability 組合」，還是分開的東西。但他加了一句「目前是這樣啦」，因為他們正在試當這些組合變得幾乎一樣的時候會發生什麼事。他對整體方向講得很直接: 這幾個 agent「基本上都在往變成同一個東西的方向走」，而且「我們的程式碼庫現在非常在變動中」。

所以比較準確的描述是: 底層正在收斂成一套共用的 capability 模組，對外還是不同的入口 (notebook 的 sidebar、聊天介面、資料應用)。他說最未定、也最有意思的反而是 UI/UX 那一層: 如果底層能力都一樣了，這些入口還需要長得不一樣嗎?

第 4 項是 Izzy 特別點出來的，因為它最難調: agent 怎麼知道該收尾了? 我們要讓它跑多久? 他們今天還是有一個硬性的迭代次數上限，撞到上限就強迫它結束。他自己並不喜歡這個設計: 「我希望根本沒有最後一輪，我想讓它一直跑下去。」

至於主迴圈本身，主持人問「最簡單的 agent 就是一個 LLM 在迴圈裡呼叫工具，你們基本上就是這樣嗎?」Izzy 說基本上就是。他們把 context 分成動態 (當下的專案狀態、倉儲 schema) 和靜態兩類，而真正有工程含量的是「context 採集」這條管線，不是那個迴圈。

他們也有 skill: 「我們叫它 guides，但完全比照 skill 的做法，有 progressive disclosure。」agent 執行時看得到工作區裡所有可用 guide 的清單，需要時才取出來讀。

底層他們自建 orchestrator。去年在使用者完全沒感覺的情況下，他們把整套系統從 single-shot、批次佇列導向的架構搬到 Temporal，換成真正的長時間工作流編排。「是個很大的工程，最糟的是你得同時維護兩套。」

4. 為模型缺陷寫的補償系統，新模型上來就變成技術債

Hex 裡每個東西 (cell、專案、資料連線) 都有一個又長又唯一的靜態 ID。早期的模型只要看到的 ID 一多就會開始幻覺: 編出不存在的 ID、或把兩個 ID 對調。症狀是 notebook 超過五六十個 cell，agent 就開始亂來。

所以他們寫了一套很複雜的系統，在短參照和真實 ID 之間做映射。這套東西後來變成 agent 的核心基礎之一，也一直有 bug 要修。

「就在這禮拜，有人跑了一次 eval，然後說: 欸，我們不需要這個了。」

「有相當多的東西，是我們當初蓋出來很自豪、而且當時確實必要的，現在反而在拖累 agent。」光是那一週就還有大概五個類似的例子。他給的規模感很具體: 五個這種補償設計，跟著模型演進一路調整很容易; 五百個就完全不是這回事。

一年前正是因為自建 harness，他們才能在那麼底層的位置補上模型的缺陷，把 Notebook Agent 做出來。但現在它就是技術債，而技術債一旦存在就很難清掉。

5. 工具太多怎麼收: 三個做法

主持人問他們有多少工具。「工具定義加起來不到 10 萬 token，但差不多就是那個量級了，太多。講清楚一點: 工具真的太多，我不引以為傲。」

Izzy 提到三條路。

一、合併重複的工具。 他們本來有 create chart cell、update chart cell、delete chart cell 這種切得很細的一整組工具，每一種 cell 類型都配一套增刪改。「我做了個測試、跑了個 eval，發現可以全部合併成一個 chart 工具，效果一樣好。」他把這種切法叫做「沒有意義的工具膨脹」: 合併掉不會損失什麼，只是他們還沒空全部做完。

二、不要在每個工具裡重複同樣的說明。 這是很多人都會遇到的問題: 同一句注意事項，要不要在每個工具的描述裡都重複一次? 寫在 system prompt 裡行不行? 只寫在其中一個工具裡，跟寫在全部工具裡一樣好嗎? 他的實測答案是「算是吧」: 可以省，但省了會有一點折損，而且不跑 eval 你根本不會知道折損多少。

三、tool search。 把工具定義從常駐 context 移出去，agent 需要時再檢索。他說這在主流 coding agent 上已經是必需品了，因為裝了一堆 MCP 之後，Claude Code 理論上可以用上千個工具。Hex 導入之後，context 的壓力小了很多。

他也點出一個結構性的原因: 命令列上的 coding agent 什麼都可以用 bash 解決，所以工具數量天然就少; 但 Hex 這種產品沒有這個選項，每個功能都得包成一個工具，所以特別容易忍不住一直加。

6. 明明可以跑任意 Python，為什麼還要做專門工具?

Notebook Agent 跑在類似 IPython kernel 的環境裡，可以執行任意 Python。既然如此，為什麼還要特地做一個「檢查某個套件有沒有裝」這種小工具?

Izzy 給了兩個理由。

第一，專門工具可以夾帶使用時機的指示。 「什麼時候該用這個工具、什麼時候該採取這個行動」這些話，在「這裡有一個 Python 工具，自己看著辦」的設計裡是沒地方寫的。工具的描述欄位本身就是最自然的行為引導位置。

第二，決定這段程式碼要不要被使用者看到。 這是資料產品特有的問題。Notebook Agent 寫的程式幾乎都會變成 notebook 裡的一格 cell，使用者看得到、可以驗證、事後也能拿去改。

但有一個例外: 他們給了 agent 一個叫 ephemeral SQL 的工具，用它跑出來的查詢不會變成 cell，跑完就丟掉，使用者也看不到。

為什麼要留這個例外? 因為回答一個資料問題之前，通常得先搞清楚一堆瑣事: 這張表真的有我要的欄位嗎? 我得 join 哪兩張表? 這個欄位裡的日期是什麼格式?

這些事有兩種問法。一種是邊做邊試: 丟一個查詢、拿到錯誤、發現不對、再改、再改。但這樣使用者就得看著 notebook 裡同一格 SQL 被改五次。另一種是讓 agent 先在背景跑一連串很小的探索性查詢，資訊蒐集夠了再一次把主查詢寫對，然後才放進 notebook。Hex 選第二種，因為對使用者來說體驗好很多。

代價是兩個很典型的副作用:

副作用一: agent 開始口說無憑。 使用者問一個簡單問題，agent 私下跑了個 SQL 就直接把答案講出來。使用者說「圖呢? 證據呢?」agent 說「相信我」。

副作用二: 模型會在背景查到失控。 現在的模型拿到可以私下查證的能力之後，會很想在回答你之前先確定自己是對的。「特別是 GPT-5 系列。你問 GPT-5.4 一個問題，如果那是個錯的問題、而且結果很複雜，看它當下的狀況，它可能會先跑 50 個 ephemeral SQL 查詢確認清楚，才開始做真正的工作。」

所以這節的取捨很清楚: 給一個萬用的 Python 工具最有彈性，但你就失去了在工具這一層管理「什麼時候該做什麼」和「什麼該給使用者看」的能力。Hex 選擇多做一些專門工具，換這兩件事的控制權。

7. 讓使用者跟著看 agent 工作，可能撐不了多久

Izzy 對那種 agent 思考時顯示的可愛碎碎念文案很有意見: 「我在公司大概被當成那種愛耍寶的人，而我最像 Grinch 的一個意見，就是我討厭那個 noodling 的小東西。」內部有人做過一版，被他擋掉了。他們的做法很單純: 執行中就寫「thinking」並展開它正在做什麼，做完就收合起來。這其實就是 Hamel Husain 講的漸進揭露: 需要建立信任的時候攤開，信任建立後就收起來。

但這節真正的觀點在後面: 他認為「把過程展開給使用者看」這件事，很快就不需要了。

工程師其實已經不在乎過程了，「手離開鍵盤，讓它跑 50 分鐘，只要做對我不在乎它做了什麼。」他自己用 Codex 是直接把輸出關掉的。商業使用者目前還比想像中更想跟著看，但他預測這是那種今天讓人很滿意、幾個月後會拚命想拆掉的設計。

原因有兩個: 模型越來越快 (他提到 GPT-5.3 Codex Spark 那種速度)，快到根本沒辦法即時呈現; 而且如果要平行跑一百個工具呼叫，硬要讓使用者跟著看，反而限制了 agent 能做多少事。

8. 資料 agent 的驗證問題: 為什麼「展示過程」不夠

為什麼 notebook 這麼適合 agent? 因為 notebook 本來就是自我記錄的: 每一格程式碼旁邊就是它的輸出。agent 做完一份分析，整條推導過程攤在那裡，技術使用者可以一格一格檢查。

但商業使用者檢查不了。 他不會 SQL、不會 Python，你把 20 格 cell 攤給他看，他也判斷不出對錯。Izzy 講了一句蠻重的話: 「以引用和可驗證性來說，展示工作過程不是資料工作的正確概念。它需要的是某種更強的驗證、信心或準確度的形式。」

編按: 小編最近也整理過 Hamel Husain 的「很難 eval」是產品設計的警訊，那篇的第一個正面案例剛好就是 Hex: Hamel 拿 Hex 的 chat + notebook 雙介面當「把驗證路徑攤開給使用者看」的模範。結果 Hex 自己的 AI 工程師在這裡說，這對商業使用者還不夠。

兩邊其實沒有衝突，只是講到了不同層。Hamel 那篇整理出四個設計提問，第二個是「使用者手上有什麼可信的東西可以對照?」對技術使用者來說，攤開的 notebook 就是可以對照的東西; 但商業使用者沒有能力對照，就得換一個東西給他。語意模型正是資料領域對這個問題的答案: 對照的對象不是那 20 格 SQL，而是資料團隊已經審核過的指標定義。

那信心要從哪裡來? 主持人問他有什麼想法，Izzy 的第一句話是「我們還沒把這件事想通多少」。他接著說，資料領域有一個很明顯的辦法: 語意模型 (semantic model)。

語意模型是一份由資料團隊維護的定義檔。裡面寫清楚: 「營收」到底怎麼算、要用哪張表的哪個欄位、要不要扣掉退款;「活躍使用者」的定義是什麼; 這些指標可以按哪些維度切; 表跟表之間該怎麼 join 才不會算錯。工具上他提到的都是既有的東西: dbt 的 semantic layer (Hex 可以直接匯入)、Hex 今年新增的語意模型編寫功能，以及他前公司 Looker 那一套。他沒有推薦特定廠商，重點在有沒有這份定義，不在用誰家的。

有了它，agent 產生查詢的時候就不是自己看著 schema 猜「營收大概是 orders.amount 加總吧」，而是照一份已經被資料團隊審核過的定義去組。換句話說，「這個數字算得對不對」在定義那一層就已經被人類確認過了，agent 只是套用。這就是為什麼可以大致相信答案是對的。Hex 另外還搭配管理員背書、資產驗證這些機制，作用是一樣的: 讓 agent 只在受治理的範圍內工作。

但他馬上就講了語意模型的三個限制，所以這不是他給的答案，只是「其中一種辦法」:

1. 人總是有辦法搞死自己。 他自嘲以前用 Looker 那套完美的語意模型，照樣會出包
2. 模型很愛自己寫 SQL。 你給了它定義，它還是會想繞過去自己算
3. 有時候「超出語意模型」本身就是任務的重點。 客戶要的分析常常沒有現成定義可用，這時候 agent 得自己決定要 join 哪些表、指標怎麼算，沒有人先幫它把關

更麻煩的是資料領域的「真相」本身常常就是模糊的: 兩個團隊對同一個指標的定義不同、一次 pipeline 更新就把你腳下的數字換掉。

所以他的原話是「這真的是一個很難的領域」，而 Hex 實際在做、也打算繼續做的方向不是語意模型，是大量的回饋迴路: 從使用者流回資料團隊。這就是下一節。

9. Context Studio: 讓客戶的資料團隊持續修正 agent

Hex 的客戶通常是有資料團隊的公司: 資料團隊負責維護倉儲和指標定義，其他部門的人 (業務、行銷、產品) 是來問問題的使用者。以下講的資料團隊都是指客戶公司的，不是 Hex 自己的團隊。

上一節的問題是: 商業使用者無法自己驗證答案。Hex 的回答不是「讓 agent 變得永遠不出錯」，而是把錯誤導回客戶的資料團隊，讓他們去修 context。

Context Studio 就是 Hex 產品裡做這件事的介面，給客戶公司的資料團隊管理員用。它讓管理員看到整個工作區的全貌: 大家在問什麼問題、拿到什麼答案。

但沒有人想每天讀幾百段對話，所以 Hex 另外跑一個 LLM 當評審，自動標記出可疑的案例: 可能出錯的、agent 看起來搞混的、或是跟語意模型有衝突的。管理員只要看被標記的那些，然後回頭去修 context: 改 guide、改語意模型、補倉儲的說明。下次同樣的問題就不會再錯，也可以順便通知當初問錯的那位使用者。

Izzy 明講今天這整套都是「事後」跑的，人在迴路裡。他們內部已經在原型一個 context agent，目標是讓 agent 自己去彙整這些回饋、更新 context。

順帶一提，Hex 自己的 AI 工程師另外還有一套內部的可觀測性和實驗系統，跟 Context Studio 不是同一套。「我有個在公司內部一直吵不完的意見: 它們應該要是同一套。」他認為兩邊都該往更高層次走: 真正該看的不是原始對話，而是 production 裡的問題分群、失敗類型、以及這些分群隨時間怎麼變化。主持人提到 Anthropic 的 Clio 就是這個想法，LangChain 也把類似機制做進了 LangSmith。

10. Memory 的難處: 使用者記錯的東西會跟治理打架

使用者心目中的 memory 是很個人的: ChatGPT 記得你有一隻叫 Rover 的狗。但同樣的東西放到資料團隊眼裡，「有點恐怖，其實不是有點，是非常恐怖」。

想像一個場景: 使用者跟 agent 說「不對，這個指標的定義應該是這樣」，而使用者其實記錯了，或那個定義已經過期。這句話一旦被存進 memory，就跟資料團隊訂下的語意模型直接矛盾。

而模型處理矛盾 context 的能力目前非常差。他們做過一個實驗，測的不是模型能不能正確化解矛盾，而是它會為此花掉多少時間。Claude Sonnet 4.6 在一定範圍內跑得相當有效率; 但只要注入一段跟它已知資訊衝突的 context，它會花 30 分鐘反覆糾結「等等、我看看、嗯、其實⋯」，進入一種完全停不下來的狀態。他說這件事其實一直以更小的規模在發生。

Hex 目前的做法是把 context 按來源分層。 資料團隊訂的語意模型和 guide 是一層，使用者個人的 memory 是另一層，兩者存在不同的地方，使用者的 memory 不會混進資料團隊管的那一份、也不會覆寫它。Izzy 說他們對推出 memory 很謹慎，「還有更多測試要做」。

他也坦承這件事沒有標準答案。管理員需要能提供夠強的治理，而這有兩種極端: 一種是全部走語意模型，什麼都照規定來，但那樣就失去了彈性分析的空間; 另一種是「你就直接告訴 LLM，然後它會小心處理」，也就是大家現在在做的 guide、rules 檔、skill。真正的難題是當這幾層說法互相矛盾的時候，誰說了算。

11. 「大多數 eval set 都是爛的，除非有人在持續維護它」

問到 eval 資料集該多大，Izzy 說他意見很多，第一句就是: 「一般來說，大多數 eval set 都是爛的，除非它一直有人在維護。」

他說在資料這個領域，幾乎每次他打開一個 benchmark 去看裡面的內容，都會很失望: ground truth 是錯的、評分方式有問題、有人想做確定性評分 (這是很值得敬佩的追求) 結果腳本有 bug、或是不接受把百分比寫成小數。還有些題目根本就出得不好、或不具代表性。

他舉了一個具體例子: 有個很熱門的 benchmark，他們自己也在用改編過的版本。這個 benchmark 很難，除非你知道它的秘密是什麼。裡面非常多題目其實都在考同一件事，就是 agent 有沒有把空陣列當成 null 看待。這條規則藏在某本手冊的角落，答案對錯全看這個。

「這不是資料 benchmark，這是 needle in a haystack、是 context 注意力 benchmark。」他認為很多 benchmark 把 SQL 語法、檢索、大海撈針這些東西，跟真正該測的分析行為與科學推理混在一起了。

主持人接了一句很準的類比: 這就像拿 tab 補全來評估一個 coding 模型，但大家實際上是要它寫完整的功能。

12. 好的 eval set: 小到你自己記得住，但跑很多次重複

他的第一個意見: 好的 eval set 應該小到你 (作為那個在乎它的人) 能整份記得住。「這可能很有爭議」，但他要能說出每一題為什麼會失敗。他們有幾組很艱難的目標型 eval set，所有 agent 都做得很差 (Opus 4.6 Max 在超難那一組大概 20%)。他認為這種 eval set 要有用，前提是你講得出它為什麼失敗、失敗有哪四種原因。

所以那些失敗模式是他一題一題手工設計的: 「我很費工地手工打造了這些失敗模式，我把它們叫做陷阱，是我希望模型掉進去的。」相對地，前面提到的空陣列 benchmark 有三四百題，但大多數只是同一個陷阱的變形。他的做法是留幾個你記得住的陷阱題，然後在上面跑很多次重複，而不是把題目擴散成一堆不同案例、讓事情變複雜。他們這類極難題的 eval set 大概就 30 到 50 題。

第二個意見: 現在很多資料 eval set 已經不能代表使用者真正在做的事了。它們大多是那種一問一答的猜謎題，「2019 年 4 月 16 日我們有多少使用者?」，本質上是在問「你能不能把這句英文重排成 SQL 語法」。

Hex 最有意思的那批 eval 則是這樣設計的:

一般的資料 eval 是給一個乾淨的環境加一個問題。Hex 的做法是先準備好一個已經做了一大半的複雜 notebook: 裡面已經有十幾格 SQL 和圖表，看起來就像某個分析師做到一半的專案。而使用者的輸入只有一句話: 「這數字很奇怪，跟我預期的不一樣。」

題目在資料和 SQL 裡埋了三個連環 bug。從 notebook 目前顯示的狀態，只看得出第一個; 第二和第三個被第一個蓋住了，要先修好第一個，後面兩個才會浮現。所以 agent 沒辦法看一眼就交差，得真的走完一整輪排查。

這跟「把這句英文翻成 SQL」的距離差很遠，但接近真實工作太多了。這些題目多半是照著他們內部的真實情況改的，「因為資料本來就難，我們自己內部也會犯錯」。

13. 那題所有模型都答錯的 eval: 全公司業務都達成 900% 配額

fan-out 是資料工程裡最常見的錯誤之一: 做 join 的時候，如果右邊那張表對左邊的同一列有多筆對應，結果的列數就會被放大。例如一個業務有 3 筆佣金紀錄，跟成交紀錄 join 之後，這個業務的成交金額就被重複算了 3 次。這種 bug 不會報錯，只會讓數字悄悄變大。

Izzy 拿了一個真實的內部 dashboard (內容是業務代表的配額達成率)，刻意在裡面埋了一個 fan-out bug，讓所有業務看起來都超級猛: 每個人至少達成 900% 配額，史上最強一季。

然後你問 agent: 這一季表現最好的人狀況如何?

每個 agent 都說: 天啊，這是史上最好的一季，跟上一季比根本是階躍式成長，Josie 達成了 1200% 配額，大家都超嗨。

他實測過，數字要一路調到幾千個百分比，模型才會開始說「這可能有資料準確性或 pipeline 的問題」。而且幾乎沒有任何一個模型會自己抓到那個 bug。目前測過的所有模型都失敗，比較新的模型也只是撐得比較久而已。

但只要你回一句「這看起來不太對」，它十秒就找到了。

Izzy 的結論是: 這類事情上，有沒有人在迴路裡差很多。用他的說法，agent 的耳朵不會像人類分析師那樣豎起來。

小編覺得這題設計得好的地方在於，它測的不是模型會不會寫 SQL，而是它有沒有那個「等等，這數字不合理」的反應。這是資料分析師最核心的能力之一，剛好也是現在最難用 benchmark 表達的能力。他們當然也維護一組正常的日常 eval，用來防退步和評估新功能，但他認為同時保有一組「專門量測模型現在全都做不好的事」的目標型 eval，價值很高。

14. 追新模型的實務: effort 怎麼設、context 累積到多長該壓縮

「資料分析和資料科學是需要通用智慧、而不是領域智慧的任務」，所以 Hex 永遠追最新最聰明的模型。目前 Opus 4.6 和 GPT-5.4 在他們的領域都非常強，但要說誰最好沒那麼容易: GPT-5.4 表現好一點，但花兩倍時間; 把 effort 調低就快一半，可是又沒那麼好了。

Effort 這個從 Opus 4.5 和 GPT-5.3 開始出現的設定，他坦承自己還沒完全搞懂 (「OpenAI 內部好像叫它 juice，蠻好笑的」)。他們做過一次內部測試，給使用者一個 effort 選擇器，收到的回饋是: 「這個有在動嗎?」因為低 effort 的時候模型有時反而搞混、開始反覆試錯; 高 effort 有時候反而一下就答完了。他們現在的做法是固定跑在一個「eval 表現夠好、又不會讓使用者為了一個簡單問題等十分鐘」的 effort 上。

最實用的一段是 1M context 該怎麼用。

agent 跑久了對話歷史會越積越長，撐爆 context 窗口。所以 harness 會在累積到某個長度時做 compaction (壓縮)，把前面的歷史摘要成一小段、騰出空間再繼續跑。問題是這個門檻該設在哪裡。

Izzy 對 1M context 的判斷是: 幫助有限、甚至有點反效果，因為你沒辦法真的把窗口填滿而不損失智慧，「模型在窗口的尾端會開始做奇怪的事」。所以結論是要很早就壓縮。

但保留 1M 的存取權 (透過 beta header) 還是有價值的，因為這樣他們可以把門檻設在 30 萬而不是 20 萬 token，實測那樣效果最好。也就是說 1M 的價值不在於真的用到 100 萬，而在於讓你有本錢把壓縮門檻往後推一點。

至於各家 API 一直冒出來的新功能 (tool search API、由 API 端代跑的 compaction)，Izzy 說有幫助的他們都用。自建 harness 加上有 eval 的好處，就是他們可以實際證明「這個有幫助」。

但他對實驗室的另一種說法有保留: 「我覺得他們現在對我們用的心理戰術，就是 in distribution 這個詞。」意思是你用他們的 agent SDK、用他們 server-side 的狀態化執行，你就落在模型訓練的分佈裡。他不否認這可能是真的，但他懷疑: 一旦你加進自己那個畫圖表或寫 SQL 的自訂工具，是不是又出了分佈? 還是掉進那種「不管你的工具，我要用 Perl」的狀況?

而且從實務上看，「模型用我們的 harness 用得相當好」，這些模型的 in-context learning 很強。要為了一個他還沒有量化直覺的好處交出這麼多控制權，對現在的 Hex 來說很難。

15. Metric City: 90 個回合的模擬，測 agent 會不會越用越好

Metric City 是 Izzy 自己做的一套 benchmark，不是 Hex 的產品功能，目前還在他說的「瘋狂科學實驗室」階段。它跑 90 個回合，一個回合代表模擬世界裡的一天，實際跑完不需要 90 天。它測的對象是模型本身的行為，不是 Hex 的 agent: 整個模擬跑在一個他自己寫的、工具很簡單的 harness 裡 (他說很想把 Hex 的 agent 放進去跑，但還沒想出怎麼做)。

為什麼要這樣測? 因為 Hex 這種產品的價值不在第零天。他甚至講了一句對自家產品很誠實的話: 第零天的 Hex 跟「Claude 接一個 Snowflake connector」比起來，大概也就是差在比較有主見、比較好用而已，「說不定一樣好」。真正的價值是隨時間累積出來的，到第 90 天那是完全不同的局面。

但現在所有的 eval 都只測第零天。「一次性的 eval 對我來說不算誠實地評估 Hex 這種系統。」pass@k 也不算，那只是平行多跑幾次而已。「現在大多數 eval set 就像是問『馬來西亞總統是誰』，答錯了，然後你就再也不會回頭去看它，什麼價值都沒產生。」

環境長這樣: 他建了一個 Snowflake 倉儲，裡面放一家虛構公司 Shorelane Commerce 的商業資料，量體貼近真實。然後親手注入各種糟糕的資料品質問題: 一堆 null、壞掉的欄位、join 不太對得起來，以及各種誤導和混淆。

每一個回合的流程:

關鍵在第 4、5 步。 回覆完 ticket 之後 agent 不會被強制結束，而是被告知「你可以結束這一回合了，但如果想先做點主動的知識工作也可以」。它自己寫的 wiki 會帶到下一個回合。所以這裡測的其實是: agent 會不會主動幫未來的自己做筆記。

計分方式也扣在這件事上: 那些 ticket 不只在問問題，也會順便告訴 agent 一些事實。題目被設計成，如果 agent 有把這些發現記下來、而且之後找得回來，到第 90 天它應該可以 100% 答對。

結果: Sonnet 4.6 第 90 天拿 24%，第零天是 4%。有進步，但離 100% 很遠。

「如果它拿 100%，我會覺得我的 benchmark 很爛。」他強調重點不是分數本身，而是第零天的分數在真實世界裡根本沒有參考價值。

他真正想觀察的其實也不是分數: 模型喜歡怎麼組織自己的 wiki? 它喜歡存下哪一類的資訊? 它怎麼取回? 它發現了什麼、又漏掉了什麼? 這些觀察是為了回頭讓 Hex 的 harness 變得更好。

跑一次很貴 (「我需要 credits，拜託」)。靈感來自 Andon Labs 的 Vending Bench (就是 Claudius 那台販賣機的相關研究)，那個是閉源的，他希望把 Metric City 開源出來。

小編補一個實作上的難點: 這種模擬允許 agent 在評估過程中動態改變系統 (自己整理 wiki、寫下發現)。Izzy 自己也承認，這讓評分變得極度困難，光是把整個模擬編排起來就很痛苦。這大概就是為什麼幾乎沒人做長時程 eval。

最後: 什麼是沙，什麼是石頭

Hex 的 CEO Barry 最近很愛問一個問題: 如果模型明天變好兩倍，產品裡哪些東西會被沖走 (沙)，哪些會留下來 (石頭)?

Izzy 的答案分兩塊，而且他認為第二塊大得多。

第一塊是把領域專業寫進產品裡。 他舉視覺化當例子: 團隊裡有兩位他形容為「職人等級」的視覺化專家，一半時間在把自己對「圖表該長什麼樣」的判斷直接寫成 agent 的規則，另一半時間在告訴其他同事哪裡做錯了、應該怎麼做。結果是使用者常常回饋說 Hex 的答案「就是比較好」，卻講不出為什麼。Izzy 認為差別就來自這些被寫進去的專業判斷。這部分模型變強也帶不走。

第二塊、也是更大的一塊，是客戶自己累積的 context。 你在 Hex 裡做事、產出報表、建立專案，這些東西全部變成 agent 未來可以參考的資訊來源。他講得很直白: 第零天，Claude 加一個 Snowflake connector 大概跟 Hex 一樣好; 差別在於 Hex 是一個整個團隊每天都在裡面工作的平台，用得越久，agent 手上可用的 context 越多。到第 90 天就完全是兩回事了。

回頭看，這個問題其實貫穿了整集: ID 映射系統是沙 (跑個 eval 就發現不需要了)、切得太細的那一整組工具是沙、把過程展開給使用者看，他自己預測幾個月後也會變成沙。這些全都是他們當初做得很自豪、而且當時確實必要的東西。所以每次為了補模型的不足而寫下什麼，都值得先問一句: 這是沙還是石頭? 如果是沙，就別把它做成整套系統的核心依賴。