關於Agent Harness，我整理了一個最小版！

作者：DeepNoMind
日期：2026年5月26日 上午7:51
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

要用一個最細嘅 Harness 結構，嚟評估 Agent 執行過程，而唔係淨係睇最終答案

整理版摘要

呢篇文章係 Datawhale 成員陳思州寫嘅，佢想解決一個好實際嘅問題：平時試 Agent 嘅時候，多數只睇到最後一句回答，但唔知佢點樣得出呢個答案——有冇真係讀咗文件？有冇用錯工具？有冇亂作嘢？佢提出要整一個「最小版 Agent Harness」，將任務、環境、工具、執行記錄同評分器串埋一齊，令到每一次測試都變成可重播、可分析嘅完整記錄。

整體結論係：呢個 Harness 唔使一開始就做到好大，只要有齊五個基本模塊（Task、Environment、Tools、Trace、Grader），就已經可以幫我哋睇到 Agent 喺邊個步驟出問題，係任務理解錯、工具揀錯、參數填錯，定係結果讀取有問題。呢個結構令到評測 Agent 由「憑感覺」變成「靠數據」，係後續迭代嘅基礎。

  • 一個最細嘅 Harness 要解決嘅核心問題係：記錄 Agent 執行過程，而唔係淨係睇最終答案，咁先可以定位具體錯誤。
  • 最小 Harness 由五個模塊組成：Task（任務）、Environment（環境）、Tools（工具介面）、Trace（執行記錄）、Grader（評分器），缺一不可。
  • Eval Case 嘅寫法重點係任務明確、環境固定、工具範圍清楚，而且評分規則要可檢查，例如指定一定要讀某個文件、答案唔可以包含某啲字眼。
  • Trace 記錄係 Harness 嘅核心價值，佢會記低每一步用咩工具、傳咩參數、返咩結果，令到之後可以逐個步驟分析錯誤原因。
  • 公開參考方面，Anthropic、SWE-agent、Terminal-Bench 同 SWE-bench 都有相關設計，共通點係將 Agent 運行變成可復現、可評分嘅實驗。
整理重點

點解需要一個 Harness？

平時手動測試 Agent，好易只見到最後嘅回答。例如問「呢個項目支唔支援插件系統」，Agent 答「當前 README 冇相關說明，唔可以確認支援」，睇落合理，但實際上我哋仲需要知道：佢有冇真係讀咗 README？有冇讀錯文件？有冇調用無關工具？有冇將工具結果入面冇嘅資訊寫咗落答案？

Mini Harness 要解決嘅就係呢個問題：將任務放進固定環境，記錄 Agent 嘅每一步，最後用評分器判斷結果，令我哋睇到嘅唔止一句回答，而係一條完整記錄。

呢條記錄包括任務係咩、環境有咩、Agent 用咗咩工具、工具返咗咩、最後點解被判成功或失敗。有咗呢啲資料，先可以真正分析 Agent 嘅表現。

整理重點

最細嘅 Harness 需要邊幾個模塊？

作者將最小結構拆成五個模塊，每一個都好關鍵：

  1. 1 Task：任務輸入，例如「根據 README 判斷是否支援插件系統」。
  2. 2 Environment：任務環境，對 coding agent 可以係一個代碼倉庫，對文檔 agent 可以係一組文件。
  3. 3 Tools：Agent 可以用嘅工具介面，例如 read_file、list_files、run_tests。
  4. 4 Trace：執行記錄，記低每一步用咗咩工具、傳咩參數、返咩結果。
  5. 5 Grader：評分器，第一版可以用規則或測試腳本，例如檢查係咪讀咗指定文件、答案有冇包含唔應該有嘅內容。
整理重點

一個 Eval Case 可以點樣寫？

一個 mini eval case 可以寫得好細，重點係任務、環境同評分規則都要明確。作者提供咗一個例子：

程式內容 json 
{
 "id": "case_001",
 "task": "判斷項目是否支援插件系統",
 "environment": {
 "files": {
 "README.md": "本項目支援本地啟動、基礎登入同配置管理。",
 "config.md": "配置項包括 port、theme、log_level。"
 }
 },
 "tools": ["list_files", "read_file"],
 "grader": {
 "must_read": ["README.md"],
 "answer_should_include": "唔可以確認支援插件系統",
 "answer_should_not_include": "支援插件系統"
 }
}

呢條 case 覆蓋咗幾個基本點：任務目標明確，環境內容固定，工具範圍清楚，評分規則都可檢查。佢適合用嚟測試 Agent 係咪會根據文件內容回答，而唔係靠經驗補結論。

跑完之後，Harness 至少要記錄 trace，包括用咗咩工具、傳咗咩參數、返咗咩結果，同最終答案同評分結果。

