AI coding agent 的成熟，不是更會寫 code，而是有沒有可信的工作區

以前我們看 coding agent，常常只問一件事：它到底會不會寫 code？

這個問題沒有錯。模型不夠好，其他都不用談。但我越來越覺得，這已經不是最關鍵的問題了。

當 agent 只能在聊天視窗裡回答一段函式時，我們當然會盯著那段 code。它有沒有 syntax error？有沒有看懂需求？有沒有胡亂補一個不存在的 API？

可是當 agent 開始能在雲端環境裡工作，能保留狀態，能連到 repo，能跑測試，能開 PR，能在你離開電腦後繼續做事，問題就變了。

這時候你不只是在評估一個模型。

你是在把一段真實工作，放進某個工作區。

而一個工作區能不能被信任，看的不是它多會產出東西。看的其實是更普通，也更麻煩的幾件事：它能碰什麼、不能碰什麼、做過什麼、證據在哪裡、最後由誰決定要不要接受。

長時間執行不是魔法，是權限問題

OpenAI 收購 Ona 這件事，表面上很容易被讀成「Codex 會更強」。這當然是其中一層意思。

但我覺得比較值得看的，是另一個訊號：coding agent 的競爭正在從模型回答，走向執行環境。

Ona 自己談的是 customer-controlled cloud environment、persistent sessions、scoped credentials、review、audit trails 這類東西。這些詞聽起來很企業，很像大型公司才會在意的治理語言。

但小團隊其實更需要它們的簡化版。

因為小團隊沒有那麼多人可以幫忙吸收混亂。一次 agent run 改錯範圍，拿錯 token，推到不該碰的 branch，或把半成品留在沒人知道的地方，最後通常不是流程部門處理，是某個工程師在深夜把它挖出來。

長時間執行本身不是問題。

真正的問題是：它長時間拿著什麼權限在執行？

如果一個 agent 可以跑很久，卻沒有明確的 access boundary，它越勤奮，風險越大。不是因為它一定會作惡，而是因為它會把錯誤放大成一串連續動作。

人類工程師也會犯錯。但人類通常知道「這個資料庫不要碰」、「這個 repo 只是參考」、「這個 branch 不能直接推」。Agent 不會天然理解這些默契。你沒有把邊界做進工作區，它就只能從 prompt 裡猜。

我不太信任只靠 prompt 管權限。

Prompt 適合說明任務，不適合當安全邊界。

可信工作區要讓人看得懂

很多人談 agent 時，會把焦點放在自動化程度。

能不能自己查文件？能不能自己修測試？能不能自己拆任務？能不能自己開 PR？

這些能力都重要。但它們還沒有回答一個 reviewer 真正會問的問題：我怎麼知道你做了什麼？

可信工作區最基本的要求，是讓人看得懂。

不是只給一個「任務完成」。

也不是丟一大包 terminal log 叫人慢慢看。

它應該讓 reviewer 很快掌握幾件事：

• 這次任務原本允許改哪些範圍

• 實際改了哪些檔案

• 用了哪些工具和憑證

• 跑過哪些驗證

• 哪些地方沒有驗證

• 結果要給誰 review

• 如果拒絕，要怎麼乾淨地收回

這些東西聽起來很土。沒有任何 AI 魔法感。

但 agent 要真的進入 repo、PR、release flow，靠的就是這些土東西。

一個不能被看懂的 agent work，就算最後 code 是對的，也很難成為團隊可以重複使用的流程。因為大家會把它當成一次運氣好的黑箱。

下一次它再跑，所有人還是緊張。

PR 數量變多，review 問題就不再是假設

今年已經有研究把 agent-authored PR 當成 GitHub 上可觀察的活動來整理。AIDev 那篇資料集提到將近 93 萬個 agent-authored pull requests，涵蓋很多 repo 和不同 coding agent。

這個數字本身不用神化。PR 多不代表品質好，也不代表開發者真的省下同等時間。

但它說明一件事：agent 產出已經不是 demo 場景。

它會進 repo。它會進 review。它會進 issue、commit、CI、merge decision 這些很無聊但很真實的工程流程。

所以我們不能再只問「AI 寫的 code 好不好」。

更實際的問題是：

這個 PR 是誰委託的？

它原本的任務範圍是什麼？

它有沒有碰到不該碰的地方？

它的測試證據是什麼？

Reviewer 要根據什麼決定接受或拒絕？

拒絕之後，這個 agent session 會留下什麼狀態？

這些問題如果沒有回答，agent 產出越多，reviewer 的心理負擔就越重。你表面上把寫 code 的時間省下來，實際上可能把成本轉移到「我到底能不能相信這包東西」。

這是很多 AI workflow 很容易低估的地方。

產出不是免費的。每一份產出都要被讀、被理解、被驗證、被收掉。

小團隊需要的是簡化版治理

我不想把這件事講成大型企業合規課。

台灣很多獨立開發者、小型 SaaS 團隊、接案團隊，根本不可能先架一套完整 agent platform，再開始用工具。大家會從很實際的地方開始：一個 repo、一個 token、一個 issue、一個晚上想修完的功能。

