DeepSeek Harness 実測：モデル以外がもたらす価値とは

腾讯技術工程 2026-08-15 09:30 広東

DeepSeek-V4-Pro の正式版リリース当日、DeepSeek Harness もオープンソース化されました。

執筆者：osli 元宝 プロダクトマネージャー

関連チーム：元宝プロダクトセンター、元宝モデルエンジニアリングセンター、元宝大規模モデル応用アルゴリズムセンター

DeepSeek-V4-Pro の正式版リリース当日、DeepSeek Harness もオープンソース化されました。以前から DeepSeek Harness の公式アカウント登録を待ち望む声は絶えませんでした。V4 Flash の発表レポートにおけるモデルカードには DSH に関する記述がわずか一行しかなく、外界ではすでに長い間推測が続いており、期待値は最高潮に達していました。

しかし、ソースコードが公開された直後、実際の製品と事前の期待にはわずかなズレがあることに気づきました。多くの人々が待ち望んでいたのは DeepSeek 版 Codex でしたが、今回オープンソース化されたのは、引き続き Agent を構築できるランタイム環境に近いものです。Web コーディングエージェント、Headless モード、Python SDK、ACP、JSON-RPC が用意されています。モデル、ツール、セッション、権限、サンドボックス、Agent Loop、UI など、すべてをモジュールとして分解・再構成可能です。

私はまずオープンソースリポジトリに基づき、ローカル環境で npm、Web、Headless、Python SDK をすべて動作させました。デフォルト設定とセッションログを解析し、同じ Kimi K3 モデルを用いて DSH と Kimi Code を比較検証しました。さらに、V4 Pro に視覚出力を含む複雑なタスクを連続実行させてみました。

一連のテストを終えた後の総評は以下の通りです。現在の DSH は、オープンな Agent プラットフォームの足場（スキャフォールド）といった性格が強く、デフォルト製品にはまだプレビュー版特有の未熟さが見られます。今後はコミュニティによる磨き上げが期待されます。「すべてをプラグイン化する」という理念は非常に新鮮で、Trajectory のソースコード設計も評価が高く、学ぶべき点が多いと感じました。

図 1：プラグツリー、置換可能性、追加型イベントフローに基づいて描かれた概念図。この図は画像生成モデルによって作成されたものであり、実際の製品インターフェースではありません。

DSH は現在、開発者プレビュー段階にあります。本記事に記載されている数値は、単一のローカル実行結果と公開されたユーザーフィードバックに基づくものであり、機能の差異や限界を確認するための目安です。製品間のランキングを示すものではありません。

コミュニティが注目しているのは、主に 2 つのポイントです。

8 月 13 日にリリースされた「DeepSeek Harness」に関する知乎（中国版 Quora）での議論を見ると、ユーザーの反応は大きく 2 つのグループに分かれています。

一方のグループは、完成度の高いコーディングエージェントを待っています。彼らが重視するのは、デスクトップアプリやターミナル体験、Windows 対応状況、キャッシュのヒット率、そして日常のコーディング支援です。また、公式 Harness が V4 Pro や Flash の性能をさらに引き上げるかどうかも注目点となっています。

他方、ベータテスターたちはプラグイン、Preset（プリセット）、Trajectory（軌跡）、そしてランタイム中の自己修正機能に注目しています。彼らが見ているのは、エージェント開発を継続できるプラットフォームです。

どちらも正しく捉えています。DSH はこの 2 つの側面を併せ持っていますが、その完成度には非対称性があります。ランタイムはすでに開放的ですが、デフォルトのプロダクト体験はまだ Claude Code、Codex、Kimi Code といった競合に追いついていません。

最も評価が高いのは「Trajectory」機能です。

段小草氏は Trajectory を、エージェント向けの開発ツール（DevTools）と表現しました。タイムラインや各ラウンドの要求、ログを可視化できるため、コンテキスト圧縮の状況、スキル（機能）の過剰さ、あるいはモデルの誤りを調査する際に非常に役立ちます。

卜寒兮氏も、実行情報パネルの有用性を特に強調しています。キャッシュヒット率や入出力トークン数、トークン生成速度などが直接表示される点は評価されています。

