Tokenomics：量化 Agent 软件工程中的 token 都花在哪了（中文全译）

Tokenomics：量化 Agent 软件工程中的 token 都花在哪了（中文全译）

翻译说明：本文是 arXiv 论文 Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering（arXiv:2601.14470，2026-01-20 提交，MSR 2026 会议论文）的中文全译，由智测团队翻译。原作者：Mohamad Salim、Jasmine Latendresse、SayedHassan Khatoonabadi、Emad Shihab（Concordia University DAS Lab，加拿大蒙特利尔）。原文以 CC BY 4.0 许可发布，允许翻译与再分发，须署名。译文保留原文全部章节、数据与结论；参考文献列表与文内引注编号从略，框架名、模型名、指标名保留英文。图 1、图 2 随文保留，版权归原作者。数据与复现包：https://zenodo.org/records/17430187 。

摘要

基于 LLM 的多 Agent（LLM-MA）系统正被越来越多地用于自动化复杂的软件工程任务，例如需求工程、代码生成和测试。然而，它们的运行效率和资源消耗仍缺乏理解，不可预测的成本和环境影响阻碍了实际采用。为此，我们对软件开发生命周期（SDLC）中一个 LLM-MA 系统的 token 消耗模式做了分析，旨在理解 token 在不同软件工程活动中消耗在哪里。我们分析了 ChatDev 框架用 GPT-5 推理模型执行 30 个软件开发任务的执行轨迹，把其内部阶段映射到不同的开发阶段（设计、编码、代码补全、代码评审、测试、文档），以创建一个标准化的评测框架。然后我们量化并比较了这些阶段间的 token 分布（输入、输出、推理）。

我们的初步发现表明：迭代式的代码评审阶段占了 token 消耗的大头，平均 59.4%。此外，我们观察到输入 token 始终构成最大份额，平均 53.9%，为 agent 协作中可能存在的重大低效提供了实证证据。我们的结果表明，agent 软件工程的主要成本不在初始代码生成，而在自动化的精炼与验证。我们的新方法论可以帮助从业者预测开销、优化工作流，并把未来研究引向开发更省 token 的 agent 协作协议。

关键词：大语言模型，面向 AI 的软件工程，多 Agent 系统，Tokenomics

1. 引言

大规模软件工程正日益探索基于 LLM 的多 Agent（LLM-MA）系统，以自动化横跨软件开发生命周期（SDLC）的复杂任务。这些 LLM-MA 框架用专门的大语言模型（LLM）agent 模拟人类团队（例如产品经理、架构师、开发者、测试者），协作设计、编写和验证软件。原则上，LLM-MA 系统可以通过在 agent 间分工来提高自主性和稳健性。先前工作指出，LLM-MA 系统鼓励发散思维、增强推理和事实性，并能扩展到超出单 agent 能力的问题。对软件工程（SE）而言，这意味着 LLM-MA 系统可以以统一方式自动化从需求到测试的端到端工作流。

近期研究已开始分析这些系统的行为和效率。AGENTTAXO 框架为剖析一般 LLM-MA 系统中的 token 分布提供了一个分类，引入「通信税」（communication tax）概念来描述 agent 间交互的开销。此外，MAST 失败分类揭示：LLM-MA 系统中的许多问题源于系统性的设计和协调挑战——例如步骤重复或验证不完整——而非单个 LLM 的局限。虽然这些先前工作为理解 token 分布和系统性失败模式建立了必要的分类，它们分析的是一般上下文中的 agent 行为。关于这些系统专门应用于独特的、多阶段 SE 工作流时的资源效率，存在一个重大知识空白。实际采用的终极问题——「token 都花在哪了？」——在 SE 领域仍未被回答。

因此，在本文中，我们引入「tokenomics」一词，作为对 LLM-MA 系统运行效率和资源消耗的研究。据我们所知，这是第一项在 SE 上下文中对 tokenomics 做实证分析的研究，通过 SDLC 的视角检视一个聚焦 SE 的 LLM-MA 系统的执行轨迹。为引导研究，我们聚焦以下基本研究问题：LLM-MA 系统在软件开发任务中的 token 消耗模式是什么？

为回答它，我们分析 token 消耗在不同开发阶段间的分布——这些阶段由我们映射多 agent 框架 ChatDev 的内部阶段导出。ChatDev 模拟一家虚拟软件公司，其中多个 agent 角色（例如程序员、测试者）通过多轮对话协作完成 SDLC。回答这个问题是构建经济上和环境上可持续的 agent SE 系统的第一步。

本文贡献了一项实证分析、一个精心整理的 30 条执行轨迹数据集，以及一个完整的复现包。

2. 研究设计

我们研究的目标是实证调查一个 LLM-MA 系统在执行端到端软件开发任务时的 token 消耗分布。为此，我们选择 ChatDev 作为初始分析系统。做这个选择是因为它的「chat chain」架构代表一个清晰的顺序瀑布模型（设计 → 编码 → 测试），使其阶段界限分明、适合映射到软件开发阶段。此外，该框架是最流行、被引用最多的开源框架之一。

