Qwen Code 多智能体协作怎么配置？Agent Team、Subagents、Arena 与 Worktree 验收

Qwen Code 的多智能体不是“同时开几个模型”这么简单。真正决定结果是否可控的，是任务能否拆成独立工作流、调查者是否保持只读、写入者是否被限制在单独工作树、谁拥有合并权，以及每一步是否留下可复核证据。本文依据 2026 年 9 月仍可访问的官方文档，把 Agent Team、普通 Subagents、Agent Arena 和外部终端编排分开讲清，并给出可以直接落地的配置、任务卡、验收表和回滚规则。

先给结论：多数团队应从“一名负责人、两名只读调查者”开始

如果目标是排查一个跨模块问题，优先使用 /coordinate：由负责人拆出最多三个相互独立的工作流，调查者只读取代码、日志和测试结果，最后由负责人汇总。只有当任务已经明确需要改代码，才增加一名写入者，并把写入者固定到负责人创建的 Git worktree。不要一开始就让多个智能体同时改同一分支；那会把“并行”变成难以审计的覆盖、冲突和责任不清。

如果目标是让不同模型对同一个实现方案竞赛，才使用 Arena。Arena 中每个模型是完整的顶层实例，拥有独立上下文和隔离工作树，彼此不协作，结束后选择一个结果合并。普通 Subagents 更适合小而明确的委派任务，工作者向父智能体回报；它不是共享任务表的协作团队。外部 CLI 或远程终端的统一调度属于另一层工具，不应误写成 Qwen Code 内建 Agent Team 的能力。

四种模式的边界，不要只看“能不能并行”

这一区分来自 Qwen Code 的多智能体协作官方文档和Agent Arena 官方文档。官方当前把 Agent Team 标为实验能力；因此上线决策需要版本记录、配置快照和回退路径，不能只保存一次成功演示。

启用 Agent Team：配置很短，治理不能省略

官方提供两条启用路径：在 Qwen Code 设置中将 experimental.agentTeam 设为 true 并重启，或者启动时设置 QWEN_CODE_ENABLE_AGENT_TEAM=1。设置项默认关闭且需要重启生效。建议项目团队优先用可审查的设置文件，并在变更记录中写明启用日期、Qwen Code 版本、负责人和回退方法；环境变量更适合一次性的隔离试验。

启用后不要立刻把生产仓库交给写入者。先用一个只读任务验证 Agent View 能看到成员、共享任务状态和消息，再验证权限拒绝是否真实发生。官方说明通过 /coordinate 创建的调查者使用强制只读工具集，不能执行 shell 或写文件。验收时要故意要求调查者创建文件，确认系统拒绝，而不是仅凭提示词中的“请勿修改”就认为权限已隔离。

配置字段和重启要求应以官方设置文档为准。实验功能随版本变化较快，截图和二手教程只能帮助理解界面，不能替代当前字段名、默认值和限制。

任务拆分：先画依赖图，再决定开几个智能体

适合并行的工作流必须在输入上共享、在写入上分离、在输出上可合并。例如“调查认证回归”可以拆为：A 查最近身份验证代码差异，B 查失败测试与日志，C 查配置和依赖变更。三者都只读，输出统一采用“发现、证据、影响、置信度、建议验证”的格式。若 B 必须等待 A 找到具体函数，二者就不是独立工作流，强行并行只会制造重复搜索。

每张任务卡至少写六项：明确问题、允许读取的路径、禁止触碰的区域、预期交付物、证据格式、停止条件。停止条件尤其重要：找到两个互相独立的证据即可回报；超过指定时间仍无证据就报告“未证实”，不能用猜测填空。负责人还要声明哪些判断必须自己完成，例如是否修改权限模型、是否迁移数据、是否合并到当前分支。

八类任务卡：把“帮我看看”改成可验收输入

代码差异调查

