Qwen Code v0.27.0支持第一层内置子任务分别保留待答问题，用户可按任意顺序回答，并通过新增“问细节”入口先理解选项背景与风险。此次更新聚焦编程智能体的人机交互与运行管理，不涉及新模型发布；部分部署方式和故障恢复路径仍有验证边界，答案被接受也不代表任务已恢复执行。
QwenLM在北京时间2026年11月8日凌晨发布Qwen Code v0.27.0，将编程智能体向人征求决定的流程向前推进了一步：多个子任务可以同时保留各自的问题，用户不必按系统选定的顺序逐一作答；遇到看不懂的选项，也可以先打开解释侧任务，而不立即解除原任务的等待。
官方发布页及发布记录API显示，版本公开时间为2026年11月7日20:45:25 UTC，即北京时间11月8日04:45:25，标记为非草稿、非预发布。这是工具交互与运行管理的更新，不是一次新模型发布，也没有提供代码生成能力提升的独立评测。
两项变化针对的是同一个实际问题：当智能体需要人的决定时，怎样既让人有机会理解问题，又不把其他任务一起拖进等待。不过，功能进入正式版本，并不意味着所有多智能体部署方式和故障恢复路径都已经获得验证。
多个子任务提问，不再挤在一张表单里
根据并发子问题实现说明PR #16484，此前只有根会话能够进入相应提问流程，页面又自动选择单张表单；两个子任务同时需要不同决定时，这种设计会限制交互。待处理请求重排可能让当前选择跳转，切换问题也可能丢失草稿。
此次改动让父页面统一列出问题与权限请求，并按完整目标身份，分别管理当前选择、草稿、提交状态和错误。以开发者给出的A、B两个子任务场景为例，用户可以先回答B，让B继续执行，而A仍保留原来的待答问题和截止时间。A提交出错或正在提交，不应因此禁用B的回答入口。
这里的“保留草稿”需要限定：未提交的文字只存在于当前页面内存中，并不是刷新后仍可恢复的持久草稿。刷新恢复的是已经持久化的请求和已接受的答案；问题修订时，也只清除对应目标的旧草稿。
运行管理层面的变化同样重要。等待人工回答时，系统只归还发问会话自身的执行成员占用，而不是释放整个工作区或兄弟任务的占用。它仍保留原有运行时身份及清理责任，继续执行前还要重新取得原绑定与相应代次的准入。
因此，“答案已接受”和“任务已恢复执行”仍是两个不同状态。界面收到答案，并不等于后端已经具备继续运行的条件；未知的执行归属或无法证明的执行结果，也不能被当作已经安全恢复。
不理解选项时，先“问细节”
另一项变化来自PR #16458。Web Shell在待答的Ask User Question面板中加入“问细节”入口，用独立侧任务解释问题背景、各选项的含义、差异、影响和风险，并可给出建议。
此前，问题待答时主输入框会隐藏，用户恰好在最需要澄清的时候，难以通过原有侧任务入口追问。新的入口会把待答问题及选项的快照带入侧任务，生成可在右侧面板预览的单文件HTML说明。每个待答问题只对应一个解释侧任务，重复点击会聚焦已有标签页，而不是不断创建新会话。
解释与决定在这里被刻意分开：侧任务不会替用户提交答案，也不会向主会话发送提示词来解除等待。用户仍需回到主视图，自行回答或忽略问题。这不是把人工确认自动化，而是在确认之前增加理解选项的途径。
这一入口也不是所有面板都能使用。只有守护进程声明支持侧任务能力时，主视图才显示按钮；分栏视图和嵌入式面板不在范围内。实现说明要求解释过程核实事实、标注未核实事项，但提示词中的要求不等于生成的每一份解释都已经被独立验证。
相较上一版，新增的是并发与澄清能力
上一版v0.26.9发布说明已经列出“持久化结构化用户问题”。因此，不能把v0.27.0写成Qwen Code首次能够向人提问；本次的具体增量，是第一层子任务各自等待、任意顺序回答、交互状态隔离，以及待答期间的解释入口。
这也不同于此前项目钩子审批与非交互信任边界的调整：后者关注仓库配置何时获准执行程序，本次则关注任务运行中如何征求人的决定。不能因为父页面同时展示问题和权限请求，就把两类机制视为同一项安全保证。
正式发布之外，哪些验证仍有边界
并发子问题的实现范围限定为普通本地files/Shell会话，以及第一层内置public子任务。SSH、MCP、Hooks、Team成员、工作流、扩展定义的子任务和更深层子任务等，并不属于这一增量。等待中的子任务仍计入既有的深度、活跃数量和生命周期启动次数限制，不能据此推断并发规模已不受约束。
PR #16484披露，开发方完成了定向运行时、恢复及相关界面测试，浏览器检查使用实际构建的Web Shell，但控制面采用模拟Java API。真实public子任务A/B集成场景当时只有编译证据；真实Hosted/MySQL执行，以及组合重启、故障验收等仍列为等待CI的事项。后台命令与问答组合、归还响应丢失或迟到、完整进程重启，以及多个任务交替改写文件的组合冲突，也没有在该本地验证中执行。
“问细节”功能的证据范围不同。PR #16458报告了Linux下真实守护进程、真实模型与无头Chromium的检查，但使用的是0.26.8守护进程配合开发版Web Shell；macOS和Windows未在其本地测试中验证。这些都是开发者披露的测试，不是本次报道独立复测的结果，也不能合并成“所有平台端到端验证完成”的结论。
对使用多个编程子任务的团队，这次更新的实际意义，是让不同问题可以分别等待，让用户在作答前多一个理解选项的入口。部署时仍需区分问题是否已展示、答案是否已持久化、执行是否真正恢复，以及运行资源是否完成清理。把这些状态分清，才能判断人机协作流程是否可靠，而不是只看一个“已回答”的界面提示。