Skip to Content
CLIКонфигурация (v1)

Конфигурация Qwen Code

Qwen Code предоставляет несколько способов настройки своего поведения, включая переменные окружения, аргументы командной строки и файлы настроек. В этом документе описаны различные методы конфигурации и доступные параметры.

Уровни конфигурации

Конфигурация применяется в следующем порядке приоритета (параметры с меньшими номерами переопределяются параметрами с большими номерами):

  1. Значения по умолчанию: Жестко закодированные значения по умолчанию внутри приложения.
  2. Файл системных настроек по умолчанию: Системные настройки по умолчанию, которые могут быть переопределены другими файлами настроек.
  3. Файл пользовательских настроек: Глобальные настройки для текущего пользователя.
  4. Файл настроек проекта: Настройки, специфичные для проекта.
  5. Файл системных настроек: Системные настройки, которые переопределяют все остальные файлы настроек.
  6. Переменные окружения: Системные или специфичные для сессии переменные, потенциально загружаемые из файлов .env.
  7. Аргументы командной строки: Значения, передаваемые при запуске CLI.

Файлы настроек

Qwen Code использует JSON-файлы настроек для постоянного хранения конфигурации. Эти файлы могут находиться в четырех местах:

  • Файл системных значений по умолчанию:

    • Расположение: /etc/qwen-code/system-defaults.json (Linux), C:\ProgramData\qwen-code\system-defaults.json (Windows) или /Library/Application Support/QwenCode/system-defaults.json (macOS). Путь можно переопределить с помощью переменной окружения QWEN_CODE_SYSTEM_DEFAULTS_PATH.
    • Область применения: Предоставляет базовый уровень системных настроек по умолчанию. Эти настройки имеют самый низкий приоритет и предназначены для переопределения пользовательскими, проектными или системными настройками.

  • Файл пользовательских настроек:

    • Расположение: ~/.qwen/settings.json (где ~ — ваша домашняя директория).
    • Область применения: Применяется ко всем сессиям Qwen Code текущего пользователя.

  • Файл настроек проекта:

    • Расположение: .qwen/settings.json в корневой директории вашего проекта.
    • Область применения: Применяется только при запуске Qwen Code из этого конкретного проекта. Настройки проекта переопределяют пользовательские настройки.

  • Файл системных настроек:

    • Расположение: /etc/qwen-code/settings.json (Linux), C:\ProgramData\qwen-code\settings.json (Windows) или /Library/Application Support/QwenCode/settings.json (macOS). Путь можно переопределить с помощью переменной окружения QWEN_CODE_SYSTEM_SETTINGS_PATH.
    • Область применения: Применяется ко всем сессиям Qwen Code в системе, для всех пользователей. Системные настройки переопределяют пользовательские и проектные настройки. Может быть полезно системным администраторам в корпоративной среде для управления установками Qwen Code у пользователей.

Примечание о переменных окружения в настройках: Строковые значения в ваших файлах settings.json могут ссылаться на переменные окружения, используя синтаксис $VAR_NAME или ${VAR_NAME}. Эти переменные будут автоматически разрешены при загрузке настроек. Например, если у вас есть переменная окружения MY_API_TOKEN, вы можете использовать её в settings.json следующим образом: "apiKey": "$MY_API_TOKEN".

Каталог .qwen в вашем проекте

Помимо файла настроек проекта, каталог .qwen может содержать другие файлы, относящиеся к работе Qwen Code, например:

Доступные настройки в settings.json:

  • contextFileName (строка или массив строк):

    • Описание: Указывает имя файла для контекстных файлов (например, QWEN.md, AGENTS.md). Может быть как одно имя файла, так и список допустимых имен.
    • По умолчанию: QWEN.md
    • Пример: "contextFileName": "AGENTS.md"

  • bugCommand (объект):

    • Описание: Переопределяет URL по умолчанию для команды /bug.
    • По умолчанию: "urlTemplate": "https://github.com/QwenLM/qwen-code/issues/new?template=bug_report.yml&title={title}&info={info}"
    • Свойства:
      • urlTemplate (строка): URL, который может содержать плейсхолдеры {title} и {info}.
    • Пример: 
      "bugCommand": {
  "urlTemplate": "https://bug.example.com/new?title={title}&info={info}"
}

  • fileFiltering (объект):

    • Описание: Управляет поведением фильтрации файлов с учетом Git для команд @ и инструментов поиска файлов.
    • По умолчанию: "respectGitIgnore": true, "enableRecursiveFileSearch": true
    • Свойства:
      • respectGitIgnore (boolean): Определяет, следует ли учитывать шаблоны из .gitignore при поиске файлов. Если установлено значение true, то файлы, игнорируемые Git (например, node_modules/, dist/, .env), автоматически исключаются из команд @ и операций вывода списка файлов.
      • enableRecursiveFileSearch (boolean): Включает рекурсивный поиск файлов в текущем дереве каталогов при автодополнении префиксов @ в prompt’е.
      • disableFuzzySearch (boolean): Если true, отключает нечеткий поиск файлов, что может повысить производительность в проектах с большим количеством файлов.
    • Пример: 
      "fileFiltering": {
  "respectGitIgnore": true,
  "enableRecursiveFileSearch": false,
  "disableFuzzySearch": true
}

