AI coding agent 的下一個問題，不是模型多聰明，而是它在哪裡跑
以前選 coding agent，很像在選一個 editor 外掛。
誰補 code 比較準？誰比較懂 TypeScript？誰改 bug 比較少繞路？誰能把整個 repo 讀進去？這些問題都合理，也真的影響每天的開發體驗。
但最近幾個訊號放在一起看，我覺得問題正在換一個層級。
Google 把 Antigravity、CLI、SDK、Managed Agents 串成一個 agent-first platform。OpenAI 把 Codex 和 Managed Agents 放進 AWS 的企業雲路線。GitHub 的 Copilot cloud agent 則把 issue、session log、branch、PR、review、CI approval 串成一個背景工作流程。
這些東西表面上都叫 coding agent。可是它們拉開差距的地方，已經超出「模型多聰明」。
更實際的問題是：agent 到底在哪裡跑？
它在哪裡讀程式碼？在哪裡寫檔案？狀態保留在哪裡？它能不能碰 shell、網路、環境變數、憑證？它做過什麼事，誰看得到 log？最後是丟回一段文字、開一個 PR，還是進入企業雲端的治理流程？
這些問題沒有模型排行榜那麼性感，但會決定你能不能真的把 agent 放進工作流裡。
Agent 正在從模型介面變成執行表面
我會把這件事叫做 execution surface。
不是只看你跟 agent 說話的介面，而是看它實際工作的地方。那個地方包含檔案系統、工具、權限、網路、狀態、紀錄、審批節點，也包含它失敗時會留下什麼東西給人接手。
如果 agent 只是回答問題，execution surface 沒那麼重要。它答錯了，你可以重問，也可以當作沒有發生。
但 coding agent 不是這樣。
它會改檔案。它會跑測試。它可能會開 branch、送 PR、讀 log、呼叫工具。更進一步，它可能在背景跑一個小時，期間問你幾次要不要批准某個命令。到了這個階段，agent 不是一個聊天視窗，而是一個有行動能力的工作單位。
所以選工具時，只問「哪個模型比較強」會太窄。
模型能力仍然重要。可是同一個模型，放在本機 CLI、產品雲端 agent、企業雲託管 agent，或自己維護的 harness 裡，風險和效率完全不一樣。
本機 CLI 最貼近你，也最貼近你的風險
本機 CLI 或 desktop agent 的好處很直覺。
它離你的 repo 最近，知道你現在的 worktree 狀態，可以直接讀本機檔案、跑專案命令、看測試結果。對 indie maker、小型接案團隊、習慣自己掌控環境的工程師來說，這種控制感很舒服。
小步重構、補測試、整理文件、查 bug，這些任務很適合在本機跑。因為上下文就在那裡，來回成本低，你也很容易介入。
但本機環境的問題也在同一個地方。
它離你太近了。
你的 shell、環境變數、git credentials、未提交檔案、客戶專案、本機資料庫、測試用 token，很多東西都可能在同一台機器上。當 agent 有能力執行命令和改檔案時，「方便」和「權限過大」常常只差一層設定。
所以本機 agent 不應該被當成一個可以自由活動的助手。
比較健康的做法是把任務切小。一次只給它明確範圍，最好在乾淨的 branch 或乾淨 worktree 裡工作。能讀的目錄和能寫的目錄要分清楚。低風險命令可以讓它自己跑，高風險命令要停下來問人。碰到 production secrets、客戶資料、資料庫狀態，就不要靠「我覺得它應該不會亂碰」來保護自己。
本機 agent 的價值在於快，不在於無邊界。
產品雲端 agent 把治理包進 PR 流程
另一條路線是 GitHub Copilot cloud agent 這類產品雲端 agent。
它的吸引力不只在於「不用佔著你的電腦」。更實際的價值，是把 agent 的工作包進一個團隊比較看得懂的物件裡：issue、session、branch、PR、review、CI。
這種模式對很多小團隊其實很務實。
你可以從 issue 指派任務，讓 agent 在背景研究 repo、修改程式碼，最後開 PR。你可以看 session log，知道它做了什麼。你可以要求 review，限制 branch，讓 CI 在需要時經過人工 approval。這些功能聽起來樸素，卻能讓 agent 的工作比較不像黑盒。
PR 在這裡變得很重要。
如果 agent 的輸出是一個 PR，人類至少還有一個熟悉的治理介面。你可以看 diff、看測試、看描述、看 commit，也可以要求它修正。這比「agent 在某個雲端環境裡做完了，請相信它」健康得多。
但產品雲端 agent 也不是自動安全。
入口變多之後，管理也會變複雜。issue 可以啟動，chat 可以啟動，mobile 可以啟動，CLI 可以啟動，各種整合工具也可以啟動。團隊如果沒有明確規則，很容易變成任何人都能丟一個模糊任務給 agent，然後產生一堆難審的 PR。
所以這條路線的重點不是「把 agent 放到雲端就好」，而是把 PR 真的當成邊界。
任務要小。branch 權限要清楚。session log 要有人看。CI 為什麼需要人工 approval，要讓團隊理解。agent 產出的 PR 不應該因為「是 AI 做的」就少看一點，也不應該因為「是 AI 做的」就恐慌到完全不用。
它只是另一種 contributor。差別是，它很勤快，而且可能很會合理化自己的錯誤。
企業雲託管 agent 解的是組織問題，不只是技術問題
OpenAI models、Codex、Managed Agents 進 AWS 這件事，我覺得最值得注意的地方不是「又多一個平台可以用模型」。
比較值得留意的是：agent 正在被放進企業既有的雲端治理裡。
對大一點的組織來說，能不能用某個 coding agent，常常不由工程師喜不喜歡決定。它還牽涉採購、帳務、identity、security controls、資料處理地點、compliance、audit log、內部雲架構，以及出了事誰負責。
把 Codex 或 Managed Agents 放進 AWS / Bedrock 這類環境，等於讓 agent 可以接上既有的企業控制面。
這對內部工具團隊、金融、醫療、企業 SaaS 會有吸引力。因為他們的問題不是「我能不能在自己電腦上跑一個 agent」，而是「我能不能在公司可接受的安全和採購框架裡，讓 agent 處理真實工作」。
代價也很清楚。
設定會更重。成本會更難只用單一月費理解。平台依賴會更深。退出成本也可能更高。一旦 agent workflow 進了雲端組織設計，它就不只是開發工具，而是基礎設施的一部分。
所以企業雲託管 agent 適合的不是所有人。
如果你只是兩個人做 side project，先把流程搬進企業雲，很可能只是在替自己增加負擔。但如果你管理的是多個團隊、客戶資料、法規要求、內部平台，那麼 execution surface 的治理能力反而比某個單點功能更重要。
自管 harness 給你最大彈性，也把責任還給你
還有一種路線，是自己維護 agent harness。
也就是你不完全依賴某個產品的預設流程，而是自己定義工具、sandbox、skills、檔案規則、log、審批節點、模型切換、失敗處理。這種方式對有特殊需求的團隊很有吸引力。
例如你有內部程式碼生成規則、特殊測試環境、多模型策略、不能外流的資料、固定的 release gate，或需要 agent 按照你們自己的平台流程工作。這些需求很難完全交給通用產品處理。
自管 harness 的好處是貼近現場。
你可以把 agent 放在最適合自己的邊界裡。某些工具能用，某些工具不能用。某些任務只能產生 patch，不能直接改主 repo。某些階段必須先寫計畫，再寫 brief，再寫 draft 或 code。你可以把流程做得很細。
問題是，細就代表你要維護。
權限設計、sandbox 更新、工具 allowlist、log 保存、錯誤重試、模型降級、安全事故、成本監控，最後都會回到你身上。自管 harness 不是免費午餐，它只是把產品供應商替你做的那部分，換成你自己負責。
這不一定不好。
對某些成熟團隊來說，這反而是必要的。只是要誠實承認：你不是只是在「接一個 AI API」，你是在維護一套新的執行環境。
台灣小團隊該怎麼選
如果把這件事拉回台灣的開發現場，我會先用任務分級，而不是先選品牌。
接案團隊最需要小心的是環境混雜。客戶 A 的 repo、客戶 B 的資料、自己的 side project、個人憑證，不該都暴露在同一個高權限 agent 面前。接案情境裡，乾淨 worktree、專案隔離、權限限制，比追最新 agent demo 更重要。
Indie maker 可以比較務實一點。
很多任務確實適合先用本機或產品雲端 agent 加速。修小 bug、補 UI、整理 README、補測試、重構一個小模組，都可以交給 agent 試。但最好把任務 PR 化，讓每次輸出都有可審查邊界。不要讓 agent 自動碰 production secrets，也不要在手機上隨手批准大範圍修改。
企業內部工具團隊則不該只比模型分數或月費。
要問資料在哪裡處理，誰能看 log，誰能啟動 agent，誰能 approve，CI workflow 會不會被 agent 自動觸發，secrets 會不會被帶進不該去的環境。也要問如果半年後要換平台，工作流和資料能不能退出。
這些問題很煩，但它們才是 agent 進入真實組織後會遇到的問題。
不同表面不是高低階，而是不同取捨
我不覺得本機 CLI、產品雲端 agent、企業雲託管 agent、自管 harness 之間有單純的高低階。
它們只是把控制權、速度、資料位置、治理成本和失敗風險放在不同地方。
本機 CLI 快、近、可控，但容易碰到過多本機權限。產品雲端 agent 適合 issue-to-PR 的背景工作，但需要團隊真的會看 log 和審 PR。企業雲託管 agent 能接上既有治理和採購，但成本與依賴更重。自管 harness 彈性最大，也最需要工程能力維護。
成熟的使用方式，不是永遠選最強或最新的平台。
而是先問：這個任務如果做錯，代價是什麼？它需要哪些資料？需要哪些工具？能不能回滾？誰要審？log 要保存多久？它能不能碰憑證？它最後應該交回什麼形式的成果？
如果答案是「低風險、可回滾、小範圍」，輕的 execution surface 就夠了。
如果答案是「碰客戶資料、牽涉金流、安全、production、跨團隊依賴」，那就不要只靠一個聰明模型撐場面。你需要邊界、紀錄、審批和可觀測性。
下一個能力，是設計 agent 的工作房間
AI coding agent 會繼續變強。這點大概不用懷疑。
但越是這樣，開發者越不能只停在 prompt 技巧。
我們接下來要學的，更像是替 agent 設計工作房間。這個房間要夠大，讓它能把有價值的工作做完；也要夠小，讓它不能在錯的地方造成太大破壞。裡面要有工具，但工具不該全開。要有記憶和狀態，但也要有清楚的收尾。要能加速，但不能讓審查消失。
模型多聰明，當然還是重要。
只是當 agent 開始真的幫你改程式、跑流程、開 PR、接企業雲端，日常開發品質會越來越受一件事影響：它在哪裡跑，以及你怎麼設計那個地方。
下一代 coding agent 的使用成熟度，可能不在於你能不能找到最會寫 code 的模型。
而在於你能不能替不同任務，安排合適的 execution surface。
Source notes
喜欢我的作品吗？别忘了给予支持与赞赏，让我知道在创作的路上有你陪伴，一起延续这份热忱！