AI Agent Harness 是什麼？模型之外的工具、記憶與驗收怎麼組起來

AI Agent Harness 概念圖：模型、任務脈絡、外部工具、隔離執行環境與驗收迴圈的關係
操作示意圖／非官方介面截圖：AI Agent Harness 把模型放進有工具、狀態、環境與驗收規則的工作迴圈。

AI Agent Harness 是什麼？模型之外的工具、記憶與驗收怎麼組起來

如果你把 AI Agent 想成一個會自己呼叫工具的模型，做到長任務時很快會發現，真正麻煩的不是模型會不會回答，而是它下一輪還看不看得到必要資料、能不能在正確的環境裡動手，以及做完後誰來確認結果。AI Agent Harness 要處理的，正是這一層。

先講本文的判斷：AI Agent Harness 可以先理解成「包住模型的執行層」。它把任務規格、Context、工具、權限、記憶、執行環境、狀態、觀測紀錄和驗收方式組成一個可以重複跑的迴圈。這個詞的用處，在於把原本散在 Prompt、腳本、工具設定和人工檢查裡的責任攤出來。

這個詞目前沒有單一組織核准的通用標準定義。OpenAI 和 Anthropic 的工程文章都使用 Harness 來描述長任務的環境、工具調度、知識管理、回饋與驗收；2026 年一篇 arXiv 論文則提出更完整的研究框架。下文會把這些第一手材料分開說，再整理成一套適合日常工作的判斷方法。文章查證截至 2026-09-10，沒有把任何一家公司的內部案例寫成普遍性能保證。

文章目錄

先講結論：AI Agent Harness 是模型周圍的執行層

已查證的來源怎麼使用 Harness 這個詞

OpenAI 在 2026 年 2 月的工程文章中，描述一個由 Codex agents 建立的內部產品。他們談到的重點放在執行環境：讓每個 worktree 都能啟動應用程式、把 DOM、截圖、日誌、指標和 trace 提供給 Agent，並把 repository 裡的文件當成系統記憶。文章也提到透過架構規則、結構測試和持續的回饋維持程式庫可理解。這些都是 Harness 的工作範圍，並不是模型權重裡突然多了一個功能。詳情可以讀 OpenAI 的 Harness engineering 工程文章。

Anthropic 的材料比較集中在長時間的 Agent 工作。他們把模型放進能使用工具的迴圈，並用 initializer、coding agent、進度檔案、feature list、測試和跨 session 的交接，讓下一次執行知道上一輪做到哪裡。較新的 Harness design for long-running application development 又把 planner、generator、evaluator 組成三個角色，讓產生和檢查互相接上。

這些文章的具體實作不同，但共同點很清楚：模型只負責做判斷和產生下一步，Harness 負責提供資訊、安排行動、保存狀態、限制風險，並讓結果回到可檢查的軌道。

本文採用的工作定義

本文把 AI Agent Harness 定義為：一套包住 AI 模型的執行層，負責把任務規格、可用 Context、工具與權限、狀態與記憶、執行環境、觀測紀錄、驗收與人工介入接成可重複的 Agent 迴圈。

這是本文根據上述工程文章與研究資料做的整理，不是某個官方規格的原文定義。你可以把它想成一個工作現場：模型像負責判斷的執行者，Harness 準備桌上的資料、工具箱、操作範圍、工作紀錄和驗收表。只給執行者一個目標，卻不準備現場，通常不會得到穩定的長任務結果。

AI Agent Harness 解決的不是回答問題，而是讓工作能繼續

單次回答和長任務是兩種問題

單次聊天通常只需要一次輸入和一次輸出。你把問題交給模型，模型產生回答，最後由你判斷好不好。就算答案不完美，修正也可能只要再問一句。

Agent 工作則會反覆經過「看資料、選工具、執行、讀結果、更新狀態、決定下一步」的迴圈。只要任務跨過多個檔案、外部服務或多個 Context window，上一輪留下的資訊就會影響下一輪。這時候，模型是否聰明只是一個變數，執行層是否讓它保持方向也同樣重要。

