智能体平台按什么计费，就会长成什么架构

九月二十五日，两家平台各自上线了自己的智能体产品，两份公告里关于计费的那句话写法完全不同。n8n 写得直白：智能体的一轮对话算一次执行，对工作流和子智能体的工具调用不再单独计费。DigitalOcean 写的是另一套逻辑：智能体在会话里大部分时间都在等待，等模型、等工具、等人。所以按活动 CPU 和峰值内存计费，等待的那段时间是 0 美元。换句话说，两家在同一个星期里给出了两种不同的会话定价方式。

这两句话看起来是商务口径，实际上各自描述了一种架构。计费单位决定哪一种任务形状在你这套工具上便宜，也就决定了你会把智能体做成什么样子。

会话的时间结构，决定了谁为等待付钱

把一个智能体会话摊开看，时间是交替的：想的时候消耗算力，动作之间在等。等待有三个来源，等模型返回、等外部工具响应、等人审批。这三段都不产出用户看得见的结果。不过它们占掉的时间往往比计算本身长得多。这就是智能体经济学与上一代云最不一样的地方。

DigitalOcean 在自己的公告里把这件事说成了全部：「智能体在会话的大部分时间里都在等待。这就是智能体经济学的全部故事。如果你按预置容量计费，你就在为等待付钱。」按活动 CPU 与峰值内存计费的做法，等于把等待从账单里删掉了。

n8n 的处理方向相反。它把计费单位放在轮上，一次对话轮算一次执行，同一轮内调用工作流或子智能体不另外计费。这样一来，账单跟着「你问了几次」走，而不跟着「它想了多久」走。

上一代计量单位留下了一个习惯

这不是新问题，只是换了计量单位。云的上一个单位是虚拟机小时，客户为计算付钱，不管它在工作还是在等待。这个口径训练出了一套维持了二十年的习惯：让机器别闲着，因为闲着的每一分钟都要付钱。问题是，这套习惯在换单位之后不再成立。

智能体不按这个方式跑。DigitalOcean 描述得很具体：它用 token 思考、用一小段一小段的计算执行，然后等；它可能今天下午需要四份自己、夜里一份也不要；第二天早上。它的工作状态要在另一台机器上被继续，接手的人或者智能体都可能换掉。它天然的单位是消耗掉的 token、真实执行的秒数，以及活得比会话更久的状态。五花八门的量词背后只有一件事：等待由谁承担。

把计量单位从虚拟机小时换成 token 与执行秒数，听起来只是记账方式变了。写这份公告的人自己说得很清楚：这改变了云的架构方式、安全方式，以及怎么计费。

两种口径，把两种形状变便宜

把口径落回架构上，两种选择各自奖励一种形状。

按轮计费的平台，奖励的是一次提问触发一长串工具编排的形状：同一轮里调用多少次工作流、拉起多少个子智能体都不另外计费，账单与轮数绑定。被惩罚的是来回追问的形状，用户与智能体来回十几轮才收敛，每一轮都单独算一次。单轮内的失败重试、同一支工具被调用三次，在账单上看起来和一次没有区别。

按活动算力计费的平台，奖励的是长等待与宽并行的形状：等待不计费。所以「放着等审批」不再需要架构上的回避。被惩罚的是上下文规模，因为峰值内存进了账单，把一份巨大的上下文一直留在内存里，成本会从计算那一侧回来。这意味着，同一套编排换个口径，账单的形态就变了。

还有一个容易被忽略的细节：n8n 在公告里把自己的边界写得很清楚，功能仍在预览期、自托管需要额外配置、企业版稍后推出、敏感动作建议保留人工审批。这些不是免责话术。它们是选型时必须一起读进去的条件——预览期的默认行为与价格都可能变，把预览期产品写进长期架构假设里是要付学费的。

我们的判断：计费口径是架构约束，不是商务条款

平台按什么计费，就会把哪一类形状做得顺手。这种惯性最终会写进你的系统。如果你的任务形状是「用户问一句、智能体干半小时活、中间等三次审批」，按轮计费的账单由审批次数决定，而不是由工作量决定；如果你的形状是「一条指令触发四十次工具调用」，按活动算力计费时要盯的是并发峰值和内存占用，不是调用次数。

判断的顺序因此确定下来：先把自己的任务形状量出来，再看哪一种口径在惩罚它。这件事必须在选型前做，因为平台一旦定下，任务编排、重试策略、审批位置都会朝它的口径形状生长，换平台的成本远高于换模型。

我们因此建议把「一次工作怎么计数」当成架构参数写进设计文档，和并发上限、超时时间放在一起，而不是留在采购部门的合同附件里。

口径不止一层，别当成替代关系

三种计费不是互斥的，而是叠在一起。模型调用本身仍然按 token 计费，平台再收一层执行计费，两层计的是你工作里不同的段。真正需要问清的是：每一层分别对你的哪一段收费，以及哪一段在你的形状里占比最大。

同一个星期里，还有第三家平台把评测、按身份作用域鉴权和轨迹视图打包进了自己的产品。控制面正在从差异化能力变成平台自带件。这意味着计费口径也会跟着平台的默认形状走。口径的问题要么在采购时一次问清，要么在第一次账单异常时重新学一遍。

签约前要问的三个问题

• 一次交互如何计数。是一轮对话算一次，还是一次工具调用算一次？同一轮里调用工作流与子智能体是否另计？
• 空闲等待算不算钱。等审批的两小时、等外部接口返回的四十秒，在你的账单上是不是 0。
• 失败重试算谁的钱。同一个任务重试三次，账单是一次还是三次；如果重试由平台自己的自动恢复触发。这笔钱由谁承担。

