把一個語言模型接上聊天介面，它可以回答問題。讓它呼叫工具，它開始能讀檔、執行程式、查資料，甚至修改一個專案。

接下來才是比較麻煩的問題：

它怎麼知道該讀哪些資料、能動哪些資源、失敗後要不要重試、何時必須停下，以及拿什麼證明任務真的完成？

模型只能回答其中一部分。

假設你要求一個 Coding Agent 修正結帳頁面的錯誤。模型可能看得懂錯誤訊息，也可能推得出修法，但一個能交付的系統還要處理更多事情：找到正確的 Repository、建立隔離的 Workspace、讀取專案規範、限制可用憑證、執行測試、判斷測試結果、保存進度、產生 Diff、等待必要批准，最後留下可追蹤的完成證據。

模型負責推理與選擇。圍繞模型、協調這些執行條件與控制機制的系統，就是這個系列要談的 Harness。

Model、Harness 與 Agent Product 的責任邊界

Figure 1-1｜模型提供推理與選擇能力；Harness 提供執行環境、限制、回饋與驗證。

本文採用的 Harness 工作定義

本文把 Harness 定義為：圍繞 LLM 或 Agent Runtime 的執行與治理系統。

它不是單純放在模型前面的一層代理。它把模型的推理與選擇接進一個可執行的工作環境，並協調上下文（Context）、工具、狀態、政策、驗證與觀測。

一套 Harness 通常要處理以下責任：

  • 組裝這一輪模型需要看到的 Context
  • 提供工具，同時限制可用工具與參數範圍
  • 控制多步驟執行、重試、停止與人工批准
  • 保存任務狀態、檢查點（Checkpoint）與可恢復進度
  • 管理身份、權限、時間、成本與資料邊界
  • 驗證產出與實際副作用
  • 記錄可以除錯、重播與評估的執行軌跡（Trace）

這個定義故意保留一定寬度。不同產品會把 Harness 的邊界切在不同位置。

某些宿主已經提供聊天介面、Agent Loop、工具執行與 Session；開發者只需要在外部 API、Repository 規則或 CI 補上工作負載需要的控制。另一種情況是自建後端，模型 API 只是其中一個元件，Context、Tool、State、Verifier 與 Trace 都由自己的 Runtime 管理。

OpenAI 對 Codex 的不同工程文章也呈現出這種邊界差異：有時 Harness 指核心 Agent Loop 與執行邏輯，有時討論的是讓 Agent 能理解、使用並遵守的工具與環境結構。[1][2]

因此，討論 Harness 前要先問清楚：這裡包住的是裸模型、Agent Runtime，還是一個已經能自行呼叫工具的 Coding Agent？

邊界可以不同，責任不能憑空消失。

Model、Harness 與 Agent Product 各自負責什麼？

可以先用一個心智模型定位：

Agent Product Outcome = Model × Harness × Task

這不是用來計算分數的數學公式。它只是在提醒我們，產品結果同時受三件事影響：模型本身、模型所處的 Harness，以及任務是否適合這種執行方式。

Model 提供推理與選擇能力

模型通常可以：

  • 理解自然語言與程式碼
  • 根據 Context 推理與生成
  • 拆解問題並提出下一步
  • 在候選工具中做選擇
  • 根據新觀察重新規劃

模型可以提出「接下來該做什麼」，但它不天然擁有資料庫權限，也不會自動取得正確檔案、保存持久狀態（Durable State），或讓一次刪除操作變得可逆。

Harness 提供工作條件

Harness 負責把模型放進一個可以工作、也可以被限制的環境：

  • 哪些資訊可被看見
  • 哪些工具可以呼叫
  • 哪些參數與資源被允許
  • 哪些狀態由系統保存
  • 哪些失敗可以重試
  • 哪些動作需要批准
  • 哪個驗證器（Verifier）有權判定通過
  • 哪些事件必須被記錄

