Команды

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

Команды Qwen Code вызываются с помощью специальных префиксов и делятся на три категории:

1. Slash-команды (/)

Slash-команды используются для управления сессиями, интерфейсом и базовым поведением Qwen Code.

1.1 Управление сессиями и проектами

Эти команды помогают сохранять, восстанавливать и резюмировать ход работы.

1.2 Управление интерфейсом и рабочим пространством

Команды для настройки внешнего вида интерфейса и рабочей среды.

1.3 Настройки языка

Команды для управления языком интерфейса и языком вывода.

• Доступные встроенные языки интерфейса: zh-CN (упрощенный китайский), en-US (английский), ru-RU (русский), de-DE (немецкий), ja-JP (японский), pt-BR (португальский - Бразилия), fr-FR (французский), ca-ES (каталанский)
• Примеры языков вывода: Chinese, English, Japanese и т.д.

1.4 Управление инструментами и моделями

Команды для управления ИИ-инструментами и моделями.

1.5 Встроенные skills

Эти команды вызывают встроенные skills, которые предоставляют специализированные рабочие процессы.

См. Код-ревью для полной документации /review и Автоисправление Pull Request для /autofix-pr.

1.6 Побочные вопросы (/btw)

Команда /btw позволяет задавать быстрые побочные вопросы, не прерывая и не влияя на основной ход диалога.

Как это работает:

• Побочный вопрос отправляется как отдельный API-запрос с контекстом недавнего диалога (до последних 20 сообщений)
• Ответ отображается над Composer — вы можете продолжать печатать во время ожидания
• Основной диалог не блокируется — он продолжается независимо
• Ответ на побочный вопрос не становится частью истории основного диалога
• Ответы отображаются с полной поддержкой Markdown (блоки кода, списки, таблицы и т. д.)

Горячие клавиши (Интерактивный режим):

Пример:

(While the main conversation is about refactoring code)

> /btw What's the difference between let and var in JavaScript?

  ╭──────────────────────────────────────────╮
  │ /btw What's the difference between let   │
  │     and var in JavaScript?               │
  │                                          │
  │ + Answering...                           │
  │ Press Escape, Ctrl+C, or Ctrl+D to cancel│
  ╰──────────────────────────────────────────╯
  > (Composer remains active — keep typing)

(After the answer arrives)

  ╭──────────────────────────────────────────╮
  │ /btw What's the difference between let   │
  │     and var in JavaScript?               │
  │                                          │
  │ `let` is block-scoped, while `var` is    │
  │ function-scoped. `let` was introduced    │
  │ in ES6 and doesn't hoist the same way.   │
  │                                          │
  │ Press Space, Enter, or Escape to dismiss │
  ╰──────────────────────────────────────────╯
  > (Composer still active)

Поддерживаемые режимы выполнения:

1.7 Второе мнение (/advisor)

Команда /advisor выполняет независимое ревью текущего диалога только для чтения и возвращает структурированное второе мнение — не выполняя задачу и не прерывая основной диалог.

Как это работает:

• Ревью отправляется как отдельный одноходовый API-запрос с контекстом недавнего диалога (до последних 40 сообщений)
• Модель-ревьюер не может выполнять инструменты — инструменты удаляются на уровне запроса (тот же механизм, что и для /btw), поэтому ревью никогда не пишет код и не выполняет команды; каждое утверждение должно основываться на видимом транскрипте
• Основной диалог не прерывается; ревью показывается только вам
• Ревью отображается как обрамлённый markdown-блок с четырьмя фиксированными разделами — Verdict, Risks, Missing evidence и Recommendation — под заголовком /advisor · <model>, указывающим используемую модель-ревьюера
• В отличие от /btw, который выполняется fire-and-forget и не блокирует сессию, /advisor блокирует ввод до возврата ревью; при полном окне контекста с мощной моделью-ревьюером это может занять десятки секунд
• По умолчанию используется основная модель; установите advisorModel, чтобы направить ревью на другую (обычно более мощную) модель — недавний транскрипт отправляется этой модели, даже если она использует другого провайдера

