Niklaus Harness 排行榜測試 Kimi Code、Hermes、Pi、Claude Code 與 Codex，不止於品牌排名

Joël Niklaus 在 28,849 次測試中比較九個編碼代理 harness，挑戰「選定模型便已決定效能」的看法。Niklaus harness 排行榜在控制底層模型與推理設定的同時，評估引導模型工作的軟件。初步結果顯示，多個知名工具的準確度處於相近範圍，而效率與可重複性方面的差異，令任何單一贏家都難以下定論。

比較涵蓋 Kimi Code、Hermes Agent、Pi、Claude Code、Codex、OpenCode、mini-swe-agent、Qwen Code 及 OpenClaw。harness 是管理 AI 模型指令、工具與執行迴圈的軟件。在此，這層周邊軟件成為受檢驗的變數。

核心張力在於產品聲譽與特定受測設定的實際表現之間。這些結果並不證明 Claude Code 或 Codex 使用預設模型時，在所有情況下都表現更佳。它們檢視的是不同 harness 在受控條件下運行指定開放模型時會發生甚麼，這是一個範圍較窄、但對開發者有實際影響的問題。

Niklaus Harness 排行榜實際比較甚麼

這項實驗分離周邊代理軟件，而非將每個編碼產品視為不可拆分的整體。

Niklaus 在發布說明中表示，該比較固定模型、供應商及推理強度，只更換 harness。每項任務會獲得三次嘗試。初步評估涵蓋 GLM-5.3-Flash、DeepSeek-V4.1-Flash 與 Flint，並使用 Terminal-Bench 2.1 及 DeepSWE。

這種設計相當重要，因為一般產品比較往往同時改變多個變數。開發者轉換編碼助手時，可能同時更換模型、指令、可用工具、權限及執行方式。因此，效能差異便難以歸因。

發布說明指出，mini-swe-agent 在三個模型的平均解題率為 51.4%，而 OpenClaw 為 27.3%。Niklaus 亦表示，另外四個 harness 與領先結果在統計上並列。這些數字描述的是初次發布的結果，而非永久排名。

他的模型特定結果令整體平均值變得更複雜。Niklaus 指出，mini-swe-agent 在 GLM-5.3-Flash 領先，Hermes Agent 在 DeepSeek-V4.1-Flash 領先，而 Kimi Code 則在 Flint 領先。因此，排序取決於開發者打算運行哪一個模型。

即時啟示雖有限，卻影響深遠。某個 harness 即使能與一個模型良好配合，也不代表能從另一模型取得相同的相對效能。整體分數有助找出候選方案，卻可能掩蓋實際部署中最重要的配對。

Terminal-Bench 評估代理在終端機環境中執行任務的能力，當中軟件會執行指令並與檔案互動。DeepSWE 則提供另一項軟件工程評估。兩者並用可擴闊比較範圍，但合併結果並不代表這些任務集合能反映每一種開發工作流程。

這項實驗的結論亦需要附上日期。本文查核時，即時應用程式顯示版本為 v0.1.2。其現時說明提到會檢查等效供應商，而非僅重複初次發布時「固定供應商」的表述。

這個區別值得注意，因為基準測試可在首次公布後演變。新的 harness 版本、額外測試或修訂後的控制條件，都可以改變截圖的意義。發布時的數字仍是關於發布設定的證據，即使現時排行榜呈現不同排序亦然。

因此，對於閱讀原始 Reddit 討論的讀者而言，關鍵修正是理解其範圍。這是對指定 harness 與模型組合的比較，並非對列出產品名稱所涵蓋的所有功能、訂閱體驗或預設設定作全面測試。

編碼代理供應商面臨說明完整設定的壓力

結果對將代理效能完全歸因於底層模型的說法構成壓力。

對 harness 開發者而言，這項比較令實作選擇更為可見。指令、工具介面、重試行為及停止決策，都會塑造模型所執行的工作。強大的模型仍可能受負責引導它的軟件所帶來的摩擦影響。

對模型供應商而言，同一實驗帶來歸因問題。某模型在特定代理中的不理想結果，並不能證明模型是唯一成因。相反，強勁結果也不能證明所有使用這些權重的應用程式都能重現該表現。

對企業買家而言，這改變了有意義的評估需要說明甚麼。當設定選擇會影響結果時，僅列出模型與助手並不足夠。買家需要足夠資訊，以理解受測組合，並重現與其工作相關的行為。

