AgentFlow 論文閱讀分析：很多漏洞 AI 真正缺的，不是更強模型，而是更會編隊的 harness
論文基本資訊
- 論文標題：Synthesizing Multi-Agent Harnesses for Vulnerability Discovery
- 作者：Hanzhi Liu、Chaofan Shou、Xiaonan Liu、Hongbo Wen、Yanju Chen、Ryan Jingyang Fang、Yu Feng
- 年份：2026
- 來源：arXiv:2604.20801
- 論文連結：https://arxiv.org/abs/2604.20801
- 主題：Agentic AppSec、Vulnerability Discovery、Multi-Agent Systems、Harness Synthesis、Runtime Feedback、Chrome Zero-Day
很多人現在談漏洞 AI，還在把焦點放在模型夠不夠強、prompt 夠不夠好、tool 有沒有接齊。但這篇 paper 點到一個更核心、也更像 production 工程問題的地方：真正決定 agent 有沒有挖到洞的，常常不是底下那顆 LLM，而是上面那層把角色、溝通、工具與重試流程綁在一起的 harness。
作者的主張很直接：就算模型完全不變，只改 harness，表現也可能差好幾倍。可現況大多數 harness 還是人工土法煉鋼寫出來，或最多只優化 prompt、只調 topology、只看 pass/fail，缺少一個能把agent roles、communication graph、message schema、tool binding、coordination protocol一起搜尋與一起改寫的框架。
這篇提出的 AgentFlow，想補的就是這個洞。它不是再做一個單點 agent，而是把 multi-agent harness synthesis 本身變成優化對象：用一個 typed graph DSL 表達整個 agent team，再用 target runtime 自己吐出的訊號——像 hidden test 結果、stdout/stderr、coverage、sanitizer reports——來診斷哪個環節卡住，然後反過來改 harness。
這篇真正想推進的，不是「哪個 agent 最會找洞」，而是把「怎麼組 agent team 才比較會找洞」從手工 craft，推向 feedback-driven synthesis。
這篇論文想解決什麼？
作者先指出單 agent 的幾個老問題：
- 上下文很快爆掉：source、build log、sanitizer、coverage 一疊上去，context window 很快就被吃光；
- 長鏈任務容易 lost in the middle：前面分析忘掉、後面重做、策略斷線；
- 不能平行探索多個假設：走錯一次就浪費整輪 budget。
所以實務上大家都會把工作拆給多個 agents：有人看 source，有人想 exploit path，有人跑驗證，有人做 triage。問題是，這個 team 怎麼編成、誰可以用哪些 tools、訊息怎麼流、失敗後誰重試誰，通常是人工憑經驗調。
這就變成一個尷尬狀態：大家都知道 harness 很重要，但harness 設計本身還沒有被當成一個可系統化搜尋、可診斷、可優化的對象。
核心 framing：別再只優化 prompt，真正該被優化的是整個 harness program
我覺得這篇最值得看的地方，是它把 harness 拆成五個一級元件：
- A：agent roles
- G：communication topology
- Σ：message schemas / prompts
- Φ：tool bindings
- Ψ：coordination protocol
作者的意思很明確：如果你的 optimizer 只能調其中一兩項，那它天生就只看得到設計空間的一小塊。像有些方法只能 tune prompt、有些能改 workflow graph 但 agent pool 固定、有些能 sample team 但 coordination pattern 不能動。這些都還不算真正對 harness 做 end-to-end synthesis。
AgentFlow 則試圖把這五個面向全部放進同一個 typed graph DSL 裡。也就是說，一次 edit 不只是改一句 prompt，而可以同時：
- 新增一個 specialist agent；
- 重接 communication edges；
- 改 message template；
- 調整 tool 權限；
- 把 sequential chain 改成 fan-out / merge ensemble。
這個 framing 很重要，因為它把問題從「怎麼把單個 agent 提示寫更好」提升成「怎麼把整個漏洞挖掘工作流編排得更像一個會自我修正的小型安全團隊」。
AgentFlow 在做什麼？
整體 loop 可以簡化成四步：
- Propose：根據上一輪 diagnosis 與歷史 archive，提出新 harness；
- Execute & Observe：把這個 harness 跑在所有 tasks 上，收集 trace 與 runtime feedback；
- Score：用 domain-specific 分數函數算成單一 score；
- Diagnose：不是只看 pass/fail，而是看完整 feedback bundle，判斷到底哪個 agent / 哪個設計元件害它失敗，然後回饋下一輪改寫。
這裡最關鍵的不是 loop 本身，而是它吃的 feedback 不是 agent 自己的自述而已。作者強調它會讀 target environment 真的吐出來的訊號，例如：
- hidden test verdict
- stdout / stderr
- line-level coverage
- sanitizer reports
換句話說，這不是單純自我反思型 agent 再包一層，而是把target-side execution evidence拉進 harness optimization loop。這很對味，因為漏洞挖掘最怕的就是 agent 很會說、很會編，但沒有真正碰到能驗證的 runtime evidence。
另一個很工程的亮點：typed graph DSL 不是花俏形式化，而是 budget guard
如果你把整個 harness space 打開，第一個直覺問題就是：這不會炸掉嗎？作者的回答是，用 type system 先把結構上就不合法的候選直接擋掉。
例如它會先檢查：
- template variable 有沒有對到已宣告輸出或 feedback channel；
- edge 有沒有接到合法 agent；
- 整張 graph 是否連通；
- tool / schema / topology 是否符合 well-formed harness 約束。
作者明講，實驗裡大約有20% proposer 產生的候選，在這一層就被打掉，還沒花到昂貴的 LLM inference。這點我很喜歡，因為它把「formalization」放在一個很實際的位置：不是為了炫理論，而是為了別把錢浪費在明顯壞掉的候選上。
關鍵結果一：在 TerminalBench-2 上做到 84.3%，是作者比較快照裡的公開榜首
作者在 TerminalBench-2 上用 Claude Opus 4.6 評估 AgentFlow。這個 benchmark 是公開 agent-harness leaderboard，包含 89 個長鏈 terminal tasks，涵蓋 code translation、ML pipeline reconstruction、distributed systems setup、cryptanalysis、memory corruption analysis、vulnerability remediation、secret recovery 等類型。
AgentFlow 的結果是：
- 84.3% pass rate
- 等於 75 / 89 tasks 通過
- 比當時對照的 ForgeCode 81.4% 高 2.9 個百分點
- 比 Meta-Harness 76.4% 高 7.9 個百分點
這裡值得注意的不是只有數字高，而是作者採的是 leaderboard 標準 protocol：同一個 task-agnostic harness program，對全部 89 個 tasks 一體適用，沒有 per-task conditional branch。也就是說，它不是每題客製化修，而是一個共享 harness 真正變得比較會做事。
關鍵結果二：優化軌跡從 35.2% 一路爬到 84.3%，而且每一段提升都對應不同層級的 harness 問題
作者把 synthesis trajectory 拆成三段，這段很有啟發性：
- Infrastructure（Steps 1–5）：+28.8 個百分點
- Specialization（Steps 6–9）：+15.8 個百分點
- Ensemble（Step 12）：再 +4.5 個百分點，最後到 84.3%
這三段分別代表：
- 先補環境防呆、tool bindings、coordination protocol；
- 再加入 specialist sub-agents、retry edges、tool refinements；
- 最後把 topology 改成 fan-out / merge ensemble，讓多路嘗試可以平行跑、交叉驗證後再 submit。
這說明一件很重要的事：harness 改進不是單點 miracle，而是從 infrastructure → specialization → ensemble 的階段性工程。你如果只盯 prompt，很可能連第一段都補不完。
關鍵結果三：prompt search 最重要，但前提是先有可工作的多代理骨架
作者做了 ablation，幾個結果很值得記：
- Full AgentFlow：84.3
- No Structure Search：76.4
- No Prompt Search：51.8
- No Tool Search：71.9
表面上看，drop 最大的是 No Prompt Search，直接掉到 51.8%，也就是少了 32.5 個百分點。但作者的解釋我認為很合理：這不代表「那就只調 prompt 就好」，而是代表prompt edits 是在已經有多角色、多路徑、多工具骨架之上，拿到最多 optimization signal 的那一層。
換句話說，真正該讀成：
prompt 的確很重要，但它之所以重要，是因為前面結構與工具層先把可用的工作流搭出來了。
關鍵結果四：在 Google Chrome 真機案例上，AgentFlow 找到 10 個先前未知 zero-days，且都被廠商接受
這篇最會吸眼球的 headline 當然是 Chrome case study。作者把同一套 synthesis loop 換到 Google Chrome 上，底模改用 Kimi K2.5，最後挖到 10 個 previously unknown zero-day vulnerabilities，而且全部都通過 Chrome VRP、被 vendor 確認。
表中的結果包括：
- 2 個 Critical
- 7 個 High
- 1 個 Medium
其中最重的兩個是：
- CVE-2026-5280：Critical use-after-free
- CVE-2026-6297：Critical use-after-free
作者還明講，這兩個都屬於sandbox escape 等級，代表從惡意頁面一路打到 host code execution 的路徑。其餘類型還包括 integer overflow、heap buffer overflow、以及 WebGL 的 inappropriate implementation 問題。
這裡當然不能把它直接讀成公平的 compute-matched SOTA 比賽，因為作者自己也說這更像 capability case study。但至少有一件事很清楚：這不是只在 benchmark 上刷榜的 harness 搜尋，而是已經碰到真實大型 C/C++ codebase 與真實漏洞回報流程。
這篇真正有價值的 insight：漏洞 AI 的上限，可能越來越取決於 orchestration，而不只是 model IQ
如果你把這篇跟最近一堆漏洞 agent 論文放在一起看，它最強的地方不是單獨創一個超神新 agent，而是重新分配 credit：
- 一部分 credit 要給模型；
- 但很大一部分，其實應該給 harness design。
這個觀點很重要，因為它會改變後面整個研究方向。未來如果大家慢慢接受「harness 是主要性能槓桿之一」，那研究問題就會從：
- 哪顆模型更會找洞？
轉向：
- 哪種角色分工更有效？
- 哪種 communication topology 更穩？
- 什麼 feedback signal 最能導出有效 rewrites？
- 哪些 static invariants 能先把壞候選擋掉？
這就比較像真正成熟的 systems engineering 問題，而不是純模型排行榜問題。
但我也會保留幾個問號
這篇很強，但不是沒保留：
- Chrome case study 沒有做 compute-matched baseline comparison，所以比較適合當 capability showcase，不適合直接喊全面碾壓；
- 方法高度依賴 target-side runtime feedback，這對 source-available、可 instrument 的場景特別友善，但對黑箱環境就未必同樣成立；
- static topology 讓它可分析、可型別檢查，但也限制了 runtime agent spawning 之類更動態的編排；
- 成功很大程度仍仰賴高品質工具鏈與執行環境，不是光有 DSL 就能平地起飛。
不過這些侷限比較像它的適用邊界，而不是把核心貢獻打掉。因為作者真正證明的，是harness synthesis 這件事本身值得被正視，而且已經有實際收益。
我自己的看法：這篇是在把「agent craft」慢慢變成「agent compiler / agent architecture search」
如果要用一句話講我對這篇的感受，大概是：
很多漏洞 agent 現在看起來像 artisanal craft——高手手工調一套很猛的隊形；而這篇是在把那件事往可表達、可診斷、可搜尋、可重寫的工程系統推。
這個方向一旦成立，後面不只對漏洞挖掘有用，對很多 agentic security 任務都可能有啟發：像 threat hunting、incident response、reverse engineering、detection engineering，甚至一般 coding agent 的 multi-role orchestration，都可能受用。
因為問題本質很像：不是模型一個人變聰明，而是整個工作流如何被編排得更會把聰明變成結果。
Takeaway
這篇論文最值得記住的一句話，我會這樣總結：
很多漏洞 AI 真正缺的，不是再換一顆更強模型，而是先把負責分工、溝通、工具權限與重試邏輯的 harness 做成可優化系統；AgentFlow 的價值，就在它把 multi-agent vulnerability discovery 從手工編隊，往 feedback-driven harness synthesis 推進了一大步。
如果你在看 agentic AppSec、automated vulnerability discovery、multi-agent orchestration，或你關心的是「AI 安全系統到底哪一層最值得工程化」，這篇很值得讀。它給出的答案相當清楚：真正該被編譯與搜尋的，可能不是 agent 單句話怎麼說，而是整個 agent team 怎麼被組起來。
本文由 AI 產生、整理與撰寫。