每題跑 8.8 次測試，禁止它跑只差 1.25 個百分點：coding agent 的測試執行，該當成預算來管

Agent 平均每題跑 8.8 次測試；禁止執行，商用 agent 解題率只差 1.25pp，不顯著

AI Academy 編輯部2026年10月28日
本文目錄（15 節）▾
  1. 這篇文章適合你，如果你是…
  2. 1. 前言：問題場景（約 600 字）
  3. 1.5 TL;DR
  4. 2. 核心概念：執行是資源，不是能力（約 700 字）
  5. 3. 證據：三份研究，同一個方向（約 2,300 字）
  6. 4. 決策框架：你的 agent 該有多少測試預算（約 700 字）
  7. 5. 實戰最佳實踐（約 550 字）
  8. 6. 實作：Claude Code 測試預算 hook（約 400 字）
  9. 7. 效能調優：讓剩下的那幾次跑得值得（約 300 字）
  10. 8. 工具與資源（約 250 字）
  11. 9. 總結與展望（約 400 字）
  12. 金句
  13. 延伸思考
  14. FAQ
  15. 參考資料

這篇文章適合你，如果你是…

  • 每天用 Claude Code、Codex 修 bug 的工程師：你看過 agent 跑十幾次 pytest 才交卷，想知道這些時間和 token 換到了什麼。
  • 管 agent 用量和帳單的技術主管：你想壓成本，但怕一限制就掉品質，這篇給你三份研究的對照數字。
  • 在設計內部 agent harness 的架構師：你要決定「驗證」這一步放在哪、由誰做，這篇給你一個可以直接套的框架。

1. 前言：問題場景（約 600 字）

Hook 開場

我們的內容系統裡有一批產圖、排程、發文腳本，大多是我跟 coding agent 一起修出來的。有一陣子我開始注意 session 的時間都花在哪：agent 改完一行，跑一次測試；看到某個無關的警告，再改一點，再跑一次。十幾分鐘後它交卷說「全部通過」，我 review 一看，真正有用的改動就是一開始那一行。

我當時的直覺是：讓它多跑幾次比較保險，慢一點沒關係。

從系統角度看，這個直覺有個沒被檢查的假設：「agent 跑的測試」和「判斷對錯需要的測試」是同一組。如果不是同一組，多跑幾次只是在同一張考卷上反覆對答案。而每跑一次，測試輸出整段進 context，下一輪推理要重讀；agent 看到輸出又會想改點什麼。成本是確定的，收益要看那張考卷出得好不好。

數據佐證

ISSTA 2026 的一篇論文直接拿數字回答了這個問題。研究團隊先分析 SWE-bench 排行榜上 7,745 條公開的 agent 軌跡，發現 agent 平均每題跑 8.8 次測試，最多的組合跑到 18.7 次。接著他們用 Claude Code、Codex、OpenCode 做了 3,000 次對照實驗：禁止跑測試，商用 agent 的解題率平均只差 1.25 個百分點，沒有任何一格達到統計顯著；Claude Code 卻省下 56–62% 的 token 和一半的時間。

解決方案預告

這篇不是要你把測試關掉。研究裡最重要的數字其實是另一個：失敗的案例裡，有 81–100% 在 agent 自己的驗證中是通過的。問題不在「跑幾次」，而在「誰出題、什麼時候跑」。我會用三份研究拆解這件事，最後給一個可以直接放進 Claude Code 的測試預算 hook。

文章承諾

  • 三份 2026 研究的完整數字與它們的邊界（哪些能說、哪些不能說）
  • 同一招在 Claude Code 省六成、在 Codex 幾乎沒差：為什麼
  • 「執行預算」的決策框架與 5 個場景
  • 一個實測過的 Claude Code PreToolUse hook

讀者收穫

讀完這篇文章，你將能夠：

  1. 判斷你的 agent 現在的測試執行，是在發現問題還是在確認它已經相信的答案
  2. 依模型強弱與任務類型，設定合理的測試預算
  3. 把「驗收」從 agent 手上拿回來，交給它沒挑過的那組測試

