A Programming Paradigm for Spatiotemporal Composab
前言
DeepSeek Harness 最近发布了，随它一起发布的其实还有一篇长达88页的论文《A Programming Paradigm for Spatiotemporal Composability》
链接：paper/paper.pdf at main · cordiverse/paper
作者来自北京大学和 DeepSeek，88页的论文，其中形式化验证占了很多的比重，跑去这些验证和数学公式，论文想表达的东西不算复杂，从摘要中就能看出来。
总结来说，论文提出了一种新的编程范式，旨在解决现代软件系统中动态组合（Dynamic Composition）所面临的挑战。
什么是动态组合（Dynamic Composition）：
既然论文是要解决动态组合的问题，我们先来理解一下什么是动态组合。
动态组合的两个正交维度：
- 时间可组合性（Temporal composability）：当移除一个组件时，其产生的所有副作用（如资源分配、状态修改）必须能够被完全且安全地撤销。
- 空间可组合性（Spatial composability）：组件之间必须能够声明、发现和解决彼此间的依赖关系，并且这种依赖关系管理必须是结构化的、可验证的。
论文还举出了一个例子，在VSCode中，存在时间限制和空间限制。
-
时间限制（Temporal limitation）：VSCode所有扩展都在一个名为“扩展宿主”的共享进程中运行。这意味着所有扩展的内存、状态、事件监听（如
onDidChangeTextDocument、onDidSaveTextDocument等）都混在一起，共享同一个进程空间。也就是说，你可以安装一个新扩展而不重启，但卸载或禁用一个扩展时，必须重启整个宿主进程。 -
空间限制（Spatial limitation）：VSCode 虽提供了
extensionDependencies字段来声明扩展之间的依赖关系，但实际使用很少。在安装量前 100 的扩展中，只有 7 个 声明了对非内置扩展的依赖。扩展 API 只暴露了固定的、表面层次的扩展点（如命令、视图、语言功能）。扩展通过这些点与宿主（VSCode）交互，而不是彼此直接依赖，因此跨扩展的依赖关系很少自然产生。本质上，VSCode 的设计倾向于让扩展通过宿主提供的固定扩展点来贡献功能，而不是让扩展之间相互依赖，并且缺乏安全、结构化的方式来实现这种依赖。
这篇论文提到这个限制并非VSCode所独有，它们普遍存在于各类插件系统中。
动态可组合性的两个维度分别涉及计算如何修改环境以及它们如何依赖环境。
效应系统（Effect Systems）和 共效应系统（Coeffect Systems）
论文开头通过动态组合描述了当前的问题是什么，之后的内容通过效应形式化验证解决问题。
通过将效应提升为可逆的运行时模型，将共效应转化为响应式依赖解析机制，为动态可组合性建立了一个统一的形式化基础。
什么是效应系统和共效应系统？
-
效应系统（Effect Systems）：效应系统是对计算可能产生的副作用进行形式化描述和分析的框架。在类型系统中，一个标准的 typing judgment 是
Γ ⊢ t : T，表示在上下文 Γ 下，项 t 有类型 T。效应系统将类型细化为Γ ⊢ t : T_effect，其中结果类型被一个效应代数的元注释，描述了计算可能产生的副作用。经典效应系统是静态分析工具，用于编译时推理，不适用于运行时组件的动态到来和离去。 -
### 共效应系统（Coeffect Systems）:与效应系统相对，共效应系统关注的是计算对环境的要求。其 typing judgment 形式为
Γ_coeffect ⊢ t : T，即上下文被一个共效应代数的元注释，描述了计算需要从其环境中获取什么资源、权限或服务。同样，经典共效应系统是静态分析工具，在编译时验证依赖关系，无法处理运行时依赖的出现、消失或变更。
与动态可组合性的关系
论文将这两个概念与动态可组合性的两个维度精准对应：
- 时间可组合性 → 效应：因为组件对环境的修改（副作用）需要可撤销。撤销需要逆操作，这对应了效应系统中的“可逆效应”。
- 空间可组合性 → 共效应：因为组件间的依赖关系正是“对环境的要求”，需要声明并被管理和满足。
核心创新：论文的贡献在于将静态的效应和共效应系统“提升”为运行时机制，从而能在组件动态组合的场景中实时保证可追踪性和可撤销性，这就是论文提出的“可逆效应”和“反应式共效应”。
Cordis
论文以上内容介绍了论文要解决什么问题，并且中间通过大量的形式化验证证明了将静态的效应和共效应系统“提升”为运行时机制的正确性后，抛出了Cordis框架，该框架实现了论文中提出的理念 。
Cordis是什么
Cordis是一个关于时空组合性的元框架，它提供了一个包含效应追踪和共效应解析的核心库，以及一个具备配置同步和热模块替换功能的声明式组件加载器。与针对特定领域的应用框架（如Web路由、ORM、UI渲染）不同，它并不规定具体场景；其唯一职责是提供通用的动态组合语义。让其他框架（如DeepSeek Harness）可以在此基础上构建其特定功能。
Cordis的架构
Cordis的实现分为三个层次：核心库（Core Library）、组件加载器（Component Loader）、应用框架（Application frameworks）
核心库（Core Library）
-
效应追踪（Effect Tracking） ：实现了可逆效应。任何通过Cordis上下文进行的操作（如写入依赖、注册回调）都会被自动追踪，并生成一个对应的逆操作（
dispose函数）。当组件被卸载时，这些逆操作会被自动执行，从而安全、完整地撤销该组件产生的所有副作用，实现时间可组合性。 -
共效应操作（Coeffect Operations） ：实现了反应式共效应。组件通过
ctx.set和ctx.get声明其提供的和需要的依赖。当依赖关系发生变化时（如某个服务被卸载），Cordis会自动通知相关组件，并触发其激活或停用（不是简单的错误），实现空间可组合性。 -
组件生命周期（Component Lifecycle） ：维护了组件从加载、激活、卸载到休眠的完整状态机，并处理了异步操作和失败情况。
组件加载器（Component Loader） ：
- 声明式配置（Declarative Configuration） ：允许用户通过配置文件（如YAML或JSON）声明一个“组件树”，而无需手动编写加载和卸载的代码。
- 增量协调（Reconciliation） ：当配置发生变化时，只更新有变动的部分，而不是卸载整个组件树再重新加载。
- 热模块替换（HMR） ：支持在开发过程中，当代码文件修改保存后，只替换修改部分，而不需要重启整个应用，并保持缓存和连接状态。
应用框架（Application frameworks）
应用框架引入了开发者真正关心的领域概念和业务逻辑（如聊天机器人中的消息处理、适配器管理、数据库驱动等），将 Cordis 的通用能力转化为具体的、可用的工具。
总结
简单来说，Cordis的作用是让“组件”像USB设备一样，可以安全、热插拔地接入和拔出一个运行中的系统。
它解决了：
- “拔掉”时，如何清理干净内存和状态（时间可组合性） ：通过自动追踪和撤销副作用。
- “插入”时，如何自动发现并连接需要的服务（空间可组合性） ：通过声明式依赖和自动化的反应式激活/停用机制。
它提供了一个脱离了特定语言和领域的、形式化保证的、可工程化的解决方案，从根本上解决了动态组件组合这一难题。
论文和DeepSeek Harness 有什么关系
DeepSeek Harness的核心设计理念是 Everything is Plugin，也就是万物皆插件。
论文中提到了：
“A future harness may generate and deploy modifications to its own components while continuously serving requests. Model-synthesized reusable tools provide a narrower precursor to component-level self-modification. Each such modification is itself an instance of dynamic composition.”
也就是一个未来的Agent框架，应该能够在持续服务请求的同时，生成并部署对其自身组件的修改。 这正是“Everything is Plugin”的核心理念——框架的每一个功能、每一个工具、每一个模块，都应该是一个可以动态加载、卸载、替换的插件。
论文为 DeepSeek Harness 提供理论基础
DeepSeek Harness 仓库根 AGENTS.md 第一句就写明："DeepSeek Harness is a plugin-based agent harness on vendored Cordis: everything is a plugin"——整个 Harness 的一切能力（session、工具、agent-loop、fs、shell、web、skill、subagent、workflow、todo 等）都是以 Cordis 插件形式实现的。
一切皆插件
DeepSeek Harness 的模型适配器（llm/）、工具注册表（core/tools）、会话日志（core/session）、agent-loop 本身（core/agent-loop）都是插件。连 Web GUI（packages/client/*）、宿主/客户端 runner（packages/extensions/*）也是。这与论文"系统由可组合的插件构成、无特权核心"的论述一致。
效应可逆
所有插件注册的东西（工具、监听器、服务）都走"可逆注册"机制——插件一卸载，它注册的一切自动按序回滚。这正是 HMR 热重载能安全工作的原因：改个配置文件，旧插件撤掉、新插件换上，系统不停机、不残留垃圾。
运行中自我重组
self-modification 包让 AI 智能体在运行中检查、挂载、修改自己的插件——AI 可以给自己加新工具、换新配置。官网还有一个演示就叫 demo:cordis（"the agent modifies its own runtime"，智能体修改自己的运行时）。
总结
《A Programming Paradigm for Spatiotemporal Composability》提出的"一切皆插件、注册可逆、运行中可重组"的编程范式，通过 Cordis 框架被 DeepSeek Harness 完整继承并产品化：Harness 官方 README 明确声明其底层由该论文描述的 Cordis 驱动，仓库内所有能力（包括 AI 思考循环本身）都以插件形式实现，支持热插拔、失败回滚，乃至智能体在运行中修改自己的插件。因此，这篇论文不仅是 Cordis 的设计蓝本，也是 DeepSeek Harness 名副其实的理论基础——它决定了 Harness 最根本的架构形态。
