GitHub 於 2026 年 9 月 11 日宣布，Copilot usage metrics 已在專用的 VS Code Agents 視窗正式可用。這項更新把 AI agent 的採用情況由概念變成可查詢的營運數據，讓企業可以知道團隊是否真的在使用代理，以及使用集中在哪些 agent 類型。
在 aggregate enterprise 或 organization 報告中，GitHub 新增可選欄位 daily_active_vscode_agent_users，以及按 VS Code agent 分組的 totals_by_vscode_agent。後者包括 session_count 和 total_user_messages，能回答「有幾多活躍使用者」之外，再補充「開了幾多 session」和「進行了幾多訊息互動」。
enterprise-user 和 organization-user 報告則提供使用者層級的 used_vscode_agent，以及每位使用者按 agent 分組的 totals_by_vscode_agent。這些欄位可以用來觀察採用分布和使用深度，但資料仍是使用遙測，不是對程式品質、交付速度或業務成果的直接量度。
GitHub 特別界定了統計範圍：只計算專用的 VS Code Agents 視窗，不包括 editor window 的 Agent Mode，也不包括一般 Copilot rollup。欄位屬於 optional，歷史資料未提供時可以缺少或回傳 null。這種向後兼容做法，提醒報告消費者不要把空值誤當成零，也不要把不同介面的數字直接相加。
存取權限由 enterprise owners、billing managers、organization owners，或具有 View Copilot Metrics 權限的 custom role 管理；同時需要啟用相關 policy。企業若要把數據接入內部 dashboard，應先確認報告層級、角色權限、欄位版本和匯出週期，避免在權限或 schema 改變後悄悄產生錯誤趨勢。
採用數字本身不能證明代理有效。session 多，可能代表任務多，也可能代表反覆重試；訊息多，可能代表深度協作，也可能代表提示不清或輸出不可靠。較完整的評估應把使用數據與 pull request 結果、review 抽樣、任務完成時間、成本、缺陷和人工介入一起看，並清楚定義每一項指標的分母。
治理層面亦要先講清楚誰可以看 user-level 數據、保留多久、哪些用途獲得批准，以及如何區分管理分析與員工監察。聚合數字有助於降低不必要的個人追蹤，但企業仍要處理內部定義、資料保留和存取審計。尤其不能只用一個 daily active user 數字，就對外宣稱生產力提升。
這次更新的意義，在於 agent rollout 開始需要像其他生產系統一樣有 instrumentation。成熟做法應同時量度 adoption、workflow outcome、quality and risk，並在變更 agent、模型或權限後保留可比較的基線。GitHub 提供的是一組實用的使用入口；怎樣把它變成可信的工程和管理決策，仍取決於企業自己的量度設計。
