Exploring AI's Frontier in DeFi: From Vulnerability Simulations to Secure Protocol Design
三句話摘要
Sherlock AI 以多代理流程自動化智能合約安全審計，覆蓋預審、漏洞搜索到修復驗證的完整周期。 將審計流程拆解為「圖分析 → 威脅建模 → PoC 驗證 → 人工反饋」的多代理閉環，是用 AI 壓縮誤報、讓人工審計員聚焦高價值漏洞的可行路徑。 圖表驅動的代碼理解：AI 首先將整個代碼庫轉為圖結構，明確哪些模組與哪些模組相互通信，讓後續的漏洞追蹤有清晰的攻擊面地圖。
重點整理
重點- 1
圖表驅動的代碼理解：AI 首先將整個代碼庫轉為圖結構，明確哪些模組與哪些模組相互通信，讓後續的漏洞追蹤有清晰的攻擊面地圖。
- 2
方面建模切割審計單元：代碼庫被拆分成邏輯區塊（如 Oracle、清算邏輯等），每塊獨立建立規範與威脅模型，避免全局掃描的噪音干擾。
- 3
兩層驗證壓制誤報：第一層對每個問題生成 PoC，第二層由獨立「判斷代理」分類所有問題，再結合人工標記有效／無效後回饋給 AI 重跑，形成閉環。
- 4
全周期嵌入而非一次性工具：AI 不只用在正式審計前，還被插入修復後驗證、二次審計前複查等節點，讓安全研究員時間集中在高價值漏洞。
實用技巧與重點
乾貨- Sherlock AI v2 發布時間：兩週前（2026 年 6 月初）
- 單次掃描問題量：約 500 個
- 嚴重性分層示例：2 高、2 中、2 低
- 五個核心代理：Graph Builder（圖表構建器）、Aspect Modeler（方面建模器）、Threat Modeler（威脅建模器）、Vulnerability Search（漏洞搜索）、Judgment Agent（判斷代理）
- 情報來源：歷史審計報告、協議文檔、同類代碼庫、業務邏輯說明
- 競爭驗證：Judgment Agent 已在 Sherlock 過去數年的所有比賽中使用
- 人工反饋機制：研究員在界面標記有效／無效 → AI 重新執行
- 對比參照：Xerox 52 等公司也在嘗試將自身框架應用於 AI 審計
結論
結論“將審計流程拆解為「圖分析 → 威脅建模 → PoC 驗證 → 人工反饋」的多代理閉環，是用 AI 壓縮誤報、讓人工審計員聚焦高價值漏洞的可行路徑。”
完整解析
詳細現代智能合約審計面臨的核心矛盾是規模與精度的衝突：代碼庫越來越大，人工逐行審查的成本難以承受，但盲目引入 AI 掃描又會產生大量誤報，反而消耗研究員時間。Sherlock 的方案是把人工審計員的工作流程拆解成可被 AI 代理模擬的標準步驟，讓人只在最需要判斷力的地方介入。
Sherlock AI 的流程從代碼庫理解開始。圖表構建器將整個代碼庫轉為節點關係圖，清楚標記哪個合約呼叫哪個函式、哪條路徑涉及資金流動。接著方面建模器將代碼庫切割成邏輯功能區塊，針對每塊撰寫規範文件；威脅建模器再結合歷史審計報告、協議文檔與同類漏洞案例，為每個區塊建立具體的攻擊情境。這個準備階段的目標是讓 AI「讀懂」代碼庫的意圖，而不只是靜態掃描語法。
漏洞搜索階段把威脅模型與圖分析結果交叉比對，驗證每個潛在攻擊路徑在實際代碼中是否真的可行。這一步通常會產生數百個候選問題。為了過濾誤報，流程分兩層：第一層讓 AI 為每個問題嘗試生成概念驗證（PoC），有 PoC 才算通過初篩；第二層由獨立的判斷代理對所有問題進行分類與嚴重性評分。最後，安全研究員在界面上看到整理後的結果，可直接標記有效或無效，這份反饋會被送回 AI 觸發下一輪掃描，形成人機協作的閉環。
在實際使用場景上，Sherlock 的團隊並不把 AI 限縮在審計開始前的一次性跑批。他們的標準流程是：正式審計前先跑一遍找出低垂果實，讓人工研究員騰出精力追蹤更複雜的邏輯漏洞；開發方修復後再跑一遍驗證修復有效性；若有二次審計，修復後再跑一遍作為起點。這樣的嵌入方式讓 AI 成為整個安全周期的基礎設施，而非替代品。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
