别再数Token，开始数交付

编者按：AI智能体正把大模型从“问答工具”变成“执行系统”。当衡量尺度仍停留在token消耗时，我们很容易把成本当成绩效。真正应该追问的是：它交付了什么，交付得是否可靠，单位成果的成本是多少。

从一次回答到多轮闭环

MIT Technology Review文章《Stop counting tokens, start counting what ships》指出，开发者给AI智能体一个编码任务后，智能体并不是简单回答一次。它会先理解需求、制定计划，再生成代码、运行测试，发现错误后继续修改，并重复这一过程直到任务完成或达到停止条件。这样的多步闭环让智能体更像一名初级工程师，而不是一个聊天机器人。

当开发者给AI智能体一个编码任务，它不只是回答一次，而是规划、生成代码、运行测试，并反复修正错误。一个任务可能比基础聊天提示多消耗10到50倍token。

这也解释了为什么智能体越有用，调用量越大。普通聊天只需一次模型前向计算，而编码智能体可能涉及多轮推理、工具调用、代码执行、日志读取和上下文重载。每一次尝试都消耗token，失败重试还会放大消耗。token在这里不是异常，而是智能体工作方式的自然结果。

Token计费的盲区

过去两年，大模型API普遍按输入和输出token计费，token成为最直观的成本单位。但token只描述模型读写了多少文本，并不描述任务是否完成、代码是否可合并、缺陷是否减少。一个消耗大量token却频繁失败的智能体，可能比一个token更少但稳定交付的智能体更昂贵。反过来，一个看似token消耗高的智能体，如果能把开发者从重复劳动中解放出来，其单位任务成本可能更低。

企业真正支付的不只是token。一次智能体编码任务还包括工具调用、测试环境、代码托管、日志存储、人工审核和失败返工。把这些成本加总，才能得到任务级成本。若只盯着每百万token价格，就像只按纸张和墨水计算一篇文章的成本，却忽略编辑、校对和发行。

把“交付”变成度量单位

文章标题给出的方向很明确：停止数token，开始数交付。对编码智能体而言，交付可以具体化为合并的拉取请求数量、解决的issue数量、测试通过率、缺陷逃逸率、任务周期时间、返工率和开发者采纳率。更进一步的指标是“每个成功任务的成本”，即总消耗除以通过质量门槛的交付数量。

这要求团队建立任务级可观测性：记录每次智能体运行的模型调用、工具使用、重试次数、人工介入和最终结果，并把结果与业务指标关联。只有这样，才能比较不同模型、不同提示策略和不同智能体框架的真实效率，而不是被token单价牵着走。

行业正在转向结果定价

随着智能体进入生产环境，AI采购逻辑也在变化。客户越来越关心“解决一个工单多少钱”“完成一次代码审查多少钱”“每处理一千份文档多少钱”，而不是单纯比较token价格。供应商则可能探索按任务、按席位、按结果或混合计费。无论计价方式如何变化，底层都需要一套可审计的结果度量。

需要警惕的是，只数交付也可能催生刷量。没有质量门槛的“交付”会制造更多返工。因此，交付指标必须与质量、安全和人工审核结合。token仍应作为运营指标保留，用于容量规划、成本优化和异常检测，但它不应成为价值判断的中心。

结语

智能体的价值不在它消耗了多少token，而在它把多少工作真正推进到完成。AI时代需要新的单位经济学：以任务为核算单元，以交付为价值锚点，以质量为约束条件。停止数token，开始数交付，才是评估智能体生产力的正确起点。

本文编译自MIT Technology Review