你敲下回车之后,大量工作才刚刚开始。
反复读文件、调工具、重试、再推理,机器开始自己跟自己说话。这组判断来自微软刚刚统计的7.61亿次大模型调用和95万亿个token。
2026年7月30日,伊利诺伊大学香槟分校(UIUC)与微软Azure Research联合在arXiv投下一篇重磅论文。他们把GitHub Copilot编码智能体在2026年6月第一周的生产数据摊开在阳光下:320万用户、1350万次会话、7.6亿次LLM调用。这是人类历史上第一次有人公开如此规模的AI编程助手生产轨迹。

▲ arXiv论文页:标题、作者与核心数据一览,3.2M用户/13M会话/761M LLM调用/95T tokens
而论文得出的第一个结论,足以让整个AI基础设施行业集体冒冷汗。
回车之后,你就是个旁观者

▲ "87%的工作发生在你按下回车之后,智能体在自己调用自己、使用工具、重试、记住上下文"
论文最醒目的数字是这个:在全部7.6亿次LLM调用中,约87%由智能体自行发起,用户直接触发的只占少数。
你输入一条指令,智能体平均会再自主跑6.6次模型调用,夹杂着读文件、改代码、跑构建、观察报错,然后才把控制权还给你。而且LLM调用和工具调用的数量比接近1:1,几乎每一次“思考”都跟着一次“动手”,每一次“动手”又引发下一次“思考”。
这已经超出聊天范畴:一台自我驱动的推理引擎在你的代码仓库里闷头跑圈。
作者Haoran Qiu在推文线程中把这层意思浓缩成三个字:Agents ≠ Chatbots。

▲ 论文作者Haoran Qiu强调:87% LLM调用由智能体发起,LLM与工具近1:1耦合
有评论者直接开了个玩笑:"模型只是在跟自己说话,直到累了。"但这个“笑话”背后站着一个严肃的产业问题:如果你的推理基础设施还在按“一问一答”的聊天模式来分配GPU资源,那你正在用2023年的地图导航2026年的公路。
KV缓存:一场每隔三分钟就会崩塌的记忆
论文的第二个发现,藏在一个大多数开发者从未直接关注过的技术层:KV缓存。
先说人话大语言模型生成每一个新词时,都需要“回忆”前面所有词的上下文。KV缓存就是把这些已经算好的中间结果存起来,下次不用从头再算。对编码智能体来说,每次调用的输入prompt中位数约6.8万token,其中约6.3万可以被缓存复用,一旦缓存命中,就能省掉海量重复计算。
论文画出了一条令人窒息的曲线:
智能体轮内第1次调用:缓存命中约45%(冷启动) - 第2次调用
:跳到86% - 第3次起
:稳定在92%–94%的高原
看起来很美对不对?然后用户说了句新话,
命中率从高原直接跌到55%


▲ 轮内>90%→跨轮边界55%→模型切换后仅8%:KV缓存的三级塌陷
如果更不幸,这一轮恰好触发了模型切换(约6.4%的会话会发生),那缓存命中率会暴跌到令人绝望的8%。几乎等于从零开始
一位评论者@0xAvseenko精准指出了这里的悖论:"如果你按每次调用做模型路由,看起来省了推理费,你抹掉的缓存价值可能远超便宜模型省下的钱。"

▲ 产业观察者指出per-call模型路由与缓存价值的深层矛盾
PhantomByte的技术解读文章更是直接把标题定为:"Your Agent's KV Cache Dies at Every Turn Boundary",你的智能体的记忆,在每一次对话轮次交接时都会死一次。
工具失败会让账单继续增长
聊天机器人报错了,你会看到一句"抱歉,请重试"。但编码智能体报错了?它会自己重试,一遍又一遍,每次重试都把错误日志塞进上下文,让prompt越来越胖,GPU越烧越热。
论文测到:约9%的轮次会遭遇工具失败,这些“失败轮”的资源消耗是正常轮的4倍,平均36次LLM调用、34批工具操作。是正常中位深度的四倍还多


