开发者呼吁关注AI智能体实际交付成果而非token数
原文：Stop counting tokens, start counting what ships
当开发者给AI智能体分配一个编程任务时，智能体所做的远不止回答一次。它会规划、生成代码、运行测试，并反复迭代以修正错误。一个单一任务消耗的token量可能是一次基础聊天提示的10到50倍。智能体越有用，它发起的调用就越多。在按token计费的模式下，创造最大价值的工作流也可能变得最为昂贵。财务压力已经显现。据报道，Uber在扩大Claude Code的使用后，于4月就耗尽了其整个2026年的AI预算。GitHub Copilot从固定费率定价转向了按量计费的额度制。Gartner预测，到2028年，AI编程的token成本将超过开发者的平均薪资。自然的应对方式是配给——使用上限、席位限制，以及在开发者启动智能体前的审批。但一刀切的限制可能扼杀那些正在创造价值的工作流。它们优化的还是错误的数字。每token成本衡量的是消耗，而非成果。有些支出反映的是浪费，包括重试和失控的循环。有些则代表着交付软件的工作。计量器无法区分二者，支出上限同样不能。衡量交付的软件 一个更好的衡量指标是每个已合并拉取请求的成本：AI辅助开发总成本除以通过审查并被合并的变更数量。同时跟踪返工和缺陷，以免更便宜的变更掩盖了质量的下降。如果该成本随着AI使用量的上升而下降，且不损害质量，说明开发者正在将更多消耗转化为有用的软件。问题不在于他们用了多少token，而在于这笔投入产出了多少完成的工作。改善这个等式需要两项改变：将昂贵的推理留给真正需要它的任务，并降低日常工作的成本。让模型匹配任务 智能体编程并不需要在每一步都使用最强大的模型。将前沿模型——或在政策要求时使用本地部署的旗舰模型——用于困难的规划和新颖推理。将合适的任务路由……