大型組織要做後量子（post-quantum, PQ）遷移，最難的不是換演算法，而是先回答一個問題：我們的程式碼裡到底哪裡用了加密？Cloudflare 在 2026 年 9 月 29 日發表的文章中，公開了他們用 AI 回答這個問題的做法，以及一支內部工具 CryptoLabe。他們設定了 2029 年的全面 PQ 就緒目標，加密傳輸已大致完成，剩下的是認證與長尾部分。
為什麼 grep 不夠用
加密在程式碼裡很少直接現形。它可能藏在共用函式庫、TLS 1.3 listener 的預設協商參數、另一個倉庫的 YAML 設定檔，或是根本不會執行的測試路徑裡。Cloudflare 在文中指出，直接搜尋演算法名稱會同時高估（找出未使用的程式碼）與低估（漏掉預設值與間接依賴），而且最關鍵的是無法判斷用途——同一個 ECDSA 簽章可能出現在 JWT、IPsec、TLS 或 SSH 中，每一種的遷移路徑完全不同。
AI 在這裡的價值不是「更好的 grep」，而是能跨檔案追證據、查內部文件與 ticket 系統、最後回傳結構化分析。
兩階段掃描與誠實的分類器
CryptoLabe 的掃描分兩段。第一段是探索：映射整個倉庫後，掃過原始碼、設定、manifest、lockfile、腳本、測試與文件，找出金鑰交換、簽章、非對稱加密、PKI、憑證、HSM 整合等使用情境，產生一批「原始觀察」。第二段是分析：每筆觀察重新對照原始碼驗證，調查執行時的實際用途、倉庫扮演的角色、依賴的內外部對象，甚至跨倉庫查相關程式碼，最後再做一輪自我審查，找設定覆寫或測試專用碼這類矛盾證據。
值得借鏡的是證據不足時的處理：模型會標成「More evidence needed」「External dependency」或「Unknown」，而不是硬猜。這種「寧可承認不知道」的設計，是這類自動化審計工具能不能被工程團隊信任的分水嶺。
架構上的三個決定
Cloudflare 把 CryptoLabe 建在自己的 Developer Platform 上，幾個決定很實用：
- 每個倉庫有一個以 Durable Object 為基礎的持久 coordinator，處理取消、重試與恢復，實際分析交給 Cloudflare Workflows 分四段（探索、深入分析、合併、發佈）執行。
- 掃描開始時把倉庫下載到指定 commit，存進 R2 快照；模型只能透過一組唯讀工具在 Sandbox 的隔離容器裡操作不可變快照，避免掃描過程動到程式碼。
- 模型請求走 AI Gateway 到 Workers AI 上的開源模型控制成本，也方便日後換模型。
其中容量問題特別值得記下：大量倉庫同時掃描時，模型請求爆量觸發 HTTP 429，各掃描獨立重試反而讓尖峰更嚴重。解法是一個全域 Durable Object 統一節流所有請求，一旦撞到限流，所有掃描一起退避、共享冷卻時間。這個「全域協調、共享退避」的模式，適用任何大規模跑 agent 的場景——和我們先前討論過的 Worker Previews 把每個 branch 變成可驗證環境 一樣，都是在回答「agent 大規模跑起來之後，基礎設施要怎麼接住它」。
對自己專案的啟發
Cloudflare 明言 CryptoLabe 高度綁定內部系統，不會對外提供，分享的是方法而不是工具。他們也坦承目前還沒有 ground-truth 資料集，無法重現地比較不同版本的 prompt——也就是說，這套流程的正確率目前靠人工抽檢，尚未被量化驗證。
如果你的產品也要做 PQ 遷移，最直接的下一步不是找工具，而是先盤點自己的加密使用點清單存不存在、進度能不能被度量。CryptoLabe 的示範是：把「發現、分類、報告」拆成可各自驗證的階段，AI 負責跨檔案推理與證據判斷，基礎設施負責快照、隔離與節流。這個分工，比任何單一模型選擇都更值得抄。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。