Qwen Code 的 Agent 架构：从 Gemini CLI 分叉后，它如何把子代理并行、自动记忆与常驻 daemon 塞进终端

起点：它为什么从 Gemini CLI 分叉，而不是直接自研

Qwen Code 的源码历史里有一个容易被忽略的事实：它最初 fork 自 Google 的 Gemini CLI v0.8.2。这意味着它不是一个从零设计的 Agent 框架，而是站在 Google 已经验证过的终端 Agent 骨架之上，再替换掉模型后端、工具链和调度逻辑。这个选择很务实——终端 Agent 最难的部分不是『让模型写代码』，而是命令执行、权限边界、上下文窗口管理、工具结果回灌这些工程细节，Gemini CLI 已经把它们跑通了。分叉后，Qwen 团队把模型层换成自家的 Qwen3-Coder，并对框架做了适配，使它从『Google 的 CLI』变成『多协议的独立框架』。代价是它继承了上游的架构假设，比如以 CLI 为核心的交互模型，后续要往 IDE/浏览器扩展时，必须在这个骨架上嫁接，而不是重写。这解释了为什么它的插件、SDK 形态和 Gemini CLI 高度相似：本质是同一棵树上的分支。

SubAgents 与 Agent Teams：把『一个 Agent 串行干活』拆成并行流水线

传统编程 Agent 最常见的形态是单一 Agent 持有整个上下文，一步步读文件、改代码、跑测试。Qwen Code 的 SubAgents 允许父 Agent 派生子 Agent，每个子代理拥有独立的上下文窗口和工具权限，并行处理不同子任务——比如一个负责生成代码、一个负责写测试、一个负责文档。Agent Teams 进一步把角色固定下来：一个『修 bug 的代理』、一个『测试的代理』、一个『文档的代理』协同处理同一份任务。这解决了长任务里最痛的问题：上下文污染和串行等待。父代理负责协调、合并结果、处理冲突，子代理互不干扰。对照 Claude Code 的串行工具调用和 OpenCode 的并行，Qwen Code 的并行粒度更接近『把一个功能拆给多个工程师』，而不是『同一次对话里交替调用工具』。对多文件重构、批量代码审查这类可拆分任务，并行子代理的提速是结构性的，不是提示词层面的优化。

Auto-Memory 与 Auto-Skills：上下文不再每次从零讲起

Auto-Memory 跨会话保存任务历史、决策和模式，下次启动时直接注入相关上下文，避免重复解释项目背景。Auto-Skills 更进一步：它观察到你反复走同一套工作流时，自动把这套流程固化成可复用技能，随时间沉淀出项目专属的技能库。这两件事合起来，让 Agent 从『每次都像新员工』变成『越来越懂这个仓库的老人』。对照 claude-mem 这类外部记忆层插件，Qwen Code 把记忆和技能做成框架内建能力，不需要额外挂 Redis/Chroma 之类存储。代价是记忆的边界需要用户信任——它默认会把偏好和项目脉络写进本地存储，对强隔离场景要手动关掉。更重要的是，自动技能沉淀依赖工作流的可重复性，如果用户的操作高度随机，Auto-Skills 反而可能学到噪声。

qwen serve daemon：让 Agent 从『一次性命令』变成『共享基础设施』

qwen serve 启动一个常驻的 Agent 服务器，多个客户端可以同时连接，共享同一份记忆、技能和状态。这是和 Claude Code（纯本地交互）、OpenCode（CLI 优先）最不一样的一点：Qwen Code 明确提出『把 Agent 跑成团队共享服务』。一个开发者在自己的机器上起 daemon，同事通过端口接入，拿到的是同一个有记忆的 Agent，而不是每个人的孤岛。这个设计点指向一个判断——编程 Agent 的终局未必是『每人一个本地助手』，也可能是『团队一台常驻 Agent 服务器』。代价是运维面扩大：你要管端口、鉴权、共享状态的一致性，单人使用的复杂度上升。对安全团队来说，共享 daemon 意味着要像对待内部服务一样对待它，而不是一个本地脚本。

多供应商路由：把模型选择从硬编码变成运行时决策

Qwen Code 完整支持 OpenAI / Anthropic / Gemini / Qwen 四种 API，也能接 Ollama、vLLM 本地模型，运行时可自由切换供应商。这意味着同一个 Agent 框架，可以今天用 Claude 4 Sonnet 跑推理、明天换 Qwen3-Coder 跑生成，不被单一厂商绑定。对比闭源的 Claude Code 只能用 Anthropic 自家模型，这种『模型无关』是开源阵营的核心武器：当某个模型降价或升级，用户改个配置就能切换，不需要等厂商适配。代价是不同模型的工具调用格式、错误语义不一致，框架要做大量适配层，行为可预测性比单一供应商方案弱。在真实工程里，这意味着同一个任务在不同模型下可能走不同的工具链路径，调试时要多一层变量。

代价：分叉的债、本地化运维、以及它替代不了什么

把上面几层加起来，Qwen Code 的工程取向很清楚：用分叉换时间、用并行换吞吐、用 daemon 换共享、用多供应商换自由。但它替代不了三件事。第一，分叉意味着它 follow 上游安全修复有延迟，上游出现漏洞时补丁节奏不由自己完全掌控；第二，daemon 和多客户端共享状态带来新的运维与权限风险，单人使用的心理负担变成团队级的安全责任；第三，模型能力上限仍由所接的底座模型决定，框架本身不生产智能，再好的调度也救不回一个弱模型。它也不是给『完全不懂命令行』的用户准备的——浏览器扩展和 IDE 插件仍在实验阶段，真正的稳定体验仍在终端。

作者判断：Qwen Code 抢的是『可自托管 Agent 底座』这块地

如果只把它看成『又一个 Coding Agent』，会低估它的位置。Qwen Code 真正想要的是成为团队可以完全掌控、自己托管、随意换模型的 Agent 底座，而不是一个依赖某家云订阅的终端工具。在 2026 年编码 Agent 三强（Claude Code / OpenCode / Qwen Code）里，它靠『开源 + 免费 + 多供应商 + daemon』这组组合，抢的是重视数据主权和可定制性的那批用户。它的短板在推理质量峰值和生态成熟度，但当底座模型（Qwen3-Coder 及后续）继续变强，这块短板会慢慢补齐。对大多数团队，正确的用法是：把它放在『需要自托管或多模型路由』的场景，而不是指望它一夜之间在每项基准上都压过闭源对手。它不是一个更聪明的模型，而是一块更自由的底座。