OpenRouter Agent Token 使用量是人类流量的 5 倍，但领先优势主要来自缓存上下文

OpenRouter 的 agent token 使用量在 8 月达到 7.3 万亿 token，超过归属于人类的 1.4 万亿 token 的五倍。不过，据称其中超过 85% 的 agent token 来自缓存提示词，而非新处理的指令或新生成的回答。

这一差异令“如今 AI 使用 AI 的程度已超过人类”的说法变得复杂。Agent 确实会在每项任务中产生远多于人类的模型流量。然而，该图表衡量的是经由单一平台路由的 token，并非全球 AI 采用情况、支出、生产性工作或经济价值。

Futurum Group CEO Daniel Newman 在 9 月 30 日的一篇 X 帖文中放大了这些数字。他预测，这一比例将从五倍升至十倍，并继续走高。五倍这一数字来自观测到的 OpenRouter 流量；十倍则仍是一项未给出时间表或支撑模型的预测。

因此，真正的较量并非 agent 与人类之间的竞争，而是原始 token 量与有用工作之间的竞争。这一区别对于管理 agent 循环的开发者、评估回报的企业，以及规划内存容量的基础设施提供商而言都至关重要。

OpenRouter Agent Token 使用量跨过了明确门槛

8 月的数据表明模型流量发生了重大变化，但仅限于 OpenRouter 所衡量的环境。

OpenRouter 运营着一个网关，可在不同模型和推理提供商之间路由请求。其位置让公司能够观察到多样化的应用流量，包括直接对话、编程工具和自主工作流。

这张报道中的图表展示了截至 2026 年 8 月 10 日的七日平均 token 使用量。Agent 流量约达 7.3 万亿 token，而人类流量为 1.4 万亿 token。

由此得出的比例约为 5.2 比 1。这支持了一个更狭义的表述：在该测量期间，agent 在 OpenRouter 上产生的 token 流量是人类的五倍。

这并不能证明 ChatGPT、Claude、Gemini、私有云部署或本地托管模型中也存在同样的比例。这些系统代表着 OpenRouter 无法观察到的大量流量。

OpenRouter 还表示，自 2 月 6 日以来，agent 使用量增长了约十四倍。同一时期，人类 token 使用量增长约 2.8 倍。结合人类和 agent 式行为的混合流量，据称增长约 4.7 倍。

2 月 6 日是该数据集中人类流量最后一次高于 agent 流量的观测日期。这使得 8 月的结果比单日峰值更有意义。Agent 在约六个月内一直保持并扩大领先优势。

OpenRouter 将每个 API key 分类为 agent、人类或混合类型。据称，该系统使用了包括工具调用率、轮次数量和响应间隔在内的七项加权信号。

这种方法比单纯依赖应用名称更具信息价值。一个通用 API 客户端可以运行自主循环，而一款以 agent 为卖点的应用仍可能处于人类的直接控制之下。

不过，行为分类会带来不确定性。API key 可能服务于多个产品、团队或使用场景。工作负载也可能在不更换凭据的情况下，在人类主导和自动化行为之间切换。

混合类别承认了这种模糊性，但并未消除它。若重新归类其中一部分流量，agent 与人类之间的比例就会改变。

还有一个重要的语义问题：从通常的经济意义上说，agent 并不是独立客户。人类和组织部署它们、定义目标、为其请求提供资金，并决定其输出是否具有价值。

更准确地说，agent 是自动化中介。一次人类请求可能会启动规划、检索、工具执行、验证、修正以及反复的模型调用。

这种放大效应才是核心事件。AI 需求不再只取决于有多少人打开聊天窗口，而越来越取决于每次人类请求会触发多少机器活动。

OpenRouter 早前的100 万亿 token 研究也指出了同样的结构性转变。该研究将 agent 推理描述为一个包含规划、工具、修订和重复模型交互的延展序列。

研究发现，编程已成为提示词增长的主要来源。到 2025 年末，编程提示词的平均长度也已是通用提示词的数倍。

