Cloudflare 讓 OpenAI Daybreak 模型讀懂正式環境,把弱點掃描結果排出優先順序
Cloudflare Blog · 2026-09-03
Cloudflare 於 2026 年 9 月 3 日在 Managed Defense 服務中加入一項邀請制早期功能,把 OpenAI 的 Daybreak 系列模型(包含 GPT-5.6 Cyber)接進客戶已授權程式碼庫的弱點掃描流程。這套機制用在客戶原始碼的弱點發現與修復建議上,會把模型輸出跟 WAF、Web Assets 等正式環境訊號交叉比對後再排序。核心賣點不是掃出更多弱點,而是決定先修哪一個。
原本的問題
掃描工具能吐出大量弱點清單,卻答不出「先修哪一個」。文中舉例:「你的掃描器剛標記了 4,000 個新弱點,其中 78 個是 critical,先修哪一個?」傳統掃描器不知道哪些路由真的部署上線、流量有多大、有沒有既有 WAF 規則擋著。LLM 加速弱點發現後清單只會更長,但排序方式仍停在單純的嚴重度分數。弱點數量跟修復急迫性從來不是同一件事。
採用的方法
Cloudflare 設計了四段式流程:先從 Web Assets 與 WAF 抓取路由的流量與安全事件快照;偵察(reconnaissance)代理人把請求路徑對應到程式碼區塊;獵人(hunter)代理人帶著這些網路情境去搜尋弱點;最後驗證階段拿原始碼交叉比對發現,用正式環境證據調整風險分數,再產生修補程式碼與範圍受限的 WAF Custom Rules,部署前跑合成測資驗證。所有提示詞會先做過 redaction,再經 Cloudflare AI Gateway 轉送到 OpenAI 伺服器做推論,推論本身不在 Cloudflare edge 上執行。
這套方法論延伸自 Cloudflare 既有的內部掃描機制,在其另一篇 Build your own vulnerability harness 文章中拆成兩段:
Vulnerability Discovery Harness(VDH):由 recon、hunt、validate、gapfill、dedup、trace、feedback、report 八種代理人組成,每個 finding 都要先定義威脅模型Vulnerability Validation System(VVS):每個 finding 需附上可執行的 proof-of-concept 與修補建議,再由獨立代理人覆核後才算存活
執行環境用 unshare 做沙箱隔離,容器設定 seccomp=unconfined 與 apparmor=unconfined 以允許受控的二進位測試,結果存進 SQLite,以 (run_id, repo, stage) 為鍵值方便斷點續跑。沙箱與可續跑的儲存設計,是讓多代理人流程能長時間穩定運作的關鍵。
實際效果
Cloudflare 官方公告本身沒有公布 VDR 功能的量化準確率或修復時間節省數字,只提到用 LLM 可以「在幾分鐘內」浮現弱點。但其底層方法論在 harness 一文中有具體數字:
| 指標 | 數值 |
|---|---|
| 原始候選項 → 可處理發現數 | 20,799 → 7,245(橫跨 145 個儲存庫) |
| 驗證階段拒絕率 | 從 40% 降到 11% |
| 高可信度發現比例 | 從 35% 升到 58% |
| 單一 3 萬行程式碼儲存庫掃描時間 | 約 3–4 小時,完整流程約 14 小時 |
驗證拒絕率下降、可信度上升,說明多階段代理人覆核確實在過濾雜訊,而不是單純靠模型多跑幾次來刷數量。
原始來源:Cloudflare Blog：Introducing context-aware vulnerability discovery and remediation、Cloudflare Blog：Build your own vulnerability harness
從連線風暴到可控扇入:Meta 用 ZGateway 代理層重塑 ZippyDB 的存取模式
Meta Engineering Blog · 2026-09-03
Meta 工程部落格在 2026 年 9 月 3 日發文說明,如何在 ZippyDB(以 RocksDB 為底層儲存引擎的鍵值資料庫)前面加上一層無狀態代理 ZGateway,取代原本客戶端直連資料庫主機的架構。這套代理目前承載 ZippyDB 整體流量的約 40%,團隊預期會提升到 60% 以上。設計目標是讓資料庫主機的連線扇入(fan-in)跟客戶端數量脫鉤。
原本的問題
直連模式下,單一客戶端可能碰到數萬個不同分片、分布在數十萬台主機上,形成「多對多的 TLS 連線網」——典型客戶端維持數萬條對外連線,典型資料庫主機也要接住數萬條進入連線。文中提到一次真實事故:一個路由錯誤導致每個客戶端對每個分片各開一條連線,主機的檔案描述符用量衝破上限,整個機群陷入重開機迴圈。扇入規模跟著客戶端數量線性成長,任何新客戶群加入都會讓每台資料庫主機的負擔變重,而這個耦合關係資料庫團隊完全無法控制。
採用的方法
ZGateway 是「一個以受管理服務形態運行的 ZippyDB 客戶端」,內部照樣跑 Meta 的 C++ thick client,只是集中搬到代理層,統一處理所有租戶(tenant)的請求。請求依序:終止 TLS 並依 use-case ACL 授權、透過 Discriminant Load Shedding(DLS) 做逐租戶准入控制、查詢分片位置命中在地快取、依相同分片打包(batching)並合併同時到達的相同 key 請求(coalescing)、再路由到正確複本。批次與合併是跨客戶端做的,單一程序的批次器只能合併自己發出的請求,代理層能把所有客戶端對同一把 key 的請求收斂成一次。
- 連線與 TLS 終止層,搭配
ServiceRouter做地區服務發現 - 讀穿快取層(read-through cache),靠 change-data-capture 串流做失效通知,並訂出明確的 bounded-staleness 邊界
- 逐租戶准入控制,採用
AIMD(adaptive increase multiplicative decrease)演算法的 CPU 併發控制器 - 負載平衡器,使用加權一致性雜湊(weighted consistent hashing)動態調整各複本權重
文中的規模模型顯示,直連模式下資料庫主機扇入是 H_client·p,跟客戶端族群數量線性相關;換成 ZGateway 後,扇入降為約 R·S_host(地區數乘上每台主機的分片密度),不再受客戶端數量影響。這個模型把一個「不受控的變數」換成「團隊自己能設定的變數」。ZippyDB 建立在 2021 年原始架構文章所述的 RocksDB + Data Shuttle(Multi-Paxos 複製)之上,ZGateway 只新增存取代理層,不動底層儲存與複製機制。
實際效果
在一個假設 20 個地區、50 萬台資料庫主機、3 萬台代理主機、100 萬個客戶端、每客戶端 5 萬個分片的規模模型中,團隊量到以下結果:
| 指標 | 直連模式 | ZGateway 代理後 |
|---|---|---|
| 資料庫主機扇入 | 與客戶端數量線性相關(H_client·p) | 約為 R·S_host,與客戶端數量無關 |
| 每主機連線數 | 基準值 | 下降約 97–98% |
| 端對端持久連線數 | 基準值 | 減少約 19 倍 |
| 平均運算開銷 | — | 約 6% |
在一次超載測試中,約 1,350 個活躍租戶桶(tenant bucket)裡,CPU 使用率衝上 90% 以上時只有 6 個桶被限流,其餘 1,344 個桶仍以 99.9% 的請求執行率運作,整體 goodput 維持在 97–98%,控制機制本身只吃掉約 8% 的 CPU。租戶隔離是結構性的,不是靠運氣——每個請求對應到一個逐租戶桶,單一租戶灌爆時只有自己的桶被限流,其他桶照常運作。整個遷移分九個階段推進到 100% 的交易流量,過程中沒有出現可靠性退化。
原始來源:Meta Engineering：ZGateway: Learnings from Putting a Proxy in Front of ZippyDB、Meta Engineering：ZippyDB（2021 原始架構文章）
Spotify 用 Portal 的「經濟艙模式」把 Claude Code 讀檔任務丟給便宜模型,省下九成 token
Spotify Engineering Blog · 2026-09-03
Spotify 工程部落格在 2026 年 9 月 3 日刊出文章,作者描述如何用內部開發平台 Portal(建立在 Backstage 之上)的 AiKA Modes 功能,把 Claude Code 裡耗費大量 token 的批次讀檔與樣板程式碼產生工作,轉發給更便宜的模型執行。這個名為 shunt 的外掛用在作者日常維護的 Java 單體儲存庫(monorepo)上。結果是批次讀檔的 token 用量平均降低 90%。
原本的問題
文中先給出成本背景:到 2028 年 AI 寫程式的成本預計會超過一般工程師的平均薪資,目前工程團隊每位開發者每月已要付 $200–$500 美元的 token 費用,某些團隊甚至超過 $2,000。真正的浪費點在於,讀一個大檔案、或照著既有樣式產生樣板程式碼這類不需要推理的 I/O 工作,也是用同一顆昂貴的主模型去做——檔案內容跟產生出來的程式碼會整個進到 Claude 的 context 裡計費。問題不是模型不夠聰明,而是把便宜的工作交給了貴的模型做。
採用的方法
解法是三層架構,把「會不會進入 Claude context」當成分流依據。最上層由兩個 PreToolUse hook 負責攔截:check-file-size 攔下超過 SHUNT_MIN_LINES(預設 350 行)的讀檔請求並轉導走,check-bash-read 則攔截對大檔案下的 cat、head、tail 等 shell 指令。
- Hooks:攔截層,依
.claude/settings.json或環境變數SHUNT_MIN_LINES判斷是否轉導 - Scripts:兩支包著 Portal CLI 的 bash 腳本——
bulk-read把檔案包進 XML 標籤丟給bulk-reader模式;code-write把規格與參考檔案丟給code-writer模式,拿到輸出後去掉 markdown 直接寫入磁碟 - Skills:用 Markdown 技能檔告訴 Claude 什麼時候該呼叫哪支腳本
bulk-reader 和 code-writer 兩個模式都設定用 Gemini 2.5 Flash 這顆較便宜的模型執行,temperature 設成 0.2,並要求只輸出條列重點或純程式碼、不准有多餘說明文字。Portal 官方文件把 AiKA Mode 定義為「跑在短生命週期執行環境上的宣告式代理人,你設定指令、選模型、調參數如 temperature、掛上 MCP 工具」,概念類似 AWS Lambda,只是服務對象換成 AI 任務。關鍵是大檔案內容與產生出來的程式碼永遠不進入 Claude 的 context——bulk-reader 只把摘要送回來,code-writer 產生的程式碼直接落地到硬碟,這跟索引或快取是不同的思路,單純是把該花的錢轉嫁給便宜的模型。
實際效果
作者在自己的 Java monorepo 上量測,批次讀檔操作的 token 用量平均省下 90%,算法是比較「Claude 直接讀檔案」跟「改讀 bulk-reader 摘要」兩種情境下消耗的 token 數。每次委派的延遲落在 10–30 秒之間,Portal 呼叫本身設有 30 秒逾時上限。專案已開源在 spotify/portal-ai-plugins,shunt 外掛目前僅支援 Claude Code。九成的節省數字來自單一 monorepo 情境的量測,並非涵蓋所有 Claude Code 用量的通用比例。
原始來源:Spotify Engineering：Portal by Spotify cut my Claude Code token usage by 90%、GitHub：spotify/portal-ai-plugins