https://developer.microsoft.com/blog/your-ai-coding-agent-evaluation-is-only-as-good-as-its-sandbox/
Principal Developer Advocate Waldek Mastykarz 2026 年 9 月 16 日在 Microsoft for Developers 發了一篇，英文題目是 Your AI coding agent evaluation is only as good as its sandbox。他用 Vally 測 GPT-5.6 Luna，看這個模型對不同版本的 Dev Proxy 知道多少，再拿去跟模型自己報的 knowledge cutoff 比。
Vally 是一套可擴充的 eval 平台，流程走 Stimulus、Executor、Trajectory、Graders、Score，留下完整 trajectory，裡面有 tool calls。Dev Proxy 在這次是被問的產品，一套 API simulator。讓 agent 在評測裡再去研究 Dev Proxy，跟 cutoff 的比較就沒有意義。
他起初把內建的 web tools 關掉，也擋住 curl，直接連網一起切掉。最新的文件拿不到，邊界看起來像已經關上。跑評測的那台 host 上，agent 要用的東西其實都還在。很多題還是過了，裡面包含近期 Dev Proxy 版本的細節題。若只看通過率，好像可以說：模型懂近期的 Dev Proxy 行為，還能推過它自己報的 knowledge cutoff。
Trajectory 走的是另一條路。Agent 搜了指派給它的 workspace 外面，找到這台機器上的 Dev Proxy 安裝，以及一份 source checkout。那份 checkout 帶著分版本的原始碼，也帶著 Git history。答案是準的。這些答案說明的是，agent 在那台機器上發現了什麼。模型在這次 run 之前知道什麼，這些答案沒有交代。
答對，只說明有沒有對上預期行為
通過的 agent evaluation，可能在證明錯的事。答案可以正確，背後的 measurement 仍然無效。他的原句是「a valid answer can still produce an invalid measurement」。正確只對得上預期行為這一項。整份結果算不算數，看 agent 怎麼拿到那個答案。
AI coding agent 生出答案，至少有三條路：靠內部知識和相關的 pattern，把 prompt 裡的資訊改一改拿來用，或從環境把證據找回來。三條路展示的能力不一樣。交出來的答案，很少會自己交代走了哪一條。
這次若要量的是 model 知道什麼，sandbox 就得擋住 agent，不讓它從環境把正在被測的知識找回來。擋不住的話，分數代表的是這次 run 期間 agent 碰得到的一切。這種分數可以看起來很強，回答的卻是跑的時候拿得到什麼。
先講清楚要證明什麼
他認為，限制任何一個 tool 之前，要先定義 evaluation 想證明什麼。他舉的題目大概三類：agent 能不能 research 一個不熟的 API；能不能使用 repository 裡的檔案；model 事先理不理解某個 product version 的行為。
題目不同，資訊邊界就不同。邊界在這裡指的是，哪些資訊准進這次 run，哪些必須扣住。Repository 層級的 coding evaluation，應該讓 agent 讀這次提供的那份 repository。Research 任務可以允許上網。測的若是模型內部知識，就得把會直接回答題目的 evidence 扣下來。
Coding agent 本來就會找資訊。碰到不熟的 API 或 error，會去搜文件、檢查周圍環境，包含原始碼和已經安裝的工具。開發者每天靠這個做事。放進 knowledge evaluation，同一種找法會變成污染，分數裡混進環境撈得到的東西。
擋掉 web 跟 curl，which 還是把路徑交出來
網路那條路關掉，只關掉一條。本機環境還是會漏答案。Coding agent 仍可以從 filesystem、已安裝的軟體、環境細節、本地 cache、tool 的輸出，以及接上去的服務拿到輸入。讀得到的，就進了這次 evaluation。
他看過的那條 Dev Proxy trajectory 是這樣走的。Web access 被拒。一開始的 command -v devproxy 被擋。Agent 改試 which devproxy，這次被允許，executable 和 source checkout 的絕對路徑一起露出來。它用 shell 裡的 rg 打那條路徑，再呼叫獨立的 rg tool，進到 repository，去看 v0.29.2 這個 tag。有一次 find 被擋，沒有改變結果，另外幾條路已經抵達同一份 evidence。
本地那份 repository 裡，就是被測的那份實作。在這條 trajectory 裡，agent 確認 parsed prompts 會按 filename 和 parameters 被 cache，然後交出一份通過的 diagnosis。研究出來的是 Dev Proxy 的這個行為。這份 diagnosis 沒有證明，模型在 run 之前、不靠外援就知道這件事。
被拒的那次 tool call，agent 把它當成障礙，再用剩下的能力繼續找。一條一條 deny rule 堆出來的 sandbox，會一直落後這種搜尋，除非那些規則強制的是同一條資訊邊界。
工具是路，sandbox 要圍的是資訊
跑評測的人多半用「限制了哪些 tools」來講一個 sandbox。實務上，tool 是通往資訊的路。該問的是：agent 靠它還留著的每一項能力，能拿到什麼資訊？
他對準的是資訊。Filesystem access 守在 workspace 邊界，每個 command 走同一條規則，讀不到外面。產品安裝，還有跟這次無關的 source checkout，從 host 拿掉。從 host 繼承下來、會洩漏路徑或已安裝軟體的環境細節，能少就少。Shell command 和接上去的工具，套同一條邊界。
對的邊界跟著 measurement 走。測 repository-level coding 時，讀提供的 workspace 裡的 source，是預期會發生的事。同一種讀取，若那些 source 裡裝的就是被測的答案，拿去測知識，evaluation 就無效。沒有一份永遠適用的禁止工具清單。資訊算不算正當，看這次在問什麼。
通過的那一筆，先把整條 trajectory 讀完
Grader 可以判斷最終答案有沒有對上預期行為。答案本身看不出來，它是模型內部生的，還是從環境找回來的。Rubric 寫得再完整，也無法在 run 之後修補已經被污染的輸入。
要信任一筆通過，先看完整 trajectory。看 tool calls，也看回傳給 agent 的 observations。有沒有搜到 workspace 外面，有沒有解析到產品已經安裝的那一份。接上去的服務要算進去。它們可能從另一個介面，把同一份資訊露出來。
失敗的嘗試要留著看。它們顯示 agent 覺得什麼有用，也常常指出下一條該守的邊界。某一次 call 被禁，只證明那一條路關了。整條 trajectory 看完，才知道另一條有沒有走通。
特別意外的通過要多看。尤其靠近模型預期的知識邊界，像它自己報的 knowledge cutoff 附近，從環境找回來的內容會讓通過看起來很合理。先把這些通過當成要去查的假設。查過，才決定能不能當證據。
下一輪，把 sandbox 當成 eval 的一部分測
Sandbox 決定這份 benchmark 量出來的 measurement 有沒有效。他給下一輪 evaluation 列了八步。
- 定義要量的能力，以及 agent 可以用哪些資訊。
- 每次 run 從一個乾淨的 workspace 開始，裡面只有預定的 fixtures，也就是這次打算放進去的素材。
- Workspace 的路徑保持中性，不洩漏跟這次 evaluation 有關的字。
- 測量需要的是內部知識時，把外部知識來源限制掉。
- 在 workspace 邊界上強制 filesystem access。
- 每一個還開著的 tool，套上等價的限制。
- 審查意外的通過，以及背後的完整 trajectory。
- Agent 每發現一條路，就加一個 regression probe，專門再測那條剛被發現的路還通不通，然後把 eval 再跑一次。
通過的分數，要在能解釋 agent 怎麼走到那個答案時才信。資訊邊界先關上，用 trajectory 核對，agent 找到新的路就再測。做不到這件事之前，分數講的可能是評測者那台機器。Model 事先知道什麼，這份分數還沒回答。