AI agent 真正貴的地方，是你看不見它在背景做什麼

現在用 coding agent，最奇怪的畫面不是它寫錯 code。

寫錯 code 至少看得到。

比較讓人不安的是那個「working」狀態。你知道它正在工作，但你不確定它到底在做什麼。它可能在讀檔，可能在跑測試，可能在重試同一個錯誤，可能開了 subagent，可能替自己做 review，也可能只是繞著一個很小的上下文缺口打轉。

過一陣子，它回來了。

有時候結果很好。有時候結果普通。有時候你只看到 quota 少了一大截，才開始回想：剛剛它到底把錢花在哪裡？

這不是單純的價格問題。

價格可以算。月費多少、token 多少、額度多少，這些都還在帳單裡。真正麻煩的是背景工作變多以後，成本開始藏進工作流裡。你以為自己只是交代一個任務，實際上 agent 可能已經做了一串你沒有明確同意、也不容易回放的事情。

這會改變小團隊使用 AI 的方式。

以前我們常問：「它能不能把這個功能做出來？」

現在還要多問一句：「它做出來的過程，我看得懂嗎？」

背景工作不是免費的

Agent 的吸引力，來自它不像傳統 autocomplete。

Autocomplete 只是補下一段。Agent 比較像一個可以被委派的工作單位。你給它 repo、issue、測試命令、限制條件，它自己去讀、自己去試、自己修、自己解釋。

這很有用。

但委派工作有一個很普通的前提：你要知道它做了什麼。

人類同事接一張 task，過一小時回來說已經完成，你大概會問幾件事。改了哪些檔？遇到什麼問題？測過了嗎？有沒有什麼地方只是暫時繞過？如果失敗，失敗在哪裡？

Agent 也應該一樣。

可是很多工具的介面，仍然把 agent work 包成一個很順的體驗：輸入需求，等待，拿到結果。中間那段被壓成一個狀態、一段 log，或乾脆消失。

這在任務很小的時候還可以接受。請它改一個 copy、補一個測試、調一個樣式，成本就算浪費也不大。

任務一變大，問題就出來了。

它多讀了多少檔案？重跑幾次測試？有沒有一直在同一個錯誤訊息附近試錯？auto-review 到底檢查了什麼？subagent 做了什麼子任務？它是不是把本來應該停止的探索，包裝成「再試一下」？

這些都不是抽象問題。

它們會變成錢，變成時間，也變成 reviewer 的負擔。

只看最後的 diff，會低估成本

我覺得很多 AI 開發工作流最容易誤判的一點，是把最後的 diff 當成全部成本。

如果 agent 最後只改了十行，大家會覺得這是一個小改動。可是那十行背後，可能讀了半個 repo，跑了很多次測試，試過三個方向，開過幾個背景流程，最後才收斂到那十行。

反過來也可能成立。

一個失敗的 run，如果它留下清楚紀錄，告訴你哪些假設不成立、哪些測試失敗、哪些檔案其實不是入口，下一次就可能省很多力氣。它沒有交付功能，但它交付了可用的探索結果。

所以 agent 成本不能只看結果。

它要看執行痕跡。

這也是為什麼我不太喜歡只把 AI 工具成本理解成「模型比較貴」或「quota 給太少」。那當然也會影響使用體驗，但對團隊來說，更重要的是每一次 agent run 有沒有留下可讀的工作紀錄。

最少要有幾個東西：

• 讀過哪些主要檔案

• 跑過哪些命令

• 重試過幾次

• 哪些檢查成功，哪些失敗

• 有沒有開子任務或背景 review

• 最後哪些判斷是有證據的，哪些只是推測

這不是為了漂亮。

它是讓人知道這筆成本值不值得再付一次。

預算邊界要在開始前講清楚

小團隊最常犯的錯，不是完全不控成本。

而是等成本出事以後才控。

Agent 開始工作前，大家通常會很在意需求有沒有講清楚，卻比較少先講停止條件。結果工具自己把「努力完成」理解成「繼續讀、繼續試、繼續修」。

對人類來說，這種勤奮看起來很合理。

對預算來說，不一定。

我會把比較大的 agent 任務，先切幾條很土的邊界：

• 最多跑幾輪測試重試

• 最多探索哪些目錄

• 不能碰哪些檔案或設定

• 背景 review 要檢查什麼，不檢查什麼

• 遇到哪一類錯誤必須停下來問人

• 如果沒有足夠證據，不准自己擴大任務

這些限制看起來像是在削弱 agent。

其實是在讓它可以被使用。

