DeepSeek、拼装可能なエージェントアーキテクチャ「DeepSeek Harness」を公開

DeepSeek が初の Agent 製品「Harness」を発表

DeepSeek が初の Agent 製品「Harness」を発表しました。

著者：chino（腾讯 WXG 微信小店 フロントエンドエンジニア）

DeepSeek が初の Agent 製品「Harness」を発表しました。今回の焦点はランタイムアーキテクチャにあります。公式が掲げるキーワードは"everything is a plugin"（すべてをプラグイン化する）。モデルの接続、ツールの実行、会話履歴の記録、ループ処理そのもの、さらには UI まで、すべてがプラグイン機構を通じて管理されます。

本稿では、Agent 分野ですでに業界共通の常識となっている部分——ツール呼び出しの検出、実行、結果のフィードバック、ループ処理など——については省略します。現在、ほぼすべてのフレームワークがこの一連の流れを同じように実装しており、改めて解説する価値はありません。代わりに、DeepSeek Harness が他社と明確に差別化されている設計のポイントに焦点を当てます。

具体的には、プラグインランタイム「Cordis」がどのようにライフサイクルを管理するか、Preset のスコープ継承チェーンがなぜ 2 層構造になっているのか、Code Mode においてあえて"安全"とは言い難い隔離方式を選んだ理由、そしてツール登録における遮蔽アルゴリズムの実装方法です。さらに、Codex のいくつかの具体的なエンジニアリング判断との比較も交えつつ、異なる点のみを解説します。

一、なぜ Cordis を採用したのか

「すべてをプラグイン化する」という方針の基盤となっているのが、Shigma がオープンソース化したプロジェクト「Cordis」です。これは"Meta-Framework for Modern JavaScript Applications"（モダンな JavaScript アプリケーションのためのメタフレームワーク）と位置づけられており、依存関係の注入、スコープごとのサービス管理、ライフサイクルのクリーンアップといった機能を担う汎用的なプラグインフレームワークです。

Agent や LLM とは直接の関係はなく、DeepSeek Harness の登場以前から既に存在していました。

Cordis はオープンソースコミュニティで実際に使われており、その代表例がクロスプラットフォームチャットボットフレームワークの Koishi です。QQ、Discord、Telegram、WeChat といった主要なプラットフォームをすべてサポートしています。チャットボットの運用では「数十個のプラグインを組み合わせて使う」「ホットスワップに対応する」「設定を随時変更できる」という要件が自然に発生しますが、これはエージェントの運用環境とほぼ同じです。唯一の違いは LLM を使わない点だけです。

DeepSeek Harness では Cordis のソースコード全体を自社のリポジトリに取り込み（vendor）、パッケージ名を @deepseek-ai/cordis として再定義しています。さらに、自社で開発したすべてのパッケージに対して、これを peer dependency として設定しました。これは単なる「サードパーティライブラリの利用」を超え、製品全体が Cordis を基盤に構築されていることを意味します。

まず、代表的なプラグインアーキテクチャを三つ比較してみましょう。従来の DI（依存性注入）コンテナ、軽量なフックベースの手法、そして Cordis です。それぞれに明確なトレードオフがあり、並べて検討する価値があります。

従来の DI コンテナには三つの課題があります。「主流」のアプローチは DI コンテナとライフサイクル注釈を組み合わせたものですが、「バインドしたサービスは誰がアンバインドし、クリーンアップするのか？」という問いに対する答えがありません。従来の DI はこれを放置してメモリリークを招くか、あるいは開発者が手動でライフサイクルフックを実装するよう要求します。例えば LLM プロバイダをホットスワップした場合、それに依存する ToolRegistry も自動的に再起動すべきですが、従来の DI では「依存関係に駆動されたリロード」を実現できません。設定についても同様です。従来の DI は起動時に設定を読み込むだけで、変更には対応しません。一方、Cordis の cordis.yml 設定ファイルでは一行が一つのプラグインインスタンスを定義しており、設定の変更は即座に HMR（ホットモジュールリロード）として反映されます。

Pi もエージェント界の注目製品ですが、その Extension（拡張機能）のアプローチは異なります。Pi は「自己拡張可能なコーディングエージェント」を自認しており、その拡張機能は TypeScript で記述され、フックポイントにロジックを注入する仕組みです。しかし、依存性注入もプラグイン間の依存管理（ロード順序が優先度となる）も備えておらず、アンインストールもできません。

これに対し、Cordis のプラグインは「依存関係の宣言」「ライフサイクル管理」「可逆的な副作用」を持つコンポーネントとして設計されています。依存性注入に対応し、反応性の coeffects を持ち、プラグイン間で依存関係を宣言可能で、アンインストール時には副作用を完全に元に戻すことができます。

この「可逆的な副作用」という点が、本稿の核心です。Cordis の設計論文ではこれを理論的レベルまで昇華させ、以下のような核心的な問いを立てています。

動的な処理に、プロセスやコンテナと同様のライフサイクル分離を持たせるプログラミングモデルは存在するか？

プロセスやコンテナの利点は、停止（kill）して再起動すれば状態がクリアされることです。その代償として、キャッシュ、接続、未完了の計算などが失われます。プラグインシステムでは、再起動を伴わずに同じクリーンアップを実現したいと考えています。論文はこの課題に対し、二つの定義を提示しています。

時間的結合性：コンポーネントをアンインストールする際、共有環境に対して行ったすべての変更が完全に安全に元に戻される必要があります。これには、コンポーネントの実行中に発生したリソース割り当て、イベント登録、状態変更のすべてを追跡することが求められます。

空間的結合性：依存関係の変化に応じて、関連するコンポーネントが自動的に有効化または無効化されます。

本稿で最も重視されているのは「時間的結合性」です。残りの要素——Fiber、effect、システム境界、preset、Code Mode——はすべて、「アンインストール＝完全な元に戻し」をどのように工学的に実現するかという問いに対する答えです。

Cordis のエコシステムには、プロジェクトと共にベンダーされたいくつかの連携パッケージも含まれています。宣言型設定ファイル（cordis.yml など）を解析する設定ファイルローダ、設定をサブツリーとしてマウントする include プラグイン（preset 機構はこの機能をリネームしたものです）、プラグインのホットスワップをサポートする HMR モジュール、そしてログとタイマーという二つの基盤プラグインです。これらを組み合わせて初めて、「すべてがプラグインである」という概念を真に理解できます。

Fiber と effect：可逆的な副作用の基盤

Cordis において、プラグインの型定義は以下のようなユニオン型となります：

