写代码的 AI，不是聊天机器人，微软用 1350 万次 Copilot 会话证明了这件事。

他们分析了今年 6 月 GitHub Copilot 的真实生产 trace，规模是 1350 万 sessions、320 万用户、7.61 亿次 LLM 调用、95 万亿 Token。

结论是：现在的 serving 基础设施，根本不适合 serving coding agent。

87% 的 LLM 调用不是用户发起的，是 agent 自己发起的。

你以为敲一行 prompt，模型回一段代码就完事？

一个用户的一段 prompt 会变成成一连串自主的模型调用、工具执行、重试、上下文膨胀……

LLM 调用和工具执行几乎是 1:1 配对。用户只开了个头，后面全是 agent 在忙。

同一个会话中内，第一次 LLM 调用的缓存命中 率只有约 45%，但从第三次开始， 命中率飙到 92–94%。这说明 agent 在会话中反复调用时，上下文是高度复用的。

可一旦跨过边界，哪怕模型没变，命中率直接掉到 55%，如果模型切换，命中率率只剩 8％。

也就是说，边界是一个非常强的状态断层信号。请求级别的调度策略完全忽略了这个信号，导致大量 KV cache 和 container 资源被白白浪费。

而 coding agent 的基础设施，应该按工作流状态来调度，而不是按请求来调度。

现在的 vLLM、SGLang 这些系统，最初都是为 chatbot 设计的：请求独立、短生命周期、无状态；但 agentic coding 又和 chatbot 不同：多步骤、工具交织、状态连续、上下文爆炸。

如果接下来 Agentic Coding 真的成为主流（Copilot、Claude Code、Codex 都在往这个方向走），那 infra 层必然会被重写。