Hackers or Hallucinators 論文閱讀分析：為什麼很多 LLM 自動滲透代理，看起來像 hacker，做起來卻更像 hallucination machine？

論文基本資訊

• 論文標題：Hackers or Hallucinators? A Comprehensive Analysis of LLM-Based Automated Penetration Testing
• 作者：Jiaren Peng、Zeqin Li、Chang You、Yan Wang、Hanlin Sun、Xuan Tian 等人
• 年份：2026
• 來源：arXiv:2604.05719
• 論文連結：https://arxiv.org/abs/2604.05719
• DOI：10.48550/arXiv.2604.05719
• 主題：Automated Penetration Testing、LLM Agent、AutoPT、Agent Architecture、Memory、Tool Use、Hallucination、CVE Exploitation

如果前幾篇還在看 agent safety、SOC workflow、OT benchmark 與 system prompt attack surface，那這篇 paper 剛好把另一個最近很熱、但也很容易被吹太大的方向拉回現實：LLM-based automated penetration testing 到底是真的在變成 hacker，還是大部分時候其實只是比較會講故事的 hallucination engine？

Hackers or Hallucinators? 的價值，不是再做一個新的 AutoPT framework，而是反過來把這一整波 AutoPT 熱潮做一次系統化拆解。作者一口氣整理了現有 framework 的設計空間，並在同一套 benchmark 上對 13 個開源 AutoPT framework 加 2 個 baseline 做大規模對照實驗，累積 超過 10 billion tokens、超過 1,500 份 execution logs，而且這些 log 還不是機器自動看一眼就算了，而是由 15 位以上具資安背景的研究者 花了四個月人工審閱分析。

所以這篇論文真正要回答的問題很簡單，但非常重要：

在自動化滲透測試裡，決定 agent 表現的關鍵到底是 multi-agent 架構、更多工具、更多知識庫，還是更紮實的記憶管理與執行設計？

這篇論文在補什麼洞：AutoPT 很熱，但真正可比較的分析其實很少

作者認為，近兩年 AutoPT 相關工作暴增，但大多數研究有三個共同問題：

• 只講自己的 framework，很少放到同一條標準線上跟別人比
• 設計細節切得不夠開，導致大家常把「模型強」和「框架設計好」混在一起
• benchmark 不一致，很難回答到底是 multi-agent 比 single-agent 強，還是只是剛好測題不同

因此這篇 paper 同時做兩件事：

• Systematization of Knowledge（SoK）：把 AutoPT framework 的設計拆成六個維度
• Large-scale empirical evaluation：在統一 benchmark 下真正做大規模比較與 ablation

這也是它比很多「我們又做了一個 autonomous pentest agent」論文更值得讀的地方：它不只是秀 demo，而是在問 這整個研究方向目前到底學到了什麼、哪些直覺其實是錯的。

作者怎麼拆解 AutoPT：六個核心維度

這篇論文把現有 AutoPT framework 的設計空間整理成六大維度：

• Agent architecture：single-agent 還是 multi-agent？角色怎麼分？如何協作？
• Agent plan：攻擊路徑是線性、樹狀還是圖狀？怎麼做 feedback 與 re-plan？
• Agent memory：如何處理長鏈任務中的歷史狀態、工具輸出與過往探索結果？
• Agent execution：誰負責調工具、怎麼選工具、怎麼處理 tool call feedback？
• External knowledge：怎麼引入 ATT&CK、CVE、exploit knowledge、RAG 知識庫？
• Benchmarks：到底在什麼環境評估？CTF、單機、網路、多主機、CVE exploitation 還是 phase-specific task？

這個拆法很有用，因為它讓我們可以不再只用「某某 agent 很強」這種模糊說法，而是開始分辨：

• 強的是 backbone model？
• 強的是記憶設計？
• 強的是外部知識補充？
• 還是其實只是 benchmark 比較友善？

架構面第一個重要結論：single-agent 沒有比較落後，很多時候反而更能打

這篇論文最值得被拿出來講的一個結論，就是它直接挑戰了近年很流行的信念：只要把 pentest agent 做成多代理、多角色、多模組，就一定比單一代理更強。

作者的實驗結果不是這樣。相反地，他們發現：

• 在大多數 Easy 與 Medium 任務上，single-agent architecture 並不輸 multi-agent
• 在某些情況下，single-agent 甚至還能超過更複雜的 multi-agent framework
• 只要 context 管理得宜，標準的 ReAct loop 在不少滲透任務裡其實就已經夠用

