In-Context Autonomous Network Incident Response 論文閱讀分析：IR Agent 要會的不只是回答，而是持續修正與規劃

論文基本資訊

• 論文標題：In-Context Autonomous Network Incident Response through LLM Agentic Workflows
• 年份：2026
• arXiv：https://arxiv.org/abs/2602.13156
• 程式碼：https://github.com/TaoLi-NYU/llmagent4incidense-response-aaai26summer
• 主題：Incident Response、LLM Agent、SOC、POMDP、Monte Carlo Tree Search、World Model、In-Context Adaptation

如果你最近一路追 sectools.tw 這波 CTI / SOC / agentic security 論文，應該會慢慢發現一個共通困境：大家都在說 LLM 可以協助 incident response，但真正麻煩的從來不是「能不能說出一個像樣的回應建議」，而是它能不能在不完整觀測、長鏈決策、持續變動的攻防情境裡，維持一致、收斂、而且不要太早亂動。

這篇 In-Context Autonomous Network Incident Response through LLM Agentic Workflows 的有趣之處，就在於它不是再做一個把 prompt 寫很長的 IR copilot，也不是單純把 RL policy 和 LLM 黏起來，而是試著回答一個更本質的問題：

如果 incident response 本質上是一個部分可觀測、需要邊看邊修正假設的長程規劃問題，那 LLM 要怎麼在不手工建 simulator 的前提下，學會感知、推理、規劃、再執行？

作者的答案很直接：把 IR 當成一個 POMDP，再把 perception、reasoning、planning、action 四個能力壓進同一個 14B 的輕量模型裡，靠 LoRA fine-tuning 加上 rollout planning 來跑完整條 response workflow。從 paper positioning 來看，這篇剛好卡在一個很值得注意的位置：它既不滿足於純 prompt orchestration，也不想回到重度仰賴手工環境建模的 RL 路線。

這篇論文想解決什麼問題？

作者對既有 incident response automation 的批評其實相當到位。傳統 RL 式方法的優點，是它們很適合長時序決策，也很自然地能表達「現在做這個 containment，會如何影響之後的 recovery time」。但問題是，這種方法通常需要一個你先手工建好的 environment model，得把真實世界裡的 system log、alert、attack progression、response action 全部壓成 simulator 可以吃的結構化狀態。

這件事的代價很高，因為你其實在做兩層工程：

• 先建一個可用的 incident simulator
• 再在那個 simulator 上訓練 policy

而這麼做常常會把原本 log 與 alert 中很有價值的語義訊號壓扁掉。也就是說，RL 雖然擅長規劃，但它經常要先犧牲掉真實安全資料原本最重要的文字脈絡。

另一邊，近年的 LLM-for-IR 方法雖然能直接看 log、看 alert、看 incident description，但多半還是停在 prompt engineering 層。作者認為這會帶來兩個典型問題：

• Hallucination：產生聽起來合理、其實不適合的 response action
• Context loss：在多步驟長鏈 response 過程中逐漸忘記前面已做過什麼、現在哪個假設還成立

這兩個問題在 IR 特別致命。因為 incident response 不是一次性問答，而是一路根據新觀測修正判斷的流程。你如果只是「每一輪都很會說」，但無法維持前後一致的世界模型，那整體 response strategy 很容易越走越歪。

核心想法：把 Incident Response 重新表述成 POMDP

這篇 paper 最有骨架的地方，在於它不是直接喊 agentic workflow，而是先把問題建模清楚。作者把 incident response 視為一個 partially observable Markov decision process。

在這個設定裡，防守方並不知道真實完整狀態，只能透過 logs 與 alerts 去推測目前網路的 recovery progress。作者把 recovery state 設成一個六維布林向量，分別對應：

• Containment：是否已阻止攻擊擴散
• Assessment：是否已判定範圍與嚴重度
• Preservation：是否已保留鑑識證據
• Eviction：是否已將攻擊者驅逐／終止惡意活動
• Hardening：是否已完成補強，降低再次發生風險
• Restoration：是否已恢復服務與存取

這種設計很值得記，因為它沒有把 IR 粗暴地縮成「是否修好」這種單一 label，而是保留了 response process 本來就具有的階段性。這代表模型不是只在猜「有沒有中毒」，而是在追蹤整條 recovery path 到底走到哪一步。

四個能力塞進同一個 14B 模型：Perception、Reasoning、Planning、Action

作者主張，他們的方法不是多模型拼裝，而是讓一個輕量的 14B LLM 同時承擔四種功能：

1. Perception：根據歷史觀測與已執行動作，推斷當前 recovery state
2. Reasoning：結合安全知識與攻擊戰術假設，預測未來 alert 與狀態演化
3. Planning：對候選 response action 做 rollout，估計哪條路 recovery cost 最低
4. Action：把高階 response strategy 轉成具體可執行動作