これはソースコードの内容とも一致しています。DSH では、モデルが認識すべき内容が必ずログに記録されることが要件となっており、Trajectory はセッションイベントログから投影されます。独自の監視データを埋め込むのではなく、モデルが実際に受け取ったリクエストに近いリアルな軌跡を表示できるのです。

プラグインの真価は、エージェントの範囲を絞り込む点にあります。

コミュニティ初期には、単なる外観変更や遊び心のあるプラグインも存在しましたが、より注目すべきはドメイン特化型エージェントです。

Kitt 氏が進化共有会で紹介した Data Agent は、読み取り（read）、編集（edit）、書き込み（write）の機能のみを保持し、sqlcmd を使用して bash コマンドを置き換えています。これにより、モデルはデータベースの実行結果を中心に動作し、データ分析に関係ないツールやコンテキストから解放されます。

この事例は、プラグインと Preset の役割分担を明確に示しています。プラグインが新しい能力を提供する一方、Preset は特定のタイプのエージェントが利用可能な能力を決定します。DSH が本格的な生産価値を発揮するのは、「何を削除し」「何を置き換えるか」にかかっています。単にツールを追加し続けるだけではトークンの消費が増え、モデルの選択難易度が上がるだけです。

長時間タスクの実行と、それに見合うコスト管理

Adam Platin 氏は、1 週間分のベータ版を使用して機械学習コンペティションを管理した経験を語っています。Agent はルールを読み込み、スクリプトを実行し、実験を進め、ブラウザを呼び出して最終的に 89 ステップで完了しました。

もう一つの事例では、DSH を微信（WeChat）に接続し、要件の提示から実機での回答受信まで約 87.6 分、費用は約 18 元でした。このプロセスには SDK の調査、ゼロ依存クライアントの構築、モックサーバーの設定、本番環境のエンドポイントテスト、そして QR コードによるバインドが含まれています。

これらはユーザーの主観的な報告であり、ベンチマークとして扱うことはできません。しかし、非常に実用的な尺度を示しています。長時間タスクが完了したかどうかは半分だけの問題で、もう半分は「何分」「何ステップ」「どの程度のトークン数」を要し、「何回人間が介入したか」というコストの問題です。

実行自体は難しくないが、コンテキストの流入経路に課題がある

公式が推奨する最速の導入方法は npx @deepseek-ai/dsh web です。Node.js のバージョンは ^22.19.0 || >=24 が必要です。起動後は API Key を入力し、ワークスペースとエージェント Preset を選択するだけで利用可能です。

ソースコードからのインストールでは、pnpm やビルドプロセス、Git hooks などの設定が必要となるため、プラグイン開発の準備ができている人向けです。

ローカル環境で実際に確認できた 4 つの起動経路は以下の通りです。

• Web UI：ローカルワークスペースとセッションを正常に作成可能
• Headless モード：ワンショットタスクの実行が可能。成功時は最終回答のみを stdout に出力
• Python SDK：バンドルされたランタイムを搭載しており、システム上の Node 依存がない
• --dump-config コマンド：最終的なプラグインツリーを直接表示可能

デフォルト設定でも、構成を直接確認できます。

Web プロファイルでは 129 行のプラグイン設定が生成される一方、Headless モードでは 81 行に抑えられます。初期モデルは DeepSeek V4 Flash で、権限は workspace-write と ask が付与されています。これらのモードの違いは単なる UI の切り替えではなく、読み込まれるプロンプトやツールセットが実際に異なります。

System Prompt はログから復元可能です。

DSH（DeepSeek Shell）では、ランタイム中のリクエストをメモリ内に隠蔽していません。System prompt は、ペルソナ、ツールの説明、そしてプラグイン登録に関するプロンプトセクションを組み合わせて構成されます。リクエスト送信前には、request/header に system、model、temperature、max tokens、tools が記録され、request/context には provider とコンテキストウィンドウが記録されます。

公式の Python SDK で提供される最小限の構成（minimal composition）を見れば、この構造はより明確になります。ここではペルソナを「You are a helpful software engineer assistant.」という固定文に設定し、workspace プロンプト、Skills、コンパクション機能を無効化します。残るのは persistent bash と str_replace_editor のみです。モデルのプレフィックスが凍結されるため、ツール面によるノイズも大幅に減少します。

Trajectory（軌跡）の下には、追記のみ可能なイベントストリームが存在します。