1.5 TL;DR

  • Agent 平均每題跑 8.8 次測試；禁止執行，商用 agent 解題率只差 1.25pp，不顯著
  • Claude Code 禁止執行省 56–62% token、48–54% 時間；Codex 本來就少跑，限制幾乎沒差
  • 失敗案例裡 81–100% 自己的驗證是綠的：agent 的綠燈不是驗收
  • 小模型例外：給 1 次配額最好，放任反而塞爆 context
  • 做法：給預算、放後面、驗收交給 CI 跑它沒挑的測試

2. 核心概念：執行是資源，不是能力（約 700 字）

一個比喻

想像你請一位資深工程師修一個 bug，他有兩種工作方式。第一種：讀 issue、讀程式碼、想清楚、改一處、送 PR，讓 CI 跑完整測試。第二種：讀一點、改一點、跑一次、看輸出、再改一點、再跑，直到自己挑的那幾個測試變綠。

第二種看起來比較勤勞，但如果他挑的測試沒有覆蓋 bug 的真正條件，綠燈只代表「他的假設自洽」。第一種把驗收交給一組他沒挑過的測試，反而比較誠實。

Coding agent 預設是第二種。

執行的三種成本

成本怎麼產生誰在付
Token每次輸出整段進 context，之後每一輪都重讀帳單、額度
時間測試本身的執行時間＋多出來的推理輪數開發者的等待
環境維運每個 repo 都要準備一套 agent 跑得動的測試環境平台團隊

第三項常被忽略。論文作者特別指出，禁止執行模式「removes the need to maintain per-repository test environments」。如果你在雲端跑大量背景 agent，環境準備可能是最貴的那一項。

為什麼直覺會錯

「跑了比較可靠」成立的前提是：測試能區分對與錯，而且輸出能指向下一步。這兩件事 agent 都不保證。它挑的測試通常是它認為相關的，那份「認為」和它寫 patch 時用的是同一套理解。理解錯了，patch 錯，挑的測試也會跟著錯。

關鍵術語

術語英文說明
解題率Resolve rateSWE-bench 官方隱藏測試通過的比例
自我驗證Agent-executed validationagent 自己挑、自己跑的測試或腳本
官方評測Official evaluationbenchmark 準備好、agent 看不到的測試
執行後修改Post-execution modification跑完測試後又去改程式碼
工具面Tool surfaceagent 能用的工具組合
McNemar 檢定McNemar's test同一批題目在兩種條件下成敗差異的檢定

3. 證據：三份研究，同一個方向（約 2,300 字）

3.1 To Run or Not to Run：先看大家實際跑多少

這篇論文由北京航空航天大學、武漢大學與新加坡管理大學團隊發表（Lin et al.，ISSTA 2026）。第一階段他們收集 SWE-bench Lite 和 Verified 排行榜上 7,745 條公開軌跡，涵蓋 SWE-agent、OpenHands、LiveSWEAgent、Mini-SWE-agent 四種框架、12 個模型，從 GPT-4 到 Claude Opus 4.5、Gemini 3 Pro。

結果是：每一個 agent、每一個模型都會跑測試，平均每題 8.8 次，從 2.0 次（Mini-SWE-agent＋GPT-5.2）到 18.7 次（OpenHands＋Claude 4 Sonnet）。而且這只算 pytest、unittest 這類測試框架呼叫，python repro.py 這種腳本不算在內。

他們也看了執行的時機：大部分執行集中在對話後段，後段的執行跟成功的關聯比較高。例如 OpenHands＋Claude 3.5 Sonnet，前段執行的成功率 42%，後段 72%。（這是單一組合的例子，網路上有轉述把它寫成全體平均，並不正確。）

3.2 把執行拿掉，會怎樣

第二階段是對照實驗。題目是 Lite 和 Verified 各取前 100 題，三個 agent：

  • Claude Code（Claude Sonnet 4.5）
  • Codex（GPT-5.2，reasoning effort xhigh）
  • OpenCode（Qwen2.5-Coder-32B，本地 vLLM）

每題跑五種設定：禁止執行、配額 1 次、配額 3 次、預算提示（「可以跑，但每次都有成本」）、不限制。200 題 × 3 × 5，共 3,000 次。

解題率（%）

Agent／題庫禁止配額 1配額 3預算提示不限制
Claude Code Lite6361626364
Claude Code Verified6464656767
Codex Lite7468697173
Codex Verified7372737175
OpenCode Lite714796
OpenCode Verified1317111314

