代理跑完任務還不夠：Microsoft Scope 把「驗收」拆成可以逐條打勾的條件

10 月 22 日，APPI News 刊出一篇關於 Microsoft Scope 的長文整理。Scope 是 Microsoft 開源的程式代理評測平臺，核心想法很簡單：讓團隊指定一項程式任務，交給現有的代理執行，然後依團隊自訂的條件逐項檢查成果，同時保留操作紀錄與工作區快照。

規格表上看不到的，往往才是重點。這類工具解決的並非「代理會不會寫程式」，而是一個更麻煩的問題：當代理宣稱完成任務，團隊憑什麼相信？

展示影片與 CI 測試之間的空隙

現有的兩種驗收方式各有盲區。一段展示影片只呈現最後成果，看不出代理怎麼查文件、挑了哪個 SDK、遇到錯誤時怎麼處理。CI 測試看似嚴謹，但它檢查的是預先寫好的輸出條件，程式可能碰巧符合表面要求，實際上卻依賴過時介面，或漏掉關鍵的例外處理。

用日常情境比喻，這就像驗收裝潢：屋主只看「照片拍起來很美」，或者只核對一張固定的檢查表。真正需要的是裝修過程的施工紀錄，水電怎麼拉、材料用哪一批，每一項都能回頭查證。

Scope 的定位在此：它把程式代理視為軟體的使用者之一，觀察代理如何實際接觸 SDK、API、命令列工具、MCP 伺服器與文件，再依證據回頭調整產品本身。Microsoft 稱這個角度為 Developer Agent Experience。

這與我們先前討論過的代理決策分岔評測是同一條思路：完成任務是一回事，沿途的每個選擇是否正確是另一回事。

條件寫法是整個機制的地基

Scope 的評估條件應寫成單一、可觀察的結果，例如「專案可成功建置」、「指定路由回傳預期格式」、「找不到資料時回傳文件規定的錯誤」。條件之間可以組成有依賴關係的圖：先確認 SDK 已安裝，通過後才檢查初始化，再驗證資料查詢與錯誤處理。前置條件失敗時，後續檢查標記為略過。

這個設計刻意避開「總分」。把建置、初始化、API 行為、錯誤處理全部揉成一個分數，失敗時無法定位原因；拆成獨立條件後，「哪個條件沒通過」和「失敗前代理做了什麼」都有答案可查。

任務設計也有對應的紀律。以 SDK 整合為例，不要只寫「完成整合」，而要說清楚：使用指定套件、依文件建立用戶端、呼叫列出產品的 API、處理找不到項目的回應、讓既有測試通過。同時，若產品有多種合法實作方式，條件應檢查可觀察的結果，不能把團隊偏好的特定寫法誤當唯一正確答案。

可重複執行，是比較的必要條件

Scope 儲存可重用的代理設定檔，記錄執行工作者、模型、代理版本、MCP 伺服器、技能與擴充功能。相同任務可搭配不同設定重跑，比較變更前後的表現。Microsoft 官方文件特別提醒，這些配置的任何一項變動都可能改變代理行為，因此單次成功展示不足以支撐決策。

這一點對所有導入代理的團隊都適用。換個模型版本、加一個外掛、改一句自訂指令，之前的評測結果就可能失效。沒有固定的配置紀錄與重跑機制，團隊之間對「代理好不好用」的討論往往流於各自印象。這也是先前MASS 評測限制分析一文指出的共同課題：分數提升之外，必須能說清楚評的是什麼設定、什麼任務。

使用入口方面，Scope 提供 Portal、CLI 與 REST API，人工檢視與流程自動化都能接入。官方文件目前列出 GitHub Copilot、Claude Code 與 VS Code Copilot 等整合方式，實際可用情況依部署版本與設定而定。值得注意的是，Scope 是驅動既有代理執行任務的評測平臺，不是供產品直接嵌入的代理執行環境。

判讀時的三條界線

評測平臺給了證據，但證據的邊界要由使用者自己守住。

第一，Scope 的評估結果只描述實際測試的任務與設定，官方文件明言它不是通用的代理排名。挑的任務若不貼近團隊真實工作，跑出來的通過率再高也沒有意義。

第二，條件寫錯，證據就跟著失真。條件太鬆，代理碰巧通過；條件綁死特定寫法，又會懲罰合理的替代實作。設計條件本身是一門需要迭代的手藝，第一版寫不好是常態，重點是能從失敗案例回頭修正。

第三，評測不能取代測試與人工審查。Scope 留下的操作紀錄與判準結果，是把「為什麼通過、為什麼失敗」變成可查證的資料，最終的判讀與決策仍在團隊手上。

對維護 SDK、命令列工具、MCP 伺服器或開發文件的團隊來說，Scope 提供的價值是把你以為的「代理能不能用」，換成一系列具體問題：它在你的文件裡找到正確的 API 了嗎？裝對套件了嗎？錯誤路徑照規格走了嗎？這些問題有答案之後，改文件、改 SDK、換模型的每一步才有依據可循。