Qwen Code работает с GitHub в двух видах: на компьютере разработчика, где агент правит локальную копию репозитория, и в GitHub Actions через отдельное действие qwen-code-action, которое разбирает issue и проверяет pull request по упоминанию @qwencoder. Первый вид безопаснее для старта, второй даёт автоматизацию, но требует секретов и ограниченных прав. Слияние в основную ветку остаётся за человеком в обоих случаях.
Два контура
Локальный контур даёт правки в вашей копии репозитория, а контур Actions добавляет ревью pull request и разбор issue по комментарию @qwencoder /review или @qwencoder /triage.
Общее представление о возможностях агента даёт статья про Qwen Code в разработке компании. Здесь разбирается связка с GitHub: что агент делает на локальной копии, что на сервере Actions и где между ними проходит граница прав. Для сравнения подхода, при котором ветку и pull request ведёт другой агент, пригодится разбор Claude Code GitHub с веткой, тестами и ревью.
Локальный контур выглядит привычно: разработчик клонирует репозиторий, запускает qwen в рабочей папке, ставит задачу и получает правки в файлах. Ветку создаёт и отправляет сам разработчик обычными командами Git, а pull request открывает от своего имени. Агент тут инструмент в руках человека, и вся ответственность за коммиты остаётся на нём.
Контур Actions устроен иначе. Рабочий процесс GitHub запускается по событию или комментарию, поднимает Qwen Code на раннере GitHub и отвечает прямо в обсуждении. Данные issue и diff уходят провайдеру модели из настроек процесса, а права определяются токеном рабочего процесса. Разбирать такое устройство нужно до первого запуска.
Настройка репозитория
Сведения о настройке взяты из репозитория qwen-code-action; версии и названия параметров там могут меняться, поэтому сверяйтесь с актуальным описанием. Для работы нужен секрет с ключом модели, по описанию проекта — QWEN_API_KEY, а необязательный секрет APP_PRIVATE_KEY нужен для варианта с собственным GitHub App. Рабочие процессы лежат в каталоге .github/workflows репозитория.
- Создайте тестовый репозиторий или форк без закрытого кода. Все первые прогоны делайте именно там.
- Сохраните ключ модели как секрет репозитория
QWEN_API_KEYв настройках безопасности GitHub. В файлах проекта и в переписке ему делать нечего. - Добавьте в
.gitignoreкаталог.qwen/и файлы видаgha-creds-*.json, как советует описание действия, чтобы рабочие данные агента остались за пределами коммита. - Запустите команду
/setup-githubв терминале Qwen Code либо вручную скопируйте примеры рабочих процессов из каталогаexamples/workflowsпроекта. Прочитайте каждый файл целиком перед коммитом. - Откройте тестовый pull request с небольшой правкой и вызовите ревью комментарием. Проверьте, что ответ появился и права рабочего процесса соответствуют ожиданиям.
Файл QWEN.md в корне проекта по описанию используется для проектных инструкций. Запишите там порядок проверки, принятые соглашения по коду и запретные зоны, а затем сверьте поведение агента с этим файлом на тестовых задачах.
Права и секреты
Рабочий процесс GitHub получает токен, права которого описаны в самом файле процесса. Это главный регулятор. Запись в содержимое репозитория, создание комментариев и работа с pull request разрешаются отдельными пунктами, и каждый стоит выдавать, только если он нужен. Для ревью обычно достаточно чтения кода и права оставлять комментарии.
- Начинайте с минимальных прав: чтение содержимого плюс комментарии в issue и pull request. Запись в ветки добавляйте после разбора первых результатов.
- Включите защиту основной ветки: обязательные проверки, обязательное одобрение человеком и запрет прямых отправок. Тогда сбой агента остановится задолго до релиза.
- Ограничьте, кто может вызывать агента упоминанием. Если комментарии доступны посторонним, текст чужого issue превращается в инструкцию для модели.
- Запрещайте выдачу секретов процессам, которые запускаются на pull request из форков: чужой код получит ваш ключ.
- Раз в квартал просматривайте процессы и журнал запусков: кто вызывал агента, какие права были у токена, куда уходили данные.
Отдельный риск — внедрение инструкций через текст. Тело issue или комментарий к pull request пишет любой участник, а агент читает его как рабочую задачу. Поэтому исполнение команд из такого текста нельзя разрешать без подтверждения, а выводы агента по чужим обращениям читает ответственный сотрудник. Доступ к репозиторию для обычных агентов подробно разбирает статья про MCP GitHub и границы прав.
Review и триаж
Две основные задачи действия — ревью pull request и триаж issue. Ревью означает, что агент читает diff и пишет замечания: возможные ошибки, пропущенные проверки, странные места. Триаж означает, что агент разбирает новое обращение, предлагает метку и уточняющие вопросы. Оба результата носят характер совета, поэтому их принимают так же, как комментарий коллеги.
| Задача | Как вызвать | Что решает человек |
|---|---|---|
| Ревью pull request | Комментарий @qwencoder /review или запуск по событию из вашего процесса | Какие замечания верны и что менять в коде |
| Триаж issue | Комментарий @qwencoder /triage или запуск по событию создания | Метки, приоритет, исполнитель |
| Свободный запрос | Упоминание @qwencoder с описанием задачи | Допустимость задачи и проверка результата |
Замечания агента сверяйте с кодом: модель способна упрекнуть вас в ошибке, которой нет, либо пропустить настоящую. Хороший порядок такой: сначала запускают обычные тесты и линтер, затем читают замечания агента, после этого ревью проводит человек. Агентское ревью дополняет человеческое и тестовое, а подменять собой любое из них нельзя.
На каком репозитории вы бы проверили ревью pull request агентом?
Полезно заранее решить, как читать замечания агента в больших pull request. Модель видит diff и выбранные файлы, а контекст всего проекта у неё ограничен, поэтому замечания о соседних модулях проверяйте особенно внимательно. Дополнительная польза — стабильный формат ответа: если в QWEN.md описаны категории замечаний, ревьюеру проще пробегать по ним и отмечать, какие приняты, какие отклонены и по какой причине.
Следите и за расходом. Каждый запуск обращается к интерфейсу модели, расход идёт по вашему ключу, а частые запуски на каждый коммит быстро накапливают токены. Условия расхода смотрите на странице провайдера ключа; в пилоте ограничьте запуск ручным вызовом комментарием.
Допуск к слиянию
Правило процесса простое: агент вправе предлагать, а сливает человек. Для этого опираются на защиту ветки в GitHub вместо личной дисциплины. Обязательные проверки включают сборку и тесты, одобрение даёт назначенный ревьюер, прямая отправка в основную ветку запрещена всем, включая администраторов. Любой сбой агента тогда остановится на этапе pull request.
Отдельно решите, кто отвечает за ключ и за рабочие процессы. У ключа есть владелец, у каталога процессов — ревьюеры изменений, поскольку правка файла процесса меняет права агента. Договорённость о разборе спорных замечаний тоже полезно записать: чьё слово решает, если агент и разработчик расходятся.
Для первого пилота подходит короткий список критериев. Агент оставил замечание по делу хотя бы в части pull request. Лишние замечания занимают малую долю и легко отличимы. Все запуски уложились в выданные права. Расход за неделю укладывается в ожидания владельца бюджета. Если хотя бы один пункт провален, возвращайтесь к ручному вызову и урезайте права, а подключение новых репозиториев откладывайте.
Начните с локального контура на тестовом репозитории: одна задача, ветка, тесты, ваш собственный pull request. Когда процесс отработан, добавьте действие с правом только на комментарии и ручным вызовом. Правила защиты веток и права процессов можно собрать вместе с нами: ИИ-агенты для разработки.