Anthropic 的 Building effective agents 把 workflow 描述為由程式預先安排路徑的系統，把 agent 描述為由模型動態決定流程與工具使用的系統。兩者都可能用到同一個模型，但 Harness 的要求不一樣。固定流程需要可靠的步驟與中間檢查；自主 Agent 需要更明確的權限、狀態和停止條件。

手伸出去之後，風險也一起出去

模型只產生文字時，最常見的問題是答錯、漏答或語氣不合。模型開始呼叫工具後，問題會多一層：它讀了哪份資料、用了哪個帳號、寫入了哪個系統、動作是否可回復，以及工具失敗後有沒有重試到失控。

Model Context Protocol 的規格把 Prompts、Resources 和 Tools 分成不同原語。Tools 是模型可以呼叫的可執行函式，Resources 是提供給模型或使用者的結構化資料，Prompts 則是預先定義的指令或模板。MCP 的安全說明也要求實作提供使用者同意、清楚顯示資料存取和操作範圍。這些規格不等於完整 Harness，但能幫你看見工具邊界不能只寫在一句 Prompt 裡。可以參考 MCP Overview 與 MCP Tools 規格。

做完不等於驗收通過

Agent 可能成功呼叫工具，卻沒有完成任務。例如它確實讀了三份文件，但漏掉最新版本；確實修改了檔案，但沒有跑測試；確實產生報告，但來源和結論沒有對上。這些都不是「工具有沒有回傳 200」可以回答的問題。

所以 Harness 至少要保存「做了什麼」和「怎麼知道可以停」這兩類資訊。前者是狀態與 trace，後者是測試、規則、評估器或人工確認。沒有這一段，Agent 只是更會自己走遠的自動化。

模型、Prompt、Context、Workflow、Agent、Harness 差在哪裡

把幾個常被混用的詞放在一起，會比較容易判斷問題到底出在哪一層。

名稱主要負責什麼一個實際例子失敗時先檢查什麼
Model依輸入產生文字、判斷或下一步讀到任務後決定要先查哪份資料能力、模型版本與任務是否超出範圍
Prompt告訴模型這一輪要做什麼、輸出要長什麼樣子要求只根據指定來源回答並列出未知指令是否矛盾、成功條件是否清楚
Context模型這一輪看得到的資料集合任務說明、文件摘錄、工具結果和歷史摘要是否漏資料、過期、太長或混入雜訊
Workflow由程式預先安排的步驟先摘要，再檢查欄位，最後產生報告步驟與分支是否適合這種任務
Agent可根據中間結果動態選擇下一步的系統自己決定要搜尋、讀檔、修改再測試是否有停止條件、工具和權限是否足夠
Harness把上述元素接成可執行、可觀察、可驗收迴圈的執行層管理工具、沙箱、狀態、trace、測試和人工核准迴圈設計、環境、狀態、驗收與介入點

這張表不是說每個產品都會把這六層拆成六個模組。很多工具把 Prompt、Context 和 Tool calling 收在同一個設定畫面，也有框架把 Workflow、Agent loop 和 tracing 包在一個 SDK 裡。名稱怎麼分不是重點，責任有沒有被處理才是。

如果你遇到的是「模型一直誤解要求」，先回頭看任務與 Prompt。如果它常常找不到剛剛讀過的資料，可能是 Context 或狀態問題。如果它能完成一半，卻不知道何時停止、改錯檔案或沒有留下驗證證據，就要看 Harness，而不只是繼續加形容詞。

一個 Harness 至少要處理哪些責任

2026 年的 AI Harness Engineering 論文提出 11 項責任，包括任務規格、Context 選擇、工具存取、專案記憶、任務狀態、可觀察性、失敗歸因、驗證、權限、熵稽核和介入紀錄。這是一個研究框架，不是已經通過某個標準組織認證的產品規格。日常工作不必一開始就照著拆成 11 個服務，但可以先用下面七組問題做最小盤點。

1. 任務和成功條件

Harness 要知道任務不是「把事情做好」而已。它需要保存輸入、範圍、輸出格式、停止條件和不能做的事。

