你让编码 Agent 修一个报错，它往往不会只回一段代码。它先读文件，再搜索相关位置，改完后运行测试；测试失败，又读错误日志、继续修改。对用户来说，这是一条指令。对后台系统来说，却是一串模型推理和工具执行交替发生的长流程。服务器该保留多久的“记忆”，什么时候释放资源，不能再照搬普通聊天机器人的经验。
一项针对 GitHub Copilot 的研究，试图用真实生产轨迹回答这些问题。作者分析了 2026 年 6 月抽样的一周数据，摘要称其覆盖 320 万用户、1300 万次会话、7.61 亿次大语言模型（LLM）调用和 95 万亿个 token——token 是模型处理文本时使用的基本单位。论文称，这是首个生产规模的编码 Agent 工作负载刻画。不过，本文所有数据和判断都来自同一作者团队，尚无公开数据集或第三方研究交叉验证。
一条指令，后台跑了多少步？
编码 Agent 的基本节奏是“观察—计划—行动—再观察”。这里的行动通常通过工具调用完成：模型生成结构化指令，让搜索器、文件编辑器或终端真正执行操作，然后读取返回结果，决定下一步。
研究把一次会话拆成用户轮次和步骤。一个用户轮次从用户发出提示开始，到 Agent 完整交回结果为止；其中可以包含多次 LLM 调用和工具调用。样本中，87% 的 LLM 调用由 Agent 自主续接，而不是用户直接触发。每次会话平均有 40.6 次 LLM 调用和 43.6 次工具调用，接近 1∶1。换句话说，模型多数时候不是“想完再统一动手”，而是想一步、做一步、看结果，再想下一步。
典型会话并不算长：中位数是 3 个用户轮次、15 次 LLM 调用，持续 4.2 分钟。但平均值分别升到 6.1 个轮次、40.6 次调用和 62.6 分钟。这种中位数与平均值的巨大差距说明负载呈长尾分布：多数任务较短，少数持续很久的任务却吃掉大量时间和算力。到第 90 百分位，一次会话已有 15 个用户轮次、超过 100 次 LLM 调用和 111 次工具调用，持续时间超过三小时。
失败还会放大成本。论文把 9.1% 的轮次归为“带失败的深循环”：它们平均包含 36 次 LLM 调用和 34 批工具操作，约为典型轮次的四倍。聊天机器人报错后通常等用户重试；Agent 则可能自行诊断、再次运行，并把新的错误输出继续塞进上下文。
真正昂贵的是反复阅读
这些调用有一个反直觉特征：模型读得极多，写得很少。每次调用的提示词中位数为 6.8 万 token，输出中位数只有 247 token，输入与输出之比超过 275∶1。会话历史平均占输入的 48%，工具调用记录再占 28%。Agent 最大的负担，常常不是生成那几行代码，而是反复读入自己此前看过和做过的内容。
这就让 KV cache 变得关键。KV cache 可以理解为模型阅读长文本时留下的中间计算结果；下次遇到相同前缀，就不用从头重算。一个轮次内部，上下文会逐步增长，但旧内容基本不变，因此缓存很好用：第一次调用的命中率约为 45%，第二次升至 86%，第三次以后稳定在 92%至94%。论文概括的轮次内平均命中率约为 90%。
问题出现在用户接手的瞬间。一个轮次结束后，用户可能花几分钟检查结果、思考下一条指令。缓存长时间不用，就可能被服务器清走。论文称，跨轮次的命中率降至约 55%；空闲不足两分钟时通常仍能保持较高复用，进入 2至10 分钟区间后明显下滑，超过十分钟时中位命中率接近 0至5%。
模型切换更彻底。不同模型的内部计算不兼容，旧缓存无法直接沿用。研究观察到，6.4% 的会话发生过模型切换，切换后的平均缓存命中率只剩 8%。
另一种破坏来自 context compaction——上下文压缩。当历史快要塞满模型可接收的长度时，系统会删除或概括旧消息，为后续步骤腾空间。但重写后的提示词前缀也不再相同，缓存近似重新冷启动。压缩只出现在 7.8% 的会话中，这些会话却贡献了 44.2% 的总 token、37.1% 的 LLM 调用和38.9%的工具调用。它不是普遍事件，却集中发生在最重的任务里。
服务器要看会话，而不只是看请求
传统 LLM 服务系统通常把请求视为彼此独立的短任务。编码 Agent 却形成一条有状态的链：前一次工具结果决定下一次推理，缓存价值也随轮次位置、用户停顿、模型切换和上下文压缩而变化。研究因此主张，调度单位应从单次请求扩展到整个会话。
用户停顿尤其值得利用。Agent 在轮次内部通常快速连续工作，轮次之间却可能空闲数分钟。论文设计了一个轻量级空闲时间预测器，可捕获总空闲时间的 86%至90%。这不是“预测准确率”，而是它能够识别出的空闲时间占比。若系统能提前判断停顿可能持续多久，就可以决定继续保留缓存，还是转移缓存、释放容器和计算资源。
这项工作的价值不在于证明 Agent 会调用工具，而在于把这种直觉量化：一次交互背后有多少自主调用，缓存在哪些节点失效，失败会放大多少工作，以及少数重度会话为何不能按平均负载处理。它为面向 Agent 的服务系统提供了一张来自生产环境的负载地图。
局限与未知
- 数据来自 GitHub Copilot 在 Visual Studio 和 VS Code 中的匿名遥测，覆盖美国多个地区、至多三个时区，不能直接外推到 Claude Code、Codex 或全部编码 Agent。
- 论文未披露抽样比例、具体模型身份、用户与产品形态的完整定义，也没有公开提示词、代码内容或工具参数；外部读者无法独立复现这些统计。
- “首个生产规模刻画”和“挑战现有系统假设”是作者的定位。轨迹能揭示资源形态，但材料没有证明依照这些发现改造系统后，实际成本或延迟会改善多少。