同一個 AI 模型，帳單為何差很多？從 Harness tax 看懂程式代理的成本
Arena 分享代理周邊系統對成本的影響。從工具呼叫、重試與完成標準，讀懂同一模型為何產生不同帳單。
團隊替 AI 程式代理挑模型，往往先看排行榜，再看每百萬字詞的價格。正式使用後卻可能發現，選了同樣的模型，不同工具跑出的帳單差很多。有的代理很快修改完，有的會反覆搜尋、讀檔和測試。差異發生在工作流程，單看模型價格很難解釋。
Arena 在 2026 年 9 月分享 UC Berkeley 研究者 Melissa Pan 的討論，聚焦隱藏的 Harness tax。官方貼文查核時已有超過七萬次瀏覽，並指出一項研究發現：周邊系統的選擇，對成本的影響比對準確性的影響更大。這是特定研究的發現，不宜直接套成每種任務的定律。
我的判斷是：比較 AI 代理，應從「成功完成一項工作要花多少」開始。模型只是整套系統的一部分。讀取什麼資料、能使用哪些工具、何時重試、怎麼確認完成，都會改變實際花費。把這些條件放進比較，才知道便宜的單次呼叫是否真的帶來便宜的成果。
Harness 是代理做事所需的周邊系統
Harness 可以理解成包在模型外面的工作安排。模型負責判斷下一步，周邊系統負責提供資料、執行工具、保存狀態與回傳結果。以修改網站為例，模型可能需要先讀檔案，再改程式、執行檢查，最後整理交付。這些步驟共同構成代理的實際行為。
同一個模型接到不同安排，可能採取不同路徑。某套系統先提供相關檔案，另一套讓代理自己從整個專案搜尋。某套會把測試失敗的重點整理好，另一套送回大量完整紀錄。模型能力相同，接收到的資訊與能做的動作仍會不同，後續呼叫次數也可能改變。
因此，Harness tax 這個名稱適合提醒我們注意額外負擔，但它不是一筆實際向政府繳交的稅。這裡指的是周邊設計所帶來的成本影響。本文依官方公開摘要說明這個議題，沒有重跑研究，也不根據未取得的完整數據宣稱哪一款代理普遍勝出。
對一般使用者，最容易觀察的是代理做了幾次相似的事情。如果同一個檔案被反覆讀取、同一段錯誤不斷重試，可能值得檢查流程。不過呼叫較多也可能有必要，例如一次修改牽涉多個模組。判斷是否浪費，仍需對照任務範圍與每一步取得的進展。
單次價格之外，還有整條執行路徑
模型服務常用輸入與輸出字詞計費，字詞也常稱為 token，是系統處理文字的單位。代理每次把資料送給模型，都可能形成新的輸入成本。工具回傳的內容若被納入下一輪，也可能增加用量。只看最後回覆很短，無法得知中間花了多少。
假設兩個流程都修改同一個按鈕。一個先讀相關元件，再完成一次檢查。另一個先掃描整個專案，接著反覆請模型解釋相同錯誤。這是理解成本的假想例子，沒有對應本文實測數據。它說明整條路徑的資料量與呼叫次數，可能比最後產物的長度更有影響。
除了模型費用，工具本身也可能需要付費。例如雲端執行環境、外部搜尋與資料服務，都有自己的計價方式。若代理同時啟動多個環境，應把這些支出放進任務總帳。工具成本若由不同帳號分開計費，容易在比較時被漏掉。
時間也要分清楚。代理等待遠端服務的時間，和使用者修改錯誤的時間，對團隊影響不同。某個流程帳單較低，卻需要工程師反覆補充指令，實際人力成本可能較高。事先定義要比較的項目，才能讓報表中的「較省」有清楚意義。
上下文愈長，未必讓代理更瞭解問題
上下文是模型這一輪能看到的資訊。把更多檔案與紀錄放進去，有時能補足判斷，有時只是增加不相關資料。對一個小修改，完整專案歷史未必有幫助。資料量應由問題決定，不能把能塞進模型的最大長度，當成每次都應使用的目標。
先提供任務需要的檔案，再依缺口補充，是一種可評估的做法。重點在於保留取得其他資料的路徑，避免資料太少讓代理猜測。如果測試失敗指出另一個元件，代理應能追查該元件。縮短輸入與限制調查是不同概念，前者要靠選擇資訊，後者會影響完成能力。
工具結果也值得整理。大量成功訊息中只有一行錯誤，直接全部回傳可能讓關鍵資訊難找。但摘要不能刪掉會改變判斷的內容，例如實際檔名、錯誤位置與執行條件。比較不同整理方式時，可以檢查代理是否更快找到原因，以及是否產生新的誤判。
對使用者，可以觀察代理是否知道目前已確認哪些事情。若每一輪都重新調查已完成項目，狀態保存可能不足。把已確認結果、未解決問題與下一個檢查保留下來，有助於延續工作。這項安排是否有效，仍要用實際任務觀察，不能只看介面顯示有記憶功能。
Arena 分享 Melissa Pan 對代理周邊系統成本的研究討論片段。完整影片連結列於文末。 影片來源：Arena.ai 官方 X。
重試要帶來新資訊，才值得繼續花費
測試失敗後重試很常見，但重試本身沒有保證會進步。若代理沒有理解原因，只改幾個字就再次執行，可能形成循環。有效的重試應有新的假設或新的證據，例如確認依賴版本、定位資料型態，或縮小失敗條件。每次嘗試都應說明解決哪個缺口。
可以替任務設定停止條件。連續幾次沒有新增證據、超過預算或遇到需要使用者決定的需求時，應留下清楚狀態。停止不代表任務完成。交付應列出已做部分、仍未解決的問題，以及繼續需要什麼。這樣使用者才能決定下一步，避免付費循環默默延續。
工具故障也應和程式錯誤分開。環境沒有啟動、服務暫時無法連線，未必需要修改程式。若代理把所有失敗都當成程式有問題，可能增加不必要變更。紀錄中保留執行狀態與實際錯誤，能幫助判斷應重啟工具、調整環境，還是修正實作。
預算上限應對應完整任務，而非只限制單次呼叫。每次都便宜，累積多次仍可能超支。工具與模型費用最好能關聯到同一個任務編號，讓使用者看到花費到了哪一步。若系統只能顯示整月總額，就較難查出哪一類流程最值得改善。
成功必須由可檢查的產物定義
一個代理說自己完成了，不足以成為成本比較的成功標記。程式任務應有可檢查的修改與相關驗證。內容工作應有符合要求的文件。資料整理應能對回來源。只有先定義成功，才有分母可以計算每項成功工作的平均成本。
對小型修正，檢查應對準受影響的行為。執行大量與修改無關的測試，可能增加時間卻沒有補足證據。相反地，只檢查程式能開啟，也可能漏掉真正問題。驗證範圍要由變更影響決定，再把必要檢查的成本算入比較，不能為了讓帳單好看而省略完成條件。
失敗任務的支出也應納入。如果只計成功那幾次的帳單，經常失敗的流程可能看起來異常便宜。可以同時呈現成功率、總花費與人工接手時間。這樣一個模型或代理的優勢，才不會靠排除失敗例子形成。
使用者修正結果的時間尤其重要。代理產出的修改能通過初步檢查，仍可能不符合原始需求。把這類交付標記為需要重做，能避免「完成」狀態被過度放寬。比較時應採用共同標準，由同樣的需求描述和覆核方式判斷，才有公平的結果。
比較代理，先固定任務與環境
想評估兩套代理，可以挑一組具代表性的已知任務，事先寫出預期結果。每次從相同專案狀態開始，使用相同資料與必要工具。若一套拿到更多提示、另一套缺少測試環境，最後差異就包含額外條件，不能全部歸因於代理設計。
模型版本與設定也需要留下紀錄。服務更新後，同名模型的實際行為可能改變。比較如果分散在不同時間，應說明版本與執行日期，並保留輸入和工具紀錄。這些資訊不一定都要公開，但必須足夠讓團隊理解結果的適用範圍。
任務種類應分開看。小型介面修改、跨模組修復與資料查詢，可能需要不同流程。一個總平均容易遮住差異。先看哪些任務省時、哪些容易重試，再決定要不要為不同工作選擇不同工具，通常比找一個所有情況都使用的冠軍更實際。
正式導入也可以逐步擴大。先比較低影響、容易確認的工作，看到穩定成果後再接更複雜任務。每一階段都保留成本與錯誤紀錄。若條件改變，就重新檢查受影響部分，避免把早期試做的成績延伸到沒有測過的工作。
使用者的提示方式同樣會改變成本。如果一開始只說修好網站，代理需要花時間查明問題。如果提供可重現步驟、預期行為與實際結果，調查可以更集中。比較工具時應固定需求描述，日常使用則可先整理這些資訊。清楚的輸入既能幫助人類工程師，也能降低代理花在猜測需求上的時間。
最後，應區分一次性的設定費用與持續成本。第一次建立環境、下載依賴或整理專案說明，可能較慢，但後續工作可以沿用。如果只測第一次，會低估穩定使用的效率。如果只測熱身完成後，又可能漏掉新專案的啟動負擔。把兩種條件分開記錄，就能知道工具適合長期維護同一專案，還是經常切換不同工作。
常見問題
換更便宜的模型，一定能降低總帳單嗎？
不一定。較低單價可能伴隨更多呼叫、重試或人工接手。應比較相同完成標準下的總花費，並記錄失敗任務。模型價格是其中一項，不能單獨代表整個工作流程的成本。
工具呼叫愈少，就代表代理設計愈好嗎？
要看是否取得必要證據。少呼叫卻漏掉關鍵檔案與測試，可能只是把工作留給使用者。合理目標是每一步對完成任務有用，並避免沒有新資訊的重複執行。必要驗證仍應完成。
Arena 的摘要能證明哪一款代理最便宜嗎？
官方貼文公開一項研究發現，並連結完整影片。它提醒我們周邊系統會影響成本，不能由這段摘要推定某產品在所有任務都勝出。具體選擇仍需對照自己的任務、環境與成功標準。
下一次選代理，把整個任務放進成本表
Harness tax 讓 AI 工具比較多了一個必要問題：模型外面的系統，花了多少力氣讓工作完成？合理的搜尋、重試與驗證有價值，但沒有進展的循環也會累積費用。使用者需要能看見這些步驟，才有機會改善流程。
下一步可以挑三種日常程式工作，記錄總花費、完成時間、必要檢查與人工修改時間。比較時使用相同起點與標準，再查看反覆讀檔或重試最常發生在哪裡。這份紀錄會比單一模型價格，更接近你真正需要支付的工作成本。
