在現代雲端原生環境中，容器鏡像（Container Image）的安全性直接決定了整個軟體供應鏈的韌性。然而，面對海量的開源套件與不斷湧現的漏洞（CVE），如何確保成千上萬個鏡像能即時更新並保持最新狀態，成了許多企業的痛點。根據 Chainguard 共同創辦人兼 CTO Matt Moore 分享的技術經驗，該公司在半年內將其建置清單（Build Manifests）的產量從 5 億次提升至 10 億次，其核心不在於單純的硬體擴展，而是在於從傳統的事件驅動架構轉向一套基於 AI 代理人的自癒系統。
建置清單與持續更新的意義
首先需要釐清的是，所謂的建置清單（Build Manifest）並非指單一的軟體版本，而是指每次產出可驗證產出物（Artifact）的紀錄。例如，當 Python 的某個版本更新、libc 補丁發布、或是為了支援不同 CPU 架構而重新編譯時，都會產生新的建置清單。
對於 Chainguard 而言，這代表其目錄中的 3,000 多個唯一鏡像與 67.5 萬個版本能保持隨時更新。大多數的漏洞管理僅關注於鏡像在下載當下的安全性，但 Chainguard 追求的是讓鏡像在之後的每一天都保持安全。為了達成此目標，他們開發了 Chainguard OS，這是一個專為雲端原生工作負載設計的 Linux 作業系統，採用滾動更新（Rolling Release）機制，而非傳統每半年一次的大版本更新，確保安全補丁能以最快速度送達使用者手中。
從事件驅動到 Factory 2.0 的轉型
早期的建置基礎設施（Chainguard Factory）採用傳統的事件驅動（Event-driven）架構：當定義檔變更或依賴項更新時，觸發建置、簽名並發布。然而，隨著規模擴大，這種模式導致了嚴重的連鎖反應，內部稱之為級聯混亂（Cascading Mess）。
在舊系統中，只要某個環節部分失敗或出現非預期狀況，就必須由 SRE（網站可靠性工程師）人工介入修復。這導致團隊陷入 CVE 惡性循環，工程師大部分的時間在處理配置漂移（Configuration Drift，指實際環境與預期設定逐漸脫節）與系統衰減，而非優化安全性。
為了打破僵局，Chainguard 推出了 Factory 2.0，其核心是名為 DriftlessAF 的自校正建置系統。該系統將確定性的自動化與 AI 驅動的對帳（Reconciliation）機制相結合，將運作邏輯從反應式轉為狀態導向。
對帳迴路與 AI 代理人的協作機制
DriftlessAF 的運作核心在於對帳迴路（Reconciliation Loop）。系統不再僅僅對單一事件做出反應，而是持續比較期望狀態（Desired State）與實際狀態（Actual State）。當上游出現新版本、發現新 CVE 或定義了新的安全標準時，系統會自動識別差距並嘗試填補。
具體實作上，大量對帳機器人（Reconciler Bots）從共享隊列中領取任務，將代碼倉庫與安全饋送（Security Feeds）中的資訊同步至目標狀態。由於每個任務都是朝向定義好的終端狀態前進，而非執行一次性指令，因此即使單次任務失敗，系統也可以直接捨棄或重試，最終會趨向正確的結果。
在此過程中，AI 扮演了處理非結構化判斷的角色。傳統自動化難以處理的任務，例如分析次要版本中新增組件的影響，或將 CVE 修復方案反向移植（Backport）到舊版語言環境，現在由 AI 代理人執行。為了防止 AI 產生幻覺（Hallucination），這些代理人必須透過高度結構化且可驗證的工具來執行操作。隨著時間推移，系統能從先前的成功案例中學習，進一步提升處理複雜補丁任務的獨立性。
速度即是安全：對抗 AI 驅動的攻擊
這種極高建置速度的實務意義在於縮短攻擊者的機會窗。目前的威脅模型已經改變，攻擊者同樣利用 AI 工具來掃描依賴圖譜、鏈結弱點並快速產生漏洞利用程式（Exploit）。當攻擊者的週期縮短時，防禦者的週期必須同步縮短。
透過將建置產量提升至 10 億次，Chainguard 證明了對帳迴路能有效降低從上游變更到產出簽名鏡像之間的時間。每減少一小時的延遲，就等於減少了一小時的受攻擊風險。此外，這種自動化讓工程團隊能從繁瑣的運維勞務中解脫，轉而專注於提升基礎設施品質與擴展功能。
目前 DriftlessAF 的核心框架已開源，旨在讓其他面對大規模自動化挑戰的團隊能直接利用這套自癒機制，而非從零開始構建。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。