这些模式有助于解释 agent 为何跨过这一门槛。一个人可能只提交一次编程请求，而 agent 可以反复检查文件、调用工具、审阅测试结果，并重新发送其工作上下文。

8 月图表在平台规模上捕捉到了这种放大。它并不能证明自主软件已取代人类需求，而是表明人类需求正越来越多地通过会产生大量下游请求的系统传递而来。

一条人类指令可触发数千次模型操作

Agent 消耗更多 token，是因为它们将单个请求转化为持续进行的计算过程。

传统聊天机器人交互通常遵循可见的节奏：人写下提示词，收到回答，再决定是否继续。每一轮新对话都依赖另一项人类操作。

Agent 则可以在没有这一停顿的情况下继续运行。它会理解目标、创建步骤、选择工具、评估结果，并决定是否需要再次尝试。

以软件迁移为例。开发者可能要求 agent 将应用从一种云服务迁移到另一种。

第一次模型调用可以审查请求并形成计划。后续调用可能检查配置文件、搜索文档、编辑代码、运行测试、诊断故障并修订实现。

每次调用通常不只包含最新指令，还可能携带系统规则、工具定义、代码库详情、先前消息、命令输出和 agent 先前的决策。

这些累积材料构成上下文窗口，即模型在一次请求中可访问的文本和结构化数据。随着任务推进，这些上下文可能远大于最初的人类提示词。

工具使用会进一步增加流量。模型可能生成一条数据库查询、检查结果，然后再次调用模型来决定下一步。

并行 agent 会让这一过程再次倍增。一名协调者可能将研究、编码、测试和审查委派给不同工作者。每位工作者都维护着自己的指令和任务历史。

这解释了为何 token 量的增长速度可能远快于用户数量。基本单位已从一次对话轮次转变为一个工作流步骤。

OpenRouter 的数据还反映出推理和编程工作负载的增长。这类任务天然支持更长的交互，因为它们涉及中间状态、外部工具和反复验证。

学术证据表明，这种放大可能走向极端。一项 2026 年针对 agent 编程的研究发现，在其实验环境中，agent 任务消耗的 token 大约是代码聊天的 1,000 倍。

这项agent 成本研究还发现，重复运行之间存在巨大差异。在研究人员的测试中，同一任务的 token 使用量最高相差三十倍。

关键在于，更多 token 并不总能产生更好的结果。在额外消耗不再带来相应收益之前，性能往往会在某个中间水平达到峰值。

这一发现强化了 OpenRouter agent token 使用量背后的核心张力：不断上升的计数可能代表生产性自动化、不必要的重复，或两者兼有。

因此，agent 构建者面临着衡量已完成工作而非仅衡量产生的活动的压力。有用指标包括被接受的代码变更、已解决的支持案例、成功交易，以及无需人工修复即可完成的任务。

Token 只是文本处理的单位，本身并不衡量准确性、难度、新颖性或商业价值。

两个工作流可以消耗相同数量的 token，却产生截然不同的结果。一个可能解决棘手的工程问题；另一个可能反复执行失败的计划，直到达到限制而停止。

周边系统的设计决定了哪种结果更可能出现。清晰的完成测试可帮助 agent 识别成功；有边界的重试策略则能防止失败任务无限运行。

优秀的工具也能降低进行冗长文本推理的需求。结构化 API 可以返回精确结果，否则可能需要反复浏览和解读才能得到。

记忆架构同样重要，原因也在于此。Agent 并不需要在每一步都携带所有旧细节，而是需要保留与当前决策仍相关的那部分信息。

这正是可搜索的个人知识库能够支持人类主导工作流的地方。当系统谨慎选择上下文时，检索到的证据可以替代无差别地携带历史记录。

这种压力也延伸至开发者之外。企业买家如今需要评估产品如何控制循环、检索上下文和报告消耗。

一款产品在短暂演示中可能看起来高效，但在长期运行的工作负载中表现不同。生产任务会遇到缺失的权限、模糊的目标、不断变化的数据和意料之外的工具响应。