Пример:

> /advisor is my fix for the null check actually correct?

  Consulting advisor...

  ╭──────────────────────────────────────────────────────╮
  │ /advisor · qwen3-max                                 │
  │                                                      │
  │ Verdict                                              │
  │ The approach is sound, but the edge case at line 42  │
  │ is unverified.                                       │
  │                                                      │
  │ Risks                                                │
  │  - The fix assumes the config is always loaded; a    │
  │    startup race could leave it null.                 │
  │                                                      │
  │ Missing evidence                                     │
  │  - No test exercises the null-config path in the     │
  │    visible transcript.                               │
  │                                                      │
  │ Recommendation                                       │
  │ Add a focused unit test for the null-config branch   │
  │ before merging.                                      │
  ╰──────────────────────────────────────────────────────╯

Ревью отображается в обрамлённом блоке, заголовок которого указывает используемую модель-ревьюера. Неизвестная advisorModel не проверяется заранее — если провайдер отклоняет её, /advisor сообщает о сбое, поэтому проверяйте имя модели; только неразрешимые селекторы алиасов (например, fast без настроенной быстрой модели) откатываются на основную модель. Запросы advisor не используют настроенные фолбэки моделей.

Поддерживаемые режимы выполнения:

1.8 Краткое содержание сессии (/recap)

Команда /recap генерирует краткое резюме «на чем вы остановились» для текущей сессии, чтобы вы могли продолжить старую беседу без прокрутки страниц истории.

Как это работает:

• Использует настроенную быструю модель (параметр fastModel), если она доступна, иначе возвращается к основной модели сессии. Для краткого пересказа достаточно небольшой и дешевой модели.
• Недавняя беседа (до 30 сообщений, только текст — вызовы инструментов и ответы инструментов фильтруются) отправляется в модель со строгим системным запросом.
• Пересказ отображается тусклым цветом с префиксом ❯, чтобы отличаться от реальных ответов ассистента.
• Отказывается выполнять команду с встроенной ошибкой, если ход модели выполняется или обрабатывается другая команда. Если нет доступной беседы или генерация не удалась, /recap показывает короткое информационное сообщение вместо пересказа — ручная команда всегда дает какой-то ответ.

Автозапуск при возвращении после отсутствия:

Если терминал теряет фокус на 5+ минут и снова получает его, пересказ генерируется и показывается автоматически (только когда нет ответа модели; иначе он ждет завершения текущего хода и затем запускается). В отличие от ручной команды, автоматический триггер полностью молчит при ошибках: если генерация завершается ошибкой или нечего резюмировать, в историю не добавляется никаких сообщений. Управляется параметром general.showSessionRecap (по умолчанию: false); ручная команда /recap всегда работает независимо от этого параметра.

Пример:

> /recap

❯ Refactoring loopDetectionService.ts to address long-session OOM caused by
  unbounded streamContentHistory and contentStats. The next step is to
  implement option B (LRU sliding window with FNV-1a) pending confirmation.

1.9 Просмотр diff (/diff)

Команда /diff открывает интерактивный просмотрщик diff, показывающий незакоммиченные изменения и diff для каждого хода. Используйте ←/→ для переключения между текущим git diff и отдельными ходами диалога, ↑/↓ для навигации по файлам и Enter для просмотра inline-diff.

Как это работает:

В интерактивном режиме /diff открывает диалоговое окно с выбором источника в верхней части:

• Current — рабочее дерево против HEAD (git diff HEAD). Показывает все незакоммиченные изменения, включая проиндексированные, непроиндексированные и неотслеживаемые файлы.
• T1, T2, T3, … — diff для каждого хода, по одной вкладке на каждый ход модели, изменивший файлы. Самые последние ходы отображаются первыми. Каждая вкладка показывает превью исходного промпта для контекста.

