Qwen Code 于 2026-10-24 发布 v0.26.1，聚焦托管会话的长期运行管理：引入会话空闲时的上下文压缩、会话内可调整的 MCP 工具管理，以及定时任务在唤醒模型前先执行外部检查的门禁机制。更新改善了持久化与触发判断，但依赖控制面、运行时和权限配置，实际可用性需按部署环境验证。
Qwen Code 于2026年10月24日发布 v0.26.1，将一批更新放在编程智能体的日常运行与管理上：托管会话可以在空闲时手动压缩上下文，在不重建对话的情况下调整 MCP 服务，定时任务则能先在模型之外检查条件，有需要时才启动模型处理。
这不是新的 Qwen 基础模型或权重发布。官方发布说明展示的是工具链、运行时与交互界面的升级。对需要让智能体持续跟踪代码审查、处理长任务的团队而言，核心变化在于如何管理已经运行起来的会话，而非单次生成代码的能力。不过，相关功能涉及控制面、执行运行时和授权配置，发布版本并不等于所有部署环境都能直接使用。
压缩模型上下文，不删除审计历史
长时间编程会话会积累需求、代码片段和工具结果。模型后续需要接收多少历史，与用户能否查看原始记录，是两个不同的问题。
根据手动上下文压缩的开发说明，本轮为绑定 Workspace 的公开类型托管会话增加了 API 和 WebShell 入口。压缩只在会话空闲时接纳，不创建新的用户交互轮次；原始聊天审计记录仍然保留，而压缩后的模型历史会被持久保存，供后续轮次以及重新打开的会话使用。
这比增加一个“生成摘要”按钮更复杂。如果摘要只保存在当前进程内，下一次请求或重启后仍可能重新装入旧历史。此次改动将压缩结果的保存、恢复和操作状态一起纳入持久化流程，并对重复提交与中断恢复作了处理。
使用条件也很具体：调用者需要具备 OPERATOR 或 OWNER 等相应权限，执行适配层 Harness 必须支持对应能力。会话存在排队或运行中的任务、待审批操作等冲突时，压缩请求会被拒绝，而不是强行改变模型正在使用的历史。压缩完成后，上下文用量暂时显示为未知，直到下一次主模型实际观测，避免继续展示压缩前的占用数据。
这些机制旨在让压缩结果能够跨轮次和重启保留，但不能据此承诺任务质量不受影响。开发者还披露，纯摘要请求中断后可能重试，模型计费因而可能重复；历史记录至多提交一次，并不等于模型只收费一次。
MCP 从只读目录变成会话内管理
另一项更新针对工具连接。MCP，即模型上下文协议，是智能体连接外部工具与服务的一种方式。实际工作中，服务失去连接、需要停用某项工具或更换配置，并不意味着用户愿意放弃整段对话重新开始。
会话内 MCP 管理说明称，获授权用户现在可以在现有托管会话中添加、更换、移除、启停、重新加载或重启已发布的 MCP 服务，同时继续使用普通文件和 Shell 工具。管理操作作用于该会话原有的执行运行时，而不是另一个守护进程环境。
每次明确修改会记录独立的会话级 MCP 配置修订，原先固定的智能体定义、Skills 和审批策略不随之重写。新增或编辑服务时，系统从运行时的私有已发布清单中选择精确版本；可执行配置和凭据不会进入公开 API 或浏览器存储。
这里的“管理”并不是任意环境下自由安装任何服务。该改动支持普通本地 shell/1 和既有 MCP 配置类型，需要匹配的控制面、Broker、Runtime 与 WebShell 组件。OAuth 配置编写、SSH、CSI 及较新的 Workspace 类型不在这项改动的支持范围内，或尚未完成相应验证。会话正忙、权限不足或配置类型不受支持时，也不能修改设置。
先检查变化，再决定是否唤醒模型
模型外调度门禁解决的是另一个常见问题：监控任务即使没有发现变化，也可能反复产生模型请求。
在定时任务门禁的核心实现中，调度器先执行一条 Shell 检查命令。如果命令没有输出且以退出码0结束，本次触发便跳过，不创建模型轮次、队列项或对话记录；有输出时，检查结果才会附在任务提示之后，并标记为命令产生的数据。
这使“多久检查一次”与“多久调用一次模型”不再必须相同。例如，持续观察代码审查或持续集成状态时，可以先通过确定性的程序检查是否出现新情况，再把需要解释或处理的结果交给模型。减少无变化时的模型轮次有助于控制调用与上下文开销，但检查进程本身仍要运行，不能把它称为零成本监控。
这一机制不是让模型绕过审批。门禁本身是无人值守执行的 Shell 命令，提出时需要相应确认，运行时还要按会话模式、权限规则及沙箱策略重新检查。命令输出也可能受外部内容影响；将其标记为数据，并不代表这些内容天然可信。
本版还包含两条配套路径，不能把它们与核心调度器混为一谈。守护进程和 WebShell 的后续改动补充了 REST 配置、界面字段与状态展示，但手动点击“立即运行”不经过调度器，其做法是要求模型先执行门禁，因而不能套用“静默检查不创建模型轮次”的承诺。
托管自动化的门禁则在认领运行任务之前，由 Workspace Runtime 执行探测。它与核心定时任务的超时参数也不同：核心实现为60秒，托管自动化为20秒。后者在命令失败、无法启动或超时时跳过该次任务并记录错误，不把失败当成有变化而照常发送提示。运行环境不支持或执行结果无法确认时，同样不会直接放行。
从保存会话，转向维护会话
Qwen Code 对托管运行时的建设并非始于这次更新。9月26日发布的官方 v0.24.6 说明已列出 Managed Runtime v2、持久化托管会话日志和故障转移。本站此前对这一版本与持久化工作流的报道也讨论了相关部署边界。
相比之下，v0.26.1 的这几项变化更接近持续运行之后的维护：历史如何压缩并恢复、工具连接如何调整、监控任务何时才值得调用模型。它们没有证明模型推理能力提升，而是把更多会话管理和触发判断交给运行系统承担。
升级时仍需检查兼容性。发布说明将 QQ 机器人在线程作用域下恢复按群组隔离会话列为破坏性变化，相关部署不能仅按普通修复版本处理。托管压缩与 MCP 管理也需要配套组件和能力协商，不能只根据 CLI 版本号判断是否可用。
开发者披露的验证范围同样有限：手动压缩与 MCP 管理的本地验证主要在 macOS 上完成，使用确定性或受控模型，真实上游模型部署链路及完整跨平台验收仍有缺口。本文依据公开发布说明和开发记录分析，未对该版本进行独立安装测试。因此，更可靠的判断是：Qwen Code 正在补齐长任务运行所需的控制与恢复机制，而这些机制在具体团队环境中的稳定性、成本收益和可用范围，仍需部署验证。