Устранение проблем с производительностью поиска файлов

Если вы сталкиваетесь с проблемами производительности при поиске файлов (например, при использовании автодополнения с @), особенно в проектах с очень большим количеством файлов, попробуйте следующие решения в порядке рекомендации:

  1. Используйте .qwenignore: Создайте файл .qwenignore в корне вашего проекта, чтобы исключить директории, содержащие большое количество файлов, на которые вы не ссылаетесь (например, build-артефакты, логи, node_modules). Снижение общего количества сканируемых файлов — это самый эффективный способ улучшить производительность.

  2. Отключите нечеткий поиск: Если игнорирование файлов не помогает, вы можете отключить нечеткий поиск, установив disableFuzzySearch в true в вашем файле settings.json. Это будет использовать более простой алгоритм поиска без нечеткого соответствия, который может работать быстрее.

  3. Отключите рекурсивный поиск файлов: В крайнем случае вы можете полностью отключить рекурсивный поиск файлов, установив enableRecursiveFileSearch в false. Это будет самым быстрым вариантом, так как избежит рекурсивного обхода проекта. Однако это означает, что при использовании автодополнения с @ вам нужно будет вводить полный путь к файлам.

  • coreTools (массив строк):

    • Описание: Позволяет указать список имен встроенных инструментов, которые должны быть доступны модели. Это можно использовать для ограничения набора встроенных инструментов. См. Встроенные инструменты для списка доступных инструментов. Также можно указать ограничения для конкретных команд для инструментов, поддерживающих это, например, ShellTool. Например, "coreTools": ["ShellTool(ls -l)"] разрешит выполнение только команды ls -l.
    • По умолчанию: Все инструменты доступны для использования моделью.
    • Пример: "coreTools": ["ReadFileTool", "GlobTool", "ShellTool(ls)"].

  • allowedTools (массив строк):

    • По умолчанию: undefined
    • Описание: Список имен инструментов, для которых будет пропущен диалог подтверждения. Полезно для инструментов, которым вы доверяете и используете часто. Логика сопоставления такая же, как и у coreTools.
    • Пример: "allowedTools": ["ShellTool(git status)"].

  • excludeTools (массив строк):

    • Описание: Позволяет указать список имен встроенных инструментов, которые должны быть исключены из модели. Инструмент, указанный и в excludeTools, и в coreTools, будет исключен. Также можно указать ограничения для конкретных команд для инструментов, поддерживающих это, например, ShellTool. Например, "excludeTools": ["ShellTool(rm -rf)"] заблокирует команду rm -rf.
    • По умолчанию: Никакие инструменты не исключены.
    • Пример: "excludeTools": ["run_shell_command", "findFiles"].
    • Примечание по безопасности: Ограничения для конкретных команд в excludeTools для run_shell_command основаны на простом сопоставлении строк и могут быть легко обойдены. Эта функция не является механизмом безопасности и не должна использоваться для безопасного выполнения недоверенного кода. Рекомендуется использовать coreTools для явного выбора команд, которые могут быть выполнены.

  • allowMCPServers (массив строк):

    • Описание: Позволяет указать список имен MCP-серверов, которые должны быть доступны модели. Это можно использовать для ограничения набора MCP-серверов, к которым можно подключаться. Обратите внимание, что этот параметр будет проигнорирован, если установлен флаг --allowed-mcp-server-names.
    • По умолчанию: Все MCP-серверы доступны для использования моделью.
    • Пример: "allowMCPServers": ["myPythonServer"].
    • Примечание по безопасности: Используется простое сопоставление строк по именам MCP-серверов, которые могут быть изменены. Если вы системный администратор и хотите предотвратить обход этого ограничения пользователями, рассмотрите возможность настройки mcpServers на уровне системных настроек так, чтобы пользователь не мог настроить свои собственные MCP-серверы. Не следует полагаться на это как на надежный механизм безопасности.

  • excludeMCPServers (массив строк):

    • Описание: Позволяет указать список имен MCP-серверов, которые должны быть исключены из модели. Сервер, указанный и в excludeMCPServers, и в allowMCPServers, будет исключен. Обратите внимание, что этот параметр будет проигнорирован, если установлен флаг --allowed-mcp-server-names.
    • По умолчанию: Никакие MCP-серверы не исключены.
    • Пример: "excludeMCPServers": ["myNodeServer"].
    • Примечание по безопасности: Используется простое сопоставление строк по именам MCP-серверов, которые могут быть изменены. Если вы системный администратор и хотите предотвратить обход этого ограничения пользователями, рассмотрите возможность настройки mcpServers на уровне системных настроек так, чтобы пользователь не мог настроить свои собственные MCP-серверы. Не следует полагаться на это как на надежный механизм безопасности.

  • autoAccept (boolean):

    • Описание: Определяет, будет ли CLI автоматически принимать и выполнять вызовы инструментов, которые считаются безопасными (например, операции только для чтения), без явного подтверждения пользователем. Если установлено в true, CLI будет пропускать диалог подтверждения для безопасных инструментов.
    • По умолчанию: false
    • Пример: "autoAccept": true

  • theme (string):

    • Описание: Устанавливает визуальную тему для Qwen Code.
    • По умолчанию: "Default"
    • Пример: "theme": "GitHub"

  • vimMode (boolean):

    • Описание: Включает или отключает режим vim для редактирования ввода. При включении область ввода поддерживает команды навигации и редактирования в стиле vim с режимами NORMAL и INSERT. Статус режима vim отображается в нижнем колонтитуле и сохраняется между сессиями.
    • По умолчанию: false
    • Пример: "vimMode": true

  • sandbox (boolean или string):

    • Описание: Контролирует, использовать ли песочницу для выполнения инструментов и каким образом. Если установлено в true, Qwen Code использует предварительно собранный Docker-образ qwen-code-sandbox. Подробнее см. Песочница.
    • По умолчанию: false
    • Пример: "sandbox": "docker"

  • toolDiscoveryCommand (string):

    • Описание: Совместимо с Gemini CLI. Определяет пользовательскую shell-команду для обнаружения инструментов из вашего проекта. Команда должна возвращать на stdout JSON-массив объявлений функций . Обертки инструментов необязательны.
    • По умолчанию: Пусто
    • Пример: "toolDiscoveryCommand": "bin/get_tools"

  • toolCallCommand (string):

    • Описание: Совместимо с Gemini CLI. Определяет пользовательскую shell-команду для вызова конкретного инструмента, обнаруженного с помощью toolDiscoveryCommand. Команда должна соответствовать следующим критериям:
      • Принимать имя функции (точно как в объявлении функции ) в качестве первого аргумента командной строки.
      • Читать аргументы функции в формате JSON из stdin, аналогично functionCall.args.
      • Возвращать результат функции в формате JSON через stdout, аналогично functionResponse.response.content.
    • По умолчанию: Пусто
    • Пример: "toolCallCommand": "bin/call_tool"

  • mcpServers (object):

    • Описание: Настраивает подключения к одному или нескольким серверам Model-Context Protocol (MCP) для обнаружения и использования пользовательских инструментов. Qwen Code пытается подключиться к каждому настроенному MCP-серверу для обнаружения доступных инструментов. Если несколько MCP-серверов предоставляют инструмент с одинаковым именем, имена инструментов будут дополнены псевдонимом сервера, определенным в конфигурации (например, serverAlias__actualToolName), чтобы избежать конфликтов. Обратите внимание, что система может удалять некоторые свойства схемы из определений инструментов MCP для обеспечения совместимости. Должно быть указано хотя бы одно из: command, url или httpUrl. Если указано несколько, приоритет имеет следующий порядок: httpUrl, затем url, затем command.
    • По умолчанию: Пусто
    • Свойства:
      • <SERVER_NAME> (object): Параметры сервера с указанным именем.
        • command (string, опционально): Команда для запуска MCP-сервера через стандартный ввод/вывод.
        • args (массив строк, опционально): Аргументы для передачи команде.
        • env (object, опционально): Переменные окружения для установки процесса сервера.
        • cwd (string, опционально): Рабочая директория для запуска сервера.
        • url (string, опционально): URL MCP-сервера, использующего Server-Sent Events (SSE) для связи.
        • httpUrl (string, опционально): URL MCP-сервера, использующего потоковое HTTP для связи.
        • headers (object, опционально): Карта HTTP-заголовков для отправки с запросами к url или httpUrl.
        • timeout (number, опционально): Таймаут в миллисекундах для запросов к этому MCP-серверу.
        • trust (boolean, опционально): Доверять этому серверу и пропустить все подтверждения вызова инструментов.
        • description (string, опционально): Краткое описание сервера, которое может использоваться для отображения.
        • includeTools (массив строк, опционально): Список имен инструментов, которые нужно включить с этого MCP-сервера. Если указано, только перечисленные инструменты будут доступны с этого сервера (поведение белого списка). Если не указано, по умолчанию включены все инструменты с сервера.
        • excludeTools (массив строк, опционально): Список имен инструментов, которые нужно исключить с этого MCP-сервера. Перечисленные инструменты не будут доступны модели, даже если они предоставлены сервером. Примечание: excludeTools имеет приоритет над includeTools — если инструмент есть в обоих списках, он будет исключен.
    • Пример: 
      "mcpServers": {
  "myPythonServer": {
    "command": "python",
    "args": ["mcp_server.py", "--port", "8080"],
    "cwd": "./mcp_tools/python",
    "timeout": 5000,
    "includeTools": ["safe_tool", "file_reader"],
  },
  "myNodeServer": {
    "command": "node",
    "args": ["mcp_server.js"],
    "cwd": "./mcp_tools/node",
    "excludeTools": ["dangerous_tool", "file_deleter"]
  },
  "myDockerServer": {
    "command": "docker",
    "args": ["run", "-i", "--rm", "-e", "API_KEY", "ghcr.io/foo/bar"],
    "env": {
      "API_KEY": "$MY_API_TOKEN"
    }
  },
  "mySseServer": {
    "url": "http://localhost:8081/events",
    "headers": {
      "Authorization": "Bearer $MY_SSE_TOKEN"
    },
    "description": "Пример SSE-сервера MCP."
  },
  "myStreamableHttpServer": {
    "httpUrl": "http://localhost:8082/stream",
    "headers": {
      "X-API-Key": "$MY_HTTP_API_KEY"
    },
    "description": "Пример потокового HTTP-сервера MCP."
  }
}

  • checkpointing (object):

    • Описание: Настраивает функцию контрольных точек, которая позволяет сохранять и восстанавливать состояние разговора и файлов. Подробнее см. Документация по контрольным точкам.
    • По умолчанию: {"enabled": false}
    • Свойства:
      • enabled (boolean): Если true, команда /restore становится доступной.

  • preferredEditor (string):

    • Описание: Указывает предпочитаемый редактор для просмотра diff’ов.
    • По умолчанию: vscode
    • Пример: "preferredEditor": "vscode"

  • telemetry (object)

    • Описание: Настраивает сбор логов и метрик для Qwen Code. Подробнее см. Телеметрия.
    • По умолчанию: {"enabled": false, "target": "local", "otlpEndpoint": "http://localhost:4317", "logPrompts": true}
    • Свойства:
      • enabled (boolean): Включена ли телеметрия.
      • target (string): Назначение собранных данных телеметрии. Поддерживаемые значения: local и gcp.
      • otlpEndpoint (string): Endpoint для OTLP Exporter.
      • logPrompts (boolean): Включать ли содержимое пользовательских запросов в логи.
    • Пример: 
      "telemetry": {
  "enabled": true,
  "target": "local",
  "otlpEndpoint": "http://localhost:16686",
  "logPrompts": false
}

  • usageStatisticsEnabled (boolean):

    • Описание: Включает или отключает сбор статистики использования. Подробнее см. Статистика использования.
    • По умолчанию: true
    • Пример: 
      "usageStatisticsEnabled": false

  • hideTips (boolean):

    • Описание: Включает или отключает полезные подсказки в интерфейсе CLI.
    • По умолчанию: false
    • Пример: 
      "hideTips": true

