最近我注意到一个很有意思的现象：Qwen Code开始不再满足于当一个"老老实实写代码的助手"，它现在会调度其他编程助手干活。GitHub上有人把Qwen Code当作一个总控台，把Claude Code、Codex、甚至本地用llama.cpp跑起来的小模型助手全部串起来，让它们各干一段，最后汇总结果。这个玩法被叫做多代理工作流（multi-agent workflow）。

我第一次看到这个用法时挺吃惊的。以前大家的思路都是"哪个编程助手最聪明我就用哪个"，现在反过来了：一个助手负责安排任务，其他助手负责执行。这个思路转变很有意思，也值得好好聊一聊。这篇文章我想结合我自己的实操经验，把"Qwen Code调度其他编程助手"这件事的前因后果、配置方法、典型场景和踩坑经验一次讲清楚。

1. 当编程助手开始管理编程助手：多代理不是把模型叠起来比赛

1.1 从"单一助手"到"调度中枢"，Qwen Code的角色发生了什么变化

在过去一年多里，AI编程助手的形态经历了三个阶段。最开始是IDE里的补全插件，你写一半它给你续写；然后是终端里的对话式助手，你把整个需求丢给它，它自己在文件系统里跑来跑去；现在到了第三阶段，出现了以Qwen Code为代表的"调度型助手"。

什么叫调度型助手？就是它本身具备完整的Agent能力——能读文件、能执行命令、能搜索代码库、能自己规划任务步骤，同时它还开放了子代理（Subagent）和外部工具调用（MCP）的能力。这意味着你可以在一个Qwen Code会话里，让它去调用另外一个编程助手的命令行，把一部分任务派发出去。

我在本地的实际操作是这样：主会话由Qwen Code控制，它的系统提示词里写清楚了哪些任务要自己完成、哪些任务要委派出去。当我丢给它一个"重构支付模块"的需求时，它先自己扫了一遍代码结构，然后把"生成接口文档"这个子任务交给了子代理，把"跑一轮单元测试并总结覆盖率变化"交给了另一个外部助手，最后把两个返回结果合并起来，自己写了重构方案。

这个过程里，Qwen Code的角色已经从"执行者"变成了"项目管理者"。它不再对所有代码细节亲力亲为，而是更像个技术组长，负责拆活、派活、验收。

1.2 为什么"调度"比"替换"更实用：模型各有各的短板

很多人会问一个问题：既然Qwen Code本身就能写代码，为什么还要费劲去调度其他助手？直接用最强的那个模型不就行了？

答案很简单：因为目前不存在一个在所有方面都最强的编程助手。不同模型在不同任务上的表现差异非常大。我自己的体感是这样：

• 某些模型在长上下文理解、多文件间跳转上很强，适合做架构分析和全局重构；
• 某些模型在单文件代码生成上速度极快、风格统一，适合批量生成样板代码；
• 某些模型在代码审查上更细心，能发现别人注意不到的边界条件；
• 本地小模型虽然智商不如云端大模型，但胜在免费、离线、跑批量任务不心疼。

如果只把全部希望押在一个模型上，相当于让一个全栈工程师同时干架构、编码、测试、运维的活，他再厉害也会疲倦。多代理工作流的本质，就是把合适的工作交给合适的模型，让Qwen Code在中间做协调。

这个思路还有一个额外的好处：节省预算。我测试过，如果所有任务都由一个高端模型完成，一次大重构要消耗不少费用，而把重复性的、低难度的任务派给本地模型或廉价模型，整体成本能降一半以上。

1.3 多代理工作流的核心：任务拆解、委托、回收

多代理工作流听起来高大上，拆开看其实就是三个动作：拆解、委托、回收。

拆解指的是主代理把一个大需求分解成若干个可以独立完成的小任务。委托指的是把这些小任务分配给不同的子代理或外部助手去执行。回收指的是主代理等所有子任务结果返回后，再统一整理、判断、合并。

拿我做过的一个真实项目举例。我需要把一套旧版Java的报表系统迁移到Python，代码量不算大，但涉及面广。我让Qwen Code做主控，第一步先拆解任务："扫描Java源码目录，列出所有报表SQL语句"、"统计Java类之间的依赖关系"、"把核心报表计算逻辑翻译成Python"、"生成迁移对照文档"。然后按任务难度，把第一、二个子任务分配给一个速度更快的模型，第三个分配给了Qwen Code自己，第四个分配给了本地模型。最后等所有结果回来，Qwen Code统一校验了一遍代码风格和接口是否对得上。

