在開源社群的維護過程中，處理 GitHub Issue（問題回報單）往往是維護者最沉重的負擔。面對大量且品質不一的 Bug 回報，開發者必須花費大量時間去嘗試重現問題、分析原因並驗證修復方案。Cloudflare 最近針對 Astro 開源框架實作了一套基於 AI Agents（AI 代理，指能獨立執行特定任務並與環境互動的 AI 系統）的自動化分流與修復流程，成功將 Astro 的未解決 Issue 數量從 200 多個降低至約 30 個，降幅高達 85%，並以此探索將 AI 代理整合進軟體開發生命週期的可能性。
自動化分流的核心邏輯
這套系統並非單純地讓一個大型語言模型讀取 Issue 並嘗試回答，而是將維護者的手動修復步驟拆解為多個獨立的子代理（Subagents），並在 GitHub Actions（GitHub 提供的自動化工作流工具）的隔離環境中運行。每個代理負責一個明確的階段，彼此之間不共享單一的執行上下文，而是透過一個名為 report.md 的文件來傳遞資訊。
具體運作流程分為四個階段。首先是重現代理（Reproduction Agent），負責驗證回報的行為是否確實存在。接著由診斷代理（Diagnosis Agent）對程式碼進行插樁分析，找出問題的根源。隨後，驗證代理（Verification Agent）會檢查相關的測試案例、文件與註釋，確保診斷結果正確。最後，修復代理（Fix Agent）將重現步驟轉換為自動化測試，並在測試通過後實作解決方案。
狀態機驅動的協作模式
為了確保 AI 的輸出能被人類信任，Cloudflare 將此工作流設計為一個由 GitHub 標籤驅動的狀態機（State Machine）。當一個新 Issue 被標記為 triage needed（需要分流）時，AI 工作流才會啟動。當 AI 找到潛在修復方案後，系統不會直接提交程式碼，而是先生成一個預覽版本（Preview Release），並將分析日誌與安裝指令回覆在 Issue 中，讓回報問題的使用者先進行驗證。
只有在回報者確認修復有效並將標籤更改為 fix verified（修復已驗證）後，系統才會正式開啟一個 Pull Request（合併請求）供維護者審核。這種設計將 AI 的工作放在沙箱（Sandbox）中執行，確保人類審核者看到的結果是已經過驗證的，有效降低了 AI 產生幻覺（Hallucination）或引入新 Bug 的風險。
從工具到框架：Flue 的演進
在實作過程中，Cloudflare 發現 AI 代理的失敗往往能反映出程式碼本身的可維護性問題。例如在處理熱模組替換（Hot Module Replacement, HMR）的案例中，AI 代理反覆修改同一段條件判斷卻導致回歸錯誤，原因是該處缺乏足夠的測試。開發團隊在加入詳細的程式碼註釋後，AI 代理便能正確理解邏輯並停止錯誤修改。這證明了 AI 代理可以作為一種偵測程式碼脆弱性的訊號。
基於這次經驗，Cloudflare 將此分流工具獨立為 triagebot-action，並進一步將其背後的編排模型演進為一個名為 Flue 的開源框架。Flue 採取宣告式模型（Declarative Model），開發者只需定義代理的上下文（包括模型、技能、沙箱與指令），而不需要編寫複雜的循環邏輯。
Flue 的核心特點在於其持久化能力。它使用一種僅限追加（Append-only）的事件日誌來記錄執行歷史，這意味著即使工作流在執行過程中中斷，也能從之前的狀態恢復。在 Cloudflare 的基礎設施上，這些代理可以作為 Durable Objects（具備持久狀態與隔離存儲的物件）運行，實現真正的持久化軟體工作流。
實務意義與限制
Cloudflare 的案例展示了 AI 代理在軟體工程中的正確應用方向：將複雜任務拆解為明確的子任務，並將 AI 產出置於人類驗證的閉環之中。這種明確的系統設計（Explicit System Design）比依賴單一 AI 迴圈的抽象化更具可靠性。
然而，這類系統的成效高度依賴於環境的隔離程度與測試覆蓋率。如果程式碼缺乏自動化測試，AI 代理將難以驗證其修復方案是否正確，甚至可能在沒有察覺的情況下破壞現有功能。因此，AI 代理的引入並非取代開發者，而是將維護者從重複性的重現與驗證工作中解放，讓他們能專注於更高層次的架構設計與複雜問題的解決。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。