这些情况会产生重试，也会暴露 agent 是否拥有可靠的停止规则，还是仅仅持续生成看似合理的下一步。

人类采用率依然重要，但它已无法单独预测推理需求。更有用的公式包括用户数、委派任务数、每项任务的模型调用次数以及每次调用的 token 数。

这一公式在原则上使十倍比例变得可信，但并不意味着 Newman 的预测必然实现。该比例还将取决于优化、模型行为、应用设计以及 OpenRouter 之外的流量。

缓存提示词解释了大部分 token 激增

Agent 领先优势中最大的一部分似乎来自重复上下文，而非全新的推理或输出。

据称，a16z 演示材料中超过 85% 的 agent token 来自缓存提示词。缓存提示词是先前处理过的输入片段，当后续请求以匹配内容开头时，提供商可以复用这些片段。

Agent 经常重新发送稳定材料，其中可能包括系统指令、工具描述、项目文件、政策和早期对话历史。

若每次调用都从头处理相同前缀，将会浪费计算资源。提示词缓存让提供商能够复用与该前缀相关的中间结果。

OpenRouter 的缓存遥测数据将缓存 token 与新处理的提示词 token 分开统计，也可以识别为日后复用而写入缓存的 token。

这意味着，不应将 7.3 万亿 token 解读为 7.3 万亿单位的全新模型工作。其中很大一部分代表系统此前已经接触过的信息。

这一区别会影响成本。与处理新输入相比，提供商通常会对缓存读取收取更低费用，因为前期的大部分计算已经完成。

不过，已缓存并不代表免费。系统仍必须识别缓存条目、检索其数据，并在推理过程中提供相关的模型状态。

相关模型状态通常被称为键值缓存（key-value cache，或 KV cache）。它存储由早期 token 推导出的注意力信息，使模型能够延续处理，而无需重新计算此前的每个位置。

更长的提示词会生成更大的 KV 缓存。并发运行的 agent 会话越多，这类缓存也越多。长生命周期的工作流还可能需要反复访问大量已存储的上下文。

这改变了基础设施的瓶颈。算力依然重要，但内存容量、内存带宽和数据搬运正变得愈发关键。

这也是为什么缓存占比较高并不意味着 OpenRouter 数据失去意义。它改变的是这些数据所表达的含义。

这张图表作为新推理需求的证据较弱，但作为证据表明 agent 系统会在多次模型调用中反复携带大量历史信息，则更有说服力。

这种差异类似于反复查阅同一本厚重的项目资料夹。再次阅读熟悉的页面所需准备较少，但这份资料夹仍必须随时可用。

缓存还可能让低效的 agent 设计在财务上看起来尚可接受。某个工作流或许会反复发送极长的系统提示词，因为折扣后的缓存读取掩盖了一部分成本。

但这种设计仍会消耗容量。它可能增加延迟、使路由更复杂，并造成对稳定提示词前缀的依赖。

并非每种配置都能保证缓存命中。修改提示词的前半部分，可能会让后续的缓存内容失效。在不同提供商之间路由请求，也会影响缓存复用。

动态数据带来了另一项挑战。如果时间戳、检索到的文档、工具结果或用户特定信息出现在开头附近，提示词前缀的稳定性就会下降。

因此，agent 开发者需要有意识地设计上下文结构。稳定的指令应放在开头；在提供商行为允许的情况下，变化的信息应置于可复用部分之后。

会话亲和性同样重要。持续关联至兼容提供商的请求，比不可预测地路由的请求更可能复用先前上下文。

85% 这一数字也值得谨慎归因。据源报道，它出现在 a16z 对 OpenRouter 数据的表述中。还有说法称，OpenRouter 的原始分析采用另一种计算方法时，显示的占比更低。

不同的分母会得出不同的百分比。一种方法可能汇总全部 token 量，另一种则可能计算各请求缓存占比的平均值。

少数规模极大的工作流可以主导总量，却未必代表典型请求。反过来，按请求计算的平均百分比也可能低估最大工作负载的影响。

