DeepSeek Harness がオープンソースに：すべてはプラグイン
DeepSeek V4 Pro の正式リリースから半日後、DeepSeek Harness（開発者プレビュー版）もオープンソースになりました。
リポジトリ構成を見た最初の感想は、これは「もう一つの Codex」ではなく、ブレッドボードだ、というものです。
230 を超える workspace メンバー。ファイルシステム、ターミナル、サブプロセス、PTY、言語サーバー、Web アクセス、スキル、サブエージェント、ワークフロー、プランモード、セッション永続化、設定、認証情報、テレメトリ —— ほぼすべての機能が独自のパッケージを持っています。
一般的な Agent プロジェクトが「組み立て済みのパソコン」だとすれば、Harness は巨大なブレッドボードです。モデル、ツール、UI、ストレージ、セキュリティポリシー、コンテキスト管理 —— どれも挿せるし、抜ける。
私たち自身が Agent オーケストレーションとモデルゲートウェイを作っているので、このリポジトリは非常に実利的な目線で読みました。どの設計を明日そのまま真似すべきか。 以下がその答えです。
Harness という命名は正確だ
見落とされやすい点から。なぜ「Harness」なのか。
この語の元の意味は馬具、ワイヤーハーネス、拘束装置です。抽象化すると、力を仕事のできる機構につなぎつつ、その力を暴走させない、ということ。
AI に当てはめれば、Harness はモデルをファイルシステム、シェル、コードエディタ、Web、他の Agent につなぎ、同時に「何をしたか」を記録し、「何ができるか」を制限し、失敗時にはリトライ・キャンセル・コンテキスト圧縮・ユーザーへの差し戻しを判断します。
この命名自体が一つの判断です。モデルは馬であって、車ではない。 必要なのは速く走らせることではなく、引いているものが本当に目的地に着くことです。
コード量が大きい理由もここにあります。「ツール呼び出しは並列可能か」「キャンセルは本当にサブプロセスを止めるか」「ツール結果がコンテキストを汚染しないか」—— この三つだけで、相当数のパッケージが必要になります。
すべてはプラグイン、Agent Loop さえも
プロジェクトは Cordis マイクロカーネル上に構築され、動作中の Harness は本質的に一つの Cordis Context です。各パッケージがサービス・イベント・機能を登録し、設定ファイルがそれらを組み合わせて動く Agent にします。
packages/core/ が中核で、Session、System Prompt、Tools、Agent、Agent Loop を含みます。その外側に大量の機能パッケージ：llm/ はモデルアダプタとストリーミング、shell/・subprocess/・terminal/ はそれぞれ単発コマンド・プロセスツリー・永続ターミナル、fs/ はファイル入出力とポリシー制限、lsp/ は言語サーバー接続でテキスト検索ではなく意味レベルのコードナビゲーションを与え、web/ は検索と取得、skill/ は再利用可能なスキル、subagent/ と workflow/ は単一 Agent を委譲・編成可能なマルチエージェントへ拡張します。
しかし本当に手が止まったのは、三層分割です：インターフェース、実装、コンシューマー。
Bash を例に取ると、インターフェースは「コマンドを実行する」とは何かを定義し、ローカル実装が実際にプロセスを生成し、モデル向けツールパッケージがその機能をモデルが理解できる schema と結果に変換します。
将来ローカルシェルをリモートコンテナ、クラウドサンドボックス、企業実行基盤に置き換える場合、理論上は実装層だけを差し替えればよく、モデルツールや Agent Loop を書き直す必要はありません。
これは私たちに直結します。ゲートウェイ運用で最も痛いのは「上流を差し替える」たびに業務コードに手が入ることでした。この分け方が言っているのは、機能の定義・機能の実装・機能のモデルへの提示は三つの別の仕事であり、一箇所に書いてはいけない、ということです。
一つの設定ファイルが、まったく違うプロダクトを組み立てる
プラグイン化は最終的に cordis.yml に落ちます。プラグイン名、安定 ID、パラメータを列挙し、今の Agent がどの機能群を持つかを決めます。
同じコードベースがまったく違う形態になります。LLM アダプタ、ファイルシステム、Bash、TUI を入れればターミナル上のコーディング Agent。UI を Web プラグインに替えればブラウザアプリ。Headless エントリなら、タスクを受け取り、モデルとツールのターンを完了し、答えを出力して終了。ACP や JSON-RPC のフロントドアを付ければ、他のプログラムから駆動できる自動化サービスになります。
設定はオーバーレイ層もサポートし、TUI と Web UI は共通のベース設定を共有して各自の UI プラグインを重ね、個人設定が最後の層に来ます。
ただし記録しておくべき落とし穴があります：設定パッチは対象プラグインの config 全体を置き換えます。ディープマージではありません。 新しいフィールドを一つ書いただけで、既存の API キーやベース URL が一緒に消える可能性があります。挙動としては明確ですが、初見のユーザーの直感には確実に反します。おそらくコミュニティで最も頻出する種類の issue になるでしょう。
Agent Loop はループではなく、交通ルールだ
初期の Agent プロジェクトの中核は数行に要約できます。メッセージをモデルに送り、ツール呼び出しが返れば実行し、結果を返し、テキストが出るまで繰り返す。
Harness も同じことをしますが、これを厳密なライフサイクルに分解しています。
ユーザー入力が一つの Turn を開き、Turn は複数の Step を含み、Step は一回のモデルリクエストとそれに続くツール実行に対応します。リクエスト前にシステムプロンプト、実行環境、ツール schema、セッションメッセージを組み立て、リクエスト後はストリーミング chunk、完全なメッセージ、ツール呼び出し、ツール結果、終了理由がすべてイベントストリームに入ります。
ツールも「関数名を得たら呼ぶ」ではありません。事前ポリシー、不可逆のセーフティガード、実行、事後処理、内容整理、結果通知を通ります。ツールは特定のパラメータ下での呼び出しが並行安全であると宣言でき、スケジューラは連続する読み取り専用タスクを並列化します。状態を変更する、あるいは安全性を確定できない呼び出しはバリアとして扱われ、先行タスクの完了後に排他実行されます。
原文にある比喩が気に入っています。これは田舎道に航空管制システムを設置するように見える、と。しかし Agent が同時に十個のファイルを検索し、テストを走らせ、さらにユーザーの追加指示といつでものキャンセルを受け付ける段階になると、これらのルールは「過剰設計」から「事故報告書で最も早く欲しかったもの」へ、あっという間に変わります。
私は完全に同意します。私たちがはまった穴は、ほぼすべてこの層にあります。 Agent の作業中にユーザーが何か打ち込んだ —— それは次のタスクなのか、現在の作業への方向転換なのか。Harness はキュー投入メッセージ、コンテキスト注入、Steering を区別し、ある転換指示が実際にどのモデルリクエストに入ったかを受領確認で保証します。
「メッセージが届いた」だけでなく、「モデルがどのステップでそれを見たか」まで気にしている。 Agent を作ったことがある人なら、この違いはすぐ分かるはずです。
セッションログは権威ある情報源であり、チャット履歴ではない
私が最も真似したい設計はこれです。
規定はこうです：モデルが見たものは、すべてログから再構築できなければならない。
ユーザーメッセージ、実行環境コンテキスト、モデルリクエスト情報、ストリーミング出力、ツール呼び出しと結果、圧縮イベント、権限切り替え、キャンセル理由 —— すべてがイベントとして追記型セッションストリームに入ります。UI、永続化、復元、Fork、テレメトリ、リプレイは、それぞれが「だいたい正しい」状態を持つのではなく、同一のイベントソースから派生します。
これは Agent システムで最も厄介な問題に答えています：タスクが失敗したとき、私たちはモデルがその時何を見ていたかを本当に知ることができるのか。
最終的なチャットテキストだけを保存していると、重要な要因が失われます。リクエスト直前にワークスペースの状態が注入されたかもしれない。ツール結果が切り詰められたかもしれない。モデルルーティングが自動で切り替わったかもしれない。ユーザーがストリーミング途中で方向を変えたかもしれない。
これはゲートウェイを作る立場では極めて重要です。以前公開した検証で、リクエストには kimi-k3 と書いたのに、レスポンスの自己申告は kimi-k2.7-code でした。答えは合っていたが、身元が違った。現場を再構築できるログがなければ、この種の問題は発見すらできず、事後の追及もできません。
セッション永続化自体もプラグインで、JSONL と SQLite 等のバックエンドを提供します。Resume は元のセッションを継続し、Fork は確定した履歴境界から新しいセッションを派生させます。
四つのプリセットは「すべてはプラグイン」の最も分かりやすい製品化
Web UI は四つの Agent プリセットを提供します。これらは独立した四つの Agent ではなく、プロンプトの文体を変えただけでもなく、同一の Harness ホスト上で、そのセッションに異なるツール・プロンプト・ランタイム機能を装填したものです。
標準モードは最も機能が揃っており、ファイル編集、シェル、検索、Skills、プラン、ゴール、サブ Agent、ワークフローを備えます。
PTC モードは全機能を保ちつつ、Code Mode SDK 経由でツールをモデルに提示します。モデルは TypeScript を書き、一回の run_code で複数ステップを組み合わせられるため、往復の多い長い呼び出し連鎖に向きます。
ミニマルモードは永続 Bash と str_replace_editor の二つだけ。ツール集合が小さいほど選択とコンテキストの負担が減り、道筋が明確なタスクに向きます。
クリエイティブモードは標準モードにランタイム検査、一時プラグイン実験、preset 作成ガイドを加えます。
最も情報量が多いのは実はミニマルモードだと思います。これは逆説的に一つのことを証明しています：ツールは多ければ良いのではなく、ツールが多いこと自体がコンテキストの負担である。 私たちは Agent にツールを渡すとき「多めに渡しておけば損はない」と考えがちですが、ここでは「少なく渡す」が公式プリセットとして提供されています。
セキュリティは確認ダイアログではなく、システム制約である
コーディング Agent がファイルシステムとシェルの権限を得た瞬間、コードの改変、依存のインストール、プロセスの起動、さらにワークスペース外のホスト環境への接触まで可能になります。
Harness はこれを UI に確認ダイアログを足して済ませるのではなく、基盤アーキテクチャの問題として扱っています。
デフォルトは workspace-write モードで、コマンド実行とファイル変更を現在のワークスペースと許可された一時ディレクトリに限定し、権限拡大が必要な操作は ask 承認ポリシーで処理します。より緩い danger-full-access も存在しますが、デプロイ側が明示的に選ぶ必要があり、無害そうな互換オプションとして包装されていません。
特にプロフェッショナルだと感じた点が三つあります。
ガードに拒否された操作は、後続のプラグインが再び許可することはできない。 「迂回する」経路を塞いでいます。
ファイルシステム、Bash、サブプロセスが同一のサンドボックスポリシーを共有する。 「コマンドは制限されているが、ファイルツールなら回り込める」という分断された境界を避けます —— これはまさに先日の OpenAI–Hugging Face 事故の形でした。モデル自体は外部ネットワークを持たないのに、呼び出せるパッケージ管理サービスは持っていた、というものです。
フェイルクローズ原則を採用している。 隔離機構が本当に有効か確認できない場合、無防備な実行に静かに退化するのではなく、実行を拒否します。
最後の一つは強調したい。多くのシステムは不確実なときに「とりあえず動かす」を選びますが、ここは「止まる」を選びました。 Agent が実際にあなたのマシンを操作できるという前提の下では、このデフォルト値の選択こそが、どんなセキュリティ機能一覧よりもチームの判断力を物語ります。
私が持ち帰った三つ
一つ目は SDK と完成品の関係について。 Web UI だけを見ると、Harness は DeepSeek 版の Codex に見えます。しかしリポジトリの重心は、置き換え可能な機能インターフェース、イベント駆動のライフサイクル、権威あるセッションログ、宣言的な組み合わせにあります —— 完成した Agent は、この SDK の最初の顧客に過ぎません。 これは根本的に異なるプロダクト思想であり、天井の高さを決めます。
二つ目はモデルと Harness の分業について。 モデルは知能の上限を決め、Harness はその知能がどう実環境に入り、どうツールを使い、どう状態を保ち、どう権限境界の中で働くかを決めます。企業開発者にとって、後者はチャット画面にボタンが数個増えることより重要です。監査・拡張・置換・長期保守が可能かを決めるからです。
三つ目、最も深く考える価値があるのは、これが当たり前だと思っていた三つの概念を定義し直していることです。 Agent は肥大化し続けるループではなく、組み合わせ・観察・置換が可能な機能の集合であるべき。セッションはチャット記録ではなく、実行の事実であるべき。ツールは関数ではなく、ポリシー・ログ・提示プロトコルを同時に持つべき。
この三文は、私たち自身の Agent オーケストレーション設計ドキュメントの冒頭に貼るつもりです。過去に書いたものは、この三点すべてで逆だったからです —— ループはどんどん長くなり、ログはチャットしか保存せず、ツールはただの関数でした。
つまり Harness で注目すべきなのは、今日あなたが使っているコーディングアシスタントを置き換えられるかどうかではなく、「Agent をどう作るか」をコードを書くことからブロックを組むことへ変えたという点です。
出典：机器之心『刚刚，DeepSeek Harness震撼开源：一切皆插件』。リポジトリ github.com/deepseek-ai/deepseek-harness、Cordis 設計論文 github.com/cordiverse/paper。技術的詳細は原文および公式リポジトリに基づきます。実測結果は机器之心のプレビュー検証によるもので、当方の実測ではありません。