FORGE 論文閱讀分析：當 LLM 真正開始碰 binary analysis，決定上限的往往不是會不會想，而是整條分析流程能不能一邊推理、一邊驗證、一邊續跑

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：Feedback-Driven Execution for LLM-Based Binary Analysis
• 作者：Qiang Li、Haining Wang
• 年份：2026
• 來源：arXiv:2604.15136
• 論文連結：https://arxiv.org/abs/2604.15136
• DOI：10.48550/arXiv.2604.15136
• 主題：Binary Analysis、Vulnerability Discovery、LLM Agents、Firmware Security、Reasoning-Action-Observation、Agentic AppSec

如果最近一整串 agent security 論文在談的是 prompt injection、MCP control plane、memory poisoning、authorization 跟 runtime governance，那這篇 FORGE 值得補進來的原因，是它把視角拉回另一個同樣很現實、但比較少被講清楚的問題：當 LLM 被拿去做長鏈、分支很多、資訊不完整的安全分析任務時，真正先卡住的常常不是模型不夠懂，而是整條 execution model 太像一次性問答。

作者挑的場景是 binary vulnerability analysis。這個題目很適合檢驗 agentic system 的真本事，因為 binary analysis 幾乎把幾個最麻煩的條件一次湊齊了：

• 高階語意不完整，沒有變數名、型別、註解這些 source-level 提示
• 必須靠工具逐步看 disassembly、call chain、data flow 與 taint path
• 探索常常是多路徑、長跨度，而且前一步看錯，後面就會越走越偏
• 最後不只要「猜可能有洞」，還要留下可以驗證的 evidence chain

所以我會把這篇 paper 的主線濃縮成一句話：對 binary analysis 這種長流程安全任務來說，真正該被重設計的不是單一 prompt，而是整條 reasoning、tool interaction 與 evidence construction 的執行架構。

這篇論文在解什麼問題？

作者先批評了一種現在很常見、但也很容易被默認的做法：one-pass analysis。也就是先用靜態分析工具把某個 global representation 建起來，再把那些切片、反組譯結果、decompiled code 一次丟給模型，期待它直接推理出漏洞。

這種方法的問題，在 source code 上可能還勉強撐得住，但到了 binary analysis 就很容易失真。因為 binary 世界本來就是部分可觀測、語意殘缺、需要反覆探索的環境。你不太可能一開始就把所有有用資訊完整建好，然後再讓模型只靠一次性的上下文消化一切。

作者的核心主張是：binary analysis 比較像 sequential decision process，而不是靜態閱讀理解。 專家分析 binary 時，通常也不是先拿到一張完美地圖再開始判斷，而是一邊假設、一邊追 call、一邊看 dependency、一邊修正自己對程式行為的理解。

也就是說，真正缺的其實不是更多 token，而是讓模型可以用 reasoning → action → observation 這種閉環方式工作，並且能在中途根據新證據改變探索方向。

FORGE 的核心觀點：把 binary analysis 從「一次性推理」改成 feedback-driven execution

這篇 paper 最值得記住的概念，就是它把 LLM-based binary analysis 重新定義成 feedback-driven execution。

這裡的意思不是單純讓 agent 會調工具而已，而是讓每一步工具互動都變成下一步推理的輸入，形成真正的執行閉環：

• 先根據目前掌握的證據形成局部假設
• 再選擇下一個分析動作，例如 disassemble function、trace call、看某段 data flow
• 根據新拿到的 observation 更新推理
• 必要時分裂成多條探索路徑，而不是逼單一上下文硬吞所有分支

這個 framing 很重要，因為它把「模型到底會不會 binary analysis」這個問題，重新拉回系統設計層：如果你的 execution model 天生不支援長鏈回饋、分支探索與中途修正，再強的模型也很容易在複雜 binary 上變成高級猜題器。

最有價值的設計：Dynamic Forest of Agents

FORGE 提出的具體做法，是一個叫做 Dynamic Forest of Agents（FoA） 的執行模型。這也是整篇論文最值得看的地方。

作者不是讓一個 agent 從頭到尾扛完整條分析鏈，而是把分析過程拆成一片會動態長出來的 agent forest。每棵 tree 以某個 source-rooted analysis process 為起點，再往下分出不同子任務、不同探索分支。

這種設計背後要解的其實是兩個經典失控點：

• Reasoning depth：分析步驟一長，前面看過的東西會被忘掉，錯誤也會一路累積。
• Reasoning breadth：同時要追很多 source-sink 組合與多條 propagation path，單一上下文很快就爆掉。

FoA 的做法很像把大任務拆成很多局部、有限上下文、可平行探索的分析單元。這不只是為了省 token，而是為了把 reasoning stability 問題壓回可控範圍。作者的意思其實很直白：長鏈任務不是不能做，而是不能再假設一個 agent 的上下文永遠不會崩。

這篇論文真正打中的，不只是發現漏洞，而是怎麼留下可重放的證據鏈

我覺得 FORGE 很加分的一點，是它沒有把 binary analysis 只當成「找答案」問題，而是把中途產生的 artifact 也當成核心產出。

