Qwen Code подключается к API поставщика модели через запись в файле ~/.qwen/settings.json: там указывают протокол, идентификатор модели, адрес и имя переменной окружения, в которой лежит ключ. Сам ключ в этот файл класть нежелательно, его хранят в ~/.qwen/.env или в окружении процесса. Схема годится команде, которая готова отправлять облачному поставщику отобранные фрагменты кода и принимать результат только по diff и тестам.
Куда уходит запрос
Qwen Code читает запись провайдера из settings.json, отправляет запросы по указанному baseUrl и достаёт ключ из переменной окружения, чьё имя записано в поле envKey.
Облачное подключение отличается от локального сервера с открытой моделью одним обстоятельством: всё, что агент прочитал в репозитории и включил в контекст, уходит поставщику вместе с запросом. Поэтому до первой строки настройки определите репозиторий для пробы: без файлов с секретами, без выгрузок клиентской базы, с понятным набором тестов.
Перед пробой выпишите три вещи: какие каталоги агенту открыты, какие закрыты и кто видит расход. Список хранится в репозитории рядом с README и меняется через обычный запрос на слияние. Тогда новый разработчик читает правила допуска при подключении, а владелец репозитория видит, кто и когда расширял права.
К моделям Qwen ведут два пути. Первый — сервис вендора напрямую: ключ заводят в консоли Alibaba ModelStudio, а условия оплаты и доступность из вашей страны проверяйте на странице вендора, как описано в статье про получение ключа Qwen API. Второй — открытые веса на своём или арендованном сервере, тогда читайте разбор Qwen Coder на своём сервере.
Старые инструкции про вход через браузер с бесплатным лимитом устарели: по документации Qwen Code, режим Qwen OAuth прекращён 15 апреля 2026. Актуальный вход запускается командой /auth, она записывает выбор в пользовательский файл настроек. Общее представление о возможностях агента даёт статья о Qwen Code в разработке компании.
Файл настроек
Документация описывает группу записей modelProviders: внутри неё провайдеры сгруппированы по протоколу. Поддерживаются openai (совместимые с OpenAI интерфейсы), anthropic, gemini и vertex-ai. Выбранный протокол фиксируется в security.auth.selectedType. Для облака Alibaba используют запись с протоколом, который поддерживает выбранный адрес, и значения берут из консоли поставщика.
| Поле | Что означает | Частая ошибка |
|---|---|---|
| id | Идентификатор модели из консоли поставщика | Название скопировано из старой заметки, а модель давно переименована |
| envKey | Имя переменной окружения с ключом | Вместо имени вписан сам ключ |
| baseUrl | Корень API поставщика | Взят адрес другого региона или другого плана |
| selectedType | Протокол, который выбран для работы | Запись создана, а выбран другой протокол |
Подписочные планы Alibaba Cloud живут по отдельным адресам и с отдельными ключами: ключ плана и ключ обычного API образуют разные пары, смешивать их нельзя. Если после настройки приходит ответ об отказе в доступе, первым делом сверьте пару «адрес — ключ», а уже потом меняйте модель.
Файлов настроек три основных: пользовательский ~/.qwen/settings.json, проектный .qwen/settings.json в корне проекта и системный (на Linux это /etc/qwen-code/settings.json); к ним добавляется файл системных умолчаний. Порядок приоритета по документации идёт от слабого к сильному: значения по умолчанию, файл системных умолчаний, пользовательский файл, проектный, системный, переменные окружения, флаги командной строки. Записи провайдеров документация советует держать в пользовательском файле, а проектный оставлять для переопределений, которые команда готова коммитить.
Хранение ключа
Документация перечисляет три места для ключа. Рекомендуются два: файл ~/.qwen/.env с строкой вида OPENAI_API_KEY=... либо переменная окружения, заданная через export. Третий вариант, поле env внутри settings.json, хранит ключ открытым текстом, и документация советует предпочесть первые два. Поле envKey содержит только имя переменной, а во время работы значение читается из окружения процесса.
Агент читает файлы рабочей папки, поэтому любой .env внутри репозитория потенциально попадает в контекст запроса. Qwen Code ищет .env от текущего каталога вверх и лишь затем в домашнем, поэтому файл с ключом держите в домашнем каталоге разработчика; если он всё же лежит в проекте, добавьте его в .gitignore и проверьте, что в индексе его нет. Для общей схемы с учётом расхода по людям полезен порядок из статьи про ключи и права при API-доступе команды: у каждого разработчика свой ключ, у пилота отдельный.
При увольнении сотрудника или подозрении на утечку ключ отзывают в консоли поставщика и выдают новый; без отзыва прежний продолжает работать. Журналы прогонов хранят имя окружения и название модели, но без значения ключа и без текста запросов с данными клиентов.
Кто в вашей команде отвечает за выдачу и отзыв ключей?
Тест на задаче
Для первой проверки возьмите условную задачу: функция нормализации телефона принимает строку с пробелами, скобками и дефисами и возвращает единый формат с кодом страны. Рядом лежит тест на пустую строку, ведущую восьмёрку и лишние символы. Задача мала, результат проверяется запуском, а вмешательство в соседние модули легко заметить.
- Создайте ветку и убедитесь, что рабочее дерево чистое: любая правка агента потом читается как единый diff.
- Запустите Qwen Code, выполните
/doctorдля проверки статуса входа и/model, чтобы увидеть, какая модель выбрана из вашего списка. - Переключите режим командой
/approval-mode planи попросите описать план правки. Затем перейдите в режимdefault: правки файлов потребуют вашего подтверждения. - Откройте
/diffи сверьте изменения с ожиданием: тронуты функция и её тест, формат вывода сохранён, новых зависимостей нет. - Запустите тесты сами в отдельном терминале. Зелёный отчёт агента доказательством считать нельзя.
Для одноразового запуска из скрипта есть флаги -p (задача текстом) и --approval-mode, а --model задаёт модель до старта сессии. Режимы auto-edit и yolo оставьте за пределами пилота: они снимают подтверждения, а смысл проверки как раз в них.
Типичные отклонения выглядят так: агент меняет формат вывода у соседней функции, добавляет зависимость ради одной проверки или переписывает тест под собственный результат. Последнее заметно по diff теста, когда ожидаемые значения подогнаны под ответ. Каждое отклонение возвращайте агенту замечанием в том же сеансе, а руками правьте в последнюю очередь: так видно, как модель реагирует на поправки.
Допуск в команду
Подключение считается готовым, когда выполнены четыре условия: ключ отсутствует в git diff, запись провайдера указывает на нужный адрес, задача пилота принята по тестам, а расход виден. Для последнего пункта в агенте есть /stats с разбивкой по моделям; сверяйте её с консолью поставщика, ведь итоговый учёт ведёт он.
Расширять допуск удобнее по ролям. Владелец репозитория утверждает список задач, разработчик запускает агента, ревьюер читает diff. На малом проекте три роли совпадают у одного человека, но записывайте их отдельно, чтобы ответственность осталась ясной, когда команда вырастет.
Если результат стабилен на одной задаче, расширяйте набор по типам: исправление ошибки, тест к готовой функции, переименование в нескольких файлах. Для разных типов может понадобиться разная модель, это разбирается в материале про выбор модели для Qwen Code. Ограничьте допуск репозиториями без секретов и клиентских выгрузок, а обмен инструментами через MCP-серверы подключайте отдельным шагом.
Заведите пробный ключ, запишите провайдера в пользовательский файл и прогоните одну мелкую задачу с тестом. Затем выпишите, что ушло поставщику, и покажите это владельцу репозитория. Нужна схема подключения с учётом вашей безопасности и ролей? Обсудите с нами внедрение ИИ в разработку, состав работ определим после разбора задачи.