Knowdit 論文閱讀分析：很多 DeFi 漏洞真正難抓的，不是 pattern 太少，而是經濟語意根本沒被寫成可驗證規格

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

論文基本資訊

• 論文標題：Knowdit: Agentic Smart Contract Vulnerability Detection with Auditing Knowledge Summarization
• 作者：Ziqiao Kong、Wanxu Xia、Chong Wang、Yi Lu、Pan Li、Shaohua Li、Zong Cao、Yang Liu
• 年份：2026
• 來源：arXiv:2603.26270
• 論文連結：https://arxiv.org/abs/2603.26270
• DOI：10.48550/arXiv.2603.26270
• 主題：Smart Contract Security、DeFi Security、Agentic AppSec、Knowledge Graph、Fuzzing、Specification Synthesis

這篇論文最值得看的，不是它又做了一個會掃 Solidity 的 agent，而是它把 smart contract audit 裡最常卡住、也最難自動化的那層講得很準：很多合約漏洞真正難抓的，不是 pattern 不夠熟，而是你根本沒先抓到這個專案在經濟語意上到底想怎麼運作。

DeFi 世界的弱點，常常不是單純的 reentrancy 關鍵字或某個 access control if statement 漏掉而已。很多真正高價值的洞，會黏在：

• 資產流如何在多個角色之間轉移；
• 清算、抵押、鑄造、贖回這些 business logic 如何互相制約；
• 不同合約模組之間對狀態前提的隱含假設；
• 「理論上應該成立」但實際上沒被寫成可驗證規格的經濟約束。

Knowdit 的核心價值，就是把這件事重新表述成：先從歷史 audit reports 萃出可重用的 DeFi semantics，再讓 agent 沿著 specification generation、harness synthesis、fuzz execution 與 finding reflection 這條線，把「商業邏輯理解」接回「可驗證 finding」。

這篇在解什麼問題？

作者要處理的，不是一般意義上的 smart contract vulnerability detection，而是更難、也更接近真實稽核流程的問題：

當漏洞和專案特定 business logic 綁得很深時，系統能不能不只靠通用漏洞 pattern，而是真的把歷史審計知識轉成新專案可用的檢查思路？

這個 framing 很重要。因為在 smart contract 場景裡，很多工具失敗不是因為它完全不會找洞，而是它只能抓：

• 語法層、模板層或局部 control-flow 層的弱點；
• 高度重複、已知、容易 pattern match 的 bug 類型；
• 不太需要理解 DeFi protocol semantics 的問題。

但只要你碰到比較像真實審計的題目，問題就會變成：這個 vault、pool、reward、liquidation、staking 或 governance 流程，到底在哪裡違反了它自己聲稱要守的經濟規則？ 單靠一般 SAST 或泛用 LLM，常常會在這裡失速。

Knowdit 的核心想法：先把人類 audit 經驗壓成可重用知識，再交給 agent 工作流反覆驗

這篇最有意思的地方，是它沒有把多代理架構神話成「多幾個 agent 就比較聰明」，而是先處理一件更根本的事：把歷史人類 audit reports 裡那些分散的洞見，整理成能被新專案重用的 auditing knowledge。

作者的觀察是，不同 DeFi 業務模型之間雖然表面流程不同，但很多 recurring vulnerabilities 共享相近的 underlying economic mechanisms，也就是文中說的 DeFi semantics。Knowdit 先把這些語意與漏洞模式連進 auditing knowledge graph，接著再讓 agent 用這張圖去驅動後續檢查。

這個方向我很買單，因為它把 smart contract audit 從「看 code 長得像不像洞」拉回「這套金融邏輯是不是在某個邊界條件下會失守」。對 DeFi 而言，後者才往往是高嚴重度問題真正出現的地方。

整條流程怎麼跑？

從摘要來看，Knowdit 的工作流大致可以拆成四個主步驟，而且是用 iterative loop 串起來：

1. Specification generation：先根據新專案與既有知識，推導應該成立的檢查規格；
2. Harness synthesis：把這些規格轉成能實際驅動測試或驗證的 harness；
3. Fuzz execution：讓系統在動態執行中找出可觸發問題的輸入與狀態組合；
4. Finding reflection：回頭檢討當前發現是否可信、是否需要修正規格或補充探索方向。

更關鍵的是，這整個循環不是各做各的，而是透過 shared working memory 持續更新。也就是說，Knowdit 的重點不是單輪生成，而是把 audit 變成一條會逐步收斂的 knowledge-guided search loop。

這種設計的實務意義在於：合約審計真正難的，往往不是跑一次 fuzzing，而是知道下一輪該往哪條語意邊界繼續挖。 如果沒有 working memory 與 reflection，很多 agent 系統其實只是在重複製造花俏但不累積上下文的嘗試。

這篇真正補到的是 business-logic-aware AppSec 缺口

我覺得 Knowdit 最值得記住的，不是它用了 KG，也不是它用了 multi-agent，而是它瞄準了一個很痛的缺口：business logic vulnerability 不能只靠 code pattern 找。

對傳統 AppSec 而言，很多工具擅長找：

• dangerous API misuse；
• 典型輸入驗證缺陷；
• 已知危險 sink / source 組合；
• 常見 CWE 模式。

但在 DeFi 裡，很多高風險問題比較像是：

• 資金守恆假設在哪裡被打破；
• 角色權限與清算條件在哪裡被繞過；
• 不同 module 對同一個 state transition 的理解是否一致；
• 看似合法的交易序列是否能把 protocol 推到設計者沒預期的經濟狀態。

