打造最好的 agentic 資料分析 harness：由 Claude 驅動，用 Claude Code 打造（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這支影片是 Omni（做資料分析平台的公司）分享他們的 AI 分析助理 Blobby 怎麼一路改進。Blobby 是一個 agent，也就是會自己規劃步驟、呼叫工具，把任務做完的 AI。最值得看的是：他們去翻 AI 的內部紀錄，找出答錯的真正原因，沒有把錯推給「AI 本來就不穩」。影片最後還有現場 demo。

• 13:23 團隊跟 Colin 說 LLM 本來就有點不可預測，要接受它不會每次都完美；Colin 回答「不夠好，去修好」
  ↳ 團隊原本跟 Colin 說：LLM（大型語言模型，Claude 這類 AI 的核心）本來就有點難預測，偶爾出錯很正常。Colin 不接受這個說法，要他們找出問題、修好。
• 13:23 於是團隊大力投入理解 traces，特別去看那些所謂「bad sessions」的 traces
  ↳ 於是團隊認真研究 traces（agent 執行時的內部紀錄，看得到每一步怎麼想、怎麼做），而且專挑表現差的 bad sessions 來看，從失敗裡找原因。
• 13:54 看 traces 之後做了一連串重大改造，團隊稱為「Blobotomies」，每一項都能追溯到 traces 裡發現的問題
  ↳ 根據 traces 裡發現的問題，他們對 Blobby 做了一連串大改造，自嘲叫「Blobotomies」（Blobby 和「腦葉切除術」的諧音）。每一項改動都能追回 traces 裡的問題。
• 13:54 traces 能讓你看到 agent 在迴圈裡怎麼自言自語、怎麼反應和回應；看起來像隨機出錯的 session，其實背後有真正的問題
  ↳ traces 讓你看到 agent 在迴圈裡一輪一輪思考、呼叫工具、看結果再決定下一步。很多看起來像隨機出錯的 session，追下去其實都有具體的設計問題。
• 14:29 原本的設計可能太聰明了：outer agent 負責產生任務清單、知道有哪些資料可用，但不負責產生 query
  ↳ 原本的設計太聰明、分工太細：外層的 outer agent 負責把問題拆成任務清單、掌握有哪些資料可用，但不自己寫 query（向資料庫要資料的查詢指令）。
• 14:29 query 交給一個 subagent 產生。這個設計看起來合理，而且這個 subagent 還能在其他幾個情境重複使用
  ↳ 寫 query 交給 subagent（主 agent 派出去做特定工作的小幫手 agent）。這樣分工看似合理，而且這個小幫手還能在其他幾個情境重複使用。
• 14:59 看 traces 才發現問題：subagent 每次只能產生一個 query，但 outer agent 不知道哪些問題用一個 query 就答得出來
  ↳ 問題是 subagent 一次只能寫一個 query，但 outer agent 不知道哪些問題一個 query 就能答、哪些要好幾個，常把做不到的任務丟給它。
• 14:59 例子：outer agent 叫 subagent 回答一個牽涉 GitHub pull requests 和 support data 的問題並做摘要
  ↳ 例如 outer agent 要 subagent 同時查 GitHub 的 pull requests（簡稱 PR，工程師提交程式修改的申請）和客服支援資料，再整理成摘要。
• 15:30 subagent 回報單一 query 答不了、需要跑多個 query。教訓是：怎麼拆分資訊要非常小心
  ↳ subagent 只能回報「一個 query 答不了，要跑好幾個」。教訓是：把資訊和能力拆給不同 agent 時要很小心，誰知道什麼、誰能做什麼都要想清楚。
• 15:30 工程師 Joel 把解法叫做「consolidating the brain」：subagent 系統和 outer agent 系統之間不要出現 split brain
  ↳ 工程師 Joel 叫這個解法「consolidating the brain」：避免 split brain，別讓兩個 agent 各知道一半，像兩顆互不相通的腦袋。
• 16:03 做法是把這些工具拉上來放進 outer agent harness，消除了很多看似無法預測、令人意外的行為，較複雜的情況大幅改善
  ↳ 做法是把寫 query 的工具直接放進 outer agent 的 harness（包在模型外、提供工具和流程的執行框架）。許多意外的怪行為因此消失，複雜問題明顯變好。
• 16:03 下一階段的觀察：直接用 Claude 寫 SQL，能答出一些很難的問題，但 Blobby 有時候反而答不好
  ↳ 接著發現：直接叫 Claude 寫 SQL（查資料庫用的標準語言），連很難的問題都答得出來；但同樣的問題交給 Blobby，有時反而答不好。
• 16:41 背景：Omni 剛做出來的時候就內建一套完整的 SQL parsing engine，但因為不夠可靠而放棄，擱置了好幾年
  ↳ 背景：Omni 剛起步時就做過一套 SQL parsing engine（把 SQL 拆開、讀懂結構的程式），但因為不夠可靠就放棄了，冷凍了好幾年。
