Agent Harness 是什麼？從 Claude 公開資料理解可驗證的 AI 工作流
從 Claude 公開工程資料整理：Agent Harness 定義資料、工具、停止條件、權限與可回看紀錄，讓 AI 工作流可驗證。
本文整理 Anthropic／Claude 公開的工程與產品文件，並加入 Gwarket 對可驗證 AI 工作流的分析；不是 Anthropic 官方文件或產品承諾。
「Harness」聽起來很技術，但它解決的是日常問題：你希望 AI 主動處理工作，卻不希望它讀錯資料、無限嘗試、誤動外部系統，或把一段漂亮的回答當成真的完成。
模型本身像一位會推理、會使用工具的執行者；Harness 則是它工作的場地與規則。它不是另一個 agent，也不等於一大段 prompt。
一個 Harness 通常包含什麼
| 元件 | 它回答的問題 |
|---|---|
| 上下文 | 它該根據哪些資料做事？ |
| 工具 | 它可以讀、查、寫或呼叫什麼？ |
| 流程 | 哪些步驟有先後？何時停止？ |
| 邊界 | 哪些動作不能自行做？ |
| 可觀測性 | 之後怎麼知道它做過什麼？ |
假設要讓 AI 幫你處理一份來源資料。Harness 可以規定：它只能讀這個資料夾；先列出可驗證主張與未知項，再提出三個方向；不得直接發布；若來源衝突或資料不足，必須停下來提問。這些規則把 AI 的能力放進一條可回看、可驗收的工作路徑。
什麼時候需要它？
一次性的探索對話通常不需要。當工作開始重複、會用到工具、涉及多人交接，或錯誤成本變高時，才需要把隱性的工作習慣寫成 Harness。
例如：資料進來後要先擷取、標出證據與未知、再形成候選稿、最後等待人確認。這條路徑就是 Harness。它不替人決定觀點或是否發布；它確保系統不會跳過必要步驟。
Harness 最容易做錯的地方
常見誤解是：既然模型會犯錯，就替每個小動作寫一條僵硬規則。結果是模型能力提升後，框架反而成為瓶頸。
比較好的原則是只保留三類必要結構：安全邊界、使用者體驗邊界、可觀測性邊界。能交給模型自行規畫與調整的部分，不必過度硬編排。Anthropic 對 Harness 的建議很直接：持續問自己「有什麼事可以不再替模型做？」
把 Harness 想成工作規範，不是技術名詞
如果一位新人加入團隊，你不會只對他說「去把這件事做好」。你至少會說明：可使用哪些資料、哪些資料不能碰、成果放在哪裡、遇到不確定時找誰、什麼動作要先確認。
Harness 做的也是這件事，只是把這些原本散落在口頭交代、資深者習慣與臨時訊息裡的規則，變成系統可以一致執行的條件。
這也說明了它與 prompt 的不同。Prompt 可以說明這次的目標，例如「從這些來源找出三個可寫的角度」。Harness 則決定它在過程中可讀什麼、何時該停、能不能寫入正式資料夾，以及事後如何看回它做過的行動。
一條內容工作流的最小 Harness
不必從複雜系統開始。以內容研究為例，最小版本可以只有：
- 來源必須被保存，不能只留下最後摘要。
- 每個主張要標示來源或標成推論。
- 資料不足時列為未知，不補寫成確定結論。
- AI 只產出候選稿，不自行轉成對外發布。
- 人確認方向與邊界後，才允許進到下一個交付階段。
這五點已經讓流程從「一段聊天紀錄」變成可以回溯的工作單元。之後若發現研究常讀到無關資料，再補資料範圍；若常在固定步驟出錯，再加對應檢查。規則應該從反覆出現的真實失敗長出來，不是從想像中的所有風險一次長滿。
Harness 也要能被刪除
AI 能力、工具介面與團隊做法都會變。曾經必要的步驟，可能後來只是拖慢工作。例如一個模型已經能可靠整理指定格式的資料，就未必需要一個為舊模型設計的多層轉換流程。
因此，設計 Harness 不是把規則永久寫死，而是定期檢查兩件事：這條規則仍在防止真實風險嗎？如果拿掉它，哪個可觀察指標會變差？答不出來的規則，可能已經是技術債。
先寫下來，才知道現在其實靠什麼運作
不少團隊以為自己沒有 Harness，其實只是把 Harness 藏在人的記憶裡：資深同事知道不能碰哪個資料夾、知道哪份文件才是最新版，也知道哪個按鈕不能直接按。這些知識沒有消失，只是不可交接、不可審查，也無法穩定地交給 AI。
把它寫成清楚的條件，不代表流程會僵化。相反地，它讓例外變得可見：哪些是固定規則，哪些確實必須由人依情境判斷。這是之後要擴大、委派或改善工作流時最可靠的起點。
當然，不是每個人的工作都需要自己寫程式做 Harness。你可以先從文件命名、固定輸出格式、可否對外動作的清單、以及完成前的檢核表開始。只要這些規則能被重複使用並在例外時被看見，你已經在建立 Harness。
讀者保存卡
Harness 不是限制 AI 思考；它把資料、工具、停止條件、權限和驗證變成明確的工作場地。