Список файлов отображает статистику по каждому файлу (добавленные/удаленные строки) с тегами для специальных состояний (new, deleted, untracked, binary, truncated, oversized). Нажмите Enter на файле, чтобы просмотреть его inline-diff с подсветкой синтаксиса для блоков изменений.

Diff для каждого хода требует включения контрольных точек файлов (по умолчанию включено в интерактивном режиме). Когда контрольные точки файлов отключены, доступен только источник “Current”.

Горячие клавиши:

Пример:

┌ /diff · Turn 3 "refactor the auth middleware" ──── 3 files +45 -12 ┐
│                                                                     │
│ ◀ Current · T3 · T2 · T1 ▶                                         │
│                                                                     │
│ › src/utils/parser.ts                              +30 -8           │
│   src/utils/parser.test.ts                         +12 -2           │
│   README.md                                        +3 -2            │
│                                                                     │
│ ←/→ source · ↑/↓ file · Enter view · Esc close                     │
└─────────────────────────────────────────────────────────────────────┘

Неинтерактивный режим:

В headless-режиме (--prompt) или неинтерактивном контексте /diff выводит текстовое резюме рабочего дерева против HEAD. Навигация по ходам недоступна.

3 files changed, +45 / -12
  +30  -8  src/utils/parser.ts
  +12  -2  src/utils/parser.test.ts
   +3  -2  README.md

Web Shell: В Web Shell UI (qwen serve), /diff открывает графический диалог diff. Панель вкладок в верхней части позволяет переключаться между представлением Changes и представлением History (/log).

Просмотр истории (/log) — только Web Shell

Команда /log открывает браузер истории коммитов для текущего рабочего пространства. Она доступна только в Web Shell UI; CLI/TUI не имеет этой команды.

Как это работает:

/log открывает диалоговое окно со списком коммитов в обратном хронологическом порядке (новые первые). Каждая строка показывает:

• Короткий SHA (моноширинный, с кнопкой копирования полного SHA)
• Тему коммита (одна строка)
• Имя автора и относительное время (например, “2h ago”)
• Метки ссылок веток/тегов, если есть
• Иконку слияния (⎇) для merge-коммитов

Нажмите на строку коммита, чтобы развернуть его детали по запросу:

• Полное тело сообщения коммита
• Статистику изменений файлов (изменённые файлы, добавленные/удалённые строки, разбивка по файлам)

Используйте Load more внизу, чтобы загрузить следующую страницу коммитов (50 на страницу).

Пример:

┌─ History ──────────────────────────── 50 commits ─ ✕ ┐
│                                                       │
│  a1b2c3d  feat(cli): add --json flag        2h ago   │
│           wenshao                                    │
│                                                       │
│  e4f5g6h  fix(core): handle null config     5h ago   │
│           dev · main  v1.2.0                         │
│                                                       │
│ ▼ 789abcd  refactor: simplify parser        1d ago   │
│   ┌─────────────────────────────────────────────┐    │
│   │  Broke the monolithic parse() into smaller  │    │
│   │  functions for readability.                 │    │
│   │                                             │    │
│   │  3 files · +45 −12                          │    │
│   │   +30 −8   src/parser.ts                    │    │
│   │   +10 −2   src/utils.ts                     │    │
│   │   +5  −2   test/parser.test.ts              │    │
│   └─────────────────────────────────────────────┘    │
│                                                       │
│              [ Load more ]                            │
└───────────────────────────────────────────────────────┘

1.10 Информация, настройки и помощь

Команды для получения информации и выполнения системных настроек.

1.11 Часто используемые сочетания клавиш

1.12 Команды аутентификации

Используйте /auth внутри сессии Qwen Code для настройки аутентификации. Используйте /doctor для проверки текущего статуса аутентификации и состояния окружения.

2. Команды @ (Подключение файлов)

Команды @ используются для быстрого добавления содержимого локального файла или директории в контекст разговора.

Примечание: Пробелы в путях необходимо экранировать обратным слешем (например, @My\ Documents/file.txt).

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