Пример settings.json:

{
  "theme": "GitHub",
  "sandbox": "docker",
  "toolDiscoveryCommand": "bin/get_tools",
  "toolCallCommand": "bin/call_tool",
  "tavilyApiKey": "$TAVILY_API_KEY",
  "mcpServers": {
    "mainServer": {
      "command": "bin/mcp_server.py"
    },
    "anotherServer": {
      "command": "node",
      "args": ["mcp_server.js", "--verbose"]
    }
  },
  "telemetry": {
    "enabled": true,
    "target": "local",
    "otlpEndpoint": "http://localhost:4317",
    "logPrompts": true
  },
  "usageStatisticsEnabled": true,
  "hideTips": false,
  "hideBanner": false,
  "skipNextSpeakerCheck": false,
  "skipLoopDetection": false,
  "maxSessionTurns": 10,
  "summarizeToolOutput": {
    "run_shell_command": {
      "tokenBudget": 100
    }
  },
  "excludedProjectEnvVars": ["DEBUG", "DEBUG_MODE", "NODE_ENV"],
  "includeDirectories": ["path/to/dir1", "~/path/to/dir2", "../path/to/dir3"],
  "loadMemoryFromIncludeDirectories": true
}

История Shell

CLI сохраняет историю выполненных вами shell-команд. Чтобы избежать конфликтов между разными проектами, эта история хранится в директории, специфичной для проекта, внутри домашней папки пользователя.

  • Расположение: ~/.qwen/tmp/<project_hash>/shell_history
    • <project_hash> — это уникальный идентификатор, сгенерированный на основе корневого пути вашего проекта.
    • История хранится в файле с именем shell_history.

