你用 Claude Code 写了一天的代码。晚上回顾，你脑子里浮现的句子是”今天完成了三个 feature”还是”今天烧了两千万 token”？
绝大多数 builder 用的是前一种语言。但行业算账用的是后一种——API 按 token 收费，投资人看 token 消耗判断增长，NVIDIA 的博客标题直接写过 “cost per token is the only metric that matters”。
这是两种完全不同方向的指标。Token 是输入性指标：它衡量你消耗了多少算力。你脑子里那个”完成了几个 feature”是输出性指标：它衡量你产出了什么。输入指标和输出指标指向不同的优化目标，这件事在企业管理里是一个老问题——但放在 AI 行业，它正在变成一个没法再拖的问题。
用输入指标管理任何东西，都有一个内建缺陷：它奖励消耗，不奖励效率。
这不是 token 特有的。如果你用”代码行数”考核程序员，程序员会写出更多行。如果你用”会议数量”考核管理者，管理者会开更多会。输入指标天然倾向于被刷高——因为刷高它的成本比刷高输出指标低得多。亚马逊和 Meta 内部已经出现了员工故意让 agent 跑不必要的任务来刷 token 消耗量，因为这个数字在他们的内部 leaderboard 上代表”AI 使用活跃度”。
Agent 把这个缺陷放大了。一个人跟 Claude 聊天，token 消耗是线性的、可预期的。一个 agent 在执行任务时会进入循环、反复调用工具、扩展上下文——它的 token 消耗曲线不是线性的，可能在某个 step 突然跳一个数量级。做企业计费的 Portal26 观察到，客户”不敢放大 agent 使用量，因为不知道下个月账单是三位数还是五位数”。来源同上当你的指标在 agent 场景下既可以被刷、又不可预期，它连最基本的成本管理功能都失效了。
但即便解决了可预期性，token 作为指标还有一个更深的问题：它完全不告诉你钱花得值不值。你拿到一份 800 万 token 的账单，它不会告诉你这 800 万 token 完成了 20 个任务还是 200 个、成功率是 30% 还是 90%、有没有反复重试同一个失败路径。token 衡量的是”你烧了多少钱”，不是”你买到了什么”。
到这里，自然的问题就是：那直接衡量输出不就行了？
问题在于，真实的商业输出——“这个 agent 帮公司多赚了多少钱”“帮团队省了多少时间”——本身就是最难量化的东西。企业里衡量一个人的绩效已经够难了，衡量一堆 agent 的绩效只会更难。这就是为什么每个时代都宁可用一个 proxy（代理指标）来代替真正的输出：它不完美，但只要它和真实输出的方向大致对齐，就比输入指标强。
2012 年 Facebook IPO 是一个教科书级的案例。Facebook 的真正价值是什么？社交网络的密度、用户之间的互动频率、广告的精准度——这三样东西都不好直接量。所以它找了一个 proxy：月活跃用户数（MAU）。MAU 不是真正的输出——一个人登录了不代表他产生了广告价值——但它和真正的价值创造大致同向：用户越多，网络越密，广告越准。在它之前，互联网行业用的是 pageview（页面浏览量），这是一个输入性指标：更多页面 = 更多广告位。Facebook 用一场史上最大的 IPO 把这个 proxy 换掉了——不是因为它证明了 MAU 更精确，而是因为它讲通了一个资本市场愿意买单的故事。
后续 Twitter、Snapchat、微信全跟了。proxy 一旦被最主要的玩家在资本市场上立住，就变成了行业默认语言。
回到 AI 行业。要找的其实不是一个”更好的 token”，而是一个像 MAU 那样的 proxy——一个虽然粗糙、但和 agent 的真实产出方向大致对齐的指标。
目前有两个比较成形的候选。
一个是 Salesforce 2026 年推出的 AWU（Agentic Work Unit），定义为 agent 完成的每一个可验证的离散任务。CEO Marc Benioff 说”价值不在 token 里，在平台用 token 做了什么工作”。Salesforce 已经在用 AWU 做结果导向定价——agent 成功解决问题才收费，失败不收费。
同一个月，百度在 Create 2026 上也提了一个概念叫”日活智能体数”（DAA），思路是数”每天有多少个 agent 在活跃工作”。百度 Create 2026 报道
两个 proxy 的逻辑可以用一个比喻说清楚：AWU 是数计件，DAA 是数人头。
数计件更接近真实的产出——“完成了一个任务”本身就带有产出意味。但它面临一个粒度问题：客服 agent 回答一个问题算一件，代码 agent 修一个 bug 算一件，两者的难度和商业价值差了十倍。如果不对”一件”做加权，这个 proxy 会把不同价值密度的工作揉成一个数字。
数人头更简洁——一个数字，一张 slide。但它和真实产出的距离更远。“活跃”不代表”产出”——一个 agent 可以在后台做一堆无效操作仍然被计为”活跃”。而且百度目前没有公布什么算”一个 agent”、多 agent 协作怎么去重、任务失败算不算活跃。这些问题不解决，“数人头”就面临和早期 MAU 一样的公信力问题——谁报谁有理。
两个方案都远未成熟。都没有第三方审计。都依赖提出者自己的平台作为计数基础。Salesforce 的方案因为绑定在付费产品上，至少有一个市场检验机制——客户不买单，定价就得改。百度的方案目前更像一个叙事工具。
但它们不重要在具体方案上。它们重要在方向：两家性质完全不同的公司，在同一个时间窗口，不约而同在推同一个转向——把用来算账的指标从”消耗了多少”换到”完成了多少”。
这不是会计问题。这是产品方向的扳道器。
当行业用 token 当核心指标时，平台的最优策略是让用户消耗更多 token——更长的上下文、更复杂的推理链、更多的工具调用。这不是阴谋论，是任何公司都会被自己的 KPI 推着走的方向。token 增长是收入增长，产品团队被考核的自然是 token 消耗量。
当行业开始认真对待一个输出侧的 proxy——不管是数计件还是数人头——激励结构就会翻转。平台的最优策略不再是让你烧更多 token，而是让你的 agent 用尽可能少的资源完成尽可能多的任务。这意味着更精简的工具调用、更准确的一次推理、更少不必要的重试。
两种指标导向，导出的产品方向完全不同。在前一种世界里，builder 拿到的 agent 框架会越来越复杂——因为复杂消耗 token。在后一种世界里，框架会越来越克制——因为克制完成任务更快。你更想要哪一种，可能心里已经有答案了。
眼下这场迁移还处在早期。有力推手的数量还不够——如果 Microsoft 在 Copilot 财报会上、或者 Google 在 Android agent runtime 发布时也提出自己的 agent proxy，整个行业会迅速进入”新旧指标并存”的过渡期。但方向本身已经不需要论证了。模型推理成本以每年 9 到 900 倍的速度下降，token 作为收入单元在持续贬值。当计费单元本身的价值在缩水、而它的消耗量又在 agent 场景下失控，找一个新的 proxy 就不再是”要不要”的问题，是”什么样”的问题。
每个时代的 proxy 初稿都是粗糙的——GDP 的初稿在 1934 年只是 库兹涅茨给美国国会的一份备忘录。粗糙没关系。方向对了，剩下的交给市场去选。