• 16:41 當初放棄的原因：使用者會丟各式各樣的 SQL 進來，引擎沒辦法處理所有可能的寫法
  ↳ 當初放棄是因為使用者寫的 SQL 五花八門，同一件事有很多種寫法，這套引擎沒辦法每一種都看懂。
• 17:12 新想法：Claude 能寫出強大、表達力高的 SQL，只要寫法符合團隊能理解的一般形式，他們就能 parse
  ↳ 新想法：Claude 寫的 SQL 強大又靈活，只要它照團隊看得懂的常見形式寫，parser（負責拆解解讀的程式）就讀得懂，不用應付所有怪寫法。
• 17:12 團隊也認為 Anthropic 應該會大力投資讓 Claude 擅長 SQL，所以決定把籌碼押在這上面
  ↳ 團隊也判斷 Anthropic（開發 Claude 的公司）會大力投資，讓 Claude 更會寫 SQL，所以決定押寶在這條路上。
• 17:12 工程師 Steven 把舊的 parsing code 重新拿出來，從根本改掉把 query generation 開放給 Blobby 的介面
  ↳ 工程師 Steven 把舊的 parsing 程式挖出來，從根本改掉 Blobby 產生 query 的介面，也就是 Blobby 跟系統說「我要查什麼」的方式。
• 17:51 原本 Blobby 用的是高度結構化、JSON 形式的 query；後來改成 SQL parsing 模式，讓它直接寫 SQL，再由系統 parse
  ↳ 以前 Blobby 要把查詢寫成規定嚴格的 JSON 格式（一種結構化資料的寫法）；改版後讓它直接寫 SQL，再交給系統的 parser 解讀。
• 17:51 同時給 Blobby 一些指引，避免 parser 出錯
  ↳ 同時給 Blobby 一些撰寫指引，提醒它哪些寫法要避開，讓 parser 不容易出錯。
• 18:21 改完之後，原本要試三、四次，或要笨拙地串接三、四個 query 的問題，現在一個 one-shot query 就能寫完
  ↳ 效果很明顯：以前要試三、四次，或把三、四個 query 笨拙地串起來才答得出的問題，現在一個 one-shot query（一次寫好就答出來的查詢）就搞定。
• 18:21 講者觀察到 Claude 很喜歡用 CTEs（common table expressions）寫 SQL，而他們的 parser 剛好很擅長 parse 這種寫法
  ↳ 講者發現 Claude 很愛用 CTE（common table expression，先把中間結果取名存起來、再一步步組合的寫法），他們的 parser 剛好最會讀這種。
• 18:21 效率大幅提升的原因 A：Blobby 不用再學團隊自己發明的專有 JSON query 格式，只要寫它本來就會的 SQL
  ↳ 效率大增的第一個原因：Blobby 不必再學 Omni 自己發明的 JSON 查詢格式，只要寫它本來就熟的 SQL。
• 18:51 效率大幅提升的原因 B：產生的 query 更有效率，不用再試兩、三次
  ↳ 第二個原因：寫出來的 query 本身更有效率，不用再試兩、三次才拿到答案。
• 18:51 目前架構：outer loop 負責替執行過程做 checkpointing，確保任何失敗都能恢復
  ↳ 現在的架構分兩層。外層迴圈（outer loop）負責 checkpointing：執行途中邊做邊存檔，哪一步出錯就從存檔點接著做，不用整個重來。
• 19:21 inner loop 有一組工具，數量正在大幅增加，包括產生 dashboards、產生 visualizations，以及一些 validation tools
  ↳ 內層迴圈（inner loop）是 Blobby 做事的地方，工具大量增加中：做 dashboard（儀表板）、做圖表，還有檢查結果的驗證工具（validation tools）。
• 19:21 也有讓 Blobby 自己做 data modeling、改善 semantic layer 的工具
  ↳ 也有工具讓 Blobby 自己做 data modeling（定義資料之間的關係），改善 semantic layer（把資料欄位翻成商業用語的那一層，例如「營收」怎麼算）。
• 19:52 他們有內部的 eval system，也正在替客戶打造 eval system
  ↳ Omni 內部有一套 eval system（用固定題目反覆測 AI、幫表現打分的評估機制），現在也在替客戶打造一套。
• 19:52 理由是他們要提供的關鍵價值之一就是可預測性和品質：CEO 問問題，要得到正確答案，而且每次都一樣
  ↳ 原因是他們主打的價值之一就是穩定可靠：CEO 問一個問題，要拿到正確答案，而且每次問都一樣，不能這次對、下次錯。
• 20:22 講者愛 evals 的理由跟多數人不同：他最喜歡的是能拿到原始 trace data，evals 的 observability 那一面讓他很有收穫
  ↳ 講者愛 evals 的理由跟多數人不同：他最喜歡的是能拿到原始 trace 資料。這種 observability（可觀察性，看得見系統內部在做什麼）讓他收穫最多。
• 20:22 他喜歡直接看資料、追問「這次為什麼壞了」；再把這些判斷寫成 judge，也能提升效率
  ↳ 他喜歡親自翻資料，追問「這次為什麼壞掉」。再把這些人工判斷的標準寫成 judge（自動打分的評審程式），就能自動大量檢查，效率更高。