Переменные окружения и файлы .env

Переменные окружения — это распространённый способ конфигурации приложений, особенно для чувствительных данных, таких как API keys, или для настроек, которые могут отличаться в зависимости от среды. Подробнее о настройке аутентификации можно прочитать в документации по аутентификации, где описаны все доступные методы.

CLI автоматически загружает переменные окружения из файла .env. Порядок загрузки следующий:

  1. Файл .env в текущей рабочей директории.
  2. Если файл не найден, CLI ищет его в родительских директориях, пока не найдёт .env или не достигнет корня проекта (определяется наличием папки .git) или домашней директории.
  3. Если файл всё ещё не найден, CLI пытается загрузить ~/.env (в домашней директории пользователя).

Исключение переменных окружения: Некоторые переменные (например, DEBUG и DEBUG_MODE) по умолчанию исключаются из проектных .env файлов, чтобы не мешать работе CLI. Переменные из файлов .qwen/.env никогда не исключаются. Это поведение можно изменить с помощью настройки excludedProjectEnvVars в файле settings.json.

  • OPENAI_API_KEY:
  • OPENAI_BASE_URL:
  • OPENAI_MODEL:
    • Указывает модель OPENAI по умолчанию.
    • Переопределяет значение по умолчанию, заданное в коде.
    • Пример: export OPENAI_MODEL="qwen3-coder-plus"
  • GEMINI_SANDBOX:
    • Альтернатива настройке sandbox в settings.json.
    • Принимает значения: true, false, docker, podman или строку с кастомной командой.
  • SEATBELT_PROFILE (только для macOS):
    • Переключает профиль Seatbelt (sandbox-exec) в macOS.
    • permissive-open: (по умолчанию) Ограничивает запись в папку проекта (и несколько других, см. packages/cli/src/utils/sandbox-macos-permissive-open.sb), но разрешает другие операции.
    • strict: Использует строгий профиль, который по умолчанию запрещает операции.
    • <profile_name>: Использует кастомный профиль. Чтобы определить кастомный профиль, создайте файл с именем sandbox-macos-<profile_name>.sb в директории .qwen/ вашего проекта (например, my-project/.qwen/sandbox-macos-custom.sb).
  • DEBUG или DEBUG_MODE (часто используются библиотеками или самим CLI):
    • Установите в true или 1, чтобы включить подробный debug-лог, полезный при отладке.
    • Примечание: Эти переменные по умолчанию исключаются из проектных .env файлов, чтобы не мешать работе CLI. Если нужно задать их для Qwen Code, используйте файлы .qwen/.env.
  • NO_COLOR:
    • Установите любое значение, чтобы отключить цветной вывод в CLI.
  • CLI_TITLE:
    • Установите строку, чтобы изменить заголовок CLI.
  • CODE_ASSIST_ENDPOINT:
    • Указывает endpoint для сервера code assist.
    • Полезно при разработке и тестировании.
  • TAVILY_API_KEY:
    • Ваш API key для сервиса веб-поиска Tavily.
    • Необходим для включения функциональности инструмента web_search.
    • Если не задан, инструмент веб-поиска будет отключён и пропущен.
    • Пример: export TAVILY_API_KEY="tvly-your-api-key-here"

