背景と問題定義
『A Programming Paradigm for Spatiotemporal Composability』は Yifan Shi、Wei Zhang（北京大学）と Tianyi Cui（DeepSeek-AI、すなわち Koishi フレームワーク作者 Shigma）の共著で、プログラミング言語理論とランタイムシステムに関する論文であり、モデル訓練やモデル能力に関する論文ではない。
Agent = Model + Harness
[論文原文の結論 §1.2.2] 本論文は Agent Runtime を motiving example の一つとして扱う：現代の AI agent はランタイムの agent harness に依存し、これらのシステムはツール一式、実行環境、権限サンドボックス、セッション状態、コンテキスト記憶、サブ agent ワークフロー、UI を組み合わせる。「将来の harness は、自分自身のコンポーネントに対する改変を生成してデプロイしつつ、リクエストに継続対応するだろう」。
この定義は DeepSeek 公式の Harness 記述と完全に合致する：Agent = Model + Harness。Model は推論と意思決定を担い、Harness は Tools / Skills / Sessions / Sandboxes / Storage / Loops / Sub-agent scheduling / UI をプラグイン経由で提供する。DeepSeek Harness はこれらの能力ドメインをすべて Cordis プラグインとして実装する。
なぜ長期間稼働し自己改変する Agent はコンポーネントの動的ロード、アンロード、置換を必要とするのか。自己進化 Agent の中核的特性が「実行中に自分自身を書き換える」ことだからだ——あるツールをアップグレードし、ある Skill を置き換え、あるサブ Agent の環境を調整する。毎回の改変でセッション全体を再起動すれば、コンテキストと中間状態が失われる；再起動しなければ、旧コンポーネントの副作用（開いた接続、登録したコールバック、保持した状態）は宙に浮いたゴミとなり、以降の実行を汚染する。従来の機構は「使用中のコンポーネントをきれいに置き換える方法」に答えを出していない。
従来のプラグインシステム、DI、HMR が不十分な理由
論文 §1.2.1 は VSCode を典型例として挙げる：
- Temporal limitation：VSCode の extension host は個別拡張コードをランタイムでアンロードする機構を提供しない；拡張の無効化やアンロードには host 全体の再起動が必要。トップ 100 拡張のうち 87 が実行可能コードを含み、いずれも再起動を要する。
deactivateフックはプロセス終了時のグレースフル終了コールバックとしてしか使われず、effect disposal を effect creation（activate内）から分離していて、locality of concern に違反する。 - Spatial limitation：
extensionDependenciesはほとんど使われない（トップ 100 中 7 しか宣言しない）；拡張間に構造的契約はなく、getExtension(...).exportsの戻り値はany型である。
[原文に基づく推論] 従来の DI（Spring、Angular 等）は初期化時にのみ依存を注入し、ランタイムで provider が置換・除去されても既存の dependent は停止も再初期化もされない；React の useEffect は effect と cleanup を対にするが、hook は条件/ループ/ネスト関数内で呼べず、effect body は async 関数やイテレータを受け付けず、既存の effect から複合 inverse を組み立てられない；HMR（webpack、Vite）は import.meta.hot で状態を前方移行するが、開発者による移行関数の手書きに依存する；ソフトウェアトランザクショナルメモリ（STM）や RAII は reversal を固定の静的スコープに限定する；OSGi Declarative Services はサービス可用性に反応するが、deactivation コールバックは手書きで同期的である。
[論文原文の結論 §1.2.3] OS はプロセス粒度で temporal composability を提供し、コンテナオーケストレータはサービス粒度で spatial composability を提供するが、これは粗粒度の代替物である：毎回の再起動はプロセスローカルの全状態（キャッシュ、接続、部分計算）を破棄し、再構築に数秒から数分かかる；コンテナ級のオーケストレーションは共有アドレス空間を持つコンポーネント間の依存を表現できない。本論文が求めるのはコンポーネント自体と同一粒度の合成抽象である。
二つの直交する次元
[論文原文の結論 §1.1] 本論文は動的合成の二つの直交する次元を識別する：
- Temporal composability（時間次元）：コンポーネントが除去される際、共有環境に対して行った変更は完全かつ安全にロールバックされなければならない。これはコンポーネントが行ったすべての資源割当、イベント登録、状態変更を追跡し、その順序ある回収を保証することを要求する。
- Spatial composability（空間次元）：コンポーネントは互いの依存を構造的かつ検証可能に宣言し、発見し、解決できなければならない。これは依存トポロジーを管理し、依存変化時にコンポーネントライフサイクルを調整することを要求する。
[論文原文の結論 §2.3] Effect は「計算が環境をどう変更するか」を記述し、Coeffect は「計算が環境にどう依存するか」を記述する——両者は方向が相補的で、混同してはならない。静的設定では temporal はレキシカルスコープ（RAII、bracket pattern）に、spatial はモジュール import 解決に帰着する；動的設定ではいずれも顕著に難しくなる。
論文の解法：古典的な effect/coeffect をコンパイル時の静的解析からランタイム機構へと引き上げる——Revertible Effects（すべてのコンテキスト変換が inverse を持ち、ランタイムで追跡）が temporal を解決し、Reactive Coeffects（コンポーネントが coeffect 仕様を宣言し、コンテキスト変化時に仕様に従って通知）が spatial を解決する。両者は単一の context 型に統一され、component 概念を構成し、動的合成計算体系を与え、メタ理論的性質を証明する。
中核概念の対応表
| 概念 | 意味 | 出典 |
|---|---|---|
| Revertible Effect | 各コンテキスト変換が inverse を持ち、ランタイムで追跡 | §3.1, Def 8 |
| Reactive Coeffect | コンポーネントが coeffect 仕様を宣言し、コンテキスト変化時に仕様に従って通知 | §3.2.2, Def 26 |
| Unified Context Γ∞ | 状態、累算器、coeffect 表を再帰的に運ぶ単一の context 型 | §3.3.1, Def 32 |
| Component ℭΓ | 三つ組 (依存仕様 d、提供 p、effect 証人関数 e) | §4.1, Def 43 |
| Fiber | コンポーネントの一回のインスタンス化、ライフサイクル状態を保持 | §4.1, Def 44 |
| Committed View ω | 現在コミット済みの依存解決（fiber 名の写像） | §4.1, Def 44 |
| Target View | fiber が置かれるべき依存解決状態 | §4.2, Def 46 |
| Isolation Realm | 同一 key が異なる context で異なるインスタンスに解決される | §3.2.3, Def 28 |
| Interception | 依存を置換せず、その使用方法だけを変更 | §3.2.3, Def 30 |
以降の節はこの主線に沿って展開する：Effects で temporal のロールバック、Coeffects で spatial の応答、ライフサイクル で両者がコンポーネントインスタンス上でどう協調するか、定理 でこの機構が何を保証するか、DeepSeek Harness でこれが実際の Agent Runtime にどう落ちるか、限界 で何を保証しないかを扱う。