Plugin は Plugin.Function、Plugin.Constructor、Plugin.Object のいずれかです。これらは「裸の関数」「クラス」「apply メソッドを持つオブジェクト」という 3 つの形式で記述されますが、最終的にはすべて統一されたコールバックとして解析されます。

プラグインをマウントするには ctx.plugin(plugin, config) を呼び出します。内部ではまず、すでに存在する Runtime の記録（コールバック関数のアイデンティティをキーとして使用）を検索します。もし該当する記録があればそれを再利用し、なければ新規作成します。その後、Fiber が生成され、その Runtime の fibers リストに追加されます。

Fiber はプラグインインスタンスのライフサイクル状態マシンです。6 つの状態（PENDING、LOADING、ACTIVE、FAILED、DISPOSED、UNLOADING）を持ちます。例えば、プラグインが inject: ['tools', 'shell'] と宣言している場合、対応する Fiber は PENDING 状態で待機します。依存チェーン上にこれらのサービスがすべて現れるまで待機し、その後に初めてプラグインのコードを実行して ACTIVE 状態に移行します。

この待ち合わせ機構は Cordis が独自に実装した依存解析機能です。プラグイン作者が「相手が準備されるのを待つ」ためのポーリングロジックを手動で記述する必要はありません。これは空間的結合可能性（spatial composability）に対応しており、依存関係が満たされると自動的にコンポーネントが活性化します。

プラグインのアンロードが安全かどうかは、effect 機構によって決定されます。プラグインが登録するあらゆるもの——イベントリスナー、サービス、タイマーなど——は ctx.effect() を通じて登録されます。登録時に即座に実行され、返される取り消し関数（disposer）が disposables リストに追加されます。

論文 5.1.1 では、Cordis におけるすべてのコンテキスト変更は唯一の原語である ctx.effect を通じて行われると指摘されています。サービス提供やコンポーネントのインスタンス化、コンテキストへのあらゆる修正操作は、すべて単一の ctx.effect 呼び出しに帰約されます。

使い方は以下のようになります：

ctx.effect(() => {
  // 副作用の実行：リスナー登録、タイマー起動、サービス提供など
  return () => { /* 逆処理：上記操作の取り消し */ }
})

コールバックは、disposer 関数、Promise、あるいは（非同期）イテレータを返すことができます。イテレータの場合は yield で逐段に disposer を返します。つまり、副作用を行うたびに、その逆処理を行う関数を一つずつ引き渡す仕組みです。

ここで言う「副作用」とは、Context を介して共有環境に対して行われるあらゆる変更を指します。以下の表では、日常的な操作がすべてこの定義に含まれることが示されています：

• 類別：例
• イベント登録：ctx.on("foo", handler) —— 共有イベントバスにリスナーを登録
• サービス提供：ctx.provide(name, service) —— コンテキスト上にサービスを追加
• サブコンポーネントのマウント：ctx.plugin(plugin) —— 子プラグイン自体が「親レベルの副作用」となる
• コンテキスト拡張：ctx.extend() / ctx.intercept() / ctx.isolate()
• 外部リソース：タイマー、ファイル監視、HTTP サーバー、サブプロセス、DB 接続など
• 状態変更：config の変更、レジストリの更新、store の書き換え

Koishi では ctx.command(...) によるコマンド登録や ctx.router.get(...) による HTTP ルート登録が、DSH（DeepSeek Shell）ではツールの登録、HMR リスナーの設置、スケジューラの起動などが該当します。これらすべてが副作用です。

「どのように逆処理するか」は実装上非常にシンプルです。各副作用には独自の取り消し関数が付随しており、実行時にはそれらを LIFO（Last In, First Out）のスタックに積みます。アンロード時にはこのスタック全体を一度に実行することで、すべての副作用を安全に取り除きます。

登録された順序の逆順に、登録解除関数を一つずつ実行します。これはスタックから要素を取り出す操作に似ています。

子ファイバーの削除関数自体も、parent.fiber.effect(...) を通じて親ファイバーに登録されます。ソースコード上では、Fiber コンストラクタの末尾にある以下の行が該当します：

this.dispose = parent.fiber.effect(() => { /* プラグイン登録 */
  return async () => { /* プラグイン解除 */ }
})

つまり、プラグインとは親ファイバー上の「エフェクト（副作用）」そのものです。プラグインの起動ロジックが副作用であり、アンロード（削除）ロジックはその逆操作となります。

子コンポーネントの逆操作は、親コンテキストの累積器に先頭へ追加（prepend）され、再帰的な構造を形成します（論文では「twisted composition」と呼ばれ、𝜕²Γ と表記されます）。したがって、あるプラグインをアンロードすると、その下に紐付いている子プラグインもスタック順に自動的にすべて削除されるため、「誰が誰に依存しているか」を管理する専用のクリーンアップテーブルを別途用意する必要はありません。

このメカニズムには、信頼性を高めるための 2 つの重要な仕組みがあります。

1つ目は冪等性（いどうせい）です。dispose() を初めて呼び出すと armed フラグが false に設定され、その後再度呼び出されても即座に返却されます。これにより、逆操作は最大で 1 回しか実行されません。「一度も発生しなかったエフェクトに対して逆操作を適用すると、状態の復元ができなくなる」というリスクを防ぎます。

2つ目は中断機能です。コールバックがイテレータ（反復子）を返す場合、各ステップの実行前にガード条件をチェックします。条件が失われた瞬間に即座に停止し、すでに累積された逆操作のみを実行します。これにより、ホットリロードやアンロード中の失敗といった状況でも、安全に処理を中断できます。

イベントリスナーも同様に可逆的なメカニズムに従います。ctx.on(...) は unsubscribe 関数を返し、リスナーはファイバーのフックテーブルに登録されます。ファイバーがアンロードされる際に、これらは一括で削除されます。

_unload() がすべての撤销（解除）関数を実行した後、もし依存関係が再び満たされていると検知されれば、即座に _reload() を呼び出して再構築します。「あるサービスの実装を差し替える」という行為は、ランタイムレベルでは自動的に「アンロード→ロード」のサイクルとして処理されるのです。

プラグインの実装例（UI 画面に時計を追加するケース）は以下のようになります：

会话日志プラグインは、イベントリスナーの登録とタイマーの起動を行い、アンロード時には自動的にクリーンアップする仕組みです。

