「The model is the soul of an agent.」DeepSeek Harnessの公式ページにはこうあります。
エージェントをモデルとハーネスに割り、モデル以外は全部プラグインとして差し替えられる、と言い切っている基盤です。
看板がここまで大きいと中身を確かめたくなるので、リポジトリと設定ファイルを読みました。
エージェントをモデルとハーネスに割るという主張
公式ページの宣言はかなり具体的です。
「Every capability is a plugin that can be swapped or recomposed」として、モデルからツール、セッション、ストレージ、UIまで並べています。
エージェントを構成する要素をここまで刻んで全部プラグインだと言い切っている例は、あまり見ません。
公開は2026年8月13日で、MITライセンスの開発者プレビューです。
反応は派手で、GitHubのスターは執筆時点で約11.5万、フォークが約1.1万。
Hacker Newsでも公開当日に700ポイント超、300件以上のコメントが付いています。
ただ、この手の「全部差し替えられます」は書くだけならタダなんですよ。
何がどこまで外せるのかは、設定ファイルを開けば分かります。
4つのモードは設定ファイル1枚で切り替わる
プラグインの土台になっているのがCordisです。
DeepSeekの新規開発かというとそうではなく、cordiverse/cordisという2022年から公開されているメタフレームワークをvendorで取り込んでいます。
スターは約4,000。
実績のある外部カーネルを持ってきて、その上にエージェントを載せた形ですね。
Cordisの流儀はシンプルで、サービスはctx.llmやctx.tools、ctx.sessionsといったキーに座り、プラグインはinjectで依存を宣言します。
実装を直接importせず、キーで見つける。
だからモデルのアダプタを取り替えても上のレイヤは何も知らずに動くわけで、モデルを替えたらツールの呼び出し側も書き直し、という手戻りが構造的に起きません。
実行モードの実体はapps/cli/config/agent-presets/配下のディレクトリです。
1モードにつき1ディレクトリで、中にはpreset.ymlとagent.cordis.ymlの2枚しか入っていません。
standardとPTCモードの分かれ目
standardはひととおり揃った普通のコーディングエージェントです。
対してcodeディレクトリの説明には、モデルに1本のTypeScriptプログラムで多段の操作を組ませる、と書かれています。
ツールを1回ずつ呼ばせるのではなく、手順をコードとして書かせて走らせる発想ですね。
英語の公式サイトはこれをCode modeと呼んでいますが、同梱のpreset.ymlに入っている表示名は「PTC 模式」です。
ディレクトリ名と表示名と公式表記が三者三様なのは、あとで触れる現在地の話につながります。
minimalとcordisは誰のためにあるのか
minimalは思い切っていて、状態を保つbashとstr_replace_editorの2本だけ。
ツールを削ったときにモデルがどこまで自力でやれるかを見る用途に向いています。
面白いのがcordisです。
tool-cordisというツールが入っていて、動作中の自分自身のランタイムを読み、プラグインを一時的にマウントしてアンマウントできます。
エージェントが自分の構成を編集するモードが、最初から同梱されているわけです。
同時に、設定ファイルには「The toolset is a trust boundary, not a sandbox」(信頼境界であってサンドボックスではない)と書かれ、このpresetのセッションはシェルアクセスと同等に扱えと明記されています。
強力さと危うさを同じ場所に書いてあるのは好感が持てます。
DeepSeek以外のモデルを挿せる範囲
自社モデルの配布チャネルとして作ったなら、差し替え可能という看板は建前で終わります。
公式ガイドを読むと、カタログとして最初から並んでいるのはDeepSeek、Anthropic、OpenAI、Bedrock、Vertex、Azure、Codexです。
AnthropicやOpenAIは設定画面でプロバイダを追加してAPIキーを入れるだけ、残りの4つは固有の認証情報が要ります。
カタログにないエンドポイントも足せて、入力項目はプロバイダID、ベースURL、APIプロトコル(openai-completionsなど)、認証情報、モデル1つ以上です。
ただしpackages/llmを覗くと、アダプタの実装はllm-deepseekとllm-pi-aiの2本しかありません。
前者がDeepSeek直結、後者がpi-aiという多プロバイダアダプタで、カタログの広さは実質こちらが引き受けています。
プロバイダごとに実装を増やすのではなく、共通アダプタ1本に寄せる設計ですね。
実務で引っかかりそうな仕様も、ドキュメントにそのまま書いてあります。
- 手で追加したモデルは、明示するまでテキスト専用の扱い。画像を通すなら
input: [text, image]を指定する - OpenAI互換の
GET /modelsを持たないエンドポイントは、モデル一覧の取得が401で落ちるので手入力になる - プロバイダIDは後から変更できない。リクエスト、保存済みセッション、既定モデル、認証情報の参照がすべてこのIDに乗っているため
重要なのは、差し替えの重心がコードではなく設定にある点です。
ここを取り違えたままだと、プラグインを書く話だと勘違いして遠回りします。
Claude Codeに慣れているほど引っかかる場所
まず入口です。
npx @deepseek-ai/dsh webで起動して、http://127.0.0.1:3080のWeb UIから使うのが標準ルート。
ターミナルに常駐させる頭でいると、最初の一歩からずれます。
次にワークスペース。
起動したディレクトリが自動でプロジェクトルートになるわけではなく、UIから作業ディレクトリを選んで登録します。
これを知らないと、ファイルが見えていないと勘違いします。
そして振る舞いの調整先です。
mdファイルにルールを書き足して制御するのではなく、presetのagent.cordis.ymlでプラグイン構成ごと差し替える。
ルールを積むのではなく能力を組み替える設計です。
セッションの扱いも違います。
設計ドキュメントの「Model-visible means logged」がそれで、モデルへのリクエストに届いたものはすべてセッションログから再構成できる。
再開も分岐も再生も同じイベントストリームに乗ります。
ヘッドレスで回すならdsh --profile headless "run the tests"です(DEEPSEEK_API_KEYが要ります)。
developer previewの現在地
npmで配布されている最新版は0.1.0-rc.6です。
「v0.1」と紹介されることが多いのですが、実際には0.1にも到達していないrc段階。
READMEにも大文字で「THERE WILL BE COMPATIBILITY-BREAKING CHANGES」と書かれています。
GitHubのIssuesは無効化されたままで、窓口はDiscussionsとDiscordのみ。
スター11万超のリポジトリでIssuesを開けていないのは、フィードバックを捌く体制がまだ整っていないという意思表示に見えます。
コミット履歴も特徴的で、公開リポジトリのコミットは全部2026年8月13日付け。
マージ済みのPR番号は#2500台まで進み、ルートには.gitlab-ci.ymlが残っています。
社内で作り込んだものを一気に外へ出した形ですね。
presetの表示名もその名残でしょう。
ドキュメントは英語と中国語で揃っているのに、preset.ymlの表示名だけ中国語のままで、対応するi18nファイルも並んでいません。
分離の発想は看板どおりだったのか
モデルは設定で挿し替わり、ツールもUIもセッションもプラグインとして分かれている。
看板の主張自体は、リポジトリを読む限り誇張ではありませんでした。
ただし「差し替えられる」と「差し替えて実務が回る」は別の話です。
rc段階でIssuesすら開いていない基盤に、いま回っているワークフローを移す理由は薄い。
一方で、設計を読む教材としてはかなり良くできています。
エージェントをどこで割るとどう組み替えられるのか、agent-presetsの4ディレクトリを開けば設定ファイル2枚で見える。
インストールせずに読める分量なので、次のエージェント基盤を選ぶ前の物差しとして目を通す価値はあります。
💬 コメント
ログイン か 会員登録 するとコメントできます