范围：只读检索最近提交、调用链和受影响文件。交付：文件与行号、提交或差异片段、影响路径。停止规则：发现需要改动时只提出候选点，不直接写入。负责人验收时还应核对任务编号、开始与结束时间、使用的代码版本以及是否发生权限请求。若回报只有结论没有定位证据，应退回补充，不进入写入阶段。

日志与失败样本

范围：按时间、请求标识和错误类型聚类。交付：最小失败样本、频次、首末出现时间。停止规则：日志缺字段时明确证据缺口。负责人验收时还应核对任务编号、开始与结束时间、使用的代码版本以及是否发生权限请求。若回报只有结论没有定位证据，应退回补充，不进入写入阶段。

测试覆盖调查

范围：映射现有测试到风险分支。交付：未覆盖分支、可复现命令、期望与实际。停止规则：不为追求通过率删除断言。负责人验收时还应核对任务编号、开始与结束时间、使用的代码版本以及是否发生权限请求。若回报只有结论没有定位证据，应退回补充，不进入写入阶段。

依赖与配置核对

范围：比较锁文件、环境变量和默认值。交付：版本差异、官方变更、回滚字段。停止规则：不读取或回显真实密钥。负责人验收时还应核对任务编号、开始与结束时间、使用的代码版本以及是否发生权限请求。若回报只有结论没有定位证据，应退回补充，不进入写入阶段。

修复写入

范围：仅在独立 worktree 实施最小补丁。交付：差异、测试、回滚提交点。停止规则：越出允许路径立即停下。负责人验收时还应核对任务编号、开始与结束时间、使用的代码版本以及是否发生权限请求。若回报只有结论没有定位证据，应退回补充，不进入写入阶段。

安全复核

范围：检查权限扩大、注入、密钥和供应链风险。交付：威胁场景、可利用前提、缓解证据。停止规则：高风险发现交给人工决策。负责人验收时还应核对任务编号、开始与结束时间、使用的代码版本以及是否发生权限请求。若回报只有结论没有定位证据，应退回补充，不进入写入阶段。

性能复核

范围：冻结样本和硬件条件再比较。交付：P50/P95、失败率、成本、样本量。停止规则：无基线不宣称提升。负责人验收时还应核对任务编号、开始与结束时间、使用的代码版本以及是否发生权限请求。若回报只有结论没有定位证据，应退回补充，不进入写入阶段。

文档同步

范围：只描述已验证行为和版本边界。交付：变更说明、示例、失效条件。停止规则：产品行为未验证则标注待核。负责人验收时还应核对任务编号、开始与结束时间、使用的代码版本以及是否发生权限请求。若回报只有结论没有定位证据，应退回补充，不进入写入阶段。

只读调查者与单一写入者：权限设计的核心

多智能体最危险的误区，是把角色名称当成权限。名叫 researcher 的智能体如果仍能执行 shell、改文件和调用外部写接口，它就不是只读。Agent Team 的价值之一，是官方明确说明 /coordinate 的调查成员使用强制只读工具集。即便如此，团队仍应保存一次负向测试：让调查者尝试写临时文件、运行命令和修改任务外资源，并记录拒绝结果。

需要实现时，只配置一名 writer。writer 的允许路径要写入任务卡，工作树由负责人创建并持有，负责人保持当前分支唯一合并权。writer 不得自行推送、合并、发布或修改凭据；它只交付一个可审查差异、测试结果和回滚点。这样，错误最多污染隔离工作树，不会同时影响调查证据和主分支。

单一 writer 并不意味着所有文件都由一个智能体盲改。调查者可以给出精确修改建议，writer 只实现已批准的最小集合；完成后由另一名只读成员复核差异是否超出任务卡。权限、职责和证据形成闭环，比增加智能体数量更能提高成功率。

Worktree 不是自动安全：必须检查基线、归属和清理