一項假設性的維護任務可具體說明這個區別。代理可能需要檢查儲存庫、找出失敗的測試、修改函式，並驗證變更。每個階段均取決於 harness 如何提供資訊及管理行動次序。

若代理完成編輯後便停止，而沒有執行相關測試，看似合理的修補程式仍未經驗證。若它持續發出無效指令，完成工作便會變慢，亦更耗用資源。即使底層模型不變，這些仍是營運層面的差異。

這並不能證明任何特定排行榜結果由哪種實作導致。這需要檢視執行紀錄並測試介入措施。然而，它解釋了為何受控比較提出了一個單靠模型排名無法回答的有用問題。

發布結果亦為熟悉的 Claude Code vs Codex 討論劃出界線。這些產品名稱通常代表圍繞特定模型家族建立的完整體驗。以指定開放模型測試其 harness，提出的是與比較完整體驗不同的問題。

在這項實驗中的低排名，並不代表產品的預設服務表現不佳；高排名亦不代表其在程式碼審查、互動協作或特定組織工作流程中更優勝。這些說法需要直接量度該等活動的評估。

Kimi Code 基準測試結果同樣有此限制。其在 Flint 上的領先表現，支持在受測條件下進一步研究這個配對，但不能證明它在無關模型或儲存庫中普遍領先。

對供應商而言，具建設性的回應是發布設定，並說明會影響結果的變更。買家便可分辨模型升級與 harness 改良，令效能聲稱更容易評估，亦令失敗原因更容易調查。

這種壓力對透過可互換代理軟件操作開放模型的團隊尤其相關。他們的採購決定包括執行層，所需的是該層所帶來貢獻的證據，而非完全依賴知名產品名稱。

相近準確度可掩蓋不同的營運行為

接近的準確度結果，仍可能在資源使用、延遲與一致性上存在重大差異。

現時排行榜將多項量度分開呈現，而非將準確度視為完整答案。其評估方法說明會外部量度模型使用量，並區分模型處理時間與運行代理所花的時間。這些區別有助解釋，為何相近解題率可帶來不同的營運體驗。

排行榜亦繪製準確度與成本的關係，並標示 Pareto 前沿，即沒有競爭者能在兩項顯示量度上同時勝出的選項集合。這讓讀者毋須假定最高準確度必然最佳，仍可檢視互相競爭的優勢。

當機構有固定工作量及有限資源時，這種框架尤其重要。對需要最低限度監督的困難任務而言，細小的準確度優勢可能很有價值；但若它令例行維護工作需要大幅增加執行時間，同一優勢便未必那麼吸引。

效率結果亦需要解讀。較低支出不一定代表代理推理得更有效，可能只是反映較少嘗試、較早終止、較短輸出，或不同的工具使用模式。執行紀錄有助區分具成效的克制與過早失敗。

同樣地，較長執行時間不代表浪費。代理可能會花額外精力檢查修補程式，或從失敗的方法中恢復。真正相關的問題是，額外工作是否改善團隊實際重視的結果。

因此，按每次嘗試及每次成功結果報告資源使用量，回答的是不同問題。廉價但失敗的嘗試仍然是失敗；若人工復原工作原本會主導整個流程，要求更多資源的成功嘗試仍可能是更佳選擇。

這些是評估考量，而非針對排行榜上每個 harness 已獲確立的解釋。圖表可揭示值得調查的模式，但本身無法確認是甚麼指令或工具行為造成該模式。

其機制在原理上相當直接。代理接收資訊、選擇行動、觀察結果，然後決定下一步。harness 控制這個迴圈的重要部分，包括哪些工具可用，以及工具回應如何傳達至模型。

設想一個因環境問題而導致建置失敗的假設性儲存庫。反覆修改應用程式碼的代理，可能在未處理成因下消耗資源；另一個設定則可能辨識環境問題，並重新引導調查方向。

差異將涉及任務執行，而非模型原始知識。要確立這個解釋，須將觀察到的行為與結果對應。若沒有這種檢查，聲稱某個 harness 「更聰明」便超出證據所能支持的範圍。

因此，Niklaus harness 排行榜所支持的比較，比單一贏家標籤所暗示的更具體。開發者可以問：哪些組合能達到可接受的準確度，同時以其工作量可承受的方式使用資源。答案可因互動式開發與無人值守運作而有所不同。

這亦改變了閱讀 Kimi Code 基準測試標題的方式。模型特定的領先表現，是進一步評估的有用訊號；但若沒有失敗嘗試、執行時長，以及產生該分數的行為等資訊，仍屬不完整。

