Decepticon 評測：把紅隊交戰流程寫進 Agent 的自主攻擊框架
Autonomous Hacking Agent for Red Team
秒懂
- 它是什麼？
- Decepticon 是 PurpleAILAB 以 Apache-2.0 釋出的自主紅隊 Agent，用 Docker 堆疊跑 LangGraph 編排，並以交戰文件（RoE、ConOps、OPPLAN）約束每個動作。本文聚焦它的實際機制、安裝路徑、以及那個把多數團隊擋在門外的架構前提。
- 適合誰用？
- Decepticon 適合已經有正式紅隊流程、能自行維運 Docker 堆疊、且需要把交戰文件與 MITRE ATT&CK 對應納入自動化的團隊；不適合只想找一個掃描器替代品、或沒有授權範圍文件可依據的使用者。導入前先確認三件事：你能否提供 DECEPTICON_LLM__PROXY_URL 與 SANDBOX_URL 指向的執行環境、你的授權測試範圍是否允許 Agent 自主串接 exploit 與 C2、以及你是否接受 Neo4j 與 PostgreSQL 這兩個常駐服務的維運成本。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 16 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的不是掃描覆蓋率，是交戰紀律
市面上多數打著 AI 駭客名號的專案，README 自己就先把這件事說白了：跑 nmap、印報告。Decepticon 的定位寫在專案描述裡，Autonomous Hacking Agent for Red Team，關鍵字是 Red Team 而不是 pentest tool。差別在於紅隊的工作不是列出弱點清單，而是沿著一條攻擊鏈推進：偵察、利用、提權、橫向移動、C2。README 明確講它執行的是 realistic attack chains，而不是 scanner 的路徑。
更值得注意的其實是它對紀律的處理。文件寫著，在第一個封包送出之前，Decepticon 會產出完整的交戰套件，包含 RoE（Rules of Engagement）、ConOps、Deconfliction Plan，以及帶有 MITRE ATT&CK 對應的 OPPLAN，之後每個動作都在這些規則內執行。這個設計選擇把工具從「自動化 exploit 執行器」推向「照著交戰計畫行動的執行者」。對已經有紅隊流程的組織，這是它最實際的賣點；對沒有這套文件的團隊，這反而是一道要先跨過的門檻。
目標使用者因此相當明確：內部紅隊、需要反覆演練特定攻擊鏈的防禦驗證團隊，以及想把 agent 當底層元件、自己往上疊產品或研究整合的開發者。後者對應的是 PyPI 上的 SDK 路徑。
資料流：LiteLLM 管模型、Sandbox 管執行、LangGraph 管編排
從安裝說明可以看出它的服務切分。預設啟動會拉起所謂的 core management plane，成員包括 LiteLLM、PostgreSQL、Neo4j、Skillogy、LangGraph 與 sandbox，同時進入終端 CLI。這幾個元件的分工在文件裡沒有逐項展開，但從命名與 SDK 說明可以推回去：LiteLLM 是模型呼叫的代理層，Neo4j 承載知識圖譜，對應 pip 安裝時那個 decepticon[neo4j] 選項所描述的 knowledge-graph attack-chain tools。
真正定義架構的是 SDK 那一段。README 說 decepticon 是 client SDK，出貨內容包含 agent factories、middleware、tools 與 skills，而 LLM 呼叫與 sandbox 執行是透過 HTTP 路由到 runtime services，對應的環境變數是 DECEPTICON_LLM__PROXY_URL 與 SANDBOX_URL。這句話的份量比它看起來重：agent 的推理與實際的指令執行被拆到兩個不同的信任邊界上。你在本機跑的是編排邏輯，真正碰目標的指令在 sandbox 服務裡跑。
另一個機制細節是 workload 的按需啟動。預設只拉起核心管理平面，特殊工作負載如 BloodHound CE、Sliver C2、Ghidra MCP 是隨需啟動，由 orchestrator 透過 ops_start("ad") 這類呼叫生成 specialist。這解釋了為什麼它能宣稱跑 interactive shells：README 指出真實攻擊工具是互動式的，例如 msfconsole、sliver-client、evil-winrm，而它把每個指令放在對應的互動環境裡執行。這段在提供的材料中被截斷，完整的 shell 處理方式需要看 docs/engagement-workflow.md。
安裝：一行 curl，但前提是 Docker 與 Compose v2
前置條件寫得很直接：Docker 與 Docker Compose v2，支援 macOS（Apple Silicon 與 Intel）、Linux（amd64 與 arm64）、Windows（amd64 與 arm64，原生 PowerShell 或 WSL2 的 Ubuntu / Kali）。
macOS、Linux 與 WSL2 的路徑是三行：
curl -fsSL https://decepticon.red/install | bash decepticon onboard decepticon
decepticon onboard 是互動式設定精靈，負責 provider、API key 與 model profile。第二個指令啟動核心堆疊並進入終端 CLI。Windows 原生 PowerShell 走另一條：
irm https://decepticon.red/install.ps1 | iex decepticon onboard decepticon
Web dashboard 不在預設啟動範圍內，要在 CLI 裡用 /web 拉起來。特殊工作負載同理，需要時才由 orchestrator 生成。這個設計對資源有限的工作站是好事，代價是你得知道什麼時候該下哪個指令。
想當函式庫用的人走 PyPI：pip install decepticon 是核心 SDK，pip install "decepticon[neo4j]" 加上知識圖譜的攻擊鏈工具。這裡有個容易踩的誤解：裝了 SDK 不等於能跑 agent。README 講得很清楚，SDK 是 client，執行仍然需要那些 runtime services，你得自己用上面的 Docker 堆疊，或把 DECEPTICON_LLM__PROXY_URL 與 SANDBOX_URL 指向你自己的等效服務。文件另外提到 factory override 介面、宣告式的 PluginBundle 外掛，以及一道 safety gate，細節在 docs/library-usage.md。
雲端託管版本與自我託管的取捨
README 在安裝之前先放了一個託管版本的呼籲，app.decepticon.red，主打跳過 Docker 設定、直接在瀏覽器裡跑自主紅隊交戰。對評估階段的人這是合理的入口：你可以在投入堆疊維運之前先確認 agent 的行為模式符不符合需求。
但託管版本有一個必須自己判斷的問題，而且文件沒有回答：你的目標環境資訊會經過誰的基礎設施。紅隊交戰本質上會產生大量敏感的內網拓撲、憑證痕跡與弱點細節。對外部顧問業或受監管產業，這個問題通常直接決定能不能用。自我託管路徑把資料留在自己的 LiteLLM 與 sandbox 裡，代價是你要維運 PostgreSQL、Neo4j 與 LiteLLM 三個常駐服務。
這裡沒有中間選項。要嘛接受託管的資料流向，要嘛接受堆疊的維運負擔。評估時把這一項單獨列出來，比事後補救便宜。
基準數字的邊界：XBOW 是別人出的題
README 給出的成績是 XBOW validation-benchmarks 全級別 102/104，通過率 98.08%。分級數字是 Easy 45/45、Medium 50/51、Hard 7/8。專案另外提供 per-challenge 索引、attack-class 矩陣與 LangSmith traces，以及一份與 Strix、PentestGPT、MAPTA、Cyber-AutoAgent、XBOW 商業版等工具的比較文件。
這些數字要怎麼讀，取決於你怎麼看 XBOW validation-benchmarks 這個題庫。它是公開的驗證題集，題目有明確的通過條件，這讓結果可比較；但它的題型分佈與真實企業內網的差異，README 沒有討論。98.08% 代表的是在一個受控題庫上的表現，不是在你家 AD 環境上的表現。Hard 級別只有 8 題，7/8 與 8/8 之間只差一題，這個樣本量撐不起「硬難度場景也穩」這種結論。
我沒有跑過這些 benchmark，也不打算替這些數字背書。可以確定的是專案願意公開 per-challenge 層級的結果與 trace，這比只丟一個總通過率誠實得多。要驗證的人應該去看那份索引，確認題目類型與你自己的環境是否有重疊。
什麼情況下它會是錯的工具
第一個限制來自架構本身。SDK 是 client，agent 執行需要外部 runtime services。這意味著你沒辦法把 Decepticon 塞進一個單一 Python 程序裡當函式庫呼叫，也沒辦法在沒有容器執行環境的機器上跑。如果你的場景是 CI pipeline 裡對 staging 環境做一次輕量檢查，這個重量級堆疊是過度的。
第二個限制是授權與範圍。它的設計前提是你有一份 RoE 可以依據，agent 會照著 OPPLAN 自主選擇路徑，包含 pivoting 與 chaining techniques。自主串接 exploit 與 C2 這件事，在多數司法管轄區與多數企業的資安政策下，需要明確的書面授權。沒有這份授權，這不是「用了有風險」的問題，而是不該用。
第三個是互動式 shell 的處理。README 的相關段落被截斷，只看到它強調真實工具是互動式的、它把每個指令放在互動環境裡跑。互動式 session 的自動化在技術上比批次執行難得多，涉及提示字元偵測、輸出解析與狀態維持。這部分是否可靠，提供的材料不足以判斷，需要直接看 docs/engagement-workflow.md。
替代方案的差異在取向上。PentestGPT 走的是輔助路線，把 LLM 當成引導測試人員推進流程的顧問，實際操作仍由人執行，授權邊界清楚，也不需要常駐服務。Decepticon 走的是執行路線，agent 自己動手，因此需要 sandbox、需要交戰文件、需要完整的堆疊。前者適合個別測試人員提升效率，後者適合已經有流程與授權框架的團隊做規模化演練。兩者不是同一個市場的東西，選錯方向的成本比選錯工具高。
授權、版本節奏與維運成本
授權是 Apache-2.0，寬鬆條款，允許商業使用與修改，附帶專利授權與商標條款。這裡不提供法律意見，但實務上要注意兩件事：Apache-2.0 不包含任何保證，而紅隊工具的使用責任完全在使用者身上，授權條款不會替你承擔未授權測試的後果。另外 README 有贊助連結與 Offensive Vaccine 的表述，這是專案的發展方向陳述，不影響授權範圍。
版本節奏從 release 記錄看相當密集：v1.1.38 在 2026-07-12，v1.1.39 與 v1.1.40 都在 2026-07-27，同一天出了兩個版本。最後一次 push 是 2026-08-30，專案未封存。這種節奏對早期採用者是雙面的：修補來得快，但介面與設定也可能跟著變。SDK 的 factory override 與 PluginBundle 這類擴充點，在快速迭代期是最容易出現破壞性變更的地方。
維運成本主要落在三個常駐服務上：PostgreSQL、Neo4j 與 LiteLLM。Neo4j 是其中比較重的一個，如果你的用法不需要知識圖譜的攻擊鏈工具，就不要裝 decepticon[neo4j] 這個 extra，核心 SDK 不含它。LiteLLM 則決定了你的模型成本曲線，自主 agent 的呼叫次數與一般聊天應用不在同一個量級。
升級前值得先確認的是設定相容性。onboard 產生的 model profile 與 provider 設定，以及 DECEPTICON_LLM__PROXY_URL、SANDBOX_URL 這兩個端點，是升級時最可能出問題的地方。在密集發版的專案上，先讀 release notes 再拉新版，比事後回退省事。
編輯結論
Decepticon 適合已經有正式紅隊流程、能自行維運 Docker 堆疊、且需要把交戰文件與 MITRE ATT&CK 對應納入自動化的團隊；不適合只想找一個掃描器替代品、或沒有授權範圍文件可依據的使用者。導入前先確認三件事：你能否提供 DECEPTICON_LLM__PROXY_URL 與 SANDBOX_URL 指向的執行環境、你的授權測試範圍是否允許 Agent 自主串接 exploit 與 C2、以及你是否接受 Neo4j 與 PostgreSQL 這兩個常駐服務的維運成本。若這三項有一項答不出來，這個專案現階段就不是你的工具。
社群筆記