這個結論很重要，因為它意味著 AutoPT 研究最近常見的「越複雜越像完整團隊」並不必然帶來更高成功率。論文甚至點得很直接：multi-agent 的額外複雜度，常常只是把資訊切碎、把 handoff 做多，最後反而讓記憶與狀態維護變更差。

也就是說，AutoPT 不像很多 agent demo 那樣，角色一多就自然變強。滲透測試的核心痛點不是「缺幾個 agent role」，而是如何在長鏈探索中維持正確的 task state。

第二個核心結論：真正拖垮 AutoPT 的，往往是 memory，而不是模型不夠會攻擊

作者反覆強調，memory management 是影響 AutoPT 成敗的核心因素。這件事從 paper 的系統化分析一路貫穿到實驗觀察都成立。

為什麼？因為滲透測試不是單輪 QA，而是高度長鏈、依賴上下文的探索任務。Agent 必須一路記得：

• 目前目標有哪些 host、service、port
• 哪些 payload 試過了、哪些失敗過
• 前一步找到的 access level、credential、file path、web entry point
• 哪些工具輸出是真訊號，哪些只是雜訊

如果 memory 設計不好，agent 很容易出現幾種典型崩壞：

• 忘記前面已經驗證過的結論，開始重複掃描
• 因為冗長 tool output 讓上下文被污染
• 把失敗假設當成已確認事實，接著一路走錯
• 在多步 exploitation chain 中途斷線，無法把局部資訊串成完整攻擊路徑

所以這篇 paper 的一個很務實的提醒是：AutoPT 的記憶不是附加模組，而是核心戰鬥力。 你如果只關心 planner 長得帥不帥、agent team 分工漂不漂亮，卻沒有認真設計記憶壓縮、記憶組織與狀態持續性，那整個 framework 其實很容易只是更昂貴的亂試器。

作者怎麼看 memory：不是只有存 log，而是要解決壓縮、組織、檢索

在 SoK 部分，作者把 memory 問題拆得很細。他們區分了：

• knowledge memory：像漏洞定義、工具用法、攻擊技術等穩定知識
• experiential memory：agent 在當前任務裡實際踩到的路、看到的回應、做過的命令
• short-term memory：當前對話上下文中的即時資訊
• long-term memory：可以跨步驟、甚至跨任務持續保留的狀態與經驗

而現有 framework 嘗試的設計，大致落在三種：

• in-context memory：直接把歷史放進 prompt 裡
• external indexed memory：把重要資訊寫到外部筆記、vector store 或結構化索引
• structure-bound memory：把記憶綁在 attack tree / task graph / knowledge graph 節點上

這裡最值得注意的是，作者並不把「記憶越多越好」當答案。相反地，他們強調 memory compression 同樣重要，因為 tool output 很容易暴增，尤其在 shell、web、掃描器輸出堆疊時，若不做濃縮，agent 很快就被雜訊淹死。

第三個很反直覺的結論：external knowledge base 常常不但沒幫忙，還會害事

這篇論文另一個很值得圈起來的觀察，是它對 external knowledge / RAG / retrieval 的態度非常不迷信。

作者做了針對知識庫模組的 ablation，結果發現：

• 在 6 個帶有 knowledge base 的 framework 中，有 3 個在移除 knowledge base 後反而分數顯著提升
• 很多情況下，knowledge base 沒帶來正向增益，甚至會把 agent 帶去錯的探索方向
• 真正有效的知識補充，多半只出現在帶有明確公開 CVE 的場景

這個結論非常值得拿來對照近年一堆「RAG everything」的安全 agent 設計。作者指出，問題不在於外部知識本身沒價值，而是 retrieval mismatch 很致命：只要抓回來的知識與當前 target / service / version 不對齊，agent 就很容易被錯誤先驗知識誤導。

換句話說，在滲透測試裡，知識庫不是天然 buff。不準的知識，比沒有知識更危險。

第四個核心結論：工具越多，不代表滲透能力越強

很多 AutoPT framework 喜歡把自己的工具池堆得很滿，彷彿只要能調更多 scanner、exploit module、shell utility，整體能力就會往上長。但這篇 paper 的觀察很冷靜：

• tool pool 的規模，和實際任務成功率沒有穩定正相關
• 工具多，不等於 agent 會選、會排程、會在對的時機用對工具
• 如果工具受限，很多 framework 會自發啟動 Python execution compensation，試圖用通用程式能力補洞
• 但這種補償機制在困難任務上效果有限，不能把一般工具魔法般變成專業 exploit capability

作者甚至指出，一些 AI coding agents 靠著相對通用的工具與簡單 prompt，反而表現出很有競爭力的結果。這件事透露的訊號是：真正重要的不只是有沒有工具，而是 agent 是否有足夠好的 task relevance modeling，知道當前階段該動哪把刀。