其中一部分是行動前的前饋控制（Feedforward Control），也就是提供規則、結構與能力；另一部分是行動後的回饋控制（Feedback Control），例如測試、Lint、Log、Browser Check、Review Agent 或其他感測器（Sensor）。

只有規則而沒有回饋，系統無法確認規則是否真的被滿足。只有回饋而沒有前置結構，Agent 會一直付學費，重犯同一類錯誤。[3]

Harness 不能替模型製造不存在的能力

Harness 能改善 Context、工具、回饋與限制，卻不能替模型補出原本不存在的領域推理能力。

如果模型無法理解任務，增加更多 if/else、流程節點或 Prompt，往往只會把錯誤包得更複雜。Harness 改善的是能力被使用的條件，不是憑空製造能力。

同樣地，模型說「我已確認結果正確」，也不能自動變成外部證據。自我評價可以作為一個訊號，通過與否仍要交給測試、Policy、Verifier 或明確的人類批准。

Agent Product 承擔完整結果

使用者接觸的通常是一個由模型、Harness、資料與產品介面共同構成的 Agent Product。

同一個模型換到不同 Harness，可能拿到不同的 Context、工具、權限與驗證流程；同一套 Harness 換了模型，也可能因規劃能力、工具使用習慣或錯誤恢復能力不同而改變結果。

模型排行榜只能描述特定條件下的模型表現。它無法替產品回答 Context 是否正確、工具是否可靠、權限是否安全，以及完成結果能否被驗證。

Harness 位於系統的哪裡？

Harness 通常存在於應用程式後端、Agent Runtime，或宿主產品與業務系統之間。

最常見的自建形式可以先簡化成：

User
  ↓
Web / App / CLI
  ↓
Backend Harness
  ├── Context / RAG
  ├── Tools / MCP / APIs
  ├── State / Checkpoint
  ├── Policy / Approval
  ├── Verifier
  └── Trace / Eval
  ↓
LLM API or Local Model

這是一張概念位置圖，不是唯一或標準的部署架構。

若使用 ChatGPT、Claude Code、Codex 或其他宿主，宿主本身已經提供部分 Harness。你的外部 API、Repository 規則、CI、權限系統與驗證工具，則形成針對自身工作負載的另一層 Harness。

談產品架構前，至少要先界定三件事：

  1. 這裡包住的是裸模型、Agent Runtime，還是已經具有工具迴圈的 Agent？
  2. 哪些責任由宿主承擔，哪些由產品團隊承擔？
  3. 誰持有唯一可信狀態（Canonical State），誰有最終批准與通過權（Pass Authority）？

沒有先界定範圍，很容易把內建 Harness、外層 User Harness 和完整產品平台混成一團。

Prompt、Modelfile、Framework 都只覆蓋一部分

Prompt、Modelfile、Framework 與 Harness 的範圍比較

Figure 1-2｜幾個常被混用的名詞，回答的是不同層級的問題。

System Prompt

System Prompt 主要提供角色、規則、格式與行為指引。它可以提高模型選對行動的機率，卻不應被當成硬性限制的唯一執行機制。

例如「最多重試三次」若只寫在 Prompt，模型可能誤讀、在長 Context 中被其他資訊稀釋，或根本無法對外部副作用形成強制約束。

可靠的做法是由 Runtime 計數，第三次失敗後停止、切換恢復路徑，或升級給人處理。

Modelfile 或 Model Config

Modelfile 回答模型怎麼被設定與封裝，例如 Base Model、System Prompt、Temperature、Context Window 或 Adapter。

它可以成為 Harness 的設定來源，但通常不負責實際工具執行、持久狀態、權限、Checkpoint、Verifier 與 Trace。把引擎參數調好，不等於車上已經有方向盤、煞車、導航與儀表。

Tool Calling

Tool Calling 讓模型提出結構化的工具請求。

完整系統還要決定：

  • 工具是否對這個任務可見
  • 參數是否合法
  • 目前身份是否有權執行
  • 失敗後要重試、降級還是停止
  • 工具造成的副作用要如何驗證