整个流程跑完，最直观的感受是：主代理不需要对每个子任务都亲力亲为，它只需要给足上下文、把验收标准说清楚，然后等着收作业。这一点和带团队很像：管理者最重要的能力不是自己写一切代码，而是把一个目标拆到每个人都能执行的程度。

提示：拆解任务时，越小的子任务越容易被不同的模型稳定完成。如果你把一个"重构整个系统"的大任务直接扔给子代理，它大概率会手足无措，效果远不如"扫描xxx目录并列出所有yyy模式"这种精确指令。

2. 先别急着上多代理：什么样的任务值得组队

2.1 适合多代理的三种典型场景：跨语言重构、并行文档、独立审查

多代理不是装饰品，用不好反而增加混乱。根据我的经验，以下三类场景最适合上多代理工作流。

第一类，跨语言迁移或重构。这类任务天然可以切分为"读源码""写目标代码""对照验证"三个阶段。读源码的模型不需要很聪明，能准确提取结构和逻辑就行；写目标代码的模型需要对目标语言有深刻理解；验证环节又需要一双冷静的"眼睛"。三个阶段交给三种不同能力的助手，效果通常比一个助手从头干到尾要好。

第二类，大规模文档生成。比如代码库注释补全、API文档生成、CHANGELOG整理。这些任务彼此之间几乎不依赖，完全可以并行。我试过用Qwen Code把代码库按模块切分，一次启动四个子代理分别处理一个模块的文档，最终汇总速度比单代理快很多。

第三类，代码审查和测试分析。让写代码的助手去审查自己刚写的代码，等于让作者自己找自己的问题，效果一般。多代理可以把"写代码的人"和"审查代码的人"分开，用不同的系统提示词约束审查者的视角——比如明确要求审查者只关注并发安全、只关注SQL注入风险、只关注可维护性。我实践下来的效果是，换一个模型做审查，找出的问题通常和写代码的模型发现的问题互补性很强。

2.2 哪些场景千万别用多代理：没必要硬凑

多代理工作流也有完全不适合的时候。我踩过的坑包括：

• 单文件小改动、修复一个明显Bug，这种任务一个代理一分钟就搞定，拆给多个代理纯属浪费时间。
• 任务之间存在严重的上下文依赖。比如A的输出必须完全作为B的输入，且中间不能有偏差，一旦割裂成两个代理，传递信息的损耗可能比收益还大。
• 场景本身就是"需要在一个长上下文里不断追问"的对话式开发，拆成多个代理反而破坏了连续性。

判断标准其实很朴素：如果这个任务你一个人干也很快，就不要拉团队。多代理解决的是"复杂、可并行、可割裂"的问题，不是所有问题。

2.3 算一笔成本账：多代理比单代理贵还是便宜

这个问题很多人关心。我以一次中等规模重构为例做过一个粗略估算。假设总消耗为一万五千个token量级的工作量：

• 单代理方案：所有token都跑在一个高端模型上，假设单价较高，总费用按相应计费走，耗时较长。
• 多代理方案：其中三分之一的token跑在本地小模型上，三分之一跑在中端模型上，只有三分之一跑在高端模型上，整体费用差不多能省下四到六成。

注意，我这里说的是"token消耗的分配"而不是总token变少。实际上多代理方案的总token消耗通常比单代理多，因为它有多次任务描述、结果返回的开销。但由于贵模型和便宜模型之间存在价格差，合理的分配反而让总费用更低。

当然，如果你的代理全部接入的是同一个高端模型，那么多代理不会省钱，反而因token开销增加而更费钱。所以省钱的前提，是你手上确实有多个不同价位的模型可用——这也是为什么本地模型（如llama.cpp）在多代理工作流里这么受欢迎。

3. 落地配置：把Qwen Code和各路助手接起来

3.1 最小配置：命令行层面直接调用另一个助手

最朴素的接入方式，是让Qwen Code通过命令执行来调用其他编程助手的CLI。比如你在终端里装了两个编程助手，一个叫codex，一个叫claude（当然这里泛指你已有的任何命令行助手），而Qwen Code本身具备执行shell命令的能力。你只要在给它的指令里写明：

