承接 Copilot Agent 会话流式审计实战从 48 小时补数到脱敏告警闭环调研日期2026-08-08本文目标基于 GitHub Copilot Usage Metrics 新增的 Agent App 字段建立可复查的多 Agent 采用度口径清楚区分 Job 启动、Session、Prompt 与结果质量避免把可计数活动误写成生产率结论。2026-08-07GitHub 为 Copilot Usage Metrics API 增加了 Agent App 活动的按 Agent 拆分。企业、组织及其用户级的 1 日和 28 日报告中新增可选的 totals_by_3rd_party_agent 数组已识别的 Agent App 会按稳定的 agent_id 聚合。官方公告给出的直接价值是团队终于可以把不同 Agent 的采用情况拆开观察而不是把所有工作都塞进一个模糊的活动桶。这是一个很容易被误读的进展。看到活动数量上升不代表代码质量上升看到 Session 变少也不一定代表效率变差更不能把 Agent 的 Job 启动次数与人类在 IDE 中发出的 Prompt 相加后宣布“总工作量”。正确的起点是先建立数据字典、时间窗口和失败解释再决定指标能支持哪些治理动作。适用前提你的企业或组织已启用 Copilot usage metrics policy且负责人员拥有相应的 Metrics 查看权限。示例只展示读取报告的最小流程不应把下载链接、原始 NDJSON、用户标识或访问令牌提交到代码库。一、先把四类计数拆开它们不是同一个单位新增字段关注的是“已识别 Agent App 的服务端作业活动”并不是所有 Copilot 或所有 Agent 的统一工时表。先把最重要的字段放在一张表中字段或概念它实际计数什么适用范围不能据此断言什么totals_by_3rd_party_agent每个已识别 Agent 的活动条目无相关活动时整个字段会省略未识别 Agent 完全不存在agent_idAgent 的稳定标识跨报表周期用于分组和关联Agent 的展示名称或厂商策略永不变化agent_nameAgent 的显示名称适合仪表盘显示跨周期主键嵌套 user_initiated_interaction_count用户发起的 Agent App Job 启动数每次 Job 开始计一次人类发出的所有 Copilot Prompt 数session_countAgent App Session 数仅企业或组织聚合报告提供用户级条目省略每个用户的会话次数顶层 user_initiated_interaction_count其他受支持遥测中的显式 Prompt 总数报告顶层Agent App Job 启动数两个约束尤其值得写进数据模型用 agent_id 分组而不是 agent_name。显示名称可能变化同一 Agent 的多个 App 集成也会被合并到一个 Agent 条目。不要把两个同名交互计数相加。嵌套字段是 Agent App Job start顶层字段是其他遥测里的显式 Prompt它们的触发路径不同官方明确说不能互换或求和。所以“本周某 Agent 有 150 次 Job”只能说明这个受管范围内出现了 150 次用户发起的作业启动。它不能单独证明 150 个任务完成、150 次代码变更正确或 150 次调用都比人工更快。二、先选对报告粒度再谈仪表盘Usage Metrics 同时提供 1 日和 28 日报告。1 日报告适合发现刚上线的策略或集成是否产生可见活动28 日报告适合查看一个完整窗口内的聚合总量。要判断“是否在多个日期持续出现”不能只看一份 28 日用户报告它是该窗口的一条聚合记录必须保留连续的 1 日用户报告再按日期计算。目标问题推荐报告为什么新 Agent 是否真的被试点成员启动用户级 1 日报告可以按用户级记录检查是否出现对应 Agent 条目一个 Agent 是否有稳定使用而非偶发点击连续 28 份用户级 1 日报告逐日记录目标 Agent 是否出现才能计算活跃天数分布某个周期的总采用量28 日用户级报告一条记录汇总窗口内的活动适合期间比较不能还原每日出现情况企业或组织层面有多少 Agent Session聚合 1 日或 28 日报告session_count 只在聚合条目中提供新旧 Agent 是否同时被采用用户级报告按 agent_id 汇总避免按可变显示名称比较是否应该扩大、暂停或训练试点28 日量化趋势加人工样本指标提供信号任务质量仍需人审读取前先核对权限与开关。官方 REST 文档要求开启 Copilot usage metrics policy企业端通常需要企业所有者、账单经理或已授予 View Enterprise Copilot Metrics 的角色组织端也需要相应的组织权限。细粒度令牌应仅授予读取 Copilot metrics 的最小权限且专用于报告拉取。不要把组织级与企业级的返回形状想当然视为完全相同。当前文档对具体字段、用户级与聚合级的可用性有区别尤其是在组织级聚合视图中应以你当天实际拿到的 schema 为准而不是只依赖早期公告或他人的截图。三、用最小权限取回 1 日报告下面以组织的用户级 1 日报告为例。GitHub CLI 会使用本机已有的安全登录状态因此命令中不出现令牌。请在受控终端中运行并将 ORG 与 DAY 替换为真实值。ORGyour-organization DAY2026-08-07 gh api \ --method GET \ -H Accept: application/vnd.githubjson \ -H X-GitHub-Api-Version: 2026-03-10 \ /orgs/$ORG/copilot/metrics/reports/users-1-day?day$DAY该请求返回的是报告下载链接和报告日期不是整份指标内容本身。下载链接为限时签名链接适合在受控的采集作业中短暂使用不适合写入 Git、Issue、聊天记录或长期日志。只处理 API 返回的完整已处理报告日不要因为当天报告尚未生成、链接过期或采集作业失败就填充零值。对于 28 日窗口可改用 users-28-day/latest 端点取得期间聚合企业范围则使用 enterprises 下对应的 reports 路径。若要计算每日持续采用度则连续拉取并留存 28 份 users-1-day 报告。完整端点、权限与响应定义应以 GitHub REST API 文档为准。报告拉取后先把字段规范化为只含聚合分析所需列的临时数据集。下例假定 report.ndjson 是已经在受控存储中下载的报告文件jq -c (.totals_by_3rd_party_agent // [])[] | { agent_id: .agent_id, agent_name: .agent_name, job_starts: .user_initiated_interaction_count, session_count: (.session_count // null) } report.ndjson这里的空数组有明确含义某条记录没有已识别的 Agent App 活动时字段可能被省略。不要强行填成“所有 Agent 都是 0”更不要把“未识别或未上报”解释为“团队完全没有使用任何 Agent”。为了让报表审阅者一眼看出计数边界可保留如下的示意记录。数值仅用于说明字段层级不代表真实组织数据{ user_initiated_interaction_count: 137, totals_by_3rd_party_agent: [ { agent_name: Example Coding Agent, agent_id: example-coding-agent, user_initiated_interaction_count: 12 } ] }上面的 137 与 12 没有加法关系。第一项是顶层显式 Prompt 计数第二项是特定 Agent App 的 Job start。只有在数据字典明确了不同事件的来源、去重方式和业务问题后才可以把它们放在同一张分析图中比较趋势。四、为多 Agent 试点建立“可回答问题”的指标契约先确定你要用数据做什么再写公式。一个适合早期试点的最小契约可以只回答四个问题决策问题建议指标计算口径需要配套的人类证据试点是否真的开始使用活跃采用者数出现目标 agent_id 的去重成员数成员是否完成接入与培训使用是否持续28 日活跃天数分布从连续 28 份 1 日报告中计算每个 agent_id 出现的报告日数量是否只是一次演示或临时故障处置用户启动后是否形成会话聚合 Job start 与 Session 的趋势同一报告粒度内分别查看不强行一一对应代表性任务是否需要多轮协作是否应扩大范围增长趋势加任务样本仅比较相同人群、相同时间窗口代码审阅、测试、返工与安全事件复盘最后一行最重要。采用度指标可以帮助发现“谁在用什么”但无法替代质量证据。若要讨论实际工程价值至少还要从独立系统取证例如PR 是否被人工合并、测试是否通过、故障是否减少、审阅返工是否下降以及用户是否明确反馈某类任务更适合或不适合交给 Agent。建议将个人数据最小化对组织级决策默认输出按 agent_id、团队或已批准的最小群组聚合后的趋势而不是公开个人排名。对用户级报告设置明确用途、访问期限和审计记录它应服务于接入障碍排查和培训改进不应成为单一绩效指标。将原始 NDJSON、下载链接和转换后的分析数据分开存放前两者只保留在受控存储中仓库只保存查询定义与无敏感的聚合结果。五、用“1 日健康检查 每日留样 28 日聚合”做渐进决策一套低噪声的运行节奏可以分为三段阶段看什么允许的动作不该做什么上线后第 1 天目标 agent_id 是否出现、字段是否按预期省略或返回修复权限、策略、采集脚本与培训入口用一天数据评价人或采购效果第一周每日已处理报告中的 Job start 异常尖峰或完全缺失排查重复触发、集成故障、报告延迟或试点覆盖问题把峰值直接当作效率提升第一个完整 28 日窗口连续 1 日报告计算的采用持续性加上 28 日聚合、不同 Agent 重叠和代表性任务样本决定扩展试点、补培训、收紧范围或下线集成用活动数替代质量、成本或风险评审如果多个 Agent 在同一团队并行试点比较时必须固定人群和时间窗口。不要用“新 Agent 的前三天”对比“旧 Agent 的全部历史”也不要因为一个 Agent 被用于更长、更复杂的任务就把更高 Job 数判成更差体验。指标是提出问题的入口不是自动裁决。当报表出现异常时按下面顺序排查通常更快确认 Copilot usage metrics policy、角色权限与报告日期是否正确。确认目标 Agent 是否属于已识别 Agent App无法识别的活动不会出现在该数组中。确认报告日已经处理完成且采集作业没有漏跑缺失报告不是零活动。确认当前查看的是用户级还是聚合级报表避免把缺失的 session_count 当作零。核对 agent_id 是否稳定避免因显示名称变化导致同一 Agent 被拆成两条趋势。再结合任务样本与人类反馈判断这是集成问题、培训问题还是实际不适配。六、六个常见误区1按 agent_name 做长期分组显示名称可以变化。仪表盘展示用名称数据仓库关联、趋势比较和告警规则都应该使用 agent_id。2把嵌套 Job start 与顶层 Prompt 相加它们名称相似事件来源不同。相加会制造一个没有清晰业务含义的“总互动数”也会误导后续预算或采用判断。3把用户级缺少的 session_count 填成 0用户级 Agent App 条目本来就不提供这个字段。缺失意味着“该层级不可用”不是“用户没有 Session”。4把字段省略理解为绝对没有 Agent 使用该数组只覆盖已识别 Agent App。没有数组可能表示没有已识别活动也可能意味着某类集成不在这一统计范围内需要结合产品配置和其他审计来源解释。5把 Job 数量当成开发质量或个人绩效一个高质量的长任务可能只启动一次一个调试失败的任务也可能反复启动很多次。活动指标不包含正确性、审阅结果、安全影响或业务价值。6把签名下载链接和原始报告塞进仓库限时链接仍可能暴露受控数据访问路径原始报告也可能包含用户级活动。代码库应保存采集说明、字段定义和脱敏聚合而不是敏感原始材料。结语按 Agent 拆分 Usage Metrics 的意义在于让多 Agent 治理终于拥有一条可复查的采用度证据链用稳定 agent_id 观察不同 Agent用 Job start 解释用户是否启动任务用聚合 Session 观察会话形态再把这些信号与人工审阅、测试和风险复盘连接起来。正确的下一步不是立刻排名“哪个 Agent 最好”而是先为一个小试点写清数据契约看哪些字段、按什么窗口、由谁读取、缺失如何解释、什么额外证据才允许扩大范围。这样得到的报表才能服务于技术决策而不是把一串活动数字伪装成生产率结论。来源与延伸阅读Copilot usage metrics API adds agent app activityGitHub 官方公告发布于 2026-08-07说明按 Agent 聚合、字段含义、报告范围与重要限制。Data available in Copilot usage metrics当前字段定义包含 Agent App、CLI、Copilot app 与活动维度的口径。REST API endpoints for Copilot usage metrics1 日与 28 日报告端点、权限、时间窗口与下载链接行为。CSDN 标题标签AI Agent · GitHub Copilot · 多智能体 · 可观测性 · 数据治理 · 工程效能
承接 Copilot Agent 会话流式审计实战从 48 小时补数到脱敏告警闭环调研日期2026-08-08本文目标基于 GitHub Copilot Usage Metrics 新增的 Agent App 字段建立可复查的多 Agent 采用度口径清楚区分 Job 启动、Session、Prompt 与结果质量避免把可计数活动误写成生产率结论。2026-08-07GitHub 为 Copilot Usage Metrics API 增加了 Agent App 活动的按 Agent 拆分。企业、组织及其用户级的 1 日和 28 日报告中新增可选的 totals_by_3rd_party_agent 数组已识别的 Agent App 会按稳定的 agent_id 聚合。官方公告给出的直接价值是团队终于可以把不同 Agent 的采用情况拆开观察而不是把所有工作都塞进一个模糊的活动桶。这是一个很容易被误读的进展。看到活动数量上升不代表代码质量上升看到 Session 变少也不一定代表效率变差更不能把 Agent 的 Job 启动次数与人类在 IDE 中发出的 Prompt 相加后宣布“总工作量”。正确的起点是先建立数据字典、时间窗口和失败解释再决定指标能支持哪些治理动作。适用前提你的企业或组织已启用 Copilot usage metrics policy且负责人员拥有相应的 Metrics 查看权限。示例只展示读取报告的最小流程不应把下载链接、原始 NDJSON、用户标识或访问令牌提交到代码库。一、先把四类计数拆开它们不是同一个单位新增字段关注的是“已识别 Agent App 的服务端作业活动”并不是所有 Copilot 或所有 Agent 的统一工时表。先把最重要的字段放在一张表中字段或概念它实际计数什么适用范围不能据此断言什么totals_by_3rd_party_agent每个已识别 Agent 的活动条目无相关活动时整个字段会省略未识别 Agent 完全不存在agent_idAgent 的稳定标识跨报表周期用于分组和关联Agent 的展示名称或厂商策略永不变化agent_nameAgent 的显示名称适合仪表盘显示跨周期主键嵌套 user_initiated_interaction_count用户发起的 Agent App Job 启动数每次 Job 开始计一次人类发出的所有 Copilot Prompt 数session_countAgent App Session 数仅企业或组织聚合报告提供用户级条目省略每个用户的会话次数顶层 user_initiated_interaction_count其他受支持遥测中的显式 Prompt 总数报告顶层Agent App Job 启动数两个约束尤其值得写进数据模型用 agent_id 分组而不是 agent_name。显示名称可能变化同一 Agent 的多个 App 集成也会被合并到一个 Agent 条目。不要把两个同名交互计数相加。嵌套字段是 Agent App Job start顶层字段是其他遥测里的显式 Prompt它们的触发路径不同官方明确说不能互换或求和。所以“本周某 Agent 有 150 次 Job”只能说明这个受管范围内出现了 150 次用户发起的作业启动。它不能单独证明 150 个任务完成、150 次代码变更正确或 150 次调用都比人工更快。二、先选对报告粒度再谈仪表盘Usage Metrics 同时提供 1 日和 28 日报告。1 日报告适合发现刚上线的策略或集成是否产生可见活动28 日报告适合查看一个完整窗口内的聚合总量。要判断“是否在多个日期持续出现”不能只看一份 28 日用户报告它是该窗口的一条聚合记录必须保留连续的 1 日用户报告再按日期计算。目标问题推荐报告为什么新 Agent 是否真的被试点成员启动用户级 1 日报告可以按用户级记录检查是否出现对应 Agent 条目一个 Agent 是否有稳定使用而非偶发点击连续 28 份用户级 1 日报告逐日记录目标 Agent 是否出现才能计算活跃天数分布某个周期的总采用量28 日用户级报告一条记录汇总窗口内的活动适合期间比较不能还原每日出现情况企业或组织层面有多少 Agent Session聚合 1 日或 28 日报告session_count 只在聚合条目中提供新旧 Agent 是否同时被采用用户级报告按 agent_id 汇总避免按可变显示名称比较是否应该扩大、暂停或训练试点28 日量化趋势加人工样本指标提供信号任务质量仍需人审读取前先核对权限与开关。官方 REST 文档要求开启 Copilot usage metrics policy企业端通常需要企业所有者、账单经理或已授予 View Enterprise Copilot Metrics 的角色组织端也需要相应的组织权限。细粒度令牌应仅授予读取 Copilot metrics 的最小权限且专用于报告拉取。不要把组织级与企业级的返回形状想当然视为完全相同。当前文档对具体字段、用户级与聚合级的可用性有区别尤其是在组织级聚合视图中应以你当天实际拿到的 schema 为准而不是只依赖早期公告或他人的截图。三、用最小权限取回 1 日报告下面以组织的用户级 1 日报告为例。GitHub CLI 会使用本机已有的安全登录状态因此命令中不出现令牌。请在受控终端中运行并将 ORG 与 DAY 替换为真实值。ORGyour-organization DAY2026-08-07 gh api \ --method GET \ -H Accept: application/vnd.githubjson \ -H X-GitHub-Api-Version: 2026-03-10 \ /orgs/$ORG/copilot/metrics/reports/users-1-day?day$DAY该请求返回的是报告下载链接和报告日期不是整份指标内容本身。下载链接为限时签名链接适合在受控的采集作业中短暂使用不适合写入 Git、Issue、聊天记录或长期日志。只处理 API 返回的完整已处理报告日不要因为当天报告尚未生成、链接过期或采集作业失败就填充零值。对于 28 日窗口可改用 users-28-day/latest 端点取得期间聚合企业范围则使用 enterprises 下对应的 reports 路径。若要计算每日持续采用度则连续拉取并留存 28 份 users-1-day 报告。完整端点、权限与响应定义应以 GitHub REST API 文档为准。报告拉取后先把字段规范化为只含聚合分析所需列的临时数据集。下例假定 report.ndjson 是已经在受控存储中下载的报告文件jq -c (.totals_by_3rd_party_agent // [])[] | { agent_id: .agent_id, agent_name: .agent_name, job_starts: .user_initiated_interaction_count, session_count: (.session_count // null) } report.ndjson这里的空数组有明确含义某条记录没有已识别的 Agent App 活动时字段可能被省略。不要强行填成“所有 Agent 都是 0”更不要把“未识别或未上报”解释为“团队完全没有使用任何 Agent”。为了让报表审阅者一眼看出计数边界可保留如下的示意记录。数值仅用于说明字段层级不代表真实组织数据{ user_initiated_interaction_count: 137, totals_by_3rd_party_agent: [ { agent_name: Example Coding Agent, agent_id: example-coding-agent, user_initiated_interaction_count: 12 } ] }上面的 137 与 12 没有加法关系。第一项是顶层显式 Prompt 计数第二项是特定 Agent App 的 Job start。只有在数据字典明确了不同事件的来源、去重方式和业务问题后才可以把它们放在同一张分析图中比较趋势。四、为多 Agent 试点建立“可回答问题”的指标契约先确定你要用数据做什么再写公式。一个适合早期试点的最小契约可以只回答四个问题决策问题建议指标计算口径需要配套的人类证据试点是否真的开始使用活跃采用者数出现目标 agent_id 的去重成员数成员是否完成接入与培训使用是否持续28 日活跃天数分布从连续 28 份 1 日报告中计算每个 agent_id 出现的报告日数量是否只是一次演示或临时故障处置用户启动后是否形成会话聚合 Job start 与 Session 的趋势同一报告粒度内分别查看不强行一一对应代表性任务是否需要多轮协作是否应扩大范围增长趋势加任务样本仅比较相同人群、相同时间窗口代码审阅、测试、返工与安全事件复盘最后一行最重要。采用度指标可以帮助发现“谁在用什么”但无法替代质量证据。若要讨论实际工程价值至少还要从独立系统取证例如PR 是否被人工合并、测试是否通过、故障是否减少、审阅返工是否下降以及用户是否明确反馈某类任务更适合或不适合交给 Agent。建议将个人数据最小化对组织级决策默认输出按 agent_id、团队或已批准的最小群组聚合后的趋势而不是公开个人排名。对用户级报告设置明确用途、访问期限和审计记录它应服务于接入障碍排查和培训改进不应成为单一绩效指标。将原始 NDJSON、下载链接和转换后的分析数据分开存放前两者只保留在受控存储中仓库只保存查询定义与无敏感的聚合结果。五、用“1 日健康检查 每日留样 28 日聚合”做渐进决策一套低噪声的运行节奏可以分为三段阶段看什么允许的动作不该做什么上线后第 1 天目标 agent_id 是否出现、字段是否按预期省略或返回修复权限、策略、采集脚本与培训入口用一天数据评价人或采购效果第一周每日已处理报告中的 Job start 异常尖峰或完全缺失排查重复触发、集成故障、报告延迟或试点覆盖问题把峰值直接当作效率提升第一个完整 28 日窗口连续 1 日报告计算的采用持续性加上 28 日聚合、不同 Agent 重叠和代表性任务样本决定扩展试点、补培训、收紧范围或下线集成用活动数替代质量、成本或风险评审如果多个 Agent 在同一团队并行试点比较时必须固定人群和时间窗口。不要用“新 Agent 的前三天”对比“旧 Agent 的全部历史”也不要因为一个 Agent 被用于更长、更复杂的任务就把更高 Job 数判成更差体验。指标是提出问题的入口不是自动裁决。当报表出现异常时按下面顺序排查通常更快确认 Copilot usage metrics policy、角色权限与报告日期是否正确。确认目标 Agent 是否属于已识别 Agent App无法识别的活动不会出现在该数组中。确认报告日已经处理完成且采集作业没有漏跑缺失报告不是零活动。确认当前查看的是用户级还是聚合级报表避免把缺失的 session_count 当作零。核对 agent_id 是否稳定避免因显示名称变化导致同一 Agent 被拆成两条趋势。再结合任务样本与人类反馈判断这是集成问题、培训问题还是实际不适配。六、六个常见误区1按 agent_name 做长期分组显示名称可以变化。仪表盘展示用名称数据仓库关联、趋势比较和告警规则都应该使用 agent_id。2把嵌套 Job start 与顶层 Prompt 相加它们名称相似事件来源不同。相加会制造一个没有清晰业务含义的“总互动数”也会误导后续预算或采用判断。3把用户级缺少的 session_count 填成 0用户级 Agent App 条目本来就不提供这个字段。缺失意味着“该层级不可用”不是“用户没有 Session”。4把字段省略理解为绝对没有 Agent 使用该数组只覆盖已识别 Agent App。没有数组可能表示没有已识别活动也可能意味着某类集成不在这一统计范围内需要结合产品配置和其他审计来源解释。5把 Job 数量当成开发质量或个人绩效一个高质量的长任务可能只启动一次一个调试失败的任务也可能反复启动很多次。活动指标不包含正确性、审阅结果、安全影响或业务价值。6把签名下载链接和原始报告塞进仓库限时链接仍可能暴露受控数据访问路径原始报告也可能包含用户级活动。代码库应保存采集说明、字段定义和脱敏聚合而不是敏感原始材料。结语按 Agent 拆分 Usage Metrics 的意义在于让多 Agent 治理终于拥有一条可复查的采用度证据链用稳定 agent_id 观察不同 Agent用 Job start 解释用户是否启动任务用聚合 Session 观察会话形态再把这些信号与人工审阅、测试和风险复盘连接起来。正确的下一步不是立刻排名“哪个 Agent 最好”而是先为一个小试点写清数据契约看哪些字段、按什么窗口、由谁读取、缺失如何解释、什么额外证据才允许扩大范围。这样得到的报表才能服务于技术决策而不是把一串活动数字伪装成生产率结论。来源与延伸阅读Copilot usage metrics API adds agent app activityGitHub 官方公告发布于 2026-08-07说明按 Agent 聚合、字段含义、报告范围与重要限制。Data available in Copilot usage metrics当前字段定义包含 Agent App、CLI、Copilot app 与活动维度的口径。REST API endpoints for Copilot usage metrics1 日与 28 日报告端点、权限、时间窗口与下载链接行为。CSDN 标题标签AI Agent · GitHub Copilot · 多智能体 · 可观测性 · 数据治理 · 工程效能