• 20:53 打造任何系統時，工程師都要了解使用者真正在乎什麼；自己無法想像怎麼用、或無法理解使用者的系統，很難做好
  ↳ 他認為做任何系統，工程師都要懂使用者真正在乎什麼。自己都想像不出怎麼用、也不懂使用者的系統，很難做得好。
• 20:53 Claude Code 除了帶來巨大的生產力提升，自己當 Claude Code 的使用者也讓團隊知道好的 harness 長什麼樣，並把這些經驗放進自家 harness
  ↳ Claude Code（Anthropic 給工程師用、能直接讀寫程式的 AI 工具）讓團隊產能大增；自己天天用，也知道好的 harness 長怎樣，再搬進自家 harness。
• 21:23 例子：要不要做一套新方法來探索 semantic model？先看 Claude Code 怎麼做，因為 semantic model 其實跟 code base 差不多
  ↳ 例如要不要自創一套方法讓 AI 探索 semantic model（公司資料的定義和關係）？先看 Claude Code 怎麼翻程式碼，因為講者認為兩者本質很像。
• 21:23 這樣做讓工程師更能深入理解問題，也看到目前最新、最好的解法
  ↳ 這樣借鏡讓工程師更深入理解問題本身，也能直接參考目前最新、最好的解法。
• 21:57 Live demo：請 Blobby「create a dashboard of engineering activity in the Omni repository」
  ↳ 現場示範：講者請 Blobby「幫 Omni 的 repository（放專案程式碼的地方）做一個工程活動的 dashboard」。
• 22:33 建 dashboard 會產生很多 query，也要花不少心思想版面配置，有時需要一點時間；Blobby 會先擬計畫，再找出相關的 topics
  ↳ 做 dashboard 要跑很多 query，還要想版面怎麼排，所以會花點時間。Blobby 會先擬計畫，再找出相關的 topics 當資料來源。
• 22:33 Omni 的 topic 是一個資料領域，可以想成把其他子資料集全部合併起來的一個又大又寬的資料集
  ↳ Omni 的 topic 是一個資料領域，可以想成把相關的子資料集全部合併起來、欄位很多的一張大表。
• 23:05 產品理念：AI to build，UI 用來 validate、troubleshoot 和 refine，這個理念深深融入聊天體驗裡
  ↳ 產品理念是「AI 負責做出來，UI（使用者介面，就是畫面上能點、能操作的部分）讓人檢查、除錯、微調」，這個想法直接融進聊天介面裡。
• 23:35 不用盯著 SQL block 猜，可以直接在 workbook 打開；Omni 的 workbook 就是用來產生 query、操作資料的地方
  ↳ 不用盯著聊天裡的 SQL 程式碼猜對不對，可以直接在 workbook 打開。workbook 是 Omni 裡產生 query、操作資料的工作區。
• 23:35 在 workbook 可以確認資料正確：用的是 GitHub pull request 資料集，篩選了 Omni repository、main branch，只看 merged pull requests
  ↳ 在 workbook 裡能確認資料沒抓錯：用的是 GitHub PR 資料集，只篩 Omni 的 repository、主要分支（main branch）、已合併的 PR。
• 24:05 可以直接調整圖表，或改看其他面向，例如改成看 docs repository，方便接著延伸 Blobby 做出來的結果
  ↳ 也能直接在這裡改圖表或換個角度看，例如改看 docs repository（放文件的程式庫），接著 Blobby 做出來的結果繼續延伸。
• 24:35 dashboard 做好了，附上摘要（engineering activity、key metrics），可以在 split pane 預覽
  ↳ dashboard 完成後，Blobby 附上摘要，說明工程活動和關鍵指標，還能在 split pane（分割畫面）直接預覽。
• 25:05 dashboard 內容：過去三個月、top PR authors、PR volume over time；改成過去 12 個月就能看到趨勢，也看得出 AI 是 Omni 目前的熱門話題
  ↳ dashboard 預設看過去三個月，有 PR 最多的作者、PR 數量隨時間的變化。改成 12 個月就看得出趨勢，也看得出 AI 是 Omni 最近的熱門話題。
• 25:36 部分 workflow data 沒有正確顯示、有圖表是空白的；可以現場 troubleshoot，但講者坦白說一眼看不出原因，猜是那份資料沒有好好寫入
  ↳ 示範中有些 workflow 資料沒正確顯示，還有圖表是空白的。可以當場排查，但講者坦白說一眼看不出原因，猜是那份資料沒有好好寫入。
• 26:06 結語：Omni AI Analytics Platform, powered by Claude；harness 專為 Claude 和 Claude 系列模型優化；公司在 San Francisco
  ↳ 結尾：Omni AI Analytics Platform 由 Claude 驅動，harness 專為 Claude 系列模型優化，公司在舊金山（San Francisco）。

根據影片，哪個改變讓 Blobby 原本要試三、四次的問題，現在一個 one-shot query 就能寫完？