從架構角度看，這篇的野心其實不小。很多工作是把「看懂 log」和「規劃 response」拆給不同 agent 或不同 prompting stage；而這篇想做的是把它們揉進一個可微調、可本地部署的統一行為體裡。

作者用的是 DeepSeek-14B（Qwen-compatible），透過 LoRA 在 CSLE-IncidentResponse-V1 上做 supervised fine-tuning，取前 50,000 組 instruction-answer pair 訓練。這表示它不是只靠 zero-shot prompting 撐場面，而是有明確在 incident-response-specific dataset 上把 state estimation、alert prediction、action generation 這些能力做 task shaping。

這篇真正有意思的，不是模型會答，而是它開始有內部 world model

我認為這篇最值得看的地方，不是它用了什麼名詞，而是它試圖把 LLM 從「回答器」往「world-model-like planner」推一步。

作者讓模型在 perception 階段先估計當前狀態 ŝ_t，接著在 reasoning 階段不只預測下一步 action 可能帶來的狀態變化，還會預測下一輪可能出現的 alert。也就是說，它不是只問：

• 現在該做什麼？

而是同時問：

• 如果我這樣做，下一步系統看起來應該會怎樣？
• 如果真實世界回來的 alerts 和我預期的不一樣，代表我原本的 attack tactic 假設可能錯了嗎？

這就是這篇所謂的 in-context adaptation。模型不是一條路走到底，而是拿「預測 alert 與真實 alert 的落差」當成校正訊號，回頭修正自己對攻擊戰術的推測，再重新規劃 response path。

這件事的重要性在於：IR 的難點從來不只是 action selection，而是 belief update。 你對攻擊方式的理解如果變了，後面的 containment、evidence preservation、eradication 先後順序都可能要重排。作者其實是在把這種 belief revision 明確放進 agent loop 裡。

Planning 怎麼做？用 rollout 而不是直接相信第一個答案

這篇另一個我認為很加分的點，是它沒有把 LLM 的第一個輸出當神諭。作者在每一輪 response planning 裡，會先讓模型產生 N 個候選 action，接著對每個 action 做 M 條 rollout trajectory 模擬，估計從這個動作出發一路走到 terminal recovery state 的累積成本。

這本質上是一種 Monte Carlo tree search under misspecification 的精神：先承認 world model 可能不準，但仍然可以用它來做 lookahead，然後再靠真實新觀測不斷修正。

對安全場景來說，這個想法比「模型直接給結論」成熟很多。因為真正危險的不是模型不知道，而是它太快相信自己知道。rollout planning 至少在某種程度上替 response action 加了一層篩選機制，把那些會導向較長 recovery path 或和後續觀測不一致的動作當成 hallucination / context rot 候選先刷掉。

實驗怎麼做？

作者把評估分成兩層。

1. 感知與推理能力

在 state estimation 上，他們從資料中抽出 17,600 組測試樣本，評估 recovery state prediction 的 exact-match accuracy 與多標籤 F1。結果相當漂亮：

• Exact-match accuracy：0.98
• Class-agnostic average F1：0.9902
• Class-specific average F1：0.9822

從 per-entry F1 看，containment、assessment、preservation、eviction 幾乎都非常高；hardening 與 restoration 稍微難一點，但仍在 0.95 左右。這其實很合理，因為 hardening / restoration 往往比 containment 更依賴跨步驟脈絡，而不是單點觀測。

在 alert prediction 方面，作者看的是 alert classification 與 priority pair 的生成，針對高頻 tactic 場景做評估。結果顯示模型在攻擊情境下的 alert generation 表現明顯比 normal activity 好，像某些 tactic 組合 F1 可到 0.85–0.87，但在正常活動場景僅約 0.57。這個結果也很真實：異常模式常常比正常行為更有結構，false alarm 與 benign noise 反而更難穩定建模。

2. 真正的 response planning 能力

更重要的是 end-to-end IR planning 評估。作者整合四個資料集：

• CTU-Malware-2014
• CIC-IDS-2017
• AIT-IDS-V2-2022
• CSLE-IDS-2024

這些資料集涵蓋 Windows / Linux、malware、ransomware、DoS、web attack、SQL injection、多階段攻擊與特定 CVE exploit。評估方式不是只看分類分數，而是看 response plan 的恢復成本。作者把每個 action 的基礎成本設成 1，若是多餘或效果差的步驟，再額外加懲罰；若整條動作鏈最後無法到 terminal state，成本直接拉到 20。

對照組則是 DeepSeek-R1、Gemini 2.5 Pro、OpenAI o3 這些 frontier model。作者的結論是：雖然 failure rate 接近，但他們的 14B 專用模型能把 recovery time 再縮短最多 23%。

這個 23% 為什麼值得看？

因為它的含義不是「小模型贏大模型」這麼簡單，而是：在 incident response 這種任務上，專門對齊 workflow 的規劃能力，比單純更大的通識知識庫更重要。

