DeepSeek Super-agentの設定：RouterとWorkerの仕組み

DeepSeek Super-agentは、1つのリポジトリ、許可した依頼者1人、専用のOSアカウントから試してください。Routerが許可された依頼をTicketに変え、Workerがそれぞれ別のセッションとディレクトリで作業します。最初はobserveを有効にしますが、明示的な依頼はこのモードでも実行されます。

2026-11-09時点で、dsh-superagent-prototypeは研究用コードです。DeepSeekの公式製品でも、本番運用の準備が整ったサービスでもありません。パッケージのマニフェストには、バージョン0.1.0とMITライセンスが記載されています。公開版は、チームの内部システムや設計記事で説明された実装とも異なります。

Router、Ticket、Workerの役割

主な違いは、リポジトリに届く依頼を継続的に受け付け、実行する作業を振り分ける点です。新しいモデルや、別のコーディング画面を提供する仕組みではありません。この拡張パッケージはDeepSeek Harness内で動作し、1つのGitHubリポジトリを監視します。任意でFeishuのメッセージも受け取れます。

ドメインモデルでは、受信したイベントと実行を許可された作業を区別します。Evalという評価機構が、作業候補を新しいTicketにするか判断します。受け付けた各Ticketには、作業を許可する根拠と範囲を記したMandateが付きます。何を根拠に、どこまで作業してよいかをTicketに持たせる仕組みです。

Routerは、依頼の振り分けを判断するメインのエージェントセッションです。Workerは、受け付けた作業を実行します。設定画面では、この実行担当のWorkerをExecutorという名前で表示します。

各Workerは、ほかのWorkerとは別のエージェントセッションを持ち、自分用の作業ディレクトリで処理を進めます。作業の結果は、依頼があった元の会話へ返されます。たとえば、作成したプルリクエストへのリンクをGitHubコメントで返す形です。ディレクトリを分けると作業コピーは分離できますが、プロセスが読めるファイルは制限されません。

たとえば、無関係な2件の不具合報告を、同じコーディング会話ではなく別々のTicketとして扱えます。個別の作業を始めるよりも、届く依頼の整理や調整に注意を取られるチームに向いています。

対話しながら1件の変更を進めるだけなら、現在のコーディングエージェントを使い続けてください。範囲を絞って作業を任せるなら、モデルを明示指定する読み取り専用のClaude Codeサブエージェントから始める方法があります。

observeが安全な隔離環境ではない理由

observeが制限するのは、文脈から推定した作業です。すべての実行を止めるわけではありません。認可ルールでは、明示的な依頼はどの受け付けモードでも許可されます。

observeでは、推定した作業候補を肯定的に評価しても、「would accept」という記録だけを残し、そこから作業を作成しません。autoでは、その評価によって推定した作業を受け付ける場合があります。許可された人がエージェントにメンションすれば、どのモードでも依頼できます。

誰から新しい作業を受け付けるかは、許可リストだけで決まるわけではありません。受け付け設定表のセルによっては、リスト外の人にも明示的な依頼を認められます。observeだけに頼らず、後述の手順で依頼者を1人に限定してください。

danger-full-accessの意味

エージェントの認証情報だけを持つOSアカウントを使ってください。導入ガイドの隔離に関する警告は、dsh-superagent-routerとdsh-superagent-workerの両方に適用されます。どちらも実行者のOSユーザーとして、danger-full-accessで動作します。

認証用ラッパーは、利用するアカウントの認証情報を選ぶための仕組みです。実行中のプロセスを、OS上の別の保護領域に隔離するものではありません。Workerは絶対パスでプログラムを実行でき、実行者のホームディレクトリも読めます。実装ガイドでは、Routerにもシェルとファイル読み取りのツールが与えられています。

初回の試験には、使い捨てにできるマシンか仮想マシンを用意し、管理者権限のないエージェント用アカウントを使ってください。個人の認証情報、本番環境のシークレット、無関係なリポジトリを置かないでください。これは導入時に取る対策であり、プロトタイプが備える保護機能ではありません。

Harnessのプロファイルも分けます。このプラグインは、プロセス全体のPATHとgit設定を変更します。パネルの待ち受けは127.0.0.1のままにし、試験用サービスを公開しないでください。

GitHubだけで試験運用を始める

新しいアカウントとプロファイルで、以下の手動設定を進めます。リポジトリには、エージェントと一緒に設定するためのSETUP.mdも用意されています。

前提条件を確認する

Node.js 22.19+または24+、pnpm、git 2.32+、Python 3.8+、tmux、GitHub CLI 2.48+をインストールします。これらが文書化された前提条件です。