export const name = 'session-logger'
export function apply(ctx: Context) {
  // effect コールバックは登録時に即座に実行される
  ctx.effect(() => {
    // 副作用 1：イベントバスを購読し、イベントをログに追加する
    const off = ctx.on('tool/result', (event) => appendToLog(event))
    // 副作用 2：タイマーを開始し、定期的にバッファをディスクへフラッシュする
    const timer = setInterval(flushBuffer, 1000)
    // 戻り値は取り消し関数：アンロード時には登録の逆順で実行される
    return () => {
      clearInterval(timer) // 後から登録されたものは先に削除
      off()              // 次にリスナーを解除する
    }
  })
}

このプラグインをマウントすると、ctx.effect のコールバックは即座に実行されます。リスナーが取り付けられ、タイマーが起動し、返された取り消し関数は disposables リストに追加されます。アンロード時（プラグインの削除、セッション終了、HMR による再読み込みなど）には、disposables.splice(0).reverse() が逆順で個別に実行され、まず clearInterval が呼び出され、次に off() が実行されます。

取り消しロジックは登録ロジックのすぐ隣に記述されるため、開発者は「どこを解除するか」を別箇所で管理する必要はありません。

この書き方は非常に React のそれに似ています。useEffect の形状もほぼ同じです：

useEffect(() => { subscribe(); return () => unsubscribe() }, deps)

—— コールバック内で副作用を実行し、クリーンアップ関数を返すことで、コンポーネントのアンロード時に自動的に呼び出されます。

両者に共通する核心的な約束事は、「副作用とその逆処理をセットで記述し、破棄はフレームワークがトリガーする」という点です。違いも明確です。React の effect はレンダリング後に実行され、依存関係の変化時にはまずクリーンアップされてから再構築されます。一方、Cordis の effect は登録時に即座に実行され、アンロード時には一元的に取り消しが行われます。また、クリーンの順序には明確な LIFO（後入れ先出し）の保証があり、「後から登録されたものが先に削除される」ため、子プラグインは親プラグインの逆順でカスケード的に解除されます。

なぜ「逆処理」にこれほど多くのページを割く必要があるのか。論文では「自進化する Agent Harness」が 2 つの主要な動機の一つとして挙げられており、その記述は非常に鋭いです：

将来の harness は、継続的なサービスリクエストを受けながら、自身のコンポーネントに対する変更を生成・デプロイしていくことになる……時間的結合性（time-composability）が失われ、自己修正のたびに完全な再起動を余儀なくされ、プロセス内に蓄積されたすべての状態が失われる。さらに悪化すれば、欠陥のある自己修正によって、回復に唯一頼れるプロセスさえも破綻する恐れがある。

これが「自進化」の前提条件です。Agent 自身がプラグインやツールを記述し、実行時に自らに組み込みます。不良なコンポーネントが導入された場合でもロールバック可能であり、かつそのロールバック機構自体（ホストプロセス）を新コンポーネントによって破壊されてはなりません。

通常のプラグインシステムではこれが実現できません。なぜなら、ホストのプロセスを再起動すれば、現在のプロセスに蓄積されていたすべての状態が失われてしまうからです。

既存の生態系と比較してみましょう。VSCode の拡張機能ホストでは単一の拡張機能をアンロードできず、無効化やアンロードにはホスト全体の再起動が必要です。Koishi コミュニティでも、設定を変更した後にデーモンをリロードするのはごく一般的な操作です。

Cordis の「逆処理」メカニズムにより、「アンロード」は「ロード」と対称的な一等操作となります。サービスは中断されず、他のプラグインへの影響もありません。

この仕組みは、2 つの一般的なエンジニアリング課題も同時に解決します。

1. 失敗時の原子性：プラグインの初期化中に例外が発生した場合（設定検証の失敗や依存関係の欠如など）、fiber は FAILED 状態に入り、dispose が実行されます。すでに適用された効果の一部は逆順で削除され、部分的な初期化状態が残留することはありません。
2. カスケードクリーンアップ：開発者はアンロード用のコードを記述する必要がありません。

論文の 5.3 セクションにおける重要な主張は以下の通りです。

コンテキストの追跡と自動逆复合（リバーシブル・コンポジション）の仕組みにより、経験が浅い開発者でも、プラグインの副作用を体系的に整理できます。アンロードパスを手動で記述する必要はなく、「正しさ」は個々の開発者の自己責任から、抽象層が一括して保証するものへと変わります。

具体的には、プラグインをアンロードする際、その子プラグインが逆順でカスケード（連鎖）的にアンロードされ、タイマーやリスナー、HTTP サーバー、データベース接続などが解放されます。これにより、「各開発者が deactivate 関数を正しく記述すること」に依存していた清理の正しさが、「フレームワーク構造による保証」へと移行します。

ここで VSCode モデルには弱点があります。同モデルでは activate と deactivate のフックが分離しており、「副作用の生成と清理が分断されている」ため、関心の局所性が損なわれ、完全な清理を検証することが困難です。

この逆転（リバーシブル）メカニズムの主な役割は以下の 4 点に集約されます。

① 開発中の HMR（コード変更で再起動不要、エラー発生時はトランザクションロールバック可能）

② 本番環境でのプラグインの動的なロード/アンロード（サービス停止なし）

③ 自己進化型 Agent（自身を修正し、障害時には自己修復）

④ 失敗の原子性とカスケード清理（不良プラグインが残留して他に影響せず、開発者はアンロードコードを書く必要がない）

この仕組みは、「手動での事後処理」だったアンロードを、「フレームワーク保証による構造的な操作」へと変革しました。これが「すべてをプラグインとする」「プラグインのホットスワップが可能」という理念が成立する前提条件です。

三、四条の制約とシステムの境界：効果（エフェクト）が確実に実行される仕組み

ここまで読んで、「もし開発者が副作用を effect の外側で記述したらどうなるのか？例えば globalThis.foo に直接代入した場合、このメカニズムは機能するのか？」と疑問を持つ方もいるかもしれません。論文はこの問いに正面から回答しています。

フレームワークの対応は二つの側面から行われます。一つは API レベルでの制約で、コンテキストの変更は effect を通じてのみ行うことを強制します。もう一つはシステム境界の明確化で、境界外で行われる操作は追跡対象外と定義されています。

フレームワークは効果（エフェクト）の使用について、以下の 4 つの側面から制約を設けます。

第一に、API エントリーポイントが唯一つであること。イベント ctx.on、サービス提供 ctx.provide、プラグインの登録 ctx.plugin、サービスの設定 ctx.use など、フレームワークの機能を利用する手段はすべて ctx 経由のみです。また、ctx 上のあらゆる操作内部では ctx.effect がラップされています。API デザイン上、effect を迂回してフレームワーク機能を利用する経路は存在しません。

