Synthesizing Multi-Agent Harnesses for Vulnerability Discovery

相同的 Claude Opus 4.6 跑相同 89 道長視野任務，不同的 harness 設計讓通過率從 20% 跳到 80%，差了整整 4 倍。AgentFlow 把 harness 的設計自動化，在 TerminalBench-2 公開排行榜取得 84.3%，並在 Google Chrome 的 3500 萬行 C/C++ 程式碼中挖出 10 個未知 zero-day 漏洞，包含兩個 Critical 等級的沙箱逃脫 CVE（CVE-2026-5280 和 CVE-2026-6297），均已通過 Chrome 漏洞回報計畫確認。

同模型差 4 倍：harness 設計是 LLM 安全代理的核心變數

LLM 代理已開始發現人類安全審計員和自動 fuzzer（隨機輸入測試工具）數十年來都未能找到的真實漏洞。Google 的 Big Sleep 代理在 SQLite 中發現了記憶體損毀零日漏洞 CVE-2025-6965；Anthropic 的 Claude Mythos Preview 找到 OpenBSD TCP SACK 實作中長達 27 年的 DoS（拒絕服務）漏洞，只需兩個封包就能讓任何 OpenBSD 主機崩潰。這些成果表明代理系統的能力真實存在，且正在加速。

然而單一代理系統有三個根本限制：第一，大型目標（如 Chrome）一次執行就產生幾 MB 的 sanitizer（記憶體錯誤偵測器）和覆蓋率資料，很快超出約 200K token 的上下文視窗；第二，原始碼分析、輸入製作、崩潰分類等異質子任務搶奪同一個上下文，導致「中段遺忘」效應；第三，單一推理軌跡無法同時探索多個假設。這也是為什麼現代系統普遍採用多代理架構，讓 analyst（分析師代理）、explorer（探索者代理）、verifier（驗證者代理）各司其職。

決定「哪些代理存在、彼此如何溝通、每個代理用哪些工具、失敗時如何重試」的協作腳本就是 harness（代理協作框架），它才是決定成效的關鍵。在 TerminalBench-2 同一組任務上，三個系統跑同一個 Claude Opus 4.6，通過率範圍達到 4 倍寬——在模型固定的情況下，是 harness 的設計決定了最終成效。

現有四個 harness 最佳化系統各有侷限

過去幾年出現了幾個試圖自動設計 harness 的系統，但各自只搜尋設計空間的一個切片。Meta-Harness 只修改單一代理的提示詞和工具綁定，通訊圖固定為「無通訊」。ADAS 可以生成新的代理程式碼，但代理之間的通訊圖固定在手寫的階層式迴圈中。AFlow 對預定義的工作流程算子庫做樹狀搜尋，可改變連線方式，但代理池、提示詞、工具都不變。MaAS 從預定義代理池中取樣代理組合，但通訊方式和控制流固定為路由串聯。

這些系統有兩個共同缺陷。其一是搜尋範圍窄：任何需要跨元件變更的最佳解——例如「同時新增一個代理、重接通訊圖、並調整它的提示詞」——都超出它們的搜尋能力，而評估顯示這類跨元件變更正是讓有競爭力的 harness 脫穎而出的關鍵。其二是反饋粗糙：它們只依賴二元的通過/失敗訊號，無法診斷「失敗發生在哪裡」——到底是輸入從未到達漏洞函數？崩潰被不相關的斷言遮蓋？還是目標的防禦機制從未被觸發？在大型搜尋空間中，粗糙的反饋讓最佳化退化為隨機漫步。

AgentFlow 的設計：型別化 DSL 搭配執行時診斷

AgentFlow 的核心是一個型別化圖形 DSL（Domain-Specific Language，領域專用語言），把 harness 的所有維度統一成同一種可搜尋的表示。一個 harness 由五個元件組成：代理集合 A、通訊拓撲 G、訊息模板 Σ、工具分配 Φ、協作協議 Ψ。每個元件都是 DSL 程式中的一個可編輯欄位，因此單次最佳化步驟可以同時新增代理、重接通訊圖、重寫提示詞、更改工具綁定——全都是對同一個程式的局部改寫。

