最近看企業 AI Agent 的產品方向，我越來越在意一個訊號：有些服務不再只賣座席、不只賣 token，也不只賣一個聊天入口，而是開始往「按結果收費」靠近。表面上這是商業模式的變化，但站在技術主管的位置，我會把它看成一個更嚴格的系統設計題：如果要按結果收費，系統必須先回答一件事——什麼叫做完成？
這個問題比聽起來難很多。
在傳統 SaaS 裡，計費單位相對直覺。幾個使用者、多少儲存空間、多少 API 呼叫、多少封信、多少筆交易，大多可以從系統事件直接算出來。它們不一定代表價值，但至少容易量化。企業也習慣為這些東西付費，因為邊界清楚：用了就是用了，沒用就是沒用。
可是 Agent 不太一樣。Agent 被期待的不是「被打開」，而是「把事情做完」。它可能讀知識庫、查資料、判斷意圖、建立草稿、呼叫系統、補資料、通知人、等待回覆，再把結果寫回流程。這一整串動作裡，哪一步算價值？哪一步算成功？如果中途需要人類確認，是 Agent 完成，還是人完成？如果 Agent 提出正確建議，但使用者沒有採納，這算不算一次有效結果？
這些不是財務部門才要煩惱的問題，而是產品和架構一開始就要處理的問題。
我現在會把「完成」拆成三層來看。
第一層是技術完成。也就是 Agent 的任務執行沒有錯誤，工具呼叫成功，資料寫入成功，流程有狀態變更。這一層最像傳統工程指標，log、trace、狀態機、retry、idempotency 都派得上用場。沒有這一層，後面都不用談。但只有這一層也不夠，因為系統成功不代表業務成功。
第二層是流程完成。也就是這件事真的抵達了業務流程定義的終點。例如一張申請完成初審、一筆客服案件被正確分類、一份報告已送到指定審核者、一個異常被標記並進入處置流程。這裡的重點不是 Agent 做了很多事，而是它推動流程前進到一個可被組織承認的節點。
第三層是責任完成。這也是最容易被忽略的一層。企業流程很少只是資料搬運，它牽涉到誰根據什麼資料做了判斷、誰批准、誰覆核、發生爭議時要回頭看哪一段紀錄。如果 Agent 只是把任務跑完，卻沒有留下足夠的決策脈絡，那它看起來提高效率，實際上可能把責任變得更模糊。
結果計費會逼迫我們把這三層講清楚。因為一旦收費綁在「完成」上，完成就不能只是行銷文案。它要變成系統裡可驗證、可查詢、可重算的事件。否則供應商說完成了，客戶覺得沒有；客戶說沒有價值，供應商說流程確實跑完。最後問題不在模型，而在雙方根本沒有共同的完成定義。
這也是我覺得企業 Agent 不能只從聊天介面開始設計的原因。聊天很適合探索需求，卻很難承載完成定義。真正要進流程，就需要狀態機、事件模型、審計紀錄、權限分層、人類確認點，以及一套能把「建議」「草稿」「已提交」「已核准」「已執行」分開的語意。這些聽起來很不 AI，但它們才是 AI 可以被放進正式工作的地基。
我也不認為所有 Agent 都適合按結果收費。越接近創意、研究、顧問型工作的場景，結果越難單一量化；越接近明確流程、標準作業、案件處理或資料維護的場景，結果才比較可能被定義得清楚。硬把模糊工作包成結果收費，短期可能很好賣，長期很容易變成雙方互相解釋價值。
所以看到「按結果收費」這個趨勢時，我不會只把它當成新的定價策略。它其實是在提醒我們：Agent 正在從回答問題，走向承擔流程責任。只要開始承擔責任，就必須回答完成、驗證、稽核、回溯與爭議處理。
未來我評估企業 AI 產品時，會多問幾個問題：它怎麼定義一次成功結果？這個結果由誰確認？失敗或部分完成怎麼處理？收費事件和流程事件是不是同一件事？客戶能不能回頭查每一次結果背後的資料、判斷和人為介入？
如果這些問題回答得清楚，按結果收費就不只是漂亮的商業包裝，而是產品成熟度的外顯。反過來，如果這些問題都還停留在「AI 會幫你完成任務」這種模糊說法，那我會很保守。
因為在企業系統裡，完成不是一句話。完成是一個被設計出來、被驗證過、也願意被追責的狀態。