创建 worktree 前先记录主分支、HEAD 提交、暂存区和未跟踪文件。若基线本身包含未提交变化，负责人要决定这些变化是否进入隔离工作树；否则测试差异可能来自不同起点。writer 启动后记录 worktree 绝对路径、目标分支、允许写入目录和依赖安装策略，避免把构建缓存或环境文件误带回主目录。

合并前至少执行四项核对：差异只包含批准文件；测试命令与退出码完整；没有凭据、生成物或大型二进制意外进入；回滚点可解析。合并动作只由负责人执行。发生冲突时不要让 writer 在主分支直接“顺手解决”，而应更新基线、重新审查冲突语义，再在隔离树中处理。

Qwen Code 的 Arena 也使用隔离 worktree，但目的不同：每个参赛模型独立完成同一任务，最终选择赢家。官方还在代码审查文档中描述了临时工作树隔离。两者都说明 worktree 是控制写入面的工具，却不能替代代码审查、测试和合并授权。

共享任务表和消息：只传递可执行状态

共享任务表应使用少量稳定状态：待领取、进行中、被阻塞、等待复核、完成。成员更新状态时同时附一条证据或阻塞原因，不能只写“正在处理”。消息也要短而结构化：任务编号、事实、证据位置、需要谁做什么、截止条件。这样负责人能区分真正依赖与普通进度，不必读取每个成员的完整对话。

禁止用消息传递真实密钥、客户数据或整段生产日志。需要敏感信息时，负责人提供脱敏样本或最小可复现夹具。成员引用外部资料要附原始 URL、访问日期和对应主张；无法访问来源时写“未核实”，不能把搜索摘要变成已确认事实。

成本和上下文：多智能体不会免费增加正确率

每增加一个成员，都会增加提示、上下文读取、工具调用和负责人汇总成本。三个成员重复扫描同一仓库，常常比一个成员按明确假设逐步验证更慢。决定并行前可计算一个简单门槛：并行节省的等待时间，是否大于任务拆分、重复读取、消息同步和结果合并的总成本。若工作流无法独立运行，答案通常是否定的。

上下文也不是共享越多越好。给调查者最小必要文件和问题背景，给 writer 已批准的定位证据与修改边界，给负责人完整任务图。把整仓库、所有日志和所有历史对话复制给每个成员，不仅浪费 token，还会让过期信息与当前事实竞争。对高风险任务，成本预算应和工具调用上限、会话轮数、超时以及停止条件一起记录。

官方Headless 文档说明了工具调用和会话轮次等预算边界；实际部署时还需确认子智能体调用如何计数，不能误以为顶层预算天然覆盖内部全部工作。

可复现验收：先测协调合同，再测模型表现

本文配套的本地验收夹具不调用模型，也不声称复现 Qwen Code 运行时。它只验证协调合同：调查者是否只读、writer 是否唯一、任务依赖是否成环、每个任务是否有交付物、证据和停止条件。这个分层很重要：合同检查通过，只证明编排输入自洽；它不能证明模型会找到缺陷、补丁正确或官方实验功能在你的版本中可用。

一个可复制的认证回归演练

第一步冻结一个不含真实用户数据的最小仓库，记录 HEAD 和失败测试。负责人创建三张只读任务：调用链、失败日志、依赖配置。每张卡明确两条允许读取路径和统一输出格式。启动 /coordinate investigate the authentication regression and propose the smallest fix 后，先观察负责人是否创建独立工作流，再故意对调查者提出写入请求，保存权限拒绝。

第二步由负责人比较三份证据。如果调用链和日志都指向同一处令牌刷新边界，而配置调查没有发现版本漂移，才创建 writer worktree。writer 只修改批准文件，并补一条能在旧代码失败、新代码通过的回归测试。若证据互相冲突，负责人先增加验证任务，不要用多数投票代替定位。

第三步保存差异、测试命令、退出码、耗时和环境版本。只读复核者检查改动是否扩大权限、是否吞掉错误、是否改变日志中的敏感字段。负责人完成最终合并，并在灰度环境观察失败率与刷新成功率。任何核心指标越过阈值立即回滚到记录的提交，不让智能体在生产分支继续试错。

