【geek-terminalニュース】DeepSeek常時稼働エージェントの内部公開、Router–Worker設計を深掘り

以前お伝えしたDeepSeek Harness公開・接続機能の続報です。今回は常時稼働を支える「dsh-superagent」の内部設計とOSS化に踏み込みます。

【事象の全貌と背景】
DeepSeek Harnessチームが公開したのは、単一のGitHubリポジトリを担当するMITライセンスのコーディングエージェント。Harnessのバンドルとして動き、GitHubと任意のFeishuから依頼を受けます。正式製品ではなく研究用プロトタイプで、公開版は社内版と同一ではありません。設計記事の構想には未実装部分もあります。[公式README](https://github.com/deepseek-ai/dsh-superagent-prototype)

注目したいのは、依頼と追加コメントを継続的に受ける担当者へ近づける設計です。長いテストを待つ間にも新しい依頼は届く。全部を同じ会話に流し込めば、受付と実作業の待ち時間、複数案件の文脈が絡み合う。ここをRouterとWorkerに分けて考えられるのが、自作派に刺さる公開内容です。

【技術的ディープダイブ】
入口はイベントのTrigger、それを評価するEval、受理された仕事のTicketという流れ。Ticketには、着手の根拠と作業範囲を示すMandateが付きます。Routerが受付と振り分けを担い、TicketごとのWorkerが専用セッションとディレクトリで実行。結果は元の会話に返し、PRも作成できます。自作実装と比べるなら、まず「依頼の識別子」と「実行セッション」が一対一になっているかを見たいところです。

継続処理の要はSubscription。関連する会話の後続メッセージを既存Ticketへ届けるため、PRの追加コメントを担当Workerが引き継げます。ただし、届いた会話は新たな権限を意味しません。外部コメントを文脈として読むことと、仕事の範囲を広げることを分離し、Mandateで制約します。これはプロンプト注入への完全な耐性を実証する話ではなく、権限を扱う設計の話です。

自発的な着手にはoff・observe・autoの3モードがあり、既定はobserve。推定した仕事を「受理するはずだった」と記録しても開始しません。許可された人からの明示依頼とは別経路です。常時稼働の意味を、周囲の発言を片端から実行することに読み替えてはいけません。[公式の認可設計](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md)

実行資料では、Workerの前景シェルコマンドは5秒後にバックグラウンドへ移ります。次のステップで新着メッセージを受け取れる仕掛けです。自作エージェントでも、長いビルド待ちが会話受付まで塞いでいないかを比較できます。[公式の実行資料](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/003-execution.md)

性能値も境界を押さえたい。MarkTechPostが紹介したチームの自己申告では、約300メッセージ・約20依頼のシミュレーションで完了時間の中央値12.4分、95パーセンタイル15.7分。単一セッション＋サブエージェント構成の後者は29.5分でした。ただし合成メッセージと模擬ツールの評価です。混雑時の仕事さばきの参考値であり、コードの品質や長期無人運用の信頼性を証明する数字にはできません。[評価条件の報道](https://www.marktechpost.com/2026/11/01/deepseek-dsh-superagent-router-worker-coding-agent/)

【コミュニティの生々しい熱量と議論】
提供されたr/DeepSeekの反応抜粋では、East-Alarm3404が、履歴をイベント記録として残してモデル向けに再構成する説明に注目し、「巨大な会話をメモリに維持することだけには依存しない」と評しています。ここは投稿者による資料の読み解きで、長期記憶が解決済みという意味ではありません。CharacterExplorer109も「長時間のワークフローで文脈のずれをどう扱うのか」と疑問を提示。セッションを分けても目的を忘れない保証にはならない、という実装者目線の論点です。

Cautious_Sky6642は「状態は実行をまたいで残るのか」と問い、I_AmA_ZebraはHermesとの比較を求めています。SilentLennieの「今や『みんな』こういうものを作っているようだ」という冷めた反応もある。以上は提供抜粋の訳・要約で、今回このスレッド本文は再取得できませんでした。長期運用を検証した証言や、競合に勝った証拠としては扱いません。[反応抜粋の出典](https://www.reddit.com/r/DeepSeek/comments/1xkg08h/deepseek_has_opensourced_again_unveils_super)

同じ抜粋には、v_0009の「ファイルにアクセスできない」という説明や、別ユーザーによるmicroVMへの言及もあります。しかし公式運用資料では、RouterもWorkerも運用者のOSユーザー権限で動作します。Ticketごとのディレクトリ分離はOS権限の隔離ではなく、専用OSアカウントの利用が案内されています。コメントが別構成を指すかも確認できず、公開版の安全性を説明する根拠には採用できません。[公式の運用資料](https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/006-deployment.md)

【今後の展望とエコシステムへの影響】
筆者の見立てでは、今回の収穫は、受付・権限・実行・追加入力を分ける設計を手元のコードと比較できることです。人への通知も、依頼の確認後は発言を抑え、結果・判断依頼・失敗報告に集中する方針。モデルの推論能力に加え、人の注意をどれだけ消費するかが設計対象になっています。

今後、単発デモの成功だけでは常駐エージェントを評価しにくくなるでしょう。自作派なら、既存Ticketにコメントを戻せるか、受付が実作業に巻き込まれないか、着手範囲を追跡できるかを点検したい。既存ツールが直ちに不要になる根拠はありません。長期状態、復旧、実コードでの品質を検証しながら、継続して任せられる条件を詰める。その設計議論をOSSで始められることが今回のニュースです。