Qoder 如何將 Harness Engineering 融入專家模式
競爭格局已變
上個月，OpenAI 發布了《Harness Engineering：在 Agent 優先的世界中利用 Codex》。其主要成果是：3 名工程師（後來增加到 7 名）在五個月內交付了一個實際產品，且沒有手寫任何一行程式碼。一百萬行程式碼。大約 1,500 個 pull request。所有這些都由 Agent 驅動。
大約在同一時間，Stripe、Ramp 和 Coinbase 公開了他們各自程式撰寫Agent系統的內部運作方式。
這表明：競爭優勢已從「模型能力」轉移到模型之外的一切。即 Harness Engineering。
什麼是 Harness Engineering？一個簡單的類比：
模型 = CPU（原始運算能力）
Context Window = RAM（有限的工作記憶體）
Agent Harness = 作業系統（管理上下文、啟動常式、標準驅動程式）
Agent = 應用程式（在作業系統上執行）
Harness 位於 Agent Framework 之上。Framework 提供建構區塊：工具呼叫、Agent迴圈。Harness 則提供其餘部分。Prompt預設值。標準化工具呼叫。生命週期掛鉤。以及你在生產環境中實際需要的能力：規劃、檔案系統存取、子Agent協調、驗證迴圈。
Harness Engineering = AI Agents 的控制系統設計。目標：建構基礎設施，使 Agent 能夠在長時間執行的迭代中持續撰寫正確的程式碼，並且能夠被稽核、回溯和擴展。
產業現況
Harness Engineering 已在頂尖工程組織中投入生產：
Stripe 分叉了 Block 的開源 Agent Goose，並建構了 Blueprint，這是一個將確定性節點與 Agent任務節點交替使用的狀態機。他們每週合併 1,300 多個完全由 Agent 撰寫的 PR。
Shopify 開源了 Roast，這是一個將 AI 步驟與確定性程式碼交錯的工作流程框架。
Ramp 在 OpenCode 之上建構了 Inspect，在 Modal 沙盒中以平行執行方式運行會話。他們合併的 PR 中有 30% 現在是由 Agent 撰寫的。
Coinbase 從頭開始建構了 Cloudbot，將 PR 審查週期從 150 小時壓縮到 15 小時。
OpenAI 將「零手寫程式碼」推向百萬行規模，使用 Codex 驅動整個產品迭代。
這些團隊都解決了實際問題。沙盒隔離。上下文預載入。確定性協調。但它們都共享一個結構性限制：Agent 仍然是單體式的。一個模型實例、一個 Context Window、一個執行路徑，從頭到尾。
單Agent Harness 的五個結構性限制
隨著任務複雜度的增加，會浮現五個限制：
Context Window 的零和遊戲。研究、程式撰寫、測試和審查上下文都爭奪同一個視窗。任務越複雜，資訊密度越低。
角色切換的認知負擔。一個 Agent 不斷在架構研究、實作和測試執行之間切換，就像要求一個人同時擔任 Tech Lead、SWE、QA 和程式碼審查員一樣。在實踐中表現不佳。
長執行鏈中的漂移。任務鏈越長，偏離原始目標的可能性越高。如果沒有外部檢查點，錯誤會傳播並累積。
缺乏功能正確性驗證。目前的實踐側重於內部品質和一致性，但在驗證產品是否實際運作方面投資不足。程式碼庫可能架構清晰、無 lint 錯誤且文件完善，但業務邏輯錯誤且使用者流程中斷。
終端執行風險。當 Agent 運行 shell 指令時，一個錯誤的指令可能會造成不可逆的損害。大多數 Harness 系統依賴黑名單或確認對話框。黑名單很容易繞過。確認對話框會中斷流程，而使用者會盲目點擊它們。
如果 Harness Engineering 意味著「從期望行為反向設計系統」，那麼當我們希望 Agent 像工程團隊一樣協作時，Harness 需要從包裝單一模型演變為組織一個團隊。
我們建構了 Experts Mode 來解決這五個問題。在內部基準測試中，它的得分比單Agent模式高 67%，而成本不到三分之二。本文的其餘部分將介紹這個數字背後的架構。
Qoder 的 Harness Engineering：Experts Mode
上述五個問題對應到 Qoder Experts Mode 中的五種機制：
除了這五個之外，我們還在兩個方向上進一步推進：跨模型排程將每個專家與最佳模型匹配，而自我演化讓系統從每次執行中累積經驗。
1. 協調與執行分離
領導者負責協調。它從不實作。它接收使用者需求、分解任務、管理依賴關係、追蹤進度並報告結果。想像一下 Tech Lead 和領域工程師。從 Harness Engineering 的角度來看，領導者是一個元Harness：它管理一組專業化 Agent Harness，每個 Harness 都有自己的工具集、上下文策略和執行限制。
2. 非同步平行處理：DAG 驅動的任務協調
所有 SWE Agent 預設都非同步平行執行。當領導者建立專家任務時，系統不會阻塞。依賴關係形成一個輕量級 DAG：「實作後端API」和「建構前端頁面」平行執行；「整合測試」等待兩者完成。每個專家都在自己隔離的 Context Window 中工作，因此零和問題消失了。
3. 星狀拓撲：集中式協調
SWE Agent 不直接通訊。所有協調都透過領導者進行。我們早期考慮過點對點通訊，但後來拒絕了。當 Agent 彼此通訊時，沒有人擁有完整的全局。兩個專家可能會做出矛盾的決策，而沒有人注意到。隨著團隊的成長，追蹤所有成對連接的狀態會呈指數級困難。以領導者為中心的星狀拓撲避免了所有這些問題。使用者也在協調路徑中：他們可以隨時插入新指令，領導者會在下一個週期中接收它們。
4. 專業化角色：每個專家都是自己的 Harness
這是對最終輸出品質影響最大的設計選擇。每個專家都是一個獨立的 Harness，針對特定任務類型進行調整。它們擁有不同的工具集、不同的上下文注入策略、不同的執行限制。我們做的不是更換系統 Prompt。整個 Harness 都不同。
每個專家的 Context Window 只包含與其角色相關的資訊。這就是我們處理 Context Rot 的方式。角色隔離從源頭上消除了上下文競爭，這比我們嘗試過的任何壓縮策略都更有效。
5. 跨模型排程：Harness 層的模型協調
單Agent系統將你鎖定在一個模型上處理所有事情。研究需要強大的推理能力。程式撰寫需要強大的程式碼生成能力。瀏覽器驗證需要視覺理解。這些能力在不同模型之間差異很大。由於每個專家獨立運行，每個專家都可以使用不同的模型：
研究專家：最強大的推理模型，用於對搜尋結果進行判斷和綜合
開發專家：最佳程式碼生成模型
瀏覽器專家：多模態模型，並為簡單驗證任務提供輕量級備用方案
審查專家：對安全和效能問題最敏感的模型
領導者將任務類型與模型能力匹配，並優化整體結果。這使得品質和成本能夠同時提高：精確的模型與任務匹配避免了為特定子任務中不需要的能力付費。
在我們的內部基準測試中：相較於 Agent Mode，品質高出 67%；相較於 Claude Code Agent Teams，品質高出 16%，而成本不到三分之二。
6. 功能正確性驗證：彌補行業差距
大多數 Harness 系統可以告訴你程式碼是否整潔。更少有系統能告訴你產品是否實際運作。我們為此專門建構了三個驗證專家：
瀏覽器專家在真實瀏覽器中針對真實使用者流程執行 E2E 驗證。它檢查互動流程、頁面渲染和視覺迴歸，達到靜態分析和單元測試無法達到的水準。
QA 專家使用變更感知上下文機制，將驗證範圍限定在實際受當前變更影響的程式碼，而不是泛泛地執行所有測試。
程式碼審查專家執行語義差異 + 呼叫鏈分析，以捕捉程式碼變更單獨看起來沒問題，但在呼叫圖中其他地方引入副作用的情況。
領導者將這三者與執行鏈內聯排程。驗證在程式撰寫完成後立即觸發，因此錯誤在傳播到下游任務之前就被捕獲。
7. 自我演化：從靜態 Harness 到動態學習系統
傳統的 Harness 系統是靜態的。你配置它們一次，它們就保持不變，直到有人手動更新它們。我們想要的是越用越好的東西。
Qoder Experts 引入了任務級技能提取。當系統檢測到更正、它從中恢復的失敗或明確的使用者指令時，領導者和每個 SWE Agent 都會獨立地從其領域中提取可重複使用的技能。程式撰寫專家提取實作模式。驗證專家提取檢查策略。審查專家提取審查啟發法。
這些技能儲存在記憶系統中，並在出現類似任務時自動回溯。隨著時間的推移，系統不再犯它已經從中學習過的錯誤。這個迴圈（任務完成、技能提取、記憶鞏固、技能回溯、直接成功）將靜態 Harness 轉變為真正改進的系統。
8. 終端執行安全：多平台沙盒和智慧攔截
撰寫程式碼只完成了一半的工作。執行程式碼才是風險實際存在的地方。第一個問題是解析。Shell 語法在不同作業系統之間差異巨大：Bash 反引號巢狀、PowerShell 管道語法、Cmd 特殊字元。我們為每個 shell（PowerShell、Bash/Zsh、Cmd）建構了獨立的 AST 解析器，它們穿透指令巢狀，以識別每個實際執行的子指令。例如，$(rm -rf /) 嵌入在一個看似無害的外部指令中：我們的解析器會提取 rm 並將其標記為高風險。
解析後，指令會經過三個獨立的風險檢查。硬編碼黑名單會捕捉已知的危險指令（rm -rf, format, dd if=）。規則引擎會檢測單獨無害但組合起來危險的指令與參數組合。而 LLM 語義分析層會讀取指令意圖，以捕捉前兩個層遺漏的內容。LLM 層是附加的：即使它失敗了，黑名單和規則引擎仍然會獨立攔截。任何單一觸發器都會阻止執行。
即使通過所有三個檢查的指令也會在作業系統級沙盒中運行：
原則是：首先隔離，然後在邊界內授予完整權限。Agent 在沙盒內自由操作，但其爆炸半徑受到限制。Stripe 使用他們的 devboxes（「牛群，而非寵物」）做了類似的事情，但這需要雲端基礎設施。我們將其作為一種本地產品能力提供，可在開發者自己的機器上運作。
Harness 的複雜性不應由使用者承擔
軟體工程的嚴謹性並未消失。它只是遷移了。從函數實作到系統限制。從手動審查到自動化治理。
你不應該需要自己分叉一個開源 Agent、設定沙盒、設計 Blueprint、撰寫 500 個規則檔案，並實作多平台安全機制。
在 Qoder 中試用 Experts Mode (Beta)。多個專業化專家，一個任務，零手把手指導。
參考資料
Harness engineering: leveraging Codex in an agent-first world, OpenAI
Minions: Stripe's one-shot, end-to-end coding agents, Stripe
Minions Part 2, Stripe
Introducing Roast: Structured AI workflows made easy, Shopify
Why We Built Our Own Background Agent, Ramp
How Coinbase scaled AI to 1,000+ engineers | Chintan Turakhia, Coinbase