很多團隊導入 AI coding agent 時，第一個反應還是很直覺：介面是不是更好聊？prompt 要怎麼寫？agent 能不能一次看懂整個 repo？
這些問題都重要，但可能不是最早讓團隊痛的地方。
真正會先撞上來的，通常是帳單。
一個模糊的任務，丟給 agent 跑幾輪。它讀了一堆檔案，試了兩三種方向，叫了高階模型，跑了測試又失敗，回頭重改。最後 PR 也許真的開出來了，但你突然發現，那句「幫我修一下」其實不是一句話。
它是一筆可計算的工程成本。
這就是 AI coding agent 跟過去 autocomplete 最大的差別。以前 Copilot 比較像一個每月付費的鍵盤加速器。它補幾行、解釋幾段、幫你想測試案例，成本感很弱。現在 agent 可以被委派任務，可以在背景工作，可以選不同模型，可以重試，可以跑工具。這代表它不只是更聰明的聊天框，而是進入了工程流程裡。
流程一旦進來，預算也會跟著進來。
工程師對 AI coding 工具的第一代想像，大多是訂閱式的。
每個月付一筆錢，IDE 裡多一個很會補字的同事。用多用少當然有差，但差異不會直接出現在每一次任務決策裡。你不太會在補一段函式前先想：「這次 autocomplete 值不值得？」
Agent mode 讓這個心智模型變得尷尬。
因為 agent 做的不是「補一下」。它做的是「接一個工作」。這個工作可能包含讀 codebase、規劃、修改、跑測試、修測試、產生 PR、等待 review。中間任何一步都可能消耗更多模型呼叫或工具時間。
這時候，問題不再只是「AI 答得準不準」。
更麻煩的是：「這個任務值不值得讓 agent 跑？要用什麼模型跑？最多讓它試幾次？失敗到什麼程度就停？誰看得懂它花了什麼？」
GitHub Copilot 的 premium requests 和 usage-based billing 訊號之所以值得注意，不是因為大家需要背熟每個方案的額度。那些數字會變，政策也會調整。真正的重點是：產品已經在告訴你，agent 時代的使用量會變成管理介面的一部分。
你不能再假裝每一次 AI 操作都是同樣便宜、同樣輕、同樣不需要記錄。
很多人談 AI 成本，會直接跳到模型價格。
我覺得那反而太表面。
模型當然有成本，但團隊真正浪費的地方，通常不是「用了貴模型」。而是把爛流程原封不動丟給 agent，然後讓 agent 很努力地燒額度。
例如：
這些不是 AI 問題。這些是團隊本來就不健康的工程習慣，只是以前沒有那麼容易被量化。
人類工程師遇到模糊任務時，會問問題、偷懶、繞路、拉同事討論，或乾脆先做一個自己覺得合理的版本。Agent 不一定會這樣。它可能很勤奮地在錯誤方向上跑很久，而且每一步都看起來像進度。
這是最危險的地方。
一個沒有停止條件的 agent，比一個答錯問題的 chatbot 更麻煩。答錯你可以關掉。沒有停止條件的 agent 會把「不清楚」轉成重試、猜測、修改範圍擴大，最後留下 reviewer 看不懂的 diff。
帳單只是把這件事變得比較刺眼。
如果團隊真的要把 coding agent 放進日常流程，我會先要求每個 agent 任務都帶一個很樸素的預算欄位。
不是財務部那種預算。是工程控制用的預算。
一個健康的 agent task 至少要講清楚這幾件事：
這聽起來很無聊，但它比「請用最好的方式完成」可靠太多。
例如，一個任務可以這樣寫：
修復
src/search/裡篩選器空狀態顯示錯誤。允許修改搜尋模組與對應測試，不要調整 API contract。先用標準模型處理，最多重試兩輪。完成後跑pnpm test search和pnpm lint。如果第二輪後仍失敗，停止修改並回報目前假設、失敗測試和建議人工檢查點。
這段文字沒有炫技，但很有用。
它把 agent 從「請你自由發揮」拉回「這是一個有邊界的工程任務」。更重要的是，它讓 reviewer 知道這個任務原本允許 agent 做到哪裡。
沒有這個邊界，reviewer 只能看 diff。可是 diff 只能告訴你它改了什麼，不能告訴你它為什麼花那麼多輪、在哪裡卡住、是不是越權處理了不該碰的問題。
以前大家談模型選擇，很容易變成跑分比較：哪個模型比較強、哪個 benchmark 比較高、哪個比較會寫 code。
進到團隊流程後，問題應該改成：「這個任務需要多強的模型？」
不是每件事都值得丟給最強模型。
改 README、補型別、整理測試命名、修一個明確的 UI copy bug，跟追一個跨服務 race condition，不應該使用同一種路由策略。前者需要穩定、便宜、可快速驗收。後者可能真的需要更強的推理能力和更多上下文。
如果團隊沒有模型路由規則，最後通常會走向兩種極端。
一種是為了省成本，什麼都用便宜模型，然後在複雜任務上反覆失敗。看起來省了單次成本，實際上把錢花在重試和人工收尾。
另一種是怕麻煩，什麼都用最強模型。這很舒服，但也很快會讓管理層開始問：「這些 agent 任務到底在燒什麼？」
比較務實的做法，是把任務分級。
低風險、局部、可測試的任務，用預設模型。跨模組、需求模糊、需要推理設計取捨的任務，才允許升級。升級時要留下原因，不要讓「我覺得它比較聰明」變成唯一理由。
這不是在跟模型計較幾毛錢。
這是在訓練團隊把 AI 使用當成工程資源，而不是神奇魔法。
Agent 完成任務後，很多人會很自然地打開 diff。
這當然必要。但只看 diff 不夠。
Agent PR 應該附上一張收據。至少要讓 reviewer 知道：
這張收據不是行政文件。它是 review 的一部分。
因為 agent 的問題常常不是「這行 code 明顯錯」。更常見的是，它用一個看似合理的方法繞過了真正問題，或是在某個假設上走太遠。沒有過程收據，reviewer 很難知道該從哪裡下手。
這也會改變團隊衡量 agent 成效的方式。
不要只問「這個 PR 有沒有 merge」。也要問：
這些資料累積起來，才會讓團隊真的變會用 agent。
不然你只是把一堆昂貴的嘗試包裝成「AI 導入」。
講到預算，很容易讓人想到限制、審批、減少使用。
我不是這個意思。
好的預算表不是為了讓 agent 少做事，而是讓它做對的事。沒有預算的團隊，最後反而會更保守。因為大家不知道成本在哪裡，只好靠感覺管理。感覺一旦變差，最簡單的管理方式就是禁止。
有預算、有重試上限、有模型路由、有收據，團隊才敢把更大的任務交出去。
這跟雲端資源很像。不是因為有 cost dashboard，大家就不開機器。剛好相反，是因為看得見成本、設得了 alert、抓得到異常，團隊才敢把工作放到雲上。
AI coding agent 也會走到這一步。
它不會永遠停在「工程師跟聊天框對話」。它會進 issue、進 PR、進 CI、進內部工具，變成可以被觸發、被追蹤、被驗收的工作單位。
到那時候，chat 只是入口之一。
真正重要的介面，是團隊能不能看懂每個 agent 任務花了多少、為什麼花、產出了什麼證據、什麼時候該停。
會用 AI coding agent 的團隊，不會只是最會寫 prompt 的團隊。
會是最早把 agent 工作變成可估算、可中止、可驗收流程的團隊。
ryanvale
iThome鐵人賽
看影片追技術