代码不是最烧 token 的地方。

2026 年 1 月发布在 arXiv 的论文《Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering》（arXiv:2601.14470）给了一个反常数字：在 ChatDev 执行的 30 个软件开发任务里，代码审查阶段平均吃掉 59.4% 的 token。

这事有意思的地方在于，它把“AI 会不会写代码”这个问题，往后推了一步。真正上线多智能体编程系统时，钱和算力可能更多花在反复看、反复改、反复传上下文上。

论文做了什么：把 token 账本拆到六个阶段

这项研究基于 ChatDev 框架和 GPT-5 reasoning 模型。研究者追踪了 30 个软件开发任务的执行轨迹，并把流程拆成六个阶段：设计、编码、代码补全、代码审查、测试、文档。

它不是在评测哪个工具最好，也不是在证明哪种模式最省钱。它做的是一件更基础的事：看 token 到底流向哪里。

观察项论文中的设置或结果该怎么理解
论文Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering关注智能体软件工程中的 token 分布
arXiv 编号2601.144702026 年 1 月发布
样本30 个软件开发任务能看初步趋势，不能下行业定论
框架与模型ChatDev + GPT-5 reasoning 模型结果绑定这组技术设置
阶段设计、编码、代码补全、代码审查、测试、文档便于拆分流程成本
最大消耗阶段代码审查平均占 59.4% token成本中心可能在审查迭代
token 类型输入 token 平均占 53.9%上下文传递本身就是成本变量

我更在意的是后两个数字放在一起看。

如果审查阶段占比最高，输入 token 又超过输出 token，那么这组任务里的主要消耗就不太像“模型写了太多代码”。它更像是多智能体之间不断把需求、历史、代码片段、审查意见塞回上下文里。

这不是坏事的证据。审查可能真的在发现问题。论文衡量的是资源分布，不是代码质量。高消耗只能说明这里值得拆账，不能直接说明这里低效。

对工具团队和工程团队，动作不一样

多智能体编程和单人辅助式补全不是一回事。

偏单人辅助的 AI 编程工具，用户常关心的是补全准不准、响应快不快、一次调用贵不贵。ChatDev 这类框架走的是另一条路：让多个智能体模拟产品经理、程序员、审查者、测试者协作。

这条路更接近完整交付，也更容易把 token 花在协调上。人类团队里开会、评审、返工会消耗时间；到了智能体系统里，这些东西会变成提示词、上下文和多轮调用。

对 AI 编程工具开发者来说，优化重点不应只放在“让模型一次生成更长代码”。更现实的动作包括：

  • 压缩审查阶段传入的上下文；
  • 缓存已经确认过的中间结论；
  • 限制重复传递需求说明和历史对话；
  • 把稳定规则交给静态检查或固定校验器；
  • 给审查轮次和重试次数设置上限。

对企业工程团队来说，采购和试点也要换问法。

不要只问供应商“单次生成多少钱”。更该问：一次任务平均会触发几轮审查？上下文会不会越跑越长？失败重试是否可控？审查多花的 token，换来了更少返工，还是只是在重复确认？

如果这些问题答不清，团队可以先延后大规模迁移，把试点压在小范围任务里。不是观望 AI 编程本身，而是先看流程账本能不能算明白。

59.4% 不能外推成行业规律

这篇论文把结论称为 preliminary findings，这个边界要保留。

30 个任务不算大样本。框架限定在 ChatDev，模型限定在 GPT-5 reasoning。任务类型、复杂度、提示词设计、智能体角色分工，都会影响 token 分布。

所以，不能把“代码审查平均占 59.4% token”直接套到所有 AI 编程工具上。更不能据此说，多智能体编程一定贵，或者审查阶段一定该砍。

目前更该盯三个问题：

接下来要看什么为什么重要
同一批任务换到其他多智能体框架后，token 分布是否接近判断这是 ChatDev 特征，还是更普遍的流程特征
压缩上下文后，代码质量和返工率是否变化判断省 token 是否会带来隐藏成本
审查阶段的高消耗是在发现问题，还是在重复确认判断该优化协议，还是接受这笔成本

这才是这篇论文的价值。它没有把 AI 写代码包装成一次生成的魔法，而是把软件工程重新放回流程账本里。

开头那个数字也因此有了更清楚的含义：59.4% 不是行业定律，但它提醒我们，多智能体编程的成本中心，可能藏在“看起来很像正常协作”的地方。

会写代码只是起点。真正难的是，让智能体少带废话、少重复、少把上下文当垃圾桶。