第二に、Context は Proxy です。ソースコードには単一の行で定義されています：const self = new Proxy(this, ReflectService.handler)。ctx の属性に対する get/set 操作はすべてプロキシを介して処理されます。これが反応性 coeffect（「アクセス＝通知」）とインターセプションのメカニズムの源泉です。したがって、ctx.foo = x という直接代入も拦截され、記録されます。

第三に、ライフサイクル状態マシンです。各 fiber には状態マシンが備わっており、ctx.effect() の第一行は this.assertActive() です。すでにアンロードされた fiber で effect を作成しようとすると、即座に CordisError INACTIVE_EFFECT がスローされます。アンロード後に副作用を登録しようとしてもフレームワークは拒否するため、時間的な観点から此类のリークが排除されます。

第四に、トランザクション型 HMR です。もし開発者が逆転ロジックを誤記し、新コードの import に失敗した場合（文法エラーなど）、Algorithm 10 の backup/restore メカニズムにより、全体が旧バージョンへロールバックされます。システムは部分的なロード状態に留まることはありません。これがメカニズムレベルでの最後の保障です。

境界外で行われる操作については、フレームワークは明確に追跡しない方針です。論文 §6.1 では環境を二つに分けています。「境界内（inside）」とは、システムが独占的に変更でき、かつ元状へ回復可能な領域で、その操作記録は Γ に保存され、recover 可能です。「境界外（outside）」では、この二つの条件のいずれかが欠けているため、操作は idΓ として扱われ、追跡も回復も行われません。注意すべきは、この境界が「場所」によって定義される点です。媒体の種類とは無関係です。

例えば、プライベートパスの scratch ファイルや、本システムのみが書き込むメモリ領域は「境界内」に分類されます。一方、公開ファイルや他のプロセスも書き込んでいるデータは「境界外」となります。グローバル変数の直接変更、monkey-patch、公共ファイルへの書き込みはいずれも境界外の操作です。フレームワークはこれらの操作を追跡せず、回復できるとも主張しません。これは設計上、明確に宣言された境界なのです。

さらに細分化すると、取得と放出の 2 つの段階があります。取得段階（open/malloc/fork）はシステムの境界内にあり可逆ですが、放出段階（write/send でデータがシステム外へ出る）は境界の外にあり不可逆です。この場合、回復には「 withholding（放出を猶予し、状態が確定するまで待つ）」か「compensation（補償動作：作成したファイルを削除したり、受け取った資金を返却したりする）」のいずれかが必要になります。補償も LIFO（後入れ先出し）で組み合わされますが、元となる理論はもう保証されません。

では、境界外の資源を工程上どう扱うか？論文 §6.1 では「coeffect を用いて外部位置を具体化し、境界を移動させる」という手段を示しています。これにより、特定位置へのアクセスを一連の操作に限定できます。各操作には逆処理が用意されているため、本来 idΓ として振る舞っていた操作も追跡可能になり、回復が可能になります。工程上ではこれが「サービス（service）」という抽象化です。開発者は ctx.database や ctx.assets を通じてこれらの資源にアクセスしますが、データベース接続やファイルハンドル、子プロセスといった低レベルの要素には直接触れません。資源のライフサイクルは各サービスの effect 内部に閉じ込められ、サービス提供者が正しい逆処理を実装する責任を負います。消費者側は高レベルなインターフェースのみを扱えばよいです。副作用はプラグインコードのあちこちに散在せず、サービス実装内部に集約されます。また、作者としての義務も多数のプラグイン作者から少数のサービス実装者に収束します。

最後に残る問題は、「逆処理が正しく書かれているか、どう判定するか」です。論文 §3.3.2 では「物理的な完全な復元」を要求していません。なぜならそれは不可能だからです（free 命令はヒープのレイアウトを元に戻せず、生成された名前も再生されません）。代わりに、「回復」は観察者による区別がつかない状態として定義されます。

「2 つの状態が関連しているとは、いかなる観察者もそれらを区別できないことを意味します。表現ではなく振る舞いを比較するのです……等価関係は、coeffect がそれぞれ持つ等価性によって構成されます。」

つまり、「逆処理」の意味は観察レベルでの復元です。回復前と回復後の状態において、いかなる観察者も違いを認識できないことが、逆処理の正しさの基準となります。ヒープレイアウトが完全に元に戻っていなくても、coeffect の操作で差異を検出できなければ、回復は成功したとみなされます。

この章で示された保証事項は、以下のように階層化して整理できます：

• 层次：谁保证 / 内容
• 路径强制：框架（API 设计） / 用框架功能只能走 ctx，ctx 内操作全是 effect 封装 → 必然被追踪
• 时间强制：框架（状态机） / 已卸载 fiber 上建 effect 直接抛 INACTIVE_EFFECT
• 属性拦截：框架（Proxy） / ctx 属性读写被代理拦截、可记录
• 模块级事务：框架（HMR backup/restore） / import 失败整体回滚，不进半重载态
• 逆的正确性：作者义务 / 运行时不验证 witness（g(δ)=γ），论文明说
• 边界外行为：无保证 / 全局变量 / 公共文件 / 发射出去的数据 = idΓ
• 边界移动：coeffect / 服务物化 / 把外部位置封装成"可逆的服务"，访问受限、逆由服务提供

まとめると、このフレームワークは「ctx.effect を通じてコンテキストを変更する」ことを唯一のパスとし、「逆処理が正しいか」については作者の義務に委ねます。同時にシステムの境界を明確に宣言します。工程上の着地点は「サービスの具体化」です。副作用はサービス実装内部に集中し、責任は「すべてのプラグイン作者」から「少数のサービス実装者」へと収束します。

論文には非常に率直な一文もあります。「逆処理を提供するコールバックはあるが、それが伴う効果を本当に復元できているかは、コンポーネント作者の義務（obligation）であり、ランタイムが検証する性質（property）ではない」と。ランタイムは「逆処理が呼び出されること」を構造的に保証しますが、「逆処理の内容が正しいか」までは保証しません。

ついでに一つの観察を：この設計は TypeScript/JavaScript で最も直接的に実装できます。多くのコンパイル言語の型システムはクラスベースであり、型レイアウトはコンパイル時に固定されます。そのため、新しいコンパイル結果を動的にロードして上書きすることができず、メモリ上に読み込まれた型情報も通常アンロードできません。

