IT之家 10月31日のニュース、DeepSeek Harness公式チームは本日、「Super-agent設計の探求：より自律的なAgentシステムへ」という記事を発表し、エンジニアリング実践に向けたSuper-agentアーキテクチャの設計思想を紹介した。
大規模モデルが単一のタスクを実行する際に人の介入をますます必要としなくなるにつれ、生産性のさらなる向上を制限する要因は次第に人の注意力へと移りつつあり、Agentシステムは、指令に受動的に応答する単一タスクのツールから、常時オンラインで複数のタスクを並行して処理できる自律的な協作者へと進化する必要がある。
DeepSeek によると、既存の主流の Agent 設計は依然として単一の Session（セッション）を基本単位としており、異なる Session 同士は相互に独立している。ユーザーが複数の作業を並行して進める場合、各 Session のコンテキストを手動で切り替えて維持する必要がある。
DeepSeekチームの観察によると、一人が同時にフォローできるアクティブなセッションは通常3〜5個程度だという。CLI、MCP、または外部コネクタでローカルAgentを拡張しても、単一セッションの同期ブロック、マルチタスクのコンテキスト混乱、ローカルデバイスのオフライン後のタスク停止といった問題に直面する可能性は残る。
彼らはこの新しいAgentの形態とそのシステムアーキテクチャをSuper-agentと呼び、連続的、高効率、能動的、持続的という4つの基本特徴を归纳した。
まず、「連続」とは、ユーザーがインスタントメッセージやGitHubのコメントなど、さまざまなチャネルを通じて同一のAgentとやり取りできることを意味します。「効率的」とは、複数の複雑なタスクを並行して処理できることを意味します。「能動的」とは、システムが環境のイベントを継続的に観察し、処理に値する事項を自ら進められることを意味します。「永続的」とは、Agentが常にオンラインであり、長期にわたる稼働の中で異常な状態から復旧できることが求められます。
DeepSeekが提案する全体アーキテクチャは、主に二層アーキテクチャ、イベント駆動、人間中心のインタラクション、計算と状態および環境の分離、Watchdogの5つの部分で構成されています。
このうち、2層アーキテクチャはシステムを Router 層と Worker 層に分割します。Router は人間との対話を受け持ち、グローバルなコンテキストを維持してタスクを割り振り、Worker は互いに分離されたセッション内で具体的な作業を並行して実行します。Worker はユーザーに直接応答するのではなく、状態と結果を Router に報告し、Router が対外的なやり取りを一元的に行います。
イベント駆動メカニズムにおいて、グループチャットメッセージ、メールや予定リマインダー、コードレビューコメント、CI 実行結果などの外部情報は Trigger と呼ばれます。システムはまずプログラムのルールでイベントをフィルタリングし、その後、大規模モデルに行動が必要かどうかを判断させます。すでにタスクが割り当てられているイベントストリームについては、Worker が対応する Thread を購読でき、以降の関連イベントはプログラムから Worker に直接送信され、毎回 Router を経由する必要がなくなり、ルーティングの負荷が軽減されます。
DeepSeek チームはさらに、Inline & Spill と Chain of Recall（連鎖的想起）メカニズムについても紹介しました。前者は、近いうちに使われる可能性のある情報をモデルのコンテキストウィンドウに直接置き、予算を超える内容や使用頻度の低い内容はウィンドウの外に保持し、モデルが必要に応じて読み取れるようにします。後者は、Trigger、Thread、Worker Session などのオブジェクト間の参照関係を通じて、モデルが関連する ID に沿って段階的に過去のタスク情報を辿って取り戻せるようにするものです。
人間の待ち時間を減らすため、Super-agent は投機的実行メカニズムも導入しており、環境のシグナルに応じてバックグラウンドで事前に作業を進めることができます。例えば、会議の招待を受け取ったら、先に予定の衝突を確認し、背景資料を収集し、返信の下書きを準備します。研究開発の協働シーンでは、グループチャットで問題が議論されている間に障害の再現を試みたり修正案を探したりすることができ、問題を確認し簡単な修正方法が見つかった後にのみ、ユーザーに結果を引き渡します。
人間と機械のインタラクションの面では、記事は非同期 ReAct Loop を提案しており、時間のかかるツール呼び出しを非同期の start () と stop () に変更しています。Agent はバックグラウンドタスクを起動した後、すぐに Started 状態を返すことができ、タスクの完了を待つ必要はなく、バックグラウンドの結果はその後、新しいイベントとしてセッションに入ります。
こうすることで、フォアグラウンドの会話はユーザーの新しいメッセージを受け取り続けることができます。ただし、DS チームは、この非同期タスクメカニズムはすでに DeepSeek Harness に実装されているものの、まだデフォルトでは有効になっていないと特に説明しています。
長期間のオンライン実行に対応するため、DeepSeek は Agent Loop の計算、セッション状態、実行環境を分離（デカップリング）しました。計算と永続化された状態はクラウドに置かれ、実行環境はユーザーのローカルデバイスに置くことができ、コマンドの実行と結果の返却を担当する軽量な daemon だけをデプロイします。この設計は、BYOM（Bring Your Own Machine）、つまりユーザーが日常的に使用している開発機や個人 PC をクラウドの Agent に接続することをサポートし、クラウドの管理マシンへの接続やオンデマンドで作成する計算環境への接続にも対応しています。
さらに、システムはメインアーキテクチャとは別に独立した Watchdog Session を設け、外部制御ループを形成しています。Watchdog はインターフェースのエラーや状態復旧の失敗などのインフラ問題を監視するだけでなく、モデルによって Worker が実質的な進展を得ているか、実行の方向が目標から逸脱していないかを判断し、異常を検知した場合には介入して修復します。
DeepSeek チームはさらに予備実験を行い、Super-agent、イベントの直接透過機構を取り除いた Super-agent、そして 2 種類のプロンプト設定でのシングル Session + Subagent 方式を比較した。
実験は毎回約 300 件のメッセージを含み、うち約 20 件がワークリクエストで、各方式を 5 回繰り返し実行した。結果として、Super-agent のタスク完了時間の p50 と p95 はそれぞれ 12.4 分と 15.7 分、中立プロンプトでのシングル Session 方式の p95 は 29.5 分だった。
DeepSeek チームは、これらの実験は合成負荷と簡略化された環境に基づくものであり、主にシステムのスケジューリングと協調能力を評価するものであり、個々のタスクの実際の実行能力は測っていないと指摘している。
Router 層のストレステストでは、Trigger の到着レートを毎分約 1 件から約 40 件に引き上げると、平均バッチサイズは 1.0 から 2.8 に増加し、1 回のリクエストの所要時間は 2.5 秒から 3.9 秒に増えた一方、1 つの決定あたりに配分される推論時間は 6.4 秒から 1.6 秒に減少した。チームはこれに基づき、イベントが急増した際、Router はバックログされたイベントを統合することで実効スループットを向上できると考えている。
記事は同時に、このアーキテクチャには依然として解決すべき課題が残っていると指摘している。それには、Router 層をタスク規模に応じてどうスケールさせるか、月をまたいだ乃至さらに長い時間スパンの長期記憶、Session を離れた後の人間と機械の協働方法、異なる Agent インスタンス間の A2A 通信、そしてセキュリティとプライバシー保護が含まれる。特に、クラウド Agent がローカルデバイスに接続した後は、プロンプトインジェクション、端末側の認証情報漏洩、デバイス間の権限リスクをさらに解決する必要がある。
DeepSeek チームは、上記の考え方と DeepSeek Harness に基づいて構築された内部の Super-agent インスタンスが継続的に稼働しており、問題の再現と修正、コードレビューへの対応、そして DeepSeek Harness 自体のイテレーションに参加していると述べています。
さらに、記事の中では dsh-superagent-prototype という名前のプロトタイプ実装も公開していますが、このプラグインは技術路線の検証用であり、DeepSeek の正式な製品ではないことを明確にしています。
参考资料：
dsh-superagent の GitHub リポジトリ：https://github.com/deepseek-ai/dsh-superagent-prototype