DeepSeek Harness との関係

论文版本948a07b (main)

論文は Cordis を実装し、DeepSeek Harness は Cordis 上に構築される。ただし Cordis、Koishi、DeepSeek Harness は三つの異なるプロジェクトであり、混同してはならない。

三つのプロジェクトの関係

[原文と公式資料に基づく推論]：

• Cordis：オープンソースのメタフレームワーク（MIT）で、論文が記述する時空構成的合成性を実装する。リポジトリは github.com/cordiverse/cordis、コアパッケージ cordis の現行バージョンは 4.0.0-rc.x（論文 §5 が記述する Cordis v4 に対応）。DeepSeek から独立しており、cordiverse 組織が保守する（Shigma が中核著者）。
• Koishi：Cordis 上に構築されたオープンソースのチャットボットアプリケーションフレームワーク（MIT）。論文 §5.3 の事例研究：Koishi は現行で Cordis v3 を使用し、論文が記述するのは Cordis v4 であり、「the core compositional model is shared across both versions」。Koishi は 4000 以上のコミュニティプラグインを持ち、論文の生産事例である。
• DeepSeek Harness（DSH）：DeepSeek がオープンソース化した Agent Harness（MIT）で、Cordis コア上に構築される。リポジトリは github.com/deepseek-ai/deepseek-harness。公式ドキュメントは明示：Cordis コアがプラグインのマウント/アンロード/依存を管理し、Harness は Cordis プラグインシステムの上に構築され、「Everything is a plugin」である。

論文著者に関する注意：Tianyi Cui（DeepSeek-AI）すなわち Shigma は、Koishi フレームワークの作者である。したがって Cordis / Koishi / Harness は三者とも同源（すべて Shigma に関連）だが、論文は DeepSeek 単独の成果ではない——第一機関は北京大学、第二機関が DeepSeek-AI である。

この機構が DeepSeek Harness に適合する理由

[原文に基づく推論] DSH は Tools / Skills / Sessions / Sandboxes / Storage / Loops / Sub-agent scheduling / UI をすべて Cordis プラグインとして実装する。したがって：

1. Tool Provider のホット置換：Agent 実行中にツールを置換する（例：ファイル検索ツールのバージョンアップ）→ Cordis は旧 fiber をアンロードし、新 fiber をインストールし、そのツールに依存する Session やサブ Agent は自動的に再解決される。全体は Ordering 定理 により保証される：旧 provider は consumer の後にアンロードされ、「解放済みのツールを使い続ける」ことは起きない。
2. サブ Agent の独立環境：各サブ Agent は ctx.isolate で独立コンテキストを派生し、同じ key（例：'filesystem'）が異なるサブ Agent で異なるインスタンスに解決される。サブ Agent 同士は互いに汚染せず、親 Agent はサブ Agent ごとに異なる realm を適用できる。
3. Sandbox 権限制御：ctx.intercept でコミュニティプラグインに厳格なアクセス方針（例：読み取り専用ファイルシステム）を適用し、プラグインコードを修正せずに能力を制限する。
4. Trajectory 追跡：DSH の append-only セッションログと Cordis の effect accumulator は精神的に一致する——どちらも「再再生可能な実行軌跡」である。ただし区別が必要：DSH のセッションログは emission（§6.1）レベルの記録であり、自動ではロールバックできない；Cordis の accumulator は acquisition レベルであり、自動で回復可能。前者は「何が起きたか」のログ、後者は「起きた副作用をどうロールバックするか」の逆操作チェーンである。

DeepSeek Harness の現状

[公式資料に基づく確認、2026-08-15] 現在時点で、DSH はまだ Developer Preview であり、コアプラグインと API は引き続き進化する。公式は明示：「core plugins and APIs are expected to continue evolving」。

四つの実行モード：

• Standard：完全なコーディング Agent で、全ツールセットを公開；
• Code：Code Mode SDK を公開し、モデルが TypeScript を生成してツール呼び出しを編成；
• Minimal：bash + str_replace_editor の二つのツールのみ、ベンチマーク用；
• Creator：カスタム preset を構築し、ランタイムを検査し、プラグインをテストし、preset を記述可能。

Trajectory view は resume / fork / search / replay をサポートし、いずれも append-only セッションログに基づく——これは論文 §1.2.2 の自己進化 Agent harness の記述（フォーク可能、再再生可能、継続的にリクエストに対応）と呼応する。

他の Agent Runtime への示唆

[個人評価] このアーキテクチャが DeepSeek Harness、Claude Code、Codex、OpenClaw などの Agent Runtime にもたらす示唆：

• Tool のホット置換：Agent 実行中にツールを置換し、セッションを再起動しない；
• サブ Agent の隔離：ctx.isolate が各サブ Agent に独立した依存ビューを与える；
• 能力宣言イコール権限：fiber.inject はすなわち capability 要求リストであり、ロード時に監査可能；
• Trajectory = Emission：append-only セッションログは emission（§6.1）であり、自動ではロールバックできない；resume/fork/replay を支えるには emission 層の補償設計が依然として必要；
• 信頼できないプラグイン：プロセス/コンテナ/WASM サンドボックスが依然として必要であり、Cordis は言語レベルの隔離しか提供しない。

ただし注意：論文は Cordis v4 の理論モデルであり、DeepSeek Harness は Cordis 上に構築された Developer Preview のプロダクトである。両者の関係は「DSH は Cordis 上に構築され、Cordis が論文モデルを実装する」であり、「DSH が論文のすべての結論をすでに証明した」ではない。 限界と証拠の強さ を参照。