两种测量都可能准确，只是回答了不同的问题。公开图表没有提供足够的方法细节，无法独立调和所有报告中的缓存比例。

因此，最稳妥的结论是方向性的：缓存上下文构成 agent token 流量的明显多数，但精确占比取决于平台如何聚合请求。

这也挑战了“AI 正在使用 AI”这一说法。这些 agent 未必在进行数万亿次独立的推理行为。它们的大部分流量，都涉及恢复继续完成委派工作所需的上下文。

这种行为依然可以创造真实价值。编码 agent 需要代码库状态和先前决策，才能避免每次工具调用后都从零开始。

效率问题在于取舍：agent 是重新加载最小且有用的上下文，还是因为更容易实现而反复发送全部内容？

随着 token 量上升，这种差异将成为重要的工程选择。高效的上下文管理能够在不削弱任务表现的前提下，降低内存需求。

Token 量增加五倍，并不意味着 ROI 增加五倍

Token 量衡量的是使用程度，而投资回报取决于成功结果与总运营成本。

Newman 认为，企业在评估 AI 回报时过度关注人类用户采用情况。他更广泛的观点有其道理，因为单个用户如今能够发起的推理量，远超基于聊天的采用指标所揭示的规模。

月活跃用户数可能低估基础设施需求。席位数量同样可能遗漏那些在员工离开办公桌后仍持续运行的自动化工作。

然而，用 token 数取代用户数又会形成另一种不完整的衡量。Token 反映活动量，却不能说明这些活动是否创造收入、减少人力、提升质量或增加风险。

五倍这一比率比较的也是两类流量，而非两个经济主体。Agent 请求仍然源自人类或组织的决策。

企业不会因为 agent 消耗了更多 token 就获得回报。只有当 agent 以可接受的成本和风险水平完成有价值的工作时，企业才会获得回报。

有用的评估应从任务成功开始。团队应询问，工作流是否完成了预定操作，以及人类是否接受了结果。

下一个问题是人工干预。无需监督即可完成任务的 agent，与需要反复纠正的 agent，有着不同的运营特征。

延迟同样重要。即使工作流最终成功，如果客户等待过久，或基础设施队列在高峰负载下不断增长，它依然可能在商业层面失败。

接下来是总成本。Token 费用只是一个组成部分。工具调用、搜索服务、数据库、沙箱、可观测性、安全审查和人工补救，都可能带来可观开支。

经风险调整后的结果同样重要。修改生产系统的 agent，需要比总结公开文档的 agent 更强的控制措施。

OpenRouter 图表无法回答其中任何一个问题。它旨在描述流量，而非企业回报。

同样的限制也适用于 Newman 对十倍的预测。该推断假设 agent 流量将继续以快于人类流量的速度增长，且没有相应的效率修正。

这一假设可能因多种原因而失效。应用可以压缩上下文，针对常规步骤使用更小的模型，用确定性软件替代重复推理，并更早地终止循环。

模型改进可以减少重试。更好的工具界面也能返回更干净的信息，从而减少完成任务所需的调用次数。

经济压力将推动这些变化。即便缓存读取相对便宜，企业也有动力移除那些无法改善结果的调用。

a16z 对循环收敛的讨论凸显了同一问题：在大部分可获得价值已经出现后，agent 仍可能继续产生额外工作。

缺少外部完成测试的循环，可能把持续活动误认为进展。它可能反复编辑一份文档、重新运行失败的命令，或不断润色已经足够合格的答案。

当每次单独调用看上去都合理时，这种行为尤其难以发现。浪费会在完整轨迹中浮现，而不是显现于某一次响应之内。

因此，可观测性必须在任务层面运作。开发者需要追踪信息，将每次模型调用与工具使用、状态变化、错误和最终结果关联起来。

预算也应反映任务价值。高风险调查可以比常规格式化请求更有理由进行更多轮迭代。

升级规则构成了另一道边界。当 agent 遭遇重复失败或权限不确定时，将控制权交给人类可能更便宜，也更安全。