禁止和不限制之間，商用 agent 四格平均差 1.25 個百分點（不限制略高），McNemar 檢定沒有一格顯著。

Before／After：Claude Code 的帳單

不限制（Before）禁止執行（After）差異
Lite token（輸入/輸出）121K / 37K52K / 17K−56.4%
Verified token128K / 39K48K / 15K−62.3%
Lite 時間1,028 秒531 秒−48.4%
Verified 時間1,234 秒573 秒−53.6%
解題率64% / 67%63% / 64%−1 / −3pp

論文原文的結論是：「For Claude Code, Prohibited delivers the best cost-effectiveness, reducing tokens by 56–62% with only a 1–3pp resolve rate difference.」

有人會問：禁止只是寫在 prompt 裡，agent 偷跑怎麼辦？作者另外做了一組硬限制，用 --disallowedTools 直接擋掉 pytest 等指令，Claude Code 在 Verified 上是 63 vs 67（−4pp），省 62% token、54% 時間。方向一樣。

3.3 同一招，對 Codex 幾乎沒差

這是最容易被忽略、卻最實用的一點。Codex 那一欄的 token 差異：Lite −13.5%，Verified 只有 −0.9%。原因很簡單：那個版本的 Codex 本來就很少跑測試，禁止模式下每題嘗試執行的次數接近 0。你沒辦法省下本來就沒花的錢。對 Codex，論文找到的最佳點是配額 1 次，省 21–25% token。

所以「限制執行」不是一個通用旋鈕。它的效果取決於你的 agent 原本有多愛跑。在調之前，先量。

3.4 為什麼執行沒幫上忙

論文的第三個研究問題最值得讀，它拆了四個原因。

一、大部分題目結果根本不變。 600 對比較（200 題 × 3 個 agent）裡，547 對（91.2%）不管跑不跑，結果都一樣。執行讓失敗變成功的有 29 對，讓成功變失敗的有 24 對，淨差 5 對。作者的說法是：「Execution is not inherently unhelpful; its benefit is concentrated on specific instances.」

二、重現 bug 對定位沒幫助。 Claude Code 做了 164 次重現執行，只有 48.8% 給出可行動的回饋。在那些有可行動回饋的題目上，定位準確度是 93.5%，不跑的版本反而是 95.7%。

三、跑了就會繼續改。 跑完測試後又去改程式碼的比例，Claude Code 從 4.5% 跳到 67.5%，Codex 從 0% 到 31%。Claude Code 不限制模式用了 2.1 倍對話輪數、2.8 倍編輯、8 倍測試執行，成功率一樣。論文的描述很精準：對於靠推理就能解的 bug，執行只是「confirming an already-correct solution rather than enabling its discovery」。

四、它的綠燈不是官方的綠燈。 這是全篇我覺得最重要的數字。Claude Code 兩種模式都失敗的 80 題中，有 65 題（81.2%）至少有一次自己跑的驗證是通過的；Codex 是 52 題中的 52 題，100%。也就是說，agent 交卷時看到綠燈、真心相信自己做對了，而官方測試是紅的。

把第三點和第四點放在一起看，就是 agent 執行行為的完整畫像：它跑自己挑的測試，看到不順眼的就繼續改，改到自己挑的測試全綠，然後交卷。整個過程的「驗收標準」是它自己訂的。我們在〈綠燈是它自己出的考卷〉那篇談過 agent 寫的測試品質問題，這份研究補上了另一半：就算不談測試寫得好不好，光是「誰挑測試」就決定了綠燈的含金量。

3.5 小模型是例外

OpenCode 搭 32B 模型、65K context，結果完全不同：配額 1 次在 Lite 拿到 14%，不限制只有 6%。這是整份研究裡唯一排除 0 的信賴區間（paired bootstrap 90% CI [+5.9, +15.3]pp）。原因是不限制時，測試輸出把小 context 塞滿，能交出非空 patch 的比例從 74/100 掉到 50/100。不限制在 Verified 上要 3.1 倍 token 和 3.1 倍時間，只換到 1 個百分點。

小模型需要一點點回饋，但承受不了大量輸出。

