不只是模型：Claude Code 的 Harness 如何打造自律的 AI 開發閉環

AI 寫程式的競賽已進入下半場。當大型語言模型的程式碼生成能力逐漸收斂，真正的差異化將不再只是模型本身，而是誰能更有效地將開發環境、工具鏈、回饋機制與任務脈絡整合成一個可持續運轉的閉環。Anthropic 的 Claude Code 所展示的 Harness 機制，便是一個具體而微的縮影，它揭示了 AI 如何從單純的指令執行者，進化為能自主迭代、具備初步工程紀律的開發夥伴，這也預示了未來 AI 輔助開發的關鍵演進方向。

為什麼我們需要超越「提示-生成」的框架？

自從 2021 年 GitHub Copilot 問世以來，AI 程式碼生成工具已經從單純的程式碼補全（autocompletion），演進到能理解複雜需求、生成完整函式甚至整個應用程式框架的階段。最新的模型如 Anthropic 的 Claude 3.5 Sonnet，在 HumanEval 這類標準測試集上的 pass@1 準確率已能達到 92.0%，展現了驚人的程式碼理解與生成能力。然而，這種「提示-生成」（Prompt-Generate）的互動模式，在本質上仍是單向、無狀態的。

開發者給出指令，AI 回傳程式碼。這段程式碼是否能在真實環境中運行？是否滿足所有邊界條件？是否符合專案既有的編碼風格與測試標準？這些問題，AI 本身無法獨立驗證。開發者必須手動將程式碼複製到本地環境，運行測試，解讀錯誤訊息，然後再把修正後的脈絡重新輸入給 AI。這個過程不僅繁瑣，也中斷了開發的「心流」（flow），讓 AI 淪為一個功能強大但被動的查詢工具。

真正的軟體開發是一個包含「構想、實作、測試、修正」的循環過程。若要讓 AI 成為更深度的開發夥伴，關鍵就在於賦予它執行這個循環的能力。這不僅僅是提升模型智商的問題，更是工程方法論的挑戰：如何為 AI 打造一個能感知環境、使用工具、接收回饋並自主迭代的工作場域？

Harness 究竟是什麼？它如何為 AI 打造結構化的開發環境？

Anthropic 在其開發者工具 Claude Code 中提出的「Harness」機制，正是對上述問題的一個系統性回答。Harness 的核心概念是「將環境上下文結構化」，為 AI Agent 提供一個標準化、可預測的沙盒（sandbox）來執行開發任務。

當我們透過 /setup-harness 指令觸發這個機制時，Claude Code 會自動分析當前專案的需求，生成一個包含測試框架、相依性管理、執行腳本的臨時環境。這個環境就像一個為特定任務量身打造的「安全帶」（Harness 的原意），確保 AI 的所有操作都在一個受控的範圍內進行。這個概念與傳統軟體工程中的「測試工具」（Test Harness）一脈相承，但應用對象從程式碼變成了 AI Agent 本身。

在 Claude Code 的設計中，Harness 與 Skill（技能）及 Subagent（子代理）有明確的分工，共同構成一個協作體系：

• Harness：定義任務的「場域」。它負責設定測試環境、管理檔案系統、執行程式碼，並將成功或失敗的結果回饋給 AI。它本身不包含解決問題的邏輯，而是提供一個驗證邏輯的標準化舞台。
• Skill：定義 AI 可以使用的「工具」。這些是原子化的、可重用的函式或 API，例如讀取檔案、執行終端機指令、呼叫外部服務等。Skill 讓 AI 的能力具象化，也讓其行為更容易被追蹤與除錯。
• Subagent：專門處理特定子任務的「專家」。例如，一個 Subagent 可能專門負責撰寫測試案例，另一個則專門負責重構程式碼。主 AI Agent 可以將複雜任務拆解並分派給這些專家。

這種分層設計，讓 AI 的工作流程從混亂的自然語言互動，轉變為結構化的「任務拆解 -> 工具調用 -> 環境驗證」流程。這不僅提升了可靠性，也為實現更複雜的自主開發奠定了基礎，呼應了如微軟 AutoGen 等多 Agent 協作框架的設計理念。

一個自律的開發循環如何運作？

有了 Harness 機制，一個自主的開發循環便得以實現。整個流程大致如下：

1. 目標設定：開發者提出一個高階目標，例如「實作一個函式，計算兩個日期間的工作日天數，並撰寫測試案例」。
2. 環境建構：AI Agent 理解目標後，執行 /setup-harness。系統會自動建立一個包含測試框架（如 Jest 或 Pytest）的目錄結構與設定檔。
3. 程式碼生成：AI Agent 在 Harness 提供的檔案結構中，生成功能的實作程式碼（例如 workday.js）與測試案例（workday.test.js）。
4. 執行與驗證：AI Agent 透過 Skill 呼叫 Harness 內建的測試指令（例如 npm test）。Harness 會在沙盒中執行測試，並捕捉 stdout/stderr 的輸出。
5. 回饋與迭代：Harness 將測試結果（例如「2 個測試通過，1 個失敗」以及詳細的錯誤訊息）回傳給 AI Agent。Agent 會分析失敗原因，並針對性地修改程式碼。
6. 循環至成功：AI 會重複步驟 3 到 5，直到所有測試案例都通過為止。最後，它會向開發者回報任務完成，並提交最終的程式碼。

這種模式的轉變，意義在於將「驗證責任」從人類開發者轉移到 AI 系統內部。AI 不再只是程式碼的生產者，也成為了品質的第一道把關者。

這個閉環徹底改變了 AI 在開發流程中的角色。它從一個需要人類不斷「微觀管理」的實習生，轉變為一個可以交付「可驗證工作成果」的初級工程師。這讓我們看到了超越單純程式碼生成，邁向真正「自主軟體工程」（Autonomous Software Engineering）的可能性，這也是如 Devin 等新創 AI 工程師專案試圖達成的目標。

當然，目前的 Harness 機制仍有其侷限。它主要適用於目標明確、可被單元測試覆蓋的任務。對於需要複雜系統整合測試、UI/UX 驗證，或涉及大量專有領域知識的開發工作，仍需要人類的深度介入。

但它所建立的「環境-工具-回饋」框架，無疑是正確的方向。未來的 AI coding 工具，競爭的焦點將不再是誰能多寫幾行程式碼，而是誰能為 AI 建立更完善、更高效的開發與驗證閉環。這不僅是技術問題，更是對軟體工程流程的重新思考與設計。

延伸閱讀

• Claude Code のハーネスとは何か (zenn.dev)
• Building with Claude - Official Documentation
• Code Llama: Open Foundation Models for Code (arXiv)

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。