3. Команды с восклицательным знаком (!) — Выполнение Shell-команд

Команды с восклицательным знаком позволяют выполнять системные команды непосредственно внутри Qwen Code.

Переменные окружения: При выполнении команд через ! устанавливается переменная окружения QWEN_CODE=1.

4. Пользовательские команды

Сохраняйте часто используемые промпты в виде команд быстрого доступа для повышения эффективности работы и обеспечения согласованности.

Краткий обзор

Правила приоритета: Команды проекта > Пользовательские команды (при совпадении имен используется команда проекта).

Правила именования команд

Таблица сопоставления пути к файлу и имени команды

Правила именования: Разделитель пути (/ или \) преобразуется в двоеточие (:).

Спецификация формата Markdown-файлов (рекомендуется)

Пользовательские команды используют Markdown-файлы с необязательными YAML frontmatter:

---
description: Optional description (displayed in /help)
---
 
Your prompt content here.
Use {{args}} for parameter injection.

Формат TOML (устаревший)

Механизм обработки параметров

1. Контекстное внедрение ({{args}})

2. Обработка параметров по умолчанию

🚀 Внедрение динамического контента

3. Выполнение Shell-команд (!{...})

Пример: Генерация сообщения коммита Git

---
description: Generate Commit message based on staged changes
---
 
Please generate a Commit message based on the following diff:
 
```diff
!{git diff --staged}
```

4. Внедрение содержимого файлов (@{...})

Пример: Команда проверки кода

---
description: Code review based on best practices
---
 
Review {{args}}, reference standards:
 
@{docs/code-standards.md}

Практический пример создания

Таблица шагов создания команды «Рефакторинг чистых функций»

---
description: Refactor code to pure function
---
 
Please analyze code in current context, refactor to pure function.
Requirements:
 
1. Provide refactored code
2. Explain key changes and pure function characteristic implementation
3. Maintain function unchanged

Резюме лучших практик пользовательских команд

Таблица рекомендаций по проектированию команд

Таблица напоминаний о функциях безопасности

5. Подкоманды CLI

Эти команды выполняются из shell как qwen <subcommand> перед началом интерактивной сессии.

Управление сессиями

qwen sessions list

Выводит список ваших недавних сессий Qwen Code с метаданными.

Флаги:

Человекочитаемый вывод (по умолчанию):

Таблица со столбцами: SESSION ID, STARTED (UTC-время), TITLE, BRANCH, PROMPT.

JSON-вывод (--json):

Выводит JSON Lines в stdout. Каждая строка представляет собой JSON-объект с полями:

sessionId, startTime, mtime, prompt, gitBranch, customTitle, titleSource, filePath, cwd

Подсказка о наличии дополнительных сессий выводится в stderr, чтобы конвейеризация в jq оставалась безопасной.

Примеры:

# Show last 20 sessions (default)
qwen sessions list
 
# Show last 50 sessions
qwen sessions list --limit 50
 
# Output as JSON for scripting
qwen sessions list --json | jq .

qwen sessions ps

Списывает записи сессий Qwen Code, видимые на этой машине. sessions list просматривает сохраненные транскрипты («над чем я работал»). Эта команда показывает как реестр живых процессов, так и записи Agent View, помеченные как managed. Записи, оставшиеся после убитой сессии, удаляются из реестра по мере обнаружения. Управляемая запись — это постоянный учет, а не доказательство того, что ее рабочий процесс еще жив. Однократный запуск qwen -p никогда не регистрируется и не отображается.

Флаги:

Человекочитаемый вывод (по умолчанию):

Таблица со столбцами: NAME, KIND, PID, AGE, DIRECTORY.