セッションは zstd で圧縮された JSONL 形式で保存され、各レコードには統一された構造体が付与されます。

{"type": "tool/call", "seq": 31, "time": 1786632922876, "data": {}}

ファイル書き込みタスクがローカルで実行された際、61 のイベントが発生しました。これには turn/start、3 つの step/start、ユーザーメッセージ、リクエストヘッダー、推論チャンク（reasoning chunks）、2 回の tool call / result、アシスタントからの応答、そして turn/end が含まれています。モデルはまず書き込みを行い、次に読み取りで確認し、最後に報告を行います。

このように Trajectory を利用することで、以下の 3 つの質問に同時に回答できます。

• モデルがその時点で何を「見て」いたか
• どのステップでどのツールを呼び出したか
• トークン数、キャッシュ状態、終了理由がどのように変化したか

4 文字の単純なタスクでも、最初のレスポンスだけで約 13,000 トークンを消費します。

DSH Headless のデフォルト設定を用いた最小限のテストでは、ユーザーからの指示は「PONG と返信して」のみでした。タスク自体は極めて短くても、初回のリクエストには約 13,467 トークンの入力トークンが含まれていました。

ログをさらに確認すると、この主要なオーバーヘッドの原因は、デフォルトで読み込まれるシステムプロンプト、ツールの説明、リポジトリのルール、そして Skill のサマリーにあることが分かりました。

テスト用ディレクトリは大規模なリポジトリ内部に配置されています。DSH は直近の .git ディレクトリを検出してリポジトリのルートを見つけ、AGENTS.md と CLAUDE.md を注入します。さらに、ユーザーのスキルディレクトリにある 27 件のサマリーもスキャンされます。

ファイル書き込みタスクの後のステップでは、約 13,000 トークンのキャッシュ読み取り（cache-read token）が発生しました。これらの固定されたプレフィックスがキャッシュに保存されることは、それらが実際にモデルへのリクエストに含まれていたことを示しています。

今後はベンチマークや機密性の高いプロジェクトを評価する際、独立した Git ルートを使用し、明示的に DSH_HOME と DSH_AGENTS_HOME を設定するようにします。また、モデル比較を行う際は minimal composition を採用することで、コンテキストをよりクリーンに整理できるようにしています。

図 2：標準、PTC、ミニマル、クリエイティブの 4 つのプリセットは、それぞれ異なるプラグインの組み合わせに対応しています。

標準モードでは、日常の開発タスクを直接処理できるよう、包括的なコーディングツールが提供されます。PTC モードはこの基盤に加え、TypeScript を用いて複数のツール操作を多段階で連携させる機能を追加します。ミニマルモードは bash とテキストエディタのみを残し、クリエイティブモードにはランタイムチェックやプラグインの実験、カスタム Preset の作成に必要な機能が加わります。

同じ「Kimi K3」モデルでも、Harness を切り替えると何が起きるのか？

Kimi Code と DeepSeek Harness はどちらも中国発で MIT オープンソースのコーディングエージェント（または Harness）であり、複数のモデルを接続可能です。しかし、両者の出発点は異なります。

• 比較項目：DeepSeek Harness / Kimi Code CLI
• 公式の位置づけ：再構成可能な Agent runtime / 箱を開けて使えるターミナル型コーディングエージェント
• メインエントリーポイント：Web、Headless、Python SDK、ACP / TUI、-p、ACP、Web
• 拡張方法：Cordis Plugin、Preset、Patch、Skills、Hooks、MCP / Plugins、Skills、Hooks、MCP、Subagents
• Agent Loop の実装：プラグインとして登録され、アーキテクチャ上で置き換え可能 / v2 DI の Agent-scope Service に組み込まれ、ソースコードは公開されているが固定エンジンの一部
• デフォルトモデル：DeepSeek（他社プロバイダーとして pi-ai も利用可能） / Kimi（互換性のあるプロバイダーもサポート）
• デフォルトツール：標準モードで約 25 項目。ファイル操作、Shell、タスク管理、サブエージェント、ワークフロー、Web ブラウジングを含む / Read、Write、Edit、Grep、Glob、Bash、Web、Todo、Task/Subagent など
• 権限設定：read-only / workspace-write / danger-full-access / 通常承認、yolo（全権限）、自動実行
• 可観測性：Session Event、Trajectory、token/cache、プログラマブルな投影 / stream-json、セッションエクスポート、kimi vis
• インストール形態：npm 利用には Node 22.19+ が必要 / 公式の単一ファイル配布では Node が不要（npm 版は Node が必要）