什么时候用 Arena，什么时候不要用

Arena 适合“同一目标、多个完整方案、可以统一评分”的任务，例如三个模型分别重构一个纯函数模块，再按正确性、变更规模、性能和可维护性选一个赢家。它不适合需要成员共享中间发现、共同维护任务表的协作问题，也不适合没有自动测试和评分规则的开放式改造。

官方文档说明 Arena 每个模型都有独立上下文、完整工具访问和隔离 worktree，参赛者之间不通信；这意味着 token 与工具成本会近似随参赛者数量增长。比赛前先冻结评判表，禁止看到结果后临时改变权重。若所有方案都未达到最低门槛，应选择“不合并”，而不是被迫从失败方案中挑一个。

Hooks、审计与观测：记录发生了什么

Qwen Code 的Hooks 文档列出工具调用前后、权限请求、权限拒绝、SubagentStart、SubagentStop 等事件。团队可以用这些事件记录任务编号、工具类型、结果状态和耗时，但日志必须先做隐私最小化：不要持久化提示中的密钥、完整文件内容或客户标识。审计日志用于追责和复盘，不应成为新的敏感数据仓库。

可观测指标至少分四组：任务完成率与阻塞率；重复读取和无效工具调用；权限拒绝与越界请求；合并后缺陷和回滚。只看“同时运行了几个智能体”没有运营价值。对比单智能体基线时，要使用相同任务、相同代码版本、相同验收和相近预算，否则无法判断收益来自协作还是资源增加。

常见失败模式与对应止损

所有成员都改代码

立即冻结写入，只保留一个 writer，并审计已产生的差异。止损完成后要保存触发条件、影响范围、恢复时间和负责人，避免下一次只凭印象判断“已经修好”。

任务卡互相依赖

合并串行链路，只有真正独立的调查继续并行。止损完成后要保存触发条件、影响范围、恢复时间和负责人，避免下一次只凭印象判断“已经修好”。

成员给结论不给证据

退回要求文件位置、命令输出或一手来源；仍无证据则标记未证实。止损完成后要保存触发条件、影响范围、恢复时间和负责人，避免下一次只凭印象判断“已经修好”。

工作树基线不同

记录并统一起点，旧结果作废后重跑关键测试。止损完成后要保存触发条件、影响范围、恢复时间和负责人，避免下一次只凭印象判断“已经修好”。

负责人自动合并

恢复人工或明确门禁控制，检查越权提交和外部发布。止损完成后要保存触发条件、影响范围、恢复时间和负责人，避免下一次只凭印象判断“已经修好”。

Arena 没有评分表

停止竞赛，在查看更多结果前冻结指标与最低门槛。止损完成后要保存触发条件、影响范围、恢复时间和负责人，避免下一次只凭印象判断“已经修好”。

成本突然放大

限制成员数、上下文、工具调用与回合；低价值任务退回单智能体。止损完成后要保存触发条件、影响范围、恢复时间和负责人，避免下一次只凭印象判断“已经修好”。

实验开关升级后失效

回退到普通只读 Subagents 或单智能体，并按新官方文档重新验收。止损完成后要保存触发条件、影响范围、恢复时间和负责人，避免下一次只凭印象判断“已经修好”。

上线前评分表：达到门槛再扩大使用

建议把试点分成四个维度，每项 0—2 分：任务拆分是否独立；权限是否由运行时强制；证据是否可复现；写入与合并是否隔离。总分低于 6 分不进入真实仓库，任何一项为 0 都必须整改。随后增加效率维度，但效率不能抵消权限或证据缺陷。

首轮只选低风险、可自动测试、可快速回滚的仓库。连续完成至少五个同类任务后，再比较单智能体基线：总耗时、人工复核时间、token 或费用、缺陷遗漏、回滚次数。若并行节省了等待却显著增加复核，可能只是把成本从模型端转移给了人。