2.1 数据集构建

我们在 30 个不同的软件开发任务上执行 ChatDev，提示词来源于 ProgramDev 数据集——基础 MAST 研究也用了它。所选提示词从简单算法（例如 Fibonacci 数生成）到更复杂的应用（例如一个国际象棋游戏），确保任务多样性。近期工作表明，模型分配的推理 token 数可以作为任务复杂度的代理。我们的数据集在 30 个任务间表现出很宽的推理 token 消耗范围（从 17,280 到 40,000 token），说明本研究有足够的任务复杂度多样性。

2.2 模型选择

选择 GPT-5 推理模型作为所有 agent 的骨干。这一决定基于该模型的流行度和新颖性、它对 agent 用例的适用性，以及它强大的推理能力——这与自主 agent 的期望一致。如表 1 所详述，使用的模型版本是 gpt-5-2025-08-07。该模型不支持温度参数，因此使用了默认值 1.0。

表 1. 实验中使用的 GPT-5 模型细节

2.3 分析流水线

为分析收集的数据，我们设计并实现了一个多步流水线，如图 1 所示。

轨迹收集。 我们对 ChatDev 做了埋点，记录 30 个任务中每一个的完整执行轨迹，捕获每次 LLM 调用，包括提示词、响应和相关 token 计数（输入、输出、推理）。

阶段映射。 我们工作的一项核心方法论贡献，是把 ChatDev 内部的、框架特定的阶段映射到普遍理解的开发阶段。这一抽象允许可泛化的分析，并可扩展到其他 SE LLM-MA 框架。所用映射详见表 2。

token 聚合。 使用这一映射，我们编写 Python 脚本解析收集的轨迹，并为所有 30 次运行中的每个开发阶段聚合 token 计数，计算总量并按输入、输出和推理 token 分解。

表 2. ChatDev 内部阶段到不同软件开发阶段的映射（映射基于框架文档中对每个阶段的描述）

3. 研究结果

本节呈现研究问题的结果：动机、回答问题的方法和结果。

3.1 RQ：LLM-MA 系统在软件开发任务中的 token 消耗模式是什么？

动机。 理解 agent SE 系统的 token 消耗模式（即「tokenomics」）对其实际和可持续的采用至关重要。高 token 用量直接转化为更高的金钱成本、能源消耗和环境影响。通过识别 token 在 SDLC 内消耗在哪里，我们可以创建一张「成本地图」，使从业者能预测开销并优化工作流。虽然先前工作分析了一般多 Agent 系统（MAS）的行为，但在软件开发这一特定上下文内理解这些效率模式存在明确空白，本 RQ 旨在填补。

方法。 为回答这个问题，我们分析第 2 节所述研究流水线的聚合 token 数据。我们聚焦两个主要维度：（1）总 token 在映射后的开发阶段（设计、编码等）间的分布；（2）每个阶段内输入、输出和推理 token 的比例。

发现 1：代码评审阶段主导 token 消耗。 我们的分析揭示 token 使用在整个开发过程中分布极不均匀。如图 2 所示，出现了一个清晰的 token 消耗层级。图中「n」值表示某个特定阶段被执行的任务数（共 30 个）。该值不总是 30，因为多 agent 系统内的 agent 自主决定执行哪些阶段，并非每个任务都需要所有阶段。误差条表示 ±1 标准差，指示每个阶段 token 消耗的波动。代码评审阶段是最大的消耗者，在全部 30 个任务中平均占 token 的 59.4%。代码补全阶段（在 30 个任务中出现 6 次）同样昂贵，在那些运行中平均占 token 的 26.8%。这两个聚焦精炼的阶段之后是文档（平均 20.1%）和测试（平均 10.3%，后者在 30 个任务中出现 12 次）。相比之下，初始编码（平均 8.6%）和设计（平均 2.4%）便宜得引人注目。这表明 agent 软件工程的主要成本不在初始代码生成，而在迭代式、对话式的精炼与验证过程。

发现 2：token 消耗由输入 token 主导。 在除编码阶段外的所有阶段，我们观察到一个一致模式：输入 token 远超输出和推理 token。平均而言，所分析每个任务的总 token 用量由 53.9% 输入 token、24.4% 输出 token 和 21.6% 推理 token 组成。这种输入对输出约 2:1 的比例，为先前工作中识别的「通信税」提供了强有力的实证证据——agent 在协作对话中反复传递大段上下文。这凸显了当前 agent 协作协议的一个重大低效：多数 token 花在传递上下文而非生成新输出上。这也表明通信税可能是对话式多 agent 架构的固有特征，未来工作应进一步调查这一现象。

发现 3：软件开发阶段表现出不同的 tokenomics 画像。 对每阶段 token 比例的更深入观察（详见表 3）揭示了不同软件工程活动的独特模式。编码阶段是一个显著离群者：输出占重（58% 输出对 6.9% 输入）。这很直观，因为它涉及从更简洁的设计规格生成冗长的源代码。相比之下，像代码评审这样的验证阶段和文档阶段是输入占重（分别为 51.4% 和 80.2% 输入）。这些阶段消耗大量现有代码作为上下文，以产出小的、分析性的输出。这些不同画像为不同工程活动提供了一张「成本地图」，使从业者能更好地预测开销并识别过程优化的机会。