请使用 codex 这个命令行工具，对当前目录下的 src/legacy 进行分析， 让它只输出一份类依赖清单，结果保存到 /tmp/deps.txt。

Qwen Code收到指令后，会自己拼出对应的CLI调用命令，然后执行，再把结果文件读回来。这种方式不需要任何特殊配置，只要你的环境里已经有这些CLI工具且它们的命令格式稳定即可。

我给这个方法起名叫"弱耦合接入"。它的优点是最简单、最灵活，缺点也很明显：主代理对执行结果的解析完全依赖工具输出的文本格式，一旦对方输出格式变了，后面的处理可能出错。所以用这种方式时，最好在子任务指令里明确要求"输出格式为纯文本清单，不要有额外解释"。

3.2 通过模型切换工具接入第三方模型：cc switch这类工具的作用

现在有另一类更高级的玩法，就是借助模型切换工具，把一个编程助手的后端模型换成完全不同的厂商模型。比如热搜里提到的cc switch，它本质上是一个配置管理工具，专门用来维护多个模型供应商的API配置。它可以把DeepSeek、GLM、Qwen等不同模型厂商的密钥和模型名写到某个助手的配置文件里，运行一条命令就能切换。

当这个切换能力和多代理工作流结合起来，就出现了很有意思的形态：同一个"助手的壳"，通过cc switch在不同API端点和不同模型之间快速切换，从而扮演不同角色的子代理。

我在本地的用法是这样：给Qwen Code配一个"编码代理"角色，让它默认使用Qwen模型；另外通过cc switch提供一套"审查代理"配置，把同一个编程助手框架切换到DeepSeek或其他模型的API上。两套配置并存，用不同的会话分别启动，Qwen Code作为主控，根据需要启动不同后端模型的会话执行子任务。

有人可能会问，为什么不在一个会话里切来切去？因为编程助手的会话上下文是独立的，来回切换容易把上下文搞混。我踩过的坑就是试图在一个会话里多次切换模型后端，结果工具状态混乱，个别情况下配置文件里的模型名没能恢复，后续请求全部失败。所以我的建议是：每个子代理角色使用独立会话、独立工作目录、独立配置，主代理只负责收结果。

注意：cc switch这类工具的关键配置项一般包括API地址、密钥、模型名称、请求超时时间。配置完一定要先跑一个最小测试，确认当前切换生效，再进入正式流程。不然你以为是A模型在干活，实际可能是B模型，整个多代理的"角色分配"就全乱套了。

3.3 本地模型搭配llama.cpp：离线辅助代理的玩法

把本地模型纳入多代理工作流，是我觉得性价比最高的一种方式。llama.cpp提供了llama-server组件，可以把量化后的模型文件（GGUF格式）启动成一个本地API服务，接口风格兼容OpenAI。这意味着任何支持自定义API地址的编程助手，都可以直接指向http://127.0.0.1:8080/v1，把它当成一个完全离线的模型后端。

我在一台配置平平的机器上用llama.cpp跑了一个小模型，专门用来承担不需要太强推理能力的任务：提取日志中的关键信息、批量给代码文件写文件头注释、把结构化文本转换成JSON格式。启动命令大致是：

llama-server -m /models/Qwen3-4B-2507-Q4_K_M.gguf --port 8080 --ctx-size 8192

启动之后，在编程助手的配置里把API地址指向本地服务，模型名填本地标注的名称。然后我让Qwen Code把简单的、重复性的子任务直接派给本地服务，把复杂的、需要全局推理的任务留给自己。整个过程不需要网络，不需要为每个token付费，批量任务随便跑。

本地模型的优势是零成本、离线可用、隐私安全，但它的输出质量和稳定性确实不如大模型。我在实测中常见的问题是：小模型偶尔会漏掉指令里的一些约束条件，比如让它"只输出文件列表"，它还是加了一段解释文字。解决方法是把指令写得更死板一点，甚至给它一个输出模板，效果会好很多。

3.4 在VS Code里跑多代理工作流的方式

如果不想离开IDE，也有方案。在VS Code里，你可以在集成终端中同时开多个终端标签，每个标签跑一个不同后端模型的编程助手会话。配合VS Code的多窗口布局，可以把终端区域上下或左右分屏，主控会话和子代理会话同时可见。