一方、TS/JS はプロトタイプシステムです。型構造を動的に調整できます。Agent が新しいツールを作成すれば、それを直接プロトタイプに紐付けるだけで、すべてのサブコンポーネントが即座に感知して呼び出せます。取り消す際はプロトタイプチェーンから切断するだけなので、システム状態は瞬時に回復します。

Proxy は「論理的には極めて解離され、構文的には完全に透明な」動的ルーティングを提供します。コードで ctx.tool と記述した瞬間に、Proxy が動的アドレス指定と権限チェックを完了させます。静的言語ではこれを実現するのは困難です。Module Augmentation により、プラグインはグローバルな Context の型定義を動的に変更できます。Agent が生成した新しいツールに対して、型ヒントとセキュリティチェックがシステム全体へ瞬時に同期され、「動的進化」と「型安全性」の両立を実現します。

さらに JS にはプログラムによるモジュール登録表があり、モジュールをアンロードして関連オブジェクトをガベージコレクションに任せることが可能です。Swift のような言語では、読み込まれた型メタデータを完全にクリーンアップすることはほぼ不可能です。

四、ctx. の解析方法：Proxy と Fiber チェイン一つで

プラグイン同士がどのようにして互いの提供能力を取得するかは、別途説明する価値があります。これが「すべてがプラグイン」という概念を実装できるもう一つの柱だからです。

ルートコンテキストは Proxy で包まれています：new Proxy(this, ReflectService.handler)。ctx.tools、ctx.llm、ctx.session といったプロパティにアクセスする際、これは Proxy の get トラップを経由します。既に存在する自身のプロパティは原生の Reflect.get で処理され、見知らぬ属性名が現れた場合は、まず登録済みのアクセサがあるか確認します。なければ、現在の Fiber を上向きに探索します。

let fiber = ctx.fiber
while (true) {
  const impl = fiber.store?.[prop]
  if (impl) return impl.value
  if (prop in fiber.inject) throw new Error('service not active')
  if (!fiber.runtime) throw new Error('unknown service')
  fiber = fiber.parent.fiber
}

親の Fiber をたどり、そのサービスを提供するレイヤーを見つけるか、本当に誰も提供していないことが確定するまで続けます。

実際にサービスを「公開」するのは Service という基底クラスです。コンストラクタで self.ctx.reflect.provide(name, self, check) を呼び出します。provide() 自体も ctx.fiber.effect(...) に包まれています。現在の Fiber の store に {name, value, fiber, check} のレコードを追加し、そのサービスに依存して待機している方々をウェイクアップさせます。返される取り消し関数は、このレコードを store から削除し、再度通知を行います。サービスの削除は、プラグインのアンロードと全く同じエフェクトの取り消しメカニズムを経由し、特別なパスは用意されていません。システム内に専用の「サービス登録センター」クラスはありません。ctx. という書き方の背後にあるのは、Proxy のインターセプトと Fiber チェーンに沿った検索です。誰がどのレイヤーで何を登録したかが、直接誰が見えるかを決定します。

この設計による直接的な帰結は、スコープの隔離が本質的に保証される点です。子 Fiber は親 Fiber で登録されたサービスを見ることができますが、逆は成立しません。特定のプラグインのサービスを特定の範囲内（例えば、ある preset に固有のファイルシステム実装など）でのみ有効にしたい場合、追加的な可視性制御ロジックは不要です。そのプラグインを対応する階層の Fiber 下に配置するだけで、検索チェーンが自動的にその範囲に制限されます。

この仕組みの価値は、実際のユースケースでこそ明確になります。

DeepSeek Harness は「llm」サービスインターフェース（packages/llm/llm）を定義しています。これは「ストリーミング呼び出しをどう行うか」「リトライをどう処理するか」という点だけを規定し、どのモデルベンダーを使うかは問いません。システムにはこのインターフェースを実装する 2 つのプラグインが同時に登録されています。

1 つは dsh-llm-deepseek で、DeepSeek 自社のモデルに特化して設計されています。もう 1 つは dsh-llm-pi-ai で、内部でサードパーティの npm ライブラリ @earendil-works/pi-ai をラップし、複数のモデルベンダー間のプロトコル変換を担当します。

なお、この「pi」は外部で比較対象として言及される Pi agent harness とは無関係です。単に名前が被っているだけです。

公式には約 40 のモデルベンダーが利用可能ですが、その大半はこの dsh-llm-pi-ai プラグインによってサポートされています。2 つのプラグインは互いの存在を知らず、どちらをインストールするか、あるいは切り替えるかによって、上位レイヤーにある agent loop の呼び出しコードは一切変更する必要がありません。なぜなら、実際に呼ばれるのはインターフェースそのものだからです。

公式ドキュメントではこの構成を「設計検証の双子（design verification twins）」と呼んでいます。2 つの完全に独立した実装が同じ定義を満たすことで、このインターフェースが十分に汎用的であることを裏付けています。

五、Agent Loop において特筆すべき設計ポイント

Loop の全体像は、現在の多くのフレームワークと同様です。モデルへの入力・出力、ツール呼び出しの検出、実行、結果のフィードバックといった基本フローについては繰り返しません。ここでは特に注目すべき具体的な実装に焦点を当てます。

第一に、ループの終了条件は多様なソースから得られます。「新しいツール呼び出しがない」こと以外にも、ツールの実行結果自体が concludesTurn: true というフラグを含めることができます。このフラグによって、「このラウンドで停止する」という意志をツール側が宣言し、モデルが「よし、これでいい」と言うのを待つ必要はありません。

第二に、max-tokens（最大トークン数）の状態は「粘着性」を持ちます。

if (turnEnds === null || turnEnds.kind !== 'max-tokens') turnEnds = stepEnd

あるステップで出力上限に達して切り捨てられた場合、その後のステップが正常に完了したとしても、ラウンド全体の終了理由として「正常終了」という情報は上書きされません。上位層（統計処理やログ表示）は、「このラウンドは一度も切り捨てられたことがある」というシグナルを正しく認識し続けます。

第三に、ラウンドが実際に閉じられる直前に、agent/turn-stopping というイベントがブロードキャストされます。これはプラグインがフックして処理を介入できるフックポイントです。プラグインは agent.steer(...) を呼び出して新たなメッセージを追加すれば、ループは継続します。何も操作しなければ、デフォルトとしてラウンドは終了します。

「いつ本当に終わるか」という判断が Loop 内部から外部へ移されました。どのプラグインも最終段階で「まだ続く、何か付け加えたい」と決定できます。Loop 自体は、「まだ続く」理由がいくつあるかを事前に知る必要はありません。

