DeepSeekが、GitHubのリポジトリを一つ担当し、依頼された作業を実行して結果を元の会話に返すコーディングエージェントのプロトタイプを公開した。初期の機能を試すための試作品だ。チームは、依頼者を定めた許可リストとルールで誰が作業を依頼できるかを決め、どのメッセージからエージェントが先に検討するかを設定できる。

1. 一つのリポジトリで働き、Webパネルで人に対応を求める

dsh-superagentは、エージェントの実行基盤であるDeepSeek Harness向けのパッケージだ。GitHubから依頼を受け、必要に応じてコラボレーションツールのFeishuも接続する。作業ごとに独立した会話セッションとフォルダーを用意して進め、コード変更のレビューを依頼するプルリクエストなどで結果を返す。Webパネルには、人が回答やレビューをすべき項目が集まる。

インストールは、コーディングエージェントにリポジトリのSETUP.mdを読んで一緒に設定してほしいと依頼する方式だ。エージェントが一つずつ質問し、全体の計画を示した後、インストールと構成を進める。チームは依頼を受け付ける対象と作業を開始するルールを決めて運用できる。

2. 許可リストとルールが作業開始を制御する

作業を開始する権限と許可範囲は、エージェントの実行システムが管理する許可リスト、ルール、作業別の権限記録で決まる。コメントは業務資料、許可リストは入場者名簿に相当する。許可された人がエージェントを指名すると、明示的な依頼になる。リスト外の人による指名依頼も、会話のスコープごとの設定で明示的に許可できる。それ以外の人や登録済みボットのメッセージは、設定に応じて検討候補になるか無視される。

開始済みの作業の会話は、別の経路で作業担当エージェントに渡される場合がある。この受け渡しは文脈を補うが、権限を増やすものではない。担当エージェントは任された範囲で処理するか、範囲外の依頼を差し戻す。ボットや自動チェックの結果は既存の作業に文脈として渡される場合があるが、終了した作業を再開させることはない。

3. 自動開始は評価モードとチームのルールで調整する

ルールに基づく自律的な作業は、基本的に観察から始まる。デフォルトのモードでは検討候補の評価結果を記録するが、作業を自動では開始しない。チームは記録を確認した後、自動モードに切り替えられる。明示的に許可された依頼は、どのモードでも処理される。

自動モードで候補を承認するには、有効なルールをそれぞれ評価し、一つ以上に合致する必要がある。ルールは開始の可否だけでなく、作業の進め方も定める。例えばレビュールールには、コードのマージ前に必要なレビュアーと承認を盛り込める。無関係な会話など、ルールに該当しないことが明らかな候補は、詳細な評価なしに無視できる。

ポリシーのバージョンには、ルール、自動開始モード、ソース別のポリシーが含まれる。ポリシーが変わると進行中の評価を再び待機させ、影響を受ける作業には変更通知を送る。進行中の作業の権限は、ポリシー変更だけで直ちに取り消されるわけではない。ただし、終了した作業を再開する前には、現在のポリシーに適合するか再確認する。

4. 作業は分離したセッションで進め、条件に応じて再開する

作業ごとに専用のセッションとフォルダーを使い、フォルダーがまだなければ設定済みの準備コマンドを一度実行する。準備コマンドには10分の制限がある。よく使われる設定は、作業フォルダーを別に作るGitの機能であるgit worktreeを利用し、チェックアウトを作成する方式だ。準備コマンドがなければ空のフォルダーから始める。

内部は、依頼を受けてポリシーと評価を経由し、作業の実行につなぐ構造だ。以下は原文の構成図の先頭10行をそのまま抜粋したものだ。

flowchart TB
  plugins[Source plugins] -->|SourceContext| engine
  tools[Session tools] --> engine
  http[Management routes] --> engine
  engine[Engine] -->|Repositories| store[Store]
  engine -->|Policy| policy[Policy]
  engine -->|SourceScope| registry[SourceRegistry]
  engine -->|Assessor| assessor[MasterAssessor]
  engine -->|Executor| executor[DshExecutor]
  assessor -->|decide| engine

人がその作業の会話に追加のメッセージを送ると、終了した作業も継続できる。再開前には、元の会話が引き続き受信対象かを確認し、承認の根拠に応じて現在の許可リストやルールなどを再点検する。再検証に失敗すると権限が取り消され、待機していたメッセージは、別の作業が担当していなければ新たな評価に戻る。

停止の方法も分かれている。会話で人が停止を求めた場合は通常のメッセージと同様に評価を経るが、パネルの停止機能はその作業を直接停止する。人が停止した作業は、新たな承認なしには再開されない。

5. 注意を払う負担は減るが、ポリシー運用の責任が生じる

エージェントが依頼を先に分類し、作業別の空間で処理すれば、人が毎回着手させる負担を軽減できる。その代わり、チームの役割は個別の依頼処理から、許可対象とルールの管理、評価記録の確認へと移る。自動実行せず評価だけを記録する観察モードは、どの依頼を自動で任せてよいかチームが判断する機会を与える。

ただし、作業担当エージェントは運用者のアカウントで承認なしにコマンドを実行する。専用フォルダーやコマンド連携の設定は、セキュリティ上の隔離手段ではない。リポジトリは正式な製品ではなく研究用プロトタイプとして公開された。バグの可能性や内部版との差異を知らせ、導入前の検討と環境ごとの調整を勧めている。

このプロトタイプの導入価値は、自律実行を増やすことよりも、チームが任せる作業の範囲と開始権限を先に設計できる点にある。