github.com上のリポジトリと、DeepSeek Harness用のモデルプロバイダーも必要です。GitHub Enterprise Serverには対応していません。対象リポジトリがGit LFSを使う場合は、git-lfsをインストールします。

試験には、ファイルがすでに置かれている空ではないリポジトリを使います。後の読み取り確認で使うREADME.mdも含めてください。初回は、自分とエージェントだけがアクセスする非公開リポジトリを推奨します。

Feishuは任意で、この試験では使いません。接続する場合は、ボットを有効にしたFeishuまたはLarkアプリとlark-cliが追加で必要です。プロジェクトが動作確認に使ったバージョンは1.0.90です。

エージェント専用アカウントでログインする

専用のGitHubユーザーアカウントを作り、試験用リポジトリへの書き込み権限を与えます。専用OSアカウントのBashで、次のコマンドを実行してください。

unset GH_TOKEN GITHUB_TOKEN
gh auth login --hostname github.com --git-protocol https
gh api user --jq .login
gh auth setup-git --hostname github.com

エージェントのアカウントでGitHub CLIの対話式ログインを完了します。gh apiには、そのアカウントのログイン名が表示される必要があります。2つの変数を解除するのは、保存済みのログインより環境変数の認証情報が優先されることを防ぐためです。

別途実行するgh auth setup-gitは、GitHub CLIをGitの認証情報ヘルパーとして設定します。Gitが接続に必要な認証情報を取得するときに、GitHub CLIを使うための設定です。準備処理とブランチの送信ではGitを直接使うため、この設定が必要です。

GitHub CLIのクローン構文に従って、ローカルにクローンを作成します。

read -r -p "Repository (owner/name): " TARGET_REPOSITORY
mkdir -p "$HOME/src"
gh repo clone "$TARGET_REPOSITORY" "$HOME/src/superagent-target"

続いて、gh apiとは別にHTTPSでのアクセスを確認します。

GIT_TERMINAL_PROMPT=0 git ls-remote \
  "https://github.com/$TARGET_REPOSITORY.git" HEAD

GIT_TERMINAL_PROMPT=0 git -C "$HOME/src/superagent-target" push --dry-run \
  "https://github.com/$TARGET_REPOSITORY.git" \
  HEAD:refs/heads/agent-auth-check

git ls-remoteは、リモートのHEADを返す必要があります。公開リポジトリでは、認証なしでもこの読み取りに成功する場合があります。push --dry-runによる確認では、リモートの参照を更新せず、送信の接続を試します。

読み取り確認と送信確認の両方が、認証エラーなどを出さずに正常終了することを確認してください。ただし、最終的な成果物の受け渡しは、後のPR作成時にブランチを実際に送信して検証します。

この例では、エージェントだけが使うOSアカウントを前提にしています。そのため、個人用アカウントとの切り替えを挟まずにghを直接呼び出しています。複数のGitHubアカウントでログインしている個人用設定を流用しないでください。

Harness専用プロファイルを作成する

導入ガイドで指定されたHarness 0.2.1-rc.3を使います。拡張パッケージのマニフェストでは、engines.dshに^0.2.1-alpha.2を要求しています。

最初のdshコマンドより前にDSH_HOMEを設定します。このバージョンのCLIリファレンスでは、名前付きプロファイルを$DSH_HOME/profiles/<name>に配置します。この試験では、保存先として$HOME/.dshを明示的に選びます。

以下のBashコマンドは、新規インストールだけに使ってください。

export DSH_HOME="$HOME/.dsh"

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
pnpm install
pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

既存環境でプロファイル作成コマンドを再実行しないでください。 プロファイルを置き換え、そのcordis.patch.ymlを削除します。更新する場合は、導入ガイドのアップグレード手順に従ってください。

マシンの設定を書き込む前に、プロファイルのマニフェストが存在するか確認します。同じBashシェルで続けます。

test -f "$DSH_HOME/profiles/superagent/package.json" || exit 1

cat > "$DSH_HOME/profiles/superagent/cordis.patch.yml" <<EOF
- id: webserver
  config:
    host: 127.0.0.1
    port: 3082
- id: dsh-superagent
  config:
    stateDir: "$DSH_HOME/state/superagent"
EOF

if tmux list-sessions >/dev/null 2>&1; then
  tmux set-environment -g DSH_HOME "$DSH_HOME"
  if tmux has-session -t '=dsh-superagent' 2>/dev/null; then
    tmux set-environment -t '=dsh-superagent' DSH_HOME "$DSH_HOME"
  fi
fi