Аргументы командной строки

Аргументы, переданные напрямую при запуске CLI, могут переопределять другие настройки для текущей сессии.

  • --model <model_name> (-m <model_name>):
    • Указывает, какую модель Qwen использовать в этой сессии.
    • Пример: npm start -- --model qwen3-coder-plus
  • --prompt <your_prompt> (-p <your_prompt>):
    • Используется для передачи prompt напрямую в команду. Это запускает Qwen Code в неинтерактивном режиме.
  • --prompt-interactive <your_prompt> (-i <your_prompt>):
    • Запускает интерактивную сессию с указанным prompt в качестве начального ввода.
    • Prompt обрабатывается внутри интерактивной сессии, а не до неё.
    • Не может использоваться при передаче ввода через stdin.
    • Пример: qwen -i "explain this code"
  • --sandbox (-s):
    • Включает режим песочницы для этой сессии.
  • --sandbox-image:
    • Устанавливает URI образа песочницы.
  • --debug (-d):
    • Включает режим отладки для этой сессии, предоставляя более подробный вывод.
  • --all-files (-a):
    • Если установлен, рекурсивно включает все файлы в текущей директории в качестве контекста для prompt.
  • --help (или -h):
    • Отображает справочную информацию по аргументам командной строки.
  • --show-memory-usage:
    • Отображает текущее использование памяти.
  • --yolo:
    • Включает режим YOLO, который автоматически одобряет все вызовы инструментов.
  • --approval-mode <mode>:
    • Устанавливает режим подтверждения для вызовов инструментов. Поддерживаемые режимы:
      • plan: Только анализ — не изменяет файлы и не выполняет команды.
      • default: Требует подтверждения для редактирования файлов или выполнения shell-команд (поведение по умолчанию).
      • auto-edit: Автоматически одобряет инструменты редактирования (edit, write_file), запрашивая подтверждение для остальных.
      • yolo: Автоматически одобряет все вызовы инструментов (эквивалент --yolo).
    • Не может использоваться вместе с --yolo. Используйте --approval-mode=yolo вместо --yolo для нового унифицированного подхода.
    • Пример: qwen --approval-mode auto-edit
  • --allowed-tools <tool1,tool2,...>:
    • Список инструментов, разделённых запятыми, которые будут обходить диалог подтверждения.
    • Пример: qwen --allowed-tools "ShellTool(git status)"
  • --telemetry:
  • --telemetry-target:
    • Устанавливает цель телеметрии. Подробнее см. в телеметрии.
  • --telemetry-otlp-endpoint:
    • Устанавливает OTLP endpoint для телеметрии. Подробнее см. в телеметрии.
  • --telemetry-otlp-protocol:
    • Устанавливает OTLP протокол для телеметрии (grpc или http). По умолчанию grpc. Подробнее см. в телеметрии.
  • --telemetry-log-prompts:
    • Включает логирование prompt для телеметрии. Подробнее см. в телеметрии.
  • --checkpointing:
  • --extensions <extension_name ...> (-e <extension_name ...>):
    • Указывает список расширений для использования в сессии. Если не указано, используются все доступные расширения.
    • Используйте специальное значение qwen -e none, чтобы отключить все расширения.
    • Пример: qwen -e my-extension -e my-other-extension
  • --list-extensions (-l):
    • Выводит список всех доступных расширений и завершает работу.
  • --proxy:
    • Устанавливает proxy для CLI.
    • Пример: --proxy http://localhost:7890.
  • --include-directories <dir1,dir2,...>:
    • Добавляет дополнительные директории в рабочее пространство для поддержки нескольких директорий.
    • Можно указывать несколько раз или в виде значений, разделённых запятыми.
    • Максимум можно добавить 5 директорий.
    • Пример: --include-directories /path/to/project1,/path/to/project2 или --include-directories /path/to/project1 --include-directories /path/to/project2
  • --screen-reader:
    • Включает режим чтения с экрана для обеспечения доступности.
  • --version:
    • Отображает версию CLI.
  • --openai-logging:
    • Включает логирование вызовов OpenAI API для отладки и анализа. Этот флаг переопределяет настройку enableOpenAILogging в settings.json.
  • --tavily-api-key <api_key>:
    • Устанавливает Tavily API key для функции веб-поиска в этой сессии.
    • Пример: qwen --tavily-api-key tvly-your-api-key-here