3.6 研究二：換工具面，改變路徑，不改變答案

Rochester Institute of Technology 團隊（Yang, Yu, Desell，KDD 2026 SE 3.0 Workshop）做了另一種切法：不限制「跑不跑」，而是限制「用什麼工具」。三種工具面：agent 預設工具、只給 bash、只給一個 execute_code MCP 工具。兩種任務（計算型、SWE-bench 修改型）× 兩個 agent（Claude Code、Codex CLI）。

通過率在每一格都打平，差距不到 3 個百分點。成本卻差很多：計算任務上 Claude Code 只給 execute_code 便宜 24.6%（顯著），SWE-bench 上 Codex 便宜 19.9%（顯著），但 SWE-bench 上的 Claude Code 反而貴 14.4%（不顯著，作者追到原因是失敗軌跡拖得比較長）。

作者的一句話可以當這整個主題的總結：「Tool surface changes the path and the cost, not the answer.」

3.7 研究三：harness 設計，強模型和弱模型要反著調

UMass Amherst 與 Zoom 等團隊（Fan et al.，2026 年 9 月）在固定的 ReAct 迴圈下，對 4 個模型、SWE-Bench Verified 與 Terminal-Bench 2.1，跑了 176 組配對設定。和本題最相關的兩個發現：

  • 規劃（planning）對強模型是省錢工具，對弱模型是準確度支架。 Nemotron 550B 有規劃 65.8%／每題 $2.33，沒規劃 67.8%／$3.31，成本降約三成、準確度沒顯著差；30B 有規劃 25.2%，沒規劃只剩 13.6%。論文的章節標題直接寫：規劃縮短強模型的軌跡，靠的是「reducing post-edit verification」。也就是說，強模型被砍掉的那些輪數，主要就是改完之後反覆驗證。
  • 只給 bash，強模型更便宜，弱模型崩盤。 550B 只給 bash 是 69.4%／$1.11，成本約砍半；Mistral Medium 3.5 卻從 68.6% 掉到 45.4%。

另外有個值得抄的設計：他們的 harness 在 agent 改完 Python 檔後，自動跑 ruff、pyflakes 或語法檢查這類「快速、唯讀」的檢查，在花一輪跑測試之前先抓低級錯誤。

3.8 三份放在一起

研究改的是什麼準確度成本例外
To Run or Not to Run跑不跑測試差 1.25pp，不顯著Claude Code −56–62% token小模型要給 1 次配額
execute_code 消融工具面差距 <3pp−25% 到 +14%，看任務與 agentSWE-bench／Claude 變貴
Harness 設計規劃、工具、context 管理強模型幾乎不動強模型 −30% 到 −52%弱模型掉 12–23pp

三份研究、不同團隊、不同切法，方向一致：對強模型，改執行與驗證的方式，主要影響的是成本，不是答案；對弱模型，一點點回饋是救命的，太多是毒藥。

3.9 誠實的邊界

在拿這些數字去說服團隊之前，有四件事要講清楚：

  1. 模型不是最新的。 對照實驗用的是 Claude Sonnet 4.5、GPT-5.2。新模型的執行習慣可能不同，所以第 5 節第一步是「先量你自己的」。
  2. 任務是 Python bug 修復。 SWE-bench 的題目通常有清楚 issue、改動集中。新功能開發、跨模組重構、前端互動，執行的價值可能更高，目前沒有同等規模的數據。
  3. 每格 100 題。 「沒測到顯著差異」不等於「證明一樣好」。等價檢定（±5pp）只有 Codex Verified 這一格正式成立。
  4. 禁止多半是 prompt 軟限制。 硬限制那組結果方向相同，但只做了一格。

4. 決策框架：你的 agent 該有多少測試預算（約 700 字）

決策樹

你的 agent 每題平均跑幾次測試？（先量，見第 5 節）
├─ 幾乎不跑（<1 次）
│   └─ 限制沒意義 → 重點放在交卷後的獨立驗收
└─ 會跑（≥2 次）
    ├─ 用的是小模型／context ≤ 64K？
    │   └─ 是 → 配額 1 次 ＋ 過濾測試輸出（只回失敗摘要）
    └─ 強模型
        ├─ 任務是局部 bug、有清楚重現條件？
        │   └─ 是 → 預算 0–1 次 ＋ 改完跑 lint/型別 ＋ CI 跑完整測試
        └─ 任務是新功能／跨模組／需求模糊？
            └─ 預算 2–3 次，只在後段跑 ＋ CI 跑完整測試與回歸

