夜雨聆风你以为你在用AI写代码实际上，你只是按了一下回车，然后AI开始了一场漫长的独角戏。
这组数据来自微软与UIUC对320万用户生产轨迹的研究。
▲ arXiv论文摘要页：320万用户、1350万会话、95万亿token，这是迄今为止对AI编码智能体最大规模的生产级解剖
一篇论文，撕开了"AI编程"的底裤
2026年7月末，伊利诺伊大学香槟分校（UIUC）与微软Azure Research的研究团队，在arXiv上静悄悄挂出一篇论文。标题很学术：《Agentic Coding in the Wild》。数据量惊人：他们拿到了GitHub Copilot编码智能体一整周的生产轨迹，约320万用户、1350万次会话、7.61亿次大模型调用、7.75亿次工具调用、总计95万亿token。
数据直接来自生产环境，记录着数百万程序员每天打开VS Code干活时，GPU集群正在经历的事。
而这份数据讲述的核心故事可以概括为：
你以为的"人机协作"，其实是机器在跟自己对话，直到累了为止。
▲ 有人在X上精准吐槽："87%的调用来自智能体自己，模型就是在跟自己说话，直到它累了。内向型人格。"
87%：那个让所有人沉默的数字
论文最核心的发现是这样的，
在约1350万次采样会话里，大约87%的大模型调用由智能体在一轮自治循环里自行发起，无需用户再次按下发送键。
具体来说：用户发一条指令（比如"帮我修这个失败的测试"），Copilot agent随后平均会自主发起6.6次额外的LLM调用，读文件、搜符号、改代码、跑构建、读报错、再改。中间没有人的任何操作人，在这个循环里，只是一个稀疏的指令源。
当你盯着屏幕等结果时，GPU集群正在以你完全不知道的密度和节奏疯狂运转。你设下导航目的地之后，车已经自己上路了。
▲ 论文Table 1：关键发现一览，87%智能体发起、缓存命中从92%跌到55%再到8%、失败turn算力放大4倍
一次缓存未命中，代价是什么？
如果87%只是让人惊讶，那KV缓存的故事就是让工程师心疼钱的。
先解释一下：Transformer模型在生成时会把已算过的注意力键值存下来（KV cache），这样下一步就不用重算整个前缀。前缀越长、复用越多，省的钱越多编码智能体的prompt中位数是68000个token，是普通聊天的几十倍，所以缓存命中与否，直接决定了一次调用是花一毛钱还是花一块钱。
论文画出了一条让人窒息的曲线：
- 轮内第1次调用
：缓存命中约45%（冷启动） - 第2次
：跳到86% - 第3次起
：稳定在92-94%，飞轮转起来了
这是好消息坏消息是，
一旦跨越"轮"的边界（用户读完结果、想一想、再发下一句），命中率断崖式下跌到55%。空闲超过10分钟？命中率几乎归零
更惨的情况是模型切换：约6.4%的会话发生了底层模型变更（限流、降级、用户手动换），切换之后缓存命中率只剩约8%。你精心攒起来的KV缓存，一次切换全部作废。
▲ 论文§5.2：前缀缓存命中率随调用序号上升的曲线，轮内像飞轮，轮边界像断崖
有评论者一针见血：
▲ "按次路由到更便宜的模型，抹掉的缓存价值可能比省下的钱还多"，工程偏好背后是一笔经济账
失败是最贵的燃料
如果缓存未命中是"慢性出血"，那工具失败就是"急性大出血"。
论文发现：约9%的turn会撞上工具执行失败（编译报错、命令超时、权限问题）。听起来不多？看看后果，
失败驱动的turn，平均触发36次LLM调用。而正常turn的中位数只有4.5次。
算力放大约4倍
为什么？因为智能体不会像人一样看到报错就去喝杯咖啡冷静一下。它会立刻重试，读错误日志、改策略、再试、再失败、再读，错误日志不断堆进上下文，prompt越来越长，缓存越来越难命中，每一次重试都比上一次更贵。
这就是为什么有人说：在智能体时代，一个不稳定的工具链，比一个慢模型更烧钱。
双峰空闲：基础设施的噩梦
论文还揭示了一个对云厂商至关重要的发现：空闲时间是双峰分布的。
| 5.8秒 | 243秒（4分钟） | |
| 1.2秒 | 172秒（近3分钟） |
翻译成人话：智能体在一轮循环内几乎不休息（秒级），但在等待用户下一轮指令时会闲好几分钟。超过九成空闲片段是轮内的、短的；跨turn的片段占比小，但长两个数量级。
由此看，轮内回收资源容易亏，跨轮才是回收的窗口。但如果回收太早，用户30秒后回来又得冷启动；回收太晚，GPU白白空转
研究者的解法是训练了一个2MB大小的LightGBM预测器，在每个turn结束时预判"还会闲多久"。结果：能覆盖约86-90%的总空闲时间。模型比人的直觉靠谱
▲ 中文技术圈的解读："别再按聊天负载调优LLM serving了，agentic coding的负载形态完全不同"
五种用户，五十倍差距
论文把用户分成五类，差距触目惊心：
Deep-loop用户（约9.2%），每轮约20次工具调用、110万token；是那种丢一个大需求让agent跑一小时的重度使用者。
Chat-only用户（约7.6%），从不调工具，每轮仅2.3万token；接近传统聊天
一次缓存未命中再重算的代价，两者之间差约50倍。
如果你用统一的LRU策略、统一的超时时间来管所有人，恭喜，你正在对最重的用户反复征税，对最轻的用户过度保留资源。一刀切是最贵的策略
为什么现有架构"建错了"
▲ Developers Digest文章标题直接写明：1350万Copilot会话揭示了AI编码智能体的真实工作负载
过去几年，工业界服务大模型的主流栈，vLLM、SGLang一类系统，假设的是：请求独立、生命周期短、状态可丢弃。这在聊天场景没问题
但编码智能体把一切都改了：
请求不独立，后一步严格依赖前一步的工具输出 生命周期不短，中位会话4.2分钟，均值62.6分钟，时长偏斜达14.9倍 状态不可丢弃，丢了就要重新prefill数万token的上下文
论文团队措辞审慎，结论却很明确：vLLM那套"短命无状态"假设，在agent场景里不成立。 调度的基本单元应从一次HTTP请求扩展到一个"轮次"甚至一整个"会话"。
▲ 中文社区回应："agent编码场景完全不一样，KV缓存命中率掉太多，原有调度思路根本不适用"
更大的图景：一个时代的基础设施换代
这篇论文恰好落在一个更大趋势的结晶点，
2025到2026年，编码智能体从"行内灰字补全"进化成了"能跨文件、跨命令、跨数十分钟自主迭代的自治系统"。GitHub Copilot agent、Claude Code、Cursor agent、Codex CLI……同一品牌名下的产品，服务形态已经换代了。但支撑它们的推理基础设施，很多还在按2022年的聊天假设扩容。
这就像高速公路按自行车流量设计，突然涌进来的全是重卡。
社区里已经有人喊出"下一代推理基础设施公司"的判断。CacheTTL、Autellix、SAGA等新系统正在尝试把缓存存活、会话调度、工作流感知写进服务栈。但在此之前，
先得有人告诉他们，真实的路上跑的到底是什么车。
这篇论文，就是那张交通航拍图
▲ 可视化解读博客的标题句："大部分时候，智能体只是在跟自己说话。"
写在最后：你的下一美元花在哪了
对普通开发者而言，这些数字意味着一条简单的省钱法则：把相关改动放在同一模型、同一会话、尽量连续的时间窗里。 别频繁切模型，别让会话闲太久再回来，别让不稳定的工具链触发无限重试。
对平台而言，启示更深：提高工具成功率和减少无谓模型切换，有时比再抠一个解码kernel更能省钱。
95万亿token像一面镜子，照出了AI编程的真实面貌：人类早已坐在后排。引擎在轰鸣，方向盘在自转，而你唯一做的事情，就是说了句"出发"。
