Fuzzing Taskflow 串起 AI 代理與 AFL++：先算整合成本，再談補上缺口

2026年9月30日，APPI News 刊出一篇針對 GitHub Security Lab 開源專案 Fuzzing Taskflow 的長文分析。這則消息的重點不在多了一個新工具，而在它嘗試把模糊測試流程中人工佔比最高、也最難計價的那幾個步驟接起來。

先看這條流程做了什麼。Fuzzing Taskflow 從指定一個 GitHub 儲存庫開始，代理辨識 C/C++ 專案中適合測試的函式與入口，分析建置系統，產生 harness（把輸入轉成目標函式可接收參數的測試介面程式），建立 AFL++ 執行檔並跑測試，再將找到的輸入重播到覆蓋率分析版本，產生可讀報告。代理依未觸及分支調整下一輪：加種子、改 harness、補格式字典，或判斷某些路徑不值得追。

成本結構：自動化的是重工，不是判斷

GitHub Security Lab 文章作者 Antonio Morales 將模糊測試描述為仍需要人員參與的工作，人員得持續看覆蓋率、補 harness、分流 crash。對照傳統流程，人力主要耗在四件事：找測試入口、寫 harness、讀覆蓋率報告、整理 crash。Taskflow 自動化的是前段的反覆操作與初步整理，crash 處理則包含縮小觸發輸入、在 AddressSanitizer 下重播、依堆疊合併相似結果，最後由代理撰寫標示可能漏洞的報告。

值得注意的界線：覆蓋率指出的是「測試走到哪裡」，不是安全評分。未觸及分支可能是低價值的錯誤處理路徑，已觸及程式也未必以足夠多樣的輸入測過。來源明確提醒，不能單憑工具名稱推論漏洞檢出能力。

這種「工具降低執行成本、驗收成本反而上升」的結構，與先前分析的美團 Agent 評測白皮書所攤開的隱形支出屬於同一類帳：代理產出越多，人工核可每一份報告的負擔越重。

適用條件與兩個風險點

其一，回饋迴圈的品質取決於代理對原始碼、建置設定與資料格式的理解。入口判錯、harness 漏掉狀態設定、種子不符合實際格式，之後的覆蓋率回饋會繞著錯誤的測試設計打轉，投入的運算時間形同沉沒成本。專案保留跨輪語料以避免每次從原始種子重新探索，是針對這點的部分緩解。

其二，來源明確指出：命令直接在 host 上執行，狀態記錄於資料庫供階段銜接，MCP 工具介面本身不提供主機隔離。介面分層與執行隔離是兩回事。讓代理在具編譯與執行權限的主機上反覆跑測試，這筆風險沒有被工具 absorb，而是轉嫁給部署端。高權限設計的成本外部化，在Muse 助理的權限風險帳已見過同款結構。

收束判斷

對已有 AFL++ 使用經驗、且程式介面文件完整的 C/C++ 團隊，Taskflow 壓縮的是 harness 撰寫與覆蓋率檢視的重工時間；對測試基礎建置尚不完整的團隊，先做小型儲存庫試跑、並為執行環境配置隔離，是比導入工具本身更優先的支出。至於漏洞檢出能力的實際數字，來源未提供基準數據，這一欄目前仍應保留空白，而非以覆蓋率上升替代。