KIND указывает, кто зарегистрировал сессию: tui для человека в терминале, external для программы, которая вообще не является сессией Qwen Code (голосовой интерфейс, ретранслятор), и headless или serve для сессии, управляемой другой программой. Несколько строк serve или headless могут разделять один PID: дочерний процесс qwen --acp размещает все свои сессии в одном процессе — serve когда демон запустил его, headless когда клиент управляет им напрямую — и каждый из них регистрируется отдельно, когда активна обмен сообщениями между пирингами. Хостируемая сессия не регистрируется здесь, если ее собственное окружение переводит ее в режим bare или safe. Переменная --bare демона не передается хостируемым сессиям (QWEN_CODE_SIMPLE удаляется из окружения дочернего процесса); унаследованная переменная QWEN_CODE_SAFE_MODE передается, исключая эти хостируемые сессии из данного списка. Это самоотчет, подобно NAME и DIRECTORY: каждое поле здесь было записано описываемым процессом, и ничто из того, что разрешено делать сессии, не зависит от него. Запись Agent View, помеченная как managed, использует managed для KIND и - для PID и AGE. Она остается отдельной строкой, даже если та же сессия имеет также запись в живом реестре. См. Cross-Session Protocol для формата записи и инструкций по регистрации собственной программы.

JSON-вывод (--json):

Выводит JSON Lines в stdout, сначала управляемые записи. Записи реестра сохраняют свою существующую структуру:

schemaVersion, pid, procStart, pidNs, sessionId, cwd, name, startedAt,
qwenVersion, kind, ipcPath (when peer messaging is available)

Управляемая запись содержит только данные, подтвержденные источником:

sessionId, cwd, managed: true

Ничего другого не пишется в stdout — пустой список ничего не печатает — поэтому qwen sessions ps --json | jq . безопасно использовать в скриптах. Если хранилище супервизора недоступно для чтения, записи реестра все равно выводятся, а причина ошибки записывается в stderr.

JSON-вывод представляет собой сырые данные: значения полей выдаются точно так, как они были записаны, без санитизации для терминала. Относитесь к ним как к данным и выполняйте санитизацию перед их отображением в терминале.

Примеры:

# Show the other live sessions
qwen sessions ps
 
# Which directories have a visible session record?
# Note: `jq -r` renders the raw recorded value in your terminal (see the
# raw-data note above); pipe through a sanitizer if the path is untrusted.
qwen sessions ps --json | jq -r .cwd

6. Обмен сообщениями с другой запущенной сессией

Две интерактивные сессии на одной машине могут обмениваться сообщениями. Функция включена по умолчанию, но --bare и --safe-mode отключают ее независимо от настройки. При наличии входящего почтового ящика сессия становится обнаруживаемой другими сессиями того же пользователя на машине, и то, что они ей отправляют, проходит через правила проверки ниже, прежде чем ее модель увидит это. Чтобы отключить обнаружение пиров и обмен сообщениями, выключите эту функцию в settings.json и перезапустите:

{ "agents": { "crossSessionMessaging": false } }

Интерактивная сессия с отключенным обменом сообщениями между пирами может по-прежнему появляться в qwen sessions ps, но не имеет ipcPath и не является достижимым пиром в list_agents. Интерфейс OpenTUI также не привязывает входящий почтовый ящик для пиров; включение настройки само по себе не делает его способным к обмену сообщениями.

При активной передаче сообщений модель в одной сессии может обнаружить другие с помощью list_agents — каждая отображается под sessions с name, который записывает qwen sessions ps --json (в табличном представлении длинные имена могут сокращаться) — и обратиться к одной из них через send_message, используя это имя как to. Если две сессии имеют одинаковое имя, list_agents показывает каждую с коротким [ref], и при отправке его необходимо указать (name [ref]); голое имя, которое может относиться к обеим, отвергается вместо угадывания. list_agents также сообщает собственное имя сессии под self, а to: "*" по-прежнему означает «мои коллеги по Agent Team» и никогда не достигает других сессий.

