Гайд · TNWS AI
Как создать custom agent для тестов в GitHub Copilot
Создание профиля custom agent в .github/agents: YAML frontmatter, tools, точные ограничения тестового агента и проверка результата.
Проверено 13 сентября 2026 года. Этот материал решает конкретную задачу: сделать отдельного агента, который анализирует покрытие и меняет тесты, но не переписывает production-код. Все команды, пути и названия элементов интерфейса ниже сверены с официальной документацией GitHub на дату проверки. Функции со статусом preview могут измениться, поэтому перед внедрением в рабочий процесс повторно откройте первоисточник.
Когда этот сценарий действительно нужен
Используйте подход, когда задача повторяется, имеет проверяемый результат и требует заранее ограничить область действий агента. Он особенно полезен для репозитория, где изменения проходят через pull request, тесты и ревью. Не начинайте с широкого поручения «улучши проект»: зафиксируйте один наблюдаемый результат, допустимые файлы, запрещённые действия и способ проверки.
Практический ориентир: Профиль custom agent — Markdown с YAML frontmatter. Репозиторный файл создаётся в .github/agents и получает суффикс .agent.md. description обязателен; tools ограничивает инструменты, а при отсутствии поля доступны все инструменты. После merge в default branch агент появляется в выборе Agents.
Перед началом сохраните чистое состояние ветки, убедитесь, что тестовый пример не содержит реальных секретов, и выберите небольшой репозиторий или отдельную ветку. GitHub Copilot ускоряет действия, но не заменяет контроль прав, review diff и проверку фактического результата.
Подготовка рабочего примера
Создайте тестовую задачу, по которой можно однозначно сказать «выполнено» или «не выполнено». Запишите исходное состояние: ветку, команду git status --short, относящиеся файлы и одну команду проверки. Если работа происходит в интерфейсе GitHub, заранее создайте отдельный issue или pull request без чувствительных данных. Не используйте production-token в тексте prompt, issue, комментарии или session log.
Определите границы в четырёх строках: цель; разрешённые файлы или действия; прямые запреты; проверка. Такая структура снижает риск красивого, но непроверяемого результата. Для примера этой статьи исходная задача выглядит так:
Добавь регрессионный тест: POST /orders без customerId должен возвращать 400 и код
CUSTOMER_REQUIRED.
Пошаговая настройка
- Откройте
github.com/copilot/agents, выберите репозиторий в dropdown под prompt box. - Через меню выберите Create an agent: GitHub создаст
.github/agents/my-agent.agent.md. - Переименуйте файл в
test-specialist.agent.mdи задайте name, description, минимальный список tools. - В Markdown-инструкции перечислите допустимые файлы, критерии теста и обязательные команды проверки.
- Закоммитьте профиль, слейте в default branch, обновите Agents и выберите нового агента для тестовой задачи.
После каждого значимого шага проверяйте не только сообщение агента, но и состояние системы: содержимое файла, список разрешений, session log, diff или метки issue. Успешная фраза в интерфейсе не доказывает, что ограничение действительно сработало.
Готовый шаблон для копирования
Скопируйте шаблон и замените только предметную часть. Не удаляйте ограничения и блок проверки, пока не получите стабильный результат на тестовом кейсе.
---
name: test-specialist
description: Добавляет и исправляет тесты, не меняя production-код.
tools: ["read", "search", "edit"]
---
Работай только с тестовыми файлами и тестовой документацией.
Сначала найди наблюдаемое поведение и существующий стиль тестов.
Добавляй минимум один позитивный и один негативный сценарий.
Не меняй src/, зависимости и CI без прямого разрешения.
В финале перечисли изменённые файлы, команды и фактический результат проверок.
Если в шаблоне указан путь, команда или имя label, они должны существовать в вашем репозитории. Не просите модель «догадаться» о названии теста или utility, когда это можно проверить поиском по коду. Любое разрешение на изменение стоит связывать с узкой папкой или типом объекта.
Реалистичный вход и ожидаемый результат
Вход: Добавь регрессионный тест: POST /orders без customerId должен возвращать 400 и код CUSTOMER_REQUIRED.
Ожидаемый результат: Агент находит существующий набор API-тестов, добавляет сценарий отсутствующего customerId, не меняет обработчик и сообщает конкретную команду запуска.
Сравнивайте результат по наблюдаемым признакам. Для файловой задачи это состав diff и exit code теста; для настройки — фактический effective policy; для GitHub UI — созданная session, выбранные tools, label или связанный pull request. Формулировка «вроде сработало» не годится для приёмки.
Как провести негативный тест
Если агенту требуется исправить production-код, он должен остановиться и описать блокер. Такой результат подтверждает границу роли, а не является провалом агента.
Негативный тест нужен до распространения настройки на команду. Он должен пытаться нарушить ровно одну границу: изменить запрещённый файл, обратиться к сети, исполнить текст как команду, добавить лишнюю метку или расширить diff. Хорошая конфигурация либо блокирует действие, либо требует явного подтверждения, либо останавливается и объясняет ограничение.
Сохраните результат негативного теста рядом с документацией процесса: исходный prompt, дату, ожидаемое ограничение, фактическое поведение и решение. Это помогает повторить аудит после обновления Copilot или GitHub CLI.
Проверка безопасности и качества
Принцип минимальных прав важнее удобства первого запуска. Разрешайте только те tools, каталоги и сетевые направления, без которых задача действительно не выполняется. Не вставляйте секреты в prompt: сообщения, журналы сессии, issue и pull request могут быть доступны другим участникам репозитория в соответствии с настройками GitHub.
Перед merge прочитайте весь diff. Проверьте новые зависимости, workflow, конфигурацию, lock-файлы, скрипты и обращения к сети. Запускайте узкие тесты, связанные с изменением, а затем обязательный набор проекта. Если агент сообщает о тесте, убедитесь, что в логе есть точная команда и успешный код завершения, а не только пересказ.
Для preview-возможностей заведите владельца настройки и дату следующей проверки документации. Не фиксируйте цены или квоты в постоянной инструкции: они меняются. В этой статье наличие и статус функций проверены 13 сентября 2026 года; актуальные условия следует смотреть по ссылкам ниже.
Чек-лист финальной проверки
- Цель описана одним измеримым результатом.
- Указаны допустимые файлы, объекты или действия.
- Явно перечислены запрещённые действия.
- Команды, пути и названия UI сверены с официальной документацией.
- В prompt и тестовых данных нет токенов, паролей и персональных данных.
- Выданы только минимально необходимые permissions или tools.
- Исходное состояние ветки или объекта сохранено.
- Выполнен позитивный тест на реалистичном входе.
- Выполнен негативный тест на нарушение одной границы.
- Проверен фактический diff, log, policy или набор labels.
- Записана точная команда проверки и её exit code.
- Не появились неожиданные зависимости, workflow или сетевые обращения.
- Результат прошёл человеческое ревью.
- Для preview-функции назначена дата повторной сверки документации.
Частые вопросы
Можно ли считать сообщение Copilot доказательством успешной настройки?
Нет. Проверяйте внешний результат: файл и diff, вывод команды, effective policy, session log, label или pull request. Текстовый отчёт агента — только указатель, а не доказательство.
Нужно ли давать агенту все доступные tools для надёжности?
Нет. Избыточные инструменты увеличивают область возможной ошибки. Начните с минимального набора и добавляйте разрешение только после воспроизводимого блокера.
Где хранить секрет, если он нужен задаче?
Не помещайте его в prompt, issue или комментарий. Используйте поддерживаемый механизм secrets для выбранного окружения и ограничьте доступ конкретной задачей. Логи также проверяйте на случайный вывод значения.
Что делать, если интерфейс или команда отличаются от статьи?
Остановитесь и откройте официальный источник. Функция могла измениться после 13 сентября 2026 года, особенно если помечена preview или experimental. Не подбирайте похожую кнопку наугад.
Как понять, что инструкция слишком широкая?
Признаки: агент меняет несвязанные файлы, устанавливает пакеты без необходимости, создаёт новые архитектурные слои или не может назвать точную проверку. Сузьте цель, область файлов и критерии приёмки.
Официальные источники
Источники проверены 13 сентября 2026 года. Текст выше является самостоятельной практической инструкцией и не заменяет чтение актуальных требований GitHub для вашей организации и плана.
Читайте также
Как безопасно настроить allowed-tools в GitHub Copilot Agent Skill
Практическая настройка allowed-tools для Agent Skill: минимальные разрешения, shell-риски, проверка скрипта и негативный тест.
Как ограничить файлы и сеть в sandbox GitHub Copilot CLI
Настройка вкладок Filesystem и Network в /sandbox: Read-Only, Denied, отключение локальной сети и проверка effective policy.
Как создать Agent Skill для GitHub Copilot в репозитории
Практический гайд по созданию проектного Agent Skill: структура каталога, SKILL.md, frontmatter, сценарий проверки и безопасные ограничения.
Комментарии
Пока тихо. Скажите первое слово