负责人最终检查清单

1. 当前版本的官方文档已复核，实验状态与更新时间已记录
2. Agent Team 开关、重启和回退路径已经验证
3. 任务不超过三个独立工作流，依赖关系无环
4. 调查者的只读限制经过真实拒绝测试
5. 若需写入，仅有一名 writer，且位于负责人持有的 worktree
6. 主分支、HEAD、脏文件和未跟踪文件已记录
7. 任务卡包含范围、禁区、交付、证据和停止条件
8. 消息不包含真实密钥、客户数据或完整生产日志
9. 外部资料保留 URL、日期、主张与证据边界
10. 差异、测试、退出码、耗时和回滚点已保存
11. 合并和发布仍由负责人或既定门禁控制
12. 成本、质量与单智能体基线按同一规则比较

十四个实施问题：从试点到日常运维

成员越多，结果一定越好吗？

不一定。成员数增加会同时扩大上下文读取、重复检索、消息同步和负责人复核。只有工作流真正独立，而且等待时间占比明显高时，并行才可能带来净收益。官方当前的协调流程把工作流数量控制在最多三个，本身就是一个值得遵守的上限信号。试点时应从两名只读调查者开始，用相同任务与单智能体基线比较总耗时和遗漏，而不是只比较首个答案出现时间。

能否让两名 writer 各改一个目录？

技术上存在各种自行编排办法，但本文推荐的安全基线是单一 writer。跨目录依赖、共享配置、锁文件和测试夹具都会让“互不相干”的写入产生隐藏冲突。若确实需要两个完整实现并行，应改用 Arena 的独立工作树并把它们视为候选方案，最后只选择一个；不要把两个候选差异自动拼接后直接发布。

调查者只读以后还能做什么？

只读不等于只能复述文件。调查者可以建立调用链、比较提交、定位测试覆盖、分析脱敏日志、核对官方文档、列出互相竞争的假设，并为每个假设设计验证方法。高质量调查的交付物不是补丁，而是把未知范围压缩到负责人可以做出写入决策的程度。若调查必须执行测试，应单独定义可执行但不可持久写入的受控角色，不能假装它仍是官方默认只读调查者。

提示词写了“禁止修改”是否足够？

不够。提示词是行为要求，不是技术权限。模型可能误解、忽略或在工具链中遇到未预期路径。必须通过工具白名单、工作区隔离、审批和负向测试建立实际边界。验收时保留一次被拒绝的写入和 shell 请求，才能证明当前会话的限制生效；即使如此，也只能证明该版本、该配置和该会话，不可外推到所有环境。

如何防止成员读取密钥？

第一道防线是不给它读取密钥的路径和工具权限，第二道防线是使用最小权限、短期、可撤销的测试凭据，第三道防线是输出脱敏和秘密扫描。不要把真实密码放进任务卡、聊天消息、环境快照或测试夹具。若任务离不开外部服务，优先使用专门的沙箱账号和额度上限；发现密钥被输出时立即停止会话、吊销凭据并检查日志副本。

共享任务表里应该写多少内容？

任务表用于状态同步，不是复制完整对话。每项保留任务编号、负责人、状态、依赖、交付物位置和最近证据即可。长篇分析放在独立报告中，任务表只链接到它。这样既减少成员重复读取，也方便负责人快速识别阻塞。状态更新若没有证据或明确下一步，就不能算有效进度；“差不多完成”应被转换成可检查的剩余项。

成员结论互相冲突怎么办？

先检查它们是否使用同一代码版本、同一时间窗口和同一术语。然后把冲突改写成可判真的问题，例如“错误发生在刷新前还是刷新后”，再设计一个最小验证。不要简单按成员数量投票，因为多个成员可能引用了同一错误来源。若证据仍不足，负责人应保留两种解释并暂停写入，直到新增日志、测试或一手资料能排除至少一种。

