Multi-Agent Collaboration in Incident Response 論文閱讀分析：當 IR 團隊開始由 LLM 組成，決定成敗的可能先不是模型，而是編制
如果最近這波 sectools.tw 的主線，已經一路從 SOC triage、incident response planning、agentic workflow、runtime guardrails 走到「AI Agent 到底能不能真的在高壓資安場景裡協作」，那這篇 Multi-Agent Collaboration in Incident Response with Large Language Models 剛好補上一塊很關鍵、但也很容易被高估的拼圖：當我們不再只問單一模型會不會回答，而是讓一整隊 LLM 扮演 incident captain、generalist、network analyst、endpoint expert 時，團隊結構本身會不會開始決定成敗？
這篇論文的有趣之處，不是它做了一個超逼真的 production SOC，而是它很誠實地選了一個夠結構化、夠接近協作決策、又能重複跑實驗的場域：Backdoors & Breaches。這本來是資安圈很有名的 incident response tabletop game，作者把它改造成 LLM multi-agent simulation，用來比較不同團隊配置下，AI 團隊在 IR 任務裡到底怎麼互動、怎麼失敗、又怎麼比較容易成功。
論文基本資訊
- 論文標題：Multi-Agent Collaboration in Incident Response with Large Language Models
- arXiv：https://arxiv.org/abs/2412.00652
- 年份：2024
- 作者：Zefang Liu 等
- 主題：Incident Response、Multi-Agent Systems、LLM、SOC、Tabletop Simulation、Team Structure
這篇論文想回答的，不是「模型夠不夠聰明」，而是「團隊怎麼排比較像樣」
很多資安 AI paper 都有個共同問題：喜歡把能力歸功到模型本身，卻把協作結構當背景音。可是真實 incident response 從來不是單人賽。你永遠要面對：
- 誰來主導決策
- 誰提供不同角度的證據
- 什麼時候需要集中領導，什麼時候該讓專家各自判斷
- 怎麼避免團隊一直重複做高把握但低價值的動作
這篇論文真正想問的是：如果把 incident response 看成多角色協作問題，而不是單模型答題問題，那 centralized、decentralized、hybrid 這些組織結構，會不會直接影響 AI 團隊的 IR 表現？
這個切角很值得寫，因為它把問題從「LLM 能不能進 SOC」往前推了一步，變成「如果 LLM 真的進 SOC，它會以什麼組織形式進去？」
作者怎麼做？用 Backdoors & Breaches 當 IR 協作沙盒
Backdoors & Breaches 是一個 incident response 桌遊。遊戲裡，防守方要在有限回合內找出攻擊鏈不同階段的隱藏 attack cards，並透過 procedure cards 去調查、辨識、揭露攻擊行為。這當然不等於真實 SOC，但它剛好很適合研究一件事：在有角色分工、有不完整資訊、有 procedure 選擇、有隨機事件干擾的情況下，一組代理人怎麼協作決策。
作者把這套框架搬到 AutoGen 上，讓不同 LLM agent 扮演：
- incident captain
- team leader
- generalist defenders
- endpoint security expert
- network traffic analysis expert
- log / behavioral analysis expert
- deception / containment expert
- incident response expert
- beginners
這些 agent 透過 shared group chat 互相討論，再由 tool executor 處理像是抽卡、擲骰、紀錄等後端流程。換句話說，這不是單純讓模型各自答題，而是把它們放進一個會互相影響、會拖累彼此、也可能互補彼此的團隊互動場景。
六種團隊結構，才是這篇 paper 的主菜
作者比較了六種 defender team structures：
- Homogeneous centralized：一位 leader 帶四位 generalists
- Heterogeneous centralized：一位 leader 帶多位不同專家的成員
- Homogeneous decentralized：五位 generalists 平權協作
- Heterogeneous decentralized：多位不同專家平權協作，沒有 leader
- Homogeneous hybrid：專家帶新手
- Heterogeneous hybrid：不同專家搭配 beginners
光看這組設計，你就知道作者關心的不只是「specialist 比 generalist 強不強」，而是更組織學的問題：
- 專業分工會不會反而增加協調成本？
- 有 leader 時是否更容易收斂？
- 混合編制能不能兼顧穩定與多樣性？
這種問題在真實 SOC 特別重要。因為很多人談 AI agent 時，會想像只要把更多 specialized agents 疊上去就會更強；但實際上，角色越多、觀點越多、上下文越碎，往往也越難把行動收斂到對的 procedure 上。
實驗怎麼跑？
作者使用 GPT-4o 作為 agent backbone，temperature 設為 1，對每種 team structure 各跑 20 次模擬。每一局最多 10 回合，目標是在回合限制內揭露四張對應不同攻擊階段的 attack cards。
這裡最值得注意的不是 benchmark 規模有多大，而是它讓比較基準相對乾淨：同一個遊戲規則、同一類任務框架、同樣數量的 defender agents，只變團隊結構與角色配置。 所以最後差異比較能歸因到協作方式，而不是雜訊太大。
結果很有意思：不是專家越多越強，而是結構越清楚越穩
論文的核心結果很直白：
- Homogeneous centralized 與 homogeneous hybrid 成功次數最高，各有 14 次成功
- Homogeneous decentralized 也不差，有 13 次成功
- Heterogeneous centralized 與 heterogeneous decentralized 反而表現較差
這個結果很值得停一下。因為直覺上，你可能會以為「多專家團隊」應該比較懂 incident response；但作者觀察到的反而是：當專家觀點變多、優先順序不同、沒有足夠好的收斂機制時，團隊更容易卡在共識、排序與 procedure 選擇上。
也就是說，這篇 paper 給出的訊息不是「specialization 沒用」，而是：在 LLM multi-agent IR 裡，協調成本常常先吃掉專業優勢。
為什麼 centralized 和 hybrid 反而比較好？
論文裡的解釋很合理，而我覺得也很貼近真實團隊：
- Centralized teams 有比較明確的 decision owner，因此不容易在多個 plausible procedure 間來回打轉
- Homogeneous teams 因為語境比較一致，彼此更容易快速對齊，不太會出現「每個人都從自己專業看事情」造成的分裂
- Hybrid teams 雖然有能力差異，但 expert / beginner 形成某種 mentor 結構，反而讓團隊比較容易在討論中收斂
換句話說，成功的不只是知識量，而是知識如何被組織成可執行的團隊流程。 這其實和很多最近的 agentic security paper 很能互相呼應：真正決定系統好不好用的，往往不是 base model 再強 5%，而是 orchestration、memory、authority 與 communication design 有沒有做好。
失敗案例透露了更真實的問題：LLM 團隊很容易過度依賴「看起來穩」的 procedure
作者還分析了 12 個 failure cases，這部分很有價值。因為失敗通常比平均分數更能說明真問題在哪。
幾種常見失敗模式包括：
- 過度依賴高 modifier、看起來最保險的 procedure，而忽略更符合上下文的調查手段
- 專家之間各看各的，導致重要線索沒有被及時優先化
- 太晚做 behavior / memory / log 方向的分析
- 團隊把 procedure 當 checklist，而不是 context-aware investigation
這點很值得記。因為它說明一個常見錯覺：多代理協作不一定自然帶來更靈活的推理，反而可能把某些看似合理的 heuristics 放大成團隊慣性。
這和最近很多 SOC / IR 論文的結論有一條共通主線——AI 在資安裡最常見的問題，往往不是完全看不懂，而是太早收斂到一條表面上合理、實際上不夠對的處置路徑。
這篇論文的價值，不在於它模擬得百分之百真，而在於它開始把「組織設計」變成研究對象
如果要挑這篇 paper 最值得 sectools.tw 讀者記住的一點，我會選這句：當資安 agent 變成團隊問題後，architecture 會開始比單點能力更重要。
它最有價值的地方，是把過去很常被當成 implementation detail 的東西——team structure、role assignment、centralization、specialization、communication——拉到檯面上，當成主要變因來看。這對之後所有想做 SOC copilot、IR copilot、multi-agent blue team 的人都很重要。
因為你最後要面對的不是「可不可以做五個 agent」，而是：
- 這五個 agent 之間誰有決策權？
- 什麼情況下需要 leader？
- 專家分工到底是在增加 coverage，還是在增加 friction？
- 怎麼避免團隊把錯的 heuristic 越討論越有信心？
它的限制也很清楚
當然，這篇論文不是沒有侷限。
- 它用的是 Backdoors & Breaches，不是 live SOC production environment
- 任務目標相對明確，不像真實 incident response 那麼開放、模糊、受外部資料品質限制
- agent backbone 主要是單一 frontier model，還沒比較不同模型人格與能力差異
- 樣本量不算很大，20 次 × 6 結構比較像 exploratory study
但這些限制不會讓它失去價值，反而說明它真正的位置：這不是一篇在證明 AI 已經能接手 IR 的論文，而是一篇開始認真研究「IR agent 團隊該怎麼設計」的論文。
跟近期 sectools.tw 這條主線怎麼接？
如果把它放進最近站上的脈絡裡，這篇剛好卡在一個很有意思的位置。
- IRCopilot、In-Context Autonomous Network Incident Response 這類文章，重點比較在單一或少數 agent 的 planning / response 能力
- OpenSec、Hallucination-Resistant Security Planning 關心的是 agent 何時不該太早動手
- LanG、Meta-Cognitive Architecture 開始把治理與 autonomy 拉進來
- 而這篇則補上另一個很實務的維度：agent team organization
它提醒我們，未來 SOC / IR 系統的競爭，可能不只是模型誰比較聰明，而是哪一套 agent 組織方式更能穩定協作、快速收斂、又不把不同專長的 friction 放大成 decision paralysis。
一句話總結
這篇論文最值得看的地方，不是它證明了多代理 IR 很厲害，而是它開始讓我們正視：當 AI 進 incident response，不只是模型要會想，整個團隊還要會收斂。
本文由 AI 產生、整理與撰寫。