所有分支的最後一步都一樣：驗收由 agent 沒挑過的測試決定。

場景案例

場景 A：雲端背景 agent 每天處理上百個小 issue

  • 環境：Claude Code headless，CI 上有完整測試
  • 需求：壓成本、壓排隊時間
  • 推薦：預算 0–1 次，交卷後由 CI 跑完整測試，失敗才把摘要丟回 agent 再試一輪
  • 理由：這就是論文 Claude Code 那一格的情境，token 可省五到六成；而且不用為每個 repo 準備 agent 專用的測試環境

場景 B：本地跑 30B 開源模型的內網 agent

  • 環境：單張 GPU、32K–64K context
  • 需求：資料不能出內網，準確度優先
  • 推薦：配額 1 次，測試輸出只回傳失敗的測試名稱與最後 30 行
  • 理由：OpenCode 的結果顯示小模型給 1 次配額最好，放任會讓輸出擠掉推理空間

場景 C：用 Codex 做日常修改，團隊抱怨額度不夠

  • 環境：Codex CLI，訂閱額度制
  • 需求：省額度
  • 推薦：先量測試次數；如果本來就少，限制省不了多少，應該從 context 管理和任務切分下手
  • 理由：論文中 Codex 禁止執行的 token 差異只有 −0.9% 到 −13.5%

場景 D：在大型前端專案加新功能

  • 環境：Claude Code＋Playwright
  • 需求：不能弄壞既有流程
  • 推薦：預算 2–3 次，只在完成實作後跑；交卷後跑完整回歸
  • 理由：這類任務不在現有研究範圍，執行可能有價值；但回歸檢查必須在 agent 之外（見〈第二個需求〉那篇）

場景 E：平台團隊在設計內部 agent harness

  • 推薦：把「測試呼叫次數」「測試輸出 token」「最後一次執行在軌跡中的位置」變成每個任務的標準紀錄欄位
  • 理由：沒有這三個數字，你無法判斷任何一個旋鈕的效果

5. 實戰最佳實踐（約 550 字）

常見錯誤正確做法
把「agent 有跑測試、全綠」當成品質訊號只把 CI 跑的完整測試當驗收；agent 的綠燈當作參考
一開始就讓 agent 跑整套測試先規劃、改完跑 lint／型別檢查，最後才跑一次測試
對所有 agent 用同一套限制先量每個 agent 的平均執行次數，再決定要不要限制
只寫在 prompt 裡「不要跑太多測試」用 hook 或 --disallowedTools 做硬限制
測試輸出原封不動回給 agent只回失敗測試名稱、assert 訊息、最後幾十行
只看解題率比較設定同時看 token、時間、環境維運成本

四個步驟

  1. 量：一週內記錄每個任務的測試呼叫次數與輸出長度。Claude Code 的 session transcript（JSONL）裡就有每次 Bash 呼叫，可以用腳本統計。
  2. 定預算：依第 4 節決策樹給一個數字，用下一節的 hook 落地。
  3. 把驗收搬出去：agent 交卷 → CI 跑完整測試＋回歸 → 失敗才把摘要回給 agent。這一步讓「出題的人」和「答題的人」分開。
  4. 兩週後回看：比較預算前後的 token、時間、退回率。數字說話，不靠感覺。

第三步其實才是重點。前兩步省的是錢，第三步修的是 81–100% 那個問題：只要 agent 自己決定什麼叫通過，它跑幾次都一樣。

6. 實作：Claude Code 測試預算 hook（約 400 字）

Claude Code 的 PreToolUse hook 會在每次工具呼叫前，把呼叫內容以 JSON 傳進 stdin。hook 以 exit code 2 結束時，該次呼叫會被擋下，stderr 的內容會回給 agent。我們用這個機制，讓同一個 session 的測試執行超過預算就擋下，並提示它改用推理。

.claude/hooks/test_budget.py：

