Гайд · TNWS AI
Как запустить agent app из issue и pull request в GitHub
Установка и запуск GitHub Copilot agent app через Assignees, PR-комментарий и Agents UI с проверкой OAuth и области доступа.
Проверено 13 сентября 2026 года. Этот материал решает конкретную задачу: делегировать партнёрскому агенту узкую задачу из issue или комментария к pull request и проконтролировать доступ приложения. Все команды, пути и названия элементов интерфейса ниже сверены с официальной документацией GitHub на дату проверки. Функции со статусом preview могут измениться, поэтому перед внедрением в рабочий процесс повторно откройте первоисточник.
Когда этот сценарий действительно нужен
Используйте подход, когда задача повторяется, имеет проверяемый результат и требует заранее ограничить область действий агента. Он особенно полезен для репозитория, где изменения проходят через pull request, тесты и ревью. Не начинайте с широкого поручения «улучши проект»: зафиксируйте один наблюдаемый результат, допустимые файлы, запрещённые действия и способ проверки.
Практический ориентир: Agent apps находятся в public preview. GitHub App сначала устанавливается через Marketplace кнопкой Add; при первом использовании проходит OAuth-авторизация. Запуск возможен из Agents UI, назначением в Assignees у issue или упоминанием @AGENT-NAME в PR-комментарии.
Перед началом сохраните чистое состояние ветки, убедитесь, что тестовый пример не содержит реальных секретов, и выберите небольшой репозиторий или отдельную ветку. GitHub Copilot ускоряет действия, но не заменяет контроль прав, review diff и проверку фактического результата.
Подготовка рабочего примера
Создайте тестовую задачу, по которой можно однозначно сказать «выполнено» или «не выполнено». Запишите исходное состояние: ветку, команду git status --short, относящиеся файлы и одну команду проверки. Если работа происходит в интерфейсе GitHub, заранее создайте отдельный issue или pull request без чувствительных данных. Не используйте production-token в тексте prompt, issue, комментарии или session log.
Определите границы в четырёх строках: цель; разрешённые файлы или действия; прямые запреты; проверка. Такая структура снижает риск красивого, но непроверяемого результата. Для примера этой статьи исходная задача выглядит так:
В PR добавлен новый checkout, но команда хочет проверить, что он включается только при
new_checkout=trueи старый путь остаётся доступен.
Пошаговая настройка
- Откройте страницу agent app в GitHub Marketplace, нажмите Add и выберите только нужный account или organization.
- На установке ограничьте список repositories, если приложение не требуется повсеместно.
- Для issue откройте Assignees и назначьте agent app; для PR добавьте комментарий с упоминанием из autocomplete.
- При первом запуске внимательно пройдите OAuth flow и проверьте запрашиваемые разрешения.
- Откройте созданную agent session, просмотрите лог и итоговый diff; не принимайте результат без обычного code review.
После каждого значимого шага проверяйте не только сообщение агента, но и состояние системы: содержимое файла, список разрешений, session log, diff или метки issue. Успешная фраза в интерфейсе не доказывает, что ограничение действительно сработало.
Готовый шаблон для копирования
Скопируйте шаблон и замените только предметную часть. Не удаляйте ограничения и блок проверки, пока не получите стабильный результат на тестовом кейсе.
@AGENT-NAME проверь этот pull request только на корректность feature flag new_checkout.
Не меняй публичный API и зависимости.
Если флаг обходится хотя бы в одном пути выполнения, предложи минимальный patch.
Запусти существующие checkout-тесты.
В ответе перечисли найденные пути, изменённые файлы и результат тестов.
Если в шаблоне указан путь, команда или имя label, они должны существовать в вашем репозитории. Не просите модель «догадаться» о названии теста или utility, когда это можно проверить поиском по коду. Любое разрешение на изменение стоит связывать с узкой папкой или типом объекта.
Реалистичный вход и ожидаемый результат
Вход: В PR добавлен новый checkout, но команда хочет проверить, что он включается только при new_checkout=true и старый путь остаётся доступен.
Ожидаемый результат: Agent app отвечает в PR, создаёт связанную сессию, анализирует оба пути, при необходимости предлагает ограниченный diff и прикладывает результат существующих тестов.
Сравнивайте результат по наблюдаемым признакам. Для файловой задачи это состав diff и exit code теста; для настройки — фактический effective policy; для GitHub UI — созданная session, выбранные tools, label или связанный pull request. Формулировка «вроде сработало» не годится для приёмки.
Как провести негативный тест
Партнёрский агент получает контекст через установленное приложение. Перед установкой проверьте publisher, permissions и выбранные repositories; после задачи удалите лишний доступ.
Негативный тест нужен до распространения настройки на команду. Он должен пытаться нарушить ровно одну границу: изменить запрещённый файл, обратиться к сети, исполнить текст как команду, добавить лишнюю метку или расширить 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 для вашей организации и плана.
Читайте также
Как архивировать остановленную сессию Copilot cloud agent
Пошаговое архивирование stopped-сессии Copilot cloud agent без потери pushed commits и с предварительной проверкой pull request.
Как найти прошлую сессию Copilot по естественному запросу
Поиск синхронизированных Copilot-сессий по смыслу: условия remoteExport, точные запросы, проверка владельца и восстановление контекста.
Как безопасно настроить allowed-tools в GitHub Copilot Agent Skill
Практическая настройка allowed-tools для Agent Skill: минимальные разрешения, shell-риски, проверка скрипта и негативный тест.
Комментарии
Пока тихо. Скажите первое слово