例如「整理一份競品報告」還不夠具體。你至少要說明比較哪些品牌、資料截至哪一天、每個結論要不要附來源、找不到資料時要填 unknown 還是停止，以及最後交付 Markdown、表格還是簡報。這些規則越晚才補，越容易變成 Agent 已經走錯方向後的返工。

2. Context 和知識地圖

Context 不是把所有文件一次倒進模型。Harness 要決定這一輪需要哪些資料、哪些資料是最新版本、哪些內容只作背景，以及如何讓 Agent 知道下一份資料在哪裡。

OpenAI 的 Harness engineering 文章提到，他們不把 AGENTS.md 寫成百科全書，而是把它當成通往更深文件的目錄，並將結構化 docs 視為知識的系統記錄。這個做法可以直接轉成一般團隊的原則：入口檔案負責指路，內容文件負責保存細節，驗證工具負責抓過期和斷鏈。不要把一份幾百頁、沒有人敢更新的說明書塞進每次請求裡。

3. 工具存取和權限

工具要有清楚的名稱、輸入格式、作用範圍、可能副作用、失敗方式和重試規則。權限則要再問一次：這個工具只讀，還是會寫入？能不能刪除？能不能對外發布？是否需要每次由人確認？

MCP Tools 規格明確把 tool annotations 當成不可信資料，並建議實作保留人類拒絕工具呼叫的能力。這提醒我們，工具自己說「我是安全的」不能當成完整授權流程。對於刪除、付款、發布、傳送信件或改動正式資料的動作，我會把人工核准放在 Harness 的控制層，而不是只放一句「請小心操作」。

4. 狀態、記憶和交接

短期 Context、長期記憶、任務進度和工作產物不是同一種東西。Harness 要知道哪些資訊只在這一輪使用，哪些要保存給下一輪，哪些狀態可以重新計算，以及什麼內容必須從原始檔案重新讀取。

Anthropic 在 Effective harnesses for long-running agents 中用 initializer agent 建立初始環境，再由後續 coding agent 逐步完成工作，並留下進度檔案、feature list 和結構化更新。這個概念不只適合寫程式。研究流程也可以留下來源清單、已核對段落、待查主張和下一輪待辦。

5. 執行環境和隔離邊界

模型看到的檔案和模型實際能改的檔案，最好不要靠想像來區分。你需要知道它在哪個資料夾執行、使用哪個分支或版本、能不能連網、能不能讀取密鑰，以及工具失敗後是否能回復。

Anthropic 在 Scaling Managed Agents 中把 session、harness 和 sandbox 當成可以分開替換的元件。這個抽象對一般使用者也有用：session 保存發生過什麼，Harness 決定怎麼跑，sandbox 限制在哪裡跑。三件事如果全綁在一個不可重建的環境裡，出問題時通常只能靠某個人記得剛才做了什麼。

6. 可觀察性和失敗歸因

至少要留下每一步的時間、輸入來源、工具名稱、參數摘要、回傳狀態、錯誤、重試次數和產物位置。這不代表所有內容都要公開記錄，個資、密鑰和敏感文件仍然要遮蔽或不進 trace。

可觀察性的目的不是把 log 做得很豪華，而是讓你回答「它哪一步開始偏掉」。如果只有最後一句回答，你只能說結果不好；如果有每一步工具與資料紀錄，就能分清楚是搜尋漏了、Context 選錯、工具失敗、模型誤判，還是驗收規則太寬。

7. 驗證和人工介入

驗證可以是格式檢查、欄位完整性、單元測試、來源回查、瀏覽器讀回、規則引擎、第二個評估器或人看過之後按下核准。不同任務需要的證據不一樣，但停止條件不能只寫成「模型覺得完成了」。

如果結果可能影響正式網站、客戶資料或金錢，我會把介入點放在不可回復動作之前。讀取和草稿可以自動化，發布和刪除則先產生預覽、列出差異，再等待確認。這不是對 Agent 沒信心，而是把錯誤成本放在還能修正的位置。