Kimi Code CLI のリポジトリ自体もオープンソースです。両者ともオープンソースですが、違いはランタイムの構成方法にあります。Kimi Code は拡張機能を一つのターミナル製品を中心に囲むように設計されていますが、DSH（DeepSeek Harness）はループ、プロバイダー、セッション、UI をすべて同じプラグイン組み合わせモデルの中に統合しています。

公開されたフィードバックでは、「同じモデルでも Harness を変えれば出力が変わる」という意見が一般的ですが、タスク内容、権限設定、コンテキストの維持状況については必ずしも一致していません。そこで今回は、Kimi K3 の API、プロンプト、ワークスペース、そして隠れた検証基準をすべて固定した上で、両製品がいかに同じタスクを完了させるかを比較します。

• モデルは統一して kimi-k3 を使用
• プロンプト、タスクテンプレート、隠れ検証基準は同一
• 毎回新しい Git ワークスペースと空のスキルディレクトリを使用
• DSH は公式のミニマルツールセットを利用

Kimi Code 使用 0.35.0 の非対話モード

各問題には実行が一度きりであるため、ここでは実行軌跡のみを確認します。

あえて違いを残した箇所があります。DSH は「minimal」構成で、persistent bash と str_replace_editor のみを利用可能です。一方、Kimi Code はデフォルトのツールセットを使用しています。これはどちらがツールが少ないかを比較する意図ではなく、2 つの Harness が同じモデルをどのように異なる実行パスへ誘導するかを観察するための設定です。デフォルト製品としての能力を比較したい場合は、DSH の「standard」構成でもう一度テストを行う必要があります。

出題された 2 つの問題は、「依存関係のバッチ計画」と「セッションイベントの投影」です。各問題には 7 つの公開テストと、8 つのモデルがアクセスできない隠しテストが含まれています。

• タスク：Harness / 合格数 / 所要時間 / 軌跡単位 / ツール呼び出し
• 依存関係の計画：DSH minimal / 15 / 15 / 112.2 秒 / 9 step / 11
• 依存関係の計画：Kimi Code / 15 / 15 / 48.9 秒 / 4 条 assistant メッセージ / 5
• セッションの投影：DSH minimal / 15 / 15 / 111.3 秒 / 7 step / 7
• セッションの投影：Kimi Code / 15 / 15 / 123.1 秒 / 5 条 assistant メッセージ / 6

正答率に差は見られませんでした。両方の Harness で 4 つの軌跡すべてが 15/15 の完全合格を記録しています。第 1 問では Kimi Code が約 1 分早く完了しましたが、第 2 問では DSH が約 12 秒速く、速度において安定した勝者はいませんでした。

しかし、プロセスの違いはより明確です。

Kimi Code は初回実行で README、ソースコード、テストファイルを並列して読み込み、その後ファイル全体を一度に書き換え、最後に Bash で検証を行いました。依存関係の計画にはツール呼び出しが 5 回のみでした。デフォルトのツールセットが豊富であることと、システムプロンプトが「いかに早くコーディングタスクを完了するか」に焦点を当てていることが影響しています。

一方、DSH minimal は persistent bash と str_replace_editor の間を行き来する形が中心です。依存関係の計画には 11 回のツール呼び出しが必要で、ステップはより細かく分割されています。その代わり、モデルの前綴（プレフィックス）やツールの構成、リクエストログを凍結しやすく、セッションログでは完全なリクエスト、ツール、使用量イベントが記録されます。

Kimi Code の stream-json は今回の実行ではトークン使用量を返さなかったため、コスト比較は行いません。DSH については、2 つの問題でそれぞれ入力トークンが 7,593 / 5,082、キャッシュ読み取りトークンが 22,515 / 18,632 を記録しています。

同じ Kimi K3 モデルが最終的に両方の問題をクリアしましたが、そのアプローチは明確に異なります。Kimi Code はすでに調整済みの完成品といった印象です。一方、DSH minimal は前綴の凍結やツール・プロバイダーの差し替えを容易にし、実験の再現性を高めます。