第四に、ツールスケジューリングでは、実際の呼び出しを行うたびに、各ツールに対して並列実行が可能かどうかを問い合わせます。この判断は静的なホワイトリストに依存しません。

executionMode(exec): ToolExecutionMode {

const tool = this.resolveExecution(exec.name, exec.agent)

if (!tool?.isConcurrencySafe) return { kind: 'exclusive' }

return tool.isConcurrencySafe(exec.arguments) === true

? { kind: 'parallel' }

: { kind: 'exclusive' }

}

同じツールでも、引数の組み合わせによって異なる回答が返されます。例えば、「ファイルの読み込み」は常に並列実行が可能ですが、「ファイルへの書き込み」は、対象パスが重複しない場合にのみ安全です。

スケジューラはグループ化して実行する際、次の呼び出しを開始する直前に再度モードを判定します。並列グループの中に、その時点で互斥と判断された呼び出しが含まれていた場合、そのグループはそこで打ち切られ、互斥な呼び出しが強制的に並列入力されることはありません。

結果は、モデルが最初に提示した呼び出し順に従って提出されます。スケジューリングの完了順序とは無関係です。

第五，工具执行前后的检查环节是独立且可插拔的。它们各自单独注册，不会直接写在工具执行的函数内部。

tools/pre-execute 是一个瀑布流式的事件触发点，任何插件都能在此拦截请求或要求审批。只有通过这一关后，系统才会进入内置的防护检查（例如：若同一工具被连续调用相同参数过多次数，会触发提醒），随后才真正执行工具调用。执行完成后，还会通过 tools/post-execute 让插件对结果进行二次处理。

这四个阶段顺序固定、彼此独立，构成了插件挂载的标准接口。若要新增一种审批策略或防护规则，无需改动底层的执行链路，只需注册一个新的事件监听器即可。

六、Preset 的两层作用域链：真实继承与影子路由表

Preset 的挂载机制解决了一个具体问题：如何让同一份配置被多个会话复用，同时避免每次都要重新解析配置文件。

一份预设本质上是一个目录，其核心是 agent.cordis.yml 文件。该文件按顺序列出了需要挂载的插件及其参数。挂载这份文件时，系统复用了 Cordis 生态中的 Include 插件，并将其重命名为 PresetTree：

const handle = agentCtx.plugin(PresetTree, { path: pathToFileURL(preset.path).href })
await handle.await()

PresetTree 重写了两个关键方法：在解析裸模块名时，它会查找系统自身的 baseUrl，预设目录不参与此过程；同时，写回配置被直接禁用，防止预设源文件被意外修改。挂载完成后，系统还会核对两件事：是否存在插件配置停留在不可用状态，以及是否有服务在挂载过程中“泄漏”到了预设作用域之外。任何一项不满足条件，都会触发整体回滚。

关于作用域链的构造方式值得细看。从全局到某个预设的过程是一次真实的上下文派生：createScope() 内部调用 ctx.plugin(scope) 获取一个 Fiber 对象，随后通过 fiber.ctx.extend({[kScope]: key}) 在 Cordis 的上下文树中真实创建一个节点。

而从预设到具体某个会话的继承，则采用另一种方式：

this.bindings.set(agentKey, bindScopeParent(agentKey, standing.key))

bindScopeParent 会在一张 WeakMap 中记录一条“逻辑上级”关系，而不会在 Cordis 的 Fiber 树中开启任何新节点。

如此拆分的动机非常直接：一份预设的“标准挂载实例”只需构建一次（通过 ensureStanding()），后续无论是写作、编码还是调研等不同类型的会话，都可以复用同一份实例。系统仅需往这张 WeakMap 中追加一条绑定即可，无需为每个新会话重新运行插件加载流程。

子 Agent 若要继承父 Agent 当前挂载的预设，调用的 composeFrom(childCtx, parentCtx) 也仅仅是这张表上的一次查找与绑定操作，属于同步行为，不会重新触发任何插件的挂载流程。因此，子 Agent 拿到的是与父 Agent 完全相同的插件实例，包括同一批已注册的工具和提示词片段。

系统判定当前会话生效的是哪个预设时，采用倒序扫描事件日志的逻辑：寻找最新一条 agent-preset/selected 记录。

セッションイベントの末尾から順にループ処理を行い、agent-preset/selected 型のイベントが見つかったら即座にそのデータを返します。該当するイベントが存在しない場合は、セッション作成時に設定されたデフォルト値を返す仕組みです。

理論上、セッション実行中にプリセットを変更することはアーキテクチャ上で許容されており、検索ロジックもこのケースを前提として設計されていますが、実際に運用で利用するかは製品側の判断に委ねられています。

プリセットの検出メカニズムについても触れておきます。スキャン対象となるルートディレクトリでは、ディレクトリ名が特定の命名規則に合致し、かつ内部に agent.cordis.yml ファイルを持つサブディレクトリのみが対象となります。各 YAML ファイルの解析可否と構造の妥当性を個別に検証し、破損した項目は検出してもスキャン自体を中断しません。

複数のルートディレクトリを統合する際は、登録順で先に現れた ID が優先され、後続のルートにある同名プリセットは無視されます。この仕様により、「ユーザー定義のプリセットが公式プリセットを上書きする（あるいはその逆）」といった柔軟な運用が可能になります。

七、Code Mode の隔離方案：worker_threads

モデルにコードを書かせて複数のツール呼び出しをオーケストレーションするというアプローチ自体は新しいものではありませんが、DeepSeek Harness が採用した隔離手法の選定と実装には注目すべき点があります。

この環境では node:worker_threads を使用しています。これは一般的な V8 分離環境や vm2 とは異なる、標準的な Node.js のワーカースレッドです。同プロセス内で動作する node:vm ベースのサンドボックスは、プロトタイプチェーンを介してメイン環境へのエスケープが可能な点や、外部から実行を完全に停止できない点など、信頼性に欠けると判断されました。独立したワーカースレッドを採用することで、コード実行ごとに新たなスレッドを起動するコストが発生しますが、その代わりに真に独立した V8 ヒープと、外部から強制終了可能な実行環境を獲得しています。

モデルが生成したコードは、まず stripTypeScriptTypes 関数によって型注釈が除去されます。この際、前後に包装文字列を追加して位置情報を保持し、除去後のコードでも元の行番号や列番号が一致するように調整します。

const stripped = stripTypeScriptTypes(prefix + program + suffix)