一個沒有停止條件的 agent，很像一個沒有預算上限的外包工作。你不能只因為它很會做事，就讓它無限探索。尤其在小團隊裡，最後收拾的人通常還是同一兩個工程師。

如果任務真的需要長時間探索，那也可以。只是要承認它是探索，不要把它假裝成一次普通修復。

探索有探索的預算，修復有修復的預算。

混在一起，成本就會變得很難判斷。

乾淨的專案，會讓 agent 少迷路

還有一個比較不浪漫的點：專案本身會影響 agent 成本。

很多人談 AI coding，第一反應是換更強的模型。這當然有用。但如果 repo 裡到處都是過期 README、重複入口、沒有測試、命名不一致、設定散在奇怪地方，再強的 agent 也要花力氣猜。

猜，就是成本。

它要讀更多檔案，要來回比對更多上下文，要重複確認某個 function 到底有沒有被用到。最後可能還是做出可以跑的結果，但過程會更貴、更慢，也更難 review。

這讓「可維護性」在 AI 時代換了一個意義。

它不只是人類工程師看 code 比較舒服。它也會影響 agent 每次進來工作時，需要花多少 token、讀多少檔案、繞多少路。

所以 clean code 沒有因為 AI 過時。

它反而變成一種成本控制。

對小團隊來說，這件事很實際。你不一定要把架構整理到教科書等級，但至少要讓 agent 有清楚的路標：主要入口在哪裡、測試怎麼跑、哪些檔案是生成物、哪些目錄不能亂碰、常見任務要從哪裡開始。

一份短 README，有時候比多買一點 quota 更有用。

我想要的是工作紀錄，不是更大的黑箱

接下來 agent 會更像工作者。

它會管理多個任務，會呼叫工具，會開子流程，會在背景做 review，會把原本聊天視窗裡的一次回答，變成一段完整執行。

這個方向我不排斥。

相反，我覺得它對獨立開發者很有價值。很多小團隊真正缺的不是靈感，而是有人幫忙把雜事推完：補測試、整理 migration、追錯誤、清掉小 bug、把文件補齊。

但越是這樣，越不能把 agent 做成更大的黑箱。

好的 agent workflow，應該讓人一眼看出這次工作花在哪裡。

不是只顯示「用了多少額度」。

而是把額度接回具體動作：哪段花在讀 repo，哪段花在測試重跑，哪段花在 review，哪段花在子任務，哪段花在無效探索。

這樣團隊才有辦法調整。

如果測試重跑很貴，就把測試切小。
如果讀 repo 很貴，就改善入口文件。
如果 subagent 常常重複工作，就縮小任務邊界。
如果 auto-review 抓不到真正問題，就改 review checklist。

看得見，才有得改。

看不見，就只能怪模型、怪價格、怪運氣。

不要問它省了多少時間，先問你看見了多少工作

我不覺得 agent 成本會讓大家不用 AI。

剛好相反。越來越多人會用，因為它確實能把一些工作往前推。

但成熟的使用方式，不會只是把更多事情丟給 agent。那很快會變成另一種混亂：產出更多、review 更累、帳單更難解釋、失敗更難復盤。

比較健康的方向，是把 agent run 當成一筆可以被管理的工作。

開始前有範圍和停止條件。
執行中有可讀的痕跡。
結束後有驗證證據。
失敗時有可回收的紀錄。
下一次可以根據這些紀錄變便宜，而不是每次重新迷路。

這些要求都不華麗。

但它們會決定 agent 能不能真的進入日常工作。

下次你按下 run 之前，可以先不要問：「它能不能完成？」

先問另一個問題：

如果它一路讀檔、重試、開子流程、替自己 review，我能不能看見它為什麼這樣做？我能不能知道什麼時候該讓它停？我能不能判斷這次成本值不值得下次再付？

如果答案是否定的，真正貴的可能不是 token。

是你用一個看不見的流程，替自己製造了一個很難驗收的結果。

AI agent 可以幫小團隊省時間。

前提是它花掉的時間和錢，不能只留在一個「working」狀態裡。

Source notes

• Business Insider, "OpenAI explains why Codex burned through credits faster than usual", 2026-06-30, www.businessinsider....

• arXiv, "The Shift to Agentic AI: Evidence from Codex", 2026-06-25, arxiv.org/abs/2606.2...

• arXiv, "Does Code Cleanliness Affect Coding Agents?", 2026-05-19, arxiv.org/abs/2605.2...

• arXiv, "Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories", 2026-06-23, arxiv.org/abs/2606.2...