安全告警很少一則一則來。一條告警常常在環境裡連環觸發，分析師得先判斷哪些相關、各代表什麼，同時新告警還在湧入。Cloudflare 在 2026 年 10 月 7 日發表的這套 agentic security operations harness，就是針對這個瓶頸：讓 agent 負責組裝調查、串連相關事件、附上證據，把最終判斷留給 Cloudflare Managed Defense 分析師。
對 builder 來說，值得細讀的不是「加了 AI」這件事，而是他們踩過的坑，以及繞開那些坑的架構選擇。
單一 agent 為什麼行不通
第一版原型把整個調查交給一個通用 agent，產出的分析有用，但也出現了證據不支持的幻覺。Cloudflare 在文章中歸納出三個反覆出現的問題：
- Context 變成 authority：偵測結果只是假說，通用 agent 卻容易把它當成攻擊確實發生的證明。
- Scope 漂移：agent 可能查錯帳號、時間範圍或資料來源，不能指望 prompt 本身成為邊界。
- 失敗消失了：查詢逾時時，結果分不清「沒查」和「查了但沒找到」。
對策是把證據收集和範圍管制搬進應用程式碼，在模型開始推理之前就完成。
前半段完全沒有 agent
最有意思的取捨：明明每一步都可以塞 agent，但 harness 的前半段一個都沒有。確定性的程式碼跑一組固定的偵察工作流，用版本化的 API 呼叫收集客戶身份、偵測歷史、流量基線和執行結果，每筆資料都帶來源、版本和時間戳。
這個固定的偵察快照帶來一個常被忽略的好處：評估可以重現。如果每個 agent 自己抓資料，兩次執行可能因為輸入不同而結論不同；同一份快照重放之後，幾個專家 agent 之間的差異就純粹來自詮釋，而不是檢索。
接著 Clef（Cloudflare 開源、跑在 Workers AI 上的決策模型）做輕量分診，把高機率誤報的告警直接擋在專家 agent 之前。
四個專家、一個合成者
需要深入調查的告警，由一個 coordinator agent 平行派給四個專家：流量分析、客戶脈絡、全球遙測、威脅情報。全球遙測只用聚合資料，接觸不到其他客戶的個別紀錄；合成 agent 把各家的 typed findings 併成一份 advisory，但不能抓新證據、也不能在核准的詞彙表之外選分類。
每個任務都收得很窄，所以沒有根據的宣稱容易被抓出來。應用程式碼會逐一驗證：每條引用是否真的存在、屬於這次調查、且支持所附的宣稱。證據不足時，系統直接不做分類，並且在報告裡區分「未檢查」、「查了沒結果」、「查了且有證據支持不存在」三種狀態——這正是修正第三個失敗模式的地方。
底層跑在 Cloudflare 自家開發者平台上：Workers 收錄與驗證證據、Workflows 協調各階段並保存已完成的工作、D1 存狀態、Durable Objects 管 case-chat、R2 放證據產物。深層分析則使用核准的 OpenAI Daybreak GPT-5.6 Cyber 與 Anthropic Mythos 模型。
對自己 harness 的三個提醒
讀完之後，我覺得有幾點可以直接搬到自己的 agent 專案上：
- 把範圍寫進程式碼，不寫進 prompt。客戶邊界、時間錨點、可用的分類清單，都由應用層先固定下來，模型拿到的只是縮小後的選擇。
- 輸入要可重放，評估才可重現。固定快照讓「agent 之間的分歧」變成可診斷的訊號。
- 失敗要有名字。「未檢查」和「確認不存在」必須是不同的狀態，否則 agent 的輸出會悄悄把無知包裝成結論。
這和之前談過的問題是同一族：工具和證據放錯層，換一個模型就壞（/blog/agent-frameworks-tool-schema-translation-layer/）。Cloudflare 這篇的價值，在於他們把「證據調度」這一層明確地放在模型之前。
計畫上，Cloudflare 表示未來幾季會加入針對個別組織更有彈性的 Custom Managed 層級，並探索持續監看流量的 AI agent。早期 beta 已在 Cloudflare Managed Defense 開放給符合資格的應用安全告警。值得留意的是，這些成效描述來自 Cloudflare 自己的發布，尚未有第三方驗證；但「先偵察、後推理」這個結構本身，已經是可複用的設計參考。