為什麼同一個模型換個 Harness，結果可能不同

Context window 用完不是唯一問題

長任務的問題不只是 Context window 裝不下。Anthropic 在 Harness 文章中把跨 Context 的工作比喻成工程師輪班：新一輪的人沒有上一輪的記憶，所以需要明確的進度、環境和交接。另一篇 Harness design 也區分了 context reset 和 compaction。Compaction 是把歷史濃縮後繼續，reset 則是用乾淨的 Context 加上結構化交接重新開始。

這裡沒有一個對所有模型都適用的最佳選擇。重點是 Harness 要知道任務目前在哪裡、接下來要做什麼、上一輪有哪些未解問題。單純把歷史對話越塞越長，可能只是把雜訊也一起保存。

環境可讀性會改變模型能做什麼

OpenAI 的案例特別強調 application legibility：把啟動方式、DOM、截圖、logs、metrics 和 traces 放進 Agent 可以取得的環境。這不是保證 Agent 一定正確，而是讓它有機會看到人類在除錯時會看的證據。

同一個模型，如果只能看到一句「頁面壞了」，和如果能開啟指定版本、重現流程、讀取 console、比對截圖，它面對的任務其實不同。前者是在猜，後者才接近可驗證的工程工作。這個差別也能套到內容研究：只給一個搜尋結果摘要，和給它官方頁面、日期、來源版本及引用位置，不是同一個 Context。

Evaluator 是迴圈的一部分

Anthropic 2026 年的 Harness 設計文章把 planner、generator 和 evaluator 放在同一個長任務架構裡。這裡值得注意的不是「多 Agent 一定更好」，而是產出和判斷被分開，並且有明確的評估條件。沒有可操作的標準，第二個 Agent 也只是再說一次「看起來不錯」。

對內容工作來說，evaluator 可以是一份來源查核表：每個重要主張是否有第一手連結、查閱日期是否存在、引用是否真的支持句子、功能和價格是否混用了不同日期。你可以先用規則檢查，再把真正需要判斷的部分交給人。

Harness 不是越厚越好

Anthropic 的 Building effective agents 建議先找最簡單能解決問題的方法，只在需要時增加 Agent 複雜度。這個原則同樣適用 Harness。每增加一個工具、記憶層、代理角色或自動重試，都增加了新的狀態和失敗可能。

如果你的任務本來是固定的三步流程，用普通 Workflow 加上三個中間檢查可能比較容易維護。為了讓一個固定流程看起來像自主 Agent，最後得到的常常是更多 log 和更多地方需要排查，模型倒沒有比較自由。

用內容研究流程走一遍 AI Agent Harness

下面是假設情境，不是我的實測成果：你要把一組官方文件整理成一份可查證的產品 brief。這個例子故意選讀取、整理和驗收，不把發布權限交給 Agent，因為先把循環跑穩比第一天就追求全自動更實際。

第一步：把任務寫成可以停下來的規格

先建立一張 task card：

  1. 任務：整理指定產品的功能、限制與適用情境。
  2. 資料範圍：只使用官方說明、產品文件和公告，查到 2026-09-10。
  3. 交付格式：一份 Markdown brief，每個重要主張附來源連結。
  4. 必須標記：已查證、本文推論、本文建議、unknown。
  5. 禁止動作：不登入私人帳號、不傳送資料、不發布文章、不修改正式檔案。
  6. 停止條件：來源互相矛盾、資料超出日期、或工具無法讀取頁面時先交回待查清單。

這張卡不是寫給讀者看的長篇說明，它是 Harness 判斷範圍的邊界。沒有停止條件，Agent 很容易把「找不到」解讀成「再多搜尋幾頁就好」，最後跑出一篇來源和日期都混在一起的長文。

第二步：先整理來源地圖，再開工具

把來源分成核心來源、背景來源和待查來源。核心來源直接支撐功能或限制；背景來源只幫助理解；待查來源不能拿來支撐結論。每個來源留標題、URL、發布或更新日期、抓取日期和要核對的段落。