Tool Calling 是能力入口，治理與執行仍由 Harness 承擔。

Agent Framework

Agent Framework 可以提供 Agent Loop、Graph、Memory、Tool Registry、State Store、Checkpoint、Human-in-the-loop 與 Trace 等元件，甚至直接實作部分 Runtime。

產品仍要根據工作負載定義租戶隔離、成本上限、資料政策、完成標準與事故恢復。這些責任不會因為選了一套 Framework 就自動完成。

Anthropic 在討論 Agent 架構時，將 Workflow 與 Agent 分開：Workflow 依預先定義的程式路徑協調模型與工具；Agent 讓模型動態決定流程與工具使用。兩者都可能存在於 Harness 之內，差別在於哪些決策交給程式，哪些交給模型。[4]

RAG、Workflow 與 Orchestrator

RAG 解決檢索與 Context 供應；Workflow 定義較可預期的執行路徑；Orchestrator 負責下一步、路由、Handoff 與停止。

它們都可能是 Harness 的一部分，但沒有任何一項單獨涵蓋整個任務的權限、狀態、恢復、驗證與觀測。

概念主要回答的問題
System Prompt模型這一輪應遵循哪些指引？
Modelfile / Model Config模型如何被設定與封裝？
Tool Calling模型如何提出一項外部操作？
RAG要從哪些來源取回哪些內容？
Workflow / Orchestration下一步做什麼，失敗往哪走？
Agent Framework用哪些抽象與元件搭建系統？
Harness整個任務如何在限制內被執行、驗證與恢復？

判斷一套 Agent 系統時，可以先找誰持有 State、Permission 與 Pass Authority，再看它用了多少模型、工具與流程節點。功能很多，不代表 Harness 完整；責任沒有主人，系統仍然會在失敗時裂開。

模型越強，為什麼 Harness 沒有消失？

模型能力提升會擴大可處理的任務範圍，同時也會擴大行動空間（Action Space）。Agent 能讀更多資料、呼叫更多工具、執行更長流程後，系統要處理的問題反而更多。

以下不是業界統一的七項標準，而是本文用來整理 Agent 系統複雜度的七個觀察角度。

1. Context 預算壓力

完成一個局部任務，可能需要讀取多個模組、服務、設定、歷史決策與外部文件。Context 太少會漏掉限制，全部塞入又會淹沒當前任務。

2. 探索如何收斂

Agent 可以探索 Repository、文件與工具，但探索需要入口、回饋與停止條件。否則「自主」很容易退化成無界漫遊。

3. 隱性的 Runtime State

一次看似局部的修改，可能喚醒全域狀態、外部服務、租戶資料與隱性副作用。模型看得到程式碼，不代表它已掌握所有執行期狀態（Runtime State）。

4. 無法取得或無法說清楚的知識

正確做法可能只存在工程師腦中、Slack 討論、事故記憶或過期文件。對執行中的 Agent 而言，無法取得的知識幾乎等於不存在。

還有一類問題不是知識完全不存在，而是需求、例外與完成標準很難被穩定說清楚。這可以視為系統的可提示性（Promptability）：團隊知道怎麼做，不代表已經能把判斷轉成 Agent 可執行的規格。

OpenAI 將 Repository Knowledge 做成可索引、可版本化、可檢查的 System of Record，背後就是這個問題。[2]

5. 驗證成本

產生一個答案或 Patch 很快，證明它正確往往更貴。

需要跑哪些測試、觀察哪些 Log、重播哪些 User Journey，不能每次都臨時交給模型自己決定全部標準。

6. 目標漂移

多輪工作會累積新線索、錯誤與中間決策。若沒有 Task Contract、Progress State 與停止條件，Agent 可能忙了很久，卻離原始目標愈來愈遠。

7. 副作用風險

讀取錯誤答案和執行錯誤操作不是同一個風險等級。

當 Agent 可以寄信、改資料、部署或付款，身份、批准、冪等性、回滾與稽核都必須由系統承擔。

