AI 程式工具
Qwen Code 0.23 Moves Multi-Agent Workflow Control and Tiered Memory Permissions into a Persistent Service
The new release adds permission-bounded project and user memory, a Workflow API with pause and retry support, and named tasks that can run in parallel and be switched between. It also expands access to private Git extensions and the local operator API, requiring enterprise deployments to reassess their network and authentication boundaries.
The focus of Qwen Code 0.23.0 is not a model change, but the gradual transformation of the command-line agent into a persistent execution environment that can be operated jointly by Web Shell, schedulers, and other agents. The new release lets Channels run multiple named background tasks concurrently, allowing users to switch sessions or terminate one with `/session cancel`. The daemon also exposes interfaces for querying, pausing, resuming, retrying, canceling, and deleting Workflows. Each scheduled run creates a new timestamped child conversation, preventing different execution runs from directly sharing the same conversation state.
State governance has also become more granular. The new workspace memory task can target either the project or user storage tier and enforces filesystem permission boundaries for `remember` and `forget` operations. Extension skill states can also be overridden in batches at the workspace level while preserving the authority of higher-level extension settings. For multi-agent communication, other sessions can be addressed by name, with messages carrying source task and sender labels. `qwen review emit-workflow` can also generate deterministic parallel review scripts, reducing inconsistencies in manually orchestrated agent fan-out.
For automatic tool approval, the AUTO mode classifier now receives not only MCP tool names but also length-limited arguments and server annotations. This provides more context for classification, but it does not make the annotations themselves trustworthy. Deployers must still treat them as server-supplied input rather than proof of authorization.
Two network-related changes particularly warrant upgrade testing: `qwen serve` can now install extensions from private enterprise Git hosts and is no longer limited to public-network policies; and when no Bearer token is configured and authentication is not explicitly required, trusted loopback interfaces can access the full operator API. This is not a disclosed vulnerability, but containers, forwarding proxies, and shared development hosts may not satisfy the assumption that “localhost equals a single trusted user.” Before deployment, teams should explicitly enable authentication, restrict reverse-proxy forwarding, audit private extension sources, and test whether pause and retry operations are idempotent. The [GitHub release notes](https://github.com/QwenLM/qwen-code/releases/tag/v0.23.0) state that there are no known breaking changes, but given such a substantial expansion of the control plane, automatic upgrades based solely on semantic versioning are still inadvisable.