仓库现在的状态：约 28.7k stars，TypeScript 写的，2025 年 6 月 26 日创建，最近一次推送在 2026 年 10 月 25 日。README 里对它的定位是一句话——"The open-source AI coding agent for your terminal, editor, desktop, browser, and chat."。下面这些是我读 README 和 packages 目录之后的整理，不是公告的翻译。

终端里的 agent 与它的来源

它的起点不是从零写的。最早基于 Google Gemini CLI v0.8.2，等于直接继承了上游成熟的终端界面和工具调用循环；从 Qwen Code v0.1 起不再同步上游，转向独立开发，目标变成"多协议、多平台的 agent 框架"。

这个出身决定了它的形状：交互方式、斜杠命令、工具循环这些"壳"的部分是现成的，真正要自己做的是模型层和入口层。运行要求也写在 README badge 和 engine 字段里——Node.js 22 及以上，两个地方口径一致。

能力矩阵直接拿 Claude Code 做参照：SubAgents、Auto-Memory、Hooks、内置 Skills、MCP、Plan Mode、LSP、Sandbox、Git Worktrees、Computer Use、IDE 插件、SDK 都列在"持平"一栏；自称独有的只有几条——模型与框架都开源、多协议、Agent Arena（同任务多模型对战）、Daemon、IM 渠道。这份清单比数字更有信息量：主体能力对齐，差异在"能不能换模型"和"能不能嵌进别处"。

安装与首次启动

安装有三条路，Linux/macOS 用官方的一行安装脚本，Windows 用对应的 PowerShell 脚本，或者走包管理器。脚本地址在 README 里，这里不贴。

node -v                                   # 必须 22 及以上
npm install -g @qwen-code/qwen-code@latest
# 或者
brew install qwen-code

cd ~/work/your-repo
qwen                                      # 在项目目录里启动
# 进入会话后输入 /auth，选 provider、填 API key

/auth 这一步是理解它的关键：provider 不是启动参数，而是会话内的配置项。这意味着同一个终端窗口里可以换模型继续同一个任务，不用退出重开。

provider 抽象的落点

多协议支持放在 provider 层，而不是编译期选型，这是我认为它最值得看的一处设计。编译期选型的意思是打包时决定接哪家，运行时切换的意思是每次请求前都能决定。后者换来的是：同一批任务可以换模型对比、本地模型能当兜底、不同区域可以按合规要求走不同供应商。

代价是适配成本。下面这段是我按它的分层思路写的示意，不是仓库源码，用来说明抽象层至少要挡住什么：

type Wire = "openai" | "anthropic" | "gemini" | "qwen";

interface Provider {
  name: Wire;
  // 三家请求体的字段名、消息角色、工具声明格式都不同，各自翻译
  toRequest(messages: Msg[], tools: ToolSpec[]): unknown;
  // Anthropic 返回 tool_use block，OpenAI 返回 tool_calls，
  // Gemini 返回 functionCall，这里统一成一种内部表示
  parseToolCalls(resp: unknown): ToolCall[];
  parseUsage(resp: unknown): { input: number; output: number };
}

三个方法对应三类差异：请求形状、工具调用结果、用量统计。工具调用这一层最难，因为各家不只是字段名不同，流式返回的切分方式、并行调用的组织方式、参数是字符串还是对象都不一样。这套适配不是写一次就完的，供应商改一次 API 就得跟一次。

一个核心与多个前端壳

入口看起来很多：终端、桌面、Web UI、IDE 插件、IM 机器人，但结构上只有一个 agent 核心，其余都是壳。Web UI 用 qwen serve --open 起（README 标了实验性）；IDE 侧有 VS Code、Zed、JetBrains 三套；IM 侧通过 qwen channel start 接 Telegram、钉钉、微信、飞书。

能同时接 VS Code 和 Telegram，靠的是核心只对外暴露 ACP（Agent Client Protocol），走 HTTP + SSE。壳不关心内部怎么循环，只负责送输入、渲染流式事件。packages 的切法也印证了这点：cli、core、三套 SDK、web-templates、zed-extension、vscode-ide-companion 各自独立。

往外还有几个同协议的项目：Qwen Code Claw 让别的编码 agent 把任务委派给它，AionUi 做图形界面，qwen-audio-agent 做实时语音前端、支持打断和本地唤醒词，另有云厂商 CLI 在这之上扩展出图、视频与知识检索。协议统一之后，这些不用改核心就能长出来。

无头模式与 daemon

非交互用法是它区别于纯终端工具的地方。

# 单次任务：适合 CI 里的固定动作
qwen -p "检查 src/ 下新增的导出是否有对应单测，缺的列成清单写到 MISSING_TESTS.md"

# 常驻服务：HTTP + SSE，ACP 协议，给编辑器或自建前端连
qwen serve --port 8080

# IM 渠道
qwen channel start

SDK 有 TypeScript、Python、Java 三套，目标用户不只是"人手一个终端"，还包括把 agent 嵌进别人系统的人。无头模式和 daemon 是这类嵌入的前提。

从 Gemini CLI 分家的时机

fork 一个成熟项目再分家，是这件事里最需要判断的决策。它选的时间点是 v0.1：先继承 TUI 和工具循环，把最难写、最不值钱重写的部分拿到手，等自己的模型层和多协议跑通，再断开上游。

这个取舍很清楚：省掉的是界面打磨和工具调度调试这一大块成本，付出的是上游后续的改进不再自动进来——上游修了工具循环的 bug、加了新命令，这边要自己判断值不值得跟、跟了还要处理分叉。v0.1 这个位置偏早，说明它宁可多背一点同步成本，也要尽早把模型层攥在自己手里。

自举作为回归负载

项目用自身的 agent 和模型来提 issue、提 PR、review 代码、跑测试。这件事的价值不在宣传，在测试：每一次真实使用都在给核心循环制造负载，工具调用、上下文压缩、失败重试这些路径会被反复走到，比自己编的用例覆盖面大。

风险是回音室：模型自己的偏好会塑造工具设计，久了会往"模型爱用"而不是"人爱用"的方向偏。

评测里被固定的变量

SWE-bench Verified 上，它报了 7 个版本、平均 76.40% 到 77.80%，统一用 Qwen 3.7 Max，500 个任务、每个版本三次试验。分版本是 0.0.14 的 77.80%、0.1.0 的 76.73%、0.5.0 的 76.60%、0.10.0 的 76.47%、0.15.0 的 77.67%、0.19.0 的 76.40%、0.22.0 的 77.33%。这是项目官方口径，我没有复现。

值得学的是固定下来的变量：模型固定、任务集固定、每版跑三次取均值。缺一条，版本间就没法比——换个模型、换个子集、只跑一次，曲线可以随便画成上升的。它这套数字看着平（版本翻了不少，分数在 76 到 78 之间晃），反而说明测量是稳的。

局限

SWE-bench 测的是仓库内改 bug，多文件重构、跨模块设计、长任务覆盖不到，分数高不等于在你代码库里好用。

28.7k stars 说明的是热度，和生产环境里的实际使用量是两件事，很多 star 来自"先收藏"。

多协议听着美好，落到实现是常年维护成本：Anthropic 的 tool_use block、OpenAI 的 tool_calls、Gemini 的 functionCall，任意一家改形状，适配层就得动，而且这类 bug 往往只在特定模型的特定版本上出现。

上游已经分家，Gemini CLI 后来的改进不会自动进来，你得自己盯着。

无头模式和 daemon 适合 CI，但也意味着凭据怎么下发、沙箱怎么隔离、并发跑多个任务时工作目录怎么隔开，这些都得自己解决，它只提供通道。