Qwen Code多代理工作流：AI编程协作指南

摘要

Qwen Code 近期把外部编程助手、可复用工作流与长任务预算放进了同一个产品方向。变化不只是"一次能调用几个模型"，更在于任务怎样拆分、权限怎样传递、结果怎样验收。本文从一次真实开发任务的组织方式出发，解释它能做什么、如何上手，以及哪些能力不能混为一谈。

一、多代理竞争进入"组织工作"层面

开发者同时使用几种 AI 编程工具，已经不算稀奇。真正的麻烦在于，把任务在它们之间搬来搬去：先解释一遍仓库背景，再复制一段变更，等另一个助手给出审查意见，最后把意见带回原会话。上下文一旦不同，两边讨论的可能已经不是同一个版本。

Qwen Code 在 9 月 17 日的官方产品周报中介绍了调用 Claude Code 与 Codex 执行子任务的能力，同时扩展了工作流调用、预算管理与 Goal 长任务控制。本周发布 v0.23.3、v0.23.4、v0.24.0 三个正式版本，267 个 PR 合入。它试图把分派、权限请求与结果回收留在一条可追踪的工作过程中。这使 AI 编程工具的竞争，进一步进入"怎样组织工作"的层面。

但需要提前分清两个概念。能调用外部助手，和外部助手能无条件参与所有内部工作流，并不是一回事。当前子代理文档明确列出了外部执行器的限制。只有把这些边界理解清楚，才能设计真正可运行的流程，而不是画出一个看起来很热闹的多代理架构。

二、它首先是围绕仓库工作的执行环境

Qwen Code 提供与模型交互、读取项目、使用工具和管理开发任务的入口。对新用户，可以先从官方快速入门进入，完成安装、模型服务配置与项目目录选择，再用一个小任务检查环境。模型能够正常回答只是第一步；能够找到项目文件、理解运行命令并回收结果，才算形成基本闭环。

它和单纯的代码问答有所不同。问答通常停留在"给出一段建议"，执行环境则要面对真实文件、命令状态和失败结果。一次修复工作，需要知道当前代码是什么、哪些修改已经存在、测试从哪里运行，以及用户允许它改到什么程度。这些信息不能都靠模型临时猜测。

因此，第一次使用不宜立即交付一个模糊的大目标。可以先要求它说明项目启动方式、定位一个函数的调用链，或者分析一个可复现的测试失败。小任务能帮助你确认：它拿到的上下文是否正确，执行位置是否正确，错误输出有没有被完整保留。把这些基础问题处理好，再谈长时间自主执行，收益会更稳定。

三、外部子代理：切换成本与职责分工

外部助手接入后，主会话可以把一项有边界的任务交出去，例如审查一个模块、检查某个异常路径或提出替代实现，再把结果汇总回来。现有账号和工具安装仍是前提。主会话负责协调，并不意味着它替代了外部产品自身的认证与用量体系。

按当前子代理文档，可以在子代理定义中配置外部执行器。Codex 目前以单项任务返回结果的方式接入，默认只读；Claude Code 支持任务过程中的多轮交互。平台支持也有区别，Windows 用户应按文档使用 WSL 路径。选择哪个执行器，应看任务需要与现有环境，而不是假设所有接入方式都完全相同。

一个合适的分工示例是：主会话负责定位问题和准备变更，外部助手只负责核查修改有没有遗漏边界条件。发出去的任务应附上仓库位置、涉及文件、基准版本、关注的问题和预期输出格式。只说"全面审查一下"会扩大搜索范围，产生很多与当前目标无关的建议，也更难判断任务是否结束。

返回结果也应有标准。好的审查意见需要明确问题所在、触发条件、影响与验证方式；只有"可能存在风险""建议增加测试"这样的泛化表达，不能直接进入修复清单。主会话应把可复现的问题和风格偏好分开，再决定是否调整代码。

四、分工需要证据，汇总需要验收

多一个模型并不自动多一份独立证据。两个助手如果读到同一份错误的需求说明，或者都没有执行测试，可能一致地得出错误结论。更有用的做法，是把不同助手的职责与证据来源区分开：一个检查逻辑路径，一个检查测试覆盖，最终由实际运行结果和人工审查收口。

一条可追踪的协作路径包含三步。
第一步，主会话派发。 明确目标、版本和文件，限定只读或修改范围，约定输出与停止条件。
第二步，外部助手执行。 使用已配置的工具与账号，按支持范围完成子任务，返回依据、发现与执行结果。
第三步，主会话收口。 核对是否基于正确版本，区分缺陷与风格建议，用测试和代码审阅作结。

两条提醒需要记住。调用外部助手，不代表它支持全部内部工作流或团队配置。多份相同意见不是独立证据；可复现的问题才值得进入修复。