日常のターミナルコーディングが目的であれば、Kimi Code のインストールとデフォルト設定の方が手軽です。しかし、コンテキストの研究、プロバイダーの交換、ドメイン固有エージェントのカスタマイズ、あるいは実験の再現を目指すのであれば、DSH のプラグインツリーとイベントログの方が適しています。

ソースコードレベルでの違いは？

前述の実行軌跡の違いは、ソースコードレベルで 3 つの対応関係として確認できます。

1つ目は「Agent Loop」です。Kimi Code は現在デフォルトで v2 エンジンを採用しており、ループ処理、ツールスケジューリング、コンテキスト管理を DI（依存性注入）サービスとして構成しています。Plan や Swarm などの機能は必要に応じて注入可能です。

一方、DSH では ReactLoopAgent そのものを Cordis プラグインとして登録します。ループとモデルプロバイダー、ツールなどのサービスはすべて同じインストール・アンインストール方式で扱われます。

Kimi Code の重心は「拡張可能なターミナルエージェント」の提供にあり、DSH は開発者による改造範囲をより広く残しています。エージェントがどのようにループ処理を行うかさえも置き換え可能です。

2 つ目のグループは会話履歴です。

Kimi Code v2 は wire.jsonl を通じてエージェント境界でのイベントを保存し、DSH もセッションイベントを用いて状態の復元と画面駆動を行います。DSH にはさらに「モデルが認識する内容は必ずログに記録されていること」というランタイム上の制約が追加されています。これこそが、Trajectory がリクエスト、ツール呼び出し、トークン数の変化を正確に再現できる理由です。

3 つ目のグループはツールと実行環境です。

Kimi Code は Agent Profile でツールの利用範囲を制御し、KAOS を介してローカル環境と SSH 環境を抽象化します。一方 DSH は Preset で使用するツールとプロンプトを決定し、ファイルシステム、サブプロセス、サンドボックスをそれぞれ交換可能なサービスとして分離しています。

両者ともモデルや実行場所の差し替えが可能ですが、DSH は特に「基盤となるこれらのサービスを切り替える際にも、上位層のツールは変更しない」という点を強調しています。

つまり、両プロジェクトにはプラグイン、イベントログ、環境抽象化という共通点がありますが、違いは開放性のレベルにあります。Kimi Code は端末でのコーディング体験を最優先し、DSH はより多くのランタイム部品を開発者に委ねて再構築させます。これが、同じ Kimi K3 モデルが両方の環境で課題をクリアできても、実行ステップやログの形式が明確に異なる理由です。

同一の V4 Pro を用い、2 つの Harness がそれぞれ「ジャンプゲーム」を開発

これまでの小規模なテストではツールの軌跡を確認するにとどまり、Harness が最終的な成果物にどう影響するかを十分に観察できませんでした。今回は deepseek-v4-pro API、プロンプト、および验收基準を固定し、DSH と Kimi Code にそれぞれ独立した作業環境で「ジャンプゲーム」の独自開発を依頼しました。

このタスクは単に Web ページを描画するだけではありません。プレイヤーはマウス、タッチ操作、そしてスペースキーによるチャージで跳躍でき、プラットフォームとの衝突判定、Perfect ボーナス、コンボシステム、失敗とリトライ機能を実装する必要があります。また、ゼロ依存の Node.js バックエンドを備え、ランキング表示、統計機能、JSON 形式での永続化、入力値の検証、パス保護を提供し、決定論的なテスト用インターフェースも用意しなければなりません。VISTA のアプローチを参考に、最終的な验收ではコードテスト、実際のブラウザ上での動作、そして視覚的な表現のすべてを確認します。

まず結果を見てみましょう。Kimi Code はフルスクールの 2.5D ブロック舞台を作成し、DSH は 2D の横スクロールキャンバスに、右側にランキングと操作説明を配置したデザインを採用しました。

図 3：同一モデル・同一プロンプトによる最終ゲーム画面。左側が Kimi Code、右側が DSH の成果で、いずれも実際のブラウザ実行環境から撮影。

Kimi Code 版と DeepSeek Harness 版の両方を直接ブラウザで体験できます。どちらのページもフロントエンド単一ファイル構成のため、ゲーム自体はそのまま動作します。ただしランキングや統計機能を利用するには、別途 Node.js バックエンドを用意する必要があります。

