Cloudflare 於二零二六年十月七日在官方博客公開其 Managed Defense 多智能體資安營運框架：先以確定性程式碼完成偵察與證據封存，再用專責代理平行分析，並以開源決策模型 Clef 過濾高機率誤報。來源真實性已驗證。
此寫法把「模型能講甚麼」與「系統已核對甚麼」分開，減少單一代理幻覺與跨租戶越權風險，對正使用 Cloudflare WAF、DDoS 防護或 Magic Transit 的香港企業安保團隊具直接參考價值。
Cloudflare／官方：推出以證據為先的多智能體資安營運框架——Managed Defense 先偵察再推理，Clef 分流噪音並聯 Daybreak／Anthropic 深析
Cloudflare 在官方博客說明，資安告警很少「一次一條」地出現；單次告警可觸發環境內連鎖訊號，分析員既要判斷相關性，又要在新告警持續湧入時補齊缺漏來源。團隊把這稱為告警悖論，並以內建的多 AI 代理資安營運框架，在 Cloudflare 規模下分擔蒐證、關聯與彙整工作。來源真實性已驗證（對照 Cloudflare Blog〈Building an evidence-grounded agentic security operations harness on Cloudflare〉，二零二六年十月七日）。
本文整理其架構取捨：為何單一代理失敗、如何「先偵察、後推理」、專責代理與合成代理如何分工，以及對香港企業雲端與邊界防護的啟示。
一、核心事件：Managed Defense 的多智能體告警管線
技術細節
根據官方說明，Managed Defense AI 代理框架負責加快蒐集數據、串聯與彙整偵測，並在新告警持續到達時標示缺失來源。初步分析與評分使用 Cloudflare 開源決策模型 Clef；更深層的模型輔助分析則使用經核准的 OpenAI Daybreak 與 Anthropic 模型（文中點名包括 GPT-5.6 Cyber 與 Mythos）。目標是把分析員從「逐條問該消音、該處置、該當誤報還是真陽性」的重複決策中抽出，改為直接看到相關告警、已採納證據、可見缺口與建議下一步。
產品狀態方面，早期 beta 已向符合資格的應用資安告警與個案開放；若企業已使用 Cloudflare WAF、DDoS 防護、Magic Transit 或其他支援產品，可經企業客戶團隊洽詢加入 Managed Defense。官方亦預告未來數季將增加更具彈性的 Custom Managed 層級，並探索可持續運行的代理以補固定規則與門檻之不足。
二、技術原理深度解析
為何單一代理不夠
團隊第一代原型把整段調查一次交給通用代理，雖能產出有用分析，卻也幻覺出證據並不支持的主張。遙測、偵測器描述、政策與威脅情報被壓成同一提示後，角色邊界模糊。官方歸納三類反覆問題：
- 情境被誤當成權威：偵測是假設，不等於漏洞已被利用或攻擊已成功；寬鬆代理容易抹平這層差別。
- 範圍漂移：代理可能查錯帳戶、時間窗或資料來源；不能單靠提示詞當邊界。
- 失敗被吞掉：查詢逾時時，結果可能分不清「未檢查」與「已檢查但無發現」。
因此 Cloudflare 把證據蒐集與範圍強制移到應用程式碼，在模型推理開始之前完成。
先偵察，後推理
框架前半段刻意不放 AI 代理。確定性程式碼以版本化 API 呼叫執行固定偵察工作流程，收集客戶身分、偵測歷史、流量基線、強制執行結果與網絡觀測；每筆資料連同源、版本與時間戳一併保存。由於 Cloudflare 同時看見請求與套用動作，調查可把觸發告警的行為與控制措施及其結果對上。
固定偵察快照亦令評估可重播：若代理各自拉取資料，兩次運行可能因輸入不同而分歧；同一快照重播時，專責代理差異來自詮釋而非檢索。
早期濾噪與專責代理
多數告警並非事故。輕量分流模型（Workers AI 上的 Clef）比對告警與偵察資料：客戶是否見過、分析員過往裁定、流量是否像正常人類行為。高機率誤報可跳過專責代理；已知高量噪音亦可在到達時被確定性標為被動，僅作情境、不進主動佇列。
需深入審視的告警，由協調代理平行啟動四類專責代理：流量分析、客戶情境、全球遙測（僅聚合、不接收其他客戶個別紀錄）、威脅情報（僅核對已納入告警或個案的指標）。合成代理把類型化發現合併成一份諮詢意見，但不能再抓新證據，也不能選出核准詞彙以外的分類。應用程式碼在模型看到結果前固定客戶範圍，並只把各專責所需證據交給對方，模型無權跨租戶或代分析員執行動作。
從不完整證據到可稽核決策
系統在分析前建立版本化證據包（主體、範圍、時間錨點、已採納證據、政策版本、來源與覆蓋缺口）。專責發現必須引用該包內項目；應用程式碼核對引用存在、屬於本次調查且支撐所附主張。無效發現會被改正或記為限制。Clef 再次評分：證據是否足夠、是否互相矛盾，並從已收窄的攻擊分類與處置清單中挑選。
開發平台側，Workers 負責採納與驗證；Workflows 協調各階段並在進入下一階段前保存已完成工作，令失敗階段可重用已通過驗證的證據；D1 保存調查與諮詢狀態，R2 存放有界情境與證據產物；個案對話狀態落在 Durable Objects，並以 Flue 與 AI Search 強化。最終由 LLM 代理產出分析員熟悉的諮詢報告（受影響面、強制執行結果、相關控制、下一步）；分析員可檢視證據、深化調查、修訂建議或把告警歸入個案。緩解建議可指向速率限制、WAF 自訂規則或 DDoS 防護調整；全面託管客戶可由分析員套用建議，其他客戶則在儀表板與既有告警路徑收到建議。最終決策與緩解仍由 Managed Defense 分析員負責。
不完整證據時，諮詢須區分三種狀態：未檢查、已檢查無匹配、已檢查且有證據支持「不存在」。若全球遙測不可用，系統可描述對該客戶而言異常之處，但不能斷言模式是否廣泛；證據不足時不作分類或處置建議。
三、日常應用場景
1. 開發者與技術團隊
對已在 Workers、Durable Objects 上建可觀測管線的團隊，這篇文示範把「確定性偵察／引用校验」與「模型推理」拆層：版本化快照、失敗可重播、缺口顯式標記，可直接對照內部 agent harness 設計，避免把 SIEM 原始事件整包丟進單一提示。
2. 企業與隱私敏感行業
金融、電訊與受規管行業最怕跨租戶洩漏與「模型越權處置」。官方強調應用程式碼先鎖客戶範圍、全球遙測只用聚合、合成代理不可自取新證據——這些邊界比單純「有 AI SOC」更貼近合規審計需求。
3. 一般用戶／中小企安保負責人
若你已買 WAF 或 DDoS 防護，告警洪峰仍常壓垮值班。Managed Defense 早期 beta 針對合資格應用資安告警；重點不是取代人，而是把重複蒐證自動化，讓人專注確認範圍與下緩解。
4. 香港與亞洲市場視角
香港不少企業把對外網站與 API 放在 Cloudflare 邊緣。本地團隊若同時面對勒索、供應鏈與假陽性疲勞，可把「證據包＋引用校验＋三種缺口狀態」寫進內部 SOC runbook；即使未購買 Managed Defense，亦可要求供應商解釋其 AI 分析是否可重播、是否區分未檢查與已排除。
四、專業評價與潛在考量
優勢
- 把偵察移出模型，直接針對單一代理的幻覺、範圍漂移與失敗吞沒。
- 專責代理窄任務＋合成代理受限詞彙，較易稽核與攔截無依據主張。
- 全球遙測採聚合、客戶歷史分權重，兼顧跨互聯網訊號與租戶隔離。
- 與既有 Clef、Workers／Workflows／D1／R2 堆疊一致，工程路徑清晰。
需要留意的地方
- 早期 beta 僅涵蓋合資格告警類型；能力邊界需向客戶團隊確認。
- 更深層分析依賴第三方核准模型（Daybreak／Anthropic），供應鏈與資料處理條款仍須企業法務檢視。
- 最終處置仍靠人；若分析員過度接受諮詢詞彙，仍可能出現自動化偏誤。
- 「持續運行代理監控流量」仍屬規劃，固定規則漏報風險不會一夜消失。
結語
Cloudflare 這次公開的不是另一個「全能資安聊天機械人」，而是把告警調查拆成可重播的證據工程與可稽核的專責推理。對香港企業而言，重點問題應是：你們的雲端與邊緣防護，能否在模型開口前先固定租戶範圍、來源版本與缺口狀態？
若貴司正評估雲端遷移、零信任或 99.99% SLA 級別的網絡安全加固，可參考 YSK Limited 的雲端遷移與網絡安全服務（https://ysk.hk/services/cloud-security）。本地模型閘道需求亦可一併了解 YSK Omni v1.0.2（https://ysk.hk/products/ysk-omni）。
參考來源
- Cloudflare Blog, “Building an evidence-grounded agentic security operations harness on Cloudflare”, 2026-10-07 — https://blog.cloudflare.com/agentic-security-operations/