除去されたコードは動的に構築された非同期関数内に格納されます。

const AsyncFunction = (async () => {}).constructor

const fn = new AsyncFunction(...bindingNames, ...errorClassNames, 'console', code)

const value = await fn(...bindings, ...errorClasses, consoleShim)

各ツールの名前空間、事前に定義されたエラークラス、そして置換用の console オブジェクトは、この関数の引数として渡されます。これにより、モデルが生成したコード内ではトップレベルの await 文や return 文を直接使用することが可能になります。

ワーカースレッド自体にはリソース制限が設けられており、resourceLimits.maxOldGenerationSizeMb でヒープメモリの上限が管理されています。また、実行時間の制御には二重のタイムアウト機構が用意されています。一つはイベントループの利用状況をポーリングして CPU 使用時間を計測する方式、もう一つは単純な setTimeout を用いた総実行時間の制限です。いずれかの条件でタイムアウトが発生すると、即座に処理を強制中断します。

コード内でのツール呼び出しは、関数を直接参照するのではなく、メッセージチャネルを通じて行われます：

worker から host への呼び出しは、{ type: 'call', id, global: 'tools', name, args } の形式で行われます。

host から worker への返信は、{ type: 'reply', id, ok: true, value } の形式です。

宿主側が呼び出しを受け取ると、それは通常のツール呼び出しとして処理され、第五章で解説した pre-execute（事前実行）、防護、dispatch（振り分け）、post-execute（事後実行）というパイプラインを通過します。モデルから直接行われる構造化されたツール呼び出しと同じ実行コアを利用しますが、入口が異なるだけです。

通信の両端では、受信するメッセージの各フィールドを手動で厳格に検証しています。宿主側では、バインド関数の検索に Object.hasOwn() を用いて自有属性を正確に判定し、コードに暴露される tools 命名空間の構築には Object.create(null) で初期化してから、一つずつ Object.defineProperty でマウントします。

これらの対策はすべて、同じ目的のために実施されています。つまり、コード内に __proto__ や constructor といったフィールドを仕込まれ、プロトタイプチェーンを迂回して予期せぬ動作を引き起こされるのを防ぐためです。コードのコメントには「worker を敵対する他者として扱う」と明記されており、この信頼性の仮定は明確に宣言されています。

Codex のアプローチとの決定的な違いは隔離層にあります。独立した V8 isolate を用意し、ツールをグローバルな tools オブジェクト上に配置します。公式の説明では「新しい V8 分離環境で JavaScript を実行する」とされています。

両者の解決策は同じ問題、つまりコードによる複数のツール呼び出しのオーケストレーションと往復通信の削減に向かっていますが、隔離技術の選定方針が異なります。背景にあるのは、「毎回新しい isolate を作成するオーバーヘッド」と「毎回新しいワーカースレッドを開くオーバーヘッド」のどちらがコスト的に有利かというトレードオフと、それぞれのエコシステムで利用可能な既存の分離原語の違いです。

八、ツール登録における階層遮蔽アルゴリズム

ツールを異なるスコープ間で「近接して上書きする」仕組みは、プラグイン設計において見過ごされがちですが極めて重要な要素であり、これが preset によるツールの真の置換可否を決定づけます。

各スコープは独自の ToolLayer を保持しており、内部では名前をキーとしたテーブルが管理されています。「現在のエージェントがどのツールを見られるか」を決定するのは view() というステップです。まずグローバル層のツールを読み込んでベースとし、次に祖先となるスコープを順にたどり、同名のエントリを上書きしていきます。この際、現在のスコープに近い祖先ほど優先度が高くなります。この処理は継承された部分のみを対象とします。

その後、制限ルール（例えば特定の preset でツールの使用が明確に禁止されている場合など）がフィルタリングされます。最後に、現在のスコープで直接登録されたツールが、それまでに継承された同名のエントリをすべて上書きします。たとえ制限ルールでその名前が禁止されていたとしても例外です。

この順序は極めて重要です。自分で登録したツールは、継承や制限ルールよりも優先されます。

登録プロセス自体にも厳格な検証が施されています：

register(definition: ToolDefinition): () => void {

if (definition.name === RUN_CODE_NAME) {

throw new Error(tool name "${RUN_CODE_NAME}" is reserved for the Code Mode transport)

}

assertSupportedJsonSchema(definition.output.schema)

return this.layers.effect(this.ctx, layer => layer.tools.insert(definition.name, definition))

}

run_code という名前はハードコードで予約されており、どのプラグインもこれを登録したり上書きしたりできません。その理由はコードコメントに書かれています。あらゆるエージェントが自分自身に対してコードモードを選択する可能性があります。デフォルトのデプロイでは一見すると空き状態に見えるこの名前ですが、あるプリセットがマウントされた瞬間、Code Mode の呼び出し入口と衝突する恐れがあります。そのため、無条件で予約されています。

登録動作自体も effect() を通じて行われます。register() から返される取り消し関数を、現在の Fiber の disposables リストに挿入します。プラグインに登録されたツールは、そのプラグインがアンロードされると自動的にレイヤーから削除されます。「アンロード時にツールを削除する」といった追加のクリーンアップコードを書く必要はありません。これは第二章で説明した効果の取り消しメカニズムと同じ経路です。ツールの登録も、「登録＝副作用」の数あるケースの一つに過ぎません。

ツールの実行自体も、このスケジューラの並行処理契約を流用しています。Code Mode でモデルコードがツールを呼び出す際、その呼び出しはホスト側の同じ TOOL_RUNTIME_SCHEDULER の待機キューに入ります。モデルが直接行う構造化されたツール呼び出しと、並行制御や事前チェックのセットを共有します。これが、前章で述べた「Code Mode と通常のツール呼び出しは実行コアを共用しており、入口が違うだけである」という理由です。

九、Codex と比較した工程上の決断の違い

核心ループの置換可能性。Codex のツールインターフェース、承認ポリシー、サンドボックス戦略はすべて設定可能ですが、「サンプリング－実行－フィードバック」という循環を駆動するコードはコアに固定されており、独立したユニットとして置き換えることはできません。DeepSeek Harness では、このループの具体的な実装（ReactLoopAgent）がファクトリとして登録されています。理論的には、全く異なる別のループ実装で置き換え可能です。現時点ではシステムに一つの実装しか紐付いておらず、ファクトリは一度だけ登録することを許可しています。