Файлы контекста (иерархический instructional context)

Хотя файлы контекста не являются строгой конфигурацией поведения CLI, они играют ключевую роль в настройке инструкционного контекста (также называемого “памятью”). По умолчанию используется файл QWEN.md, но имя файла можно изменить с помощью настройки contextFileName. Эта мощная функция позволяет передавать ИИ проектные инструкции, руководства по стилю кода или любую другую релевантную информацию, благодаря чему ответы модели становятся более точными и соответствующими вашим ожиданиям. CLI включает элементы интерфейса, например индикатор в нижнем колонтитуле, показывающий количество загруженных файлов контекста, чтобы вы всегда были в курсе активного контекста.

  • Назначение: Эти Markdown-файлы содержат инструкции, рекомендации или контекст, который вы хотите, чтобы модель Qwen учитывала во время взаимодействия. Система спроектирована так, чтобы управлять этим инструкционным контекстом иерархически.

Пример содержимого контекстного файла (например, QWEN.md)

Вот концептуальный пример того, что может содержать контекстный файл в корне проекта на TypeScript:

 
# Project: My Awesome TypeScript Library
 
## Общие инструкции:
 
- При генерации нового кода на TypeScript следуйте существующему стилю кодирования.
- Убедитесь, что все новые функции и классы сопровождаются комментариями JSDoc.
- Предпочтение отдавайте парадигмам функционального программирования, где это уместно.
- Весь код должен быть совместим с TypeScript 5.0 и Node.js 20+.
 