這一步有點像 NotebookLM 教學裡的來源邊界，只是本文談的是更一般的執行層。工具可以幫你抓資料，但不會自動替你決定某份文件是不是最新，也不會因為回答附了引用就完成查核。

第三步：只給目前需要的工具

最小工具集可以只有：

  • 讀取官方網址或本機來源的 read 工具。
  • 搜尋來源內文的 search 工具。
  • 將主張、來源和狀態寫入草稿區的 write 工具。
  • 檢查連結、日期、欄位和引用對應的 verify 工具。

讀取工具和寫入工具的權限要分開。write 工具只准寫入草稿資料夾，不准碰正式輸出；verify 工具只回報問題，不直接替你改掉來源。若未來要串 MCP，先從只讀伺服器開始，再針對每個會產生副作用的 tool 設計核准流程。

第四步：每一輪留下可接續的狀態

狀態檔至少記錄：已讀來源、已完成主張、尚未核對的數字、工具錯誤、目前草稿路徑和下一步。不要只保存一段「目前進度良好」的摘要，因為下一輪真正需要的是可操作的資訊。

例如：

狀態欄位範例值用途
sources_checked4知道有哪些來源已讀
claims_verified9知道哪些句子有證據
claims_unknown2下一輪先處理缺口
last_tool_errortimeout on source C不要盲目重試同一動作
next_actioncompare source B and C讓下一輪直接接手

第五步：把驗收放在產出旁邊

每完成一個段落，就問幾個具體問題：來源是否真的談到這件事？日期是否在範圍內？這句話是來源原意、本文推論還是建議？如果換成另一個讀者，他能不能沿著連結重做判斷？

這個驗收步驟能抓到很常見的偏移：來源只說「支援某功能」，文章卻寫成「所有帳號都能用」；來源只示範一種流程，文章卻把它說成唯一正確做法。Agent 可以幫忙找疑點，但疑點被標出來不等於已經解決。

第六步：用可回復的草稿結束第一版

第一輪只交付 brief、來源表、unknown 清單和待確認差異。等人確認範圍後，再生成長文或更新網站。這樣就算模型誤讀一份文件，也只需要丟掉草稿，不必回復已經發出去的頁面。

如果你想把這套流程接到既有工作自動化，可以延伸閱讀 NICROW 的如何實現工作自動化？開始前先掌握框架。那篇文章談的是自動化前要先看目標、流程和結果檢查；Harness 則把這些判斷變成執行時可追蹤的責任。

建立小型 Harness 的 8 步檢查表

先做一個最小可用版本

如果你真的要設計一個小型 Harness，我會照這個順序開始：

  1. 寫一張 task card，定義輸入、範圍、輸出和停止條件。
  2. 列出這一輪真的需要的 Context，給每份資料加來源和日期。
  3. 把工具分成 read、write 和 side effect 三類。
  4. 設定執行目錄、版本、網路和密鑰邊界。
  5. 保存每輪的狀態、產物路徑和下一步。
  6. 為中間輸出加一個可重複的格式或規則檢查。
  7. 對工具錯誤、來源矛盾和驗收失敗定義停止或人工介入。
  8. 用一個小而真的任務跑兩到三次，記錄偏移，再決定要不要加記憶、路由或多 Agent。

順序很重要。你若先裝一套很大的 Agent framework，再回頭想成功條件，通常會被框架的預設流程牽著走。工具多不等於 Harness 完整，只有在失敗時能找到原因、在成功時能留下證據，才開始接近可維護的執行層。

先從 read-only 開始

第一個版本的 Harness 最好只允許讀取、整理和產生草稿。等你確認來源、狀態和驗收都能回放，再逐步開放寫入。發布、刪除、付款、寄信或修改正式資料等動作，則要在更外層加上人工核准和差異預覽。

這個做法也符合 MCP 規格對工具同意與人類控制的提醒。規格可以提供協定層的工具描述和輸入格式，但它不會自動替你的公司決定哪些資料可以離開系統。授權政策、帳號範圍、稽核和回復能力仍要由你的 Harness 或宿主應用程式負責。

