DeepSeek Superagentの使い方：実演でわかる受付・実行・会話の再利用

AIに作業を頼んだあと、「さっきの説明に例を追加して」と送ることもあれば、「別の機能も作って」と頼むこともあります。システムは、元の作業の続きなのか、新しい仕事なのかを区別する必要があります。

DeepSeek Superagentは、依頼を受け付け、作業単位の「チケット」にまとめ、実行担当へ渡して結果を返す仕組みです。 Routerが受付と振り分けを担当し、Workerが実際の操作を行います。

この記事では、ファイルを1つ作る小さな依頼を実際に流し、5枚の画面で順番に確認します。公開版の dsh-superagent-prototype はDeepSeek Harness（dsh）上で動く研究用プロトタイプです。内部版や設計記事の構想とは差があり、ここでは確認したソースの版に沿って説明します。公式リポジトリ

実演で確認する5つのポイント

まず、次の順番だけ押さえておくと、画面を追いやすくなります。

順番	確認すること
1	送る依頼の内容
2	システムが受信した記録
3	Routerが受け付けた理由
4	Workerが使ったツールと読み取り結果
5	依頼元に戻った完了メッセージ

今回は、上部に依頼フォーム、下部に実際のdshパネルを置くローカルページを追加しました。

このページと接続用の処理は、学習のために追加した独自拡張です。公式版に同じ画面が付属するわけではありません。 起動時のチェックと納品条件もローカル用に調整し、コード管理サービスに接続せず完了できるようにしています。Routerのモデル判断とWorkerのツール実行は、実際に動作させました。

スクリーンショットのUIは中国語です。以下では、見るべきラベルもあわせて説明します。

1. 確認しやすい依頼を用意する

依頼は「チケットの作業フォルダーに hello.txt を作り、指定した文を書き込み、読み直してパスと内容を返す」というものです。

書き込む文字列は、画面と照合できるよう中国語の原文をそのまま使いました。

你好，我是 Worker，已收到任务。

意味は「こんにちは、私はWorkerです。タスクを受け取りました」です。依頼には、外部サイト、子Agent、コードリポジトリを操作しないことも含めています。

送信前は、受信・評価・受付の件数がすべて0です。

2. 送信後、受信記録を確認する

「下发给 Router」（Routerへ送信）をクリックすると、上部に stored と表示されました。

dshの「触发」（トリガー）タブにも同じ依頼が現れ、状態は「已排队，等待评估」（待機列に入り、評価待ち）になっています。

受信は済んでいますが、Routerの判断はまだ始まっていません。

トリガーとは、受信したメッセージの記録です。今回は自動処理を先に一時停止し、「受信できた」と「実行することが決まった」を分けて観察しました。

3. 処理を再開し、Routerの判断を見る

処理を再開すると、「评估」（評価）タブに受付の記録が表示されました。理由は、許可リストに登録された人からの明示的な依頼であることです。

ここでチケットが作られます。チケットは、元の依頼、作業範囲、状態、実行用の会話をまとめる記録です。

今回のチケット番号は f751fe7e45 で始まります。後の実行と返信も同じチケットに対応しています。

4. Workerの実行記録を開く

チケットからSessionを開くと、Workerが何を行ったか確認できます。今回の記録には、作業フォルダーの確認とファイル作成を行うコマンド、ファイルの読み取り、完了報告が残っていました。

次の画面では、読み取りツールの詳細を開いています。

右側の「結果」にある1行目が、ファイルから読み戻した内容です。上部には同じチケットの完了返信も見えます。

Routerが依頼の行き先を決め、Workerがツールを使って作業を進める、という役割の違いがここで見えます。

5. 依頼元に戻った結果を確認する

ローカルページには、受付の返信に続いて、完了メッセージが戻りました。実際のファイルパスと内容が記載されています。

最初に依頼を送った場所で、結果を確認できます。

別途ファイルを直接確認し、指定した文字列と一致する UTF-8、43バイト のファイルが存在することを確かめました。Workerの会話画面では、この回の実行時間は 11秒 と表示されています。小さなタスクを1回動かした値であり、一般的な処理速度を示すものではありません。

