编码智能体完成一个子任务后，是立即消失，还是继续留在工作区等待追问？Qwen Code在7月24日发布0.21.0正式版，一次加入37项功能、73项修复和5项性能改进。最值得关注的变化不是又多了一个模型入口，而是让已完成的后台智能体保持可用，并把会话、工作区、目标、技能和MCP连接重新串成一套可持续运行的工程工作台。

三点看懂：编码智能体开始有“班组”状态

从一次性子任务，走向可恢复的后台协作

过去的多智能体体验常有一个断点：主智能体把测试、检索或代码修改交给后台角色，任务结束后，用户只能看到一份结果，原来的执行上下文却难以继续利用。0.21.0让完成后的后台智能体继续驻留，同时恢复后台名单、同步状态，并修正单槽位调度、空工作目录和任务恢复等问题。

这意味着开发者可以把一个复杂需求拆成多个相对独立的任务，再回到具体会话追问依据、要求补测或比较不同实现。Web工作台增加子智能体详情、文件预览和工作区智能体管理，CLI则能通过“@”引用历史会话。它仍不是自动保证正确的“软件团队”，但上下文不再只是一段用完即丢的临时记录。

工作区级运行同样重要。版本把生成任务、消息通道生命周期和配置持久化都收拢到工作区，新增工作区选择器和Git模式入口。对于同时维护多个仓库或分支的团队，这有助于减少会话、代码目录与通知通道串线，不过权限、分支和执行环境仍需要人为设定清楚。

Goal v3与技能目录，把长期任务的状态写得更明确

0.21.0新增Goal v3状态协议和“有限证据验证”，意图是在智能体宣称目标完成前，要求检查可观察的结果，而不是只凭一段自然语言总结。官方发布说明没有给出成功率或端到端基准，因此不能把协议升级直接等同于更高可靠性；它提供的是更清晰的状态接口，最终效果仍取决于任务定义和验证项是否可执行。

技能系统允许通过设置加载自定义目录，便于团队把代码规范、排障流程或部署检查作为可复用能力管理。MCP服务支持主动重连，Java SDK增加守护进程传输，CLI的学习入口可直接接收视频，文件预览和图像生成模型也可配置。组合起来看，Qwen Code正在从终端问答工具扩展为可以承载多种输入、技能和长期会话的智能体运行层。

这些入口也改变了团队沉淀经验的方式。过去的操作习惯往往散落在提示词、脚本和个人笔记中；自定义技能目录让它们可以跟随项目配置复用，历史会话引用则便于把一次排障延续到后续修改。但技能仍会继承工具权限和运行环境，目录可共享不代表其中步骤天然安全，团队需要像审查脚本一样审查其命令、输入范围和失败处理。

73项修复说明能力变多，也意味着边界更复杂

正式版声明没有已知破坏性变更，但修复清单本身值得谨慎阅读。项目强化了守护进程事件流、会话恢复、工具调用和工作区隔离，并清理子进程、钩子及工具发现流程中的内部密钥。无人值守的PR审查也改为通过接口静态读取CI状态，不执行待审代码，降低把不可信仓库内容带进审查环境的风险。

与此同时，后台常驻会话会增加内存、状态一致性与权限治理压力；MCP重连不代表外部工具一定幂等，目标证据也可能因测试覆盖不足而失真。升级前应在真实仓库验证会话恢复、分支隔离、工具授权、密钥传递和失败任务的重入行为，再决定是否用于无人值守流程。

ATYUN编辑判断：Qwen Code 0.21.0的价值不在某个醒目的模型分数，而在于把多智能体协作最容易断裂的状态链补得更完整。后台角色能留下、工作区能隔离、目标能验证、技能能复用，编码智能体才可能从一次性演示进入日常工程。下一步真正需要观察的，是这些机制在大型仓库和长时间任务中的资源占用、恢复一致性与权限可审计性。