DeepSeek Super-agent 设计解析：Router-Worker 架构与本地连接挑战

DeepSeek が Super-agent という AI エージェントの構想を公開しました。利用者と会話を続けながら複数の仕事を進め、GitHub やチャットの変化にも対応します。人が作業やセッションを管理する負担をどう減らすのか、既存のエージェントとの違いも含めてまとめました。

TL;DR

• Super-agent は仕事の進行やセッションの管理をシステムへ任せ、人が細かく指示・確認する負担を減らす構想です。
• 利用者との会話と仕事の振り分けは Router、個々の作業は Worker が担当します。GitHub やチャットの通知も受け取り、対応が必要なものを担当へ届けます。
• Router と Worker をクラウドで動かし、自宅PCのコードや開発ツールを使って作業する構成も想定しています。
• 利用者が複数サービスで組んでいる仕組みを、AI ベンダーが体系化して提供してくれることに期待しています。
• Worker もクラウド側にあるため、自宅PCとの接続や GUI・ブラウザ操作が安定して動くかは気になるところです。

はじめに

DeepSeek Harness のチームが、Exploring Super-agent Design: Towards a More Autonomous Agent System という設計記事を公開しました。

元記事では、仕事の振り分けやセッション間の情報の引き継ぎをシステムへ任せ、人が細かく指示・確認する負担を減らす設計を提案しています。その分、人が仕事の目的や優先順位を決めたり、成果を確認して承認したりすることに集中できるようにする狙いです。

以前、Work や dot から自宅PCの Codex へ仕事を依頼する構成を記事にしました。今回の構想では、利用者との対話と実作業を分担する仕組みを、エージェントの実行基盤として扱っています。

自分でも仕組みを理解しておきたかったので、元記事の設計を既存のエージェントと比べながらまとめてみました。

DeepSeek の Super-agent 構想

Super-agent が目指すのは、人が個々のセッションを操作して仕事を進める負担を減らし、複数の仕事を継続して任せられるエージェントです。人は目的や優先順位を伝え、必要な場面で判断や承認を行います。その間の仕事の振り分けや情報の引き継ぎを、システム側が受け持つ設計です。

元記事では、モデルの能力が上がるにつれて個々の仕事への監視や細かな指示が減ってきたと説明しています。複数のエージェントを連携させる能力も上がり、別々のセッションへ仕事を分担する使い方も可能になってきました。

Claude Code や Codex で複数の仕事を進めるときは、実装用や調査用のセッションを分けて使うことがあります。文脈が混ざらない一方で、進捗の確認や対応するセッションへの追加指示は利用者が行う必要があります。

個々の仕事を任せられるようになっても、どのセッションが何を知っているかを人が覚えておく必要があれば、同時に任せられる仕事の数は人間の注意力に制限されます。元記事では、モデルの能力向上に伴って、この人間側の負担が生産性を制限するようになると説明しています。

そこで、担当を決めて必要な情報を届けるところまでエージェントの仕組みに含めます。人からの指示に加えて GitHub やチャットの変化も受け取り、対応が必要な仕事を進めます。途中で判断が必要になったときや成果の確認を求めるときには、人へ戻ってきます。

利用者が話す相手や場所を変えても、それまでの依頼を踏まえて対応する。作業中にも別の仕事を引き受け、異常があれば復旧する。こうした動作を継続して行えるように、エージェントの実行基盤を設計し直すのが Super-agent の構想です。

比較の出発点として、ローカルのエージェントを仕事ごとに起動する構成を描くと次のようになります。

利用者が仕事ごとのセッションを管理する構成

Super-agent では利用者とのやり取りを受け持つ Router と、仕事を実行する Worker を分けます。会話や作業の記録は実行プロセスの外へ保存し、コードや開発ツールがある環境にも接続します。

DeepSeek の Super-agent 構想

利用者は実装を頼んだ後に別の調査を依頼しても、同じ Router と話を続けられます。担当は裏でそれぞれの仕事を進め、結果や相談が必要な点を Router へ返します。チャットから始めた仕事について、後から GitHub の PR に書いた追加指示を受けて進めることも想定しています。

元記事が挙げる性質は次のとおりです。

これを Router と Worker の分担やイベントの処理、非同期のやり取りによって実現します。実行処理と状態・環境を分けることや、外側から監視する仕組みも含まれます。ハーネスを含む実行基盤全体の設計が話の中心になります。

仕事ごとのセッションは内部に残ります。その管理をシステムへ任せ、利用者が毎回どのセッションを開くか考えなくても済むようにする構想だと理解しました。