所以我覺得比較好的做法，是先定一份「agent 任務卡」。

不用長。真的不用。

每次把比較大的工作交給 agent 前，先寫清楚：

• 這次可以改的目錄或檔案

• 這次不能碰的目錄、設定、資料或憑證

• 允許使用的工具

• 任務完成後必須留下的證據

• Review owner 是誰

• 結果可以落在哪裡，例如 PR、draft branch、markdown 報告或 demo

• 哪一種情況要直接停止，而不是自己繞路

這張卡片的價值，不是讓 agent 變聰明。

它是讓 agent 的工作變得可接手。

如果任務卡寫不出來，通常代表你自己也還沒想清楚這段工作要怎麼驗收。這時候硬把它交給 agent，很容易得到一個看起來很努力、但很難採用的結果。

我自己會把這當成一個很簡單的判斷：人類都不知道怎麼 review 的任務，不要交給 agent 長時間跑。

可以請它幫你探索。可以請它列方案。可以請它做一個小範圍 spike。

但不要讓它拿著大權限自己往前衝。

持久狀態有用，也需要清理

Persistent environment 很有吸引力。

它可以保留 dependencies、cache、branch、上下文、已經跑過的測試結果。你不用每次從零開始，也不用把所有東西塞進一次對話裡。

這對開發工作是合理的。真實工程本來就不是一次問答。它有環境，有歷史，有中間狀態。

可是狀態留下來，就會有清理問題。

一個 agent session 跑完之後，它留下的 branch 要不要刪？臨時檔案要不要保留？測試環境是不是還連著某個 token？它記住的上下文是不是下次還適用？它產生的 patch 是不是已經被另一個人改過？

如果這些事情沒有人管，持久環境會慢慢變成另一種技術債。

不是 code debt，而是 workflow debt。

每個人都知道那裡有東西，但沒人確定那些東西還能不能用。久了以後，團隊就不敢碰，只好開新的 session，新的 branch，新的環境。然後混亂再複製一次。

所以可信工作區不能只有「保留」。

它也要有「結束」。

結束不是把東西刪掉而已。結束是明確判斷：這次結果被接受、被拒絕、被封存，還是被轉成下一個任務。

這個判斷一定要有人負責。

不要把 agent 當成比較便宜的工程師

我覺得很多 AI coding 討論卡住，是因為大家很快就滑到替代人力。

這個 agent 能不能抵一個 junior？能不能讓一個 founder 少請一個工程師？能不能讓產品團隊不用寫那麼多 code？

這些問題很刺激，但不一定有幫助。

比較務實的看法是：agent 會讓某些工作變得更容易被外包給一個受限的執行環境。

重點是「受限」。

你不會把整間公司的鑰匙交給一個臨時外包，然後只說「請幫我把產品變好」。你會給他任務、資料、權限、交付格式和驗收方式。

Agent 也一樣。

而且 agent 更需要這些限制，因為它沒有團隊常識，沒有責任感，也不會真的理解你們公司下個月要不要維護這段 code。

它能做事，但不會替你負責。

所以成熟的 coding agent workflow，不是讓 agent 看起來更像人，而是讓它更像一個被妥善限制的工作環境：權限清楚、輸出清楚、紀錄清楚、拒絕路徑清楚。

先問工作區，再問模型

我不是說模型能力不重要。

模型當然重要。推理、工具使用、程式理解、測試修復，這些都會直接影響結果。

但當 agent 開始進入長時間工作，模型能力只是一半。

另一半是工作區設計。

下次你準備把一個比較大的任務交給 coding agent，可以先不要問「它夠不夠聰明」。

先問這幾個比較不浪漫的問題：

• 它只能碰必要的 repo、branch、token 和工具嗎？

• 它的每一步重要動作會留下紀錄嗎？

• 它的輸出有清楚 review surface 嗎？

• 它失敗時會停下來，還是自己亂繞？

• 它完成後，有人可以明確接受或拒絕嗎？

• 如果結果不好，我們能不能乾淨地收回？

這些問題回答得出來，agent 才有機會變成可靠的日常工具。

回答不出來，那就算模型再強，也只是把更多不確定性塞進專案。

真正可靠的 AI coding workflow，不是把更多事丟給 agent。

是讓 agent 做的每件事，都能被限制、被看見、被拒絕。

先把工作區設計好，再談它能跑多遠。

Source notes

• OpenAI, "OpenAI to acquire Ona", 2026-06-11, openai.com/index/ope...

• Ona, "Ona is joining OpenAI", 2026-06-11, ona.com/stories/ona-...

• TechRadar, "OpenAI's latest acquisition could see big changes on the way for its Codex coding assistant", 2026-06-12, www.techradar.com/pr...

• arXiv, "AIDev: Studying AI Coding Agents on GitHub", submitted 2026-02-09, arxiv.org/abs/2602.0...

• arXiv, "Coding Beyond Your Training: Claude Code and the Technological Frontier of Software Developers", submitted 2026-05-25, arxiv.org/abs/2605.2...