超越單次對話：將 AI 編碼改造成可持續執行的「狀態機」

當前的 AI 輔助編碼，儘管模型日益強大，其核心互動模式仍停留在「一次性對話」。這種類似聊天會話的工作流，在處理片段任務時效率驚人，但面對跨越多日、涉及數千行程式碼的複雜工程時，便會暴露其脆弱性——任何中斷都可能導致前功盡棄。本文主張，要讓 AI 成為真正的工程夥伴，關鍵不在於追求更長的上下文視窗或更強的單次推理，而是必須將整個開發流程重構成一個可重入、可恢復、可觀測的「狀態機」循環。這種轉變不僅是技術架構的升級，更是從「工具」邁向「系統」的思維躍遷，為 AI 處理複雜工程任務開闢新路。

為什麼現行的 AI 輔助編碼會遇到瓶頸？

我們已經習慣了與 AI 進行問答式的互動。無論是 Copilot、ChatGPT 或其他工具，它們的基礎都是一個短暫的 session。在這個 session 中，AI 憑藉上下文（context）來理解我們的意圖並生成程式碼。儘管像 Google Gemini 1.5 Pro 這樣的新模型提供了超過 100 萬個 token 的龐大上下文視窗，但这並未從根本上解決問題。

一個真實的軟體專案，其「狀態」遠比文字上下文複雜，它包含了檔案系統、依賴版本、測試環境、資料庫 schema 等等。單純擴展文字視窗，無法完整捕捉這些動態的工程狀態。更致命的是，這種 session 模式的脆弱性體現在以下幾個方面：

• 中斷即失敗： 一個長達 3 小時的複雜任務，若在第 2 小時 50 分因網路問題或任何錯誤而中斷，整個 session 的上下文與進度便可能完全遺失，使用者必須從頭來過。
• 過程不透明： AI 的「思考」過程被封裝在一個黑盒子裡。如果最終結果不符預期，我們很難追溯是哪一個環節出了問題，只能反覆調整提示詞，進行昂貴的試錯。
• 難以協作： 無狀態的 session 很難讓人類工程師在過程中介入、修正或接手。它更像是一個一次性的委託，而非一個可持續協作的流程。

這些限制使得 AI 在「輔助」層面表現優異，卻難以獨立承擔需要長期、多步驟才能完成的「工程」任務。

如何將開發流程改造成「狀態機」？以 Ralph 為例

要突破這個瓶頸，我們需要一種新的架構，將開發過程模型化為一個狀態機（State Machine）。這意味著整個流程被拆解成一系列明確的「狀態」與「轉換」。近期在 GitHub 上出現的一個實驗性專案 Ralph，就體現了這種思維。

Ralph 的目標是成為一個自主的 AI Agent 循環，它會重複執行，直到完成產品需求文件（PRD）中的所有項目。它的運作方式，正是一個典型的狀態機，其核心要素包括：

• 狀態（State）： 程式碼庫的當前狀態，由 Git 的 commit hash 精確定義。
• 輸入（Input）： PRD 中的待辦事項、測試結果、靜態分析回饋。
• 行動（Action）： AI 根據輸入，生成或修改程式碼、撰寫測試、更新文件。
• 轉換（Transition）： 每次成功的行動都會觸發一次新的 Git commit，將系統推進到下一個明確的狀態。
• 終止（Termination）： 當所有 PRD 項目都完成且所有測試通過時，循環結束。

這種模式的重點，是將模糊、連續的對話，轉化為離散、可驗證的狀態節點。每一次 commit，都是一個可供審查、回滾與恢復的檢查點。

這並非全新的概念，許多前沿的 AI Agent 研究，如奠定基礎的 ReAct (Reason and Act) 框架，都隱含著類似的循環思想。然而，將其與 Git 這樣成熟的工程系統結合，才真正賦予了它在軟體開發領域的實用價值。

這種 Agent Loop 的真正價值是什麼？

將 AI 編碼流程改造成狀態機循環，其價值並非單純地「自動化更多工作」，而是根本性地提升了長任務的強韌性（robustness）與可持續性。這也是像 Cognition Labs 的 Devin 這類 AI 工程師備受關注的原因，儘管其自主能力在 SWE-bench 基準測試中解決 13.86% 問題的表現仍有待提升，但它所展示的「任務導向循環」正是正確的方向。

這種模式帶來了幾個關鍵優勢：

1. 可恢復性（Resumability）： 任務不再是脆弱的單體。如果 Agent 在執行第 7 個步驟時失敗，我們不必從零開始。由於前 6 個步驟的狀態已由 Git commit 固化，我們可以輕易地從上一個穩定狀態恢復，修正問題後讓 Agent 繼續執行。例如，一個長達數小時的複雜任務，即使在後期中斷，也能從最近的穩定狀態快速恢復。
2. 可觀測性（Observability）： 每一次狀態轉換（commit）都是一次透明的紀錄。我們可以清楚地審查 AI 在每一步的決策與產出，理解它的「思路」，而不是面對一個巨大的、難以理解的最終程式碼塊。這對於除錯和人類監督至關重要。
3. 人機協作（Human-in-the-loop）： 當 Agent 陷入困境或做出錯誤決策時，人類工程師可以隨時介入。我們可以暫停循環，手動修改程式碼，提交一個修正的 commit，然後再讓 Agent 從這個新的人工校準過的狀態繼續。AI 從一個黑盒執行者，變成了系統中一個可被管理的組件。

總結來說，我們正在見證一個重要的範式轉移：從將 AI 視為一個「對話夥伴」，轉變為將其整合為一個「狀態化的系統組件」。未來的 AI 開發系統，可能更像是一個由 AI Agent 驅動的 CI/CD pipeline，而非一個聊天視窗。這種基於狀態機的 Agent Loop，雖然離完全取代人類工程師還很遙遠，但它將脆弱的 session 變成了可持續執行的系統，這才是 AI 真正跨過複雜工程門檻的務實之路。

延伸閱讀

• SWE-bench: Can Language Models Solve Real-World Software Engineering Problems? (arXiv)
• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv)
• LangChain Documentation on Agents (官方文件)
• Ralph: An autonomous AI agent loop (GitHub)

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。