## Стиль кодирования:
 
- Используйте 2 пробела для отступов.
- Имена интерфейсов должны начинаться с `I` (например, `IUserService`).
- Приватные члены классов должны начинаться с символа подчеркивания (`_`).
- Всегда используйте строгое равенство (`===` и `!==`).
 
## Конкретный компонент: `src/api/client.ts`
 
- Этот файл обрабатывает все исходящие API-запросы.
- При добавлении новых функций для API-вызовов убедитесь, что они включают надежную обработку ошибок и логирование.
- Используйте существующую утилиту `fetchWithRetry` для всех GET-запросов.

О зависимостях:

  • Избегайте добавления новых внешних зависимостей, если в этом нет крайней необходимости.
  • Если новая зависимость необходима, пожалуйста, укажите причину.

Этот пример демонстрирует, как можно предоставить общий контекст проекта, конкретные соглашения о кодировании и даже заметки о конкретных файлах или компонентах. Чем более релевантными и точными являются ваши контекстные файлы, тем лучше ИИ сможет вам помочь. Настоятельно рекомендуется использовать специфичные для проекта контекстные файлы для установления соглашений и контекста.

- **Иерархическая загрузка и приоритетность:** CLI реализует сложную иерархическую систему памяти, загружая контекстные файлы (например, `QWEN.md`) из нескольких источников. Содержимое файлов, расположенных ниже в этом списке (более специфичных), обычно переопределяет или дополняет содержимое файлов выше (более общих). Точный порядок объединения и финальный контекст можно проверить с помощью команды `/memory show`. Типичный порядок загрузки следующий:
  1.  **Глобальный контекстный файл:**
      - Расположение: `~/.qwen/<contextFileName>` (например, `~/.qwen/QWEN.md` в вашей домашней директории пользователя).
      - Область применения: Предоставляет стандартные инструкции для всех ваших проектов.
  2.  **Контекстные файлы корневой директории проекта и её предков:**
      - Расположение: CLI ищет указанный контекстный файл в текущей рабочей директории, а затем в каждой родительской директории до корня проекта (определяемого наличием папки `.git`) или вашей домашней директории.
      - Область применения: Предоставляет контекст, относящийся ко всему проекту или значительной его части.
  3.  **Контекстные файлы поддиректорий (локальные/контекстуальные):**
      - Расположение: CLI также сканирует наличие указанного контекстного файла в поддиректориях _ниже_ текущей рабочей директории (с учётом распространённых шаблонов игнорирования, таких как `node_modules`, `.git` и т. д.). По умолчанию глубина этого поиска ограничена 200 директориями, но может быть изменена через поле `memoryDiscoveryMaxDirs` в вашем файле `settings.json`.
      - Область применения: Позволяет задать очень специфичные инструкции, относящиеся к конкретному компоненту, модулю или разделу вашего проекта.