私も実際に数回プレイしましたが、両バージョンとも単に起動するだけでなく、チャージ、着地、連続ジャンプといった基本的な操作感も十分に備わっています。Kimi Code 版は舞台の臨場感が強く、DSH 版は情報表示領域が充実した Web ゲームという印象です。

両 Harness はフロントエンド、バックエンド、ランキングの永続化、自動テストをすべて完了しましたが、そのプロセスは異なります。DSH は 3 つのセッションに分けて実行され、合計約 25 分、85 ステップ、96 回のツール呼び出しを行い、19 項目の後端テストを提出しました。一度中断した後も、約 880 行に及ぶゲームロジックとブラウザの Smoke Test を自動的に補完して完了させています。

Kimi Code の初回生成には約 14 分 30 秒を要し、2 回の修正を含めると合計 21 分で完了しました。最終的に 17 件のバックエンドテストが交付されています。初版ですでに 2.5D の視覚スタイルは完成しており、その後の実ブラウザフィードバックに基づいて updateHUD の呼び出しやマスクレイヤーの表示問題などが修正されました。

今回の検証から得られた印象を三点挙げます。

第一に、同じモデルと同一のプロンプトを用いても、最終的に異なる二つのプロダクトが生まれました。Kimi Code はフルスクリーンのゲーム体験に寄せていますが、DSH はランキングや説明エリアを含む完成度の高いページへと進化しています。小サンプルではこれが安定した傾向であるとは断言できませんが、Harness が生成物の方向性を形作る要因の一つとなっていることは確かです。

第二に、両者とも 20 分程度のタスクを処理できる能力を持っています。バックエンドとフロントエンドの双方があり、テストも含まれ、途中で修正が必要なケースにも対応可能です。DSH の固定物理ステップサイズやシード付き擬似乱数生成器（PRNG）、原子書き込み機能、そして Kimi Code の 2.5D ステージと完全なインタラクションは、単発のページデモを超えたレベルにあります。

第三に、両者とも「モデル自身のテストは通過したが、実ブラウザでは失敗する」という事象が発生しました。DSH ではキャンバスのバックストアサイズが誤っており、画面には空だけが表示される状態でした。Kimi Code はまず関数の所属に関するエラーに直面し、その後 CSS によって hidden属性 が上書きされる問題が発生しました。これらの問題は V4 Pro にフィードバックされたことで修正され、それぞれのブラウザテストにも回帰チェックが追加されました。

この共通する失敗こそが最も記憶に残るべき点です。エージェントが作成したテストは、実装側と同じ盲点を共有しやすいものです。Harness は完全な実行軌跡を保持し、モデルの継続的な修正を支援できますが、最終的には独立したブラウザや外部検証、そして人間による手動プレイを通じて、プロダクトが実際に使えることを確認する必要があります。

DSH が他のモデルも駆動可能

DSH には DeepSeek の直接接続用アダプターと、pi-ai ベースのマルチプロバイダーアダプターの両方が用意されています。本機では Kimi K3、GPT-5.6 Sol、Claude Opus 4.8 をそれぞれ使用し、ファイルの書き込み、読み戻し、ツール呼び出しを完了しました。

このスモークテストは、プロバイダー、OpenAI 互換メッセージ形式、SSE、およびツールプロトコルが機能することを示すものであり、三つのモデルを比較するものではありません。実際の導入では、テキスト生成、ストリーミング、ツール呼び出し、エラーマッピング、長接続のそれぞれについて個別に検証を行うべきです。

これらの体験はソースコードのどこから来るのか

本リポジトリは TypeScript のモノレポ構成を採用しています。その構造を大まかに以下のように層化して捉えることができます。

deepseek-harness/

├── apps/cli + apps/web 命令行とブラウザの入口

├── packages/boot + bundle プロファイルとプラグインツリーの構築

├── packages/core/

│ ├── agent-loop ターン/ステップ駆動

│ ├── session 追加式イベントログ

│ ├── tools ツール登録と実行

│ └── system-prompt プロンプト断片の組み立て

├── packages/preset 各セッションごとのエージェント構成

├── packages/llm DeepSeek と複数プロバイダーへの対応

├── packages/fs + sandbox 交換可能な実行環境

├── packages/code-runtime PTC / Code Mode