▲ 9%的轮次出现工具失败,算力可被放大至正常的4倍
推特用户@mkeremturhan据此抛出了一个犀利的问题:"智能体恢复了,账单没有。" 他认为未来评测编码智能体时,不应只看“任务是否最终完成”,还必须给恢复成本打分。跑了十次才修好一个bug的智能体,不该和跑一次就过的得到相同评价。
50倍的鸿沟:不同用户需要不同SLO
论文把320万用户按行为特征分成五类,最深刻的发现是:最重的用户和最轻的用户之间,每轮token消耗相差50倍。
- Deep-loop用户
(9.2%):每轮吞噬约110万token,跑深度自治环,周末更活跃 - Chat-only用户
(7.6%):每轮仅约2.3万token,纯问答,不碰工具
一次缓存未命中,对前者意味着重算百万级token的prefill,对后者只是两万多token的小事。如果用同一套"一刀切"的缓存保留策略服务这两群人,要么深度用户被反复惩罚,要么轻度用户的资源被白白浪费。
论文由此指向一个工程命题:分层SLO,给深环用户更长的KV保留时间,对轻用户更积极地驱逐。这和云计算早年从"虚拟机统一调度"走向"按工作负载分层"是同一条路。
空闲时间里藏着“基础设施套利”
会话的绝大多数墙钟时间里,GPU其实闲着。多轮会话中,用户空闲中位可占整个会话时长的80%。跨轮用户空闲中位约25分钟,长尾可到次日。
但轮内的空闲又极短,KV缓存空闲中位仅1.2秒,工具容器空闲中位5.8秒。
这是一个教科书级的双峰分布:要么几秒钟后智能体就会再次需要这块缓存,要么要等好几分钟甚至更久。关键问题变成,你能不能在轮边界的那一刻,准确预判这次空闲属于哪个峰?
研究者做到了他们训练了一个轻量预测器,输入轮次特征(时长、调用数、token量、失败率)、会话历史与时间信号,输出"还会闲多久"的概率曲线。评估显示能捕获约86%–90%的总空闲时间。


▲ Prasenjit Sarkar认为,基础设施套利的空间就在适配智能体循环模式
Prasenjit Sarkar在长帖中一语中的:Cursor、Cline、Codex、Claude Code、Devin,所有这些产品对推理基础设施施加的负载,与任何上一代开发者工具都根本不同。 谁先把调度粒度从“请求”拉到“会话”,谁就能在同等GPU预算下服务更多用户。
一篇论文,一面镜子

▲ 独立读文站点概括:"大多数时间,智能体在自言自语"
这篇论文研究的是一个已经大规模商用的系统,并且把生产环境里的关键数字摆上桌面。
Romir Jain称之为"可能是今年最有用的系统论文"。这个评价或许并不夸张,因为它给了整个行业一个此前不存在的分母。以前我们说"智能体很贵"、"缓存很重要"、"工具会失败",都是直觉判断。现在我们知道:贵多少、重要到什么程度、失败后烧多少倍。

▲ 论文自带的"一页纸摘要":七条核心结论,每一条都指向一个工程决策
论文作者们承诺将发布脱敏轨迹数据。如果兑现,这批数据可以成为系统社区的经典trace:用来检验你的调度器、你的缓存策略、你的分层SLO,在真实世界里是否站得住。
尾声:聊天已死,循环永生
2022年底ChatGPT上线时,所有人的心智模型都是"对话",你说一句,我答一句。三年半过去了,微软用7.6亿次调用证明:对话框里发生的交互,早已超出一问一答。
它是循环是自治是“用户点了一下回车,然后去泡了杯咖啡,回来时智能体已经自己跑完了三十几步推理和工具操作”。
而我们为“对话”设计的一切基础设施,缓存策略、调度器、计费模型、甚至心理预期,全部需要重写。
这或许就是为什么,推特上一个评论者把整件事总结得如此精辟:
"模型只是在跟自己说话,直到累了"
只不过这一次,它累了,而账单才刚开始。
夜雨聆风