- **Объединение и отображение в интерфейсе:** Содержимое всех найденных контекстных файлов объединяется (с разделителями, указывающими их источник и путь) и передаётся как часть системного промпта. В нижнем колонтитуле CLI отображается количество загруженных контекстных файлов — это позволяет быстро понять, какой объём инструкций активен в данный момент.
- **Импорт содержимого:** Вы можете модульно организовать свои контекстные файлы, импортируя другие Markdown-файлы с помощью синтаксиса `@path/to/file.md`. Подробнее см. в [документации Memory Import Processor](../core/memport.md).
- **Команды управления памятью:**
  - Используйте `/memory refresh`, чтобы принудительно пересканировать и перезагрузить все контекстные файлы из всех настроенных местоположений. Это обновит инструкционный контекст ИИ.
  - Используйте `/memory show`, чтобы отобразить текущий объединённый инструкционный контекст, что позволит вам проверить иерархию и содержание, используемое ИИ.
  - Полное описание команды `/memory` и её подкоманд (`show` и `refresh`) доступно в [документации по командам](./commands.md#memory).

Понимая и используя эти уровни конфигурации и иерархическую структуру контекстных файлов, вы сможете эффективно управлять памятью ИИ и адаптировать ответы Qwen Code под свои конкретные нужды и проекты.

## Sandboxing

Qwen Code может выполнять потенциально небезопасные операции (например, shell-команды и изменения файлов) в sandbox-окружении, чтобы защитить вашу систему.

По умолчанию sandboxing отключен, но вы можете включить его несколькими способами:

- Используя флаг `--sandbox` или `-s`.
- Установив переменную окружения `GEMINI_SANDBOX`.
- Sandbox включается по умолчанию при использовании `--yolo` или `--approval-mode=yolo`.

По умолчанию используется предварительно собранный Docker-образ `qwen-code-sandbox`.

Если вашему проекту требуется специфичная sandbox-конфигурация, вы можете создать собственный Dockerfile по пути `.qwen/sandbox.Dockerfile` в корневой директории проекта. Этот Dockerfile может быть основан на базовом sandbox-образе:

```dockerfile
FROM qwen-code-sandbox

# Добавьте сюда свои зависимости или настройки

# Например:

# RUN apt-get update && apt-get install -y some-package

COPY ./my-config /app/my-config


Когда файл `.qwen/sandbox.Dockerfile` существует, вы можете использовать переменную окружения `BUILD_SANDBOX` при запуске Qwen Code для автоматической сборки кастомного sandbox-образа:

```bash
BUILD_SANDBOX=1 qwen -s

Статистика использования

Чтобы помочь нам улучшить Qwen Code, мы собираем анонимизированную статистику использования. Эти данные помогают нам понять, как используется CLI, выявить распространенные проблемы и определить приоритеты для новых функций.

Что мы собираем:

  • Вызовы инструментов: Мы записываем названия вызванных инструментов, информацию об успешности их выполнения и время выполнения. Мы не собираем аргументы, переданные инструментам, или любые данные, возвращенные ими.
  • API запросы: Мы записываем модель, использованную для каждого запроса, продолжительность запроса и его успешность. Мы не собираем содержимое промптов или ответов.
  • Информация о сессии: Мы собираем информацию о конфигурации CLI, например, включенные инструменты и режим подтверждения.

Что мы НЕ собираем:

  • Персональные данные (PII): Мы не собираем никакой персональной информации, такой как ваше имя, адрес электронной почты или API ключи.
  • Содержимое промптов и ответов: Мы не записываем содержимое ваших промптов или ответов модели.
  • Содержимое файлов: Мы не записываем содержимое файлов, которые читаются или записываются CLI.

Как отключить сбор статистики:

Вы можете отказаться от сбора статистики использования в любое время, установив значение свойства usageStatisticsEnabled в false в вашем файле settings.json:

{
  "usageStatisticsEnabled": false
}

Примечание: Когда статистика использования включена, события отправляются на эндпоинт сбора данных Alibaba Cloud RUM.

  • enableWelcomeBack (boolean):
    • Описание: Показывать диалог приветствия при возвращении к проекту с историей разговора.
    • По умолчанию: true
    • Категория: UI
    • Требуется перезапуск: Нет
    • Пример: "enableWelcomeBack": false
    • Подробности: Если включено, Qwen Code автоматически определяет, возвращаетесь ли вы к проекту с ранее созданным сводным файлом проекта (.qwen/PROJECT_SUMMARY.md), и показывает диалоговое окно, позволяющее продолжить предыдущий разговор или начать заново. Эта функция интегрирована с командой /chat summary и диалогом подтверждения выхода. Подробнее см. в документации Welcome Back.
Last updated on
КонфигурацияТемы