OpenRouter 的流量还存在选择效应。该平台服务于有意识地使用模型网关的开发者，因此其工作负载构成可能比消费者应用更具技术性。

因此，编程和 agent 框架在 OpenRouter 中的占比，可能高于它们在整个 AI 市场中的占比。

OpenRouter 的规模仍使这一趋势值得重视。其数据覆盖了多个模型和提供商的大量真实世界流量。只是这些结果应始终限定在这一范围内理解。

该平台的关系还带来另一项考量。Andreessen Horowitz 已投资 OpenRouter，这使 a16z 对 token 路由基础设施的增长抱有利益关联。

这并不会使这些数字失效。但当数据被用于支持有关 AI 经济的广泛主张时，透明的方法论和独立复核就更为重要。

最有力的解读应避免两个极端。这张图既不是自主机器已成为 AI 主要客户的证明，也不是缓存造成的空洞假象。

它证明了 agent 架构会放大推理需求。它也表明，这种放大目前在很大程度上依赖于传输和检索既有上下文。

对买家而言，核心问题不是 agent 是否使用了大量 token，而是每增加一轮，是否都会提高获得成功且有价值结果的概率。

内存提供商与 Agent 平台正面临迫在眉睫的压力

流量转变会奖励高效管理上下文的系统，并给那些把 token 消耗当作进展代理指标的产品施加压力。

模型提供商面对的工作负载比普通的请求—响应式聊天更复杂。Agent 会话可能保持活跃更长时间，反复调用工具，并维护不断增长的历史记录。

这种工作负载给调度器和路由系统带来压力。提供商必须在不断变化的需求中，平衡缓存局部性、模型可用性、延迟和可靠性。

OpenRouter 等网关平台获得了战略重要性，因为应用越来越多地使用多个模型。一个工作流可以将规划、编码、验证和摘要路由到不同端点。

动态路由可以降低成本或提升性能，但也可能干扰缓存。发送至不同提供商的请求，可能失去对先前已建立缓存的访问权限。

能够提供清晰缓存指标的提供商，将在成熟买家中占据优势。团队需要了解多少 token 是新增、缓存、生成，或写入存储的。

内存制造商同样面临来自更长上下文和更多并发会话的需求。高带宽内存为模型加速器供给数据，而传统内存和存储则支撑周边系统。

不过，这张图并未量化未来的内存采购。它展示的是 token 流量，而不是每个 token 与新增硬件容量之间的精确映射。

硬件需求取决于模型架构、数据类型、批处理、缓存淘汰、压缩方式以及同时运行的会话数量。软件改进可以改变其中每一种关系。

Agent 平台则面临来自另一个方向的压力。客户将越来越多地比较每个 token 所产生的有效工作，而不只是能否接入强大的模型。

当企业财务团队要求按任务核算经济性时，隐藏在宽泛使用声明背后的产品可能会陷入困境。买家将希望在自身工作负载中看到可重复验证的证据。

编码 agent 提供了一个早期测试案例，因为其输出可以通过构建、测试、审查和部署结果来评估。这些信号创造了可衡量的停止条件。

其他领域仍然更难。研究、战略和写作往往缺少单一的客观测试。Agent 可以持续打磨输出，却没有明确的完成时刻。

这种不确定性使人工审查更加重要，即便 agent 完成了大部分中间工作。它也让不同供应商之间的 token 效率更难比较。

基础设施供应商可以通过上下文压缩、前缀缓存、有状态会话和检索系统来应对。每种方法都试图避免重新发送不必要的历史信息。

应用开发者可以将持久记忆与工作上下文分离。持久记忆存储可能有用的信息，而工作上下文仅包含当前步骤所需的内容。

这种分离减少了重复文本，并限制了无关信息。通过将干扰因素排除在活跃提示词之外，它还可以提高模型准确性。

确定性软件应承担确定性工作。当可靠代码可以直接完成计算、模式验证或访问检查时，智能体无需为此进行推理。

