Muse Code がエージェントをセッション中ずっと生かし続ける理由

「生成して捨てる」モデルの問題

マルチエージェント型のコーディングツールの多くは、同じレシピに従っています。タスクが来たらヘルパーエージェントを起動し、作業の一部を渡し、結果を回収して破棄する。抽象としてはきれいですが、コストは醜い。新しく生成されたエージェントは毎回ゼロからのスタートです。リポジトリ構造を読み直し、ビルドシステムを再発見し、コードベースの規約を学び直さなければなりません。10 タスクのセッションでは、このコンテキスト収集の「税金」を 10 回払うことになります。

この税金はトークンだけの話ではありません。コールドスタートのたびに本来の作業が遅れるレイテンシの問題であり、1 時間前に学んだことを忘れたエージェントが同じ質問を二度してくるという、人間側の誘導コストの問題でもあります。

Muse Code の答え：永続化

Muse Code は、シンプルなメインエージェントループと、一連の非同期バックグラウンドエージェントで構成されています。そしてこのバックグラウンドエージェントは、セッションを通じてずっとアクティブなままです。個々のタスクのために生成されるのではありません。それぞれが専門化されており、セッションの進行とともにコンテキストを蓄積し続け、メインエージェントに報告する価値があるかどうかを自分で判断します。

この最後のポイントは、聞こえ以上に重要です。バックグラウンドエージェントは指示を待ってメインループをブロックすることもなければ、ステータス更新でメインループを溢れさせることもありません。次のステップを自律的に進め、意味のあるタイミングでだけ連絡してくる。Meta が明言している設計理由は、まさに前述の 2 つのコストです。永続化はレイテンシを削減し、難しいマルチステップのタスクにおける人間の誘導の必要性を減らします。

並列で働くワーカー、バックグラウンドで見張るレビュアー

実際に使ってみると、これは「派遣の順番待ち行列」ではなく「固定の役割を持つチーム」として体感できます。ワーカーが並列で変更を実行し、レビュアーがバックグラウンドで出力を継続的に批評してから、あなたのもとに届けます。ローンチ時の「デフォルトでマルチエージェント」というフレーズは正確です。協調は有効化するモードではなく、すべてのタスクの実行方法そのものなのです。出荷が速くなるのは、個々のエージェントが速いからではありません。品質管理が後付けではなく、並行して行われるからです。

後付けではなく、モデルに訓練済み

このハーネス設計が、汎用モデルのラッパーよりも Muse Spark 1.2 と組み合わせたときにうまく機能するのには理由があります。モデルは Muse Code のハーネスと共同で訓練されており、そのトレーニングレシピはゴール達成やコンテキスト圧縮と並んで、サブエージェントの挙動を明示的に最適化しています。メインループと永続的なスペシャリストたちという分業体制は、上に被せたプロンプトエンジニアリングの小技ではなく、モデルが訓練中に実際に経験したものです。「リトライが減り、ツールの使い方が上手くなる」という主張の根拠はここにあり、詳細は Muse Spark 1.2 の訓練に関する記事で解説しています。

永続化が解決しないこと

長生きするエージェントたちが同じリポジトリを同時に編集すれば、マージ災害のレシピになりかねません — 作業コピーを共有していれば、の話ですが。実際には共有していません。作業がファンアウトするとき、書き込み可能な子エージェントはそれぞれ分離された git worktree を受け取るため、並列作業がファイル上で衝突することはありません。この分離メカニズムは独立した解説に値します：エージェントのファンアウトと git worktree。そして、見ていない間にエージェントたちが実際に何をしたのか知りたくなったら、追記専用のイベントログに完全な答えがあります。