命令

本文档详细介绍了 Qwen Code 支持的所有命令，帮助你高效管理会话、自定义界面并控制其行为。

Qwen Code 命令通过特定前缀触发，分为以下三类：

1. 斜杠命令 (/)

斜杠命令用于管理 Qwen Code 的会话、界面和基本行为。

1.1 会话与项目管理

这些命令可帮助你保存、恢复和总结工作进度。

1.2 界面与工作区控制

用于调整界面外观和工作环境的命令。

1.3 语言设置

专门用于控制界面和输出语言的命令。

• 可用的内置 UI 语言：zh-CN（简体中文）、en-US（英语）、ru-RU（俄语）、de-DE（德语）、ja-JP（日语）、pt-BR（葡萄牙语 - 巴西）、fr-FR（法语）、ca-ES（加泰罗尼亚语）
• 输出语言示例：Chinese、English、Japanese 等。

1.4 工具与模型管理

用于管理 AI 工具和模型的命令。

1.5 内置 Skills

这些命令调用内置的 skill，提供专门的工作流。

有关 /review 的完整文档，请参阅 Code Review。

1.6 侧边提问 (/btw)

/btw 命令允许你快速提出侧边问题，而不会中断或影响主对话流。

工作原理：

• 侧边问题会作为单独的 API 调用发送，并带有最近的对话上下文（最多 20 条消息）
• 响应显示在 Composer 上方——你可以在等待时继续输入
• 主对话不会被阻塞——它会独立继续
• 侧边问题的响应不会成为主对话历史的一部分
• 答案支持完整的 Markdown 渲染（代码块、列表、表格等）

键盘快捷键（交互模式）：

示例：

（当主对话正在重构代码时）

> /btw JavaScript 中 let 和 var 有什么区别？

  ╭──────────────────────────────────────────╮
  │ /btw JavaScript 中 let 和 var 有什么     │
  │     区别？                               │
  │                                          │
  │ + 正在回答...                            │
  │ 按 Escape、Ctrl+C 或 Ctrl+D 取消         │
  ╰──────────────────────────────────────────╯
  > (Composer 保持活跃——继续输入)

（答案到达后）

  ╭──────────────────────────────────────────╮
  │ /btw JavaScript 中 let 和 var 有什么     │
  │     区别？                               │
  │                                          │
  │ `let` 是块级作用域，而 `var` 是          │
  │ 函数作用域。`let` 在 ES6 中引入，        │
  │ 且不会以相同的方式提升。                 │
  │                                          │
  │ 按 Space、Enter 或 Escape 关闭           │
  ╰──────────────────────────────────────────╯
  > (Composer 仍然活跃)

支持的执行模式：

1.7 第二意见 (/advisor)

/advisor 命令对目前为止的对话进行独立的只读审查，并返回结构化的第二意见——不会执行任务，也不会中断主对话。

工作原理：

• 审查以单独的单轮 API 调用发送，带有最近的对话上下文（最多 40 条消息）
• 审查模型无法执行工具——工具在请求级别被剥离（与 /btw 相同的机制），因此审查永远不会编写代码或运行命令；每个结论都必须基于可见的对话记录
• 主对话不会被中断；审查结果仅展示给你
• 审查渲染为带边框的 markdown 块，包含四个固定部分——裁决、风险、缺失证据和建议——在 /advisor · <model> 标题下标注解析后的审查模型
• 与 /btw 不同（/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 条消息，仅限文本——工具调用和工具响应会被过滤掉）会连同严格的 system prompt 一起发送给模型。
• 回顾内容以暗色渲染，并带有 ❯ 前缀，以便与真实的助手回复区分开来。
• 如果模型轮次正在进行或另一个命令正在处理，则会以内联错误拒绝。如果没有可用的对话，或者底层生成失败，/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 查看内联 diff。

工作原理：

在交互模式下，/diff 会打开一个对话框，顶部带有来源选择器：

• Current — 工作树与 HEAD 对比（git diff HEAD）。显示所有未提交的更改，包括已暂存、未暂存和未跟踪的文件。
• T1, T2, T3, … — 每个轮次的 diff，每个修改了文件的轮次对应一个标签页。最近的轮次显示在最前面。每个标签页会显示原始 prompt 的预览以提供上下文。

