Agentic SOC Platform：把告警洪流收斂成案件，再用 Agent 接手調查
Agentic SOC Platform: A powerful, flexible, open-source, and agent-centric automated security operations platform (AI SOC)
秒懂
- 它是什麼？
- FunnyWolf 的 agentic-soc-platform 是一套以 Agent 為核心的開源安全營運平台，主打把 SIEM 與 Webhook 告警收斂成 Case，再讓 LLM 與 Playbook 接手調查與情資濃化。判斷重點在於：它把 AI 分析與傳統 SOAR 流程放進同一套 Playbook 系統，但導入成本取決於你願不願意寫 Python Module 與維護本地 LLM 依賴。
- 適合誰用？
- 如果你的團隊已經有 Splunk 或 ELK，痛點是告警量太大、分析師不夠，而且內部願意寫 Python Module 去接自家 SIEM 規則，這套平台值得排進試用清單。若你期待裝完就能自動處置、或組織內沒有能維護 LLM 與 Playbook 的人，先不要導入。
- 可以商用嗎？
- 未經許可不行。GitHub 在這個儲存庫中沒有找到授權檔案；沒有授權，預設即「保留所有權利」：你可以閱讀程式碼，但不能重複使用。使用前請看看 README，或先取得作者同意。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 41 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是告警量與人力之間的落差
SOC 的日常不是找不到告警，而是告警太多。README 開頭把問題講得很直接：讓安全團隊從 alert fatigue 走向 AI-assisted decision-making。這句話決定了它的目標使用者，是有 SIEM、有告警來源、但人力不足以逐條追查的藍隊。
它的做法不是取代 SIEM，而是在 SIEM 之上加一層收斂與調查。README 描述模組會串流 SIEM 與 Webhook 告警、抽取 IOC、關聯相關訊號，然後產生 Case、Alert 與 Artifact 三種物件。這個切分很關鍵：Alert 是原始訊號，Case 是收斂後要人處理的單位，Artifact 是被抽取出來、可以拿去濃化的實體。對照多數 SOAR 產品把事件與案件混在一起談，這裡的物件邊界相對清楚。
適合的對象因此不是只有兩三個人、沒有正式 SIEM 的小團隊。沒有穩定告警來源，就沒有東西可以收斂。
Case 為中心的資料流，以及 Playbook 同時容納 SOAR 與 LLM
從 README 的敘述可以還原出一條主線：告警進來，模組抽取 IOC 並做關聯，收斂成 Case；接著在 Case 上觸發 Playbook，執行 LLM 調查、知識抽取、威脅情報濃化與 CMDB 濃化。
最值得注意的設計是 Playbook 的定位。README 寫的是 orchestrating traditional SOAR workflows and AI analysis in the same Playbook system，也就是傳統 SOAR 動作與 LLM 分析共用同一套編排。這跟把 LLM 當成獨立聊天視窗、分析師手動複製貼上的做法差別很大：在同一套 Playbook 裡，LLM 的輸出可以成為後續自動化步驟的輸入，反過來也一樣。
另一個方向是對外暴露能力。README 提到透過 CLI 與 plugins 把 ASP 的能力開放給 Claude Code、Codex、OpenCode 等 Harness Agent，讓這些 Agent 直接操作 Case、搜尋日誌、查詢威脅情報，甚至撰寫模組與 Playbook。這裡的實際介面細節在 README 中沒有展開，只有一句描述，要動手前應以官網文件為準。
知識累積則掛在 Case 關閉之後：從已結案的調查紀錄、回應過程與討論中抽取可重用知識。這是一個長期才看得出價值的機制，短期內無法驗證效果。
部署與接入：從 Quick Start 到 Splunk、ELK 設定
README 本身沒有提供安裝指令，只有指向官網 Quick Start 的連結（https://asp.viperrtp.com/asp/quick-start/deployment/）。因此具體的 docker compose 或安裝步驟，必須以官方文件為準，這裡無法憑 README 給出可複製的指令。
能從 README 確認的接入面有兩項。第一是 Multi-SIEM：明列支援 Splunk 與 ELK 配置，並提供統一日誌搜尋與 Webhook 告警接入。第二是擴充方式：用 Python Modules 去適配新的 SIEM 規則與告警來源，用 Playbooks 編排 LLM 分析與自動化動作。README 只寫到這裡，沒有給出模組的類別名稱、註冊方式或設定檔路徑，這些都要看官方文件。
治理面則相對明確：本地與 LDAP 登入、使用者角色、API Keys、Inbox 通知與 Audit Log。對需要留痕的環境來說，Audit Log 與 API Keys 是能不能進正式流程的前提，README 有提到，但沒有描述記錄欄位與保存策略。
部署形態是自架，README 強調 fully local deployment supported，安全資料留在內網。這對資料不能出境的團隊是必要條件，同時也意味著 LLM 這一段的算力與維運要自己承擔。
自架 LLM 與模組開發，是兩個容易被低估的成本
README 把「低成本的適配」放在 Python Modules 與 Playbooks 上，但這兩者都指向同一件事：需要有人寫程式。新的告警來源要寫 Module，新的調查流程要寫 Playbook。這不是設定檔填空，是持續的開發工作。
第二個成本在 LLM。平台的核心價值建立在 LLM 調查與知識抽取上，而部署形態是本地。README 沒有說明支援哪些模型、是否需要外部 API、或是本地推論的硬體要求。這代表在你確認官方文件之前，無法估算推論成本，也無法判斷資料是否真的完全不出內網。
第三個是版本節奏。近期釋出包含 v0.5.0、v0.5.1、v0.5.2，其中 v0.5.2 的標題是 When all is darkest，時間落在 2026 年 7 月底。版本號還在 0.x，三個版本集中在一個月內，說明介面與行為仍可能變動。把 Playbook 與 Module 綁在 0.x 版本上，要有跟著改的心理準備。
授權也必須自己確認。README 寫 MIT licensed，但 GitHub 的 License 欄位顯示 unknown。這兩者不一致時，以倉庫內實際的 LICENSE 檔案為準，這不是法律意見，只是導入前該做的核對。
什麼情況下它會是錯的工具
第一種情況是沒有 SIEM。平台的輸入端是 SIEM 與 Webhook 告警，收斂邏輯建立在既有告警之上。若你的環境只有端點防護主控台，沒有集中式日誌，這套平台沒有原料可用。
第二種情況是需要確定性回應的場景。LLM 調查產出的是 severity、confidence、impact、priority、verdict 這類帶有信度的判斷。README 用秒級描述 AI 調查的速度，但沒有提供準確率、誤判率或任何評測數字。對於必須逐條舉證、回應動作要可重現的合規場景，把 LLM 判斷放進主流程需要額外的驗證設計，而平台是否提供這層驗證，README 沒有交代。
第三種情況是團隊沒有 Python 能力。整個平台的擴充路徑都指向 Python Module 與 Playbook，這是它的彈性來源，也是它的門檻。
還有一種是規模太小的團隊。本地部署、LDAP、角色、Audit Log 這些治理功能，只有在多人協作、需要分工與留痕時才產生價值。單人維運的環境負擔不起這套複雜度。
與 Shuffle、n8n 這類通用編排工具的差別
常見的替代路線是用 Shuffle 或 n8n 這類通用自動化編排工具接 SIEM，自己串通知與濃化動作。兩者的差別在資料模型。通用編排工具的狀態是流程實例，觸發一次跑一次，跑完就結束；ASP 的狀態是 Case、Alert 與 Artifact，告警會被關聯、收斂，並在同一個 Case 上累積調查紀錄與知識。
第二個差別在 LLM 的位置。在通用編排工具裡，LLM 通常是一個 HTTP 節點，輸出要自己解析、自己塞進下一步；ASP 把 LLM 調查與傳統 SOAR 動作放進同一套 Playbook 系統，並在 Case 關閉後回頭抽取知識。前者需要你自己設計上下文傳遞，後者由平台承擔。
代價是綁定。用通用編排工具，流程邏輯是你自己的資產，換工具時可以搬；用 ASP，Playbook 與 Python Module 綁在它的物件模型與 0.x 版本上。若你的自動化流程會頻繁重構，通用工具的鬆散耦合反而更好。
誰該導入，以及動手前先驗證什麼
已有 Splunk 或 ELK、告警量已經壓垮分析人力、內部有 Python 開發能力、且資料必須留在內網的藍隊，是這套平台最合理的對象。README 描述的功能組合，正好對應這類團隊的三個痛點：告警收斂、調查加速、知識沉澱。
不該導入的情況同樣清楚。沒有集中日誌來源、沒有人能維護 Python Module 與 Playbook、或需要以確定性與可重現性為前提的回應流程，都不適合。
動手前建議先確認四件事。第一，倉庫內是否確實有 LICENSE 檔案，README 標示 MIT 但 GitHub 欄位顯示 unknown。第二，官方 Quick Start 文件中的部署方式與硬體需求，特別是 LLM 這一段是本地推論還是外部 API。第三，你的 Splunk 或 ELK 版本是否在支援範圍內，以及 Webhook 告警的格式要求。第四，Case 與 Artifact 的欄位能否對上你現有的 CMDB 與身分來源，這決定了濃化功能是即插即用還是要另外寫 Module。
最後一點關於維護：版本仍在 0.5.x，且三個版本集中在一個月內釋出，升級時要預期 Playbook 與 Module 可能需要跟著調整。這不是勸退，而是把它當成一個還在快速變動的專案來安排人力。
編輯結論
如果你的團隊已經有 Splunk 或 ELK，痛點是告警量太大、分析師不夠，而且內部願意寫 Python Module 去接自家 SIEM 規則，這套平台值得排進試用清單。若你期待裝完就能自動處置、或組織內沒有能維護 LLM 與 Playbook 的人，先不要導入。動手前先確認三件事：倉庫內是否有 LICENSE 檔案（README 標示 MIT，但 GitHub 授權欄位顯示 unknown）、你的 SIEM 版本是否落在官方文件支援範圍、以及 Case 與 Artifact 的資料模型能否對上你現有的 CMDB 與身分來源。
社群筆記