夜雨聆风你按下回车键那一刻，以为AI在帮你写代码。但真相是，它根本没在理你，它在跟自己对话。
2026年7月底，一篇来自伊利诺伊大学香槟分校（UIUC）与微软Azure Research的论文悄悄挂上arXiv，编号2608.00101。论文标题读起来平淡无奇，里面的数字却相当醒目：1350万次编码会话、320万用户、7.6亿次大模型调用、95万亿tokens，全部来自GitHub Copilot编码智能体在2026年6月仅仅一周的生产数据。
这是迄今为止，人类公开可见的最大规模编码智能体负载画像。它揭示的核心事实集中在一点：
你以为的"AI助手"，其实是一台自动运转的token焚化炉。
▲ arXiv论文摘要页：320万用户，1350万会话，95万亿tokens，仅一周数据
87%：一个让整个推理基础设施行业失眠的数字
先看结论
在GitHub Copilot的编码智能体模式下，约87%的大模型调用由智能体主动触发，用户直接触发的只占约13%。用户敲一句"帮我重构这个函数"，智能体平均会自主再跑6.6次LLM调用，读文件、搜符号、改代码、跑构建、看报错、再推理，直到它认为任务完成，才把控制权还给你。
用一位X网友的话说：
"智能体发起了87%的调用。模型就像在跟自己说话，直到它累了为止。内向者。"
▲ 社区调侃：模型在跟自己对话直到累了，"introvert"
调侃背后是一条结构性的系统事实：你每按一次回车，背后平均会触发将近7次推理。而现有的推理服务架构，vLLM、SGLang这些被整个行业倚仗的系统，全部是按"一次请求"来调度的。
换句话说，我们用聊天机器人时代的基建，在跑一个完全不同物种的负载。
一周95万亿tokens：这台机器的胃口到底有多大
论文给出的全景数字值得逐一品味：
- 会话数
：约1350万 - 用户轮次
：约9510万 - LLM调用
：约7.605亿次 - 工具调用
：约7.747亿次 - Token总量
：约95万亿（其中prompt约44.9万亿，completion仅约393亿）
注意最后一组数据的极端不对称：输入是输出的1000倍以上。单次LLM调用的中位prompt约6.8万tokens，而输出中位数仅247个tokens。模型大部分时间都在"重读自己做过的事"，对话历史占prompt的48%，工具结果占28%，实际生成只占很小一部分。
服务瓶颈随之落在缓存命中率上，生成速度退居其次。
▲ 基础设施工程师Romir Jain发起的分析线程：现有LLM服务架构"建错了"
KV缓存的生死线：2分钟之后，一切归零
如果你做过任何推理优化工作，下面这组数据会让你冷汗直冒。
论文精确测量了KV缓存（大模型推理的"短时记忆"）在不同场景下的命中率：
轮内（智能体自主循环中）：
第1次调用：约45%（冷启动） 第2次：跳到86% 第3次起：稳定在92–94%
这很美好问题是，
跨轮（用户思考间隙之后）：
空闲<2分钟：命中率仍可≥95% 2–10分钟：中位掉到70%，下尾可到0% >10分钟：中位接近零
而用户两次输入之间的中位空闲是多少？25.2分钟
也就是说，你出去倒杯咖啡回来，AI之前辛辛苦苦积累的全部"记忆"，那些6.8万token的KV张量，大概率已经被服务端当垃圾回收了。下一轮开始，一切要从头算起你的账单上，很大一部分是为被丢掉的记忆重新付费。
模型切换的损耗更大约6.4%的会话发生了模型切换（多因限流或报错），切换后缓存命中率直接崩到约8%。论文指出：不同模型的注意力布局无法复用KV。
有评论一针见血：
"按次模型路由省下的钱，可能远小于毁掉的缓存价值。"
▲ 社区指出：换更便宜的模型省下的推理费，可能还不够补上缓存重建的开销
9%的失败轮次，吃掉了不成比例的算力
接下来是论文中最具"运维恐怖感"的发现。
约9%的用户轮次遭遇了工具调用失败，构建报错、终端超时、文件不存在。在传统聊天场景，失败就是返回一条错误消息。但在智能体里，失败会触发自主恢复循环。
失败驱动轮的中位LLM调用次数：36次。对比正常轮次的中位数4.5次，算力放大约4倍。而P95极端情况？48倍
▲ 一次工具调用失败，可以把30秒的轮次变成"多分钟token焚化炉"
这里存在双重惩罚机制：失败的构建不仅更慢，还会把大量编译器日志灌入上下文，让后续每一次LLM调用的prefill都更贵。墙钟变长的同时，每步token也在膨胀。
论文把工具可靠性的定位从"开发体验问题"升格为"服务效率问题"，在分布式系统的语境里，这就是经典的"重试风暴"，只不过现在是AI在自动化地制造它。
50倍鸿沟：五类用户的负载差异
论文按使用模式将320万用户聚类成五种画像：
| Readers | |||
| Coders | |||
| Terminal Users | |||
| Deep-loop Users | |||
| Chat-only |
Deep-loop用户与Chat-only用户之间的每轮token差距：约50倍。
用统一的资源分配策略服务所有人，会同时在两个方向犯错，轻用户被过度分配浪费钱，重用户被不足分配伤害体验。
▲ 五类用户，50倍token差距：统一SLO是一种结构性的资源错配
整个行业都建错了？
论文用一张对照表把"聊天/补全"与"编码智能体"切开：
| 极高 | ||
这张表的潜台词是：vLLM、SGLang等现有服务栈的每一个默认假设，都被智能体负载反转了。
短轮次？不，中位会话15次LLM调用用户驱动节奏？不，87%是自动续写无状态请求流？不，紧致的串行依赖链LRU缓存即可？不，轮边界和模型切换会结构性地摧毁缓存。
▲ 社区将同一结构推广到Cursor、Claude Code、Codex、Devin等，所有编码智能体共享这套负载形态
Prasenjit Sarkar在一条引用推文中写道："下一家认真的推理基础设施公司，将围绕这种工作负载重新构建基础设施。"
86–90%的空闲可以预测：套利窗口就在轮边界
论文最后给出了一个"解药"方向：一个轻量的空闲时间预测器（据社区解读约2MB的LightGBM模型，推理<3ms），能捕获86–90%的总空闲时间。
核心洞察是：轮内，缓存应高优先级驻留（下一跳中位仅1.2秒）；轮边界，可降级卸载（中位空闲172秒）。这个信号，轮次是否结束，是整个系统里最强、最便宜、最被忽视的调度信号。
对于只有API层控制权的工程师，论文的实操外推更朴素：在提供商缓存TTL（通常300秒量级）到期之前，发一个廉价的keep-alive请求，就能避免整段recompute。你的费用很大一部分花在了重建被丢掉的记忆上。
尾声：当AI开始自己跟自己说话
回到最初的那个画面：你按下回车，Copilot开始工作。屏幕上看到的是一行行代码在生成但屏幕背后，
一台机器正在与自己进行一场每轮6.6个回合的对话，读着自己写过的历史，调用着自己触发的工具，有时撞墙失败、有时疯狂重试、有时在你上厕所的时候把辛苦积累的记忆全部丢光，然后从零开始重来。
这正是编码智能体的本质结构
而我们为此付出的代价，以算力、以账单、以等待时间的形式，正在被第一次精确地测量出来。95万亿tokens，一周这个数字还在增长
问题随之落到基础设施上：谁来为这个新物种建造配得上它的系统？