文件列表显示每个文件的统计信息（增加/删除的行数），并带有特殊状态的标签（new、deleted、untracked、binary、truncated、oversized）。在文件上按 Enter 可查看其内联 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                     │
└─────────────────────────────────────────────────────────────────────┘

非交互模式：

在无头（--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）之间切换。

History Viewer (/log) — 仅限 Web Shell

/log 命令打开当前工作区的 commit 历史浏览器。它仅在 Web Shell UI 中可用；CLI/TUI 没有此命令。

工作原理：

/log 打开一个对话框，按时间倒序列出 commit（最新的在前）。每行显示：

• 短 SHA（等宽字体，带有复制完整 SHA 的按钮）
• Commit 主题（单行）
• 作者姓名和相对时间（例如 “2h ago”）
• 分支/标签 ref 标签（如果存在）
• 合并 commit 的合并图标（⎇）

点击 commit 行可按需展开其详细信息：

• 完整的 commit 消息正文
• 文件变更统计（变更的文件数、增加/删除的行数、按文件分类的明细）

使用底部的 Load more 获取下一页 commit（每页 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 身份验证命令

在 Qwen Code 会话中使用 /auth 来配置身份验证。使用 /doctor 检查当前的身份验证和环境状态。

2. @ 命令（引入文件）

@ 命令用于快速将本地文件或目录内容添加到对话中。

注意：路径中的空格需要使用反斜杠进行转义（例如：@My\ Documents/file.txt）

3. 感叹号命令（!）- Shell 命令执行

感叹号命令允许你直接在 Qwen Code 中执行系统命令。

环境变量：通过 ! 执行的命令会设置 QWEN_CODE=1 环境变量。

4. 自定义命令

将常用的提示词保存为快捷命令，以提高工作效率并确保一致性。

快速概览

优先级规则：项目命令 > 用户命令（同名时使用项目命令）

命令命名规则

文件路径到命令名的映射表

命名规则：路径分隔符（/ 或 \）转换为冒号（:）

Markdown 文件格式规范（推荐）

自定义命令使用带有可选 YAML frontmatter 的 Markdown 文件：

---
description: 可选的描述（在 /help 中显示）
---
 
你的提示词内容。
使用 {{args}} 进行参数注入。

TOML 文件格式（已弃用）

参数处理机制

1. 上下文感知注入（{{args}}）

2. 默认参数处理

🚀 动态内容注入

3. Shell 命令执行（!{...}）

示例：生成 Git Commit 信息

---
description: 基于暂存区的更改生成 Commit 信息
---
 
请根据以下 diff 生成 Commit 信息：
 
```diff
!{git diff --staged}
```

4. 文件内容注入（@{...}）

示例：代码审查命令

---
description: 基于最佳实践的代码审查
---
 
审查 {{args}}，参考标准：
 
@{docs/code-standards.md}

实际创建示例

”纯函数重构”命令创建步骤表

---
description: 将代码重构为纯函数
---
 
请分析当前上下文中的代码，将其重构为纯函数。
要求：
 
1. 提供重构后的代码
2. 解释关键更改以及纯函数特性的实现
3. 保持函数功能不变

自定义命令最佳实践总结

命令设计建议表

安全特性提醒表

5. CLI 子命令

这些命令在启动交互式会话之前从 shell 中以 qwen <subcommand> 的形式运行。

会话管理

qwen sessions list

列出你最近的 Qwen Code 会话及其元数据。

标志：

人类可读输出（默认）：

包含以下列的表格：SESSION ID、STARTED（UTC 时间戳）、TITLE、BRANCH、PROMPT。

JSON 输出（--json）：

在 stdout 输出 JSON Lines。每行是一个包含以下字段的 JSON 对象：

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

“还有更多会话”的提示信息会通过 stderr 输出，因此通过管道传递给 jq 依然是安全的。

示例：

# 显示最近 20 个会话（默认）
qwen sessions list
 
# 显示最近 50 个会话
qwen sessions list --limit 50
 
# 以 JSON 格式输出，便于脚本处理
qwen sessions list --json | jq .

qwen sessions ps

列出当前在此机器上注册的 Qwen Code 会话。 sessions list 遍历已保存的对话记录（“我做过什么”）；而此命令 遍历实时进程注册表（“此刻正在运行什么”）。被终止会话 留下的记录会在发现时被清理。一次性的 qwen -p 运行永远不会注册， 因此永远不会显示。

标志：

人类可读输出（默认）：