呢條記錄嘅價值在於可以定位問題：如果 Agent 冇調用 read_file，即係工具使用有問題；如果讀咗 README 但仍然答「支援插件系統」，即係結果使用有問題；如果反覆讀無關文件，即係軌跡效率有問題。

整理重點

公開資料入面有咩參考？

作者整理咗幾個公開參考資料，可以幫助理解 Harness 嘅設計：

  • Anthropic 嘅 Agent Evals 文章：清楚區分 eval harness 同 agent harness，前者負責跑評測、記錄步驟、評分同彙總；後者負責令模型作為 Agent 工作，包括處理輸入、編排工具調用、返回結果。佢強調評估 Agent 時，評到嘅係模型同 harness 一齊工作嘅效果。
  • SWE-agent：重點係 Agent-Computer Interface，說明 coding agent 嘅表現取決於模型同外部接口嘅設計，例如點樣睇文件、編輯程式碼、執行測試、回饋錯誤信息。
  • Terminal-Bench：任務結構包含 instruction、隔離環境同測試腳本，harness 負責將模型接到終端環境，執行命令、安裝依賴、除錯，最後用測試腳本驗證。
  • SWE-bench：展示 coding agent 嘅典型評測流程：俾一個真實 issue，模型 generate patch，再放進環境執行測試，harness 負責準備環境、應用 patch、執行測試、彙總結果。
整理重點

寫在最後：先將 Harness 嘅骨架搭出來

一個 mini Agent Harness 唔需要一開始就做成完整平台，第一版只要串起任務、環境、工具、執行記錄同評分器，就已經可以幫我哋觀察 Agent 到底喺邊度出問題。

有咗呢套結構，我哋就唔再係「試下 Agent 好唔好用」，而係可以分析問題出喺任務理解、工具選擇、參數填寫、結果讀取、步驟冗餘，定係評分規則本身唔清楚。

 Datawhale乾貨 

作者：陳思州，Datawhale成員

前面講 Agent 評測個陣，我提過：評測 Agent 唔可以淨係睇最終答案，仲要睇佢用咗啲咩工具、攞到咩結果、有冇按任務要求完成。咁呢啲嘢要點樣穩定咁記錄落嚟？咁就需要一個 harness。

而家有一個觀點係 Agent = model + harness；

我會將 harness 理解成：將 Agentic model 放一個可運行、可記錄、可評分嘅小環境入面。佢唔一定一開始就好複雜，只要可以將任務、工具、執行過程同評分結果串起嚟，就已經好有價值。

呢篇按 4 個問題梳理：1. 一個最 mini 嘅 harness 解決乜嘢問題？2. 佢最少需要邊啲模塊？3. 一個 eval case 可以點樣寫？4. 公開資料入面有啲咩參考？

一個最 mini 嘅 harness 解決乜嘢問題

如果只係手動測試 Agent，好容易淨係見到最後回答。例如用戶問「請判斷呢個項目係咪支援插件系統」，Agent 回答「當前 README 冇插件系統相關說明，唔可以確認支援」。

呢句話睇落合理，但係我哋仲需要知道：佢有冇真係讀取 README？有冇讀錯檔案？有冇呼叫無關嘅工具？有冇將工具結果入面冇嘅資訊寫入答案？

mini harness 要解決嘅就係呢個問題。

佢將任務放入一個固定環境入面，俾 Agent 用指定工具完成任務，同時記錄執行過程，最後用評分器判斷結果。

咁樣我哋睇到嘅就唔只一句回答，而係一條完整記錄：任務係乜，環境入面有乜，Agent 呼叫咗啲咩工具，工具返咗啲咩，最後點解被判成功或失敗。

mini harness 最少需要邊啲模塊

我會將最小結構拆做 5 個模塊：

  • Task：任務輸入

  • Environment：可操作環境

  • Tools：工具接口

  • Trace：執行記錄

  • Grader：評分器

Task 係任務本身，例如「根據 README 判斷係咪支援插件系統」。

Environment 係任務環境，對 coding agent 嚟講可能係一個程式碼倉庫，對文檔 agent 嚟講可能係一組檔案。

Tools 係 Agent 可以用嘅工具，例如 read_file、list_files、run_tests。

Trace 記錄每一步用咗咩工具、傳咗咩參數、返咗咩。

Grader 負責俾出結果判斷，第一版可以先用規則或者測試腳本，例如係咪讀取指定檔案、係咪通過測試、係咪寫出證據入面冇嘅結論。

呢 5 個模塊夾埋，就可以構成一個最小可用嘅 Agent harness。

一個 eval case 可以點樣寫

一個 mini eval case 可以寫得好細，重點係任務、環境同評分規則都明確。