scripts/dsh-superagent start
scripts/dsh-superagent status

サービススクリプトは、tmuxを通してdsh --profile superagentを起動します。新しいtmuxサーバーは、エクスポート済みの環境変数を引き継ぎます。このコードは、既存のサーバーやセッションのtmux環境も更新します。

サーバーマシン上のブラウザーでhttp://127.0.0.1:3082を開きます。HarnessのSettingsで、設定ファイルを開く操作であるOpen configuration fileを選びます。開いたファイルが、上記のsuperagent/cordis.patch.ymlと同じ場所にあることを確認してください。別の場所を指している場合は、作業を止めます。プロバイダー設定を追加した後は、このパッチを上書きしないでください。

サイドバーでSuperagentを選びます。リポジトリとエージェントのアカウント情報をまだ設定していない段階では、初期設定が未完了という警告が表示される想定です。依頼の受け付けを設定する前に、後述のモデル選択を完了してください。

依頼の受け付けとTicketごとの作業ツリーを設定する

Superagent → Settingsを開き、文書化された設定グループを使います。

Sources → GitHubで、リポジトリを自分のowner/nameに、エージェントのCLIをghに設定します。Issues、プルリクエスト、コメント、デフォルトブランチのCIをすべて受信するスイッチはオフにします。Feishuも無効のままにしてください。

Eval → On each Source → GitHubのGitHub accounts that may originate workには、自分の個人用ログイン名だけを残します。ほかの登録を削除し、ボットのリストも空にします。リスト外の人に関する表示中の受け付けセルは、直接エージェントに話しかける場合も含め、すべてignoreにします。受け付けモードをobserveにして保存します。

リスト外の人に対する初期値は、受け付けマトリクスに定義されています。これらは新しい作業依頼を制限します。ただし、購読中の議論に届いたメッセージが、既存のTicketへ文脈情報として渡ることまでは防ぎません。試験中の会話は、自分とエージェントだけに限定してください。

Executionでは、試験用の同時実行数を1にします。Worker用ディレクトリを配置するルートの設定は、画面に表示されている初期値から変更しないでください。次のコードを準備コマンドの欄へ貼り付けてください。実行に使われるのはshで、構文はBashでも有効です。

git -C "$HOME/src/superagent-target" fetch --no-tags \
  "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C "$HOME/src/superagent-target" worktree add \
  -b "agent/$DSH_SUPERAGENT_NAME" \
  "$DSH_SUPERAGENT_DIR" \
  "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

この準備コマンドは、導入ガイドの作業ツリー作成例で使うパスを、先ほど作成したローカルクローンの場所に合わせたものです。対象のコミットを取得し、Ticketのブランチと作業コピーを作成します。準備コマンドがなければ、Workerは空のディレクトリから作業を始めます。

Promptsでは、コミット作者の識別情報と、エージェントが関与したことを示す文面を設定します。マージは人が行うものとし、別のマージ用アカウントは渡さないでください。プロンプトの指示は行動のガイドであり、リポジトリ側で強制される保護ではありません。

別のモデルを使うには

DeepSeek Harnessに設定したプロバイダーを通して、別のモデルを使えます。タグdsh-v0.2.1-rc.3のプロバイダーガイドに、インストールしたバージョンでの手順が記載されています。

HarnessのSettings → Modelsを開きます。DeepSeekのカードでAPIキーを入力して保存するか、Add model providerから別の対応プロバイダーを追加します。認証情報はローカルのこの画面で入力し、GitHubの議論には書かないでください。

Custom model APIでは、小文字のProvider ID、ベースURL、対応するAPIプロトコル、認証情報、1つ以上のモデルを指定します。値はプロバイダーの文書に従ってください。プロバイダーの設定を保存できたことと、そのモデルが作業に必要なツール呼び出しを実行できることは別です。モデル選択後の読み取り確認まで進めて、動作を確かめます。

次に、このバージョンのWeb UIガイドに従い、Choose workspaceで$HOME/src/superagent-targetを追加して選びます。通常のセッションを開始し、モデル選択欄で設定済みのモデルを選びます。この選択が、新しいセッションのデフォルトになります。

最初のモデル選択を終えたら、もう1つ新しいセッションを開きます。依頼を送る前に、先ほど選んだものと同じプロバイダー名とモデル名が表示されているか確認してください。README.mdを読み、編集せずに最初の見出しを返すよう依頼してください。返答をファイルと照合します。この確認には、管理用のdsh-superagent-*プリセットをどちらも使わないでください。

