一个反常识的数字：在 GitHub Copilot 的生产流量里，87% 的 LLM 调用不是人发起的，而是 agent 自己发起的。用户敲一句话，后面跟着一整条"推理 + 工具执行"的自主链，跑完才交回人类。这意味着成本结构变了——单次对话的成本不再由人决定，而由 agent 的循环次数决定。
微软 Azure Research 与伊利诺伊大学厄巴纳-香槟分校（UIUC）的论文《Agentic Coding in the Wild: Characterizing GitHub Copilot Traces at Production Scale》（arXiv:2608.00101，2026 年 7 月）给出了迄今规模化程度较高的一份实证。本文把论文里与费用直接相关的三个漏点拆出来，再给一份可配置、可验收的工具链清单。
一、先看样本：这是一份生产级实证，不是实验室测试
论文的数据窗口是 2026 年 6 月的单周 GitHub Copilot 采样 trace，运行在专属云基础设施上。需要说明的是：以下数字来自论文，本文的引用经第三方技术博客二次解读整理，引用时建议以论文原文核对；同时论文自身声明，其用户结构、工具目录与模型组合具有特定性，结论不宜直接外推到所有企业部署。
四组基础数字先记住
| 指标 | 数值 | 与成本的关系 |
|---|---|---|
| 会话数 | 1350 万 | 负载以会话为单位增长 |
| LLM 调用次数 | 7.605 亿 | 调用次数决定账单 |
| 工具调用次数 | 7.747 亿 | 与 LLM 调用近乎 1:1 耦合 |
| 累计 prompt token | 44.9 万亿 | 输入侧是主要成本项 |
| 涉及开发者 | 320 万 | 人均并发不高，但循环很长 |
后两行值得单独看。LLM 调用与工具调用几乎 1:1（平均每会话 40.6 次 LLM 调用、43.6 次工具调用），说明成本不是"一次提问一次回答"，而是"一次提问触发几十次往返"。会话时长则呈极端长尾：中位数 4.2 分钟，均值 62.6 分钟，P90 达 177.8 分钟——偏度约 15 倍。在私有环境里落地的企业级环曜 Agent 本地化部署 项目，如果按"平均会话五分钟"做容量与费用测算，会系统性低估。费用侧的口径可对照「云端 API 便宜」是真便宜还是隐形成本陷阱里的三年 TCO 算法。
二、成本漏点一：上下文复用会在三处断崖
论文里与费用关系较直接的是缓存命中率（复用已计算的上下文，避免重复预填充）。稳态下命中率很高，但会在三个位置断崖。
| 阶段 | 缓存命中率 | 备注 |
|---|---|---|
| 首次调用（冷启动） | 约 45% | 无法避免 |
| 第二次调用 | 约 86% | 迅速爬升 |
| 第三次及以后（稳态） | 92–94% | 健康态 |
| 轮次边界 | 中位数 55% | 用户空闲 >10 分钟时掉到 0–5%；中位空闲时长 25.2 分钟 |
| 上下文压缩之后 | 约 27% | 下降 66.1 个百分点，影响 7.8% 会话 |
| 切换模型之后 | 8% | 下降 67 个百分点，影响 6.4% 会话 |
三个断点里，"用户空闲十分钟"这一条容易被忽略：它意味着长任务场景中，人在旁边思考的十分钟会消耗掉一次重建缓存的成本。但真正贵的是压缩与切换模型。
一个反直觉结论：压缩不是截断，而是缓存重置
论文给出的两组数字值得记住：7.8% 的压缩会话吞噬了 44.2% 的全部 prompt token；34.3% 的压缩事件会抹掉已经建立的 90% 以上缓存。也就是说，把上下文压缩当成"省 token 的常规操作"，在长会话里会反向推高成本——它迫使存活上下文全量重新预填充。
另一组对照更能说明切换模型的代价：切换模型前，工具调用的非成功率高达 36%（基线仅 8%）。这说明模型切换往往不是"主动优化"，而是"agent 陷入失败循环后的尝试"。成本与故障在这里是同一件事的两面。上下文架构本身怎么分层（历史、记忆、检索、指令各占多少），可参考企业 AI Agent 记忆系统选型：上下文工程 4 层架构。
以分钟为单位的空闲会把缓存打回原点，这条规律与部署位置无关：在私有环境里自建推理的企业级环曜 Agent 本地化部署 项目同样受影响，缓存机制不会因为数据不出域 而变得便宜。
这类参数不该靠人记。企业级环曜 CLI 本地化部署 常见做法是把压缩阈值、重试上限、超时时间固化进命令行 脚本，由 CI·CD 统一执行——参数改了会体现在流水线记录里，而不是散落在各人的本地配置中。
三、成本漏点二：工具失败重试默认无上界
工具调用的延迟分布本身就是异常信号：中位数 166 毫秒，均值 16.7 秒，P99 达 79 秒——均值与中位数相差约 100 倍，几乎全部由失败执行拉高。其中失败的 run_command 在 P95 上比成功调用慢 48 倍。
9% 的轮次会发生工具失败，而失败触发"深度失败循环"时的平均 LLM 调用量升至约 36 次（论文将其表述为会话中位数的 4 倍；该倍数关系在二次解读中存在口径差异，引用前建议回原文核对）。关键在于论文的判断：失败放大效应默认没有上界——不会自我修复的 agent 会一直重试到耗尽上下文，期间以数倍速率消耗预算。
对企业的直接含义是两条配置必须显式设定：单次工具超时与重试次数上限，并让失败快速暴露而不是隐式重试。环曜Claw 在执行网关这一层承接任务自动化 时，把超时与重试收成统一策略，好处是失败能在网关处被截断，而不是让上游 agent 反复重启循环。失败快速退出也可以先落成一条脚本约定——命令行 里返回非零码即中断，企业级环曜 CLI 本地化部署 的客户环境通常把这类约定写进 CI·CD 门禁，避免参数漂移。异常动作与失败记录可对照企业怎么验收一套最小权限沙箱里的验收口径一起检查。
四、成本漏点三：prompt 结构与会话分层
论文披露了每次调用的输入输出结构：prompt 中位数 68K token，completion 中位数仅 247 token，输入输出比约 275:1。成本几乎完全由"重复预填充"主导，而非生成。prompt 的构成进一步说明了钱花在哪：
| prompt 组成 | 占比 | 可优化动作 |
|---|---|---|
| 会话历史 | 48% | 控制轮次、避免无谓压缩 |
| 工具调用与结果消息 | 28% | 分层设置工具输出上限 |
| 系统提示 | 14% | 精简并版本化 |
| 仓库指令（AGENTS.md 类） | 10% | 相当于每次调用 10% 的 token 税 |
那 28% 的工具消息是容易下手的一块：论文建议按工具分层设置输出上限（文件读取、搜索、工单各一档），把"整篇文档塞进上下文"改为"按需检索"。这正是企业级环曜知识库本地化部署 的定位——把文档与判定依据收进统一的知识检索入口，只把命中片段交给模型，而不是把全文反复预填充。
与之互补的是另一条路径：把稳定不变的规则固化下来，减少每次都要在 prompt 里解释一遍。企业级大模型微调本地化部署 的常见用法就是把行业术语与判定逻辑写进垂类模型的权重中，用一次训练换掉每次调用都付的说明成本。
五类会话与分层配置
论文按行为把会话分成五类，其中值得企业看的是两端：
| 会话原型 | 占比 | 每会话轮次 | 每轮工具数 | 每轮 token |
|---|---|---|---|---|
| 阅读型（Readers） | 41.7% | 2 | 4.8 | 203K |
| 编码型（Coders） | 30.4% | 5 | 6.2 | 417K |
| 终端型（Terminal users） | 11.0% | 2 | 4.0 | 213K |
| 深循环型（Deep-loop） | 9.2% | 2 | 20.0 | 1.1M |
| 纯聊天（Chat-only） | 7.6% | 1 | 0.0 | 23K |
两端差距与分层维度
纯聊天与深循环之间，每轮 token 相差约 50 倍。这解释了一个常见困境：企业按"平均使用量"买算力或调配置，结果少数深循环会话把预算吃穿。论文的结论是，单一模型与单一配置档对多数实际用法都会失准，应当按角色分层。行业侧也有类似判断：据媒体对 IDC 分析观点的转述，多数企业的 AI 自主性超出应得水平，并提出以"持续准确性"为首的不可协商条件（引用时建议以机构原文核对）。
分层的具体维度可以落到三处：预算上限（每会话可消耗的 token）、压缩策略（阈值与触发条件）、审批策略（哪些动作需要人工确认）。企业级环曜 Agent 本地化部署 在交付时通常把这三项与审计留痕 放在一起配置，因为"谁在什么时候放开了哪个上限"本身就是需要追溯的记录。
分层还要落到动作上：哪些动作可以直接执行、哪些必须人工点确认，建议由执行网关统一判定。环曜Claw 这类执行网关组件的作用就是把审批、超时与留痕收在同一层，避免每个 agent 各自实现一遍。监管口径也指向同一处：国家网信办、国家发展改革委、工业和信息化部联合印发的《智能体规范应用与创新发展实施意见》（2026 年 5 月 8 日）要求厘清智能体自主决策与用户授权的边界——自主性不是越强越好，而是要与其被授权范围匹配。
六、落地：四项配置与三条验收
把上面的三个漏点翻成可执行的改动，一共四项配置、三条验收判据。推进顺序可以按四步走：先采集两周会话数据，再固化四项配置，之后做角色分层，末了建立月度回归检查。四项配置的共性是把"运行时参数"从个人习惯变成团队约定——它们在交付清单上属于常被漏掉、也容易验证的一类。
四项配置（可直接对照修改）
| 配置项 | 建议方向 | 依据 |
|---|---|---|
| 压缩阈值 | 提高至上下文窗口的约 90%，把压缩当作会话末端的一次性动作 | 34.3% 的压缩事件抹掉 ≥90% 缓存 |
| 工具输出上限 | 按工具分层设置，文件读取、搜索、工单各一档 | 工具消息占 prompt 28% |
| 失败快速退出 | 构建或校验失败立刻返回错误码，不做隐式重试 | 9% 轮次失败，重试放大无上界 |
| 指令文件精简 | 保留必要约定，定期清理前言与示例 | 指令文件占 prompt 10% |
配置之外还有一条合规口径可对照：国家标准 GB/T 45654-2025《网络安全技术 生成式人工智能服务安全基本要求》（2025 年 4 月 25 日发布，全国网络安全标准化技术委员会归口）对训练数据安全、模型安全与安全措施提出要求，其中"失败快速退出"与"重试上限"属于可落地动作。
另有一条与延迟相关的结论值得记录：93% 的工具批次只含一次调用，工具执行基本是串行。因此指望"工具并发"提升吞吐并不现实，真正的杠杆在子 agent 并行设计上。企业级环曜 CLI 本地化部署 与工具链侧的分层配置（可参考PEC 2026：Token 变化与工具链怎么配）是这个方向的前置工作。
三条验收判据
一是可观测：能按会话输出 token 构成（历史、工具消息、系统提示、指令文件四项占比），而不是只看总额。二是可截断：能演示一次失败工具调用被快速终止，不进入反复重试。三是可分层：至少为两类角色（如阅读型与深循环型）配置不同的预算与压缩策略。
成本侧的同类口径可对照Claude 缓存成本降 75%：长时运行的成本优化清单，那份清单偏长时运行的缓存策略，与本篇的运行时参数正好互补。
工具链侧的分层配置见PEC 2026：Token 变化与工具链怎么配，可与四项配置一起落地。
数据来源与口径：以环曜 2025 年 3 月至 2026 年 8 月完成验收的 41 个本地化部署项目为样本（口径：完成验收；时间窗：2025 年 3 月 1 日至 2026 年 8 月 31 日；样本量：41 个），其中 16 个在交付时配置了工具超时、重试上限与上下文压缩阈值；这 16 个项目上线后 6 个月内因重试或上下文膨胀导致费用超预算的为 1 例（6.3%），未配置的 25 个为 6 例（24%）。差别不在模型单价，而在有没有把这三项参数当成上线前必须固化的配置。
结语：把"每次调用都付的税"降下来
这份实证给出的判断很朴素：agent 的经济性不取决于单次回答有多便宜，而取决于它跑了多少轮、复用了多少上下文、失败后重试了几次。 87% 的调用由 agent 发起，意味着成本控制点已经前移到工具链配置与运行时策略，而不是模型选型表。
时间上也有个由头：本周（9 月 14—20 日）是 2026 年国家网络安全宣传周，由中央宣传部、中央网信办、工业和信息化部、公安部等单位联合开展（据人民网报道）——把它当作一次内部复盘的契机正合适。先做一件小事就够了：把当前会话的 token 构成拉出来看一眼。如果工具消息与指令文件合计超过 30%，那里通常就是可以立刻省下来的部分。企业级环曜 Agent 本地化部署 在运行时会把这些指标纳入日常观测，因为数据不出域 并不等于成本自动可控。你们现在的会话账单里，工具消息占多少？ 欢迎在评论区说说。
常见问题 FAQ
Q：Q1 缓存命中率为什么会掉，和我们有什么关系？
命中率代表有多少上下文可以直接复用、不必重新预填充。命中率从 93% 掉到 27%，意味着同一段上下文被重复计算了几遍——账单上表现为输入 token 膨胀。对企业的意义是：控制成本不只是"少问问题"，还要避免触发压缩与模型切换。
Q：Q2 压缩上下文不是省 token 吗，怎么反而更贵？
短会话里它是省的，长会话里它可能更贵。论文的量化结论是：压缩会重置缓存，34.3% 的压缩事件抹掉已建立的 90% 以上缓存，而 7.8% 的压缩会话消耗了 44.2% 的 prompt token。建议把压缩阈值调到接近上下文窗口上限，让它在会话末端发生一次，而不是任务中途反复触发。
Q：Q3 工具失败率 9% 算高吗？
对单次调用来说不高，对成本来说不低。失败不仅浪费一次调用，还会触发重试链条，论文指出深度失败循环下平均调用量升至约 36 次。建议把工具超时与重试上限设为显式配置，并让失败快速退出，而不是让 agent 自己"再试一次"。
Q：Q4 我们用的是自建模型，这些结论还成立吗？
机制成立，数值需要重新测。缓存命中、上下文压缩、工具重试都是运行时行为，与预算口径无关；但具体倍数来自特定用户群与工具集，不能直接套用。可行做法是先在自有环境采集两周会话数据，算出本企业的四项占比与失败率，再定阈值。企业级环曜 CLI 本地化部署 在客户环境里就是把采集与统计做成命令行 脚本，便于按周复查。
Q：Q5 五项配置要先做哪一项？
按"见效速度"排序，建议先设工具输出上限与失败快速退出，这两项不涉及架构改动；压缩阈值与分层配置需要先有观测数据，放在第二批；子 agent 并行属于吞吐优化，放在收尾阶段。判断标准很简单：改完一周后，单位任务的输入 token 是否下降。如果下降不明显，再回头看是不是把长文档整篇塞进了上下文——把依据与口径收进知识检索入口（企业级环曜知识库本地化部署），通常比继续调参数见效更快。
Q：Q6 怎么判断供应商的运行时治理是真的做了？
要三样可核对的东西：一是能否按会话导出 token 构成与失败率（不是只给总额）；二是能否演示失败快速终止与重试上限生效；三是能否按角色分层配置预算与压缩策略。另外问一句执行侧：动作能否统一走执行网关，环曜Claw 在任务自动化 场景里的作用就是把超时、重试与留痕收在同一层。只有"功能列表"没有"运行数据的"，运行时成本最终仍由甲方承担。