表 3. ChatDev 配 GPT-5 推理模型、跨 30 个任务的逐阶段 token 比例分解

RQ 的答案：在 ChatDev LLM-MA 系统中，token 消耗高度集中在 SDLC 的代码评审阶段。此外，token 消耗由输入 token 主导，反映出一个可能重大的通信税；不同开发阶段表现出与软件工程任务性质（例如规划、推理或验证）对应的独特 tokenomics 画像。

4. 讨论

我们的初步结果提供了 agent 软件开发的一张初始「成本地图」，对从业者和研究者有若干启示。

代码评审阶段的巨大 token 成本可被解读为「对话的成本」。这是 LLM-MA 系统固有对话架构的直接后果：agent 迭代地来回传递完整代码上下文以精炼它。这表明当前用于验证的 agent 协作协议高度低效——为执行可能只涉及微小修正的任务消耗大量资源。这与 MAST 分类的发现一致：与验证和步骤重复相关的失败很常见，说明高 token 用量可能是 agent 系统试图通过蛮力对话克服这些固有协调挑战的症状。

对从业者，我们的发现为成本预测和过程优化提供了基础。不同的 tokenomics 画像意味着一个 agent 驱动项目的成本可以基于所需工作类型来估算。例如，以大量初始编码为主的全新项目（greenfield），其成本结构会不同于聚焦重构和调试现有代码的项目——后者将由昂贵的、输入占重的代码评审循环主导。这一洞察可以指导设计决策，例如在代码评审阶段之前整合一个「人在回路」检查点，以防止昂贵的迭代循环，从而最大化经济和计算效率。

对研究界，我们的结果提出了一个明确挑战和一个潜在解法。挑战是为验证和精炼设计更省 token 的协作协议，超越朴素的全上下文传递。此外，明显需要一个标准化、全面的评测框架。这个框架可以作为共同基础，在未来工作中对不同 LLM-MA 架构（例如 ChatDev 的层级式对话工作流对 MetaGPT 的基于 SOP 的装配线）的效率做基准和比较，提供一块「罗塞塔石碑」，把框架特定的操作翻译成通用的软件工程活动。

5. 有效性威胁

在解读我们的发现时，需要考虑本工作的几个重要局限。第一，我们的分析基于单一 LLM-MA 系统（ChatDev）和单一 LLM（GPT-5 推理模型）。观察到的 token 消耗模式在其他 LLM-MA 架构中，或在 token 效率不同的其他 LLM 上，可能不同。第二，30 个软件开发任务虽然多样，可能不代表所有可能的软件开发场景和复杂度。整理数据集的规模是当前缺乏公开的、大规模 SE 特定 agent 轨迹基准的直接后果，这使数据整理成为耗时且昂贵的过程。第三，一些开发阶段只在 30 个任务的一小部分中执行。例如代码补全（n=6）和测试（n=12）阶段被 agent 系统触发的频率不高。关于这些特定阶段 tokenomics 画像的结论基于小样本，可能不具代表性，并可能限制那些特定发现的可泛化性。最后，我们提出的 ChatDev 内部阶段到软件开发阶段的映射是一种抽象。虽然我们相信它对创建标准化评测框架是逻辑且有用的，它代表了 agent 活动若干可能映射中的一种。

6. 结论与未来工作

这篇进行中的工作论文着手回答 agent 软件工程中「token 都花在哪了」。我们用 ChatDev 框架做的初步实证研究揭示，答案并不直白。成本不是均匀分布的，而是压倒性地集中在代码评审这一迭代式、对话式阶段。我们还发现，构成「通信税」的输入 token 形成了 token 用量的主体，凸显了一个未来优化的关键领域。

本研究为一个全面的研究议程奠定了基础。未来工作应聚焦：（1）用更多任务扩展我们的数据集以确保更好的可泛化性。（2）把分析扩展到其他 LLM 以理解模型特定效应。（3）把分析扩展到其他 LLM-MA 系统，对架构差异如何影响 tokenomics 做比较研究。（4）调查 token 消耗模式与失败模式之间的关系。（5）进一步开发并验证我们的开发阶段映射，作为对 SE agent 效率做基准的稳健、通用框架。

署名与许可：原文 Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering，作者 Mohamad Salim、Jasmine Latendresse、SayedHassan Khatoonabadi、Emad Shihab（Concordia University DAS Lab），arXiv:2601.14470v1 [cs.SE]，2026-01-20，MSR 2026（23rd International Conference on Mining Software Repositories，里约热内卢）。原文以 CC BY 4.0 许可发布。中文全译由智测团队完成，译文同样以 CC BY 4.0 发布；图 1、图 2 版权归原作者。原文地址：https://arxiv.org/abs/2601.14470 。数据与复现包：https://zenodo.org/records/17430187 。译文中省略了参考文献列表与文内引注编号；框架名、模型名、指标名保留英文。如译文与原文有出入，以英文原文为准。