DeepSeek Harnessチームは10月31日夜、長文記事「Super-agent設計の探求：より自律的なAgentシステムへ」を公開した。2層構造のエージェントアーキテクチャを提案し、原型となるdsh-superagent-prototypeをGitHubで公開している。チームは記事中で、この原型は技術路線を検証するためのもので、DeepSeekの正式な製品ではないと明記した。
記事の出発点は素朴な観察だ。モデルが1つのタスクを単独でこなすのに必要な人手の介入は減り続けており、生産性を縛るのは人の注意力になった。チームによれば、1人が同時に追えるアクティブなセッションは通常3〜5個で、タスクが増えると手動で行き来し、文脈も自分で覚えておかなければならない。
セッションはシステムの実装上の詳細であるべきで、ユーザーの認知的負担であってはならない。
Routerが対話を、Workerが作業を担う
アーキテクチャは2層に分かれる。常駐するRouter層は、人からのメッセージの受信、全体の文脈の維持、タスクの割り振りを担当する。Bashなどの実行ツールは持たず、軽量モデルで駆動できる。Worker層は、文脈が互いに隔離された複数のセッションで構成される。完全なツールを備え、最強のモデルを使い、それぞれが1つの仕事に専念して並行して動く。Workerはユーザーに直接返信せず、状況や結果をまずRouterに報告し、対外的にはRouterが一括して話す。
このほか、エージェントを「常にオンライン」にするための設計がいくつかある。
- イベント駆動：グループチャットのメッセージ、メール、予定のリマインダー、コードレビューのコメント、CIの結果はすべてTriggerとして扱う。まずプログラムのルールでノイズの大半を除き、残ったものだけをモデルに渡して動くかどうかを判断させる。すでに割り当て済みのThreadの後続イベントは、Routerを経由せず、プログラムが対応するWorkerへ直接届ける。
- 非同期ReActループ：時間のかかるツール呼び出しをstart()とstop()に分ける。バックグラウンドのタスクは起動後ただちにStartedを返し、フォアグラウンドはユーザーの発言を受け続ける。結果は新しいイベントとしてセッションに戻る。
- 計算・状態・環境の分離：Agent Loopと状態はクラウドに置き、実行環境はユーザーのローカル機にとどめて軽量なデーモンだけを動かす。自前のマシンを持ち込むBYOMにも対応する。
- Watchdog：独立したセッションが定期的に目を覚まし、プロセスが生きているかを確認するだけでなく、各Workerに実質的な進展があるか、方向がずれていないかをモデルに判断させる。
記事には「投機的実行」の例も挙がっている。グループで誰かがバグを報告すると、エージェントはまずバックグラウンドで再現と修正を試み、直せたときだけ発言し、直せなければ人の手を煩わせない。
数字は合成負荷によるものだけ
チームは比較実験を行った。1ラウンドあたり約300件のメッセージのうち、業務依頼は約20件で、残りは雑談とノイズ。各方式を5回ずつ繰り返した。Super-agentのタスク完了時間はp50が12.4分、p95が15.7分。対照群の「単一セッション＋Subagent」は、中立的なプロンプトでp95が29.5分だった。イベント直通の仕組みを外すと、Routerの判断回数は約30%、キャッシュ読み取りトークンは約37%増えた。
Routerの負荷試験では、Triggerを毎分約1件から約40件へ増やした。平均バッチサイズは1.0から2.8に、1回のリクエスト時間は2.5秒から3.9秒に上がった一方、判断1件あたりに割り振られる推論時間は6.4秒から1.6秒に下がった。
制約もはっきり書かれている。実験は合成負荷と簡略化した環境で行われ、測っているのはスケジューリングと協調だけで、個々のタスクの出来栄えは測っていない。Super-agentのトークン消費は単一セッション方式より多いが、総量は公表されていない。公開された原型は現状、単一のGitHubリポジトリのみが対象で、デバイスをまたぐ運用、クラウド常駐、Watchdogは完全には実装されていない。
dshからSuper-agentへ
時系列でつなげると、DeepSeekはエージェント分野でまずフレームワークを公開し、続いて調整の考え方を公開した形だ。今年8月前後に、MITライセンスでエージェントフレームワークのDeepSeek Harness（コマンド名dsh）をオープンソース化した。ファイルシステム、シェル、モデルアダプター、Web UI、サブエージェントはいずれも差し替え可能なプラグインとして作られている。その後の数か月でV4.1 Flashなどのモデルが相次いで公開され、サードパーティのコーディングツールも主力モデルとして採用し始めた。
今回の長文は一段上の層を扱い、議論しているのは「1つのエージェントインスタンスが同時に数十件をどう見張るか」だ。チームによると、記事中の非同期タスクの仕組みはすでにDeepSeek Harnessに組み込まれているが、デフォルトではオフになっている。同じ考え方に基づく社内インスタンスは稼働を続けており、問題の再現と修正、コードレビューへの対応、Harness自体の改良に使われているという。
チームが挙げた未解決の課題には、タスク量に応じたRouter層のスケール、数か月にわたる長期記憶、複数のエージェントインスタンス間の通信がある。最も具体的に書かれているのは安全面だ。クラウド上のAgent Loopがプロンプトインジェクションを受けると、接続しているローカル機器が操作されかねず、モデルの文脈に入れた認証情報も通常の実行中に漏れる可能性がある。これらのリスクをどう防ぐかについて、記事は完全な解決策を示していない。
参考資料：DeepSeek Harnessチームの技術長文とdsh-superagent-prototypeリポジトリの説明、ITHome、CocoLoop、鳳凰網科技。実験の所要時間と負荷試験のデータは、チームが公表した合成負荷の結果に基づく。