In-Context Autonomous Network Incident Response 論文閱讀分析：真正讓 IR Agent 比較像系統的，不是它會講幾個步驟，而是它會不會一路重規劃
論文基本資訊
- 論文標題：In-Context Autonomous Network Incident Response: An End-to-End Large Language Model Agent Approach
- 作者：Yiran Gao、Kim Hammar、Tao Li
- 來源：arXiv / AAAI 2026 Summer Symposium
- 年份：2026
- 論文連結：https://arxiv.org/abs/2602.13156
- 主題：Incident Response、LLM Agents、Autonomous Defense、POMDP、Response Planning、SOC
如果前幾篇像 Multi-Agent Incident Response 跟 SIR-Bench 都在問「IR agent 到底該怎麼協作、怎麼評估」，那這篇 In-Context Autonomous Network Incident Response 比較像是在補另一個核心問題：當 agent 真正要一路從 log、alert 走到 response action，它到底該怎麼避免一邊想一邊飄掉？
這篇 paper 的企圖其實很明確：作者不想只做一個會讀 alert、吐建議的 security copilot；他們想做的是一個 end-to-end 的 incident response agent，把 perception、reasoning、planning、action 全塞進同一個 14B 模型裡，再用 rollout 規劃跟 in-context adaptation 去壓 hallucination 與長流程失憶。
一句話講它的野心，就是：
不是讓 LLM 幫 analyst 寫 response 建議，而是讓它自己沿著 incident state 一步一步規劃、執行、發現不對，再重規劃。
這篇論文在解什麼問題？
作者對既有做法有兩個不滿。
- RL 路線太依賴手工建模：要先把 incident environment 壓成 simulator、state、transition、reward，才能訓練 agent。
- 純 prompt-based LLM 路線太容易漂：看起來會講，但一長流程就容易 hallucinate，或者前後策略不一致。
這個批評很合理。因為 incident response 不是單步問答，而是一條持續更新假設的工作鏈：你先看到 alert，接著推測攻擊在做什麼，再決定要隔離、掃描、保留證據、還原服務，然後根據新的觀察修正前面的假設。如果 agent 沒有持續維護「目前系統恢復到哪裡」的內在狀態，它就很容易講得像有邏輯，實際上卻是在亂接。
這篇的核心想法：把 RL 的 lookahead 靈魂搬進 LLM agent
我覺得這篇最值得看的地方，不是它說自己有 perception / reasoning / planning / action 四個模組——現在很多 paper 都會這樣切。真正有意思的是，它不是把這四塊當流程圖畫漂亮而已，而是把 POMDP / rollout planning 那種「先預測後果，再選比較好的動作」的味道，硬塞回 LLM agent 裡。
它的大致流程是：
- Perception：根據 logs 與 alerts 推估目前 recovery state
- Reasoning：結合內建 security knowledge，推測攻擊 tactics 與後續可能觀察
- Planning：針對多個候選 response action 做 rollout，模擬後續 recovery trajectory
- Action：輸出具體回應動作
換句話說，它不是單純問模型「下一步該做什麼」，而是先讓模型提出多個候選動作，再把這些動作往後推演，挑比較可能把系統帶往 recovered state 的那條路。
這種設計的價值在於：它把 LLM 從「回答器」往「狀態驅動的規劃器」推了一步。
它怎麼定義 incident response 的內在狀態？
論文把 response planning 建成一個部分可觀測的 Markov decision process（POMDP）。這點很重要，因為在真實 incident 裡你永遠看不到完整真相：你只能從 alert、log、掃描結果、工具回傳慢慢拼湊。
作者用 recovery state 去表示目前事件處在什麼恢復階段，像是：
- 有沒有完成 containment
- 有沒有掌握攻擊面與影響範圍
- 有沒有保留證據
- 有沒有完成 eradication
- 有沒有完成 hardening
- 有沒有回到 recovered
這種抽象其實蠻聰明。它不是硬把所有系統細節都建模，而是把 IR workflow 最核心的進度與目標壓成一個可推理的 state。因此 agent 不用真的成為完整數位分身，但至少不會每一步都像在失憶。
這篇真正想壓的兩個老毛病：hallucination 與 context loss
作者說得很直接：目前很多 LLM-based IR 方法的問題，不是完全不會做，而是會在兩個地方摔倒。
- Hallucination：給出看似合理、其實不合適的 response action
- Context loss：流程一拉長，就忘了前面已經做過什麼、目前事件假設是什麼
而他們的解法也很務實：
- 用 rollout planning 去篩掉那些看起來會說、但模擬下去不太對勁的動作
- 用 in-context adaptation 在觀察到實際結果與預測不符時，修正 tactics conjecture 與後續計畫
這裡我最喜歡的一點是，它承認一件常被 agent demo 忽略的事：好的 response planning 不是一開始就算對全部，而是中途發現自己想錯時，能不能及時重規劃。
offline fine-tuning + online planning，這個組合比單純 prompt engineering 更像真的系統
論文把方法拆成兩階段：
- Offline fine-tuning：用 incident logs、對應 response plan 與 reasoning trace 去微調模型
- Online planning：實際 incident 來時，再基於目前觀察產生候選行動、做 rollout、選下一步
這個架構的好處是，它沒有把所有東西都壓在單次 prompt 上。很多 prompt-heavy agent 其實有一個根本弱點：你是希望模型在當下憑語言能力臨場硬撐整條流程。 但這篇做法比較像先把 IR workflow 的內在偏好學進去，再讓線上階段去處理當前 incident 的不確定性。
對 production-minded 的人來說，這種設計比較像真的 engineering：基底能力靠訓練，當前決策靠規劃，偏差修正靠回饋。
結果怎麼看？
論文的 headline result 很簡單：他們的 14B agent 在四組 incident datasets 上，平均 recovery time 比幾個 frontier model 更短，最多快到 23%。
拿來比較的對象包括：
- OpenAI O3
- Gemini 2.5 Pro
- DeepSeek-R1
- 以及同尺寸的輕量化 baseline
作者的解讀是：前沿模型不是沒有知識，而是沒有被 task-specific 地綁進 incident response planning 這件事。 所以它們也許知道很多 security 概念，卻不一定能穩定地形成一條有效 recovery sequence。
這點我基本同意。因為在 IR 場景裡，真正難的常常不是「你知不知道某個 technique」，而是你能不能按對順序做對事情，並且在新 evidence 進來時不把整條策略弄亂。
ablation 比 headline 數字更值得看
論文還做了 ablation，把幾個關鍵部件抽掉來看影響：
- 拿掉 fine-tuning
- 拿掉 planning
- 拿掉 context adaptation
結果很直觀：fine-tuning 與 planning 的影響最大，context adaptation 也有幫助，但沒有前兩者那麼關鍵。作者認為這是因為測試資料大多還是短流程，平均只有大約五步 action 左右，所以長上下文漂移還沒被完全放大。
這個結果我反而覺得很誠實。因為它說明一件事：目前這篇 paper 真正做出來的主體，不是什麼神奇的自我修正人格，而是「把 task-specific fine-tuning 加上 lookahead planning」這個組合。 context adaptation 比較像是往更長流程的一個方向，而不是今天最主要的 performance 來源。
這篇最有價值的，不是更強模型，而是更像 IR workflow 的 agent 結構
如果只看 benchmark headline，很容易把這篇誤讀成又一篇「我們的 agent 比某某 frontier model 快幾%」的 paper。但我覺得它更有價值的地方其實是這個：
它把 incident response agent 從「會講 response 建議」往「會維護 incident state、做 lookahead、在預測失準時重規劃」推近了一步。
這個差別很重要，因為很多 security agent demo 最大的問題，就是把規劃包裝成敘事。模型看起來很像在推理，實際上只是把 alert 重述成比較長的段落。但這篇至少有在努力把 planning 做成顯式流程，而不是純靠話術撐住。
但這篇也很清楚暴露了 agentic IR 的現實瓶頸
論文最後也很老實地承認，現在最大限制其實不是模型會不會講，而是算得太慢。
他們的 Monte Carlo tree search / rollout 規劃成本大致跟 O(MN) 成長，而且整套系統跑在單張 A100 上，平均處理一個 incident 要 20 分鐘才生出五步 response plan。
這件事非常關鍵，因為它直接提醒大家：把規劃做得比較像真的 incident response，通常就代表成本、延遲、工程複雜度會一起上來。 你不能一邊要求 agent 不要亂講、要能看狀態、要會回頭修正，又假設它能像聊天機器人一樣秒回。
所以如果把這篇放回 production 現實裡，我會說它比較像是在證明一條方向：真正可用的 autonomous IR agent，多半不是更大的聊天模型，而是更強的 state tracking + planning + replanning 結構。
放回最近 sectools.tw 主線裡，它補的是哪一塊？
如果把最近這串文章串起來看，這篇的位置其實很漂亮：
- SIR-Bench 在問：你怎麼知道 agent 不是只會背 alert？
- Multi-Agent Incident Response 在問：不同 agent / 角色如何協作？
- 這篇 在問：就算只有一個 agent，它要怎麼把整條 IR workflow 接起來，而且不要中途亂掉？
也就是說，這篇補的是 single-agent response planning architecture 這一塊。它不是在講 collaboration，而是在講：一個 agent 自己要怎麼維持策略連續性。
我的看法
我自己覺得這篇比表面上看起來更值得注意，因為它沒有把重點放在 flashy demo，而是直接去碰 autonomous IR 最麻煩的骨頭：長流程規劃。
它真正提出的關鍵觀察大概是這句：
incident response agent 真正難的不是懂多少 security 知識，而是能不能把「目前恢復到哪裡、下一步做什麼、做完後應該看到什麼」這三件事穩定接起來。
這也解釋了為什麼這篇會把 RL 的 planning 靈魂拉回來。因為一個只靠 prompt 的 agent，也許很會說；但真正像 production 的 agent，需要的不只是會說，而是會沿著 state 前進、在偏差出現時收斂回來。
如果要我用一句話總結這篇 paper，我會這樣講：
這篇真正往前推的，不是讓 LLM 更像 analyst，而是讓 IR agent 終於比較像一個會持續重規劃的控制系統。
而在 autonomous incident response 這條路上，這可能比再多幾句漂亮解釋更重要。