利用者との対話と作業担当の分担

Router は利用者との会話を続けながら、新しい仕事を Worker へ振り分けます。進行中の仕事との関係や、複数の仕事にまたがる判断も扱います。

たとえば、ある不具合の修正を頼んだ後に別のライブラリの調査を依頼したとします。修正は Worker A、調査は Worker B が担当し、Router は両方の状況を把握して利用者と話を続けます。

Router 自身は実作業を行いません。元記事では Bash ツールを持たなくてもよく、軽いモデルで速度と品質を両立できる場合が多いとしています。会話を担当するモデルが実装や長い調査に取りかかると、その間の会話や別の依頼への応答も遅くなるためです。

Worker は仕事ごとに分かれた文脈と、実作業に必要なツールを持ちます。不具合の原因を調べてコードを直す担当と、ライブラリの仕様を調べる担当では、途中のログや推論を共有し続ける必要はありません。各 Worker が作業を進め、重要な結果を Router へ報告します。利用者への返答は Router がまとめて行います。

別の担当へ仕事を任せる点は、一般的な orchestrator / worker 構成やサブエージェントと共通しています。ただ、複雑な仕事を細かい作業へ分ける orchestrator と、ここでいう Router では担当範囲が違います。Router は独立した仕事の振り分けと全体の調整を行い、一件の仕事の詳細な計画や分割は Worker 側が受け持ちます。

Worker はその仕事に必要ならさらにサブエージェントを使えます。たとえば機能追加を担当する Worker の中で、設計・実装・テストを分担する Agent Team を動かす形です。Router と Worker は役割の区分なので、必ずそれぞれが一つのセッションになるという意味でもありません。

外部イベントと作業中の追加指示

継続して仕事を進めるには、最初の依頼に加えて、その後に起きたことも受け取る必要があります。

修正した PR にレビューが付く。CI が失敗する。チャットで変更の相談が出る。元記事ではこうした外部の出来事を Trigger として扱います。

すべてをモデルに判断させると、関係のないメッセージにも推論が必要になります。そこで、送信元や対象のグループなど、決まった条件で判定できるものはプログラムで先に絞ります。そのうえで、内容を読まないと対応の要否が分からないものをモデルに判断させます。元記事の Fast Path / Slow Path はこの分担です。

担当が決まった後の続報にも、毎回 Router の判断は必要ありません。

たとえば Worker A が PR の修正を担当するなら、その PR に関する通知の届け先として Worker A のセッションを登録します。コメントや CI 結果の通知が届くと、プログラムがこの登録に従って Worker A へ直接送ります。通知のたびに Router のモデルが担当を選び直す必要はありません。

元記事の subscription (購読) は、この通知先の登録を指しています。PR やチャットのスレッドごとに届け先を登録し、後続の通知をプログラムで振り分ける仕組みです。届いた内容を読んで対応を考えるのは Worker です。

まだ担当のいない新しい仕事や、担当をまたぐ調整は Router が扱います。Worker も重要な結果を Router へ報告するので、Router は全体の状況を追いながら利用者とやり取りできます。

作業中の追加指示を受け取るため、ツールの実行も非同期にします。長いビルドを開始したら、完了までその呼び出しの中で待ち続けず、結果が後からイベントとして届くようにします。その間に届いた追加指示も、現在のモデルの推論ステップが終わった時点で扱えます。

これならビルド中に方針が変わっても、ビルドの終了まで会話を止めずに済みます。単に裏でコマンドを実行するだけでなく、作業の途中にも入力を受け取れるようにする設計です。

長く動かすほど増える履歴にも工夫があります。直近で必要な情報はコンテキストへ入れ、長い内容や古い記録は外へ置いて参照を残します。過去の仕事が再び話題になったら、その参照をたどって必要な記録を読み直します。元記事では Inline & Spill、Chain of Recall と呼んでいる仕組みです。

実行処理・履歴・作業環境の分離

この構想ではエージェントの実行処理と履歴をクラウドへ置き、実際に作業する環境を必要に応じて接続します。

Agent Loop はモデルに問い合わせ、返ってきたツール呼び出しを実行へつなぎ、その結果をモデルへ返す処理です。これを実行するプログラムと、残しておきたい会話や作業の記録を分けます。

Agent Loop のプロセスが落ちても、記録は外へ残ります。別のプロセスがその記録を読み直せれば、同じ仕事の続きを扱えます。実行中の一つのプロセスを生かし続けることと、仕事の継続を分けて考えるわけです。