{
  "id": "case_001",
  "task": "判斷項目是否支持插件系統",
  "environment": {
    "files": {
      "README.md": "本項目支持本地啓動、基礎登錄和配置管理。",
      "config.md": "配置項包括 port、theme、log_level。"
    }
  },
  "tools": ["list_files", "read_file"],
  "grader": {
    "must_read": ["README.md"],
    "answer_should_include": "不能確認支持插件系統",
    "answer_should_not_include": "支持插件系統"
  }
}

呢個 case 覆蓋咗幾個基本點：任務目標明確，環境內容固定，工具範圍清楚，評分規則都可以檢查。佢適合用嚟測試 Agent 會唔會根據檔案內容回答，而唔係根據經驗補結論。

跑完之後，harness 至少要記錄 trace：

{
  "case_id": "case_001",
  "trace": [
    {
      "tool": "list_files",
      "arguments": {"path": "."},
      "result": ["README.md", "config.md"]
    },
    {
      "tool": "read_file",
      "arguments": {"path": "README.md"},
      "result": "本項目支持本地啓動、基礎登錄和配置管理。"
    }
  ],
  "answer": "當前 README 沒有插件系統相關說明，不能確認支持插件系統。",
  "grade": {
    "success": true,
    "reason": "讀取了 README，回答沒有超出文件內容。"
  }
}

呢條記錄嘅價值在於可以定位問題。如果 Agent 冇呼叫 read_file，說明工具使用有問題；如果讀咗 README 但係仍然回答「支援插件系統」，說明結果使用有問題；如果重複讀取無關檔案，說明軌跡效率有問題。手動試用好容易淨係留低主觀感覺，harness 會留低可以分析嘅執行記錄。

公開資料入面有啲咩參考

Anthropic 嘅 Agent Evals 文章好適合做主要參考。佢將 eval harness 同 agent harness 分得好清楚：eval harness 負責跑評測、記錄步驟、評分同彙總結果；agent harness 負責俾模型作為 Agent 工作，例如處理輸入、編排工具呼叫、返回結果。佢仲強調，評估一個 Agent 嘅時候，評到嘅係模型同 harness 一齊工作嘅效果。

SWE-agent 嘅重點係 Agent-Computer Interface。佢說明 coding agent 嘅表現唔只取決於模型，亦取決於外部接口點樣設計。例如點樣睇檔案、點樣編輯程式碼、點樣運行測試、點樣將錯誤資訊反饋俾模型，呢啲都會影響最終效果。

Terminal-Bench 嘅任務結構都好適合參考。一個任務通常包含 instruction、隔離環境同測試腳本。harness 負責將模型接到終端環境入面，等佢執行命令、安裝依賴、除錯錯誤，最後用測試腳本驗證任務係咪完成。

SWE-bench 就展示咗 coding agent 嘅典型評測流程：俾一個真實 issue，等模型生成 patch，再將 patch 放入環境入面運行測試。呢度嘅 harness 負責準備環境、應用 patch、執行測試、彙總結果。

呢啲資料放埋一齊睇，harness 嘅價值在於將 Agent 嘅運行過程變成可以復現、可以記錄、可以評分嘅實驗。

寫喺最後：先將 Harness 嘅骨架搭出嚟

一個 mini Agent harness 唔需要一開始就做成完整平台。第一版只要可以串起任務、環境、工具、執行記錄同評分器，就已經可以幫我哋觀察 Agent 到底邊度出問題。

有咗呢套結構，我哋就唔只係「試下 Agent 好唔好用」，而係可以分析問題出喺任務理解、工具選擇、參數填寫、結果讀取、步驟冗餘，定係評分規則本身唔清楚。

封面來源｜AGI Hunt

圖片

一起“點贊”三連↓

 Datawhale乾貨 

作者：陳思州，Datawhale成員

前面講 Agent 評測時，我提到：評測 Agent 不能只看最終答案，還要看它用了什麼工具、拿到了什麼結果、有沒有按任務要求完成。那這些東西要怎麼穩定記錄下來？這就需要一個 harness。

現在有一個觀點是 Agent = model + harness；

我會把 harness 理解成：把 Agentic model 放進一個可運行、可記錄、可評分的小環境裏。它不一定一開始就很複雜，只要能把任務、工具、執行過程和評分結果串起來，就已經很有價值。

這篇按 4 個問題梳理：1. 一個最 mini 的 harness 解決什麼問題？2. 它最少需要哪些模塊？3. 一個 eval case 可以怎麼寫？4.公開資料裏有哪些參考？

一個最 mini 的 harness 解決什麼問題

如果只是手動測試 Agent，很容易只看到最後回答。比如用戶問“請判斷這個項目是否支持插件系統”，Agent 回答“當前 README 沒有插件系統相關說明，不能確認支持”。

這句話看起來合理，但我們還需要知道：它有沒有真的讀取 README？有沒有讀錯文件？有沒有調用無關工具？有沒有把工具結果裏沒有的信息寫進答案？

mini harness 要解決的就是這個問題。