五、工作流、Skill 与工具，分别管什么

这些词经常同时出现，但可以从三个问题区分。Skill 提供某类任务的做法与知识；工具负责真正读取、查询、修改或运行；工作流规定多个步骤怎样组织、在什么条件下继续或结束。一个有经验的助手可以根据 Skill 安排工作，但需要稳定重复的团队流程，往往还需要明确的阶段结构。

比如每次发布前都要整理变更、检查测试、生成说明和核对版本，就可以把这套顺序保存成工作流。它的价值在于复用已经约定好的过程，减少每次重新讲一遍的成本。工作流拥有名字后可以按名称调用，扩展也可以分发预定义工作流。但安装了流程不等于它适用于所有仓库，项目自己的构建命令、分支规则和验收标准仍然要补齐。

近期更新强化了执行前的结构预览，使你有机会看清哪些步骤会分派任务、哪些分支并行、哪些地方循环。这个预览应当被当作审阅对象。一个简单的文档整理任务，如果被展开成多层循环和大量子任务，说明流程可能过度设计。增加协作节点，有时只是在增加上下文传递与汇总成本。

尤其不要把外部执行器和内部代理的所有配置混用。当前文档列出的外部执行器限制，包括某些模型覆盖、工具列表、钩子、团队与工作流等能力。文章里画出的协作示意，也不意味着你可以把外部助手直接塞进任意工作流节点。实际落地时，要查当前版本支持的执行方式，再选择主会话分派或受支持的内部流程。一个可靠的工作流，更像一份清楚的任务合同：输入是什么，允许触碰哪些内容，每一步交付什么，什么情况必须停止。如果这些内容缺失，再漂亮的可视化结构，也很难阻止任务范围越做越大。

六、预算、轮数与时间，约束的是不同资源

长任务的成本，不能只看屏幕上已经显示了多少文字。读取文件、传递上下文、调用子代理、验证结果与反复修复，都可能消耗模型资源。给工作流设置 token 预算，可以帮助系统在有限资源内安排工作，但它不应被当成跨服务商统一的精确账单。

Goal 则面向持续推进的目标任务。Goals 文档说明了目标的持续执行与控制方式；近期更新又增加了轮数和活跃时间上限。轮数限制的是推进回合，时间限制的是实际工作时长，token 约束的是模型处理量。它们互相关联，却无法一一换算。

举一个组织方式的例子。准备让助手排查一个间歇性测试失败，可以要求先整理复现路径，再允许它在约定轮数或时间范围内尝试。达到边界时，应该交付已经排除的原因、仍未验证的假设和下一步最有价值的实验。这样，即使没有当场修好，也留下了可继续使用的成果，而不是一段"还在努力"的说明。

停止条件最好同时包含任务条件与资源条件。例如"找到可复现原因并通过针对性验证"是任务条件，"达到轮数或活跃时间上限"是资源条件。只设置后者，可能提前停止在一个无用的中间状态；只设置前者，又可能让任务在错误假设里持续消耗。两者一起设计，才更适合实际项目。"继续"也需要明确续的是什么。恢复任务时，应确认仓库和依赖有没有变化、之前的结论是否仍适用，再接着使用已有证据。否则，任务虽然在同一条会话里延续，测试环境却已经不同，前面的排查结果就可能失去意义。

七、Worktree 与沙箱，不能相互替代

当多个任务会修改同一个仓库时，隔离工作目录非常重要。Git worktree 可以让不同任务在独立检出目录中工作，减少彼此覆盖文件的机会。它适合分支上的并行开发与独立审查，但不意味着任务天然拥有不同的数据库、缓存或外部服务。

例如两个独立工作区都连接同一个测试数据库，那么它们仍可能修改同一份数据；两个开发服务都使用固定端口，也可能发生冲突。文件隔离只是其中一层，端口、服务、凭证与测试数据还需要按任务安排。设计协作流程时，应把这些共享资源标出来。

沙箱关注另一类边界：进程能够访问哪些文件、使用哪些资源。Qwen Code 近期加入的 Linux bwrap 后端，在所配置的范围内限制写入位置，具体安装要求与边界以官方沙箱说明为准。沙箱能够限制执行范围，但无法替你判断业务逻辑正确与否，也不能把错误的删除需求变成正确的操作。

比较实用的顺序是：先采用只读分析，再对必要的修改开放范围；先在隔离工作区完成变更，再检查差异并运行验证。对于外部执行器，还应单独确认权限如何传递、哪些能力由对方进程控制。不能因为主工具显示了一个安全模式，就推断所有子进程天然继承完全相同的限制。

八、用一个小型修复流程，建立自己的使用方法