元記事でも、Anthropic の Managed Agents の設計記事を参照しています。こちらもハーネスとセッションの記録、作業環境を分け、それぞれを交換できるようにする設計です。

DeepSeek が特に接続先として挙げているのは、利用者が普段使っているPCです。自宅PCには未コミットの変更や、そのPCで使っている開発ツールがあります。すべてをクラウドへ複製する代わりに、作業環境をそのまま使います。

PC側にはコマンドを実行して結果を返す軽量な daemon を置きます。会話や仕事の状態はクラウド側で管理し、Agent Loop が必要な処理をPC側へ依頼する形です。元記事では BYOM (Bring Your Own Machine) と呼んでいます。クラウドの環境や、必要なときに作る環境も接続先に含まれます。

この構成なら、自宅PCを閉じてもクラウド側での対話や記録は維持できます。そのPCが必要な作業は接続を待ち、再びオンラインになったときに進める想定です。

継続運用には外側から状態を見る Watchdog も置きます。プロセスの停止や API エラーだけでなく、同じ作業を繰り返して進んでいない状態や、目的からのずれも確認します。Watchdog 自身もツールを持つエージェントのセッションで、主な実行処理とは別に監視や復旧を行います。

以前の自分の構成では、クラウド側の dot からローカルで動く Codex などの作業担当へ依頼していました。Super-agent の構想では Worker の Agent Loop もクラウド側に置き、ローカルPCにはコマンドを実行して結果を返す daemon を置きます。

以前は作業担当がPC上で動いていたので、そのPCの GUI やブラウザを操作するツールを直接使えました。Worker がクラウド側にあると、手元の画面を確認したり操作したりするためにも、クラウドとPCの間でやり取りする仕組みが必要になります。クラウドに用意したブラウザで調べる仕事と、自宅PCのアプリや既存のブラウザを使う仕事では、接続先も変わります。

クラウド側で操作を判断し、PC側のプログラムに画面取得やクリックを実行してもらう形が考えられます。会話や仕事の記録が残っていても、通信が切れる前と同じ画面が開いているとは限りません。接続が戻ったら操作対象の状態を確認し、その状態に合わせて続きを進める必要があります。

操作の指示や結果がクラウドとPCを行き来するため、途中で止まったり、結果がうまく戻らなかったりしないかは気になります。画面の取得から操作結果の確認、通信断後の再開まで、基盤側で安定して扱えるようになることを期待しています。

構想の一部を実装した dsh-superagent-prototype も公開されています。README には内部版や設計記事と同一ではなく、記事中の将来構想には未実装のものもあると明記されています。ここで説明した全体像がそのまま完成した製品として使える段階ではないようです。

既存のエージェントとの比較

Claude Code や Codex でもサブエージェントへの分担やクラウドでの作業、離れた端末からの追加指示ができます。Cowork にも複数段階の仕事を任せ、クラウドで並行して進めたり定期実行したりする機能があります。

Super-agent の構想で整理されているのは、そうした機能を継続的な仕事の流れとしてどう組み合わせるかです。利用者と話す担当や続報の届け先に加え、記録の保存と作業環境への接続まで設計しています。

利用体験としては Grok Bot や ChatGPT dots、Claude Duet にも近い部分があります。

Claude Duet は現時点では research preview で、接続したアプリを一定間隔で確認します。

Grok Bot や dots、Duet を見ると、普段の会話を保ったまま裏で仕事が進む使い方は想像しやすくなります。DeepSeek の記事は、その使い方を実現するための実行基盤を具体的に説明しているところが面白いと感じました。

おわりに

仕組みを追っていくと、最近見かける Grok Bot からほかのエージェントへ仕事を任せる構成に近いと感じました。以前自分が組んだ dots 基盤も、会話を担当するエージェントと実作業を進めるエージェントをつなぐ点では同じ発想です。

利用者が複数のサービスを組み合わせて作っているこうした仕組みを、AI ベンダーが体系化して提供してくれると面白そうです。サービス同士のつなぎ方や仕事の引き継ぎを自分で組まなくても済むなら、より多くの人がエージェントに仕事を任せやすくなると思います。

自分は以前、dot との接続がうまくいかず、結局使わなくなりました。その経験もあるので、Worker までクラウド側へ移る構成で自宅PCとのやり取りがどう扱われるかは気になります。普段の開発環境や GUI・ブラウザの操作まで含めて安定して使えるなら、かなり自分の使いたい形に近づきそうです。