Arena 的赢家怎样选？

比赛开始前冻结评分维度和最低门槛。正确性应是硬门槛，其后才比较变更规模、性能、可维护性、安全和成本。评审者最好看匿名化差异，避免对模型品牌先入为主。每个方案都运行相同测试和静态检查；若环境或依赖不同，比较无效。没有候选达到门槛时，正确答案是全部拒绝并重新定义任务，而不是强行合并排名第一的方案。

如何衡量并行是否值得？

记录端到端时间，而不仅是模型运行时间：任务拆分、等待、重复读取、人工复核、冲突处理、回滚都要计入。质量侧记录真实缺陷遗漏、错误建议、越界请求和合并后回归。成本侧记录输入输出 token、工具调用、外部 API 与基础设施。至少积累五个同类任务，再和单智能体基线比较中位数与尾部值，单次演示不能支撑采购或全面推广。

实验功能升级前要做什么？

先冻结当前版本、设置文件、可用命令和一组小型回归任务。升级在隔离环境完成，逐项验证启用开关、成员可见性、任务消息、只读拒绝、writer worktree 和负责人合并权。任何一项行为变化都更新运行手册。生产仓库保持可回退版本，在验证完成前不让新版本继承发布凭据或无人值守权限。

非 Git 项目能否使用这套方法？

只读调查和结构化任务卡仍然适用，但 writer 隔离和可审查合并会明显变弱。可先把待改文件复制到专用沙箱，建立内容哈希和完整备份，再由单一 writer 生成差异包，由负责人手工应用。若项目允许，最好先纳入版本控制。不能因为没有 Git 就跳过基线、备份和回滚，也不能把目录复制等同于可靠的合并历史。

如何处理数据库或云资源变更？

不要让普通 writer 直接操作生产数据库、DNS、云权限或第三方发布接口。智能体可以生成迁移草案、只读查询、变更计划和回滚脚本，执行仍通过既有审批与审计通道。先在脱敏副本或测试租户演练，记录前后状态和幂等性。不可逆迁移要有额外人工批准；验证失败时停止，而不是让智能体连续尝试更多写操作。

什么证据值得长期保存？

保存任务合同、代码版本、配置摘要、批准记录、关键工具输出、最终差异、测试结果、部署与回滚标识。对外部事实保存来源 URL、访问日期和对应主张。聊天全文未必需要长期保留，尤其可能含有敏感信息；可提取最小审计字段并设置保留期限。证据应该支持“谁在什么基线上做了什么、为什么通过”，而不是单纯证明会话曾经存在。

何时应退回单智能体？

任务高度串行、范围很小、缺少自动验收、仓库无法隔离，或人工复核成本已经超过节省时间时，都应退回单智能体。发生权限边界不明、成员反复重复工作、任务状态失真或实验功能不稳定，也应立即降级。降级不是失败，而是运行手册的一部分；可控地减少并行，通常比在复杂编排中继续追加成员更快恢复可靠交付。

七份运行记录：把协作过程变成可审计资产

启动记录

写明仓库或项目标识、主分支、HEAD、工作区是否干净、Qwen Code 版本、模型与配置摘要。任务目标要用可观察结果表达，例如“定位认证失败并给出最小补丁候选”，不能写成“全面优化认证”。同时列出数据敏感级别、允许访问的外部服务和总预算。启动记录一旦冻结，任何扩大范围的请求都成为新决策。

任务图记录

为每张卡分配稳定编号，列出依赖、所有者、只读或写入属性、允许路径、禁止路径、交付物和停止条件。负责人检查依赖是否成环，也检查多个任务是否其实在回答同一问题。任务被重新分配时保留旧所有者和原因，不能覆盖历史，否则后续无法判断重复工作来自任务设计还是成员执行。

权限负测记录