可以从"修复一个接口在空结果时返回错误状态"这样具体的任务开始。第一阶段，先保存当前代码状态，明确期望行为与复现输入，然后让主会话定位相关实现及测试。这个阶段的目标是形成简短的诊断：问题在哪里，为什么出现，准备怎样验证。

第二阶段再修改代码。要求改动尽量局部，并保留原有正常路径。测试应覆盖原始失败情况和最接近的正常情况，不必为了显得充分而复制实现写一堆形式化断言。测试失败时，应先读失败信息，再判断是修复不对、测试假设不对，还是环境没有准备好。

第三阶段使用独立审查。可以交给一个只读外部助手，让它围绕变更检查边界条件、兼容性与异常处理。给它明确的基准和修改范围，要求只报告有依据的问题。主会话根据报告补充验证，必要时修正，再输出最终差异与测试结果。

这套流程故意保持简单。只有当你发现多个互不依赖的模块确实可以同时推进时，才增加并行任务；只有反复使用相同顺序时，才值得保存为工作流。自动化应来自重复需求，而不是为了使用新功能而制造更多步骤。对于团队，流程还要明确谁负责最终验收。助手可以完成代码分析和验证执行，但发布风险、需求取舍与用户体验往往需要项目负责人判断。把结论写成"修复了什么、如何验证、还有什么边界"，比让模型生成一长串看似积极的工作日志更有用。

九、给代理一份清楚的任务合同

一份适合分派的任务说明，可以包含五项内容：目标、已有事实、允许范围、交付物和停止条件。目标说明要解决什么；已有事实避免重复调查；允许范围控制修改；交付物决定结果怎样汇总；停止条件则规定遇到缺失信息或资源边界时怎样收尾。这比给不同代理起几个角色名字更能影响协作质量。

例如分派代码审查时，可以写明："检查这次分页参数修改是否影响空结果与最后一页；只读取相关文件；不改代码；每个问题列出触发输入、文件位置和建议验证；没有确定问题时明确说明。"这种说明使助手更容易围绕可验证缺陷工作，也减少把一般性建议当成严重问题的机会。

如果分派的是实现任务，则要补充文件归属和接口约定。两个任务同时编辑同一个核心配置，即使分别位于独立工作区，也可能在合并时产生语义冲突。可以指定一个任务负责接口定义，另一个在接口确定后实现调用；或者让不同任务只写互不重叠的模块，最后由主会话统一集成。

上下文不必越多越好。把整段历史原样塞给每个执行器，会增加处理量，也可能把过期判断和无关讨论一起传递。更合适的做法是提供必要文件、当前版本和已经确定的结论，并保留原始证据入口。摘要负责降低理解成本，证据负责允许接手者核对。

还要避免循环审查没有出口。一个助手提建议，另一个照单修改，第三个又提出另一种偏好，流程可能一直持续。可以规定：只有可复现缺陷或明确违背需求的问题才触发返工，样式偏好进入可选建议；连续几轮没有新增有效问题，就进入最终验收。停止的依据应是任务质量，而不是模型是否还能继续说话。这些约定也适用于单助手。即使你最终没有使用外部执行器，清楚的输入、边界和验收方式，仍然会让 AI 编程更容易掌握。多代理只是把交接问题放大了，并没有改变开发工作需要明确需求和证据的基本事实。

十、怎样判断多代理真的带来了收益

可以先比较单助手与分工方式完成同一类任务的结果。记录总耗时、人工介入时间、最终确认的缺陷数、误报数、代码返工和模型费用。某种分工如果找到了更多真实问题，同时减少了人工复查，就有价值；如果只是产生了更多文字和重复意见，未必值得保留。

需要特别关注交接成本。每次把任务交给另一个助手，都要重新组织背景；每次拿回结果，都要核对它基于哪个版本。任务过小，协作成本可能超过执行成本；任务过大，又容易出现含糊的边界和重复劳动。适合分派的通常是输入清楚、输出明确、能够独立验收的一块工作。

当团队同时接入多个外部助手，每个产品都有各自的认证与用量体系时，统一管理接入层就变得必要。把端点路由、鉴权与用量记录收敛到单一入口，可以降低多代理环境的配置复杂度。koalaapi 作为 API 网关，为多模型与多端点接入提供统一管理，让团队在一个入口控制任务如何分发、流量如何观测。

结论

Qwen Code 这一轮更新最有意思的地方，是把"会写代码"继续推向"能管理一段开发过程"。外部助手、工作流、Goal、Worktree 和沙箱分别解决不同问题，组合时也需要遵守各自的支持范围。先把一个任务做得可追踪、可验证、可恢复，再逐渐扩大自动化范围，往往比一开始就搭建庞大的代理团队更容易获得稳定收益。多代理的价值不在模型数量，而在任务组织、证据管理与验收闭环的质量。

了解更多：https://koalaapi.com