理解 Agent 評估中的基礎設施噪聲：區分代碼錯誤、環境故障與資源約束，分析 CPU、內存和時間預算怎樣影響執行，再用對照實驗與完整報告解釋分數差異。
上一篇討論了測試題能不能提供有效區分。題目有區分度之後，還需要確認另一件事：測出來的差異，究竟來自 Agent，還是來自運行條件？
假設兩個 Coding Agent 的通過率分別是 61% 和 63%。只看分數，後者似乎更強；但如果前者經常遇到容器退出，後者擁有更多內存和更寬鬆的超時，兩個數字就不能直接解釋為模型能力的差距。
Anthropic 的《Quantifying infrastructure noise in agentic coding evals》用資源配置實驗討論了這個問題。沿着它提出的測量問題，本文分三個層次整理：
- 失敗歸因： 區分 Agent 的判斷錯誤、環境故障，以及策略與資源預算之間的關係。
- 運行條件： 理解資源分配、限制方式、時間與併發怎樣改變執行過程。
- 實驗比較： 怎樣控制變量、處理重複運行和異常，報告可以解釋的結果。
下面用一個自擬的代碼修復任務貫穿説明：修復項目中的 CSV 解析問題，並運行測試確認修改。場景與配置例子用於解釋機制，不是實際跑出的 Benchmark 成績。
一、評估分數與失敗怎樣歸因h2
Coding Agent 不只交出一段答案。它會讀取項目、安裝依賴、修改文件、啓動測試，再依據輸出繼續行動。環境參與了這條執行鏈，也就參與了最終結果。
1. 測量對象：模型能力與端到端表現h3
同一個模型，配上不同工具、指令和運行環境，可能得到不同成績。因此首先要明確，比較的對象是什麼。
如果要比較兩個模型在相同條件下的解題能力，Harness、任務、工具和資源預算就應該儘量一致。否則，換模型的同時也換了工作條件，很難知道差異由誰帶來。
如果要比較兩套完整 Agent 系統的實際表現，不同的 Harness 或資源安排可以是方案的一部分。例如，一套系統用更好的緩存降低安裝開銷，這本身有工程價值。但結論應當是“這套系統在這組條件下表現更好”，而不是直接歸為“模型更聰明”。
回到 CSV 修復任務：成功意味着最終代碼通過約定的檢查。模型是否找對原因、執行環境是否跑得動測試、評分程序是否拿到完整結果，都會影響這一次成功能否發生。成績可以評價整個執行鏈；要解釋某個組件，就需要進一步控制其他組件。
2. 失敗分類：能力錯誤、環境故障與資源約束h3
看到一個失敗記錄，先找導致任務中斷的證據，再決定歸類。
| 任務中的現象 | 初步判斷 | 需要繼續確認什麼 |
|---|---|---|
| Agent 把帶引號的分隔符也當成列邊界 | 代碼或判斷錯誤 | 測試輸入、修改內容和實際輸出 |
| 工作容器沒有啓動，Agent 尚未獲得項目 | 環境故障 | 調度、鏡像和啓動日誌 |
| Agent 啓動大量並行測試後內存不足 | 策略與預算共同作用 | 資源限制、進程峯值和任務約定 |
| 測試超時，只有一條退出記錄 | 暫時無法歸因 | 程序是否死循環、CPU 是否受限、等待發生在哪裏 |
第三類尤其重要。資源相關錯誤並不天然獨立於 Agent：無節制地創建子進程可能是策略問題；正常步驟因宿主機故障被打斷，則是另一回事。只有一個 OOM 或 timeout 標籤，證據還不夠。
歸因也不必強行二選一。可以先記錄“內存限制下終止”，再標註已確認的原因與未知部分。這樣既保留了任務未完成的事實，也沒有把不確定的原因寫成模型缺陷。
二、資源與運行條件怎樣影響結果h2
運行條件有兩種作用：一是讓相同工作能否穩定完成，二是決定哪些工作方式實際可行。前者關係到測量噪聲，後者關係到測試本身的難度和範圍。
3. Requests 與 Limits：資源分配和限制方式h3
“給容器 2 個 CPU、4 GiB 內存”還不夠明確。這些數字是調度時申請的資源，還是運行時不允許超過的上限？
以 Kubernetes 為例，requests 主要參與調度和資源分配；節點有可用資源時，容器的實際使用量可以超過 request。limits 則限制運行時使用：CPU 通常通過節流限制執行速度，內存限制在壓力下可能觸發 OOM 終止。不能把 CPU 超限也統一理解為立即殺死進程。 具體語義見 Kubernetes 資源管理文檔。
例如，下面是解釋兩者區別的配置片段，不是通用的評估推薦值：
resources: requests: cpu: "2" memory: "4Gi" limits: cpu: "4" memory: "8Gi"申請量與上限之間留出了空間，但這不意味着容器始終獨佔 4 個 CPU，也不保證每次都能獲得相同的額外資源。宿主機負載與資源競爭仍然需要關注。
所以，復現一場評估，既要記錄配置數字，也要記錄這些數字怎樣被執行。相同的名義配置，不一定對應相同的運行條件。
4. Resource Headroom：運行穩定性與策略空間h3
Headroom 是基礎分配之外允許使用的資源餘量。它為什麼會影響通過率，可以沿着兩個方向看。
第一種影響是減少意外中斷。 修復方案和測試步驟沒有變化，只是依賴安裝或測試啓動的短暫峯值不再導致終止。這時更多執行記錄能夠完整結束，但不代表這些記錄最後都會通過。
第二種影響是改變可用策略。 原本跑不動的大型依賴、全量分析或並行測試，現在可以運行了。Agent 獲得的不只是穩定性，還獲得了不同的解題空間。
Anthropic 在 Terminal-Bench 2.0 上固定模型、Harness 和任務，比較了六種資源配置：最嚴格到不設上限的成功率相差約 6 個百分點。基礎設施錯誤率從 1x 的 5.8%，降到 3x 的 2.1%，再降到無上限時的 0.5%。但 1x 到 3x 的成功率差異未達到統計顯著；3x 到無上限的成功率卻又提高了約 4 個百分點。錯誤率下降和成功率上升，不是一一對應的關係。 這些數字及其範圍來自原文實驗，3x 不是適用於所有任務的標準配置。
在 CSV 場景裏，小規模測試可能用標準庫就足夠；Agent 也可能安裝較重的數據處理依賴，再加載完整數據集驗證。不同預算下，後一條路線未必都可行。如果測試本來就要求低內存運行，那麼資源效率是被測能力的一部分，不能把失敗一律當作噪聲消除。
5. 時間、併發與網絡：執行預算的其他條件h3
相同的內存上限，還不能保證相同的完成機會。
假設任務有固定的總時限。Agent 先等待依賴下載，再等待模型響應，最後才啓動測試。等待時間變長，留給實際調試的時間就變少了；即使沒有出現顯式網絡錯誤，結果也可能受影響。
時間預算因此要説明計時邊界：從容器啓動，還是從 Agent 接到任務開始？是否包含初始化、排隊、工具等待和重試？只寫“十分鐘”，讀者無法判斷兩次運行是否真的等價。
併發也有類似問題。同一台機器上同時運行更多任務，可能帶來 CPU、磁盤和網絡競爭。一次獨佔運行與一次高併發運行，就算容器配置相同，也可能面對不同的實際吞吐。
這些因素不是要求評估擁有完美環境，而是提醒我們：環境條件需要成為實驗記錄的一部分，而不是分數出來之後才尋找的解釋。
三、怎樣比較實驗並報告可信結果h2
把環境影響列出來之後，下一步不是一味增加資源，而是讓比較對象、控制條件和結論對應起來。
6. 對照實驗：固定條件與校準資源h3
比較模型版本時，儘量保持任務、項目快照、工具、Harness、評分規則和運行預算一致。研究資源影響時，則固定模型與其他設置，只調整明確的資源變量。
仍以 CSV 修復為例，可以先檢查項目在指定配置下能否正常安裝、啓動和運行既有測試，再觀察 Agent 執行時的峯值、錯誤類型與軌跡。這能幫助區分“基礎環境就無法工作”和“Agent 選擇了一條過重路線”。基線跑通並不保證所有路線都跑得通，但能排除一部分明顯的配置問題。
需要校準餘量時，小步調整並同時觀察兩類結果：意外終止是否減少，以及策略與成功率是否發生變化。若測試已經允許完全不同的重型路線，就不能只把變化描述成“修復了環境噪聲”。
資源更寬鬆不一定不公平，資源更嚴格也不一定更科學。關鍵是預算是否符合測量目標，兩個方案是否在約定條件下接受比較。
7. 重複運行：隨機波動與系統偏差h3
同一個任務多跑幾次，可以觀察 Agent 的隨機性與偶發運行異常；把運行分佈到不同批次，也能減少某一次服務波動主導結果的風險。
但重複運行不能自動解決系統性差異。如果 A 始終在較小內存下運行，B 始終擁有更多資源，重複一百次只會更穩定地測出這兩套條件的差別，不會把它變成純模型比較。
比較時應保留每個任務、每次 Trial 的結果，儘量讓兩個方案經歷相近的運行批次和負載條件，再看總體差異與任務級變化。只對失敗的一方無限重跑，直到它通過，測到的就不再是原來約定的單次表現。
統計區間可以反映所用方法覆蓋的抽樣不確定性，不會自動包含未控制的環境偏差。因此，“多跑幾次”與“控制運行條件”是互補關係，不能互相代替。
8. 異常處理：失敗分類、重跑與分母h3
環境異常怎麼處理，應當在看到成績之前確定，而不是為了某個結果臨時調整。
例如，容器尚未啓動就遇到已確認的宿主機故障，可以按預先約定重跑；Agent 已經修改項目後再重跑，則還需要恢復初始快照，避免繼承前一次留下的文件或緩存優勢。原始失敗、重跑原因和重跑結果都應保留。
如果報告排除了某些運行，至少同時交代：總共嘗試多少次、排除了多少次、排除依據是什麼，以及哪些失敗仍然計入成績。不同分母的通過率不能悄悄當成同一個指標比較。
同樣，環境錯誤減少 3 個百分點，不意味着成功率應該補回 3 個百分點。被打斷的任務繼續運行之後，仍然可能解錯。不能用錯誤率給最終分數直接做加法修正。
9. 結果報告：把成績與實驗條件一起交付h3
一份便於複核的結果，可以把下面幾組信息與成績放在一起：
- 被測方案： 模型版本、指令、工具與 Harness 版本。
- 任務與判分： 任務集版本、初始項目狀態、Grader 與成功標準。
- 運行預算： CPU、內存、申請量和上限、超時計時規則、併發與網絡條件。
- 執行記錄： Trial 數量、運行批次、錯誤分類、排除和重跑策略。
- 比較結果： 通過率、任務級變化，以及統計方法對應的不確定性。
這不是為了給每個分數附上一份運維手冊，而是保留影響判斷的條件。讀者應當知道，自己看到的是同一預算下的模型比較，還是不同資源成本下的系統比較。
於是，面對開頭的 61% 與 63%，可以先核對條件，再看差異是否穩定、集中在哪些任務、有沒有對應的執行證據。不能僅憑兩個百分點就確認優勢，也不能反過來規定“小於某個數的差異都無效”。分差的意義來自實驗條件與證據，不來自一個脱離任務的固定門檻。
幾個關鍵問題，串起失敗歸因與實驗比較h2
任務因為 OOM 失敗，就能排除為基礎設施問題嗎？
不能。需要看內存限制、使用峯值、執行步驟，以及任務是否本來就要求資源效率。正常運行被異常打斷，與 Agent 選擇了超出預算的策略，是不同情況；證據不足時應保留不確定歸因。
環境錯誤率下降，為什麼通過率不一定等幅上升？
減少中斷只讓任務有機會完整結束，不保證解題正確。一部分被恢復的運行最後仍會失敗。因此錯誤率與成功率應分別報告，不能直接相加或互相抵扣。
為什麼給兩個模型寫上相同的 CPU、內存數字，還不夠？
數字可能分別指申請量和上限，執行方式也可能不同。CPU 節流、內存終止、宿主機競爭與併發負載都會影響實際運行。需要比較配置含義和執行條件，而不只是名義規格。
增加資源是在去除噪聲，還是改變考試？
兩種情況都有可能。如果相同路線只是少了意外中斷，主要改善的是穩定性；如果大型依賴、重型測試或並行探索因此可行，策略空間也變了。判斷時要結合軌跡和資源使用，而不只看分數。
把評估多跑幾遍，能解決環境不公平嗎？
不能。重複運行有助於觀察隨機波動，但不會消除始終存在的預算差異。比較模型時需要控制環境；比較完整系統時則應把環境配置與成本一起報告。
面對一個小幅領先，應該怎樣下結論？
先確認測量對象和運行條件是否匹配，再檢查樣本、重複結果、錯誤分類與任務級變化。證據支持到哪裏，結論就寫到哪裏：在特定配置下表現更好，不自動等於在所有環境下都更強。