列出预期被拒绝的操作，例如调查者写入临时文件、执行 shell、触发发布或访问任务外目录。记录请求时间、工具名称、系统结果和界面证据。若某项意外成功，立即把当前会话视为权限门禁失败，停止所有写入并审计影响；不能只在提示词中再次强调禁止后继续运行。

证据索引记录

每个关键结论对应至少一个可回到原始上下文的定位：文件与行、提交、测试名称、脱敏日志时间段或官方 URL。再写清证据支持哪条主张、有什么限制、是否存在反例。负责人抽样复核定位是否真实可达。只有搜索摘要、模型解释或无日期截图的内容，统一标为线索而不是事实证据。

写入交付记录

writer 提交改动文件清单、差异摘要、运行命令、退出码、失败测试、残余风险和回滚提交点。记录工作树路径与基线哈希，确保差异没有混入负责人原有的未提交文件。依赖锁文件、配置和生成物变化必须单列说明；未解释的大规模格式化会掩盖语义差异，应在合并前移除。

合并决策记录

负责人逐项核对范围、正确性、安全、性能、文档与回滚，不使用“模型说可以”作为通过理由。若接受部分建议，写明舍弃其余建议的原因。合并后保存新提交标识，并把工作树清理作为独立步骤；清理前确认所有必要证据已转移，清理后确认主工作区没有意外文件。

灰度复盘记录

定义观察窗口、核心指标、告警阈值和自动或人工回滚负责人。记录实际流量范围与用户影响，禁止把爬虫请求、健康检查或内部测试当成真实用户采用。观察结束后比较基线与结果，说明差异是否具有业务意义。若数据不足，就写“未取数”或“样本不足”，不要用任务完成数量替代效果。

五阶段采用路线：先证明边界，再追求规模

阶段一：纸面演练

不连接真实仓库，只用本文的协调合同和虚构任务检查角色、依赖、交付物与停止条件。让参与者扮演负责人、调查者和 writer，刻意制造循环依赖、第二名 writer、缺失证据等错误，确认审查者能在执行前发现。此阶段的目标是统一语言和门禁，不评价模型能力。

阶段二：只读真实仓库

选择低敏感、已有测试的小型仓库，只允许读取。让两个调查者分别分析代码路径和测试缺口，负责人核对结论与人工基线。保存权限负测，确认不能执行 shell、写文件或调用发布接口。若成员无法稳定提供定位证据，暂停采用并改进任务卡，不急于开放 writer。

阶段三：隔离写入

由负责人创建一次性 worktree，仅给一名 writer 最小路径。任务应是低风险、差异小、可自动测试的修复。先由调查者给证据，再授权写入；writer 不接触主分支和生产凭据。负责人复核差异并手工决定是否合并。连续多次稳定通过后，才考虑更复杂任务。

阶段四：受控灰度

把通过代码门禁的变更部署到非生产或很小流量范围，设置明确指标和回滚阈值。智能体可以生成观察摘要，但发布、扩量和回滚权限仍由现有系统控制。区分模型任务成功、技术请求和真实用户指标，避免把自动化活动误报为产品增长。异常出现时优先回滚，再分析原因。

阶段五：制度化运营

形成版本支持矩阵、角色模板、任务卡、证据保留、成本预算和事故响应手册。每次 Qwen Code 升级都重跑最小回归集；每月比较单智能体与协作基线，淘汰没有净收益的场景。制度化不等于无人值守，涉及数据、权限、付费、发布和不可逆操作的决策继续保留明确的人类责任人。

示例验收会：负责人应该逐句问什么

验收会先从范围开始。负责人要求每名调查者用一句话重述任务，再指出实际读取过的路径和没有覆盖的区域。接着选择两条关键结论，现场打开原文件、提交或脱敏日志，确认定位存在且语义没有被截断。对于“可能”“通常”“看起来”等表述，追问它是事实、推断还是建议；推断必须写出替代解释和下一步验证，建议必须说明会改变什么以及如何回滚。