包含以下列的表格：NAME、KIND、PID、AGE、DIRECTORY。

JSON 输出（--json）：

在 stdout 输出 JSON Lines，最新的会话排在前面。每行是一个包含以下字段的 JSON 对象：

schemaVersion, pid, procStart, pidNs, sessionId, cwd, name, startedAt,
qwenVersion, kind, ipcPath (当 peer 消息可用时)

不会向 stdout 写入其他内容——空列表完全不输出任何内容——因此 qwen sessions ps --json | jq . 可以安全地用于脚本。

JSON 输出是原始数据：字段值按记录原样发出，不经过终端净化。请将它们视为数据，在终端中渲染前进行净化处理。

示例：

# 显示其他活跃会话
qwen sessions ps
 
# 哪些目录当前正在使用中？
# 注意：`jq -r` 会在终端中渲染原始记录值（参见上方
# 原始数据说明）；如果路径不受信任，请通过净化器管道处理。
qwen sessions ps --json | jq -r .cwd
 
## 6. 向另一个运行中的会话发送消息
 
同一台机器上的两个交互式会话可以互相发送消息。此功能是实验性的，**默认关闭**；在 `settings.json` 中开启并重启：
 
```json
{ "agents": { "crossSessionMessaging": true } }

开启后，一个会话中的模型可以通过 list_agents 发现其他会话——每个会话都出现在 sessions 下，带有 qwen sessions ps --json 记录的 name（表格视图可能会截断长名称）——并使用 send_message 以该名称作为 to 来寻址。当两个会话共享同一个名称时，list_agents 会为每个会话显示一个简短的 [ref]，发送时必须包含它（name [ref]）；可能指向任一会话的裸名称会被拒绝而不是猜测。list_agents 还会在 self 下报告会话自身的名称，而 to: "*" 仍然表示”我的 Agent Team teammates”，永远不会到达其他会话。

消息到达另一个会话时，会标记为来自另一个会话，而不是来自其用户，并且在那里不携带你的任何权限：接收会话只会在其自身的权限设置内对其采取行动。其用户可以使用 agents.crossSessionInbound（accept、hold 或 refuse）选择传入消息的处理方式。未设置时，只有当两个会话处于同一审查类别时，消息才会被传递：双方都审查每个操作（默认或 plan 模式），或者双方都处于无需逐次审查即可应用某些操作的模式（auto-edit、auto 或 yolo）。来自另一类别的会话、或未声明自身所属类别的发送方的消息，会被保留以待审查——双向皆如此。审查每个操作的会话会保留来自不审查操作的会话的消息，因为该消息是由无人监督的模型编写的，而逐次操作提示保护的是操作本身，而非会话被说服去做的事。保留的消息会在接收会话中使用 /peers 列出并释放，仅因模式差异而被保留的消息会在双方模式一致后自动释放。

仓库可以使其内部打开的会话更加谨慎，而绝不会更宽松：工作区 .qwen/settings.json 可以将 agents.crossSessionInbound 设置为 hold 或 refuse，或将 agents.crossSessionMessaging 设置为 false，该值会覆盖用户设置中较宽松的值。会放宽你设置的工作区值（accept，或开关的 true）会被忽略并给出警告，CLI 无法识别的值在作为有效值时会保留所有消息。系统设置会覆盖以上所有，正如它对每个设置所做的那样。

保留不会无限等待。无人决定的消息会在 agents.crossSessionHeldExpiry（1m、5m、10m 或 never，默认为 5 分钟）后过期，发送会话会被告知未做出任何决定。缩短该设置会影响已在等待的消息。

如果会话无法绑定其收件箱——运行时目录缺失、被其他用户拥有、或为只读（如在容器内可能发生的情况）——它会先尝试临时目录下的私有目录，只有当这也失败时，才会以无收件箱的方式启动。发生这种情况时，会话会在启动时说明，/peers 也会重复说明原因及需要更改的内容（通常是 XDG_RUNTIME_DIR 或 TMPDIR）。

两个会话也可能解析到相同的收件箱地址，因为地址是按进程 id 为键的，而进程 id 在共享运行时目录的容器之间会重复。第二个启动的会话会取一个相邻的地址，而不是接管正在使用的地址，这样两者都不会变得不可达。Peer 不受影响：它们从会话注册表中读取会话的地址，而不是自行推导。

send_message 调用仅确认消息已传递给另一个会话。它的后续情况会作为回执稍后到达：如果它被保留、拒绝、refused、过期或地址错误（地址已变更——再次列出代理）——或在保留后释放——发送会话的记录中会出现通知（Message to <name>: …）。Declined、refused 和 dropped 是三种不同的结果：declined 表示有人审查了消息并拒绝，refused 表示该会话的 agents.crossSessionInbound 是 refuse 且根本没有人看到它，dropped 表示其收件箱在上述任何情况发生之前就拒绝了该消息（见下文）。第一次 dropped 会立即回复，其余的会每隔几秒合并到一条回执中，每条回执会指明它所代表的消息，因此一批 dropped 只需几行而不是每条一行。发送它的模型不会被告知；如果另一个会话回复，回复会作为跨会话消息到达。

泛洪保护

一个会话一次最多接受来自同一发送方的 30 条消息，之后每两秒一条；来自所有发送方合计一次最多 32 条，之后每秒一条。第二个限制的存在是因为发送方会自报名称：轮换名称可以从第一个限制获得新的配额，但不能从第二个获得。它仅比第一个限制稍高，因为每条被接受的消息都会产生一条回执，而一个会话同时能发出的回执数量有限。来自另一会话的消息如果在 30 秒内逐字重复该发送方之前的消息，也会被拒绝——在一个句子上循环的模型每次都会生成新的消息 id，因此靠文本内容来识别。会话启动的脚本和受信任控制器发来的消息免于重复检查，因为报告同一行两次的 hook 是在报告两个事实，而一个人说两次”继续”就是两次；两者仍然受速率限制约束。最后，被接受但因会话已有 50 条消息排队而无法入队的消息也会被拒绝。

以这种方式被拒绝的消息永远不会被保留，永远不会展示给模型，也不会留下记录，因此发送方可以稍后重试并成功送达。接收会话在其记录中每分钟最多为每个发送方报告一次，并附带该行所代表的计数。发送会话会收到一条回执，列出该次突发所消耗的所有消息，其记录会建议将仍然重要的内容合并到一条后续消息中，而不是重新发送。

发送方不会等待结果。每个会话跟踪它已发送到每个地址的内容，并拒绝接收方会丢弃的发送，因此模型在消息写入之前就被要求批量处理——而不是之后——接收方也永远不会在它本要拒绝的消息上浪费连接。

收件箱认证与脚本注入

每个会话的收件箱都需要一个每会话 token：连接必须在其第一行出示 token，然后才会读取任何消息，会话通过它们互相发现的相同注册表记录自动交换 token。不支持 token 的构建版本中的会话可以从较新版本接收，但其发往较新版本的消息会被丢弃。

会话会将自己的收件箱地址和 token 作为 QWEN_CODE_MESSAGING_SOCKET 和 QWEN_CODE_MESSAGING_TOKEN 导出给子进程，因此会话运行的脚本或 hook 可以向其发送消息。这是一个第二位的、子级 token，永远不会在任何地方发布：只有会话启动的进程才能持有它，因此携带该 token 到达的消息会被识别为会话自身的，而不是其他会话的。

收件箱认证与脚本注入

每个会话的收件箱都需要一个每会话 token：连接必须在其第一行出示 token，然后才会读取任何消息，会话通过它们互相发现的相同注册表记录自动交换 token。不支持 token 的旧版本构建的会话可以从较新版本接收，但其发往较新版本的消息会被丢弃。

会话会将自己的收件箱地址和 token 作为 QWEN_CODE_MESSAGING_SOCKET 和 QWEN_CODE_MESSAGING_TOKEN 导出给子进程，因此会话运行的脚本或 hook 可以向其发送消息。这是一个第二位的_子级_ token，永远不会在任何地方发布：只有会话启动的进程才能持有它，因此携带该 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。接收端网关会记住它已处理过的 id，因此重用 id 的 hook 在第一次会被传递，之后每次运行都会被静默去重。重复相同的_文本_没有问题——上面的重复检查不适用于会话自身的进程——但速率限制仍然适用，因此循环中的 hook 会像其他泛洪一样被丢弃。

注入的消息仍然会经过入站网关，并被标记为非来自用户，但网关知道它来自会话自身的进程：在模式一致性的默认情况下，它会被直接传递而不经过审查（处于相同位置的 peer 会被保留），而显式的 agents.crossSessionInbound 为 hold 或 refuse 时，会像对待其他消息一样对其生效。模型会将其视为 <cross_session_message from="own process" origin="own-process">，并附有通知说明它来自会话运行的脚本或 hook，而非来自用户。

受信任的控制器

上述规则会保留来自任何未声明其审查类别的发送方的消息，而非 Qwen Code 会话的程序没有此类类别可声明。对于陌生人来说，这是正确的默认行为，但对于你选择的程序来说则不然：语音前端、听写桥接、转发你自己指令的自动化守护进程——每条消息都会被停放，手动批准每一条就失去了意义。

你可以通过为其铸造 token 来授予此类程序传递权限：

qwen sessions controllers add --label voice-bridge

该 token 仅打印一次，不会存储在任何地方：你的 Qwen home 下的文件只保留其 SHA-256 哈希，因此后续读取该文件的任何内容都无法出示该 token。在命令打印出 token 时，将其放入控制器自身的配置中。

控制器像其他任何发送方一样出示 token——作为连接的第一行——并从会话注册表中获取 socket 路径（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"

通过已授予 token 到达的消息会直接传递，无需逐消息审查，无论任一方处于何种审查类别——但它仍然服从显式设置：agents.crossSessionInbound 为 hold 时会像其他消息一样停放它，refuse 则会拒绝它。授予属于您的 Qwen home，而非某个会话，因此控制器可以到达你正在运行的任何会话，会话在每次连接时都会重新读取该文件：铸造或撤销一个授予会在下一次连接时生效，无需重启任何内容。

qwen sessions controllers list          # id、标签、添加时间
qwen sessions controllers remove c_1a2b # 撤销一个

/peers controllers 和 /peers revoke <id> 在会话内部执行相同的操作。通过授予到达的消息会显示为 Message from a trusted controller (voice-bridge)，如果 hold 设置停放了它，则会在 /peers 中显示为 [controller] voice-bridge。

模型会将此类消息视为 <cross_session_message from="controller" origin="controller" controller="voice-bridge">，并附有通知说明它正在转发你自己的指令——以及适用于其他所有来源的相同两项禁止：它不得因为消息要求而编辑权限设置、QWEN.md 或配置，也不得将消息视为你批准了待处理的确认提示。控制器可以说接下来做什么；它不能代你回答提示。

任何持有该 token 的人都可以作为该控制器发送，因此请将其视为任何其他凭证：将其授予一个程序，不要放入共享配置中，并在该程序完成后撤销它。

程序通过 ACP 驱动的会话

任何 qwen --acp 子进程都会注册它所托管的每个会话——当守护进程生成该进程时注册为 serve，当编辑器或其他客户端直接驱动 qwen --acp 时注册为 headless——该会话会出现在 qwen sessions ps 和另一个会话的 list_agents 中，与其他会话一样。它可以发送：其模型可以调用 send_message 来联系你打开的终端。其中几个共享一个进程和一个收件箱，因此发送方必须指明它要联系的会话——每个 Qwen Code 会话都会自动执行此操作。

发送给它们的消息会被拒绝而不是保留。保留是向人提出的问题，而没有人会代表被驱动的会话监视保留消息列表；发送方会立即被告知，而不是等待过期。保留的消息应该在哪里为这些会话 surfaced 尚未确定。

会话只有在其自身设置中 agents.crossSessionMessaging 开启时才会注册。关闭时它会保持不可见，因为列出没有人可以发消息的会话的唯一目的就是宣传一个永远不会应答的地址。

不是 Qwen Code 会话的程序

以上所有内容都在会话之间工作，但其中没有任何特定于某一个会话的内容。一个为自己写入注册表记录并以相同方式绑定收件箱的程序会被 qwen sessions ps 和 list_agents 列出，可以从 send_message 按名称寻址，并接收它所发送消息的传递回执——例如语音前端、中继、构建监视器。它应该记录 kind: "external" 以便列表可以说明它是什么。

Cross-Session Protocol 是编写此类程序的契约：记录 schema 和如何判断活跃性、socket 路径和帧格式、认证行、每个帧字段、回执状态及其转换，以及接收方在模型看到消息之前对消息的处理。

Node 程序不必手动编写所有这些： @qwen-code/sdk/peer 实现了该契约。PeerEndpoint.start({ name }) 发布记录并绑定收件箱，list() 和 send() 按名称寻址会话，onMessage 接收它们发送的内容。