Сообщение приходит в другую сессию с пометкой о том, что оно исходит от другой сессии, а не от её пользователя, и не несёт никаких ваших полномочий там: принимающая сессия действует на его основе только в рамках своих настроек разрешений. Её пользователь может выбрать, что происходит с входящими сообщениями, с помощью agents.crossSessionInbound (accept, hold или refuse). Если значение не установлено, сообщение доставляется только тогда, когда обе сессии находятся в одном классе проверки: обе всё ещё проверяют каждое действие (режим по умолчанию или режим плана), или обе находятся в режиме, который применяет некоторые действия без проверки каждого действия (авто-редактирование, авто или yolo). Сообщение от сессии из другого класса или от отправителя, который не указывает свой класс, задерживается для проверки — в обоих направлениях. Сессия, которая проверяет каждое действие, задерживает сообщение от той, которая этого не делает, потому что такое сообщение было написано моделью, за которой никто не следил, а запросы на подтверждение каждого действия защищают действия, а не то, во что убеждают сессию. Задержанные сообщения перечисляются и освобождаются с помощью /peers в принимающей сессии, а сообщение, задержанное только из-за различия в режимах, освобождается автоматически, когда режимы совпадают.

Репозиторий может сделать сессии, открытые в нём, более осторожными, но никогда менее: рабочее пространство .qwen/settings.json может установить agents.crossSessionInbound в hold или refuse, или agents.crossSessionMessaging в false, и это значение имеет приоритет над более мягким значением в ваших пользовательских настройках. Значение рабочего пространства, которое ослабило бы операторскую настройку (accept, или true для переключателя, если пользовательская или системная область установили его в false), игнорируется с предупреждением; значение рабочего пространства true, где ничто другое не установило переключатель, просто повторяет значение по умолчанию и молча отбрасывается. Значение, которое CLI не распознает, задерживает все сообщения, когда оно является действующим. Системные настройки имеют приоритет над всем этим, как и для любой другой настройки.

Задержка не длится вечно. Сообщение, по которому никто не принял решение, истекает после agents.crossSessionHeldExpiry — 1m, 5m, 10m или never, по умолчанию пять минут — и отправляющей сессии сообщается, что решение не было принято. Уменьшение этого параметра применяется к уже ожидающим сообщениям.

Если сессия не может привязать свой почтовый ящик — каталог среды выполнения отсутствует, принадлежит другому пользователю или доступен только для чтения, как это может быть внутри контейнера — она сначала пытается использовать частный каталог под временным каталогом, и только если это тоже не удается, запускается без него. Когда это происходит, сессия сообщает об этом при запуске, а /peers повторяет причину и что нужно изменить (обычно XDG_RUNTIME_DIR или TMPDIR).

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

Вызов send_message только подтверждает, что сообщение было передано другой сессии. Что с ним стало, приходит позже в виде квитанции: если оно было задержано, отклонено, отвергнуто, сброшено, истекло или адресовано неверно (адрес сменился — снова перечислите агентов) — или освобождено после задержки — уведомление появляется в транскрипте отправляющей сессии (Message to <name>: …). Отклонено, отвергнуто и сброшено — это три разных ответа: отклонено означает, что кто-то проверил сообщение и сказал «нет», отвергнуто означает, что agents.crossSessionInbound этой сессии равно refuse и никто его вообще не видел, а сброшено означает, что его почтовый ящик отверг сообщение до всего этого (см. ниже). Первый сброс обрабатывается немедленно, а остальные сворачиваются в квитанцию каждые несколько секунд, каждая из которых называет представляемые ею сообщения, так что серия таких событий стоит несколько строк, а не по одной строке на каждое. Модель, которая отправила его, не получает уведомления; если другая сессия ответит, ответ придет как межсессионное сообщение.

Защита от переполнения

