Agent Metering 和傳統 SaaS 的用量計費（例如 API 呼叫次數計費）本質上有什麼不同？
最大的差別在於「單位成本是否固定」。傳統 SaaS API 計費幾乎都是固定成本模型——每呼叫一次 /search 端點就是 $0.001，不管請求內容是什麼，成本都一樣，因為後端邏輯是確定性的。
Agent 完全不是這樣。同一個「幫我分析這個 DeFi 協議的風險」的 prompt，這次 Agent 可能推理 3 輪就得出結論（成本 $0.02），下次因為工具回傳的鏈上數據裡有異常格式，Agent 陷入重試和自我修正的循環，推理了 9 輪才收斂（成本 $0.15）。同一個輸入、7.5 倍的成本差異，這在傳統 SaaS 裡幾乎不會發生。
這個不確定性直接影響計費設計：如果你按「請求次數」固定收費，成本波動大的任務會讓你虧錢；如果你按「實際消耗」精確計費，用戶體驗會變差（他們無法預測這次要花多少錢）。多數成熟的 Agent 產品最後採用混合模型——設一個基礎價格覆蓋大部分情況，超過某個消耗閾值後才額外收費，同時對外承諾一個「最高上限」讓用戶有心理錨點。
如果 Agent 在任務中途因為錯誤而崩潰，還沒完成任務就中止了，這部分已經消耗的成本應該怎麼計費？
這是 Agent Metering 系統設計裡最容易被忽略、也最容易產生糾紛的場景。有三種常見的處理方式：
方案一：全額退款。任務未完成 = 不收費，公司自行吸收已消耗的 LLM/工具成本。優點是用戶體驗最好、糾紛最少；缺點是如果失敗率偏高（例如 Prompt Injection 導致 Agent 頻繁卡在錯誤處理循環），公司會持續虧損，且這個設計反而讓公司沒有動機去優化失敗率——反正虧的是公司不是用戶。
方案二：按實際消耗計費，不管任務是否完成。優點是成本精確反映；缺點是用戶會對「付錢卻沒得到結果」強烈不滿，客訴率高，需要非常清楚的事前告知（例如「本次分析可能因為鏈上數據異常而失敗，失敗仍會收取已消耗的運算費用」）。
方案三（多數成熟產品採用的折衷）：設定一個「免費重試額度」——如果任務在前 N 次工具調用內失敗，不收費（視為系統問題，成本由公司吸收）；如果任務已經進行到後期階段才失敗（例如已完成大部分推理但最後一步鏈上寫入失敗），收取部分成本（通常是已消耗成本的 50-70%），因為多數運算價值已經產生。
技術實作上，這要求計費系統支援「任務狀態機」——追蹤每個任務所在的階段，並在失敗時依據階段套用不同的退費規則，而不是簡單的「成功收費/失敗不收費」二分法。
Agent Metering 系統要怎麼防止「用戶操縱輸入讓 Agent 消耗異常低的資源，藉此套利計費差價」這類的濫用？
這類濫用的典型模式：如果計費模型是「按任務完成計價、不論消耗多少」，惡意用戶會想辦法讓任務用最少的資源完成（例如故意給出簡化到失去意義的指令），套利那個固定價格和實際極低成本之間的差價，然後大量重複這個操作。
防禦設計分三層：
輸入品質門檻：在計費前，先用一個輕量模型或規則判斷輸入是否構成一個「有效任務」（有足夠的資訊讓 Agent 產出有意義的結果）。低於門檻的輸入直接拒絕或降級計價，而不是照樣按標準價格收費——這同時防止套利，也避免用戶被收取「無意義任務」的錢。
異常消耗模式偵測：對單一用戶的請求模式做統計監控，如果短時間內大量請求都落在「消耗量遠低於中位數」的區間，這是套利行為的訊號（正常用戶的任務複雜度會有自然分佈，異常集中在低消耗區間不符合自然分佈）。觸發後可以人工審查或動態調整這類用戶的計價方式。
動態定價下限：不設固定價格，改成「min(固定基礎價, 實際消耗成本 × 加成倍率)」——這樣即使用戶操縱輸入讓消耗降到極低，計費也會跟著降到接近實際成本，套利空間被壓縮到接近零。這個方案犧牲了定價的可預測性，但從根本上消除了套利誘因，是安全性和用戶體驗的取捨。
在多 Agent 系統（Orchestrator + Sub-agent）裡，Metering 要怎麼設計才能追蹤到「是哪個 Sub-agent 花了最多錢」，而不只是總帳？
多 Agent 系統的 Metering 設計核心是「計費事件必須帶上完整的執行路徑標籤（trace context）」，而不是只在 Orchestrator 層記一筆總帳。
具體實作：每個任務啟動時，Orchestrator 產生一個唯一的 trace_id；每次調用 Sub-agent 時，把 trace_id 連同一個新的 span_id（標識這是這條追蹤鏈裡的哪一段）一起傳遞下去；Sub-agent 內部每次消耗資源（LLM 調用、工具調用），都把這筆消耗記錄和 trace_id + span_id + agent_name 綁在一起寫入計費事件表。
這個設計借用了分散式系統可觀測性（Observability）裡成熟的 Distributed Tracing 概念（類似 OpenTelemetry 的 trace/span 模型），把它套用到 Agent 計費場景。
有了這個結構之後，你可以做到：按 trace_id 彙總，得出這個任務的總成本（用於對外收費）；按 agent_name 分組彙總，得出「哪個 Sub-agent 平均消耗最高」（用於內部優化，例如發現某個 Sub-agent 經常需要多輪重試，值得優化它的 prompt 或換更便宜的模型）；按 span_id 排序，重建整個任務的執行時間軸和成本曲線（用於除錯和事後分析）。
沒有這層 trace context，多 Agent 系統的 Metering 只能看到「這次任務花了 $X」的黑盒總數，完全無法定位成本異常的來源，也無法針對特定 Sub-agent 做成本優化。
一個 DeFi 收益優化 Agent 產品的 Metering 系統設計案例
某個幫用戶自動在 Aave/Compound/Morpho 之間移動資金找最優利率的 Agent 產品，Metering 系統的實際設計如下：
消耗事件定義：三種事件類型——llm_call（記錄 model 名稱、input_tokens、output_tokens）、tool_call（記錄工具名稱如 get_protocol_rates、estimate_gas，以及該工具的第三方 API 成本，例如 DeFi Llama API 免費但 Alchemy RPC 節點按請求計費）、onchain_write（記錄實際 Gas 費，以執行當下的 ETH 價格換算成 USD）。
寫入時機：每個事件在發生的當下立即寫入 PostgreSQL 的 metering_events 表（不是任務結束後批次寫入），欄位包含 trace_id、event_type、raw_cost_usd、timestamp。這樣即使 Agent 中途因為異常斷線，已發生的消耗也不會遺失。
計費規則：基礎服務費 $0（免費使用分析功能），只在 Agent 實際執行「移倉」操作且成功完成時，收取「省下利差的 15%」（例如原本年化 3%，移倉後年化 3.8%，用戶資金 $10,000，一年省下 $80，收費 $12）。這是價值抽成模型，不是按 token 計價——用戶完全不需要理解 Agent 內部消耗了多少運算資源，只需要看到「省了多少錢，付多少服務費」。
內部成本監控：即使對外是價值抽成計價，內部仍然完整記錄每筆 llm_call 和 tool_call 的實際成本，用來算出「這個抽成模型是否還能覆蓋 LLM/Gas 的實際支出」。他們發現某類「多資金池比較」的任務平均消耗 $0.28（因為需要並行查詢 6 個協議），而典型抽成收入只有 $8-15，成本占比健康；但另一類「異常數據重試」的任務因為 Aave 的 API 偶爾回傳格式錯誤，觸發 3-4 次重試，平均消耗飆到 $1.1，值得優先修復。
這個案例說明：對外計價模型（用戶看到的）和內部 Metering（公司用來算成本和優化）可以是兩套完全不同的邏輯，但內部 Metering 必須精確，否則公司無法知道「這個定價模型實際上有沒有賺錢」。
Agent Metering 的核心取捨是「計費精確度 vs 用戶可預測性」。按實際消耗精確計費（token/工具/Gas 全部照實收）能確保公司不虧本，但用戶無法在任務開始前知道要付多少錢，體驗較差、容易產生「怎麼比預期貴這麼多」的糾紛。固定價格或範圍定價讓用戶心裡有底，但公司要承擔「這次任務消耗特別高」的風險，長期依賴大數法則讓高低消耗互相抵銷。另一個取捨是「即時寫入 vs 系統開銷」：每個工具調用都即時寫入計費事件，能確保資料完整不遺失，但會增加資料庫寫入頻率和延遲；如果為了效能改成批次寫入，會有崩潰時資料遺失的風險。建議：對外採用固定或範圍定價降低用戶認知負擔，內部堅持即時精確記錄以確保成本可控，兩者不衝突，是「對外簡化、對內精確」的分層設計。