AI Agent 定價：按動作計費與自託管執行時成本

先給結論：按動作計費不一定錯，低頻試點時甚至更靈活；問題出在 agent 一旦成功，用量和中間工具呼叫會一起增長。agent 的真實成本要看三件事：用量是否隨成功暴漲、資料是否持續出域、業務定義是否被鎖進平臺。自託管不是天然便宜，但它能把成本曲線從“每次呼叫都跳錶”改成“主要由基礎設施規劃決定”。

季度末，CFO 開啟 agent 平臺的賬單，愣了一下：是預算的四倍。

沒有人亂花錢，恰恰相反——是客服 agent 太成功了。把那筆賬攤開算：上線前，團隊一天處理約 5,000 張工單；agent 上線後，人均效率拉高，承接量翻到約 10,000 張。而平臺按動作計費，每處理一張工單，背後是查客戶、查訂單、查歷史、查知識庫、調退款、發通知——七八個動作起步。算一筆粗賬：10,000 張 × 7 個動作 × $0.10 ≈ 每天 $7,000，一年約 250 萬美元。而預算當初是按”5,000 張、每張算少點”拍的腦袋。

最諷刺的地方在這兒：這個專案越成功，這張賬單就越嚇人。 於是董事會的第一反應不是慶祝效率翻倍，而是問”能不能把用量壓一壓”——一個本該擴大的成功，因為計費模型，反而被踩了剎車。ROI 還沒真正兌現，規模先被成本焦慮卡死了。

一毛錢，乘以一個會膨脹的數

Salesforce 的 Agentforce 推出 Flex 計費：每個動作 $0.10。單看這個數字，便宜得讓人放鬆警惕。

但 agent 計費最該警惕的就是這裡——它把成本和用量綁死，而 agent 的全部意義恰恰是自主、高頻、不知疲倦地動作。而且越自主的 agent，為做好一件事而發起的中間動作越多：一個”幫我把這個客戶的情況理一理”的請求，背後可能是十幾次工具呼叫，你事先既數不清、也很難封頂。還有些平臺按 token 計費，比按動作更難預測——同一個任務，模型多想幾步，賬單就多一截。在高頻場景裡，SaaS 賬單會隨動作數線性上升；自託管執行時則更多受基礎設施、許可和運維能力約束。具體數字要按團隊自己的用量和企業協議重算，不能拿一個公開價目表直接套到所有組織。

按量付費不是更省、更靈活嗎？

這裡得認真接一個反駁，因為它在很多場景下是對的：按量付費沒有前期投入、用得少就花得少、供應商替你運維、你只為產生的價值買單——這套邏輯在雲端計算時代被反覆驗證過，憑什麼到 agent 這兒就不成立了？

它成立，但有個前提：成本隨之增長的那個”量”，得和你的價值脫鉤或弱相關。 雲端儲存按 GB 計費沒問題，因為存得多通常意味著業務大、付得起，二者大致同步。

agent 把這個前提打破了。它按”動作數”計費，而動作數恰恰隨自主程度和成功程度暴漲——你越想讓它替你多幹活、幹得越好，它發起的動作越多，賬單越高。這就成了一種”對成功徵稅”：你最佳化得越狠（讓 agent 多查一步、多核對一遍以提高質量），賬單反而越高。傳統軟體按席位收費，用得再狠成本也相對可預期；按動作收費，你做得越好，付得越多。雲時代那套”按量即公平”的直覺，在一個會自己發起大量中間動作、且你鼓勵它多做的執行體上，會變得沒那麼可靠。

那到底多大用量該自己跑？算個交叉點

別停在”看情況”。用 CFO 那兩個數，能把交叉點大致算出來。

自託管那側，先做一個簡化模型：假設年成本固定在約 $25 萬（許可 + 基礎設施 + 一部分運維分攤），它不直接隨每次工具呼叫線性變化。按動作那側是 $0.10 × 動作數。令兩者相等：

$250,000 = $0.10 × 年動作數
年動作數 ≈ 250 萬次  →  約 每天 6,800 個動作

也就是說，在這個假設下，當你一天的 agent 動作數超過約 7,000 量級，按動作計費就可能開始比自託管貴，而且之後差距越拉越大。回到那位 CFO：他一天 7 萬個動作（10,000 工單 × 7），已經比交叉點高出一個數量級。這個痛點不是意外，而是用量已經從試點區間進入了規模化區間。

