智能体的成本账：从数token到数交付

本期要点

• 编码智能体单任务 token 消耗是普通对话的 10–50 倍
• 智能体越有用，调用次数越多，成本非线性上升
• 评估口径应从 token 计量转向实际交付

一个任务，几十次调用

开发者把编码任务交给 AI 智能体时，得到的不是一次回答。智能体会先规划，再生成代码，然后运行测试，并根据错误反复修正——这是一个多轮循环。MIT Technology Review 给出的量级是：单个任务消耗的 token 可达基础聊天提示的 10 到 50 倍。(来源: MIT Technology Review)

这个数字本身不新鲜，但它把智能体产品化的一个核心矛盾摆到了台面上：智能体的能力来自循环，成本也来自循环。

越有用，越贵

文章给出的判断是：智能体越有用，调用就越多。工具调用、测试执行、错误重试，每一步都要重新把上下文送进模型，token 消耗随任务复杂度放大，而不是随用户数线性增长。(来源: MIT Technology Review)

对做智能体产品的团队来说，这直接影响三件事：单任务毛利怎么算、定价按什么单位、以及哪些环节值得用更贵的模型。按对话轮次计费的老口径，在智能体场景下会失真。

换一把尺子

标题给出的主张很直接：停止数 token，开始数交付。也就是说，衡量智能体不该看它烧了多少 token，而该看它完成了多少可用的工作——代码是否通过测试、任务是否闭环。(来源: MIT Technology Review)

这是一个可被推翻的判断：如果后续出现更高效的推理与上下文复用方式，单任务 token 消耗大幅下降，那么「成本高」就不再是智能体落地的主要约束，评估重心也会随之移动。但在当前量级下，把交付结果作为核心指标，比统计调用量更接近真实价值。

对智能体团队而言，今天更值得回答的问题不是「我们的 agent 调了多少次模型」，而是「它替用户交付了什么，以及这份交付的成本是多少」。