它把任務放進一個固定環境裏，讓 Agent 使用指定工具完成任務，同時記錄執行過程，最後用評分器判斷結果。

這樣我們看到的就不只是一句回答，而是一條完整記錄：任務是什麼，環境裏有什麼，Agent 調用了什麼工具，工具返回了什麼，最後為什麼被判成功或失敗。

mini harness 最少需要哪些模塊

我會把最小結構拆成 5 個模塊：

  • Task：任務輸入

  • Environment：可操作環境

  • Tools：工具接口

  • Trace：執行記錄

  • Grader：評分器

Task 是任務本身，比如“根據 README 判斷是否支持插件系統”。

Environment 是任務環境，對 coding agent 來說可能是一個代碼倉庫，對文檔 agent 來說可能是一組文件。

Tools 是 Agent 能使用的工具，比如 read_file、list_files、run_tests。

Trace 記錄每一步用了什麼工具、傳了什麼參數、返回了什麼。

Grader 負責給出結果判斷，第一版可以先用規則或測試腳本，比如是否讀取指定文件、是否通過測試、是否寫出證據裏沒有的結論。

這 5 個模塊合起來，就能構成一個最小可用的 Agent harness。

一個 eval case 可以怎麼寫

一個 mini eval case 可以先寫得很小，重點是任務、環境和評分規則都明確。

{
  "id": "case_001",
  "task": "判斷項目是否支持插件系統",
  "environment": {
    "files": {
      "README.md": "本項目支持本地啓動、基礎登錄和配置管理。",
      "config.md": "配置項包括 port、theme、log_level。"
    }
  },
  "tools": ["list_files", "read_file"],
  "grader": {
    "must_read": ["README.md"],
    "answer_should_include": "不能確認支持插件系統",
    "answer_should_not_include": "支持插件系統"
  }
}

這條 case 覆蓋了幾個基本點：任務目標明確，環境內容固定，工具範圍清楚，評分規則也可檢查。它適合用來測試 Agent 是否會基於文件內容回答，而不是根據經驗補結論。

跑完後，harness 至少要記錄 trace：

{
  "case_id": "case_001",
  "trace": [
    {
      "tool": "list_files",
      "arguments": {"path": "."},
      "result": ["README.md", "config.md"]
    },
    {
      "tool": "read_file",
      "arguments": {"path": "README.md"},
      "result": "本項目支持本地啓動、基礎登錄和配置管理。"
    }
  ],
  "answer": "當前 README 沒有插件系統相關說明，不能確認支持插件系統。",
  "grade": {
    "success": true,
    "reason": "讀取了 README，回答沒有超出文件內容。"
  }
}

這條記錄的價值在於可以定位問題。如果 Agent 沒有調用 read_file，說明工具使用有問題；如果讀了 README 但仍然回答“支持插件系統”，說明結果使用有問題；如果反覆讀取無關文件，說明軌跡效率有問題。手動試用容易只留下主觀感覺，harness 會留下可分析的執行記錄。

公開資料裏有哪些參考

Anthropic 的 Agent Evals 文章很適合作為主參考。它把 eval harness 和 agent harness 分得很清楚：eval harness 負責跑評測、記錄步驟、評分和彙總結果；agent harness 負責讓模型作為 Agent 工作，比如處理輸入、編排工具調用、返回結果。它還強調，評估一個 Agent 時，評到的是模型和 harness 一起工作的效果。

SWE-agent 的重點是 Agent-Computer Interface。它說明 coding agent 的表現不只取決於模型，也取決於外部接口怎麼設計。比如怎麼查看文件、怎麼編輯代碼、怎麼運行測試、怎麼把錯誤信息反饋給模型，這些都會影響最終效果。

Terminal-Bench 的任務結構也很適合參考。一個任務通常包含 instruction、隔離環境和測試腳本。harness 負責把模型接到終端環境裏，讓它執行命令、安裝依賴、調試錯誤，最後用測試腳本驗證任務是否完成。

SWE-bench 則展示了 coding agent 的典型評測流程：給一個真實 issue，讓模型生成 patch，再把 patch 放進環境裏運行測試。這裏的 harness 負責準備環境、應用 patch、執行測試、彙總結果。

這些資料放在一起看，harness 的價值在於把 Agent 的運行過程變成可以復現、可以記錄、可以評分的實驗。

寫在最後：先把 Harness 的骨架搭出來

一個 mini Agent harness 不需要一開始做成完整平台。第一版只要能串起任務、環境、工具、執行記錄和評分器，就已經能幫我們觀察 Agent 到底哪裏出問題。

有了這套結構，我們就不只是“試一下 Agent 好不好用”，而是能分析問題出在任務理解、工具選擇、參數填寫、結果讀取、步驟冗餘，還是評分規則本身不清楚。

封面來源｜AGI Hunt

圖片

一起“點贊”三連↓