這條演算法你可以直接套自己的數：把團隊一天的互動量乘以”每次互動大概幾個動作”，跟 7,000 這個量級比一比，就知道自己在交叉點的哪邊。

三種成本模型，攤開比一比

模型	代表	成本隨什麼漲	可預測性	資料在哪
按動作 / 按 token	Agentforce Flex（$0.10/動作）	隨動作數線性甚至超線性膨脹	差，用得越好越貴	廠商雲
按席位計費	多數 Copilot 類	隨人數漲，封頂但人均不低	中，但與 agent 自主性脫節	廠商雲
自託管執行時	ObjectStack / ObjectOS	隨基礎設施，與用量基本解耦	好，用量翻倍曲線幾乎不動	你自己的基礎設施

按席位看著穩，但它有內在矛盾：agent 的價值在於不佔席位地替代大量重複勞動，你卻還在按”人頭”付錢——計費維度和價值維度對不上。自託管則換掉整個成本結構：你為執行引擎和自己的算力付費，用量從一萬漲到十萬，賬單不再按動作線性增長。

先潑一盆冷水：自託管不是處處更便宜

別把”省 40–60%“當成放之四海皆準。它有個明確的成立區間，越界就不成立。

那個 $25 萬的頭部數字，沒把人算進去。自託管意味著你得有人去運維、打補丁、保證可用性——如果你沒有平臺團隊，這筆隱性的人力成本可能把賬面優勢吃掉一大半，也會把上面那個交叉點往右推。而且它有固定成本：基礎設施和運維是先花的，跟用量關係不大。

所以在用量很小、很低頻、純試驗性質的階段，按量付費反而更靈活、更便宜——你不用為一臺幾乎閒置的執行時養一個團隊。自託管的優勢，是在你確定會上規模之後才兌現的。

真正貴的那筆，不在價目表上

就算到了自託管更划算的一側，只比每月賬單仍然低估了問題。選計費模式之前，真正該算的是三筆賬，而其中兩筆不在價目表上：

1. 用量賬：成本會不會隨成功暴漲？ 這就是 CFO 那張四倍賬單——你的用量是否和 agent 的成功正相關。是，按動作就是個陷阱。
2. 合規賬：資料出域的代價。 按動作、按席位的 SaaS 往往意味著業務資料持續流向廠商雲。隨著 EU AI Act 分階段適用、歐洲繼續推進雲與 AI 主權框架，資料駐留和證據鏈不再只是安全團隊的偏好，而會進入採購和審計問題清單。
3. 鎖定賬：將來走不掉的代價。 當業務定義、流程、許可權都長在某家平臺裡，遷移成本隨使用時間複利上漲。你以為在為軟體付費，其實在為”將來走不掉”付押金。

把這三筆一起算，“一毛錢一個動作”那點表面便宜，很快被吃光。

自託管為什麼能把這幾筆同時摁住

核心只有一句：你為執行這份業務定義的引擎付費，而不是為它被呼叫了多少次付費。 由此：

• 成本與用量解耦。 ObjectOS 在你自己的伺服器上執行業務定義，agent 呼叫受治理工具的次數再多也不按次收費——成本由基礎設施決定，可預測、可規劃。那位 CFO 的工單翻倍，賬單幾乎不動。
• 資料不出域。 物件、許可權、審計證據都留在你自己的基礎設施裡，合規風險和資料出域成本一起降。
• 不被鎖定。 業務定義是開放協議（Apache 2.0）下你倉庫裡的後設資料，可 diff、可遷移。你買的是執行時的服務，不是”將來走不掉”的押金。

結語

“每個動作 $0.10”是一句很容易被低估的價籤：你剛起步、用量小的時候它顯得無害；你真正成功、用量起飛的時候，它才開始決定預算上限。回到季度末那位 CFO——他的賬單不是偶然失控，而是這套計費模型在高用量場景下自然長出來的結果。

算 agent 的成本賬，別隻看單價。算那三筆賬——用量、合規、鎖定——再用那條交叉點公式比一比自己的用量。算清這些，“自託管省 40–60%“就不是口號，而是能寫進預算表、也知道什麼時候不成立的結論。

npm i -g @objectstack/cli && os start

在自己的機器上把一個業務物件跑起來，讓 agent 反覆呼叫它幾千次，再看賬單——它不會動，因為沒有”每次 $0.10”這一項。