Qwen Code 0.23、マルチエージェントワークフロー制御と階層型メモリ権限を常駐サービスに統合

Qwen Code 0.23.0 の焦点はモデルの変更ではなく、コマンドラインエージェントを、Web Shell、スケジューラ、ほかのエージェントから共同操作できる常駐実行環境へ段階的に移行することにある。新バージョンでは、Channels で複数の名前付きバックグラウンドタスクを同時実行でき、ユーザーはセッションを切り替えたり、`/session cancel` で中止したりできる。daemon はさらに、Workflow の照会、一時停止、再開、再試行、キャンセル、削除のためのインターフェースを提供する。スケジュールされたジョブは実行のたびにタイムスタンプ付きの新しい子会話を作成し、異なる実行回が同じ会話状態を直接共有することを防ぐ。

状態管理もさらにきめ細かくなった。新しい workspace memory task では、保存レイヤーとして project または user を指定でき、remember と forget の操作にファイルシステムの権限境界を強制する。ワークスペースレベルでは Extension skill の状態を一括で上書きできる一方、上位レイヤーの拡張機能設定が持つ権威性は維持される。マルチエージェント通信では、名前を使ってほかの session を指定でき、メッセージには送信元の task／sender ラベルが付く。`qwen review emit-workflow` は決定論的な並列レビュースクリプトも出力でき、agent fan-out を人手で編成する際のばらつきを抑える。

ツールの自動承認については、AUTO モードの分類器が MCP ツール名だけでなく、長さを制限したパラメーターとサーバーの annotations も受け取るようになった。これにより判断材料は増えるが、annotation 自体の信頼性が保証されるわけではない。導入担当者は引き続き、これを認可の証明ではなく、サーバーから提供された入力として扱う必要がある。

ネットワーク面の2つの変更は、アップグレード時に特にテストが必要だ。`qwen serve` は企業のプライベート Git ホストから拡張機能をインストールできるようになり、公開ネットワーク向けのポリシーだけに制限されなくなった。また、Bearer token が設定されておらず、認証も明示的に要求されていない場合、信頼済みの loopback インターフェースから完全な operator API を利用できる。これは開示済みの脆弱性ではないが、コンテナ、フォワードプロキシ、共有開発ホストが「localhost は単一の信頼できるユーザーと同義」という前提を満たすとは限らない。チームは本番投入前に認証を明示的に有効化し、リバースプロキシによる転送を制限し、プライベート拡張機能の取得元を監査するとともに、一時停止と再試行が冪等性を備えているかをテストすべきだ。[GitHub リリースノート](https://github.com/QwenLM/qwen-code/releases/tag/v0.23.0)では既知の breaking change はないとしているが、制御プレーンがこれほど大幅に拡張されている以上、セマンティックバージョニングだけを根拠に自動アップグレードするのは避けるべきである。