[AI 分享] 讓引擎管流程、讓模型管執行：AI 程式開發的 Harness 設計
摘要 : 透過確定性的流程引擎，管理 AI 開發階段、工具與門控，避免跳步並提升一致性與複用性。
內容:
當我們讓 AI 撰寫程式碼時，整個工作流程應該由誰主導？這看似是技術問題，實際上也關乎產品哲學。主流做法是將流程寫進提示詞，建議 AI 按照步驟完成任務；但建議不等於約束，AI 仍可能省略規劃、跳過測試或略過審查。
我們的產品選擇另一條路：以確定性的引擎硬性驅動流程，AI 只負責完成各個步驟中的工作。一句話概括，就是「讓引擎管流程，讓模型管執行」。
智慧體迴圈：有執行能力，卻不負責全局流程
理解這套設計，首先要認識智慧體迴圈，也就是 Agent Loop。它是 AI 程式開發助手的執行核心，運作方式是不斷循環：思考該使用什麼工具、呼叫工具，例如讀取檔案或執行命令，再觀察結果是否足夠；如果不足，就繼續下一輪。
這就像派一位員工處理複雜任務，他不是一次完成所有事情，而是逐步探索、採取行動，再根據結果調整。這個迴圈讓 AI 具備實際動手的能力，但它的主要職責是完成眼前任務，而不是管理整體流程。
我們將它稱為「執行核心」。給它任務、工具與工作說明，它就持續運作，直到任務完成。然而，它不負責判斷整個流程進行到哪一步、目前是否應該執行這件事，也不負責決定完成後要前往哪個階段。
它像是一位能力很強、卻不負責全局安排的工匠。你讓他砌牆，他可以把牆砌好，但不會主動決定現在是否應該砌牆，或砌完之後是否需要驗收。
裸迴圈的三個缺口
當一個 AI 程式開發產品只有執行核心，上層沒有流程管控時，我們稱之為「裸迴圈」。這種設計有三個主要缺口。
第一，缺乏品質門控。AI 認為工作差不多完成，就可能停止，甚至跳過測試與程式碼審查，因為系統沒有設置必須通過的關卡。
第二，缺乏流程一致性。同一個任務，AI 這次可能執行五個步驟，下次只執行三個，導致流程與結果難以預測，也難以重現。
第三，缺乏複用性。好不容易摸索出一套有效的工作方法，卻只存在於某次對話的上下文中。換個專案或會話，就難以延續，無法有效沉澱與分享。
這三個問題，都指向同一個根源：執行核心之上，缺少一個統一管理節奏與流程的角色。
提示詞是建議，不是流程約束
常見的解法，是把工作流程寫進系統提示詞，例如要求 AI 先分析需求、再規劃、接著實作，最後執行測試。
這樣做看似合理，卻仍然只是建議。AI 可能認為任務很簡單，不需要規劃就直接寫程式碼；也可能在完成程式碼後宣告任務結束，卻沒有真正執行測試。單靠提示詞，無法硬性保證它遵守每個步驟。
這就像把交通規則寫在紙條上交給司機，與在道路上設置紅綠燈和檢查站，是兩種不同的管理方式。前者依靠遵守，後者則建立實際的流程約束。我們的產品要做的，就是為 AI 工作流程裝上這些「紅綠燈」。
Harness：可插拔的工作流程引擎
Harness 可以用線束的概念理解：將原本散亂的部分，組織成有序、可控的整體。在我們的產品中，它是一套可插拔的工作流程引擎，主要負責三件事：規定任務分成哪些步驟、每一步由誰執行，以及完成後前往哪一步。
它相當於 AI 的排程中心。執行核心不再自行決定整體節奏，而是接受排程：先完成第一步，完成後回報，取得放行才能進入第二步。
這套規則可以替換。換一套 Harness，就等於換一套工作方式，像是為同一臺機器換上不同的作業指導書。
雙層架構：排程與執行各司其職
整體架構分成兩層。上層是排程中心，也就是階段狀態機，負責讀取目前階段的作業指導書、配置工具與工作手冊，以及決定完成後的去向，但不親自執行任務。
下層是執行核心，接收派發的工作，透過智慧體迴圈逐步完成，但不管理全局流程。兩層各司其職，形成清楚的分工：排程歸排程，執行歸執行。
階段 Stage：流程中的任務卡
階段是工作流程中的一站，也是整套系統的基本組成單元。每個階段都像一張任務卡，包含四項資訊。
第一是工作手冊，說明這一步的目標與做法。第二是工具箱，規定此階段允許使用哪些工具，也可以限制為只開放必要工具。第三是門控，決定完成後自動放行、等待人工確認，或依條件判斷。第四是下一站，指定完成後要前往哪個階段。
例如，產品內建的 Dev Flow 開發流程包含八個階段：梳理需求、制定規劃、撰寫程式碼、審查是否符合需求、審查程式碼品質、執行測試、沉澱知識，以及提交程式碼。每個階段都有各自的任務卡。
階段狀態機 Stage Machine：以程式邏輯決定流程
階段狀態機是整套系統的排程中心，只回答三個問題：現在執行哪個階段、完成後前往哪裡，以及是否需要停下來等待使用者。
最關鍵的設計是：排程中心具有確定性，所有流程決策由程式碼邏輯做出，而不是由 AI 決定。
即使 AI 在畫面上輸出「梳理階段完畢」，那也只是一段顯示文字，不是排程中心放行的依據。排程中心依照自身維護的狀態與規則運作，因此 AI 不能僅憑自己的判斷跳過某個階段。
即使 AI 認為審查沒有必要，也無法自行繞過關卡，因為放行權掌握在排程中心，而不是模型手中。這就是「硬驅動」：流程由系統硬性推進，而不是只透過提示詞提出建議。
門控 Gate：管理階段之間的放行
門控是階段之間的關卡，分為三種模式。
第一種是自動放行。階段完成後，立即進入下一站，不等待人工確認，適合不需要人員拍板的執行環節，例如撰寫程式碼或執行測試。它就像高速公路的 ETC 通道，符合通行要求便可繼續前進。
第二種是人工放行。階段完成後必須停下來，等使用者確認繼續才往下走，適合梳理需求與制定規劃等需要人員決策的環節。
第三種是條件放行。完成後，系統會檢查是否符合通行條件；通過才放行，有問題就攔下。這適合審查、測試等需要判斷結果是否合格的環節。因此，即使同樣是測試階段，也可以依流程需要採用不同的門控模式。
此外，系統設有連續自動跳轉的上限，避免全自動流程持續空轉，始終不將控制權交還使用者。就像高速公路不能無限延伸，流程運作到一定程度，也需要保留出口。
執行者 Runner：決定這一站由誰完成
執行者回答的是「這個階段由誰來做」，分為兩種模式。
第一種是本機執行。在主迴圈中更換工作手冊，繼續由同一個 AI 執行，就像同一位員工轉換崗位，人沒有更換，但任務與工作要求改變了。
第二種是委託執行。將整個階段打包，交給獨立的專家處理，就像聘請一位外部顧問，由他帶著自己的工具箱來完成該階段的工作。