└── vendor/cordis プラグインライフサイクルの基盤

この図で DSH（DeepSeek Harness）の技術スタックがわかります。Cordis がプラグインのライフサイクルとサービス依存関係を管理し、その上で DSH はエージェント領域におけるセッション、ループ、ツール、LLM、サンドボックス、UI を定義します。KM のランタイム分解については、Fiber、Preset、Code Mode、そしてツールの遮蔽（シャドウイング）に対するより詳細なソースコードマッピングが存在しますが、ここではユーザー体験に直結する 5 つのポイントに絞って解説します。

「すべてがプラグイン」である理由は、Cordis が持つ可逆的なライフサイクルにあります。

コードの入口は vendor/cordis/src/context.ts、fiber.ts、そして service.ts にあります。

プラグインは inject を通じて依存するサービスを宣言します。依存サービスがまだ存在しない場合、Fiber は PENDING（待機中）状態になります。サービスが提供されると ACTIVE（アクティブ）状態へ移行し、提供者が退出する際には、まず依存コンポーネントをアンロードしてから、自身で effect を回収します。

サービスやリスナー、タイマーの登録を行う際は、必ず disposer（解放関数）を ctx.effect() に渡す必要があります。アンロード時には逆順でクリーンアップを行います。このメカニズムこそが、Agent Loop を単なるプラグインとして扱える前提条件です。つまり、このような大規模なコンポーネントの読み込み、依存関係管理、そして退出処理を基盤レベルで制御できるからこそ実現されています。

ただし、この仕組みにも明確な限界があります。外部ファイルやネットワークメッセージ、すでに発生した業務アクションは自動的にロールバックされません。また、依存注入（DI）が悪意あるコードに対するサンドボックスの代わりになるわけではありません。

Profile と Preset はそれぞれプロセスとセッションを制御します。

コードの入口は packages/boot/app-boot/src/profile.ts および packages/preset/agent-presets/src/ にあります。

Profile は空リストからスタートし、bundle を積み重ねていきます。その後、profile、home、そしてコマンドラインのパッチが適用されます。これにより、Web 版と Headless 版は異なるプラグインツリーとして構築されます。dsh --profile web --dump-config コマンドも同じパッチアルゴリズムを使用して最終結果を出力するため、設定の表示ロジックと実際の起動ロジックで別々の仕組みを採用しているわけではありません。

Preset は、特定のセッションで利用可能なツール、プロンプト、および投影ユニット（ビューコンポーネント）を決定します。同じプロセス内で standard、minimal、あるいはドメイン特化型エージェントを同時に実行することも可能です。例えば、Data Agent では sqlcmd を使用して bash を置き換えていますが、これはまさにこのスコープ制御が製品レベルで実装された事例です。

モデルが見ている内容は、必ずログから再構築可能である必要があります。

コードの入口は packages/core/agent-loop/src/agent.ts、invariant.ts、および packages/core/session/src/ にあります。

各リクエストはセッションから派生したメッセージとして処理されます。送信前に不変条件（invariant）が再チェックされ、現在のリクエストと session.deriveMessages() の結果、およびモデル、システムプロンプト、温度設定、最大トークン数、ツール構成が一致しているか確認されます。

const expected = session.deriveMessages()
if (JSON.stringify(options.messages) !== JSON.stringify(expected)) {
  fail('log-reconstruction desync')
}

この制約により、Trajectory の明確性が保たれ、フォークや復元、UI 操作が同じイベントストリームを共有できる理由も説明されます。さらに重要なプライバシー上の意味合いもあります。コンテキストがモデルに注入されると、同時にログやデータ境界にも流れ込んでしまうのです。

Capability Seam：ツールと実行環境の分離

コードのエントリーポイントは packages/fs/fs/src/types.ts、fs-local/、fs-sandbox/、そして tool-str-replace-editor/ です。

ファイルシステムはまず FileSystem 型、非公開ターゲット（opaque target）、バージョン定義を設け、その後ローカルまたはサンドボックスプロバイダーが実装します。最後に読み取り、書き込み、編集ツールがこれを利用します。ファイルやサブプロセスのプロバイダーをリモート沙箱へ移行しても、上位層のツールはフォークする必要がありません。