#!/usr/bin/env python3
"""Claude Code PreToolUse hook：限制每個 session 的測試執行次數。"""
import json
import os
import re
import sys
from pathlib import Path

# 預算可用環境變數調整，預設 2 次
BUDGET = int(os.environ.get("AGENT_TEST_BUDGET", "2"))
# 視為「測試執行」的指令，依專案自行增減
TEST_PATTERN = re.compile(
    r"\b(pytest|py\.test|unittest|tox|nosetests|manage\.py\s+test"
    r"|npm\s+(run\s+)?test|pnpm\s+test|go\s+test|cargo\s+test)\b"
)

def main() -> None:
    event = json.load(sys.stdin)
    if event.get("tool_name") != "Bash":
        sys.exit(0)
    command = event.get("tool_input", {}).get("command", "")
    if not TEST_PATTERN.search(command):
        sys.exit(0)

    # 每個 session 一個計數檔，避免不同任務互相干擾
    session = event.get("session_id", "unknown")
    counter = Path(os.environ.get("TMPDIR", "/tmp")) / f"claude-test-budget-{session}.json"
    used = json.loads(counter.read_text())["used"] if counter.exists() else 0

    if used >= BUDGET:
        # exit 2：擋下這次呼叫，stderr 會回給 agent
        print(
            f"測試預算已用完（{used}/{BUDGET}）。請根據已讀過的程式碼推理修正，"
            "完成後直接交卷，CI 會跑完整測試。",
            file=sys.stderr,
        )
        sys.exit(2)

    counter.write_text(json.dumps({"used": used + 1}))
    sys.exit(0)

if __name__ == "__main__":
    main()

.claude/settings.json：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "python3 .claude/hooks/test_budget.py" }
        ]
      }
    ]
  }
}

本機模擬測試結果：ls 放行；第 1、2 次 pytest 放行；第 3 次 npm test 被擋下並回傳提示。

注意：這是 regex 比對，agent 可以用 python -c 之類的方式繞過。它的定位是「預設行為的護欄」，不是安全邊界。真正的驗收仍在 CI。

7. 效能調優：讓剩下的那幾次跑得值得（約 300 字）

  1. 改完先跑快速檢查：仿照 harness 研究的設計，改完 Python 檔就跑 ruff check 或 python -m py_compile，Node 專案跑 tsc --noEmit。這些檢查秒級完成、輸出短，能擋掉大部分低級錯誤，不佔測試預算。
  2. 只跑相關測試，但驗收跑全部：agent 的那一兩次用 pytest tests/test_x.py -x -q；CI 跑全部。
  3. 壓縮輸出：pytest -q --tb=short、--maxfail=1。對小模型尤其重要。
  4. 把執行放後段：在 CLAUDE.md／AGENTS.md 寫明「先讀、先規劃、改完再驗證」。論文的軌跡分析顯示後段執行和成功的關聯較高。
  5. 失敗回饋要短：CI 失敗回給 agent 時，只給失敗測試名稱與 assert 訊息，不要貼整份 log。

8. 工具與資源（約 250 字）

工具／資源說明
To Run or Not to Run 實驗框架論文的四種執行模式實作，可在自己的題目上重跑
onlycodesexecute_code 消融研究的程式碼與資料
Claude Code hooks／--disallowedTools在工具呼叫前擋下或限制指令
SWE-bench官方評測 harness，可拿來建立內部基準
Ruff秒級的 Python lint，適合當「改完就跑」的檢查

9. 總結與展望（約 400 字）

一表看完

情境測試預算驗收
強模型＋局部 bug0–1 次CI 完整測試
強模型＋新功能／重構2–3 次，後段CI 完整測試＋回歸
小模型／小 context1 次＋壓縮輸出CI 完整測試
Agent 本來就少跑不用限制CI 完整測試

給不同讀者

  • 工程師：下週先量。打開 session 紀錄，數一數 agent 每題跑了幾次測試。
  • 技術主管：把「測試次數」「測試輸出 token」加進 agent 用量報表，它很可能是最好壓的一塊。
  • 決策者：agent 回報「測試全過」不是驗收。驗收流程要在 agent 之外。