frontier model 當然有更多一般知識，也可能更懂最新 security buzzword，但如果它沒有被教會怎麼維持 recovery state、怎麼做多步驟 lookahead、怎麼在觀測不一致時回頭修正 tactic 假設，那最後產出的 response plan 仍可能比較慢、比較散、比較不收斂。

換句話說，這篇其實再次提醒了一件事：在安全高風險工作流裡，能力的關鍵常常不只是 knowledge，而是 task-shaped decision structure。

Ablation 告訴我們什麼？

作者還做了 ablation，把幾個關鍵部分拿掉比較。結果很直白：

• 拿掉 fine-tuning（也就是 perception / reasoning 對齊）會明顯變差
• 拿掉 planning 也會顯著變差
• 拿掉 in-context adaptation 仍會退步，但退步幅度相對小一些

作者猜測 adaptation 影響看起來沒那麼大，部分原因是測試資料裡很多 response sequence 還偏短，通常只有五步左右。這點我認為很合理。若未來把任務拉長到真正大型企業網路、多子系統、多權限域的 incident response，context adaptation 很可能會變得更重要，因為那時候 belief drift 和 tactic mis-specification 的成本會被放大。

我怎麼看這篇？

我覺得這篇論文最有價值的地方，是它很清楚地踩在兩種極端之間。

一邊是傳統 RL-based cyber defense：規劃能力強，但太依賴手工建模；另一邊是純 prompt-based LLM agent：看起來靈活，但容易 hallucinate，也容易在長流程裡 context rot。這篇想走的是中間路線：用 LLM 保留文字語義與安全知識，用 RL 啟發的 lookahead planning 保留長程決策結構。

這條路我認為比很多「把大模型接上工具就叫 autonomous IR」的論文成熟。因為它承認 incident response 的本質不是單輪問答，而是受限資訊下的 sequential decision-making。只要這個本質沒有被正視，很多 IR agent 最後都會淪為會講話的 incident playbook summarizer。

這篇的限制也很清楚

• 評估成本仍偏代理式： action quality 與 recovery penalty 仍部分依賴 GPT-5.2 評估，不是完整真人 blue-team 介入。
• scalability 是硬傷： Monte Carlo search 複雜度是 O(MN)，作者也直接承認平均處理一個 incident 需要約 20 分鐘 才能生成五步 response plan。
• 測試序列仍偏短： adaptation 的真實價值可能尚未被完全放大。
• attack-model calibration 目前仍借助 frontier LLM： 雖然主體可本地部署，但關鍵修正步驟尚未完全閉環在同一體系內。

也就是說，這篇比較像是在證明一條方向：LLM-based IR agent 要想真的往前走，不能只加更多 prompt，而要把 state tracking、world modeling、lookahead planning、belief correction 一起做進來。

對實務有什麼啟發？

如果你在做 SOC automation、IR copilot 或安全 agent，這篇至少給了幾個很實用的提醒：

1. IR 不是單點分類，而是多階段 recovery process：系統若無法明確追蹤 containment / assessment / eviction / restoration 等狀態，後面很難規劃得穩。
2. 不要太相信第一個 action：candidate generation 後做 rollout 篩選，是很值得保留的安全護欄。
3. 預測未來觀測，比只預測下一步動作更重要：因為 alert mismatch 才是最自然的 calibration signal。
4. 專用小模型 + workflow alignment，不一定輸給 frontier model：尤其在高結構、長流程、強約束的安全任務上。
5. 真正的瓶頸會落在成本與延遲：20 分鐘生五步 response plan，在 production IR 還遠遠不夠，需要更便宜的 simulation 或更強的 parallelization。

總結

In-Context Autonomous Network Incident Response 這篇不是那種看完會覺得「明天就能把 SOC 全自動化」的論文，但它很值得讀，因為它開始把問題問對了。

它提醒我們：incident response 真正難的，不是讓模型生成一句看似專業的建議，而是讓它在不完整觀測下維持一個可持續修正的世界模型，能根據新 alert 校準自己，並在多條可能路徑中挑出 recovery cost 更低的那一條。

如果說 OpenSec 那類工作在提醒我們 IR agent 最大的風險是太早動手，那這篇則是在補另一半：IR agent 真正需要的，不只是 restraint，還要有規劃。 而這種規劃，不該只靠更大的模型硬背，而要靠更貼近 incident workflow 的 decision structure 去養出來。

一句話收掉這篇的重點，大概會是：

在 Incident Response 裡，真正有價值的 LLM，不是最會回答的那個，而是最能一邊觀察、一邊修正、一邊規劃下一步的那個。

免責聲明

本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、原始論文 source、技術文件與可取得之研究資料進行彙整、解讀與摘要；儘管已盡力確保完整性與可讀性，仍可能因模型理解限制、資料版本差異或語意轉譯而存在疏漏、不精確或更新延遲之處。實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。