六個月暴增 25 倍：Anthropic 自家 CI 系統的崩潰史，揭露代理式編程的隱藏帳單

每一場代理式編程（agentic coding）的產品展示都是同一套精華片段：代理啟動、寫好一個功能、通過測試，然後 pull request 在幾分鐘內合併。2026 年 9 月 14 日，Anthropic 出版了更罕見的東西——收據。在一篇標題為「Agentic coding is straining CI」的工程檢討文章中，工程師 Sachin Malhotra 完整交代了當程式碼生成不再是瓶頸之後，一個軟體組織裡最不起眼的基礎管線會發生什麼事。即使以一家打造代理的公司而言，這些數字依然令人吃驚。

Anthropic 工程師平均每季產出的程式碼量，如今是 2021–2025 年期間的 8 倍，其中約 80% 由 Claude 撰寫——這是該公司五月首次披露、並在此文中再次確認的數字。Claude 同時也在「審查與核准 PR 的過程中扮演重要角色」。同期間，程式碼庫中的測試數量成長了 10 倍，而工程師人數只有名目上的增加。結果就是：持續整合（CI）作業量在六個月內暴增 25 倍。

沒有人編列預算的那一塊

代理式編程的 punchline 是：寫程式不再是瓶頸。但魔鬼藏在細節裡——寫程式之後的每一個環節（code review、merge queue，尤其是 CI）都必須承受完整的乘數級負載。Anthropic 內部有一套確定性的測試影響分析（test impact analysis）服務，依據歷史結果與套件相關性，決定每個 pull request 要跑哪些測試。正是這套基礎設施讓「不必在每個 PR 上跑全部測試」變得可行——而它差點成為下一個單點故障。

這套服務的原始設計是單體架構：一個「listener」程序記錄每次 CI 執行的結果，一個「selector」讀取這些歷史、為新開的 PR 挑選測試。因為每個測試的歷史需要單一寫入者，服務無法水平分片。當 CI 作業開始以每秒多個的速度湧入，listener 開始落後於 PR 佇列——而在 AI 原生的軟體開發生命週期裡，延遲會殘酷地複利放大。listener 落後二十分鐘，可能意味著數萬筆測試結果更新沒有即時套用到 selector 上，於是 selector 拿著過期資料做決策：flaky 測試擋住合併、回歸問題從縫隙溜走、待命工程師在凌晨兩點被警報叫醒。

三次修補：70 天、29 天、不到一天

接下來是一篇前沿實驗室迄今最坦白的擴容敘事之一。2025 年 10 月，這套服務已經連續兩天觸發警報。修補方案以一個熟悉的遞減曲線登場：

• 修補一：換更大的機器。 他們把核心數加倍。所有人都知道撐不久；這次買到了大約 70 天。
• 修補二：分片。 關鍵洞見在於 listener 並不需要唯一的寫入者處理所有結果，只需要每個套件有單一寫入者。一個內部版的 Claude Tag 長時間 session——它已經監控這套服務數個月、每當積壓超過 5 萬筆作業就主動通知負責人——生成了將每個套件狀態拆分為獨立 shard 的程式碼。這次買到了 29 天。
• 修補三：每日重啟。 到了三月，程序在平常日大多下午三點前就觸頂記憶體限制。重啟買不到一天的安定，更糟的是，每次重啟都讓服務落後得更多。

最值得停下來咀嚼的細節是：持續建議「別再修補、直接重寫」的，是監控 session 裡的 Claude 本人。人類「通常還是選擇再補一版」——這是非常人類的失敗模式，而代理工具本來就是要修正這種模式，最終也確實修正了。

重新設計

最終的方案採納了代理的建議：單體服務獲得了一個記憶體內資料儲存，listener worker 以無狀態方式把結果寫入 journal，一個小型消費者程序每隔幾秒把 journal 彙整成每個測試的歷史，selector 則直接查詢儲存層。任何 worker 都能處理任何結果，整條路徑因此可以水平擴展。分散式版本的成本更高——但它穩定、可分析，不再是一場賭局。

文末最安靜也最激進的一句話是：這次重新設計由一位工程師在三週內完成；一年前，同樣的專案需要一整季。 把基礎設施壓垮的工具，也吸收了重建它的成本。連 journal 大小與 worker 數量的微調，「大部分也由 Claude 自主完成」。

為什麼這件事不只關乎 Anthropic

這篇檢討文章裡藏著兩個結構性轉變，而且適用於每一個認真採用編程代理的團隊。

第一，代理改變了 pull request 的形狀。Claude 偏好更小、更細顆粒的 PR——這是良好的衛生習慣，但會讓每單位交付工作的 CI 作業數量倍增。同時活動基線被墊高，因為代理在夜間與週末持續推 code；但負載依然呈現爆發性，因為相當比例的 PR 仍由人類驅動與核准。CI 負載變得既更高、又更難預測。

第二，「過度工程」的經濟學已經反轉。Malhotra 的明確建議是：無論自建或採購，都要假設你的架構將在兩季內承受 25 倍負載，「只要預算允許」，在 v0 設計就納入 10–20 倍的預期規模。從第一天起就讓狀態離開程序；為服務做好儀器化，讓代理成為「眼睛和耳朵」、自主爬坡修復問題；絕對不要把關鍵服務跑在你無法量測、無法金絲雀部署的單一實例上。

誠實的帳本

Anthropic 有充分動機宣傳加速的成果，而沒有動機公開隨之而來的成本——這正是這篇文章珍貴的原因。「80% 程式碼由 Claude 撰寫」佔據了標題，但可移植的教訓存在於技術堆疊無聊的中層：驗證基礎設施現在必須以代理式編程的第一級產品之姿來擴展，而不是事後補上的附屬品。測試影響分析——一個多數組織從未需要過的冷門學科——正在變成標準配備，因為另一條路是支付運算資源與時間，在源源不絕的機器撰寫 PR 上跑完每一個測試。

「永遠為指數成長做計畫」是作者用教訓換來的結論。對正在規劃 2027 年預算的工程主管而言，這篇 Anthropic 的檢討文章提供了一個罕見且量化的預覽：代理會寫你的程式碼，然後也會寫出能撐住你程式碼的基礎設施。最終勝出的，會是那些提早注意到後半句的組織。