基於同一原因，Claude Code vs Codex 的比較應保留受測脈絡。名稱可提供方向，但設定才決定結果實際描述的是甚麼。

可重複成功與偶爾成功是不同的結果

一個只能間歇完成任務的代理，與一個能穩定完成任務的代理，代表的是不同的部署條件。

Niklaus 其後強調多次嘗試下的可靠性。根據他的可靠性分析，mini-swe-agent 平均每次嘗試可解決 51.4% 的任務。在三次嘗試中，它至少成功一次的比例為 68.6%，但每次都成功的比例則為 33.0%。

這些量度回答的是不同的營運問題。平均值反映各次嘗試的整體表現。至少成功一次反映重複嘗試最終能否產生解決方案。每次都成功則反映在量度的嘗試中是否保持一致。

當有人觀察代理工作時，這個分別尤其重要。開發人員可以檢查失敗的嘗試、修改指令，或決定是否值得再執行一次。人手監督可令間歇性成功變得有用，但所花的監督時間仍是工作流程的一部分。

無人監督的程序面對不同限制。除非周邊系統實際執行替代方案並能辨識其品質，否則它不能假設存在一次成功的替代嘗試。重複嘗試需要選擇方法、執行預算，以及處理未解決失敗的機制。

因此，偶爾成功的分數不能取代一致性的量度。它可以顯示某個設定在某些條件下有能力找到解決方案，卻不能證明該設定可按需要可靠地交付該方案。

Niklaus 指出，在所引用的比較中，五個 harness 在每次嘗試中均解決了 32.0% 至 33.3% 的任務。他形容這些結果過於接近，難以判斷高下。這支持我們避免在領先組別內作出精確的勝者宣稱。

可靠性數字亦需要附帶其限制。三次嘗試只能提供該實驗中可重複性的證據，不能確立在不斷變化的 repository、相依套件、權限及用戶指令下的生產環境失敗率。

同樣地，在 benchmark 中失敗並不會自動等同於造成有害的生產環境操作。評估器量度任務是否符合成功準則；營運後果則取決於代理可存取甚麼，以及其工作受哪些批准或驗證程序包圍。

對工程經理而言，含意是要把能力與可靠交付分開看待。一個設定可能偶爾足以產生正確的 patch，卻仍不適合無人監督的工作流程。這個落差需要額外驗證，而不是更強烈的行銷標籤。

假設性的相依套件更新可說明當中的分別。代理可能在一次執行中成功更新套件並通過測試，卻在另一次執行中漏掉相關的設定變更。這種偶爾成功，對無人監督準備程度的證明，遠不如標題百分比所暗示般充分。

評估該工作流程的團隊會關心可重現的完成結果及清晰的失敗處理方式，也會關心審閱者能否理解最終變更。這些面向與 benchmark 驗證器是否接受最終狀態，仍是不同的問題。

排行榜的重複嘗試視角，將這項分別帶進公開比較之中。它鼓勵讀者詢問代理必須再次工作時會發生甚麼，而非把一次成功的軌跡視為產品的完整描述。

Benchmark 版本與公開紀錄限制勝者宣稱

已發布的結果是可檢查的證據，但仍受 benchmark 版本、設定及驗證完整度所限。

Terminal-Bench 本身提供一個清楚例子，說明版本標籤為何重要。其 2.1 修訂版修正了上一版 89 個任務中的 28 個問題。維護者報告，在完成這些修正後，具代表性的代理－模型分數有所變動。

這段歷史令 benchmark 版本成為宣稱的一部分。Terminal-Bench 2.0 的分數不能簡單視為可與 2.1 互換。即使顯示的指標名稱相同，任務及評估條件已經改變。

同一原則亦適用於 harness。結果屬於受測試的軟件版本及設定。如更新改變指令、工具執行或終止行為，較早的分數描述的便是較早的實作。

這對快速發展的公開討論構成挑戰。排行榜更新後，舊圖表仍可能繼續流傳，而留言亦繼續把圖表當作最新資料。讀者需要原始設定和量度日期，才能判斷該圖表目前仍能證明甚麼。

該項目的公開執行紀錄提供了核查這些細節的途徑。紀錄可取得是透明度上的好處，但其發布不代表每項結果已獲獨立重現或完成全面人手審查。

獨立重現需要執行指定設定，並檢查相關模式是否持續存在。閱讀紀錄可支援審核已報告的計算結果或個別行為。這些活動提供的是不同種類的證據。

