Qwen Code 预览版整合多入口编程智能体

Qwen Code 想做的，是让同一套 AI 编程能力进入终端、编辑器、浏览器和聊天工具，再由用户选择背后的模型与服务商。它的重点已经超出命令行问答，开始覆盖自动化、会话共享和多 Agent 协作。

这份 README 最值得看的有两部分：一是它怎样把这些入口连起来，二是它拿出了什么证据证明工具可靠。功能清单很长，但跑分、默认权限和实验状态，需要分开判断。

它想连接的，是整个编程工作流

Qwen Code 把 Auto-Memory、Auto-Skills、SubAgents、Agent Teams 和 MCP 列为开箱即用能力。可以把它们理解为：保存工作上下文、按任务使用技能、拆分任务给子 Agent，以及接入外部工具。不过，README 没有展开这些机制的边界，「zero setup」不能直接理解为接入任意项目都无需配置。

它支持 OpenAI、Anthropic、Gemini 和 Qwen APIs，也声明能够接入第三方服务商，以及通过 Ollama / vLLM 使用本地模型，并在运行时切换。

对程序员而言，这种设计的价值是保留选择权：交互入口和模型供应可以分别调整。但协议兼容不保证模型效果一致，README 也没有给出各家模型在工具调用、长任务执行上的对照结果。

入口包括 VS Code、Zed、JetBrains，以及 Telegram、DingTalk、WeChat、Feishu。官方 Qwen Code Desktop 支持 macOS、Windows、Linux；AionUi、Gemini CLI Desktop 则提供其他图形界面。项目正在扩展使用场景，但不能据此判断每个入口已经具备相同能力。

项目最初基于 Google Gemini CLI v0.8.2，从 Qwen Code v0.1 起停止同步上游，转向独立开发。理解这一点有助于判断它的定位：它正在发展为支持多协议、多平台的 Agent 框架。

从本地试用到自动化，应该走哪条路

原文区分了主版本与 Qwen Code 1.0 Preview，下面的安装说明对应主版本。对已经有 Node 环境的开发者，NPM 路径最直接：

npm install -g @qwen-code/qwen-code@latest

注意包名是 @qwen-code/qwen-code，NPM 安装要求 Node.js 22+；徽章给出的下限是 22.0.0。

原文还提供独立安装脚本，以及 macOS / Linux 下的 brew install qwen-code。安装后需要重启终端，让环境变量生效。进入项目执行 cd /path/to/your-project、qwen，再在会话里运行 /auth：可以选择 Qwen Account with Subscription，使用 Plus 或 Pro 订阅登录，也可以配置服务商的 API key。

第一次尝试，原文建议让它解释仓库并指出从哪里开始。这比直接交付大范围修改更适合检查它是否理解项目结构。

需要脚本化时，有两条主要路径：qwen -p "..." 用于脚本、CI/CD 和批处理；TypeScript、Python、Java SDK 用于自定义集成。下面这段 Python 示例展示了怎样指定项目目录并读取结果：

import asyncio

from qwen_code_sdk import is_sdk_result_message, query

async def main() -> None:
    result = query(
        "Summarize the repository layout.",
        {
            "cwd": "/path/to/project",
            "path_to_qwen_executable": "qwen",
        },
    )

    async for message in result:
        if is_sdk_result_message(message):
            print(message["result"])

asyncio.run(main())

要看的是 cwd 和 path_to_qwen_executable：前者指定工作目录，后者指定可执行文件。这个示例仍然依赖本机可用的 qwen，README 没有展示超时、失败重试或取消任务的处理方式。

共享会话很实用，默认权限也要看清

如果浏览器、编辑器和自动化客户端分别启动 Agent 进程，会话就容易分散。Qwen Code 的 Daemon 提供常驻服务，让多个客户端共享 Agent 会话，支持多个工作区，以及重新连接仍在运行的会话。

启动入口是 qwen serve，通过 HTTP + SSE（ACP）连接客户端；加上 --open，即 qwen serve --open，会打开内置 Web Shell。默认地址为 http://127.0.0.1:4170。后台管理则使用 qwen daemon start、qwen daemon status、qwen daemon logs -f 和 qwen daemon stop。

这条路径被原文标为 experimental，适合先验证自己的工作流。

默认只监听本机，不等于只有启动它的人能够调用。

README 明确说明：Daemon 默认没有 bearer authentication，能够访问该地址的本地进程，可以使用完整 API，其中包括代码执行。共享或不可信主机应设置 QWEN_SERVER_TOKEN，并使用 --require-auth。这直接影响能否把个人开发机上的配置搬到共享服务器。

原文还列出 Computer Use，可通过原生 MCP 工具或 Node REPL + SDK 配置；Qwen Code Claw 则让 Claude、Codex 等 Agent 经 ACP、通过 acpx 委派编码任务。这里展示的是扩展入口，README 没有提供这些组合的完整效果评估。

我的判断

我认可它把模型选择、交互入口和自动化接入放在同一框架里的方向。相较于只提供交互终端的工具，它给脚本和自定义客户端留出了入口；相较于各入口各自启动进程，共享会话也有明确用途。

但「与 Claude Code 功能对齐」目前仍是项目方的表述，不能当成效果相同的结论。

原文提供的实测是 SWE-bench Verified：使用同一个 Qwen 3.7 Max 模型，在 500 个任务上，对七个 Qwen Code 版本各进行三次试验，平均得分范围为 76.40%–77.80%。具体是 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%。

这组数据说明，不同版本在这套测试中的平均成绩接近；它没有显示持续上升，也不能证明前端页面开发、浏览器调试或团队协作同样可靠。原文没有提供 Claude Code 的同条件对照、成本和耗时，不能替它补出性价比优势。

框架与 Qwen 模型开源，有利于检查和调整实现；「没有厂商锁定」则还要看实际使用了哪些认证、工具和平台集成。团队使用自身 Agent 提 issue、交 PR、审查代码和运行测试，说明它进入了项目开发流程，但这不等于独立质量评估。

能拿来做什么

• 在现有前端或 Node 仓库里，先让它解释目录结构、入口文件和测试位置，再对照代码检查答案，用这个小任务判断它是否理解项目。
• 有批处理需求时，先用 qwen -p "..." 跑通仓库摘要等范围明确的任务；需要在程序中消费结果，再接入对应语言的 SDK。
• 经常切换编辑器和浏览器时，可以试用 Daemon，检查会话恢复是否符合习惯；部署到共享主机前，落实 QWEN_SERVER_TOKEN 与 --require-auth。
• 比较模型或版本时，保留同一组真实仓库任务，记录完成质量、耗时和费用；把 README 的跑分作为参考，再决定是否迁移日常工作流。