另外一类做法是使用MCP服务扩展。MCP（Model Context Protocol）让编程助手可以暴露和调用外部工具。你可以在Qwen Code上配置MCP服务器，把一个外部编程助手封装成一个MCP工具。这样一来，Qwen Code在主会话里可以把子任务作为工具调用发出去，比纯命令行解析更规范。

不过说实话，MCP方式虽然好，配置成本也高。我的建议是：如果你的子代理数量不多、任务不复杂，直接用命令行或切换工具就够了；等你在生产环境里跑久了，再考虑MCP封装。

4. 一组真实任务拆解：从需求到多代理流水线

4.1 一个具体的例子：让旧系统代码"开口说话"

下面我把我实际跑过的任务完整复盘一遍，给大家一个可以直接参考的流程。这个任务的背景是：我有一个旧项目，代码里充满了缺少注释的历史遗留代码，团队想先搞清楚这套系统的模块边界，再决定从哪里开始重构。

如果只用一个编程助手，过程会很痛苦：它需要从头读完全部代码，然后给你一份可能很笼统的梳理报告。而我用多代理工作流是这样拆的：

• 主代理（Qwen Code）：负责整体规划、派发任务、汇总结果；
• 子代理A（接第三方模型服务）：扫描src/modules/下所有Java文件，提取每个文件的类名、继承关系和主要方法签名，输出结构化清单；
• 子代理B（本地llama.cpp小模型）：统计所有文件的行数分布、注释占比、方法数量，输出统计报告；
• 子代理C（接另一个云端模型）：针对扫描出的核心类清单，生成一份模块依赖关系说明文档；
• 主代理自己：根据A、B、C三份报告，给出重构优先级建议和风险清单。

4.2 子代理指令怎么写：越具体越好

这个任务里最关键的一步是指令设计。我踩过很多次"指令太粗导致子代理跑偏"的坑，后来总结出一套写法：

• 第一句点明角色：你是一名资深Java代码分析工程师；
• 第二句点明目标：分析指定目录下所有Java文件，输出类和方法的清单；
• 第三句约束上下文：只需要读取src/modules/目录，不要改动任何文件，不要生成代码；
• 第四句指定输出格式：用表格或列表输出，每行包含文件名、类名、父类、主要方法；
• 最后一句给出验收提示：如果目录不存在，直接返回错误信息，不要猜测。

比如子代理A的指令可以写成：

你是一名熟悉Java代码结构的分析工程师。请扫描 src/modules/ 目录下的全部.java文件， 逐文件提取文件名、类名、继承的父类、实现的接口、以及public方法签名。 不允许修改任何代码文件。将结果按以下格式输出到 /tmp/class_list.md： | 文件名 | 类名 | 父类 | 接口 | public方法 | 如果目录不存在或没有Java文件，只返回一句话说明原因。

这种写法在下游模型上跑，输出基本不会太跑偏。

4.3 结果回收与冲突裁决：主代理最后要做什么

子代理的结果返回后，主代理做的不是简单拼接，而是要做三件事：过滤、对账、质疑。

过滤是指把子代理输出里带出来的废话、格式不正确的内容去掉。对账是指检查A、B、C的报告是否有互相矛盾的地方——比如A统计的类数量是18个，B统计的Java文件数是20个，这两个数字对不上，就要让子代理重新核对。质疑是指主代理不能无脑相信子任务结果，应该挑几个抽样点亲自验证一下，比如随机打开两个类文件，确认子代理的清单有没有漏掉关键依赖。

我特意在Qwen Code的系统提示词里加了一段："在汇总前，必须交叉验证各子代理结果的一致性，如发现冲突，标记冲突项并请求对应子代理重新输出。"这一步让整个流水线可靠了很多。

4.4 实际运行效果与几个值得调的参数

最终这个任务的总耗时大约不到十分钟（取决于你子代理网络和本地模型的推理速度）。对比单代理版本，结论更结构化，且每个子任务都可以单独重跑，不用因为某个环节出错就把整个任务重来一遍。

如果你也想复现这套流程，有几个值得调的参数：

• 子代理的上下文长度：本地模型上下文建议至少4K，否则长文件的分析容易中途截断；
• 请求超时时间：第三方API偶尔会慢，超时太短会导致失败重试，太长则浪费时间，我一般设置成120秒；
• 最大输出token数：如果子代理需要输出很长的清单，默认值可能不够，导致答案被截断，提前调大很关键。