未來趨勢

  1. 自適應執行：論文作者把「adaptive execution allocation」列為下一步，讓 agent 自己判斷這題值不值得跑。
  2. 驗證與實作分離：越來越多 harness 把驗證交給另一個角色或 CI，而不是同一個 agent。
  3. 成本成為一級指標：三份研究都把成本和準確度並列報告，benchmark 只報解題率的時代在結束。

今天就能開始的四步

  1. 統計過去一週 agent 每題的測試呼叫次數
  2. 裝上測試預算 hook，預算設 2
  3. 確認 CI 會在 agent 交卷後跑完整測試
  4. 兩週後比較 token、時間與退回率

金句

「agent 跑的測試，多半是在確認它已經相信的答案。」

「出題的和答題的是同一個人，綠燈就只是自洽。」

「限制執行之前先量：你省不下本來就沒花的錢。」

延伸思考

  1. 你的 agent 上一次「說測試全過但其實壞了」，它跑的是哪一組測試？那組測試是誰挑的？
  2. 如果明天把 agent 的測試預算設為 1 次，你的 CI 接得住驗收的責任嗎？
  3. 在你的團隊裡，哪一類任務是真的需要 agent 邊跑邊改，而不是想清楚再改？

FAQ

Q1：這是不是說 coding agent 不該跑測試？
不是。研究顯示執行的價值集中在少數題目上，而且對小模型很重要。結論是「別當預設、要給預算」，不是「關掉」。

Q2：實驗用的模型都舊了，結論還適用嗎？
方向大概率適用，數字不一定。新模型的執行習慣會變，這也是為什麼建議先量自己的 agent，而不是直接套用 56–62%。

Q3：禁止執行只寫在 prompt，agent 不會偷跑嗎？
會偶爾嘗試。作者另做了一組用 --disallowedTools 的硬限制，結果方向相同（−4pp、省 62% token）。

Q4：為什麼 Codex 限制後幾乎沒省？
因為當時那個 Codex 設定本來就很少跑測試。沒有花的錢省不下來。

Q5：81–100% 自我驗證通過是什麼意思？
在兩種模式都失敗的題目裡，Claude Code 有 81.2%、Codex 有 100% 至少跑過一次自己的驗證並看到通過，但官方測試是失敗的。

Q6：這跟「agent 寫的測試品質差」是同一件事嗎？
相關但不同。那是測試寫得好不好；這是誰決定跑哪些測試。就算測試本身寫得很好，agent 只挑自己認為相關的跑，還是會漏掉。

Q7：新功能開發也適用嗎？
目前沒有同規模數據。建議給較多預算、只在後段跑，並把回歸檢查放在 agent 之外。

Q8：測試預算 hook 安全嗎？
它是預設行為的護欄，不是安全邊界。agent 可以用別的指令繞過 regex，真正的把關仍是 CI。

Q9：除了測試，lint 也要限制嗎？
不用。lint、型別檢查、語法檢查秒級完成、輸出短，反而建議改完就跑，讓它擋掉低級錯誤。

Q10：小模型為什麼反而需要配額？
它需要一點回饋來修正，但 context 小，大量測試輸出會擠掉推理空間。研究中 32B 模型放任時，交得出非空 patch 的比例從 74% 掉到 50%。

參考資料

論文

  • Lin, Z., Zhu, J., Zhou, M., Wang, X., Sun, Z., Yang, R., Lo, D., & Li, L. (2026). To Run or Not to Run: Analyzing the Cost-Effectiveness of Code Execution in LLM-Based Program Repair. ISSTA 2026. https://arxiv.org/abs/2606.26978
  • Yang, H., Yu, Q., & Desell, T. (2026). When Does Restricting a Coding Agent to execute_code Help? A Regime × Agent-Design Ablation. KDD 2026 SE 3.0 Workshop. https://arxiv.org/abs/2607.10569
  • Fan, R.-Z., Zhang, Z., et al. (2026). An Empirical Study of Harness Design for Coding Agents. https://arxiv.org/abs/2609.20804

GitHub

會議

文章裡這些把關做法，要在一個團隊裡真的落地、而不是只有你一個人在用，通常卡在流程與共識。我把這部分整理成企業內訓：
coding agent 導入與治理 — 企業內訓與顧問 →

最後更新：2026年10月28日