Сессия принимает до 30 сообщений сразу от одного отправителя, а затем по одному каждые две секунды, и до 32 сообщений сразу от всех отправителей вместе, а затем по одному в секунду. Второй лимит существует потому, что отправитель называет себя сам: ротация этого имени получает новый лимит из первого ограничения, но не из второго. Он едва превышает первый, потому что каждое принятое сообщение требует квитанции, а сессия может одновременно отправлять только ограниченное количество таких квитанций. Сообщение из другой сессии, которое дословно повторяет предыдущее сообщение того же отправителя в течение 30 секунд, также отклоняется — модель, зацикленная на одной фразе, каждый раз генерирует новый идентификатор сообщения, поэтому именно текст позволяет это обнаружить. Сообщения от скрипта, запущенного сессией, и от доверенного контроллера освобождены от проверки повторов, поскольку хук, дважды сообщающий одну и ту же строку, сообщает два факта, а человек, дважды говорящий «продолжить», действительно имеет это в виду; оба типа все еще подчиняются ограничениям частоты. Наконец, сообщение, которое принято, но не может быть поставлено в очередь, так как в сессии уже есть 50 ожидающих сообщений, также отклоняется.

Отклоненное таким образом сообщение никогда не сохраняется, не показывается модели и не оставляет записи, поэтому отправитель может попробовать снова позже и успешно доставить его. Принимающая сессия сообщает об этом в своем журнале не чаще одного раза в минуту для каждого отправителя, с указанием количества пропущенных строк. Отправляющая сессия получает одну квитанцию, перечисляющую все сообщения, которые были потеряны из-за превышения лимита, и ее журнал рекомендует объединить важные данные в одно последующее сообщение вместо повторной отправки.

Отправляющая сторона не ждет ответа. Каждая сессия отслеживает то, что она отправила на каждый адрес, и отказывает в отправке, которую получатель отбросил бы, поэтому модели рекомендуется пакетировать сообщения до их записи, а не после — и получатель никогда не тратит соединение на сообщение, которое он собирался отклонить.

Аутентификация входящих сообщений и скриптовая инъекция

Входящий ящик каждой сессии требует отдельный токен для сессии: соединение должно представить его в первой строке перед чтением любого сообщения, и сессии автоматически обмениваются токенами через те же записи реестра, с помощью которых они обнаруживают друг друга. Сессии из сборки без поддержки токенов могут получать сообщения от более новой версии, но их исходящие сообщения будут отброшены.

Сессия экспортирует свой адрес входящего ящика и токен в дочерние процессы как QWEN_CODE_MESSAGING_SOCKET и QWEN_CODE_MESSAGING_TOKEN, чтобы скрипт или хук, запускаемый сессией, мог отправить сообщение обратно в нее. Это второй, дочерний токен, который нигде не публикуется: только процессы, запущенные сессией, могут его иметь, поэтому сообщение, прибывшее с ним, распознается как собственное сообщение сессии, а не как сообщение другой сессии.

{ printf '%s\n' \
    '{"msgV":1,"type":"auth","token":"'"$QWEN_CODE_MESSAGING_TOKEN"'"}' \
    '{"msgV":1,"msgId":"'"$(uuidgen)"'","type":"user","priority":"next","message":{"role":"user","content":"build finished"}}'; \
} | socat - UNIX-CONNECT:"$QWEN_CODE_MESSAGING_SOCKET"

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

Внедренное сообщение все равно проходит через входящий шлюз и помечается как не исходящее от пользователя, но шлюз знает, что оно поступило от собственного процесса сессии: при значении по умолчанию «режим паритета» оно доставляется без проверки (равный участник в той же позиции был бы задержан), тогда как явный agents.crossSessionInbound со значением hold или refuse применяется к нему так же, как и к любому другому сообщению. Модель видит его как <cross_session_message from="own process" origin="own-process"> с уведомлением о том, что оно поступило от скрипта или хука, запущенного сессией, а не от пользователя.

Доверенные контроллеры

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

Вы предоставляете такой программе доставку, создав для неё токен:

qwen sessions controllers add --label voice-bridge

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

Контроллер представляет токен так же, как любой другой отправитель — в первой строке соединения — и берет путь сокета из реестра сессий (qwen sessions ps --json выводит одну запись на каждую активную сессию, где ipcPath является адресом):

