google/mantis：把安全審查拆成可替換的 agent 技能鏈

它解決的是流程問題，不是偵測率問題

多數 SAST 工具的輸出是一份清單，清單之後的工作（這條是不是真的、能不能重現、補丁長什麼樣）全靠人接。Mantis 把這段接手工作也交出去：README 說它是一組解耦、依序執行、以安全為焦點的技能，設計上搭配 coding agent 使用，並強調自己是「a starting point rather than a rigid set of instructions」。目標讀者不是想找現成掃描器的 AppSec 工程師，而是已經在用 Gemini CLI 或 Antigravity CLI 這類工具、想把安全審查步驟寫進 agent 工作流的團隊。技能本身以 slash command 形式存在，README 舉例的進入點是 /mantis-plan，後續還有 /mantis-reproduce、/mantis-patch、/mantis-review。這代表它的產出品質取決於兩件事：agent 對技能指令的遵循程度，以及你在 /mantis-review 裡放進去的負向規則。Mantis 沒有提供規則庫，規則要自己寫。

順序本身就是設計：從規劃到覆核的階段契約

Mantis 把整個審查拆成有先後關係的階段，README 明確說這是「decoupled, sequential」，並把階段細節、流程與階段之間的契約（inter-stage contracts）指向 README_AGENTS.md。從主 README 能確認的階段至少有四個：/mantis-plan 負責規劃，/mantis-reproduce 在隔離容器中執行程式碼以驗證問題，/mantis-patch 產生修補，/mantis-review 套用負向規則過濾誤報。這個順序有一個實際後果：重現失敗的項目在流程裡會走到哪裡、會不會被當成誤報丟掉，取決於你怎麼設定 review 階段。README 自己點出這個陷阱，說「A failure to automatically reproduce a vulnerability does not definitively mean it is a false positive」，反過來說，重現成功也不保證在所有情境下都可利用。對硬體、RTL、IaC、ML pipeline 或編譯後韌體這些領域，README 說技能可以改編，但改編的內容得自己寫，repo 只提供方向。

安裝與執行：從 npx 到逐條 slash command

安裝指令在 README 裡很單純，一行：npx skills add google/mantis。文件說技能可以裝在全域（跨專案可用）或只裝進特定工作區，也可以直接叫 coding agent 幫忙裝。裝完之後的執行方式決定了風險輪廓。README 建議新手從互動模式開始：在平常的開發流程裡啟動 coding agent，然後一條一條手動輸入 slash command，例如 /mantis-plan，而不要用 --yolo 或 --dangerously-skip-permissions，也不要開啟任何形式的自動核准。理由寫得很直接：/mantis-reproduce 與 /mantis-patch 這兩個技能會寫檔、會執行程式碼，人應該在動作發生前看到 AI 打算跑什麼。要拿掉人工核准，前提是你已經先架好夠強的邊界把 agent 關住，而不是反過來。這一段是整份文件裡最具體的操作建議，也是採用與否的分水嶺。

沙箱不是建議，是前提：gVisor 與 network=none

README 開頭兩段警告的密度比功能說明高。第一段用 CAUTION 標示，要求只在隔離、受限的環境中使用，並且明講不要在有生產系統、敏感資料或內網存取權的機器上跑。第二段是責任使用聲明：模型非確定性，會產生幻覺發現或不正確的補丁，所有發現都必須由安全專家人工驗證後才能回報，也不要批次把未驗證的 AI 報告送給開源維護者。技術上，文件建議用 gVisor（runsc）來執行不可信的 AI 生成重現程式碼，並給出具體做法：用 sudo runsc install -- --network=none && sudo systemctl restart docker 註冊 runtime，或寫進 /etc/docker/daemon.json，把 runtimes.runsc.runtimeArgs 設為 ["--network=none"]。技能本身被指示要在停用網路的隔離容器裡執行 payload，但 README 同時承認 agent 非確定性，「may occasionally attempt unsafe actions or bypass intended constraints if the local environment allows it」。這句話是整份文件最誠實的地方：隔離必須由環境強制，不能只靠提示詞。

誤報處理與模型分級：兩個容易被略過的設定面

