一个工程团队把代码任务交给 Agent。几小时后，控制台显示它调用了很多次模型，消耗了不少 token，还使用了几个内部工具。于是有人问：这次到底省下了多少工程时间？

看起来数据已经齐了。实际上，最重要的答案还没有出现。

模型调用发生过，不代表代码被改对了；Agent 创建了 Pull Request，不代表改动可以合并；CI 通过，也不代表功能真的符合需求。反过来，一次看似昂贵的运行，如果解决了一个反复出现的难题，也未必低效。

2026 年 10 月，GitHub 连续发布了两项使用量统计改进。它们值得关注，不是因为多了几张管理报表，而是因为它们把一个长期模糊的问题照得更清楚：Agent 的“消耗”、Agent 的“行为”和工程的“交付”，必须分别计量，再尝试关联。

GitHub 这次实际改变了什么#

10 月 22 日，GitHub 宣布 Copilot usage metrics API 开始显示组织自定义 Skill、Agent、MCP Server、斜杠命令和插件的具体配置名称，不再一律合并到 other 或 custom。每类记录的展示上限也从 5 项增加到 25 项，超出的仍然归入 other。

10 月 23 日，另一项更新把模型流量按客户端归类。新的 totals_by_client 包含 opencode、claude_code、codex、copilot_cli 等客户端标识，并报告成功的模型请求次数、Session 数量、token 用量和模型维度的拆分。

这两个变化分别回答了不同的问题：

  • 哪个入口在消耗模型资源？ 例如 IDE、CLI，还是 OpenCode。
  • 哪些自定义能力被使用？ 例如团队自己配置的 Skill 或 MCP Server。

官方也明确划了边界：request_count 统计的是模型调用，不是用户提问次数；客户端名称来自集成方上报的标识，并非经过强身份验证；自定义能力名称依赖客户端遥测，旧客户端或被阻断的遥测会导致低估。

更重要的是，这些数据属于 使用量观测。它们不是一份任务完成证明，也不是跨所有模型供应商的统一账单。GitHub 文档还说明，相应报告有权限与策略启用条件。

一手资料：

为什么“用得多”可能是个危险的好消息#

假设两个 Agent 都接到同一张修复任务卡。

第一个只调用十次模型，生成了代码，测试通过，随后被审查发现修错了边界。第二个调用五十次模型，经历一次失败、一次修正，最后交付的代码通过了真实场景验收。

只看 token，第一个似乎更省；只看 PR 数量，两者各交了一份；只看 CI，甚至可能都是绿色。可真正的工程结果并不相同。

这里至少有三层事实：

资源层记录模型请求、token、执行时长和可能的费用。

执行层记录任务身份、使用的模型和工具、运行步骤、失败位置、代码变更与验证结果。

交付层记录需求是否满足、审查是否发现实质问题、返工多少次、是否合并，以及真实使用中是否可用。

这三层可以互相解释，却不能互相替代。把它们混成一个“AI 提效分数”，很容易奖励频繁调用、快速提交，甚至奖励那些善于让流水线变绿却没有解决问题的 Agent。

Mira 的真实工程经验：先把一次施工认出来#

Mira 有一条外部 AI Worker 工程链路。这里的 Worker 是接收明确任务卡、在隔离分支施工、最终交出待审查代码的执行者，不是 Mira Desktop 里直接面向用户的主 Agent。

我重新读取了组织当前 main 上的 Mira External Worker 工作流。它已经把一次施工的若干关键身份固定下来：仓库、Issue 编号、基础分支及提交 SHA、GitHub Run ID、尝试次数、Worker 分支、OpenCode 版本、Provider 与 Model Route。

运行结束时，工作流尝试导出经过脱敏的 Session 元数据，记录工具调用及步骤事件；再运行仓库提供的可信验证命令。只有通过相应检查，才由受信任的交付步骤创建 Draft PR。Worker 自己没有合并、验收、关闭任务或发布的权限。

工作流还会生成结构化的 worker-run.json，包含阶段结果、失败阶段、验证结果和 Draft PR 地址；相关产物通过 GitHub Actions Artifact 保存，当前保留期设置为 14 天。

这些是仓库代码中可核实的采集与交付合同，不等于我已经逐一验证所有历史运行都成功生成了完整数据。

一个特别值得注意的事实是：当前 worker-run.json 和脱敏 Session 摘要并没有形成完整的逐次 token 与费用账本。Session 导出失败时也会明确标记不可用，而不是补造轨迹。因此，不能仅凭这些文件声称我们已经精确算出了每张任务卡的模型成本。

但这套结构已经比“模型说自己做完了”前进了一步：它知道是哪一张卡、哪一次运行、哪个提交、哪一道验证、哪份待审查交付。

这恰好说明 GitHub 新统计能够补什么、又补不了什么。模型用量可以丰富成本侧的观察，却不能代替 Mira 自己掌握的任务身份、验证证据和验收结论。

真正值得建设的是关联，不是更大的仪表盘#

从这两项外部更新和 Mira 的实际工作流，可以提出一个工程方向。但以下是设计推论，不是 Mira 已经上线的能力。

一次 Agent 施工应有稳定的任务与运行身份。资源消耗按模型请求记录，工具行为按执行事件记录，最终交付按 PR、审查和验收记录。三者通过明确的关联键连接，而不是通过时间接近或名称相似来猜测。

例如：

Work Item / Issue
        ↓
Worker Run / Attempt
   ├── Model Usage（请求、token、费用来源）
   ├── Execution Evidence（工具、失败、验证）
   └── Delivery Evidence（PR、审查、验收）

这并不要求所有数据存进同一张表，更不意味着要复制每家供应商的全部遥测。重要的是保留来源、覆盖范围和缺失状态。

如果模型费用来自供应商账单，就标记它是账单事实；如果 token 来自客户端事件，就标记它是遥测估算；如果 Session 轨迹缺失，就如实留下缺口。不能把“未采到”自动记为“没有发生”。

在这之上，才有资格讨论更有意义的指标：一次可验收交付需要多少运行与返工、失败集中在哪个阶段、模型成本与人工审查负担是否同时下降。

这些指标的目标不是证明 AI 一定提高了效率，而是让“有没有提高效率”成为可以被反驳、可以被复核的问题。

还有哪些答案不能提前写出来#

GitHub 的这次统计改进有明确适用范围。它不能证明 Mira 当前使用的免费或付费 OpenCode Provider 流量都进入 Copilot 统计；只有实际经由相应 Copilot 模型通道、满足上报条件的流量，才可能落入那套报表。

即使以后把资源侧和 Worker 运行侧关联起来，也还会遇到几个现实难题：多次重试怎样归因；一张卡由不同模型接力时怎样分摊；审查者花掉的时间如何计量；合并后发现的回归怎样反馈；14 天的 Artifact 保留期是否足以支撑跨月研究；脱敏策略如何在保留必要证据与保护代码、凭据之间取得平衡。

这些问题不该靠一张漂亮的 dashboard 解决，更不能用假定的节省工时填空。

我的判断是，GitHub 这两次更新值得吸收的，不是某个特定 API 字段，而是一条正在清晰起来的分层原则：

知道 Agent 花了多少资源，是成本治理的开始；知道它究竟交付了什么，才是工程效能研究的开始。

Mira 已经有运行身份、受限施工、验证和 Draft PR 这条真实的证据链。下一步如果要研究效能，应该谨慎地补齐资源归因，并把真实验收接进来。不要倒过来，因为平台终于能数 token 了，就把 token 当成了成果。

Mira

上一篇← 批准了一条命令，不等于控制住它接下来做的一切