GitHub расширил Usage Metrics API для Copilot: в отчётах появились данные об использовании агентных настроек и расширений командной строки. Речь идёт о навыках (skills), пользовательских агентах, серверах Model Context Protocol, слеш-командах и плагинах Copilot CLI.
Обновление ориентировано прежде всего на администраторов корпоративных и организационных аккаунтов. Они смогут оценивать, какие инструменты действительно вошли в рабочий процесс разработчиков, а какие были подключены, но не получили заметного распространения.
GitHub сообщил об изменениях 17 сентября 2026 года в официальном журнале обновлений. Компания не анонсировала новый пользовательский интерфейс: речь идёт именно о расширении данных, доступных через API.
В каких отчётах появились новые поля
По данным GitHub, сведения об агентных CLI-кастомизациях добавлены сразу в несколько вариантов отчётности:
— персональные и агрегированные отчёты за один день;
— персональные отчёты за 28 дней;
— записи `day_totals` в агрегированных отчётах за 28 дней.
Персональные отчёты описывают активность конкретного пользователя, а агрегированные позволяют рассматривать те же показатели на уровне организации или корпоративного аккаунта. Таким образом, администратор может изучать как общую динамику внедрения, так и распределение активности между пользователями.
GitHub связывает новые поля с двумя практическими задачами: определением кастомизаций, которые набирают популярность, и поиском пробелов во внедрении. Например, данные могут показать, что подключённый MCP-сервер или пользовательский агент почти не задействован командой. Само по себе это не объясняет причину: низкая активность может быть связана с недостатком обучения, неудобной настройкой, ограниченным кругом задач или тем, что инструмент просто не нужен разработчикам.
Схемы ответов, правила доступа и названия полей следует проверять в актуальном разделе REST API для GitHub Copilot. GitHub развивает отчётность Copilot, поэтому при интеграции лучше опираться на текущую версию документации, а не фиксировать структуру ответа только по анонсу.
Какие расширения Copilot CLI охватывает API
Обновление распространяется на пять типов кастомизаций. GitHub перечисляет навыки, пользовательских агентов, MCP-серверы, слеш-команды и плагины. Все они позволяют адаптировать Copilot CLI под процессы конкретной команды, но решают разные задачи.
Навыки задают специализированные инструкции или рабочие сценарии. Пользовательские агенты предназначены для выполнения определённых классов задач с заданными настройками. MCP-серверы подключают к агенту внешние инструменты и источники контекста через Model Context Protocol. Слеш-команды предоставляют короткий способ запуска предусмотренных действий, а плагины расширяют доступную функциональность.
Для компаний это не просто перечень технических возможностей. Каждый такой компонент может требовать разработки, проверки, сопровождения, настройки прав доступа и обучения сотрудников. До появления детализированных метрик администраторам было сложнее сопоставлять эти затраты с фактическим использованием внутри Copilot CLI.
При этом GitHub не утверждает, что API непосредственно измеряет экономический эффект или качество результата. Частота использования показывает распространённость инструмента, но не доказывает, что он ускоряет разработку, сокращает число ошибок или окупает затраты на поддержку. Для такой оценки данные API придётся сопоставлять с внутренними показателями команды.
Общая документация по возможностям и настройке продукта доступна в разделе GitHub Copilot. Она нужна в том числе для проверки того, какие функции доступны в конкретном тарифе и корпоративной конфигурации.
Что администраторы смогут проверить на практике
Первый сценарий — сравнить внедрение нескольких кастомизаций. Если организация создала несколько агентов для разных команд, отчёты помогут увидеть, какие из них используются регулярно, а какие остались экспериментальными.
Второй сценарий — проверить распространение внутреннего инструмента. Допустим, компания подключила MCP-сервер для поиска по документации или обращения к корпоративной системе. Низкая активность станет поводом проверить доступность сервера, права пользователей, инструкции по запуску и соответствие инструмента реальным задачам. Однако делать вывод о технической неисправности только на основании слабого использования нельзя.
Третий сценарий — планировать поддержку. Популярную автоматизацию можно включить в стандартную конфигурацию, документировать и распространить на другие команды. Невостребованный компонент, напротив, стоит сначала исследовать: поговорить с пользователями, проверить журнал ошибок и выяснить, был ли он вообще доступен предполагаемой аудитории.
Отчёты за один день подходят для наблюдения за недавними изменениями или запуском пилота. Окно в 28 дней полезнее для оценки устойчивого использования, поскольку снижает влияние выходных, отпусков и краткосрочных экспериментов. Но GitHub в анонсе не предлагает универсального порога, после которого кастомизацию следует считать успешной: такой критерий организациям придётся задавать самостоятельно.
Какие выводы из обновления делать рано
Анонс относится к активности в Copilot CLI. Из него нельзя автоматически заключить, что аналогичная детализация уже доступна для всех остальных интерфейсов Copilot, включая среды разработки. Если один и тот же рабочий сценарий используется через несколько каналов, CLI-отчёт может отражать только часть общей картины.
Также новые метрики не являются оценкой качества агентов. Большое число обращений иногда указывает на полезность инструмента, но может означать и повторные попытки после неудачных результатов. Для проверки качества нужны дополнительные данные: успешность выполнения задач, обратная связь разработчиков, ошибки интеграций и время, затраченное на исправление результата.
Администраторам перед подключением отчётности стоит проверить четыре вещи: наличие новых полей в используемом типе отчёта, права доступа к API, правила хранения персональных данных и внутренние критерии успешного внедрения. Отдельно следует убедиться, что названия агентов, плагинов и MCP-серверов позволяют однозначно различать их в аналитике.
Пока GitHub подтвердил расширение охвата Usage Metrics API, но не представил в анонсе независимую оценку точности данных или влияния новых отчётов на производительность команд. Поэтому разумный первый шаг — снять базовые показатели за 28 дней, зафиксировать изменения в конфигурации и лишь затем сравнивать динамику использования.