為了讓全空間搜尋可行，AgentFlow 的型別系統在執行昂貴的 LLM 推理之前，先做一次線性時間的圖形合法性檢查：（1）每個提示詞模板中的所有自由變數，必須解析到某個上游代理的輸出或某個反饋頻道；（2）每條宣告的邊，下游代理的模板必須真的引用了上游輸出；（3）圖是連通的，沒有孤立節點。在實驗中，約 20% 的提案因為結構不合法而被提前過濾，節省了大量推理成本。

反饋方面，AgentFlow 從目標程式讀取四類結構化執行時訊號：測試判斷、程式 stdout/stderr、行級覆蓋率圖，以及 AddressSanitizer 和 UndefinedBehaviorSanitizer 的記憶體安全報告。每次迭代的診斷步驟讀取完整的反饋包，定位「哪個代理失敗了、為什麼、應該做什麼樣的 harness 改寫」，再驅動下一輪提案——這套機制讓最佳化有方向可循，而非盲目試誤。

libheif 的三次迭代：從格式錯誤到 heap-buffer-overflow

論文用 libheif（HEIF/HEVC 圖像格式參考實作）上的 CVE-2020-23109 展示三次迭代如何完整觸發一個 heap-buffer-overflow（堆積緩衝區溢位）漏洞：函式讀取 8-bit alpha 通道卻把複製長度硬編碼為 16-bit（width × 2），造成越界讀取。

第一次迭代：單一代理生成 815 位元組的 HEIF 檔案，但二進位在早期格式檢查就拒絕了輸入，根本未執行到漏洞程式碼。AgentFlow 從 stderr 讀到「format constraint not satisfied」，判斷代理在構造有效格式上失敗。第二次迭代：系統拆成 analyzer（讀原始碼、描述有效 HEIF 格式）和 crafter（把描述轉成位元組）兩個代理。新的 817 位元組檔案通過格式檢查，parser 正常執行，但行覆蓋率資料顯示顏色轉換函數進入了，卻從未走到處理 8-bit alpha 通道的分支。第三次迭代：AgentFlow 加入第三個代理 verifier，改用磁碟上真實 HEIF 圖像為起點，只修改控制 alpha 位元深度的欄位，並在迴圈中不斷調整並重跑二進位，直到 AddressSanitizer 回報越界讀取。幾次嘗試後，verifier 成功重現漏洞。三次迭代跨越了「新增代理、重接通訊圖、改寫提示詞策略、接入 sanitizer 反饋頻道」四個維度的變更。

TerminalBench-2 的 84.3% 與 Chrome 的 10 個 zero-day

在 TerminalBench-2 的 89 道長視野終端機任務上，AgentFlow 合成的 harness 搭配 Claude Opus 4.6 取得 84.3% 通過率，是論文評估時公開排行榜快照中所有 harness 的最高分。在 Google Chrome（逾 3500 萬行 C/C++ 程式碼）上，相同的合成迴圈改用開源權重模型 Kimi K2.5（Kimi Team，2026）驅動，發現了 10 個先前未知的 zero-day 漏洞，包含兩個 Critical 等級的沙箱逃脫漏洞 CVE-2026-5280 和 CVE-2026-6297，全部通過 Chrome Vulnerability Reward Program 獲得廠商確認。

值得注意的是，TerminalBench-2 和 Chrome 兩個目標使用了不同的 LLM 模型，顯示 AgentFlow 的框架並不依賴特定模型。此方法有一個明確的適用前提：目標程式的原始碼和構建基礎設施必須可取得，以便編譯並插入覆蓋率與 sanitizer 插樁——這是標準的原始碼層級安全分析前提，不適用於純黑盒情境。論文也指出，手工設計的 harness 單次活動耗費可能高達數萬美元，而良好的 harness 設計可以用更少的推理呼叫解決更多任務。

harness 的設計，而非模型能力，是 LLM 漏洞挖掘系統通過率差 4 倍的真正原因；AgentFlow 自動搜尋全部五個 harness 維度，在 Chrome 找到 10 個 zero-day。