這些問題無法只靠更長的 Prompt 解決。Prompt 影響模型如何選擇；程式、Policy 與執行環境才有能力強制邊界。

Harnessability：系統是否容易被 Agent 駕馭

討論 Agent 表現時，我們很容易把失敗歸因於模型。另一個問題同樣重要：這套系統是否提供足夠清楚的結構與回饋，讓 Agent 能理解、局部修改、快速驗證，失敗後還能可靠恢復？

這裡要看的不是模型分數，而是系統的 Harnessability。

高 Harnessability 的系統通常具備：

  • 清楚而穩定的模組邊界與 Ownership
  • 可重現的 Setup、Build、Test 與 Runtime
  • 明確的 Input、Output、Side Effect 與完成條件
  • 可導航的 Repository Map 與可取得的 System of Record
  • 可局部執行的測試、快速 Sensor 與可診斷的錯誤訊息
  • 可隔離、回滾、重播與恢復的變更路徑

Harnessability 也取決於任務能否被封裝。若一項工作無法限制 Context、權限與副作用，也沒有明確 Input、Output 和完成證據，它就很難成為可靠的 Agent 工作單元。這種可封裝性可以稱為 Capsuleability。

型別系統、Schema、Lint、標準專案結構與統一 Migration，都可能成為環境裡的隱性助力（Ambient Affordances）。它們不是專門為 AI 新增的華麗功能，卻能縮小搜尋空間，讓錯誤更早暴露。MartinFowler.com 的 Harness Engineering 文章也把這些環境特性視為 Harnessability 的來源。[3]

兩個很直接的壓力測試是：

  1. Agent 能否在不改變外部行為的情況下完成局部重構？
  2. Agent 能否只靠現有規格重建核心行為，並用外部測試證明一致？

兩項都做不到時，問題往往不只是模型能力，而是行為邊界、隱性知識或驗證基礎還不夠清楚。

Harnessability 不適合被硬壓成一個漂亮總分。更實用的結果是列出高風險維度、支持證據、受影響的任務類型，以及需要補上的 Sensor、文件、邊界或恢復機制。

有些專案此刻不適合高自主 Agent。先補 Repository Map、測試、模組邊界與可恢復執行，可能比換一個更大的模型有效。

人類的工作上移到 Steering Control Plane

從逐步操作到 Human Steering Control Plane

Figure 1-3｜人類從每一步同步操作，轉向定義意圖、邊界、Sensor、任務組合與演化方向。

Agent 承擔更多執行工作，不代表人類退出系統。人類工作的重心會從逐步操作，上移到控制平面（Steering Control Plane）。

控制面責任人類要決定什麼
意圖（Intent）哪個問題值得做、優先級、Trade-off，以及可驗收結果
邊界（Boundaries）哪些資源可存取、哪些動作需批准、哪些狀態轉移必須由程式控制
感測與驗證（Sensors）要測量什麼、哪些測試可信，以及目前看不到哪些 Failure Mode
任務組合（Task Portfolio）哪些工作交給人、Agent 或混合流程，以及如何控制並行量
系統演化（Evolution）哪些重複錯誤要升級成文件、工具、測試、Policy 或架構約束

控制平面的重點不只是「人還在不在」，而是誰持有最終 Authority。

人類不必親自檢查每一步，但必須決定哪些測試具有 Pass Authority、哪些判斷需要抽驗，以及系統在什麼條件下必須停止或升級處理。

高風險、不可逆操作仍然需要批准閘門（Approval Gate）。一般進度則應記錄成持久事件（Durable Event），留到自然 Checkpoint 批次處理。

Mitchell Hashimoto 描述自己的 Agent 工作方式時，特別強調由人決定何時查看背景 Agent，而不是讓通知反過來切碎人的注意力。[5] Anthropic 對實際 Agent 使用的研究也觀察到，較有經驗的使用者一方面更常允許 Agent 自主執行，另一方面也更常在必要時主動中斷。[6]

監督仍然存在，只是從逐步批准移到邊界、證據與例外處理。

