别再数令牌，开始数交付成果

AI编程智能体的成本账正在被重新计算。当开发者给AI智能体布置一个编程任务时，它并不是简单回答一次就结束，而是会规划、生成代码、运行测试，再反复修正错误。一个任务消耗的token量可能是普通聊天提示词的10到50倍，而且智能体越好用，调用次数就越多。在按token计费的模式下，创造价值最多的工作流反而可能变成最烧钱的。这种财务压力已经显现：据报道，Uber在扩大Claude Code的使用后，到4月份就花光了2026年全年的AI预算；GitHub Copilot从固定费率转向了按量计费；Gartner预测到2028年，AI编程的token成本将超过开发者的平均工资。 面对这种局面，企业的本能反应是限额——设置使用上限、席位限制、智能体启动前的审批流程。但一刀切的限制会卡住真正创造价值的工作流，而且它们优化的是一个错误的数字。每次token的成本衡量的是消耗，不是产出。有些花费确实是浪费，比如重试和失控的循环；但有些花费是在交付软件。计费表分不清这两者，支出上限同样分不清。 更合理的衡量指标是“每个已合并拉取请求的成本”：将AI辅助开发的总成本除以通过评审并合并的代码变更数量，同时跟踪返工率和缺陷率，防止更便宜的变更掩盖了质量下降。如果这个成本随着AI使用量上升而下降，且质量没有受损，说明开发者正在把更多的消耗转化为有用的软件。问题不在于用了多少token，而在于这笔投入产出了多少完成的工作。 要改善这个等式，需要做两件事：把昂贵的推理留给真正需要的任务，同时降低日常工作的成本。智能体编程并不需要在每一步都调用最强大的模型。困难的规划和新颖推理可以用前沿模型，或者政策要求时用本地部署的旗舰模型；而代码生成、测试编写、重复重构等适合的工作，可以路由到自己运营的开源权重模型上。通过网关根据任务复杂度、数据敏感性、成本和延迟来分配请求，就能把高端推理留给真正值得的时刻，而不是让整个工作流都承受高端定价。 开源权重模型让这种分工越来越可行。软件工程基准测试显示，领先的开源权重模型在某些任务上已经接近前沿模型的水平，但这并不意味着在每个代码库或工作流中都等价。在分配生产任务之前，需要用自己的代码、测试和验收标准来评估候选模型。 接下来要想清楚谁拥有算力。租用推理时，每次调用都会增加账单；而自有算力的大部分成本是前期投入，使用越多，每次调用就越便宜。经济账很简单：按token计费让重度使用更贵，自有算力则随着团队使用增加而变得更高效。但自有算力并非免费，电力、运维、维护和折旧都要算进去，真正重要的数字是每个已合并拉取请求的全负载成本。自有算力还带来一种永远不会出现在发票上的价值：对敏感代码的控制权。当代码生成和测试在本地运行时，专有代码留在企业内部，只有经过批准的规划提示词和受管控的例外情况才通过企业控制的网关发送给外部模型。这打开了那些因安全问题而迟迟无法采用AI的敏感代码库，而最大的收益恰恰在那里等着。 惠普企业（HPE）的实践提供了一个参考：其混合AI平台将来自150多个内部应用的日常负载路由到本地运行的开源权重模型上，包括在HPE Private Cloud AI上运行的模型，结果token成本下降了30%到50%。