最高效的系统很可能会将模型与传统软件结合。模型负责处理模糊性和规划，代码则负责执行规则和稳定操作。

这种混合设计削弱了“智能体流量必须无限增长”这一假设。更好的系统能够完成更多任务，同时降低每项任务的 token 消耗。

与此同时，单位成本下降也可能推高总体需求。当每个工作流变得更便宜，开发者便能在更多场景部署智能体，并更频繁地运行它们。

由此产生的反弹效应，即使单项任务变得更高效，仍可能维持基础设施增长。这一可能性支持了 Newman 预测的方向，但并不支持其精确比例。

人类流量同样可能增长。更好的消费级产品、新型界面以及更广泛的企业采用，都可能在智能体流量之外提升直接使用量。

未来的比例取决于哪条曲线增长更快。它并不只是智能体不断改进的函数。

OpenAI、Anthropic、Google、开放权重模型开发者和专业推理服务商之间的竞争，将塑造这条曲线。它们的缓存规则和工具能力各不相同。

模型选择也可能在工作流中发生变化。小型模型可能先对请求进行分类，而较大型模型则处理复杂决策。

这种架构降低了单一汇总 token 计数的重要性。由紧凑模型处理的 token，与由前沿模型处理的 token，具有不同的资源特征。

企业将需要结合模型选择、token 类型、延迟、能耗和任务成功率的标准化衡量指标。目前尚无被广泛接受的标准能够完整反映全貌。

在这样的标准出现之前，OpenRouter 的智能体 token 使用量仍是有用的领先指标。它能在财务报告解释其价值之前，揭示需求的形态。

三个信号将检验 10 倍预测

下一阶段应根据分类稳定性、新增 token 增长，以及每单位推理所完成的工作量来评判。

第一个信号是，OpenRouter 的智能体与人类流量比率是否会在 8 月之后继续上升。持续增长将支持这样一种观点：自主工作流的扩张速度快于直接交互。

比较应采用相同的分类方法和测量窗口。方法变更可能造成表面增长，而行为本身并未发生相应变化。

混合流量值得特别关注。如果它的增长速度快于两类流量，人类与智能体使用之间的边界将变得不那么可靠。

第二个信号是智能体 token 的构成。缓存占比上升将表明，上下文重复而非新增模型处理，仍是主要的增长引擎。

如果缓存占比下降，同时总量上升，则说明情况不同。这将意味着智能体正在执行更多新的推理，而非主要重放既有上下文。

公开报告应区分新增输入、缓存读取、缓存写入、推理 token 和输出。将它们合并为一个数字，会掩盖成本和基础设施需求方面的重要差异。

第三个信号是任务效率。智能体供应商和企业用户应报告每次模型调用完成的工作量、每项成功任务的 token 数，以及每次完成任务所需的人工干预次数。

如果这些指标改善，同时智能体总流量上升，增长逻辑就会更有说服力。这表明采用规模和成功自动化正在同步扩大。

如果 token 使用量上升而成功率保持不变，那么这张图表将越来越多地反映运营浪费。更高的比率届时将削弱，而非强化 ROI 论点。

独立数据集也将提升可信度。来自直接模型 API、云平台和私有部署的流量，可以显示 OpenRouter 是否反映了更广泛的市场。

目前，证据支持的结论比这一病毒式传播的说法更为有限：在 2026 年 8 月，智能体产生的 token 流量超过了 OpenRouter 所观察到的人类流量的五倍。

这些流量中的大部分似乎涉及缓存上下文。这类上下文仍然需要内存、路由和谨慎管理，但不应将其与等量的新推理混为一谈。

向 10 倍迈进是一项预测，而非既定结果。其重要性将取决于新增 token 实现了什么。

开发者应检查每个循环是否具有明确目的、预算和停止条件。企业采购方应在将消耗量视为采用情况之前，要求提供任务层面的证据。

有用的问题已不再是智能体是否会产生比人类更多的流量。OpenRouter 的数据表明，它们已经如此。问题在于，下一万亿个 token 会完成更多工作，还是只会更多地重读过去。