上週我們討論了將數 TB 的 CI 日誌餵給大型語言模型（LLM）處理。Hacker News 上大部分問題並非針對日誌本身，而是關注代理的運作：使用哪些模型、如何協調，以及整體成本。

目前我們使用 Opus 4.6，付出的成本比起之前全部使用 Sonnet 4.0 時還要低。

主要原因在於 Opus 不做的事：80% 的失敗案例根本不會到達 Opus，且即使到達，Opus 也不會讀取任何日誌行。

上週我們分析了約 4,000 筆 CI 失敗案例，其中 818 筆是新問題，另外 3,187 筆是已知問題再次出現，例如不穩定的測試、基礎設施故障、網路短暫中斷等。

當 80% 的答案都是「重複問題」時，叫醒昂貴的模型顯然不合理。不幸的是，我們無法確定性地判斷重複問題：同一工作可能因完全不同原因多次失敗，因此必須實際查看日誌才能判斷是否曾見過。

我們最初使用 Sonnet 來平衡成本與效能。雖然可行，但兩者皆不理想：成本仍高，且結果不如 Frontier 模型。

我們改用「分流器」模式：一個 Haiku 代理負責非常具體且狹窄的任務。判斷此問題是否已被追蹤，若是則停止，否則升級至 Opus。

用 Haiku 偵測重複問題有些挑戰。我們盡量簡化任務，將錯誤訊息附加到先前失敗案例，並給 Haiku 兩種搜尋工具：精確匹配已知錯誤片段，以及語意搜尋（pgvector）找出相似但不完全相同的錯誤。雖然 RAG 已過時，但語意搜尋相當實用。像是 "operator does not exist bigint character varying" 和 "migration type mismatch on installation_id" 是不同字串，但語意搜尋能找出它們有相同根本原因。

Haiku 代理會讀取日誌、搜尋錯誤訊息、嘗試與已知失敗匹配並做出判斷。若有疑慮，則升級。誤判成本較低，漏判則可能錯過真實問題。

五成以上失敗案例不會送到 Opus。分流匹配成本約為完整調查的 1/25。

有人問我們如何處理超過 20 萬行的日誌。我們不會直接將它們放入提示中，而是給代理一個 SQL 介面連接 ClickHouse，讓它自行查詢所需資料。

這不只是為了節省 token 成本。如果你給代理一組特定日誌行，等於你在還不知道問題本質前就判斷了相關性。代理會被你給的資料限制，若真正原因在別處，反而更難找。這就像你不會一開始就說「我覺得問題在這個檔案」，因為這會讓調查有偏見。

我們上週詳細說明了 SQL 架構，簡單說就是有一張原始資料表（github_logs，每行一筆日誌）和多個物化檢視表，包含工作流程失敗率、工作時間、結果統計等。大部分調查先從物化檢視表縮小範圍，再深入原始日誌。

我們不會告訴代理要查哪張表，而是用回應引導它逐步查詢。如果查詢回傳太多行，我們會截斷並建議更精確的物化檢視表。若日誌尚未匯入，我們會指向 GitHub CLI。代理能自行判斷需求，不需我們預先設想所有路徑。

Opus 會根據失敗狀況形成假設，並派出 Haiku 子代理進行實際挖掘。每個子代理都會收到 Opus 的提示：要查什麼、怎麼查、回傳什麼。子代理只能一層深，不能再派出子代理，避免成本失控。

幾週前，三個 Storybook CI 工作在同一提交失敗，皆在 pnpm install 階段崩潰。

Opus 先派子代理抓取失敗步驟的錯誤訊息。因 ClickHouse 尚無日誌，子代理改用 GitHub CLI。

結果是 gyp ERR! 找不到 make，因為執行環境沒有安裝 make。

Opus 搜尋現有洞察（無匹配），接著查詢 ClickHouse 14 天內的失敗趨勢：

2 月 25 日明顯有變化。Opus 派出第二個子代理：

調查 2 月 24-25 日間變動。失敗率從 0.2% 飆升至 8%。錯誤是 gyp ERR! 找不到 make。對該時段的 workflow 檔案和 package.json 執行 git log。

建置依賴在一次無關遷移中被移除。修正該遷移，但 re2 仍需 make 進行原生編譯。Opus 派出第三個子代理確認目前工作流程狀態，然後建立包含根本原因與修正方案的洞察。

協調者從未讀取過日誌行、git 歷史或程式碼本身。

成本方面，Haiku 處理約 65% 的輸入 token，但只佔約 36% 的 LLM 花費。昂貴模型負責思考，便宜模型負責閱讀。若無模型分層，日費用會翻倍以上。

Opus 會邊做邊計畫。它從假設開始，每個子代理結果都會影響下一步。在這次調查中，它先取得錯誤訊息、搜尋歷史，再詢問變更。超過三成調查需多輪進行，新問題的調查深度約為已知問題的兩倍。

上下文管理方面，協調者保持乾淨：使用子代理的結構化摘要，而非原始日誌輸出。每個子代理從乾淨狀態開始，完成後丟棄上下文。工具呼叫輸出累積很快，舊上下文會影響後續判斷。

定向搜尋方面，「回傳 pnpm install 步驟的精確錯誤訊息」與「分析這些日誌」是截然不同的提示。Opus 決定搜尋目標，Haiku 負責尋找。Haiku 的輸入輸出比約 86:1（讀取大量資料，回傳精準摘要），協調者約 50:1（綜合判斷）。Haiku 吸收資料，讓 Opus 不必。

六個月前我們用 Sonnet 4.0，寫 ClickHouse 查詢時常出錯：錯表、漏過濾條件、讀取過多資料。Haiku 4.0 只能做簡單的是非分類。

如今 Opus 4.6 能規劃調查並撰寫精確子代理提示。Haiku 4.5 能執行狹義定向任務，因任務範圍足夠緊湊，快速且便宜的模型能勝任。

升級到 Frontier 模型後，成本反而降低。

我們為 CI 日誌打造此系統，但此模式適用於任何高事件量場景：安全日誌、物聯網遙測、金融資料。大多數事件是噪音或重複，昂貴模型只需處理非重複部分。

還有第四層未提及：重新評估。系統定期檢查結論是否仍然正確，關閉過時洞察、捕捉誤判、驗證修正效果。這是另一篇文章的主題。

我們仍在調整子代理邊界。有時派出子代理成本比直接處理還高，因為設定開銷超過節省。

最困難的不是讓代理更聰明，而是建立阻止代理不該運行時啟動的層級。

AI DevOps 工程師。自動化團隊不該手動做的 DevOps 工作：供應鏈安全、不穩定 CI、緩慢建置，以及你堆疊中專屬的問題。