夜雨聆风你以为你在指挥AI写代码实际上，你按下回车的那一刻，只不过是点燃了一根引信。
接下来发生的事，跟你没什么关系了
2026年7月底，伊利诺伊大学香槟分校（UIUC）与微软Azure Research联合挂出一篇论文，标题朴素得像实验室日志：《Agentic Coding in the Wild》。但里头的数据，足以让整个AI基础设施行业集体失眠，320万用户，1350万次会话，7.61亿次大模型调用，95万亿个token。这是人类第一次在生产环境规模上，完整看清编码智能体在GPU上究竟干了什么。
答案令人不安：模型大部分时间，在跟自己说话。
▲ arXiv论文摘要页，数据规模一目了然：3.2M用户 / 761M次LLM调用 / 95T tokens
87%：那个安静的循环
这个数字是整篇论文最尖锐的发现，在所有大模型调用中，只有约13%是用户亲手触发的。剩下的87%，全部由智能体自主决定发起。
什么意思？你在VS Code里写一句"帮我修这个失败的测试"，Copilot agent接手后，开始读文件、搜符号、改代码、跑构建、读报错、再改代码……中间没有你再点一次发送。平均每个用户指令之后，智能体还会自己续跑6.6次LLM调用；中位数约4.5次，长尾可到几十次
用一位推特网友的话说：
"87% of calls come from the agent, not the user. The model is just talking to itself until it gets tired. Introvert."
▲ 网友调侃：模型在跟自己说话，说累了就停，"内向型人格"
这句调侃背后是生产轨迹刻画数据窗口是2026年6月的一个完整工作周，来自GitHub Copilot的coding agent模式。
人类在这个系统里充当稀疏的"下一回合指令源"，偶尔敲下指令，然后等着机器自己把事情做完。容量规划如果还按"用户请求到达率"估算GPU需求，会系统性低估轮内突发，高估人的节奏。
68000个token的独白
单看一次LLM调用的体格，更能感受这台机器的饥渴程度：
- Prompt中位数：约68,000 tokens
- 其中可缓存前缀：约63,000 tokens
- 模型输出中位数：仅247 tokens
输入与输出之比：275:1
你没看错模型每次被唤醒时，要重读六万多个token的上下文，自己之前做过什么、工具吐回了什么结果、系统提示词、仓库指令，然后只说出短短两百来个字。
这就像一个人每回答一个问题之前，都要把整本会议纪要从头到尾读一遍，然后说一句"好的，下一步我来跑测试"。
瓶颈从"生成吞吐"翻转成了"缓存能不能命中"。
▲ 论文§5.2详细刻画了KV缓存命中率随调用次数的变化曲线
飞轮与断崖：缓存经济学的残酷真相
这是论文中最受关注的技术故事线，也是让基础设施工程师心跳加速的部分。
轮内是飞轮，
智能体连续工作时，缓存越转越热第一次调用命中率约45%（冷启动），第二次跳到86%，第三次起稳定在92%–94%。道理很简单：每一步只在旧前缀后面追加一点新的工具输出，绝大部分上下文是重复的。
轮边界是断崖，
用户拿到结果后，会停下来想一想、读一读、改改需求。这段"人在思考"的空闲，中位数约2.9分钟。就这几分钟，缓存命中率平均暴跌26个百分点，落到约55%。如果超过10分钟没有下一步操作，命中率中位数直接归零。
模型切换是核弹，
约6.4%的会话中途切换了底层模型切换后，命中率只剩约8%，掉了67个百分点。不同模型的权重和注意力布局无法复用同一份KV缓存。这等于把飞轮一锤子砸碎，从头再来
▲ "按次把流量路由到更便宜的模型，可能毁掉的缓存价值比省下的钱更多"
▲ "轮次级批处理能抓住第三次调用后的90%命中红利；请求级策略白白浪费它"
这两条评论精准地指向了一个工程矛盾：省钱的直觉（切便宜模型）和物理现实（缓存连续性）在打架。
9%的噩梦：失败如何把账单放大4倍
论文把turn按行为模式分成了六类。其中资源消耗最突出的一类叫"Deep-loop with failures"，占比约9%，听起来不多。
但这9%的turn，每个平均触发36次LLM调用，而全局中位数只有4.5次。失败驱动的重试循环，把单个turn的算力消耗放大到正常情况的约4倍。
循环由此形成：工具报错了，错误日志被塞进上下文，模型看到错误，决定换一种方式再试，再失败，再塞进去，再推理……聊天场景里一次失败就是一个错误码返回给用户；智能体场景里，失败是"继续烧token的理由"。
提高工具成功率，有时候比抠解码kernel更能省钱。 这是论文隐含的、但工程上最可执行的建议之一。
重尾的恐怖：中位4分钟，平均63分钟
数字的离散度同样触目惊心
中位会话：3个用户turn、15次LLM调用、4.2分钟结束，像一次快速问答。
但均值呢？6.1个turn、40.6次调用、62.6分钟。时长的均值/中位数比达到14.9倍P90会话可超过100次LLM调用，接近三小时。
少数巨型会话像黑洞一样吞噬服务资源，而简单会话来去如风。如果你用统一策略管理它们，统一超时、统一LRU驱逐、统一容器回收，等于对最重的用户反复征税，对最轻的用户过度保留状态。
▲ 论文Table 1：关键发现一览，覆盖87%、缓存曲线、空闲双峰、失败放大等核心数字
五种用户，五十倍差距
论文把320万用户聚类为五种画像：
Readers（41.7%），主要在读代码，每轮约20万token，会话短，状态轻。
Coders（30.4%），读改跑齐全，每轮约42万token，是"典型开发者"。
Terminal Users（11.0%），重度终端控，命令时延从瞬间到分钟级构建，空闲极难预测。
Deep-loop Users（9.2%），每轮约110万token，单turn极重，像深夜不睡觉的炼丹术士。
Chat-only（7.6%），从不调工具，每轮仅约2.3万token，最接近传统对话。
一次缓存未命中的代价，Deep-loop和Chat-only之间可差约50倍。统一的缓存策略会形成一种隐性的、对重度用户不公平的定价。
空闲是双峰的：秒级心跳，分钟级沉默
资源管理者面前有两种截然不同的空闲：
轮内，智能体在等工具返回结果，KV缓存空闲中位仅1.2秒，容器空闲约5.8秒。这是心跳间隙，回收它代价极高
跨轮，人在思考或去泡咖啡，KV缓存空闲中位约172秒（近3分钟），容器空闲约243秒（超4分钟）。长尾延伸到次日再回来
轮内去睡容器、丢缓存，得不偿失；跨turn才是回收的窗口 论文团队甚至训练了一个仅2MB的LightGBM预测器，在turn结束时判断"还会闲多久"，可捕获约86%–90%的总空闲时间。边界处推理延迟不到3毫秒
这让人想起云计算领域的经典故事：Azure serverless的生产刻画曾经把"以为的负载"纠正为"双峰的真实负载"，直接驱动了冷启动优化。编码智能体正在走同一条路，先测量，再谈调度。
更大的图景：补全时代结束了
▲ "微软刚扔出一篇分析了95万亿token的论文……第一次有人展示了生产规模的agent编码到底长什么样"
GitHub Copilot最早以行内补全进入大众视野，灰字提示，按Tab接受，状态弱，失败成本低。那是补全系统的故事
而现在，同一个品牌名下的产品，服务形态已经换代。一次用户意图可以跨文件、跨命令、跨数十分钟。论文把对照写得很明白：调用次数从1到中位15，状态从可丢弃到强顺序依赖，失败从手动重试到自动重试环。
基础设施若仍按2021–2023的补全假设扩容，就会系统性误判。 vLLM、SGLang这些为聊天场景打造的serving引擎，请求独立、生命周期短、状态按请求丢弃，面对编码智能体时，假设已经碎了一地。
社区讨论迅速把87%外推到了Cursor、Claude Code、Codex等全品类。论文数据只覆盖GitHub Copilot。用户稀疏发起、智能体密集续跑、缓存按工作流生命周期起伏，这些结构假说大概率可迁移。具体百分比仍应用各家的生产遥测校准。
▲ 可视化解读站标题直接写明："Mostly, the agent is talking to itself."
尾声：谁在为沉默买单
这篇论文更深层的洞察，是对一个范式转移的确认：当AI开始自己跟自己说话时，人类建造的整套服务架构，从调度粒度到缓存生命周期到账单归因，都要随之重新设计。
你按下回车后的那87%，静悄悄地发生在数据中心的某个角落。界面上看不见进度条或转圈动画，token已在GPU的显存里翻涌，读、改、跑、错、再读、再改。
模型在跟自己对话而你为这场独白，付了全部的账