README 把誤報處理寫成一條規則，叫負向過濾（negative filter），由 /mantis-review 階段套用負向規則來過濾。文件給了兩條操作建議：一是按自己的程式庫客製這些負向驗證規則，二是不要第一天就跑全 repo，先從窄範圍掃描開始調校流程。這兩條其實是同一件事的兩面，因為負向規則的品質只能在真實誤報上調。另一條是模型分級：文件建議把不同等級的模型配到不同階段，不需要每一階段都用最重的前沿模型，細節在 README_AGENTS.md 的模型選擇與效率指引。這個建議合理，但 README 沒有給出各階段的具體模型清單或成本數字，所以實際配法仍要自己試。把這兩點放在一起看，Mantis 的調校成本主要落在 review 階段的規則撰寫與模型配置上，而不是安裝。

什麼情況下 Mantis 是錯的工具

最明顯的錯配是把 Mantis 當成 CI 裡的自動掃描閘門。它的輸出需要人工驗證，README 反覆強調這點，而 /mantis-reproduce 與 /mantis-patch 會執行程式碼與寫入檔案，這在共用 CI runner 上不是可以隨手放行的行為。第二種錯配是團隊沒有安全審查人力：如果沒有人能判斷 AI 生成的發現是真是假，整條流程只會產出一批需要再過濾的雜訊，而 README 明確禁止把未驗證報告批次送給開源維護者。第三種是環境限制嚴格的組織，例如無法在開發機上跑 Docker、也拿不到隔離 VM 的團隊，這種情況下 Mantis 的執行階段技能根本無法安全落地。還有一種情況是期待開箱即用的規則庫：Mantis 不附規則，負向過濾要自己寫，這對想直接跑一次就看到結果的人是落空。

與傳統 SAST 的差異在哪裡

拿 Semgrep 這類規則式 SAST 來對照最清楚。Semgrep 的機制是用你寫的 pattern 對原始碼做比對，輸出位置固定的規則命中，行為可重現、可進 CI、結果穩定。Mantis 走的是相反方向：它不提供比對引擎，而是把「規劃、重現、修補、覆核」四個動作寫成 agent 技能，讓模型在每一步做判斷，代價是輸出非確定性，好處是能處理規則難以描述的問題，例如需要實際執行程式碼才能確認的重現路徑。兩者不是取代關係。實務上合理的組合是先用規則式掃描取得穩定的基線，再用 Mantis 處理需要推理與重現的個案，並把 Mantis 的產出當成待驗證線索而非結論。README 對自家定位的說法也支持這種用法：它是起點，不是固定指令集。

維護成本與授權：採用前要算的帳

授權是 Apache-2.0，寬鬆授權，允許修改與再散布，具體義務與專利條款請看 repo 內的 LICENSE 全文，這裡不提供法律意見。維護成本要分兩塊看。第一塊是技能本身：Mantis 鼓勵用 AI 迭代技能、用內部文件與建置系統擴充威脅模型、按環境調整風險校準，這意味著技能會偏離上游，之後要合併上游更新就得處理分歧。第二塊是執行環境：gVisor 的 runsc runtime 註冊、daemon.json 的 runtimes 設定、以及每個技能的容器網路設定，都是需要持續維護的基礎設施，不是裝完就放著。另外，本次取得的資料顯示 recent releases 為空，也沒有可引用的版本號，因此無法從版本節奏推估更新頻率，升級前應直接檢視 repo 的提交紀錄與 README_AGENTS.md 的變動。

編輯結論

Mantis 適合已經有沙箱或專用隔離 VM、而且願意派人逐筆覆核 AI 產出報告的安全團隊；不適合想把它當成 CI 掃描器直接掛上生產程式庫、或沒有能力審查 AI 生成程式碼的團隊。採用前先確認三件事：你的 agent 框架是否支援 slash command 形式的技能載入、Docker 是否已註冊 runsc 並加上 --network=none、以及 /mantis-review 的負向過濾規則是否已按你的程式庫調整過。這三項沒有一項能從 repo 直接推得，必須在自己的環境裡驗證。

官方來源

1. google/mantis on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README