先用五個原則檢查 Harness 設計

後面的文章會逐一展開具體架構。Part 01 先保留五個會反覆使用的原則：

  • Constraint-first：先定義身份、資源、工具、資料流、時間、成本與批准條件，再決定開放多少自主性。
  • Verifiability：重要行動必須留下外部證據。模型可以回報完成，Pass Authority 應掌握在測試、Verifier、Policy 或明確的人類 Gate 手上。
  • Progressive trust：權限依任務風險與已有證據分級，不必在「完全自動」與「每一步都問人」之間二選一。
  • Design for failure：模型、工具、網路、資料與外部服務都可能失敗。Timeout、Retry、Checkpoint、Fallback、Compensation 與 Escalation 要在失敗前設計。
  • Agent ergonomics：Tool Schema、錯誤訊息、Context 與執行入口，也是給 Agent 使用的介面。資訊密度與可操作性會影響結果，但便利性不能取代安全與驗證。

用結帳頁案例走一次

回到開頭的結帳頁錯誤，可以把三層責任拆開：

Model

  • 閱讀錯誤訊息與相關程式碼
  • 推測優惠券狀態與付款狀態的更新順序可能有問題
  • 提出修改方案
  • 根據測試結果調整 Patch

Harness

  • 定位正確的 Repository 與 Branch
  • 建立隔離 Workspace
  • 載入專案規範與相關模組
  • 只提供必要的測試憑證
  • 限制不可存取 Production Database
  • 執行單元測試、整合測試與 Browser Journey
  • 保存 Checkpoint、Diff、Log 與測試證據
  • 在高風險操作前要求批准

Task Contract

  • 修正重複扣款問題
  • 不更換付款供應商
  • 不修改無關模組
  • 相關測試必須通過
  • 結帳主流程不得出現 Regression
  • 完成時要附上可重播的驗證證據

Prompt 可以提醒 Agent「不要存取 Production Database」。真正的硬限制，是 Runtime 根本不提供該憑證，Policy 在工具執行前拒絕不允許的操作，驗證流程再確認沒有產生越界副作用。

這就是 Harness 與單純提示工程的差別。

一個可用的判斷方式

看到一個新的 Agent 產品或 Framework 時，可以先問七個問題：

  1. 誰組裝模型每一輪看到的 Context？
  2. 誰決定可用工具、權限與資料範圍？
  3. 誰保存 Canonical State 與 Checkpoint？
  4. 誰控制 Retry、Timeout、停止與人工批准？
  5. 誰驗證產出和實際副作用？
  6. 誰記錄 Trace、成本與錯誤證據？
  7. 模型、工具或 Session 失敗後，誰負責恢復？

若答案散落在 Prompt、前端狀態、幾支腳本與人的記憶裡，系統不是沒有 Harness。它只是有一套隱形、分裂，而且很難稽核的 Harness。

理論轉實作：Part 01 檢查表

  • 團隊能用一句話說清楚目前討論的 Harness 邊界。
  • 硬性限制由 Runtime、Policy 或執行環境強制，不只存在於 Prompt。
  • Canonical State、Pass Authority 與恢復責任都有明確主人。
  • 重要任務具有可觀察、可重播的外部完成證據。
  • 重複失敗會被提升成 Guide、Sensor、Tool、Policy 或架構約束。

Part 02 會把這些責任攤成一張完整架構圖，進一步處理 Request Boundary、Policy、Canonical State、Controller、Context、Capabilities、Verifier、Persistence、Observability 與 Client Protocol 的位置。

References

  1. OpenAI, Unrolling the Codex agent loop, 23 January 2026.
  2. OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 February 2026.
  3. Birgitta Böckeler, MartinFowler.com, Harness engineering for coding agent users, 2 April 2026.
  4. Anthropic, Building effective agents, 19 December 2024.
  5. Mitchell Hashimoto, My AI Adoption Journey, 5 February 2026.
  6. Anthropic, Measuring AI agent autonomy in practice, 18 February 2026.