サンドボックスの位置づけ。Codex は Linux における bwrap/Landlock や macOS における Seatbelt を、コア実行パスに直接コンパイルして組み込んでおり、インフラストラクチャの一部です。一方 DeepSeek Harness では、サンドボックスを能力プラグインとして実装しています。Linux 上では独立したネイティブ Node 拡張を通じて Landlock を呼び出し、前述のサービス登録経路を踏みます。理論的には他の隔離実装に置き換え可能で、それを呼び出すツールコードに変更は不要です。

コード規模の分割粒度。Codex の Rust コードは約百個の crate に分けられていますが、DeepSeek Harness の TypeScript コードは二百以上のパッケージに分かれています。どちらもモノリスアーキテクチャではありませんが、Codex で分割されたモジュールは最終的に置き換え不可能な核心ループのために機能します。一方 DeepSeek Harness で分割されたモジュール（循環自体を含む）は、理論上すべて同じ置換可能な階層にあり、どのモジュールも特別視されることはありません。

コードオーケストレーションツールの呼び出しにおける隔離技術の選定について、両方のアプローチは独立して同じ結論に至りました。ツール呼び出しは単一の構造化リクエストだけでなく、コードによるオーケストレーションもサポートすべきです。実装時の隔離手法には違いがあり、Codex は独立した V8 isolate を採用しましたが、DeepSeek Harness は worker_threads を選択しました。この差異が裏付けるトレードオフについては第七章で詳しく解説しています。

ツールを外部に公開する粒度の違いについても触れておきます。Codex のツールインターフェースでは、DIRECT/DEFERRED/CODE_MODE/Hidden といった公開方式は、ツール側が静的なマークとして宣言します。一方 DeepSeek Harness では、あるスコープ下でツールが見えるかどうかもしくは上書きされるかは、ランタイム時にスコープチェーンをたどってリアルタイムに計算されます。つまり、同じツールでもセッションによって可視性が異なり、これはどの preset がマウントされているかに依存します。

参考：プロセス起動からツール呼び出しまでの一連のフロー

プロセスが起動すると、まず使用するプロファイル（Profile）を確認し、それに合わせて必要なプラグインパッケージをロードします。これを Cordis のローダーが順次マウントし、各プラグインは 1 つの Fiber として扱われます。セットアップ完了後、host レイヤーではモデルへの接続、認証情報の管理、サンドボックスといったランタイム基盤が準備されます。

新しいセッションが始まると、エージェント登録表から具体的なインスタンスが割り当てられ、これは「グローバル - プリセット - セッション」というスコープチェーンの下に配置されます。利用可能なツールやプロンプトは、このチェーン上の位置と、第八章で解説する遮蔽ルールによって決定されます。

セッションの運用を担うのは Agent Loop です。現在のコンテキストを読み取り、モデルへリクエストを送り、ツール呼び出しを検知して、統一されたツールパイプラインに渡します。ここでは事前チェック、実行、事後処理の一連の流れが処理されます。

プロセス中のあらゆる事象、つまりモデルからの出力やツールの結果は、すべてイベントとしてセッションログに追加されます。削除も上書きもされません。このログは、永続化の源であり、次のリクエストにおけるコンテキストの提供元であり、Web 画面での表示ソースでもあります。これら 3 つの用途は、同一のログから投影されるものです。Web 画面自体も、このアーキテクチャに属する一連のプラグインとして機能します。

この記事では、Cordis の Fiber ライフサイクルと効果の取り消しスタック、ctx. の Proxy 解析、Agent Loop 内のいくつかの詳細設計、Preset の 2 層スコープチェーン、Code Mode における隔離技術の選定、そしてツール登録における階層的遮蔽アルゴリズムなど、具体的な仕組みについて多くを語りました。これらを組み合わせることで解決されるのは、エージェント製品を開発する際や、深く活用する際に繰り返し直面するいくつかの課題です。

まず一つ目の課題は、機能追加や変更に伴うリスク管理です。一般的な手法では、コアループの外側にプラグインを追加し、コア自体はほとんど改修しません。一度改修すると影響範囲が広がり、回帰テストも再実行が必要になるためです。DeepSeek Harness では、このリスク管理の粒度をプラグインレベルまで落とし込みました。各プラグインに登録されたすべての要素は effect として登録され、アンロード時には登録時の逆順で元通りに取り消されます。機能の追加や置き換えによる影響範囲は、そのプラグイン自身の境界内に限定され、検証範囲も同様に縮小されます。

二つ目の課題は、同じエージェントサービスで異なるシナリオに対応しつつ、毎回環境を再構築する必要がないようにすることです。Preset の 2 層スコープチェーンがこれを解決します。一つのプリセットのプラグインタリーは一度だけマウントされ、ライティング、コーディング、リサーチなど用途の異なるセッション間で、すでに稼働している同一インスタンスを共有できます。論理的な親子関係テーブルによって、負荷分散と再利用が行われます。

3 つ目の課題は、多段階タスクにおけるツール呼び出しの往復コストです。Code Mode では、こうしたタスクのオーケストレーションロジックをモデル自身がコードとして記述することで、「発言して待つ」という往復回数を大幅に削減します。この点において DeepSeek Harness と Codex はほぼ同時に同じ結論に至りましたが、その分離アプローチは異なります。

4 つ目の課題はツールの可視性と権限です。多くのシナリオでは、ツールが「グローバルに利用可能」か「グローバルに利用不可」かの二択しかありません。しかし、階層化された遮蔽アルゴリズムを採用することで、可視性はランタイム時にスコープチェーンに基づいてリアルタイム計算されるものになります。これにより、同じツールでも異なるプリセットやセッションによって全く異なる可視性を示すことが可能になり、ツールコード内で多数の条件分岐を書く必要がなくなります。

これらの設計はすべて、より大きな洞察へとつながっています。つまり、エージェント製品の競争力はモデル性能だけでなく、ランタイム層の設計次第です。ランタイムをどう組織し、拡張コストはいくらになるか、コンポーネントを交換する際の代償はどの程度かといった工学的判断も、ユーザーがそのエージェントを使いこなせるかどうかを左右します。DeepSeek Harness はこの洞察に焦点を当て、Cordis という既存のプラグインフレームワークと「可逆的な副作用」という設計哲学を用いて、これを具体的なコード構造へと落とし込みました。その効果は、このアーキテクチャが実際の運用でどれほど持続可能か、より複雑なシナリオにも耐えられるかどうかにかかっています。

P.S. この記事で紹介したサンプルプラグインを実装する際、UI がクラッシュしてしまいました。HMR の安定性にはまだ改善の余地があるようです。