Cloudflare 內部 AI 工程基礎架構：241 億 Token、三層架構與 MCP Portal 設計
Cloudflare Blog · 2026-04-20
Cloudflare 公開了其在自身平台上構建的企業 AI 工程基礎架構，30 天內處理 4,795 萬次 AI 請求、2,413.7 億個 Token，覆蓋 3,683 位工程師。此架構以三個層次組成：平台層（Platform）、知識層（Knowledge）、執行層（Enforcement）。
平台層：認證、路由、安全
Cloudflare Access 處理零信任認證。AI Gateway 集中管理 LLM 路由、成本追蹤與資料保留控制。一個 Proxy Worker 管理供應商 API Key——金鑰永遠不接觸工程師的機器。模型分佈：前沿模型（OpenAI、Anthropic、Google）佔 91.16% 請求，Workers AI 佔 8.84%。
用戶端配置透過單一 URL 完成：opencode auth login 觸發 discovery endpoint，返回包含供應商、MCP 伺服器、Agent、權限的完整設定，無需手動編輯設定檔。
知識層：服務目錄與 AGENTS.md 系統
Backstage 服務目錄維護 16,000+ 實體，包括 2,055 個服務、167 個函式庫、122 個套件、228 個附有 schema 的 API、375 個具擁有者映射的團隊，以及連接服務至資料庫與資源的依賴關係圖。
約 3,900 個 repository 各自維護 AGENTS.md 檔案，規格包含：runtime、測試命令、程式碼組織、開發慣例、邊界說明、依賴項。Agent 在工作階段開始時讀取此檔案作為程式庫上下文。
執行層：AI 程式碼審查與 Engineering Codex
AI 程式碼審查員（AI Code Reviewer）在標準 CI 管線中達 100% 覆蓋率，30 天內處理 547 萬次 Gateway 請求、247.7 億 Token。多 Agent 架構依風險層級對 PR 分類，設有程式碼品質、安全、合規、效能等專責 Agent。Engineering Codex 將組織工程規範形式化為 Agent 可存取的規則，審查回饋引用具體的 Codex 規則。
MCP Portal 的 Token 效率設計
Portal 將 34+ 個獨立工具 schema 合併為兩個 portal 層級工具，將上下文開銷從 15,000 Token 降至最小，實現可擴展的工具整合。
規模指標（2026-02-05 至 2026-04-15）
| 指標 | 數值 |
|---|---|
| 活躍使用者 | 3,683（R&D 部門覆蓋率 93%） |
| 每週 MR 數 | Q4 ~5,600 → 2026-03-23 達 10,952 |
| Workers AI 安全工作 | Kimi K2.5 每日 70 億 Token，成本比同等專有模型低 77% |
原始來源：Cloudflare Blog – The AI engineering stack we built internally
Spotify Honk Part 4：背景程式碼 Agent 自動化資料集遷移 1,800 條管線
Spotify Engineering · 2026-04-22
Spotify 工程團隊發布 Honk 系列第四篇，記錄如何利用 Claude-based Agent（Honk）、Backstage、Fleetshift Plugin 協同，在六個月的遷移窗口內自動化處理約 1,800 條直接下游資料管線，節省約 10 工程師週的手動工作量。
遷移規模與技術挑戰
廢棄資料集影響公司內數千條管線（直接下游約 1,800 條），涉及三種不同的管線技術框架：BigQuery Runner、dbt、Scio。三種框架的遷移複雜度差異顯著，最終 Scio 因實作模式過於多樣而排除在自動化範圍之外。
三平台整合架構
Backstage：提供端點血緣（endpoint lineage）可見性與程式碼探索。每個端點的 Backstage 頁面列出明確的下游消費者清單，配合 Codesearch 插件跨 GitHub Enterprise 識別目標 repository。
Fleetshift Plugin：在 repository 間協調遷移流程，提供快照式 UI 監控進度，簡化問題排查與跨團隊溝通。
Honk Agent：執行自動程式碼轉換，共生成 240 個成功的遷移 Pull Request。Agent 在不使用外部工具或 Claude Skills 的情況下運行，純靠上下文設計（context engineering）驅動。
上下文工程關鍵
初始使用改編的遷移指南作為提示不足以應對複雜案例。最終解決方案是在上下文檔案中加入明確的欄位映射表，消除 Agent 對欄位對應關係的錯誤假設；同時包含需要人工判斷的邊緣案例指引，並附上遷移文件連結。由於 BigQuery Runner 和 dbt repository 幾乎不使用建構時單元測試，自動驗證無法實施，需下游團隊手動驗證。
未來改進方向
團隊識別出規模化 Agent 輔助遷移的三項前提：資料格局標準化與整合、強制性測試與驗證基礎架構、Agent 上下文收集能力的增強。
原始來源：Spotify Engineering – Background Coding Agents: Dataset Migrations (Honk, Part 4)
Meta 後量子密碼遷移：六步框架、ML-KEM 部署與組織協調
Meta Engineering · 2026-04-16
Meta 公開了其後量子密碼（Post-Quantum Cryptography，PQC）遷移的框架、技術選型與組織層面的挑戰，已在內部流量的顯著部分部署 PQC 保護，涉及 Transport Security、WhatsApp、Infrastructure、Reality Labs、Hardware、Payments 等多個跨職能團隊。
核心演算法選型
金鑰交換：ML-KEM（Kyber），優先採用 ML-KEM768（NIST Security Level 3，對應 FIPS 203）。
數位簽章：ML-DSA（Dilithium），優先採用 ML-DSA65（對應 FIPS 204）。
備選方案：HQC（由 Meta 密碼學家共同撰寫），提供數學多樣性——若格密碼（lattice-based cryptography）出現理論弱點，可作為後備。
六步遷移框架
1. 優先級定義：依量子威脅嚴重程度將應用分為高/中/低等級。2. 密碼學清單：透過自動化探索與開發者申報建立完整的密碼使用映射。3. 解決外部依賴：與標準機構、硬體廠商、實作社群協調。4. 設計 PQC 元件：選擇經審查的演算法與安全參數。5. 實施護欄：更新指南、阻止脆弱金鑰建立、限制脆弱 API。6. 整合：透過混合方式（hybrid approach，結合經典 + PQC 層）部署。
「現在儲存、未來解密」威脅模型
Meta 遷移的核心驅動是「Store Now, Decrypt Later」攻擊：攻擊者今日蒐集加密流量，待量子電腦（預估 10–15 年後）成熟後再解密。這意味著 PQC 保護的價值在當下即存在，而非等量子電腦實際出現才需行動。
混合部署策略
Meta 優先採用混合方式，在經典密碼之上疊加 PQC 層，攻擊者需同時破解兩層才能取得明文。此策略緩解了 PQC 標準尚不成熟、實作可能存在缺陷的風險。實作透過與 Open Quantum Safe/LibOQS 聯盟合作確保生產等級的安全性。
原始來源：Meta Engineering – Post-Quantum Cryptography Migration at Meta