什麼時候先不要做 Harness

單次、固定、可人工確認的任務

你只是想摘要一篇文章、改一段文字，或用固定欄位把表格轉成另一個格式，通常不需要完整 Harness。一個清楚 Prompt、一個小型檢查表和人工讀回可能就夠了。先算維護成本，再決定要不要增加執行層。

資料與權限還沒整理好

如果團隊連最新版文件在哪裡、誰可以看、哪些欄位不能外傳都還沒有答案，先做 Harness 只會把混亂自動化。執行層可以放大清楚的規則，也可以放大不清楚的規則。後者通常比較快出事。

想用框架掩蓋目標不清

看到 Agent loop、memory、planner、evaluator 這些元件很容易覺得「少一個就不完整」。但 Anthropic 的官方建議是先採用能解決問題的最簡單方案，再依實際結果增加複雜度。你可以先用固定 Workflow，等任務真的出現不可預測的分支，再考慮讓模型自己選路徑。

我會把「有沒有必要做 Harness」改問成三題：這個任務是否會跨多輪或多個工具？失敗後是否需要知道責任落在哪一步？結果是否需要留下可供別人重做的證據？三題都回答是，才值得開始拆執行層。

怎麼驗收 Harness，而不是只看最後答案

你要驗收的是一個 episode

arXiv 的研究框架提出 trace-based evaluation，把一次 Agent 執行看成一個 episode，除了最後 patch 或答案，也保存 trace、驗證報告、結果和環境資訊。這是研究者提出的做法，不表示每個產品都必須輸出相同格式，但方向很實用：不要只評最後一段文字。

一個日常可用的驗收包可以包含：

證據要回答的問題
Task cardAgent 原本被要求做什麼，不能做什麼
Source list它實際讀了哪些來源，版本和日期是什麼
Tool trace呼叫了哪些工具，是否有錯誤或重試
State snapshot結束時做到哪裡，還有哪些 unknown
Output diff產生或修改了什麼，是否超出範圍
Verification report哪些規則、測試或來源回查已通過
Intervention record哪一步由人核准、拒絕或改變方向

對內容研究來說，這份證據包比「AI 說它已經查證完成」可靠。對程式工作來說，測試、diff、重現步驟和環境版本比最後一句「應該可以」有用。不同任務的證據內容會不同，但都要能回到「它做了什麼」和「我們為什麼接受」。

用故意的失敗案例測試

不要只拿順利的任務試跑。至少準備幾個會觸發邊界的案例：

  • 來源頁面在查證日期後更新。
  • 兩份官方文件對同一限制說法不同。
  • 工具回傳空資料或 timeout。
  • Agent 嘗試寫入不在允許範圍內的路徑。
  • 最後輸出格式正確，但其中一個主張沒有來源。

你要觀察的不是 Agent 有沒有百分之百猜對，而是 Harness 能不能把問題標成 unknown、停止在安全位置、保存錯誤和交回人工判斷。如果失敗只留下空白答案，下一輪還是只能重新猜。

把成功定義成可重做

一次成功可能只是碰巧。你可以固定同一份輸入，再跑幾次，檢查來源、工具順序、輸出欄位和驗收結果是否符合預期。這不是嚴格的效能基準測試，也不會直接告訴你哪個模型比較好，但能發現 Harness 是否依賴偶然的對話歷史。

如果你要比較不同模型，請把同一個 Harness、同一份資料、同一套停止條件和同一套評分方式固定下來。NICROW 的 Claude 與 ChatGPT 比較也採用這種工作情境優先的思路，本文則把比較再往執行層推進。沒有相同條件，就不要把一次漂亮輸出寫成模型排名。

AI Agent Harness 與 RAG、MCP、Context Engineering 的關係

RAG 是資料取得路徑

RAG 可以把外部資料找回來放進 Context，解決「模型原本沒有這份資料」的問題。但 RAG 不會自動決定來源是否可信、版本是不是最新、資料是否超出任務範圍，也不會替你定義輸出驗收。它可以是 Harness 裡的 retrieval 元件，不是 Harness 的全部。