因果問題尤其要求嚴謹。分數差異可識別在受控條件下，設定與結果之間的關聯。要解釋差異，則需要檢查失敗情況，並測試所提出的改動是否會改變它們。

例如，懷疑有逾時問題時，應在保持其他相關條件不變下調整逾時設定來測試。懷疑有資訊遺失問題時，則需要檢查哪些資訊消失，以及保留該資訊是否能改善結果。兩種解釋都不會由低排名自動得出。

benchmark 熟悉度帶來另一項值得調查的疑慮，但不應先假定存在不當行為。針對公開任務優化的系統，可以在該任務分布上有所改善，卻未必在其他地方同樣進步。來自陌生任務的證據，有助確立這項提升可廣泛遷移至何種程度。

任務涵蓋範圍是另一項限制。repository 維護涉及組織慣例、含糊的要求及人手審閱期望，固定 benchmark 無法完全捕捉。benchmark 即使有用，仍可能未能解答這些部署問題。

實際做法是讓證據與決策相稱。公開結果可以支持建立候選名單或進行針對性試驗；要取代團隊的開發工作流程，則需要來自與該團隊實際職責相似工作的額外證據。

把設定、失敗示例及審閱決定一併保存，會令這些比較更容易回顧。可搜尋的知識庫可協助保留這段評估歷史，並與測試期間使用的技術文件並列。

驗證缺口不會抹殺實驗的價值。它界定結果目前支持甚麼，以及哪些額外工作可令它們更有說服力。這比逐字接受每個排名，或完全否定比較，都是更有用的解讀。

下一輪測試應追蹤更新、重現及無人監督工作

最有力的後續證據，將會把版本變更與初步比較以外工作的可重現改進連結起來。

首個值得留意的訊號，是具備清晰版本歷史的更新後 harness 表現。當開發人員修改執行軟件時，可比較的重新執行可顯示準確度、效率或一致性是否改變。保留較早設定，才能令這種比較有意義。

若改進在重複量度中持續出現，便更能支持 harness 工程會實質影響結果的說法。若結果在可比較的重新執行下消失，對所宣稱提升的信心便會減弱。無論結果如何，都比更新一個勝者徽章提供更多資訊。

這亦為供應商提供具建設性的回應方式。他們可以識別失敗模式、解釋相關實作變更，並發布結果證據。讀者便可評估具體的工程宣稱，而不是從產品聲譽推斷品質。

第二個訊號是具有相同控制條件的獨立重現。另一位評估者應記錄模型、供應商條件、推理設定、任務版本及 harness 版本。差異應保持可見，而不是被整合成看似相同的分數。

若獨立結果保留整體排序或模型特定模式，對比較的信心便會增加。若結果分歧，便表示有些條件需要更仔細檢視。供應商行為、執行設定及量度細節，會成為研究問題，而不是方便的解釋。

重現並不要求每個數字完全一致。關鍵在於結論能否經得起合理的重複量度。除非有額外證據支持區分，接近的結果就應維持接近。

第三個訊號，是在陌生工作上按明確的無人監督成功準則取得的表現。這意味著檢查代理是否完成所要求的任務、驗證結果，以及適當處理失敗。人手介入應被記錄，因為它會改變「自主完成」的含義。

若在這類工作上有一致改進，將加強排行榜發現的實際重要性。若收益只限於熟悉的 benchmark 任務，其相關性便會收窄。這項分別對部署的重要性，勝過整體平均值再有一次小幅變動。

對現時選擇軟件的團隊而言，證據支持在實際配對層面進行比較。Kimi Code、Hermes Agent、Pi、Claude Code、Codex 及 mini-swe-agent，都值得按團隊打算使用的設定進行評估。單憑名稱不足以決定結果。

Niklaus harness 排行榜提供了這種評估的公開起點，包括推出結果、重複嘗試及可存取的紀錄。它的長遠貢獻，取決於這些量度能否協助解釋及改善代理行為。

在改變你的編碼工作流程前，應以具代表性的維護工作，把候選配對與你已信賴的設定作比較。記錄確切設定、完成證據、審閱者投入，以及需要介入的失敗情況。納入那些即使有看似合理的 patch，卻仍須通過驗證步驟才算足夠的任務。在有意義的 harness 更新後重新檢視比較，並保留較早結果，使變更仍可理解。把公開排行榜視為決策證據，同時讓你自身的工作流程作最終判斷。值得回答的問題很具體：在你實際可提供的監督下，哪個經測試的組合能交付你的團隊可以驗證、重複並接受的工作？