三个答案都要写进合同，连同口径变更的通知义务。还有一条更实际的要求：让平台提供可导出的逐任务记录，包含轮数、工具调用数、等待时长与峰值内存。没有这些数字，你连自己的任务形状都算不准，也就无法预判换口径时账单会往哪边走。我们建议把逐任务记录写进验收条件：轮数、工具调用数、等待时长、峰值内存这 4 个数。

选型之前，先把自己的形状量出来

有一件内部的事应该排在选型之前：在现有流水线里记录每个任务的轮数、工具调用数、等待时长和峰值上下文，跑两周就有一个分布。有了这个分布，选型的问题就从「哪家便宜」变成「哪家的口径对我的形状有利」，前者只能靠感觉，后者可以被复核。

这件事的收益不止于省钱。当你知道自己的任务平均要等多久、等待发生在哪一段，也就知道了哪些等待可以并行、哪些可以提前拿掉。这部分优化不需要任何供应商配合，今天就做得了。

什么样的口径最容易被算错

最常被漏掉的是重试。自动恢复看起来是平台送的可靠性。不过在按轮计费的口径下，一次自动重试就是一次新的执行，账单上多出来的那部分不会单独标出来。第二种是长尾任务，一两个跑了一整夜的会话，在预置容量口径下把月度成本拉高，在活动算力口径下几乎不留痕迹。第三种是人，工程师为了等审批把会话挂在那里。这段时间在两种口径里的归属完全不同。

这三种情况都没法靠读定价页算出来，只能靠逐任务记录去对。这也是我们把它列为签约前置条件的原因：口径写在纸上，账单长在数据里，能对上账的才叫口径。

把两种口径放在同一个任务上算一遍

口径之争可以在一个具体任务上算清楚。假设一个退款审批任务：用户提一次诉求，智能体来回澄清 15 轮，工具调用合计 45 次，中间等人审批占掉 10 分钟，处理过程中峰值上下文 8 万 token。

• 按轮计费。这个任务产生 15 次执行。45 次工具调用不另外计费，10 分钟等待也不产生费用。不过用户如果多问一句澄清，账单就多一轮。
• 按活动算力计费。计费的是思考与执行真正占用的那几十秒，10 分钟等待为 0；成本重心移向 8 万 token 的峰值上下文，要么压小它，要么接受它。

同一件事，在两种口径下哪个更便宜，取决于「轮数乘单价」与「活动秒数加峰值内存」哪个更大。这个比较必须在签约前做完，签约后你只能接受已经长进架构里的那一侧。

三种常见编排，各自适合哪一种口径

• 一次提问触发长链编排。用户只问一次，智能体在单轮内完成十几次工具调用与子智能体分工。轮数少、链路长，按轮计费的口径对这类形状最友好。
• 多轮澄清型交互。信息不齐，靠来回追问补齐，轮数天然多。这类形状在按轮计费下最贵，在按活动算力计费下最接近它的真实消耗。
• 后台长跑批处理。任务成批触发、长时间等外部系统、并发高但单次算力零碎。等待占比高、峰值上下文小，按活动算力计费的口径对这类形状有利。

这张对照表的用处不是让你去挑最便宜的平台，而是让你在编排设计阶段就知道自己在往哪一种形状上走。同一个业务需求，用澄清型交互还是长链型交互实现，账单结构完全不同。这意味着，交互方式的选择同时是一次成本选择。同一个业务在两家平台上被设计成两种交互，设计者往往没有意识到自己是在跟着计费口径走，等到第一次对账才发现交互形状早就替账单做完了决定。

一个反直觉的结果：口径会塑造产品交互

按轮计费的影响不只落在工程侧。当每一轮都算一次执行，把澄清问题一次问完、把上下文一次给足、让智能体在单轮里多做几步，都会直接反映在账单上。于是交互设计会出现一个不容易被察觉的偏移：从「一次问一句、逐步收敛」的对话，转向「一次性提交结构化描述、让系统自己补齐」的表单。后者对用户未必更自然。不过对账单更友好。换句话说，口径会一路走到产品设计里。

反过来说，等待不计费的口径不会推动这种偏移。它的压力落在并发与内存上，产品侧感受到的是「同时能跑多少个」而不是「用户要说几遍」。选平台的时候。这两种压力会以完全不同的方式回到你的产品决策里。

什么时候口径不值得花时间算

如果你的每个月度调用量还落在几百次这个量级，口径的差异在账单上是四舍五入的误差。这个阶段该花的时间在别处：把任务的结束判定写清楚、把重试策略定死、把审批位置放对。

口径开始变得重要，是在并发和等待成为常态之后：一天几百个任务并行、审批排队、外部系统响应时间进入分钟级。这时候账单的差异会从误差变成预算项。问题是，大多数团队手上只有一份月度总账单，看不出轮数与等待时长。判断自己处在哪个阶段的标志很简单，看你的任务里有多少比例的时间在等待，而不是在计算。我们建议把这个问题放进下一次架构评审，而不是留到采购环节。

参考来源

• n8n：Introducing n8n Agents（2026-09-25，含计费口径原文「One turn with an agent is one execution」与预览期边界说明）
• DigitalOcean：The agent-first cloud: why we built Managed Agents（2026-09-25，含「按活动 CPU 与峰值内存计费」与等待成本说明）
• DigitalOcean：Harness Runtime 定价页（活动 CPU 与峰值内存的公开单价）
• LangChain：LangSmith Engine 与 Managed Deep Agents 0.8（2026-09-25，评测、按身份作用域鉴权与轨迹视图一并进平台）