書き込み機能には createIfAbsent や replaceIfVersion といったオプションも用意されています。モデルがファイルを読み込んだ後、もしそのファイルが他者によって更新されていれば、プロバイダーは古いバージョンでの上書きを拒否できます。これにより並行処理の安全性はツール層ではなく、より下位のレベルで担保され、各編集ツールが個別に実装する必要がなくなります。

PTC：コードによるツール往復の削減

コードのエントリーポイントは packages/code-runtime/ です。

PTC（Programmatic Tool Composition）では、モデルが TypeScript コードを記述して複数のツール呼び出しを組み合わせます。このプログラムは worker_threads 内で実行され、ツールへのリクエストはメッセージチャネルを通じてホストへ戻されますが、依然として同一の「事前実行・承認・スケジューリング・事後実行」というパイプラインを経由します。

中間データは実行環境内に保持できるため、各ステップでモデルのコンテキストにデータを埋め込む必要がありません。これは単に「モデルがコードを書ける」ことよりも重要な利点です。ただし代償として、モデル生成コードの実行には追加の隔離が必要となり、worker は完全なセキュリティ境界ではないという課題も残ります。

現在、誰が時間を割くべきか

Agent インフラストラクチャを構築する開発者は、今すぐ確認すべきです。DSH（DeepSeek Harness）はループ、セッション、プロバイダー、ツール、UI をすべて検証可能なソースコードとして公開しています。

ドメイン特化型 Agent のチームは小規模な実験を行う価値があります。minimal または standard プリセットをコピーし、そこから不要なツールを削除したりプロバイダーを差し替えたりする方が、ワークフロー全体を移行するよりも効果を検証しやすいでしょう。

モデル評価担当者には「最小構成（minimal composition）」の利用が推奨されます。これにより、モデルバージョン、推論設定、エンドポイント、外部検証条件を同時に固定できます。

単に日常のコーディングツールを探しているだけの方は、現状は様子見でも構いません。Kimi Code、Claude Code、Codex などの製品は、ターミナル体験、デスクトップ入口、IDE 統合、デフォルトワークフローにおいて、より成熟した状態にあります。

本番環境への導入には、自社のガバナンス体制を補完する必要があります。プラグインのソース管理、設定差分の確認、認証情報の境界設定、Windows での検証、ログ保持期間、データ外部送信の制限など、すべてデプロイ担当者が責任を持って実装しなければなりません。

もしチームが独自の Harness を設計中なら、以下の3つの問いを胸に置いてください。

1. 実行時に最終的に何を読み込むのか？ 単一の命令で出力できるか？
2. モデルが実際に何を「見た」のか？ ログから完全に再構築可能か？
3. ファイルシステム、沙箱、またはモデルプロバイダーを差し替えた際、どのツールの変更が必要になるか？

DSH はこれら3つの問いに対し、「動作し、検証可能な回答」を提供しています。デフォルト製品やプラグインの品質、ガバナンス機能がこのアーキテクチャに追いつけるかどうかは、次の段階で問われる課題です。

資料まとめ

公式情報とソースコード

DeepSeek Harness のソースコード

中国語版アーキテクチャドキュメント

Python SDK を使った最小限の Agent ガイド

Cordis のソースコード

時空の組み合わせ可能性に関する論文

V4 Pro 0813 モデルカード

Kimi Code CLI のソースコード

ユーザーフィードバックと方法論

知乎での目標質問

一週間の内部テストと 89 ステップの競合タスク

デフォルトツールとトークン消費量の試算

WeChat 記録への接続に要した 87.6 分

Data Agent のプリセット実践

VISTA 視覚 Web アプリベンチマーク

ローカルでの再現資料

基本結果 working/eval/results.md

Kimi K3 との比較 working/cross-model/harness-compare/

Kimi Code ソースコードのスナップショット working/kimi-code/

複数モデルのサニティチェック working/cross-model/compat/

V4 Pro のジャンプゲームケース working/jump-game/workspace/

知乎からのフィードバック抜粋 working/eval/zhihu-feedback.md

KM 画像と HTML アタッチメント output/attachments/

すべての数値は、2026-08-14 にローカルマシンで実行した単一結果を基準としています。

📦 完全な再現資料の入手方法：

「腾讯技术工程」公式アカウントをフォローし、バックヤードでキーワード「deepseek」と送信してください。すると、資料が受け取れます。

WeChat で開くにはこちらへ