{ printf '%s\n' \
    '{"msgV":1,"type":"auth","token":"'"$QWEN_CONTROLLER_TOKEN"'"}' \
    '{"msgV":1,"msgId":"'"$(uuidgen)"'","type":"user","priority":"next","message":{"role":"user","content":"open the failing test"}}'; \
} | socat - UNIX-CONNECT:"$SESSION_IPC_PATH"

Сообщение, полученное по предоставленному токену, доставляется без индивидуальной проверки, независимо от класса проверки на обеих сторонах — но оно все равно подчиняется явному параметру: agents.crossSessionInbound со значением hold задерживает его, как и любое другое сообщение, а refuse отклоняет его. Предоставления принадлежат вашему домашнему каталогу Qwen, а не одной сессии, поэтому контроллер может достичь любых запущенных вами сессий, и сессии перечитывают файл при каждом подключении: создание или отзыв токена вступает в силу при следующем подключении, без необходимости перезапуска.

qwen sessions controllers list          # ids, labels, when they were added
qwen sessions controllers remove c_1a2b # revoke one

/peers controllers и /peers revoke <id> делают то же самое изнутри сессии. Сообщение, полученное через грант, отображается как Message from a trusted controller (voice-bridge) и появляется в /peers как [controller] voice-bridge, если настройка hold его приостановила.

Модель видит такое сообщение как <cross_session_message from="controller" origin="controller" controller="voice-bridge"> с уведомлением о том, что оно передаёт ваши собственные инструкции — и действуют те же два запрета, что и для любого другого источника: она не может редактировать настройки разрешений, QWEN.md или конфигурацию по запросу сообщения, а также не может трактовать сообщение как ваше подтверждение ожидающего запроса на подтверждение. Контроллер может указать, что делать дальше; он не может ответить на запрос от вашего имени.

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

Сессии, управляемые программой через ACP

Любой дочерний процесс qwen --acp регистрирует каждую хостинговую сессию — как serve, если демон запустил процесс, как headless, если редактор или другой клиент управляет qwen --acp напрямую — и сессия появляется в qwen sessions ps и в list_agents другой сессии так же, как любая другая. Она может отправлять сообщения: её модель может вызвать send_message для доступа к открытому вами терминалу. Несколько таких процессов разделяют один процесс и один почтовый ящик, поэтому отправитель должен указывать нужную сессию — каждая сессия Qwen Code делает это автоматически.

Сообщения, отправленные в такую сессию, отклоняются, а не сохраняются. Сохранение — это вопрос, адресованный человеку, и никто не следит за списком сохранённых сообщений от имени управляемой сессии; вместо ожидания истечения срока действия отправителю сразу сообщается об отказе. Где именно должны отображаться сохранённые сообщения для таких сессий, пока не определено.

Сессия регистрируется, если только её собственные настройки не отключают agents.crossSessionMessaging, или если она была запущена с параметрами --bare или --safe-mode — эти параметры отключают обмен сообщениями независимо от настроек. При отключении сессия остаётся невидимой, потому что единственная причина перечислять сессию, в которую нельзя отправить сообщение, — это реклама адреса, который никогда не отвечает.

Программы, которые не являются сессиями Qwen Code

Всё вышеперечисленное работает между сессиями, но ничего из этого не специфично только для них. Программа, которая сама создаёт запись в реестре и привязывает почтовый ящик аналогичным образом, отображается в qwen sessions ps и list_agents, может быть вызвана по имени из send_message и получает квитанции о доставке для отправленных сообщений — например, голосовой интерфейс, ретранслятор или наблюдатель за сборкой. Ей следует записывать kind: "external", чтобы список мог показать, что это за программа.

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

Программе на Node.js не нужно писать всё это вручную: @qwen-code/sdk/peer реализует контракт. PeerEndpoint.start({ name }) публикует запись и привязывает почтовый ящик, list() и send() обращаются к сессиям по имени, а onMessage принимает отправленные ими сообщения.