DeepSeek、ルーターワーカー型プログラミングエージェント「dsh-superagent」のコードを公開

リクエストを待機するエージェント

その仕組みは「Ticket」という概念に基づいている。これは、許可された人物がエージェントに話しかけた際にオープンされる作業単位だ。各Ticketは独自のセッションとディレクトリで実行され、結果は元の会話（多くの場合、コード変更の提案としてレビューに提出されるpull requestの形）に戻される。ローカルのWebインターフェースは、人間の介入が必要な項目のみをリスト表示する。

プロジェクトのREADMEは、人間の注意力を最小限に抑えつつ、最大限の価値を提供するというシンプルなルールを定めている。プロジェクトの哲学文書によれば、エージェントは確認を1回だけ求め、作業中は沈黙を保ち、結果、質問、または失敗があった時のみ発言を再開する。

ルーター・ワーカーアーキテクチャ

同チームによれば、一般的なエージェントはセッションを基本単位と考える。ifengが引用したレポートによると、人間が同時に能動的に追跡できるセッションは3〜5つまでであり、モデルの能力ではなく人間の注意力が並行作業の制限要因となる。提案されたアーキテクチャは2層構造だ：長時間稼働するRouterが通信とタスクの割り当てを管理し、分離されたWorkerセッションが実際の作業を実行する。

ドメインモデルは、GitHubまたはFeishuがTriggerと呼ばれるイベントを生成し、評価ステップで一連のTriggerが新規作業を呼び出すかどうかを決定する、という正確な連鎖を記述している。各Ticketは、なぜ実行可能なのかを述べた不変のMandateを持つ。その後、pull requestへの後続コメントは、新たなメンションなしに適切なWorkerにルーティングされる。シェルコマンドは5秒後にバックグラウンドに移行され、Workerがメッセージを受け取り続けられるようにする。プロアクティブな作業は、off、observe（デフォルト）、autoの3つのモードによって制御される。observeモードでは、エージェントは受け入れていたであろう内容を記録するだけだ。

シミュレーションによる結果

DeepSeekは、模擬的なグループディスカッションとGitHub CIのフロー（試行あたり約300メッセージ、そのうち実際の作業依頼は約20件）でシステムをテストし、各設定を5回実行した。スーパーエージェントはp50が12.4分、p95が15.7分を示した。一方、サブエージェントとニュートラルプロンプトを使用した単一セッションではp95が29.5分で、p50は報告されなかった。このベースライン設定では、サブエージェントは5回の試行で一度も呼び出されなかった。

同じデータによると、到着数が約1件/分から40件/分に増加すると、バッチサイズは1.0から2.8に、リクエストあたりのレイテンシは2.5秒から3.9秒に増加した。これらの数値はDeepSeekによる自己申告であり、レポートの二次的な記録に基づいている。また、プロジェクトは合成メッセージと模擬ツールでのみテストされており、生成されるコードの実際の品質は測定されていないと明記している。

インストールには、プロトタイプはNode.js 22.19+または24+、git 2.32+、Python 3.8+、tmux、GitHub CLI 2.48+を必要とする。リポジトリは最後に、このエージェントがオペレーティングシステムのユーザーの全権限で実行されるため、使用前には隔離する必要があると記している。