私はこのリリースを、すぐに使えるコーディングエージェントと、その基盤となるメタハーネスフレームワークという2つの提供物として捉えている。ちょうどPiがOpenClawに対して果たす役割に似ている。
これはこのプロジェクトをめぐる論争の一部も説明してくれるかもしれない。人々は必ずしも同じものを議論しているわけではない。多くの批評家は前者を評価しているが、私がより興味を持っているのは後者の設計だ。
DeepSeek Harnessはコーディングエージェント自体をプラグイン可能にする。企業や開発者は個々のコンポーネントを置き換え、自らのニーズに合ったハーネスを組み立てることができる。また、実行時の自己拡張と反復的改善のための作成モードも提供する。
高レベルで見ると、モデルはこのようになる：
- カーネルはランタイムと拡張メカニズムを提供する。
- プラグインは置き換え可能で組み合わせ可能な原子的能力を提供する。
- 企業はコミュニティからプラグインを選ぶか自社で構築し、カーネルとプラグインを自社のニーズに合わせた内部ハーネスにパッケージ化する。
これがなぜ重要かを理解するには、まずハーネスとは何かを明確にする必要がある。
ハーネスとは何か？
数日前、InfoQの誰かが私にこう質問した：
コンテキスト管理やタスク計画からMCPツール呼び出しやマルチエージェントオーケストレーションまで、ハーネスの能力はますます似通ってきている。意味のあるイノベーションの余地はどこに残されているのか？
ハーネスについて、まだ広く受け入れられた定義は存在しない。
私の見解では、モデルはエージェントの基盤となる推論と認知能力を提供する。ハーネスはそれらの能力がどのように組織化され、呼び出され、実際のタスクに適用されるかを決定する。モデルとハーネスが相まって、エージェントの実用的な能力と性能を定義する。
私はハーネスを2つの層に分けている。
狭義のハーネスとは、コーディングエージェントがタスクを完了するのを支援するランタイムフレームワークである。コンテキスト管理、メモリ、ツール呼び出し、計画、テスト、検証、マルチエージェントオーケストレーションを含む。エージェントがタスクを確実に完了できるかどうかを決定する。
広義のハーネスとは、エージェントが実際のビジネス環境の中で検証、フィードバック、修正を受けられるようにする閉ループシステムである。エージェントを組織のシステムやプロセスに接続し、時間をかけて正しいことをし続けられるよう支援する。
ハーネス問題の前半は、エージェントがどのようにタスクを完了するかである。この領域の能力は確かに収束しつつある。
しかし、似たような機能リストが同一の結果を生むわけではない。速度、精度、安定性、コスト、障害復旧の違いは、しばしば表面下に隠れている。
後半は、エージェントが実際のエンジニアリングやビジネスシステムに入り、フィードバックを受け取り、目標に向かって働き続ける方法である。
差別化がますます生まれてくるのはここだ：シナリオ固有の検証、フィードバックの帰属、閉ループ実行。
開発プラットフォーム、本番ログ、トレーシングシステム、内部自動化プラットフォーム、独自の知識、組織のルールはすべて接続される必要がある。エージェントは実際のフィードバックを見て、結果が正しいかどうかを判断し、失敗の原因を特定し、修正を続けなければならない。
この層は特定の環境に大きく依存する。汎用のコーディングエージェントでは直接解決できない。
同じコーディングエージェントが、あるチームではほとんど魔法のように感じられ、別のチームではまったく役に立たないことがある。その違いはしばしば、チームがその周りに構築したハーネスにある。
これが、これほど多くのプロジェクトがプラグインをパッケージ化している理由だ。その核心において、これらのプラグインは以前は散在していたスキル、MCP統合、ドキュメント、コネクタを、インストール可能で、組み合わせ可能で、配布可能な単位にまとめる。
この観点から見ると、DeepSeek Harnessの方向性はずっと明確になる。
DeepSeek Harnessを再び見る
DeepSeek Harnessの中心的なメッセージは「すべてはプラグイン」である。
さらに重要なのは、コーディングエージェント自体をプラグイン可能にしていることだ。モデル、ツール、スキル、セッション、サンドボックス、ストレージ、ループ、スケジューリング、UIはすべて、置き換えと再結合が可能なプラグインから組み立てられている。
これは、企業がコミュニティのプラグインを使ったり、自社のシナリオ固有のプラグインを開発したり、DeepSeek Harnessに含まれるデフォルトのハーネスコンポーネントを置き換えたりできることを意味する。
原則として、これは二次開発の柔軟性を高めつつ、プロジェクト全体をフォークする必要性を減らし、上流の開発を追い続けやすくする。
この設計は、何年も前に私たちがEggで行ったことを思い出させる。
Eggはランタイムカーネル、プラグインシステム、そして高レベルのフレームワークを構築するための拡張メカニズムを提供した。
同じモデルを使ってDeepSeek Harnessを理解することができる：
- カーネルはランタイムと拡張メカニズムを提供する。
- プラグインは置き換え可能で組み合わせ可能な原子的能力を提供する。
- 企業はカーネルとコミュニティまたは内部開発のプラグインを組み合わせて、独自のハーネスを構築する。
考え方は、安定したカーネルを維持し、残りはエコシステムに探索させることだ。
この方向性が成功すれば、私たちは複数のoh-my-dsh以上のものを手にすることになるかもしれない。異なるシナリオ向けに構築された無数のバリエーションが見られるかもしれない。
既存のコーディングエージェントへの影響の可能性
コミュニティの一部の人々は、MiniMax、Kimi、ZCodeなどのチームはきっと笑っているに違いないと冗談を言っている。
私はそうは思わない。
DeepSeek Harnessは既存のコーディングエージェントに即座の製品プレッシャーを生み出さないかもしれない。しかし、そのエコシステムレベルの影響ははるかに重要になる可能性がある。
梁文鋒のAGIビジョンとDeepSeekのオープンソースモデルはすでに2つの強力な結集点を提供している。DeepSeek Harnessは今、興味深いアーキテクチャ上の提案を加える。
もしそのアーキテクチャが現実の精査に耐えられれば、世界中のオープンソース開発者を引き付ける可能性がある。その場合、既存のコーディングエージェントチームが必ずしも最後に笑うとは限らない。
歴史的にOpenClawの下で重要な役割を果たしたPiは、今も広く議論されている。OpenCodeもまた、忠実な開発者コミュニティを引き付け続けている。しかしこれらのプロジェクトは、独自の基盤モデルを持たないハーネスである。
DeepSeekはLLMとハーネスの両方を持っている。その組み合わせが大きなエコシステムの可能性を生み出す。
コミュニティは最近、同じモデルが異なるハーネスの下でいかに大きく異なるパフォーマンスを発揮できるかを議論している。
もしDeepSeek Harnessが最終的にモデルを比較するための共有インフラの一部になったらどうだろうか？
もしそれがオープンソースコミュニティで好まれるハーネス基盤となり、開発者が徐々にその周りに豊かなプラグインエコシステムを構築していけば、DSHは事実上の標準に発展する可能性がある。そうなれば、他のコーディングエージェントはそのインターフェースや慣習との互換性へと向かうかもしれない。
これらの可能性はまだ推測に過ぎない。それらは今日見えているアイデアとアーキテクチャに基づいており、実証されたエコシステムの成果に基づくものではない。
コンセプトは説得力があり、可能性は現実的だ。次に何が起こるかは、開発者がコードを顕微鏡で調べた後も、そのアーキテクチャがコミュニティの支持を得られるかどうかにかかっている。