MCP 是連接工具和資料的協定

MCP 提供 Host、Client 和 Server 之間的標準化溝通方式，並定義 Prompts、Resources、Tools 等能力。它能幫你解決「怎麼把外部工具接給 AI 應用程式」，但不會單獨解決「什麼時候可以用、用完如何回復、誰要核准、結果怎麼驗證」。連接標準和執行治理是兩件事。

Context Engineering 是 Harness 的一個責任

Context Engineering 關心模型在每一輪看到哪些資訊、怎麼整理、何時摘要或重新取得。它和 Harness 有交集，但不等於 Harness。你可以先讀 NICROW 的 Context Engineering 是什麼？從提示詞走向可維護的 AI 脈絡，再回來看工具、sandbox、狀態、trace 和人工介入如何把 Context 接進完整工作迴圈。

換句話說：RAG 負責找資料，MCP 負責提供一種連接方式，Context Engineering 負責整理模型看到的資訊，Harness 則把這些元件和任務、權限、狀態、執行環境及驗收接起來。這是本文的分層整理，不是宣稱每個產品的內部模組都照這樣命名。

FAQ：AI Agent Harness 常見問題

AI Agent Harness 和 AI Agent 是同一件事嗎？

不是。AI Agent 是能根據任務與中間結果決定下一步的系統；Harness 是讓它能取得資訊、使用工具、保存狀態、在指定環境中執行並被驗收的周邊執行層。有些產品會把兩者包在一起，所以介面上不一定看得到這個分界。

AI Agent Harness 是一個框架或產品嗎？

不一定。它可以由程式碼、SDK、工具設定、沙箱、狀態檔、測試和人工核准流程組成，也可以是某個產品裡已經封裝好的能力。本文把 Harness 當成責任集合與架構觀點，不把它當成單一可下載軟體。

不會寫程式也需要懂 Harness 嗎？

需要懂它處理哪些責任，但不代表你現在就要自己寫一套 Agent runtime。即使只是使用 AI 工具，你仍然可以檢查資料邊界、工具權限、產物版本、引用和結果驗收。這些判斷會影響你選擇工具，也會讓你知道問題該回報給模型、Prompt，還是產品的執行環境。

RAG 或 MCP 做好了，就等於有 Harness 嗎？

不等於。RAG 解決資料取得的一部分，MCP 解決工具或資源連接的一部分。完整 Harness 還需要任務規格、權限、狀態、環境、觀測、停止條件與驗收。把工具接上去只是開始，接上之後誰可以用、怎麼知道用對了，才是後面容易漏掉的工作。

Harness 會讓模型變聰明或一定更準嗎？

不能這樣保證。較好的執行環境可能讓模型取得更完整的資料、看到錯誤並有機會修正，但它也可能增加成本、延遲和錯誤累積。OpenAI、Anthropic 的案例和研究論文提供了具體設計與實驗觀察，不能直接推導出所有任務、模型和團隊都會得到同樣結果。

我該從哪裡開始建立自己的 Harness？

先選一個真的會重複發生、但不涉及刪除或正式發布的小任務。寫 task card，限制成只讀工具，留下來源與狀態，設一個可以重跑的驗收表，再用故意失敗的資料試一次。確認你能回答「它讀了什麼、做了什麼、哪裡失敗、為什麼可以停」後，再增加記憶、路由或多 Agent。

結語：先把模型放進可以驗收的工作環境

AI Agent Harness 這個詞還在形成中，這反而是現在適合把責任拆清楚的原因。你不必先決定要買哪一套框架，也不必把每個工作都改造成自主 Agent。先看任務是否需要多輪工具、長期狀態、隔離環境和可重做的證據。

如果只是一次性問答，Prompt 和人工讀回可能已經夠用。如果工作開始跨文件、工具、帳號或多個執行階段，就把 task card、Context、權限、狀態、trace 和驗收放到同一張設計圖上。模型會換，工具也會換；能把失敗留在可修正的位置，才是值得維護的部分。

參考來源