論文裡提到，FORGE 在分析過程中會持續記錄像是：

• call-chain fragments
• symbolic values
• taint flows
• 與工具互動得到的中間證據

這些東西的價值不只是在當下幫推理，更重要的是它們可以被拿去做 verification。換句話說，FORGE 想做的不是那種「模型覺得這裡可能有洞」的脆弱式發現，而是把 discovery 跟 validation 放進同一條 evidence-preserving workflow。

這件事其實很符合最近 sectools.tw 一直在追的主線：真正可落地的 agent，不是只會給答案，而是要能把答案怎麼來的、證據在哪裡、哪一步需要再驗，清楚留在系統裡。

實驗結果怎麼看？

論文最亮眼的數字是：

• 在 3,457 個 real-world firmware binaries 上做評估
• 找到 1,274 個 vulnerabilities
• 分布在 591 個 unique binaries
• precision 達到 72.3%

作者還拿 FORGE 去跟 Mango、SaTC、LATTE、SWE 等既有方法比較，論文主張它不只 precision 有競爭力，還能涵蓋更廣的漏洞型態。

這裡我認為最值得看的，不只是 72.3% 這個數字本身，而是它背後在說什麼：當 binary analysis 被重構成 feedback-driven、decomposed execution system 之後，LLM 不再只是在固定 representation 上做表層判讀，而是真的能支撐比較長、比較像實務分析的探索過程。

當然，72.3% precision 也不該被解讀成「已經可以全自動上 production 不用人看」。但對這種高複雜度、低可觀測的任務來說，這個結果至少說明一件事：execution structure 本身，就是 LLM security tooling 能不能 scale 的一級因素。

FORGE 為什麼值得放進 agentic security / AppSec 的脈絡裡看？

表面上這篇看起來像 binary analysis 論文，但如果把它放到更大的 agentic security 脈絡，它其實剛好補上一塊很關鍵的拼圖：agent 的能力上限，不只取決於 model intelligence，也取決於 runtime 如何處理 partial observability、branching exploration 與 evidence reuse。

這跟最近很多 agent 論文其實是同一條邏輯，只是落點不同：

• Prompt injection / MCP security 在談 untrusted input 怎麼接管流程
• Authorization / runtime governance 在談 agent 憑什麼做某件事
• FORGE 則是在談：就算沒有被攻擊，當任務本身已經很長、很分支、很不完整時，agent architecture 怎麼樣才不會自己先崩

所以我會把它看成一篇很有代表性的 agentic AppSec systems paper。它提醒我們：很多看起來像「模型能力不足」的問題，本質上其實是 execution design 沒有把長鏈任務當成長鏈任務來設計。

我特別認同的一點：作者把「分析」當成 runtime，而不是當成離線閱讀

這篇論文的一個成熟之處，是它沒有把 binary analysis 浪漫化成單次 prompt engineering 問題，而是明確承認這是一種 runtime process。

只要是 runtime process，就會有幾件事一定要面對：

• 中間狀態怎麼保存
• 分支怎麼管理
• 錯誤怎麼隔離，不要整串 reasoning 一起污染
• 中途證據怎麼回傳、彙整、重放

這個觀點其實很值得拿來看今天很多 security agent 系統。因為不少 agent demo 的隱含前提還是「把資料塞給模型，模型自然會想」。但一旦任務需要持續探索、反覆確認、跨多路徑比較，那種設計很快就會暴露出 fragility。

限制與保留

• precision 不是完美準確，72.3% 代表它已經很有競爭力，但仍需要人類或額外驗證流程接手高風險發現。
• 場景聚焦在 firmware binaries，雖然 execution insight 很有泛化性，但不同類型的 reverse engineering / vulnerability discovery 工作流不一定能直接照搬。
• FoA 的協調成本與工程複雜度不低，這類 decomposed multi-agent execution 要真的產品化，還要面對 orchestration、observability 與成本控制問題。
• 論文重點是 capability / execution stability，不是防禦型安全論文；也就是說，它強化的是 agent 做分析的能力，並不直接解決 prompt injection 或 tool trust 這些外部攻擊面。

一句話總結

FORGE 真正值得看的，不是它又讓 LLM 多找出幾個 binary 漏洞，而是它把這件事從一次性問答重構成 feedback-driven、可分解、可續跑、可保留證據的 execution system，直接點破了長鏈安全分析真正的 bottleneck 在哪裡。

結語

如果你最近已經看膩了「模型又更會回答安全問題」那類 paper，FORGE 會是比較有意思的一篇。因為它在講的其實不是回答品質，而是當任務本身需要長時間探索、反覆驗證、跨多分支推進時，agent 應該怎麼被做成一個真正能工作的系統。

對 binary analysis 是這樣，對很多更廣義的 AppSec、reverse engineering、甚至長鏈 incident investigation workflow 也是這樣。真正讓 agent 變得比較像工程系統、而不是只像會說話的模型，關鍵常常不在 prompt，而在 execution architecture。

---

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