进入写入审查时，先比较 worktree 基线与主分支记录，再看文件清单，不先读模型的总结。负责人检查是否出现任务外文件、权限扩大、错误吞没、默认值变化、依赖升级或日志敏感字段。然后从零运行复现命令和测试，保存真实退出码。测试通过后还要确认测试确实覆盖失败路径，避免 writer 只修改断言或夹具让结果变绿。任何无法解释的变化都从候选补丁中移除。

最后讨论上线而不是“感觉”。明确灰度对象、观察时长、正常区间、停止阈值和回滚执行者。若改动涉及认证，至少观察成功率、错误类型、延迟和异常重试；若涉及成本，记录实际调用量而不是估算峰值。发布后出现问题时先按预案回滚，不在生产环境临时追加智能体探索性修复。复盘中区分编排缺陷、模型判断、工具故障和人工决策，分别指定改进项。

一场合格的验收会最终应产生五个可保存结果：证据索引、批准差异、测试回执、上线或拒绝决定、回滚标识。若只留下聊天记录和一句“已完成”，团队下次无法复现，也无法判断协作模式是否真正优于单智能体。反过来，如果记录完整，即使决定不合并，这次运行仍然创造了可复用的风险知识。

还要安排一次反向验证：由未参与写入的人依据记录独立复现关键判断。如果对方无法找到同一证据、无法运行同一命令，或不知道何时应停止与回滚，说明交付仍依赖会话中的隐性上下文。此时不应扩量，而应补齐任务卡、环境说明和证据定位。多智能体协作的成熟标志不是对话更热闹，而是换一位负责人仍能沿着记录得到相同边界，并在条件变化时明确拒绝过期结论。

对外发布经验时也应保留同样边界：说明版本、日期、样本、权限和失败条件。不要把内部一次成功写成普遍能力，不要隐去人工审查与回滚成本，更不要用自动化请求数冒充真实用户收益。只有可复核的事实才能进入长期知识库。

如果证据无法独立复现，就把结论降级为待验证线索，并停止继续扩大权限、流量和预算。

发布前再做一次无上下文复核：仅把任务卡、代码基线和证据索引交给复核者。如果复核者仍能指出相同风险、运行相同测试并解释回滚条件，记录才算足够完整；否则继续补证，不进入生产。

站内延伸阅读

如果你还在选择日常编码工具，可先看Cursor 定价、安全与采购验收；需要了解 Qwen Code 的隔离工作区与检索能力，可继续阅读Qwen Code worktree 与 web search 指南；希望把同样的证据边界用于普通问答任务，可从兰塞 AI 助手入口开始，并始终保留人工复核。

证据边界与更新说明

本文核对的是 2026 年 9 月 15 日可访问的 Qwen Code 官方英文文档，关键页面标注的多智能体协作更新时间为 2026 年 9 月 8 日。文中没有把官方示例当成独立性能证明，也没有声称在本站环境实际运行了 Qwen Code Agent Team。配套静态夹具只验证本文提出的协调合同，不验证模型质量、远程会话、跨供应商调度或生产安全。

如果你的版本看不到 /coordinate、设置字段不生效，或 Agent View 行为与本文不同，应先记录版本并回到当前官方文档核对。可靠的回退方案是关闭实验开关，改用单智能体或普通只读委派，再由人工控制写入和合并。任何第三方教程、搜索摘要和截图都不能覆盖本地实测结果。

参考的一手资料

• coord：Qwen Code 官方文档（访问于 2026-09-15）
• arena：Qwen Code 官方文档（访问于 2026-09-15）
• settings：Qwen Code 官方文档（访问于 2026-09-15）
• headless：Qwen Code 官方文档（访问于 2026-09-15）
• hooks：Qwen Code 官方文档（访问于 2026-09-15）
• review：Qwen Code 官方文档（访问于 2026-09-15）