今回の流れは次のとおりです。

ローカルページから依頼
        ↓
メッセージを保存
        ↓
Routerが受け付け、チケット作成
        ↓
チケット用のWorker会話を起動
        ↓
ファイルを作成し、読み戻して確認
        ↓
元のページへ結果を返信

この実演ではGitHubやGitLabには接続しておらず、PRやMRも作成していません。納品物はローカルのファイルです。

RouterとWorkerの役割

受付窓口と実行担当を分けると考えると、理解しやすくなります。Workerが作業している間も、Routerは別の依頼を扱えます。

担当	役割	今回の動き
Router	新規受付、既存作業への追加、停止、無視を判断	ファイル作成を新しい仕事として受付
Worker	調査、ツール操作、確認、結果報告	ファイルを作成して読み直す
実行基盤	記録保存、メッセージ配送、実行枠の管理	チケットと会話を作り、結果を返す

確定した作業の関係や状態はプログラム側で管理します。独立した依頼を複数受け付ければ、それぞれのWorkerで処理できます。同時に実行できる数は設定された枠によって決まり、空きがなければ待機します。Workerが作業内で子Agentを使う仕組みもありますが、今回は使っていません。実行と並行処理の説明

同じ会話を再利用する条件

Workerの会話はチケットごとに作成され、保存されます。同じチケットの続きなら既存の会話を使えます。新しいチケットには別の会話が作られます。

たとえば、後から来るメッセージによって扱いが変わります。

後からのメッセージ	想定される扱い
「さっきのファイルに説明を追加して」	元の範囲内なら同じWorkerが続行
「別に天気のページも作って」	新しい仕事として判断
「ありがとう、受け取った」	新しい作業を始める必要がない場合もある
「この作業を止めて」	人からの停止要求に従って終了

これらはルールを説明する例で、今回モデルで実演したのは最初のファイル作成だけです。

元の議論とチケットのつながりが保存されているため、追加メッセージがそのWorkerへ直接届く場合があります。通常の完了後でも、条件を満たせば同じチケットを再開できます。Workerが範囲外と判断した依頼はRouterへ返され、改めて振り分けられます。人が明示的に停止したチケットは、後のメッセージだけで自動再開しません。追加メッセージと権限のルール

同じチャット内の依頼でも、同じ仕事とは限りません。新しい仕事がいったん既存Workerに届き、その後Routerへ戻ることもあります。

実装上も会話IDは worker-チケットID で決まります。まず既存の会話を探し、見つからない場合に新しく作成します。会話の作成処理、チケットと会話の対応

継続して育てる専門Botとの違い

フロントエンド担当、調査担当、文章担当などを長く使い続け、仕事が来たら得意なBotへ任せる構成もあります。

公開版Superagentが主に管理するのは、チケットとメッセージの関係です。以前ファイル作成を担当した会話が、似た依頼をしたという理由だけで「ファイルの専門家」として自動選択されるわけではありません。

Routerの主な操作は、新規受付、既存チケットへの追加、停止、無視の4つです。既存チケットへの追加には明確な関連が必要で、話題が似ているだけでは足りません。振り分けの指示

Grok Botは、継続して存在するBotを中心にした製品です。各Botがルール、好み、作業の記憶を持ち、Bot同士で仕事を引き継げます。ただし、引き継ぎ機能があることと、常に最適な専門家を自動選択できることは別です。Botの記憶、Bot同士の引き継ぎ

比較する点	公開版Superagent	Grok Bot
中心となる単位	チケットと実行用の会話	継続して存在するBot
引き継ぐ情報	チケットの経緯、ファイル、作業記録	Botのルール、好み、作業の記憶
次の仕事への対応	元のチケットを続けるか、新規作成	既存Botへ依頼するか、別のBotへ引き継ぐ

参考資料

• 公式README：プロジェクトの位置づけ。
• 実行モデル：Workerの実行と会話。
• Routerの指示：新規受付と既存作業への振り分け。