Background and problem definition

论文版本948a07b (main)

"A Programming Paradigm for Spatiotemporal Composability" is co-authored by Yifan Shi, Wei Zhang (Peking University) and Tianyi Cui (DeepSeek-AI, i.e. the Koishi framework author Shigma). It is a programming language theory and runtime systems paper, not a model training or model capability paper.

Agent = Model + Harness

[Paper's original conclusion §1.2.2] The paper takes Agent Runtime as one of its motivating examples: modern AI agents depend on runtime agent harnesses, systems that assemble tool suites, execution environments, permission sandboxes, session state, context memory, sub-agent workflows and UI; "future harnesses may generate and deploy modifications to their own components while continuing to serve requests".

This definition matches DeepSeek's official description of Harness exactly: Agent = Model + Harness. The Model is responsible for reasoning and decision-making; the Harness provides Tools / Skills / Sessions / Sandboxes / Storage / Loops / Sub-agent scheduling / UI through plugins. DeepSeek Harness turns all these capability domains into Cordis plugins.

Why does a long-running, self-modifying Agent need to dynamically load, unload and replace components? Because the defining trait of a self-evolving Agent is "modifying itself while running" — upgrading a tool, replacing a Skill, adjusting a sub-Agent's environment. If every modification required restarting the whole session, context and intermediate state would be lost; if it did not restart, the side effects of the old component (open connections, registered callbacks, held state) would become dangling garbage that pollutes subsequent execution. Traditional mechanisms give no answer to "how do you cleanly swap out a component that is still in use".

Why traditional plugin systems, DI and HMR are insufficient

The paper §1.2.1 takes VSCode as the canonical example:

• Temporal limitation: VSCode's extension host provides no mechanism to unload an individual extension's code at runtime; disabling or uninstalling an extension requires restarting the entire host. 87 of the top 100 extensions contain executable code, all requiring restart. The deactivate hook is only used as a graceful exit callback at process shutdown, and it separates effect disposal from effect creation (in activate), violating locality of concern.
• Spatial limitation: extensionDependencies is almost unused (only 7 of the top 100 declare it); there is no structural contract between extensions, and getExtension(...).exports returns a value of type any.

[Inference based on the paper] Traditional DI (e.g. Spring, Angular) only injects dependencies at initialization; when a provider is replaced or removed at runtime, existing dependents are neither deactivated nor reinitialized. React's useEffect pairs effect with cleanup, but hooks cannot be called inside conditions/loops/nested functions, the effect body cannot be an async function or iterator, and a composite inverse cannot be composed from existing effects. HMR (webpack, Vite) migrates state forward through import.meta.hot, relying on developers to hand-write migration functions. Software transactional memory (STM) and RAII confine reversal to a fixed, static scope. OSGi Declarative Services react to service availability, but the deactivation callback is hand-written and synchronous.

[Paper's original conclusion §1.2.3] Operating systems provide temporal composability at process granularity; container orchestrators provide spatial composability at service granularity, but these are coarse-grained substitutes: every restart discards all process-local state (caches, connections, partial computations), and rebuilding takes seconds to minutes; container-level orchestration cannot express dependencies between components sharing an address space. The paper demands a composition abstraction at the same granularity as the components themselves.

Two orthogonal dimensions

[Paper's original conclusion §1.1] The paper identifies two orthogonal dimensions of dynamic composition:

• Temporal composability (time dimension): when a component is removed, every modification it made to the shared environment must be completely and safely reverted. This requires tracking every resource allocation, event registration and state change the component performed, and guaranteeing their orderly recovery.
• Spatial composability (space dimension): components must be able to structurally and verifiably declare, discover and resolve dependencies on one another. This requires managing the dependency topology and coordinating component lifecycles when dependencies change.

[Paper's original conclusion §2.3] Effect describes "how a computation modifies the environment", and Coeffect describes "how a computation depends on the environment" — the two directions are complementary, do not conflate them. In the static setting, temporal reduces to lexical scope (RAII, the bracket pattern) and spatial reduces to module import resolution; in the dynamic setting, both become significantly harder.

The paper's solution: lift the classical effect/coeffect from compile-time static analysis to runtime mechanisms — Revertible Effects (every context transformation carries an inverse, tracked at runtime) solves temporal; Reactive Coeffects (components declare coeffect specifications; the context notifies them per spec when it changes) solves spatial. The two are unified in a single context type, constitute the component concept, and yield a dynamic composition calculus with proven metatheoretical properties.

Core concept map

Concept	Meaning	Source
Revertible Effect	Each context transformation carries an inverse, tracked at runtime	§3.1, Def 8
Reactive Coeffect	Components declare coeffect specifications; the context notifies per spec on change	§3.2.2, Def 26
Unified Context Γ∞	A single context type that recursively carries (state, accumulator, coeffect table)	§3.3.1, Def 32
Component ℭΓ	A triple (dependency spec d, provision p, effect witness function e)	§4.1, Def 43
Fiber	One instantiation of a component, carrying lifecycle state	§4.1, Def 44
Committed View ω	The currently committed dependency resolution (fiber name mapping)	§4.1, Def 44
Target View	The dependency resolution state the fiber is expected to be in	§4.2, Def 46
Isolation Realm	The same key resolves to different instances in different contexts	§3.2.3, Def 28
Interception	Not replacing a dependency, only modifying how it is used	§3.2.3, Def 30

The subsequent chapters follow this main line: Effects covers how temporal is reverted; Coeffects covers how spatial responds; Lifecycle covers how the two coordinate on a component instance; Theorems covers what this mechanism guarantees; DeepSeek Harness covers how it lands on a real Agent Runtime; Limits covers what it does not guarantee.