Frontier LLM Offensive Cyber Benchmark 論文閱讀分析：真正把 agent 表現往上推的，常常不是 prompt，而是它手邊到底有沒有一個像樣的 Kali 工作台
本文由 AI 產生、整理與撰寫。
論文基本資訊
- 論文標題：Systematic Capability Benchmarking of Frontier Large Language Models for Offensive Cyber Tasks
- 作者：Tyler H. Merves、Michael H. Conaway、Joseph M. Escobar、Hakan T. Otal、Unal Tatar
- 來源：arXiv / submitted to IEEE SIEDS
- 年份：2026
- arXiv：https://arxiv.org/abs/2604.17159
- 主題：Offensive Security、CTF Benchmark、LLM Agents、Pentesting、Agent Tool Use、Cyber Range Evaluation
這篇 paper 有意思的地方，不是它又做了一次「哪家模型比較強」排行榜，而是它把一件很多人其實早就隱約知道、但很少被乾淨量化的事講清楚了：在 offensive cyber agent 這種任務裡，真正決定表現的，常常不是你又多塞了幾句 prompt，而是 agent 手邊到底有沒有像樣的工具環境。
作者把 10 個前沿模型丟進同一個多代理框架，在 NYU CTF Bench 的 200 題上做完整比較，還系統性去拆三個變因：Ubuntu vs. Kali、generic prompt vs. category tips、以及有沒有先做 auto-prompting。結果很直接：把環境從普通 Ubuntu 換成裝滿 100+ pentest tools、還有指令查詢能力的 Kali，平均 solve rate 直接多了 9.5 個百分點；反過來，很多大家以為會加分的 prompt engineering，在工具夠齊時反而變成扣分。
如果你平常在看 AI agents for cybersecurity，這篇最值得記住的一句話大概是：很多 benchmark 最後量到的，不只是模型會不會推理，而是整個 agent runtime 到底有多像真實工作台。
這篇論文真正想回答的，不是哪個模型最聰明，而是哪個環節真的在拉高能力上限
近一年 offensive security agent 的論文很多，但常常很難互相比。有人換模型、有人換工具鏈、有人加 RAG、有人改 agent architecture，最後分數升了，卻很難知道到底是什麼在起作用。
這篇 paper 的價值就在這裡：它不是再發明一個新框架，而是基於既有的 D-CIPHER multi-agent 架構，盡量把變因拆乾淨，然後問四個很實際的問題：
- 更完整的 security tooling 會不會真的提升 agent 解題能力？
- tips 和 auto-prompting 這類 prompt 手段，效果到底穩不穩？
- 不同 frontier models 在 offensive tasks 上的差距有多大？
- planner / executor 混搭大小模型，是否真的比同模組合更划算？
這些問題都比單純比榜單更重要，因為它們比較接近 production 現實：你真的要部署 agent 時，通常不是在問「世界第一是誰」，而是在問「我該先投資在哪個層：模型、環境、prompt，還是 orchestration？」
方法設計的核心：同一個 benchmark、同一個框架、把工程變因分開量
作者用的是 NYU CTF Bench，總共 200 題，涵蓋 crypto、reverse engineering、pwn、misc、web、forensics 六大類。這是個合理的 offensive proxy，因為它至少要求 agent 做多步推理、工具操作、命令執行與環境互動，而不只是紙上答題。
整個系統沿用 D-CIPHER 的 Planner–Executor 階層式多代理架構：Planner 負責高階拆解與策略，Executor 負責具體工具呼叫、寫 code、跑 shell、看輸出再回報。作者在這個骨架上補了三個很關鍵的工程擴充：
- 多供應商模型 backend：讓不同模型能在同一框架下公平比較。
- Kali Linux 執行環境：預裝 100+ 常用安全工具，而不是只有比較精簡的 Ubuntu baseline。
- runtime tool discovery agents：agent 不只手上有工具，還能查現在有哪些指令、每個指令怎麼用。
這第三點其實很重要。很多 benchmark 會把「有工具」和「agent 知道怎麼找到工具」混成一件事，但兩者不是同一回事。工具可用，不代表 agent 會用；而這篇的 Kali 優勢，其實量到的是『工具豐富度 + 可探索性』的組合效果。
最值得記住的結果之一：Kali 比 Ubuntu 高 9.5 個百分點，環境比 prompt 更像主因
論文裡最醒目的結果，是在其他條件相同時，Kali + generic prompt + no auto-prompt 達到 52.0% solve rate，而 Ubuntu + generic prompt + no auto-prompt 只有 42.5%。這不是小修小補，而是整整 +9.5 percentage points。
而且這個優勢不是平均灌水，而是在某些高度依賴專用工具的類別上特別明顯，例如：
- Forensics：Kali 46.7% vs Ubuntu 20.0%
- Reverse engineering：Kali 58.8% vs Ubuntu 49.0%
這個結果背後的含義很現實：很多人把 agent 解不出來歸咎於模型太笨，但其實它常常只是手上少了對的工具，或根本不知道現場有什麼工具能用。 在 offensive cyber 這種 heavily tool-mediated 工作裡，runtime substrate 很大程度決定了 agent 能不能把推理變成有效行動。
換句話說，這篇其實在提醒我們：不要把 agent capability 想成純模型屬性。它更像是模型 × 工具環境 × tool discoverability × execution interface 的乘積。
另一個很打臉研究圈直覺的結果：prompt engineering 不一定加分，甚至常常扣分
很多 agent paper 一卡住就會回去加 prompt、加 tips、加 pre-analysis。但這篇最有趣的地方，就是它把這些常見招數放進完整 ablation 後發現：環境夠好時，prompt engineering 的邊際效益不只變小，還可能變成負數。
最典型的是在 Kali 環境下：
- generic prompts：52.0%
- category-specific tips：40.0%
也就是說，明明工具都在了，硬塞更多類別提示，反而讓 agent 表現更差。 作者的解釋我覺得合理：當環境本身已經夠 rich，agent 本來就有比較大的探索空間，這時再額外加一層人工 tips，可能變成過度約束，讓它往不夠好的既定路徑走。
更慘的是 auto-prompting。Kali + generic 下，開了 auto-prompt 之後 solve rate 從 52.0% 掉到 39.5%，直接少 12.5 個百分點。Ubuntu + tips 甚至從 44.5% 掉到 16.0%。
這很值得 agent builder 記住：前置探索與額外分析，不一定是在「幫模型暖機」，也可能只是在浪費時間、token、和注意力，甚至把後續規劃帶偏。 有些 prompt scaffolding 在弱環境裡像拐杖，但在強環境裡更像噪音。
模型排名本身當然也有看點，但真正有價值的是 cost-performance 解讀
在最佳配置（Kali + generic + no auto-prompt）下，作者拿 10 個模型做比較。結果上，Claude 4.5 Opus 以 59% solve rate 第一，Gemini 3 Pro 以 52% 第二。這兩個 frontier models 形成明顯第一梯隊。
但如果只停在「第一名是誰」，其實有點浪費這篇資料。更值得看的是：
- Gemini 3 Flash solve rate 雖然只有 27%，但 cost per solve 只有 0.05 美元，是整體最省。
- Claude 4.5 Opus 雖然最強，但 cost per solve 2.12 美元，大概是 Gemini 3 Pro 的 5 倍。
- GPT-5.2-Codex（18%）明顯優於 base GPT-5.2（13.5%），代表 code specialization 在這類 agentic cyber task 還是有實際差異。
所以比較像 production 的結論不是「永遠上最強模型」，而是：如果你追求純能力上限，Claude 類旗艦模型確實佔優；但如果你要跑大量任務、成本敏感、而且可接受較低成功率，較小但便宜的模型可能更合理。
也就是說，這篇 paper 幫我們把 offensive agent 的選型問題，從「哪個分數最高」拉回「哪個能力/成本點比較符合你的部署邏輯」。
Planner / Executor 混搭沒有想像中香：同模組合通常比大小模型混搭更穩
另一個很值得記的結果，是作者去測了 planner / executor 的模型配置。直覺上，很多人會以為可以用大模型做 Planner、小模型做 Executor，拿到比較好的 cost-performance balance；但實驗結果沒有支持這個想法。
Gemini 3 Pro / Pro 的同模配置表現最好（52%）。而 Pro Planner + Flash Executor 雖然比純 Flash 稍微高一點，但只多了 1.5 個百分點，成本卻增加約 45%。更反直覺的是，Flash Planner + Pro Executor 還比純 Flash 更差。
這很像在說：多代理架構裡，planner 和 executor 不是可獨立替換的零件，而是需要共享某種隱含工作語言與能力層級的協作對。 如果 planner 想的世界，和 executor 理解任務的方法不是同一套，整個 loop 會出現協調摩擦，最後浪費 round 與上下文。
所以這篇其實也在提醒另一個常見誤區：multi-agent 的效能不只看單個 agent 的能力總和，還要看它們之間是否能以同樣的 problem framing 協作。
我認為這篇真正重要的，不是 offensive 榜單，而是它重新定義了我們該怎麼讀 agent benchmark
這篇 paper 的真正價值，不在於證明某家模型今天在 CTF 比別人多解幾題，而在於它逼我們正視一件事：agent benchmark 的分數，本質上是整條 runtime stack 的聯合作品。
你看到 solve rate 提升，不能立刻把功勞全記到 model reasoning。那可能來自：
- 更完整的工具箱
- 更低摩擦的 tool discovery
- 更一致的 API / tool calling interface
- 更少干擾探索的 prompt scaffold
- 更協調的多代理角色配置
這對資安圈尤其重要。因為 offensive / defensive agent 的真實工作，本來就不是裸模型答題，而是在具體環境裡看得到、摸得到、叫得到工具，還能把輸出接回下一步行動。如果 benchmark 沒把這些 runtime 條件想清楚，最後量出來的很可能不是能力，而只是某套實驗配置的偶然優勢。
怎麼看這篇的限制？
當然，這篇也不是沒有邊界。
- CTF 仍然不等於真實入侵行動：它是有用 proxy，但不等於 enterprise environment、真實 lateral movement、權限限制與防禦干擾。
- 工具整合本身也可能偏袒某些模型：作者自己也承認，結果反映的不只 reasoning，還包括模型與 agent tooling / API integration 的相容性。
- prompt 結論未必可無條件外推：這篇主要在這個框架、這個 benchmark、這批模型上成立；換任務或換環境，效果可能不同。
但即便如此，這篇仍然有很高參考價值，因為它提供的不是單點技巧，而是一個更成熟的研究視角：不要再把 agent performance 當成 prompt magic，而要把它視為 runtime systems engineering 的結果。
總結
《Systematic Capability Benchmarking of Frontier Large Language Models for Offensive Cyber Tasks》最值得記住的地方，是它把 offensive cyber agent 的核心瓶頸，從「怎麼再多調幾句 prompt」重新拉回「agent 到底是不是站在一個夠完整的工作台上」。
在這篇裡，真正最穩的增益不是 fancy prompting，而是：
- 更完整的安全工具環境
- 更低摩擦的工具發現能力
- 更合適的模型選型
- 更一致而不是更花俏的多代理配置
如果把這篇放回更大的 agent security / cyber automation 脈絡裡看，我會把它濃縮成一句話：很多人以為 agent 的上限由模型決定，但在真正需要工具、環境與回饋閉環的任務裡，決定上限的常常是整個 runtime substrate 有沒有先長對。