企業開始評估 AI coding agent 時，第一個問題通常是：「Codex、Claude Code、Cursor、Copilot，到底哪個比較強？」
這個問題太早了。
真正該先問的是：公司準備讓 AI agent 進到軟體開發流程的哪一層？
如果只是讓工程師在 IDE 裡補程式碼，評估標準很簡單：誰順手、誰便宜、誰能減少切換成本。但如果要讓 agent 讀大型 repo、改檔案、跑測試、開 PR、甚至協助處理安全修補，評估方式就完全不同。
２０２６ 年的 AI coding agent 已經不是「更聰明的 autocomplete」。它正在變成一種軟體工程基礎設施。
企業評估 AI coding agent，先分清楚 ４ 種層級
不要一開始就問「哪個工具最好」。先問你要導入到哪個層級。
| 層級 | 使用方式 | 主要風險 | 適合工具型態 |
|---|---|---|---|
| Level 1：輔助補全 | 在 IDE 裡補 code、寫註解、生成小段函式 | 程式品質不穩、工程師過度依賴 | Copilot、Cursor、傳統 AI IDE |
| Level 2：互動協作 | 用聊天或 CLI 讀 repo、解釋架構、產生修改建議 | context 讀錯、建議不可執行 | Claude Code、Codex、Cursor agent |
| Level 3：代理改碼 | agent 直接修改檔案、跑測試、產生 PR | 權限、測試覆蓋、review 負擔 | Codex、Claude Code、Devin 類工具 |
| Level 4：流程自動化 | agent 串 issue、CI、security triage、release checklist | 稽核、責任歸屬、供應鏈安全 | 企業版 coding agent 平台 |
大多數企業其實還在 Level 1 到 Level 2。真正需要嚴格採購治理的是 Level 3 之後。
如果公司只是要讓個別工程師寫得快一點，選工具可以偏重體驗。
如果公司要讓 agent 進入 repo 與 CI，選工具就要偏重控制。
２０２６ 年為什麼企業評估標準變了？
Gartner 在 ２０２６ 年把 Enterprise AI Coding Agents 當成獨立市場討論，重點不是哪一家廠商被放在哪個象限，而是這個分類本身代表採購邏輯改變。
過去買 coding 工具，企業常看：
- 工程師採用率
- IDE 整合
- 程式補全品質
- 授權費用
- 支援哪些語言
現在買 coding agent，企業還要看：
- 能不能限制 agent 可以讀哪些 repo？
- 能不能限制 agent 可以改哪些檔案？
- 變更前是否需要人工 approval？
- 每一次 tool call、檔案修改、測試執行能不能被稽核？
- 是否支援 sandbox 或隔離環境？
- 產生的 PR 能否清楚標示 AI 參與？
- 模型是否會接觸公司機密、客戶資料或憑證？
- 採購後能否被資安、法務、IT、工程主管共同接受？
這就是「個人工具」與「企業平台」的差別。
一張表看懂：企業該比哪些項目？
| 評估面向 | 要問的問題 | 不合格訊號 |
|---|---|---|
| Repo 理解能力 | agent 能不能讀懂專案結構、測試、依賴與既有慣例？ | demo 很會寫新檔，但碰到舊 codebase 就亂改 |
| 權限控制 | 能不能做到 read-only、限定目錄、限定 branch、限定工具？ | 一開就拿到過大的檔案與命令權限 |
| Sandbox | agent 執行指令時是否與本機、內網、憑證隔離？ | 需要在工程師主機上直接跑未知命令 |
| Approval gate | 寫入、安裝依賴、刪檔、推 PR 前能不能要求批准？ | agent 可以連續執行高風險操作 |
| Audit log | 誰下了什麼任務、agent 看了什麼、改了什麼，是否可追溯？ | 只能看到最後結果，看不到過程 |
| CI 整合 | 能不能跑測試、讀錯誤、修正、再提交？ | 只會產生 code，不會處理失敗測試 |
| 成本控管 | 能不能設定每人、每 repo、每任務上限？ | 月底才知道 token 或 seat 成本爆掉 |
| 資料治理 | prompt、程式碼、log 是否會被拿去訓練？保存多久？ | 廠商條款說不清楚，或管理員無法控制 |
| Review 負擔 | agent 產出是否讓 reviewer 更輕鬆？ | 產出很多，但每個 PR 都需要大修 |
| 開發者體驗 | 工程師願不願意在日常 workflow 裡使用？ | 安全做得很滿，但使用流程太卡 |
如果只能選三個優先指標，建議優先看：PR 可合併率、稽核完整度、單任務成本。
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 不應該碰的敏感任務，用來測權限與拒絕行為
真正的問題不是 agent 能不能在乾淨環境寫 code，而是能不能在公司現有 codebase 裡交出 reviewer 願意合併的 PR。
建議用 ７ 個指標驗收
企業 PoC 最好不要只寫主觀心得。每個工具都要用同一批任務跑一次，再用同一組指標比較。
| 指標 | 怎麼看 |
|---|---|
| PR 可合併率 | agent 產出的 PR 有多少能在少量修改後合併 |
| Review 修改量 | reviewer 需要改多少行、重寫多少邏輯 |
| 測試通過率 | agent 是否能自己跑測試並修到 pass |
| 任務完成時間 | 從 issue 到可 review PR 花多久 |
| 單任務成本 | seat、token、雲端執行、CI 成本加總 |
| 安全例外數 | 是否嘗試讀不該讀的檔案、跑不該跑的命令 |
| 開發者保留率 | PoC 結束後，工程師是否仍願意主動使用 |
這裡有一個常見誤判：agent 產出越多，不代表效益越高。
如果 agent 讓 reviewer 每天多看十個品質不穩的 PR，那不是生產力提升，而是把成本從寫 code 轉移到 review。
Codex、Claude Code、Cursor 應該怎麼分工？
不同工具的最佳位置不一樣。企業不一定只能選一個，也不應該用單一榜單決定全部團隊。
| 工具型態 | 適合情境 | 評估重點 |
|---|---|---|
| OpenAI Codex | 需要企業治理、ChatGPT／API 生態、雲端任務與較完整管理面的團隊 | sandbox、approval、RBAC、audit、企業資料政策 |
| Claude Code | 偏 terminal-first、需要深入讀 repo、重視工程師互動體驗的團隊 | repo 理解、CLI workflow、權限邊界、長任務穩定性 |
| Cursor | 想從 AI IDE 開始、重視日常 coding flow 與個人開發效率的團隊 | IDE 體驗、多人採用率、成本、review 品質 |
| GitHub Copilot | 已深度使用 GitHub 與 Microsoft 生態的企業 | 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 triage、CI failure、dependency update、安全修補與 release checklist。
這階段才需要真正完整的 audit log、政策設定與成本上限。
不要跳過前兩階段。AI agent 導入最危險的地方，通常不是模型不夠聰明，而是組織太快把權限開太大。
企業採購前的 １２ 個問題
在簽年度合約前，至少把這 １２ 個問題問清楚：
- 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 與低風險任務裡，讓數據決定下一步。