Knowdit 等於是在說：要把這些洞自動化抓出來，先決條件不是再堆更大的模型，而是先把歷史審計知識整理成能喚起對應經濟語意的中介層。

關鍵結果：不是小幅提升，而是把「高嚴重度不能漏」這件事拉到很有存在感

論文摘要裡最值得記住的數字有幾個：

• 在 12 個近期 Code4rena projects 上評估；
• 總共有 75 個 ground-truth vulnerabilities；
• Knowdit 抓到 全部 14 個 high-severity vulnerabilities；
• medium-severity 漏洞抓到 77%；
• 整體只有 2 個 false positives。

這幾個數字放在 smart contract audit 場景很有份量。因為對很多審計流程來說，真正最不能接受的不是少幾個低風險 warning，而是高嚴重度漏洞沒抓到，或誤報多到足以拖垮人工 triage。

Knowdit 在這裡給出的訊號很明確：它不只是 recall 有進步，而是把 high-severity coverage、medium-severity coverage 與 false-positive discipline 一起拉到比較能交付的區間。

更有意思的是 real-world 驗證：不只 benchmark 漂亮，還挖出未知漏洞

如果只有 benchmark 成績，這篇還可以被看成「針對 Code4rena 題型調得很會」。但作者還做了第二層驗證：把 Knowdit 套到 6 個 real-world projects，結果又找到：

• 12 個先前未知的 high-severity vulnerabilities；
• 10 個先前未知的 medium-severity vulnerabilities。

這比單純 benchmark 分數更值得注意。因為它代表這條 knowledge-driven workflow 至少不是只會背公開題庫，而是有能力把歷史 audit semantics 轉移到新專案上，做出真正可行的 finding discovery。

當然，這種結果最終還是要看 disclosure、驗證與修補狀態，但至少它釋放出的訊號很強：若把 audit 知識圖、規格生成、動態執行與反思迴圈接好，agentic AppSec 確實可能開始碰到「能幫人類審計師打開新洞口」的門檻。

我的看法

我覺得 Knowdit 的可取之處，在於它沒有把 smart contract 安全自動化講成一個純模型能力問題，而是很老實地把它拆回：

• 知識怎麼整理；
• 規格怎麼形成；
• 測試怎麼落地；
• finding 怎麼被反覆驗證與收斂。

這個 framing 比「再來一個會看 Solidity 的 agent」有價值得多。因為 DeFi audit 真正稀缺的，常常不是語法理解，而是把過去人類審計的 tacit knowledge 變成下一個專案可操作的驗證起點。

如果要挑可能的限制，我會先看幾件事：

• auditing knowledge graph 的品質與覆蓋率多依賴歷史 reports；
• 不同 DeFi protocol family 之間，DeFi semantics 的可轉移性是否會在陌生設計上下降；
• harness synthesis 與 fuzz execution 的效果，仍會受測試環境建模品質影響；
• unknown vulnerabilities 的確認成本，最後還是需要嚴格驗證與 disclosure 流程接住。

但即便如此，這篇還是給了一個很清楚的方向：agentic smart contract security 真正該補的，不只是更多 agents，而是把 audit 經驗濃縮成能驅動規格、測試與反思的可重用知識層。

重點整理

• Knowdit 處理的是 smart contract business-logic vulnerability detection，而不只是一般語法層或 pattern-level 弱點掃描。
• 核心洞見是：不同 DeFi 專案雖然商業模型不同，但 recurring vulnerabilities 常共享底層經濟機制，也就是文中的 DeFi semantics。
• 系統先從 歷史 human audit reports 建立 auditing knowledge graph，把細粒度 DeFi semantics 與 recurring vulnerability patterns 連起來。
• 給定新專案後，Knowdit 透過 specification generation、harness synthesis、fuzz execution、finding reflection 的迭代循環持續收斂。
• 整條工作流由 shared working memory 驅動，重點不是單輪生成，而是累積式 refinement。
• 在 12 個近期 Code4rena projects、75 個 ground-truth vulnerabilities 上，Knowdit 抓到 全部 14 個 high-severity 漏洞，並抓到 77% 的 medium-severity 漏洞。
• 整體只有 2 個 false positives，顯示它不是靠灌水式 candidate volume 撐 recall。
• 在 6 個 real-world projects 上，作者進一步找到 12 個先前未知的 high-severity 與 10 個先前未知的 medium-severity 漏洞。
• 這篇最重要的訊號是：DeFi 安全自動化真正缺的，往往不是模型再大一點，而是先把 audit knowledge 變成能驅動規格與驗證的中介層。

Takeaway

這篇論文真正提醒我們的，是smart contract audit 最難自動化的部分，往往不是 code 長得多怪，而是協議背後那套經濟邏輯本來就沒被很好地寫成可驗證規格。

Knowdit 給出的答案不是單純再堆一個更會讀 code 的 LLM，而是把 歷史審計知識、DeFi semantics、規格生成、harness 建立、fuzz execution 與反思迴圈 接成一條真正能跑出 finding 的流水線。

對做 smart contract security、agentic AppSec、fuzzing、audit automation 或 knowledge-driven vulnerability discovery 的人來說，這篇值得看。因為它抓到了一個很核心的事實：很多高價值漏洞不是藏在語法裡，而是藏在系統自以為成立、卻從來沒被硬寫進驗證流程的經濟假設裡。