企業開始評估 AI 程式代理（AI coding agent）時，問題常被簡化成：「Codex、Claude Code、Cursor、Copilot，到底哪個比較強？」
這個問法適合個人選工具，放到公司採購就太早。真正麻煩的是：同一個 agent 在 10 分鐘 demo 裡看起來普通，給它更多 token、重試次數與測試時間後，可能能解掉更難的 issue；如果 PoC 沒把任務預算、成本和審查負擔一起記錄，公司會同時低估能力，也低估帳單。
可以先把問題換成：公司準備讓 AI agent 進到軟體開發流程的哪一層，並願意給每個任務多少預算？
如果只是讓工程師在整合開發環境（IDE）裡補程式碼，評估標準很簡單：誰順手、誰便宜、誰能減少切換成本。若公司要讓 agent 讀大型 repo、改檔案、跑測試、開 PR，甚至協助處理安全修補，就要改用權限、審查、成本、任務預算與稽核標準來驗收。
２０２６ 年的 AI 程式代理已經跨出自動補全（autocomplete）階段，正在變成軟體工程基礎設施。讀完這篇，團隊可以把採用層級、PoC 任務、八個驗收指標與採購問題放進同一張檢查表，再決定要先試哪一類工具。
企業評估 AI 程式代理，先分清楚 ４ 種層級
不要一開始就問「哪個工具最好」。先問公司要把 agent 用到哪個層級。Level 1 是輔助補全，主要在 IDE 裡補 code、寫註解或生成小段函式，風險多半是程式品質不穩與工程師過度依賴。Level 2 是互動協作，agent 透過聊天或 CLI 讀 repo、解釋架構、產生修改建議，重點風險變成 context 讀錯與建議不可執行。Level 3 是代理改碼，agent 直接改檔、跑測試、產生 PR，企業要開始管權限、測試覆蓋與 review 負擔。Level 4 是流程自動化，agent 接到 issue、CI、security triage 與 release checklist，這時稽核、責任歸屬與供應鏈安全會變成主題。
大多數企業其實還在 Level 1 到 Level 2。嚴格採購治理通常從 Level 3 之後開始。
如果公司只是要讓個別工程師寫得快一點，選工具可以偏重體驗。
如果公司要讓 agent 進入 repo 與 CI，選工具就要偏重控制。
２０２６ 年為什麼企業評估標準變了？
Gartner 在 ２０２６ 年把 Enterprise AI Coding Agents 當成獨立市場討論，這個分類本身比單一象限排名更重要：採購邏輯已經從補全品質，移到代理能否被企業管理。
過去買 coding 工具，企業常看工程師採用率、IDE 整合、程式補全品質、授權費用與支援語言。現在買 coding agent，還要問它能不能限制可讀 repo、可改檔案與可執行工具；變更前是否需要人工 approval；每一次 tool call、檔案修改與測試執行能不能被稽核；是否支援 sandbox 或隔離環境；產生的 PR 能否清楚標示 AI 參與；模型是否會接觸公司機密、客戶資料或憑證；資安、法務、IT 與工程主管能不能共同接受這套流程。
這就是「個人工具」與「企業平台」的差別。
企業該比哪些項目？
先把評估面向分成三組。第一組是「能不能正確工作」：agent 要讀懂專案結構、測試、依賴與既有慣例，也要能跑測試、讀錯誤、修正後再提交；如果 demo 很會寫新檔，但碰到舊 codebase 就亂改，不能算通過。第二組是「能不能被公司管」：read-only、限定目錄、限定 branch、限定工具、sandbox、approval gate 與 audit log 都要說清楚；如果只能看到最後結果，看不到誰下任務、agent 看了什麼、改了什麼，就不適合碰核心 repo。第三組是「用起來是否划算」：成本上限、資料治理、review 負擔與開發者體驗要一起看；如果工具讓 reviewer 每天多看一堆品質不穩的 PR，省下的 coding 時間會被審查成本吃掉。
如果只能選四個優先指標，建議優先看：PR 可合併率、稽核完整度、任務預算敏感度、單任務成本。 若要把 seat、token、CI 與 review 時間拆成財務模型，可以接著看 AI Coding Agent 成本與 ROI 怎麼算。
2026-06 更新：把 context localization 與 skill 穩定性放進評估表
６ 月的新研究提醒企業 PoC 不能只看「最後 patch 有沒有通過」。兩個方向特別值得加入評估：agent 是否真的找到該讀的程式碼，以及團隊寫給 agent 的 prompt / skill 是否能被驗證、迭代與移植。
SWE-Explore 研究把 coding agent 的修 bug 流程拆開，只評估 agent 在動手前是否找到相關程式碼區段（code regions）。研究頁面與 arXiv 摘要顯示，它覆蓋 848 個 issues、203 個開源 repositories、10 種程式語言，並用成功解法實際讀過的程式碼行建立行級標準答案（line-level ground truth）。它給企業的採購提醒很直接：agent 找到正確檔案還不夠，若漏掉關鍵行號、測試或呼叫鏈，後面的 patch 很容易只是猜測。
Microsoft Research 的 SkillOpt 則從另一邊補上問題：很多團隊會把「怎麼使用 coding agent」寫成 prompt 範本或 skill 文件，但這些文件通常是手寫、一次生成或鬆散自我修訂。SkillOpt 把 skill 文件視為凍結代理的外部狀態，再由最佳化模型根據執行評分提出有限範圍的增刪改；只有保留驗證集分數變好時才接受。官方摘要提到它跨六個 benchmark、七個目標模型、三種執行環境（direct chat、Codex、Claude Code）測試，目標是讓 skill 訓練更接近可控的文字空間最佳化，避免把 prompt 改寫停留在玄學。
對企業來說，這兩個提醒應該轉成四個 PoC 檢查。Context localization 要求 agent 在 patch 前列出讀過的檔案、行號、測試與跳過理由，再抽樣比對 reviewer 認為必要的 context；如果它只列檔名、不列行級 evidence，就不能算通過。Context efficiency 追蹤 agent 讀了多少無關檔案，避免把半個 repo 都塞進 context，成本很高卻仍說不清 root cause。Skill / prompt validation 則把團隊常用範本放進固定任務集，記錄成功率、重試率與 review 修改量。Transferability 最後確認同一套 skill 在 Codex、Claude Code、Cursor 或內部 harness 上跑相同任務時，是否不會換工具就失效。
每家公司不必自己重跑 SWE-Explore 或 SkillOpt。比較務實的做法，是把它們的精神放進採購流程：要求 vendor 或內部平台交代 agent 的探索軌跡、任務範本版本、驗證集、失敗案例與 rollback 設計。若團隊已經在用 AI Coding Agent Prompt 範本，下一步可以挑 5 到 10 個高頻任務，把 prompt 當成可測試的產品資產，不要繼續累積口訣。
這也和 Interpreter Skills 的方向相連：可寫成程式的固定流程，應該進入可審查、可測試的 skill code；仍需要模型判斷的部分，才留在 skill 或 prompt 裡。成熟團隊不會只追更強模型，還會同時建立上下文證據、prompt/skill 驗證、權限邊界與審查關卡。
2026-07 更新：把 test-time compute 放進 PoC
英國 AI Security Institute（AISI）７ 月公布的研究指出，固定預算評測會系統性低估 frontier agent 的能力，尤其是較新的模型。AISI 的說法是，agent 在任務中可使用的 test-time compute 會改變量到的成功率；同一組任務如果只給固定 token 上限，最長、最難的任務會先被截斷，最後得到的分數比較像下限，不一定是能力上限。
這對企業採購很實際。假設團隊用 20 個真實 issue 測兩套 coding agent，只設定一個很緊的 token 或時間上限，可能會把「預算太短」誤判成「模型不會」。反過來，如果某個 agent 只在高預算下成功，也不能直接說它適合全公司使用，因為成本、等待時間與 review 壓力都會跟著上升。
AISI 在公開文章裡提到，把總 token 預算從 1M 提高到 10M，軟體工程任務（TerminalBench 2.0、SWE-Bench Pro）的表現約提升 25%；在 AISI 的 cyber task suite 裡，約 8% 任務只有在 10M+ tokens 時才被解出，有些需要到 50M tokens。這些數字不應直接搬成企業 KPI，但足以提醒採購團隊：benchmark 分數要和任務預算一起看。
比較安全的 PoC 做法，是讓同一批真實 issue 跑兩種上限：日常上限與延伸上限。日常上限回答「平常值不值得用」，延伸上限回答「遇到高價值任務時是否值得多花」。如果團隊需要把這件事做成可重跑的 eval harness，可以接著看 AWS LangSmith deep agent evaluation 怎麼做，但不要把 harness 本身當成採購結論；最後仍要回到 PR 可合併率、review 修改量與單任務成本。
PoC 不要用玩具任務，要用真實工程流程
很多 AI coding agent 評估會失真，是因為 PoC 任務太像展示，不像工作。
不要只測：
- 寫一個 todo app
- 產生單一函式
- 重構一個乾淨範例
- 解 LeetCode
- 修一個已知答案的 bug
這些任務可以測模型能力，但測不出公司採用風險。
比較好的 PoC 任務應該包含：
- 舊 repo 裡的小型 bug
- 有 failing test 的真實 issue
- 需要讀文件與既有慣例的功能調整
- 需要改兩到三個模組的中型任務
- 需要補測試、改文件、更新 migration 的完整 PR
- 需要處理 lint、type check、unit test、integration test 的 CI 流程
- 一個 agent 不應該碰的敏感任務，用來測權限與拒絕行為
企業 PoC 要測的是 agent 能否在公司現有 codebase 裡交出 reviewer 願意合併的 PR。乾淨範例能測模型能力，測不出採用後的真實風險。
建議用 ８ 個指標驗收
企業 PoC 最好不要只寫主觀心得。每個工具都要用同一批任務跑一次，再用同一組指標比較：PR 可合併率看 agent 產出的 PR 有多少能在少量修改後合併；review 修改量看 reviewer 需要改多少行、重寫多少邏輯；測試通過率看 agent 是否能自己跑測試並修到 pass；任務完成時間看從 issue 到可 review PR 花多久；單任務成本把 seat、token、雲端執行與 CI 成本加總；任務預算敏感度比較同一批 issue 在日常上限與延伸上限下的成功率、重試率與成本差距；安全例外數記錄它是否嘗試讀不該讀的檔案或跑不該跑的命令；開發者保留率則看 PoC 結束後，工程師是否仍願意主動使用。
這裡有一個常見誤判：agent 產出越多，不代表效益越高。
如果 agent 讓 reviewer 每天多看十個品質不穩的 PR，review 成本會吃掉寫 code 省下的時間。
2026-06 實例：Block Builderbot 顯示公司級編排要怎麼驗收
Block ６ 月公開 Builderbot，給了企業評估 Level 4「流程自動化」一個更具體的參考。Block 的說法是，Builderbot 是一層代理編排系統，工程師可以在 Slack 討論串標註 @builderbot，讓多個 AI agent 處理跨 repo、跨服務的工程任務。
它的定位已經超過一般 IDE 裡的單人助手。Block 強調 Builderbot 會在公司級程式庫（codebase）與系統設定（system configuration）上運作，並且不存取客戶資料、付款資訊或個人識別資訊。官方也公布一組採用數字：每天執行超過 200,000 次操作、每週合併約 1,500 個 PR，約占 Block 正式程式碼變更的 15%。這些數字仍是 Block 自述，不能直接當成所有企業都能複製的 benchmark；它們的價值在於提醒採購團隊：到了公司級編排階段，評估表要多看「任務入口、資料邊界、審查負擔與合併品質」。
可以把 Builderbot 案例轉成四個驗收問題。第一，任務從 Slack 討論串啟動時，討論、批准與結果是否都留在可追蹤系統。第二，任務橫跨大型程式庫與多服務時，agent 如何取得必要 context，是否能說明讀過哪些 repo、檔案與測試。第三，平台能不能用權限政策排除客戶資料、付款資料、憑證與高風險 production 操作。第四，如果供應商或內部團隊提出每週 PR 數、正式程式碼占比等採用數字，也要同時追蹤 PR 可合併率、review 修改量、事故率與回滾率。
如果公司還在 Level 1 或 Level 2，不需要急著複製 Block。比較安全的做法，是先把任務來源、權限邊界、測試證據與 AI PR 審查流程做好，再逐步把 agent 接到 issue、CI 與安全修補。
Codex、Claude Code、Cursor 應該怎麼分工？
不同工具的最佳位置不一樣。企業不一定只能選一個，也不應該用單一榜單決定全部團隊。需要企業治理、ChatGPT／API 生態與雲端任務時，OpenAI Codex 的評估重點會偏向 sandbox、approval、RBAC、audit 與資料政策。偏 terminal-first、需要深入讀 repo 的團隊，評估 Claude Code 時要多看 repo 理解、CLI workflow、權限邊界與長任務穩定性。想從 AI IDE 開始的團隊，Cursor 的重點是 IDE 體驗、多人採用率、成本與 review 品質。已深度使用 GitHub 與 Microsoft 生態的企業，GitHub Copilot 則要看 GitHub workflow 整合、policy、管理後台與授權模式。
採購時不要問「哪個最強」。比較務實的問法是：
- 哪個最適合我們目前的 repo 與工程流程？
- 哪個能被資安和 IT 接受？
- 哪個開始用之後不會讓 reviewer 崩潰？
- 哪個能用數字證明節省時間，避免只停留在新鮮感？
開始順序：不要一次開滿權限
企業開始用 AI coding agent，最穩的路徑是逐步開權限。
第一階段：read-only
先讓 agent 讀 repo、解釋架構、整理技術債、分析 issue。
這階段先看它是否懂公司 codebase，暫時不要開放直接改檔。
第二階段：小型修補
開放 agent 處理低風險任務，例如文件、測試、lint、簡單 bug。
所有修改都必須經過人類 review。
第三階段：受控 PR
允許 agent 建 branch、改檔、跑測試、開 PR。
但刪檔、安裝依賴、修改 infra、碰憑證、碰 production config，都要 approval gate。
第四階段：流程自動化
把 agent 接到 issue 分流、CI 失敗處理、依賴更新、安全修補與發布檢查清單（release checklist）。 這階段需要完整的 audit log、政策設定與成本上限。
不要跳過前兩階段。AI agent 採用初期常見風險，是組織太快把權限開太大，讓尚未驗收的代理直接碰核心 repo。
企業採購前的 １２ 個問題
在簽年度合約前，至少把這 １２ 個問題問清楚：
- Prompt、程式碼與執行紀錄是否會被用來訓練模型？
- 管理員能否限制 agent 可讀取的 repo、branch、目錄與檔案類型？
- agent 執行 shell command 時是否有 sandbox？
- 哪些操作可以設定人工批准？
- 是否支援 SSO、SCIM、RBAC 與群組權限？
- 是否能匯出 audit log 給 SIEM 或內部稽核系統？
- 是否能設定每人、每團隊、每 repo 的成本上限？
- 產生 PR 時是否標示 AI 參與與任務來源？
- 是否能與現有 GitHub、GitLab、Bitbucket、Jira、Slack、CI/CD 串接？
- 遇到錯誤輸出、測試失敗、權限拒絕時，agent 會如何處理？
- 資料保存位置、保存期限、刪除流程是否清楚？
- 廠商是否提供企業支援、事故回報與安全白皮書？
如果這些問題答不清楚，就不要讓 agent 直接碰核心 repo。
結論：２０２６ 年比的是「可控的生產力」
AI coding agent 的價值很真實。它可以降低讀陌生 codebase 的成本、加快 bug 修補、幫工程師跨到不熟的技術區域，也能把很多低價值維護工作自動化。
但企業採購與擴大使用時，不能只看 demo。
２０２６ 年採購要回答的是：這個 agent 能不能在可控、可稽核、可驗收的前提下，穩定進入軟體開發流程？
答案如果是肯定的，它就會從寫 code 工具升級成工程組織的新基礎設施。
如果答案還不明確，就先把它放在 read-only 與低風險任務裡，讓數據決定下一步。
資料來源
- Gartner：Enterprise AI Coding Agents Market Entering a New Phase
- OpenAI：OpenAI named a Leader in enterprise coding agents by Gartner
- OpenAI：Running Codex safely at OpenAI
- arXiv：SWE-Explore: Benchmarking How Coding Agents Explore Repositories
- Microsoft Research：SkillOpt: Executive Strategy for Self-Evolving Agent Skills
- The Decoder：Microsoft’s SkillOpt boosts GPT-5.5 by using nothing but a trained Markdown file
- AISI：More compute, more capability: Why AI agent evaluations need to account for test-time compute
- Block：Block rolls out Builderbot, a new suite of AI-native tools that changes the way we ship