第五個核心結論：不同 backbone LLM 的差異，真的會讓同一個 framework 變成不同東西

這篇 paper 也做了 backbone model 的比較，包含 DeepSeek-Chat、Claude、GPT、Gemini、DeepSeek-Reasoner 等不同模型家族。作者的結論不是單純誰分數最高，而是更重要的一件事：

在 general benchmark 表現好的模型，不一定是 AutoPT 任務裡最適合的模型。

同一套 framework，換不同 backbone 後，可能會出現截然不同的偏好：

• 有的模型較敢探索，但更容易 hallucinate
• 有的模型較保守，能維持狀態，但 exploitation aggressiveness 不夠
• 有的模型對工具規格比較敏感，有的則更依賴 prompt scaffolding

這代表 framework 不能再假設自己是 model-agnostic。真正成熟的 AutoPT 系統，必須根據 backbone 特性去調整 memory、tool calling 與 planning。

第六個核心結論：CVE exploitation 需要的是「動態且有針對性的知識庫」

雖然作者對一般外部知識很保留，但他們並沒有全面否定 knowledge base。相反地，paper 很清楚指出：在 public CVE exploitation 場景中，動態維護、與目標高度對齊的 targeted knowledge base 是有價值的。

論文提到，在 CVE exploitation 任務裡，約有 56.67% 的樣本雖然能正確把目標對上 CVE identifier，但卻無法把這份漏洞知識轉成可執行 payload。這說明現階段很多 agent 不是完全不知道漏洞，而是卡在「知道名稱」到「會穩定利用」之間的轉譯斷層。

所以作者的結論很實際：如果你的 AutoPT 真的要做 CVE exploitation，與其丟一大坨泛知識，不如維護針對特定目標、特定版本、特定 exploitation path 的動態知識庫。

這篇 paper 最誠實的一刀：hallucination 在 AutoPT 裡非常普遍，尤其是 flag hallucination

我覺得這篇論文最值得安全社群反覆咀嚼的一句話，就是它點名了 hallucination phenomena are widespread, especially flag hallucinations。

這句話很致命，因為 AutoPT 最危險的風險之一不是 agent 完全沒反應，而是它過早宣稱自己成功了。在 CTF、lab、甚至模擬 exploitation 場景裡，如果 agent 把不存在的 flag、假的 exploitation success、或未驗證的攻擊結論當成已完成結果，整個 pipeline 的後續評估就都會被污染。

這其實和前面幾篇談到的 agent governance、runtime guardrail、state verification 有很深的呼應：只要系統把 agent 的自述當成 ground truth，安全自動化就很容易變成自我欺騙。

實務上該怎麼讀這篇 paper？我會把它當成 AutoPT 的「去泡沫報告」

如果你現在在做 LLM pentest agent、red teaming automation、或安全研究型 agent framework，這篇 paper 帶來的訊息大概可以濃縮成幾句：

• 不要先迷信 multi-agent，先把單代理的 state management 做對
• 不要迷信工具數量，要重視工具選擇與時機
• 不要迷信 RAG，先問 retrieval quality 和目標對齊度夠不夠
• 不要把 backbone LLM 當可替換零件，模型特性真的會重塑 framework 行為
• 不要相信 agent 口頭說成功，要有可驗證的 state / artifact / exploit result check

對研究圈來說，這篇論文的重要性在於它讓大家開始從「做更多 framework」轉向「理解 framework 為什麼會贏、為什麼會輸」。對實務圈來說，它則提供了一種更冷靜的判準：如果一個 AutoPT 系統沒有清楚處理 memory、verification、knowledge alignment 與 hallucination control，那它很可能還不適合被當成真正的自主滲透測試工具。

總結

Hackers or Hallucinators? 不是在告訴我們 LLM-based pentest agent 沒前途；它真正做的是把這條路從 hype 拉回工程現實。這篇 paper 用很大的實驗成本證明了一件事：決定 AutoPT 表現的，往往不是你堆了多少 agent、多少工具、多少 retrieval，而是你能不能讓系統在長鏈任務中持續保有正確記憶、對齊正確知識、並且用可驗證方式約束 hallucination。

如果最近很多論文都在問「agent 能不能做更多」，那這篇論文更像是在問：

當 agent 開始真的碰滲透測試時，我們要先解決的，究竟是能力上限，還是認知可靠性？

而作者給出的答案其實很明確：在 AutoPT 這條線上，可靠性設計現在比想像中的花式自主性更關鍵。

---

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