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”这一项。