その後、確認したプロバイダーとモデルをSuperagent → Settings → EvalとExecutionで明示的に選択します。EvalはRouterと評価処理のモデル、ExecutionはWorkerのモデルを指定します。この試験では、未確認のデフォルト設定に頼りません。選択欄を空のままにしてよいのは、プロファイルのデフォルトモデルを確認した後だけです。

Executorのモデル選択は、セッション作成時に適用されます。既存のWorkerセッションは元のモデルを使い続け、Retryも同じセッションを再利用します。後からモデルを変えた場合は、新しいTicketで確認してください。

1件の依頼で動作確認し、失敗箇所を調べる

コード変更を依頼する前に、GitHubでの依頼から返答までを確認します。パネルの画面が開くだけでは、依頼者の認可、作業ディレクトリの準備、モデルへの呼び出しまで正しく動くとは判断できません。

まずscripts/dsh-superagent statusを再実行します。終了コードが0で、設定の問題がないことを確認してください。許可した個人用アカウントから、Issueに新しいコメントを投稿します。@AGENT_LOGINはエージェントのログイン名に置き換えます。

@AGENT_LOGIN Read README.md and reply here with its first heading.
Do not edit files, push a branch, or open a pull request.

導入ガイドの試験手順では、作成されたTicketをOverviewで確認します。元のGitHubの会話に、正しい見出しを含む返答が届くことを確かめてください。

確認できたら、小さな文書変更と、人がレビューするためのプルリクエスト作成を依頼します。ブランチが実際に送信されたか、PRがエージェントのアカウントによるものか、差分が依頼の範囲内かを確認します。これは導入環境の受け入れ確認であり、モデルの成果を保証するものではありません。

Ticketが見つからなければ、許可したログイン名、受け付け設定、リポジトリ、GitHubソースの稼働状態を確認します。その後、エージェントにメンションする新しいコメントを投稿してください。

サービススクリプトは、プロセスや実行環境の問題で1、構成要素のエラーで2、設定未完了で3を返します。1では再起動が役立つ場合があります。2や3では、表示された原因を解消してください。

一時的なモデルやネットワークの障害には、実行ガイドで、待ち時間を延ばしながら3回再試行すると定めています。HTTP 408、429、5xxも対象です。準備コマンドの失敗は、この自動再試行に含まれません。

準備コマンドが失敗した場合の復旧

Retryを選ぶ前に、記録された準備エラーとTicketのディレクトリを調べます。起動処理の実装は、そのディレクトリが存在しない場合だけ準備を実行します。作業が途中でも、既存のディレクトリは準備済みと見なされます。

ディレクトリがなければ、認証情報または準備コマンドの問題を修正してからRetryを選びます。新しい起動処理で、準備をもう一度試みます。

ディレクトリがある場合は、Ticketの詳細からパスをコピーし、Bashで確認します。

read -r -p "Ticket directory (absolute path): " TICKET_DIR
git -C "$TICKET_DIR" rev-parse --show-toplevel
git -C "$TICKET_DIR" status --short --branch

表示された作業ツリーのルートは、親の作業コピーではなくTicketのディレクトリである必要があります。ブランチと作業ツリーの状態、必要なファイル、前に失敗した準備の各工程を確認してください。

既存のディレクトリをそのまま使って再試行する場合は、必要な準備を自分で完了させ、その結果を確認してから操作してください。Retryはディレクトリを作り直しません。不完全な作業コピーを安全に復元できなければ、それを保存したままTicketを停止し、準備コマンドを修正します。そのうえで、新しいIssueから依頼を送ってください。続行前に、代わりのTicketが新しいディレクトリを使っているか確認します。

Ticketが失敗状態になると、CIやボットのメッセージではWorkerは再開しません。人による対応が必要です。試験が終わったらサービスを停止します。

scripts/dsh-superagent stop

継続運用を判断する基準

依頼の振り分けと提出された変更に、運用の手間を上回る価値がある場合だけ、プロトタイプを稼働し続けてください。最初は対象を絞ります。実際に役に立った成果がどれだけ得られ、モデルプロバイダーの利用量がどれだけ発生したかを測定してから、同時実行数を増やします。

モデルの単価だけでなく、受け入れた変更1件あたりのコストを比べます。依頼の振り分け、評価、Workerの呼び出し、障害からの復旧も試験予算に含めてください。コーディングエージェントのタスク別コスト解説では、モデルとその実行基盤を組み合わせて比較する考え方を説明しています。

内部デモを、この公開コードの動作と同一視しないでください。リポジトリは、設計記事の一部がまだ実装されていないと警告しています。自分の受け入れ確認で利用範囲を広げられると判断するまでは、人によるレビューと環境の隔離を続けてください。