5. 多代理调度中最容易翻车的五个地方

5.1 上下文膨胀：各子代理各说各话，主代理被淹没

多代理工作流最大的隐性成本就是上下文膨胀。每个子代理返回的报告动辄几千字，三份报告加起来就可能占满了主代理的上下文窗口。一旦主代理的上下文满了，后面它做分析和汇总时就会"忘掉"前面的重点，甚至开始乱说。

我的应对办法是：在子代理指令里明确要求"精简输出"，同时在主代理汇总前先让它用脚本把结果文件压缩成摘要格式。比如用命令统计文件行数、提取关键行，而不是把整个报告读进上下文。先压缩、再阅读，这个顺序很重要。

5.2 权限边界：助手调用助手可能死循环

当你允许Qwen Code执行shell命令时，理论上它可以无限次调用其他助手，其他助手如果也有执行权限，理论上也能反过来调用更多工具。如果你不多加约束，可能会出现"助手调用助手，助手再调用助手"的套娃行为，消耗预算不说，还可能陷入死循环。

我习惯在主代理的指令里写清楚：不允许调用任何会修改系统全局配置的命令，不允许递归调用其他编程助手，子代理最多允许一级嵌套。跑完一次任务后，我会手动检查一遍执行的命令历史，防止出现意外循环。

5.3 质量方差：不同模型在同一任务上的风格撕裂

不同模型的输出风格差异非常大。本地小模型可能输出简短、跳跃；云端大模型则可能会输出啰嗦的解释。当几份风格完全不同的报告汇总到Qwen Code手里时，主代理如果没有足够强的整理能力，成稿就会有明显的"拼接感"。

想要缓解，可以在每个子代理指令中放置相同的输出模板（比如所有代理都用同一个Markdown表格结构），让主代理只需要填充而不是兼容。我测试过，模板统一之后，最终汇总的文本质量提升比想象中明显。

5.4 并发与串行的取舍：避免互相等待

多代理工作流天然适合并行，但并非所有任务都可以并行。如果任务之间有依赖关系，比如B需要A的结果才能继续，硬并行就是浪费token。Qwen Code在执行命令时默认是串行的，如果你需要并行执行多个子代理，要么手动在多个终端里分别启动会话，要么使用编程助手的并发执行功能。

我的原则是：先梳理依赖关系，没有依赖的子任务才并发，有依赖的必须串行。依赖混乱时宁可保守串行，因为一次出错重跑的成本远高于省下的时间。

5.5 配置失效：环境一变，整个链路就断

多代理工作流对环境的依赖比单代理大得多。llama.cpp本地服务的端口被占用、第三方API的密钥过期、cc switch的配置文件被其他会话重置、PATH里的命令路径变了——任何一个环节出问题，整个链路都会失败，而且错误信息往往非常隐晦。

我养成了一个习惯：每次开始复杂多代理任务前，先花两分钟跑一个"冒烟测试"——检查本地API服务是否响应、检查默认模型能否正常返回、检查Qwen Code能否执行基础命令。这些检查可以写成一个shell脚本一键执行，省得任务跑到一半才发现配置失效。

6. 我的一些体会

把Qwen Code从"写代码的助手"升级成"调度助手的助手"，这个思路的改变对我自己的工作流影响很大。以前我总是追着最新最强的模型换，现在反而开始认真规划"哪个任务该交给谁"。

目前我最顺手的配置是：Qwen Code做主线控制，负责理解需求、制定方案和汇总输出；一个云端大模型负责重活，比如跨文件重构和复杂逻辑实现；一个本地小模型负责琐碎但量大的活，比如批量注释、格式整理、粗筛日志。这套组合在我这边的日常开发里已经稳定跑了挺长时间，省了不少时间和预算，输出质量也稳定。

如果你也想上手试，我建议从最小配置开始：先在命令行里手动让Qwen Code执行一次外部助手的调用，感受一下"调度"是怎么回事，再慢慢加角色、加并行。不要一上来就搭一个六代理的豪华流水线——那只会让你同时面对三倍的踩坑概率。

工具永远在变，但"把任务拆给擅长它的人"这个思路不会过时。在模型能力变得越来越多样、越来越便宜的当下，谁更擅长组织这些工具，谁就能把AI编程的生产力再往上推一截。