openJiuwen、シングルエージェントとSwarmの実行セマンティクスを統一し、診断と目標に応じてcoding harnessを動的に調整

HuaweiのopenJiuwenチームは、長時間稼働するcoding agent harnessのシステム論文を公開した。焦点は固定ワークフローをもう一つ追加することではなく、シングルエージェント、サブエージェントへの委任、Swarmで同一の実行セマンティクスを共有させることにある。Railは、ツール、プロンプト、コンテキスト、制御機能を順に組み合わせ、可視性ゲートによって各ロールが利用できる能力を制限する。一方、Swarm Flowは、`budget`、`parallel`、`compact`、`pipeline`、ステートフルな`agent_session`、human-in-the-loopなどの演算子を提供する。これにより開発者は、エージェントアーキテクチャごとに実行エンジンを書き直すことなく、協調トポロジーを再構成できる。

実行中、フレームワークは基盤モデルの戦略を変更せず、モデルから見える状態のみを調整する。コンテキスト管理では、履歴を段階的に圧縮し、大きな生成物をコンテキスト外へ移して必要に応じて取得するほか、session affinityを利用してKV cacheを調整することもできる。Goal Modeは結果を「継続」「完了」「ブロック」に分類し、さらに回数、時間、リソースの上限を適用することで、エージェントが「予算枯渇」をタスク成功として誤って報告するのを防ぐ。コード変更後は、LSPが生成した型およびシンボルの診断を優先順位付け、重複排除、件数制限したうえで、次のターンへ自動的にフィードバックする。タスク横断のSelf-Reflectionは検索可能な経験ストアにのみ書き込まれ、モデルの重みは更新しない。

著者らは、500問のSWE-bench Verifiedで82.6%のPass@1を報告している。Terminal-Bench 2.1では、GPT-5.6 Sol使用時に87.19%、Fable 5使用時に84.04%を記録した。後者は同一モデルを使ったClaude Codeの83.8%に近く、harnessによる改善の可能性を示す一方、差はわずか0.24パーセントポイントにとどまる。異なるプロンプト、ツール、実装条件も依然として統制されていない。また、論文で比較されているのは「選定された」公式リーダーボード結果のみであり、総コスト、token使用量、再現可能な実行イメージについてはまだ十分に説明されていない。エンジニアリングチームは、まずbenchmarkのレシピが完全に公開されるか、そしてRailの権限ゲートが実際のプロセス、ファイル、ネットワークの隔離へと結び付くかを見極めるべきだ。