Cordis 时空可组合性编程范式 --- 三段式精读笔记（一）
摘要 / 第1章 引言 / 第2章 预备知识
本文档采用三段式结构：每节先给出英文原文，再给出中文翻译，最后给出详细解释说明。
原论文: "A Programming Paradigm for Spatiotemporal Composability" (Yifan Shi, Wei Zhang, Tianyi Cui, DeepSeek-AI, 2026)
Abstract / 摘要
原文 (English)
Modern software---from plugin systems to self-evolving agent harnesses---increasingly requires dynamic composition, yet its formal foundations remain underdeveloped. We identify two orthogonal dimensions of the problem: temporal composability, the ability to completely revert a component's side effects upon removal, and spatial composability, the ability to declare and reactively manage inter-component dependencies. We address the two dimensions by lifting classical effect and coeffect concepts to runtime mechanisms. In particular, we formalize revertible effects, in which every context transformation carries an inverse that the runtime tracks. We formalize reactive coeffects, in which each change of the context notifies a component against its coeffect specification. We unify the effect context and the coeffect context into a single context type, which constitutes a programming paradigm. After that, we combine these mechanisms into the notion of a component and give a calculus of dynamic composition, whose metatheory carries spatiotemporal composability from a single component to a whole system of interleaved components. We implement these ideas in Cordis, a meta-framework of spatiotemporal composability that provides a core library with effect tracking and coeffect resolution, as well as a declarative component loader with configuration reconciliation and hot module replacement.
中文翻译
现代软件------从插件系统到自演化(self-evolving)的 agent harness------越来越需要动态组合(dynamic composition)，然而其形式化基础仍不成熟。我们识别出该问题的两个正交维度：时间可组合性(temporal composability)，即在移除组件时能够完全撤销其副作用(side effects)的能力；以及空间可组合性(spatial composability)，即能够声明并响应式地管理组件间依赖关系(inter-component dependencies)的能力。我们通过将经典的效应(effect)与协效应(coeffect)概念提升(lift)为运行时机制来处理这两个维度。具体而言，我们将可逆效应(revertible effects)形式化：每一次上下文变换(context transformation)都携带一个逆(inverse)，由运行时跟踪。我们将响应式协效应(reactive coeffects)形式化：上下文的每一次变化都依据组件的协效应规约(coeffect specification)通知该组件。我们将效应上下文与协效应上下文统一为单一的上下文类型(context type)，这便构成了一种编程范式(programming paradigm)。随后，我们将这些机制组合进"组件(component)"的概念，并给出一个动态组合演算(calculus of dynamic composition)，其元理论(metatheory)将时空可组合性从单一组件推广到一整由交错(interleaved)组件构成的系统。我们在 Cordis 中实现了这些想法------这是一个时空可组合性的元框架(meta-framework)，提供了一个带有效应跟踪(effect tracking)与协效应解析(coeffect resolution)的核心库，以及一个带有配置调和(configuration reconciliation)与热模块替换(hot module replacement)的声明式组件加载器(declarative component loader)。
详细解释
这段摘要用最凝练的方式交代了整篇论文的"问题---方法---理论---实现"四步逻辑。首先点出问题背景：今天的软件已经从"一次性写好、编译期就定型"走向了"运行时还在不断加载、卸载、改造自己"的动态组合阶段------典型的两个例子就是 IDE 的插件生态和能够自我修改的 AI agent harness（比如 DeepSeek Harness 这种在运行中加载工具、加载 skill、动态装拆子系统的系统）。然而，与静态组合那套成熟的形式化体系（类型系统、模块系统）相比，动态组合几乎没有像样的理论基础，工程师只能靠"重启进程"这种粗暴手段。
接着，论文把"动态组合"这个含糊的工程难题拆成了两个彼此独立、可以分别攻克的维度：时间维度 管的是"组件走了之后，它留下的痕迹能不能干干净净地擦掉"；空间维度管的是"组件和组件之间谁依赖谁、谁要先在谁才能工作，这个依赖图能不能被声明出来并在变化时自动响应"。这两者正交，意味着你可以单独地、各自完整地处理它们，这为后面的形式化扫清了道路。
方法上的核心创见是"把经典的 effect/coeffect 理论从编译期静态分析提升为运行时机制"。effect（效应）在类型论里描述"计算会对环境做什么改变"，coeffect（协效应，effect 的对偶）描述"计算从环境那里要求什么"。论文把"效应"运行时化得到"可逆效应"------每一次对共享上下文的改动都附带一个"撤销操作"，运行时记下来，组件卸载时就逐条回放撤销；把"协效应"运行时化得到"响应式协效应"------组件声明自己需要什么，运行时在上下文变化时对照这份规约通知组件"你现在被激活/失活/无影响"。最后再把这两套机制塞进同一个上下文类型里，配上一套演算，并在 Cordis 这个元框架里实现。这条脉络是后面所有章节的主轴，理解了它就读懂了全文。
1. Introduction / 第1章 引言（开篇）
原文 (English)
Composition---assembling complex systems from simpler parts---is a foundational principle of software engineering 1. Traditionally, composition is static: function calls, module imports, and class inheritance are resolved at compile time and remain fixed throughout execution. However, modern software increasingly demands dynamic composition, where components are loaded, unloaded, and reconfigured at runtime. Plugin architectures 2 and self-evolving agent harnesses both require systems that can safely add and remove functionality on the fly, yet current practice defers to coarse-grained mechanisms 3 that reconfigure only by restarting, discarding runtime state. Despite the growing practical importance of dynamic composition, its theoretical foundations remain underdeveloped, compared to the rich formal frameworks available for static composition.
中文翻译
组合(composition)------即用更简单的部分拼装出复杂系统------是软件工程的一条基础原则 1。传统上，组合是静态的：函数调用、模块导入(module imports)和类继承(class inheritance)在编译期就被解析，并在整个执行过程中保持固定。然而，现代软件越来越需要动态组合(dynamic composition)，即组件在运行时被加载、卸载和重新配置。插件架构(plugin architectures)2 和自演化的 agent harness 都要求系统能够在运行中安全地增加和移除功能，但当前实践却诉诸粗粒度机制(coarse-grained mechanisms)3------只能通过重启来重新配置，并丢弃运行时状态。尽管动态组合的实际重要性日益增长，但与静态组合所拥有的丰富形式化框架相比，其理论基础仍不成熟。
详细解释
这一段为全文定调：它先把"组合"抬到软件工程第一性原理的高度------一切复杂系统都是拼出来的，这没有争议。然后划出一条时代分界线：过去的组合是静态 的，函数调用、import、继承在编译那一刻就钉死了，程序跑起来之后结构不再变化，这一套有极其成熟的类型论和模块论支撑。但今天的软件已经越过了这条线，进入动态组合：组件要在运行中装上去、拆下来、重新配置。
论文立刻举出两类刚需场景：插件架构（VSCode 这类）和自演化 agent harness（能自己改自己的 AI 运行时）。这里的痛点描述非常精准------目前的"最佳实践"其实是退而求其次的粗粒度变通：出了问题就重启整个进程，重启就意味着把进程内积累的状态（缓存、连接、进行到一半的计算）全部丢掉。这是一种"用粒度换正确性"的妥协，它之所以能容忍，是因为我们还没有更细粒度的、有理论保证的替代方案。
最后一句点出全文的学术定位：动态组合在工程上已经火烧眉毛，但在理论上几乎是空白------这正是这篇论文要填补的缝隙。这种"工程已经很成熟、理论却跟不上"的张力，是整篇论文的动机原点，也解释了为什么作者要花大力气做形式化而不只是再写一个工程框架。
1.1 Dimensions of Composability / 1.1 可组合性的维度
原文 (English)
To characterize the requirements of dynamic composition, we identify two orthogonal dimensions beyond the well-studied algebraic aspects of composition:
• Temporal composability addresses the time dimension: upon removal of a component, the modifications the component made to the shared environment must be completely and safely reversed. This requires tracking every resource allocation, event registration, and state mutation the component performs, and guaranteeing their orderly reclamation upon removal.
• Spatial composability addresses the space dimension: components must be able to declare, discover, and resolve their dependencies on one another in a structured and verifiable manner. This requires managing dependency topology and coordinating component lifecycles in response to dependency changes.
In the static setting, temporal composability reduces to lexical scoping (e.g., RAII 4, bracket patterns 5), and spatial composability reduces to module import resolution 6. In the dynamic setting, where components arrive and depart at runtime, both dimensions become significantly harder: temporal composability must handle long-lived, stateful effects whose scope is not lexically bounded; and spatial composability must handle dependencies that appear, disappear, or change identity during execution.
中文翻译
为了刻画动态组合的需求，我们在已被充分研究的组合的代数层面(algebraic aspects)之外，识别出两个正交的(orthogonal)维度：
• 时间可组合性(temporal composability)针对时间维度：当一个组件被移除时，它对共享环境(shared environment)所做的修改必须被完全且安全地逆转(reversed)。这要求跟踪该组件执行的每一次资源分配(resource allocation)、事件注册(event registration)和状态突变(state mutation)，并保证在移除时有序地回收(reclamation)它们。
• 空间可组合性(spatial composability)针对空间维度：组件必须能够以结构化且可验证的方式，声明(declare)、发现(discover)并解析(resolve)它们彼此之间的依赖。这要求管理依赖拓扑(dependency topology)，并依据依赖变化协调组件的生命周期(lifecycles)。
在静态设定下，时间可组合性退化为词法作用域(lexical scoping)（如 RAII 4、bracket 模式 5），空间可组合性退化为模块导入解析(module import resolution)6。而在组件于运行时到来与离去的动态设定下，两个维度都显著变难：时间可组合性必须处理那些作用域不被词法限定的、长存且带状态的效应(long-lived, stateful effects)；空间可组合性则必须处理那些在执行过程中出现、消失或改变身份(identity)的依赖。
详细解释
这一节是全文的概念地基，提出了贯穿全篇的两个关键词：时间可组合性 和空间可组合性。它先声明这两个维度是"正交"的------这是一个很强的性质，意味着它们在逻辑上互相独立，可以分别定义、分别证明，而不会彼此牵扯，这为后面把两套机制"统一进一个上下文类型"埋下了伏笔。
时间可组合性 讲的是"撤销"问题。一个组件活着的时候会往共享环境里"写"东西：开了一块内存、注册了一个事件监听器、改了一个全局状态。当这个组件被卸载时，它写的这些痕迹必须被完整且安全地抹掉，不能留垃圾、不能影响还活着的其他组件。这要求运行时像记账一样把每一笔"改动"都记下来，并在卸载时按相反顺序逐笔回收。用一个生活类比：就像你租了一间办公室，入住时挂的画、接的网线、注册的快递地址，退租时必须全部复原，房东才能把干干净净的办公室交给下一个租客。
空间可组合性 讲的是"依赖"问题。组件之间谁需要谁，必须能被声明 出来、被发现 、被解析，而且这个过程要是结构化、可验证的------也就是说依赖关系不是埋在代码角落里靠人脑追踪，而是有明确的契约，系统能自动检查"你要的 A 我有没有、版本对不对"。当依赖发生变化时（比如 A 被换成了 A'），依赖 A 的组件要能被协调地响应。
最后一段的对比非常关键：它告诉我们这两个维度在静态世界里其实早就有现成的、便宜的解法------时间维度靠词法作用域（C++ 的 RAII：对象出作用域自动析构；Haskell 的 bracket：配套 acquire/release），空间维度靠模块导入（编译期就解析好 import 图）。问题在于，一旦组件是运行时才到来和离去的，这两套静态机制就双双失灵：一个插件在部署之后才被加载，它的作用域无法被任何词法结构框住；一个运行时配置产生的依赖，没有任何编译期上下文能预见到。正是这个"从静态到动态"的跃迁，把原本免费的可组合性变成了一个需要重新发明的难题。这也是为什么论文要"提升"effect/coeffect------因为静态的词法手段已经不够用了。
1.2.1 Plugin Systems / 1.2.1 插件系统（以 VSCode 为例）
原文 (English)
Plugin systems are a canonical instance of dynamic composition. We use Visual Studio Code (VSCode), one of the most widely-used extensible IDEs, as a representative example.
Temporal limitation. VSCode runs all extensions in a shared process called the extension host. Although extensions can be installed dynamically, this host provides no mechanism to unload an individual extension's code at runtime. Once an extension's activate function has executed, disabling or uninstalling it requires restarting the entire host, affecting all loaded extensions. Purely declarative extensions such as themes, keybindings, and snippets carry no code and can be removed freely. Among the top 100 extensions by install count, however, 87 contain executable code 1 and will therefore require such a restart upon removal. Although VSCode provides a deactivate hook, it serves only as a graceful shutdown callback during the host process' termination, and thus does not enable live removal. Moreover, the hook separates effect disposal from effect creation (in activate), violating locality of concern and making complete cleanup difficult to verify.
Spatial limitation. VSCode does provide extensionDependencies for declaring dependencies between extensions, but it sees little use: among the top 100 extensions by install count, only 7 declare extensionDependencies on non-built-in extensions. 1 This scarcity reflects the shape of the extension API, which exposes fixed, surface-level extension points such as commands, views, and language features. Extensions contribute to the host through these points rather than depending on one another, so inter-extension dependencies rarely arise. Moreover, VSCode's mechanism for inter-extension interaction provides no structural contract: it exposes an extension's functionality to others through vscode.extensions.getExtension(...).exports, but the returned value is untyped (any by default), so the dependent cannot rely on a checked interface. In short, VSCode steers extensions toward a fixed set of host-provided extension points, and offers no safe, structured way for them to depend on one another.
These two limitations are not unique to VSCode; they recur across plugin systems generally 2, 7, differing only in degree.
中文翻译
插件系统是动态组合的一个典型实例(canonical instance)。我们以 Visual Studio Code（VSCode）------最广泛使用的可扩展 IDE 之一------作为代表性例子。
时间上的局限(temporal limitation)。VSCode 在一个名为扩展宿主(extension host)的共享进程中运行所有扩展。虽然扩展可以被动态安装，但这个宿主没有提供任何在运行时卸载单个扩展代码的机制。一旦某个扩展的 activate 函数执行完毕，禁用或卸载它就需要重启整个宿主，从而影响所有已加载的扩展。纯声明式的扩展(declarative extensions)------如主题、快捷键和代码片段------不携带任何代码，可以自由移除。然而，在按安装量排名的前 100 个扩展中，有 87 个包含可执行代码 1，因此在移除时都需要这样的重启。尽管 VSCode 提供了一个 deactivate 钩子(hook)，但它仅仅充当宿主进程终止期间的一个优雅关闭回调(graceful shutdown callback)，因而无法实现实时移除(live removal)。而且，该钩子把效应的清理(effect disposal)与效应的创建(effect creation，在 activate 中)分离开来，违反了关注点局部性(locality of concern)，使得完整清理难以被验证。
空间上的局限(spatial limitation)。VSCode 确实提供了 extensionDependencies 用于声明扩展之间的依赖，但它几乎无人使用：在按安装量排名的前 100 个扩展中，只有 7 个对非内建扩展声明了 extensionDependencies。1 这种稀少反映了扩展 API 的形态(shape)：它暴露的是固定的、表层级的扩展点(extension points)，如命令(commands)、视图(views)和语言特性(language features)。扩展是通过这些点向宿主贡献功能，而不是彼此依赖，因此扩展之间的依赖很少产生。此外，VSCode 用于扩展间交互的机制不提供结构性契约(structural contract)：它通过 vscode.extensions.getExtension(...).exports 把一个扩展的功能暴露给其他扩展，但返回的值是无类型的(untyped，默认为 any)，因此依赖方无法依赖一个经过检查的接口(checked interface)。简而言之，VSCode 把扩展引向一组由宿主提供的固定扩展点，却没有为它们彼此依赖提供任何安全、结构化的方式。
这两个局限并非 VSCode 独有；它们普遍地复现于各类插件系统 2, 7 之中，只是程度不同。
详细解释
这一节用 VSCode 这个最接地气的真实系统，把上一节抽象的"时间/空间"两个维度落到具体的工程痛点上，让读者立刻感受到问题不是纸上谈兵。
时间维度的痛点 用一个硬数据点明：前 100 大扩展里有 87 个带可执行代码，而这些代码一旦在 activate 里跑起来，就再也"收不回来"------VSCode 的扩展宿主根本不支持卸载单个扩展的代码，唯一的办法是重启整个宿主，把所有扩展一起牵连。这里有一个关键的工程观察：VSCode 提供了 deactivate 钩子，听起来像是"卸载时回调"，但它实际上只是进程关闭时的优雅退出回调，根本不是"热卸载"机制。更深的批评在于：deactivate 这个钩子把"创建副作用"（在 activate 里注册的监听器、分配的资源）和"清理副作用"（在 deactivate 里释放）放在了两个分离的地方 ，违反了"关注点局部性"。这恰恰是 Cordis 要解决的：它要求每一次效应创建都就地附带一个逆操作，由运行时跟踪，而不是让开发者另写一个配对的清理函数------后者几乎不可能保证"恰好完整地抵消"。
空间维度的痛点 则揭示了 VSCode 的架构哲学问题：它的扩展 API 是"辐射型"的------所有扩展都往宿主提供的一组固定扩展点（命令、视图、语言特性）上贡献，而不是"网状"地彼此依赖。结果是 extensionDependencies 这个本该表达依赖的字段几乎没人用（前 100 大里只有 7 个）。即便有人想用扩展间交互，getExtension(...).exports 返回的也是 any 类型------没有接口契约、没有编译期检查，依赖方根本不敢相信对方导出的东西长什么样。这意味着 VSCode 实质上放弃了"扩展之间结构化依赖"这件事。用类比来说：VSCode 把所有插件都设计成只和"总部"（宿主）打交道，禁止插件之间直接签合同，于是插件之间一旦有协作需求，只能靠口头约定（any 类型），出了问题没人负责。Cordis 的协效应机制正是要补上这张缺失的"组件间合同"。
最后一句"这两个局限并非 VSCode 独有"很重要：它把 VSCode 从"被批评的个例"提升为"整个插件生态普遍现象的代表"，论证了论文要解决的是一个普遍性问题而非特定于某个产品的 bug。
1.2.2 Self-Evolving Agent Harnesses / 1.2.2 自演化的 Agent Harness
原文 (English)
Modern AI agents rely on runtime agent harnesses 8--10. These systems may compose diverse tool suites 11 and execution environments, govern permissions and sandboxing, maintain session state and persistence, provide context management and memory systems 12, orchestrate subagents and multi-agent workflows 13, and expose interfaces to users and automation. 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 14. Each such modification is itself an instance of dynamic composition.
Because these modifications occur continuously and with limited or no human oversight, dynamic composability becomes indispensable. Without temporal composability, each self-modification forces a full restart that discards all process-local accumulated state; at such frequency the cumulative unavailability becomes substantial, and in-flight tasks are disrupted repeatedly; even worse, a faulty self-modification can disable the very process needed to recover. Without spatial composability, each module must itself detect and adapt to changes in the modules it depends on as they appear, disappear, or change identity, and can do so only by ad hoc means; even worse, a naive code-replacement strategy may silently break dependents or introduce circular dependencies that surface only at reload time.
中文翻译
现代 AI agent 依赖运行时的 agent harness（运行时框架）8--10。这些系统可能组合多种多样的工具套件(tool suites)11 和执行环境(execution environments)、管理权限与沙箱(sandboxing)、维护会话状态与会话持久化(persistence)、提供上下文管理与记忆系统(memory systems)12、编排子 agent(subagents)与多 agent 工作流(multi-agent workflows)13，并向用户和自动化暴露接口。未来的 harness 可能会在持续服务请求的同时，生成并部署对其自身组件的修改。模型合成的可复用工具(model-synthesized reusable tools)为组件级的自我修改(component-level self-modification)提供了一个更窄的前身(precursor)14。每一次这样的修改，本身就是动态组合的一个实例。
由于这些修改持续不断地发生，且人类监督有限甚至完全没有，动态可组合性便变得不可或缺。没有时间可组合性，每一次自我修改都会迫使一次完全重启，从而丢弃所有进程本地积累的状态(process-local accumulated state)；在如此高的频率下，累积的不可用时间(cumulative unavailability)会变得相当可观，且进行中的任务(in-flight tasks)会被反复打断；更糟的是，一次有缺陷的自我修改可能恰恰使恢复所需的那整个进程瘫痪。没有空间可组合性，每一个模块就必须自己去检测并适应它所依赖的模块所发生的变化------这些模块出现、消失或改变身份------而且只能用临时性的(ad hoc)手段来做到；更糟的是，一种天真的代码替换策略(code-replacement strategy)可能悄悄地破坏依赖方，或者引入只在重载时才暴露的循环依赖(circular dependencies)。
详细解释
这一节把镜头从传统的 IDE 插件转向了作者自己所在的领域------AI agent harness，这也是这篇论文从 DeepSeek-AI 出来的直接动机。它先描绘了现代 agent harness 的复杂全貌：工具套件、执行环境、权限沙箱、会话状态、上下文与记忆、子 agent 编排、对外接口------这几乎就是 DeepSeek Harness 这类系统的功能清单。然后点出一个近未来的图景：harness 会在持续服务的同时，自己生成并部署对自己组件的修改。这比 VSCode 插件更进一步------插件还是人写的、人装的；而自演化 harness 是 agent 自己改自己，修改频率高、且往往没有人在旁边盯着。
这段的精彩之处在于它把"没有时间/空间可组合性"的后果推到了极端，从而论证这两个维度对 agent harness 是生死攸关而非锦上添花：
时间维度失效时，每一次自我修改都要重启，而自演化 harness 的修改是高频且持续的------重启成本不再是偶发的不便，而是累积的停机时间，进行中的任务（一个正在跑的多步 agent 任务）会被反复打断。最致命的是最后那句：一次写坏的自我修改，可能恰恰把"用来恢复的那套进程"也搞挂了------也就是说，系统会失去自我修复的能力，陷入"自己把自己锁死"的死局。这正是动态组合里"撤销能力"为什么必须内建、而不能依赖外部重启的根本原因。
空间维度失效时，每个模块都得自己手写"感知依赖变化、做适配"的逻辑，而且只能用临时手段（ad hoc）------这相当于让每个开发者各自发明一套依赖管理，结果一定是漏洞百出。更隐蔽的危险是天真的代码替换：你以为把模块 A 换成 A' 就行了，却没发现 B 依赖 A，A' 的接口变了，B 在运行时悄悄崩掉；或者替换顺序不当引入了 A→B→A 的循环依赖，而这只在重载那一刻才暴露出来。Cordis 的响应式协效应就是要让这些"该被运行时管的事"由运行时统一管起来，而不是甩给每个模块自己 ad hoc 处理。
1.2.3 The Coarse-Grained Workaround / 1.2.3 粗粒度的变通
原文 (English)
One reason dynamic composability has received limited formal attention is that operating systems and container orchestrators already provide a coarse-grained substitute. Operating systems yield temporal composability at the granularity of a process; container orchestrators 3 yield spatial composability at the granularity of a service. In practice, most software tolerates the lack of fine-grained composability by deferring to these coarse-grained mechanisms: a misbehaving module is handled by restarting the process, and a service dependency is managed by the container orchestrator.
However, this workaround imposes substantial costs. Temporally, each restart discards all process-local accumulated state (e.g., caches, connections, partial computations), and rebuilding it takes seconds to minutes 15; maintaining availability in the interim requires redundant replicas, incuring resource overhead to compensate for the inability to recover a single component. Spatially, container-level orchestration cannot express dependencies between components sharing an address space, and introduces network overhead for interactions that could be local function calls. Both mechanisms operate at the boundary of processes and containers, yet modern systems increasingly compose at a finer level. This granularity mismatch demands a compositional abstraction that manages effects and dependencies at the same level as the components themselves.
中文翻译
动态可组合性之所以受到的形式化关注有限，一个原因是操作系统和容器编排器(container orchestrators)已经提供了一个粗粒度的替代品。操作系统在进程(process)的粒度上提供时间可组合性；容器编排器 3 在服务(service)的粒度上提供空间可组合性。在实践中，大多数软件通过诉诸这些粗粒度机制来容忍细粒度可组合性的缺失：一个行为不端的模块靠重启进程来处理，一个服务依赖则由容器编排器来管理。
然而，这种变通要付出相当大的代价。在时间上，每一次重启都会丢弃所有进程本地积累的状态（例如缓存、连接、进行到一半的计算），而重建它们需要数秒到数分钟 15；为了在停机期间维持可用性，需要冗余副本(redundant replicas)，从而带来资源开销，以补偿"无法恢复单个组件"这一缺陷。在空间上，容器级的编排无法表达共享同一地址空间(address space)的组件之间的依赖，并为那些本可以是本地函数调用的交互引入了网络开销(network overhead)。这两种机制都运作在进程和容器的边界上，然而现代系统越来越在更细的层次上进行组合。这种粒度失配(granularity mismatch)要求一种组合式抽象(compositional abstraction)，它能在与组件自身相同的层次上管理效应与依赖。
详细解释
这一节回答了一个关键的"反诘"：既然动态组合这么重要，为什么学术界之前没好好研究它？论文给出的答案非常诚实------因为操作系统和容器编排器（Kubernetes 这类）已经提供了一个够用但不理想的粗粒度替代品。这一段的作用是先把现有的"行业默认方案"摊在桌上，逐条算清它的账，从而证明"我们确实需要一个更细粒度的新东西"，而不是无的放矢。
操作系统在进程 粒度上给了你时间可组合性：进程一杀，它占的内存、文件句柄、监听端口全部被操作系统强制回收------这是"杀进程=干净撤销"的粗粒度版本。容器编排器在服务粒度上给了你空间可组合性：哪个服务依赖哪个服务、健康检查、滚动更新、依赖编排，都由 K8s 这类系统管。大多数软件就是靠这套"进程+容器"的组合苟过来的。
但论文逐条算账，揭示代价：时间上，重启要丢掉进程内一切状态------缓存要重算、数据库连接要重建、跑到一半的计算要重来，重建动辄秒到分钟级；为了在这段停机期还能服务，你要再开冗余副本，白白多花一倍机器。空间上，容器编排只能管"跨服务"的依赖，管不了"同一个进程内、共享地址空间"的组件依赖------可偏偏现代系统越来越多的组合发生在进程内部（插件、模块、agent 子系统），这时你被迫把这些本可以是本地函数调用的交互，硬塞进跨容器的网络调用，凭空多了网络开销和序列化成本。
最后一句"粒度失配(granularity mismatch)"是本节的核心结论，也是全文的需求陈述：组合实际发生的层次（细粒度的组件）和管理它的手段（进程/容器边界）之间错位了。Cordis 要做的，就是提供一种与组件同粒度的组合抽象------效应和依赖都在组件这一层就被管理，而不是被迫上浮到进程或容器边界。这个"同粒度"原则，是后面"把 effect/coeffect 提升为运行时机制"的设计出发点。
1.3 Contributions / 1.3 贡献
原文 (English)
The two dimensions of dynamic composability concern, respectively, how computations modify and how they depend on their environment. These two directions are what effect systems 16, 17 and coeffect systems 18, 19 formalize: effects provide the formal vocabulary for reasoning about environmental modifications, and coeffects for reasoning about environmental requirements. However, existing formulations restrict reasoning to compile-time analysis over lexically fixed scopes, and do not extend to dynamic scenarios where components arrive and depart at runtime. By lifting effects to a revertible runtime model and coeffects to a reactive dependency resolution mechanism, we obtain a unified formal foundation for dynamic composability, one that is language-agnostic and applicable to any software architecture requiring dynamic composition. We make the following contributions:
- We formalize revertible effects (Section 3.1): every context transformation carries an explicit inverse that the runtime tracks, and both tracking and recovery preserve composition, so the context is recovered upon component removal. This establishes local temporal composability.
- We formalize reactive coeffects (Section 3.2): a component declares the coeffects it requires as a specification, and each change of the context notifies the component against that specification as activating, deactivating, or neutral. This establishes local spatial composability.
- We unify the effect context and the coeffect context into a single context type (Section 3.3), in which an observational equivalence on the coeffects supplies the effects with independence, constituting a programming paradigm for spatiotemporal composability.
- We give a calculus of dynamic composition (Section 4), which combines the two mechanisms into the notion of a component and equips its lifecycle with an operational semantics. Its metatheory carries spatiotemporal composability from a single component to a whole system of interleaved components.
- We implement these ideas in Cordis (Section 5), a meta-framework of spatiotemporal composability that provides a core library realizing the formal model with effect tracking and coeffect resolution, as well as a declarative component loader with configuration reconciliation and hot module replacement.
中文翻译
动态可组合性的两个维度，分别关乎计算如何修改、以及如何依赖其环境。这两个方向正是效应系统(effect systems)16, 17 与协效应系统(coeffect systems)18, 19 所形式化的内容：效应为推理环境修改提供了形式化词汇，协效应则为推理环境需求提供形式化词汇。然而，现有的形式化把推理限制在编译期对词法固定作用域(lexically fixed scopes)的分析上，无法扩展到组件在运行时到来与离去的动态场景。通过把效应提升为一个可逆的运行时模型、把协效应提升为一个响应式的依赖解析机制，我们为动态可组合性获得了一个统一的形式化基础------它是语言无关的(language-agnostic)，适用于任何需要动态组合的软件架构。我们做出如下贡献：
- 我们将可逆效应(revertible effects)形式化（第 3.1 节）：每一次上下文变换都携带一个显式的逆(explicit inverse)，由运行时跟踪，且跟踪与恢复都保持组合性(preserve composition)，从而在组件被移除时恢复上下文。这确立了局部时间可组合性(local temporal composability)。
- 我们将响应式协效应(reactive coeffects)形式化（第 3.2 节）：一个组件把它所需的协效应声明为一份规约(specification)，上下文的每一次变化都依据该规约通知组件，将其判定为激活(activating)、失活(deactivating)或中性(neutral)。这确立了局部空间可组合性(local spatial composability)。
- 我们将效应上下文与协效应上下文统一为单一的上下文类型(single context type)（第 3.3 节），其中协效应上的一种观察等价(observational equivalence)为效应提供了独立性(independence)，由此构成一种时空可组合性的编程范式(programming paradigm)。
- 我们给出一个动态组合演算(calculus of dynamic composition)（第 4 章），它把两种机制组合进"组件(component)"的概念，并为其生命周期配备操作语义(operational semantics)。其元理论(metatheory)将时空可组合性从单一组件推广到一整由交错(interleaved)组件构成的系统。
- 我们在 Cordis（第 5 章）中实现这些想法------这是一个时空可组合性的元框架(meta-framework)，它提供了一个实现该形式化模型的核心库（带效应跟踪与协效应解析），以及一个带配置调和(configuration reconciliation)与热模块替换(hot module replacement)的声明式组件加载器(declarative component loader)。
详细解释
这一节是全文的"贡献清单"，结构上先有一段承上启下的方法论阐述，再逐条列出 5 项贡献。开篇这段阐述极其重要，因为它揭示了论文最核心的学术洞察：动态可组合性的两个维度，恰好对应效应系统（讲"计算怎么改环境"）和协效应系统（讲"计算怎么依赖环境"） 。这是一个漂亮的"对偶映射"------工程问题被精准地接到了已有的理论工具上。但论文同时指出这些理论工具的现成版本都是静态 的（编译期、词法作用域内），于是论文的贡献本质上就是"把这两套静态理论动态化"。
下面逐条解释这 5 点贡献，以及它们的内在递进关系：
贡献 1 ------ 可逆效应（对应时间维度）。 核心思想是：组件对共享上下文做的每一次改动，都必须就地附带一个"逆操作"，运行时把这一对"改动+逆"记下来。卸载组件时，运行时按记录把逆操作逐条回放，把上下文恢复到组件到来之前的样子。这里有两个形式化要求：一是"跟踪要保持组合性"------记逆的过程本身不能破坏其他组件的改动；二是"恢复要保持组合性"------回放逆操作时不能误伤别的组件。这就是第 1.1 节"时间可组合性"的形式化落地。类比：像数据库事务的回滚日志，每条改动都记下如何撤销，事务失败时按日志逆向回滚，且回滚不影响其他已提交的事务。
贡献 2 ------ 响应式协效应（对应空间维度）。 组件不再被动地"以为自己依赖的东西一直在"，而是主动声明 一份协效应规约："我需要 A、需要 B"。运行时在上下文发生变化时，拿这份规约去比对，然后把变化对该组件的影响归类成三种状态之一：激活 （之前缺的依赖现在齐了，该组件可以工作了）、失活 （之前依赖的东西没了，该组件该停下）、中性（变化与我无关）。这让"依赖管理"从"每个模块自己 ad hoc 检测"变成了"运行时统一、声明式地响应"。这是第 1.1 节"空间可组合性"的形式化落地。
贡献 3 ------ 统一上下文类型（两维度合一）。 这是最具理论雄心的一步：把贡献 1 的"效应上下文"和贡献 2 的"协效应上下文"合并成同一个上下文类型。关键技巧是"协效应上的观察等价为效应提供独立性"------也就是说，只要两个组件的协效应规约在观察上是等价的，它们各自的效应修改就互不干扰（相互独立）。这一步把两个原本分开的形式化粘合成"一个范式"，所以论文敢称之为"一种编程范式"而不只是"两个机制"。这是从"两个工具"到"一个统一世界观"的飞跃。
贡献 4 ------ 动态组合演算（从单组件到多组件系统）。 前三条贡献都还是"局部"的（论文明确说贡献 1、2 分别确立"局部"时间/空间可组合性）。贡献 4 要把"局部"推广到"全局"：定义什么是"组件"、给它配一套带生命周期的操作语义，然后通过元理论 证明------只要每个组件局部满足可组合性，那么一整系统里交错运行的多个组件也整体满足可组合性。这种"局部→全局"的提升，正是形式化方法最擅长、也最有价值的事：它保证你拼出来的大系统不会因为"组件多了"而崩坏。类比：就像证明单个模块是线程安全的（局部），再证明线程安全的模块组合起来整体仍线程安全（全局）。
贡献 5 ------ Cordis 实现。 前四点是理论，第五点落地为一个真实的元框架(meta-framework)。"元框架"这个词值得注意------它不是又一个应用框架，而是用来构建其他框架的基础设施。Cordis 提供两部分：核心库（把形式化模型做成可调用的 effect tracking + coeffect resolution）和声明式组件加载器（带配置调和与热模块替换）。"配置调和"指的是当组件配置发生变化时，自动把它调和到当前运行态；"热模块替换"则是无需重启就替换组件代码------这正是前面 1.2 节批评 VSCode 做不到、容器方案又太粗的那两件事的精细版本。可以说贡献 5 是把贡献 1--4 的理论直接兑现成了能跑的工程，也回应了 1.2 节里 VSCode 和 agent harness 的全部痛点。
五条贡献呈清晰的"梯子"结构：1、2 各自攻一个维度（局部），3 把两维合一（统一），4 从局部推到全局（系统级证明），5 落地为实现。这条梯子也是后续章节的顺序（3.1→3.2→3.3→4→5），阅读时可对照。
2. Preliminaries / 第2章 预备知识（开篇）
原文 (English)
This section provides a concise overview of effect and coeffect systems---the two theoretical pillars underlying our work. We assume familiarity with basic type theory and category theory; the goal here is to fix notation and introduce the key abstractions that Section 3 will operationalize as runtime mechanisms.
中文翻译
本节对效应系统与协效应系统------支撑我们工作的两根理论支柱(theoretical pillars)------作一个简明概述。我们假定读者熟悉基本的类型论(type theory)与范畴论(category theory)；这里的目标是固定记法(notation)，并引入那些将在第 3 章被操作化为(operationalize)运行时机制的关键抽象(key abstractions)。
详细解释
这一段是第 2 章的"使用说明"。它直接告诉读者：这一章不打算从头教类型论和范畴论，而是假定你已经有基础，然后做两件具体的事------固定记法 （后面公式里 Γ、𝑇、𝜂 这些符号到底指什么，统一下口径）和引出关键抽象（monad、comonad、algebraic effects、graded coeffects 这些概念）。特别值得注意的是最后一句里那个动词"操作化为运行时机制(operationalize as runtime mechanisms)"------它泄露了整章的真正用意：第 2 章表面上是在复习经典理论，实质上是在为第 3 章"把这些静态理论提升成运行时机制"做准备。换句话说，第 2 章里介绍的每一个抽象，到第 3 章都会被"激活"成能跑的东西。所以读这一章时，最好带着这个问题：每个经典概念，要怎么从"编译期静态分析"变成"运行时能操作的对象"？
2.1 Effects / 2.1 效应
原文 (English)
In the simply typed lambda calculus (STLC) 20, 21, a typing judgment Γ ⊢ 𝑡 : 𝑇 states that term 𝑡 has type 𝑇 under context Γ. An effect system refines the type to describe what side effects a computation may produce, yielding judgments of the form
Γ ⊢ 𝑡 : 𝑇effect (1)
Here, the result type is annotated with an element of an effect algebra that describes which side effects the computation may produce, enabling compositional reasoning about stateful computations. This approach originates with Lucassen and Gifford 22, who introduced a kinded type system distinguishing types, effects, and regions to discover scheduling constraints in parallel programs.
Monadic effects. Moggi 16 first modeled computational effects categorically via monads; Wadler 23 popularized the approach in Haskell. A monad (𝑇, 𝜂, 𝜇) on a category 𝒞 encapsulates an effectful computation as a value of type 𝑇(𝐴), with 𝜂 : 𝐴 → 𝑇(𝐴) lifting pure values and 𝜇 : 𝑇(𝑇(𝐴)) → 𝑇(𝐴) sequencing nested computations. Classic instances include the Maybe monad (for partiality), State monad (for mutable state), and IO monad (for external interaction).
Algebraic effects. Plotkin and Power 17, 24 showed that algebraic operations determine monads, establishing a framework in which effect interfaces are decoupled from their implementations. An effect signature Σ declares a set of operations (e.g., get : () → 𝑆, put : 𝑆 → () for state); programs invoke operations freely without committing to a particular interpretation. Plotkin and Pretnar 25 subsequently introduced effect handlers, which interpret operations by providing continuation semantics:
handle 𝑒 with { op(𝑣, 𝜅) ↦ ... } (2)
The handler receives the operation argument 𝑣 and the delimited continuation 𝜅, which it may invoke zero, one, or multiple times, enabling exceptions, coroutines, and non-determinism within a uniform framework 26. Languages such as Koka 27, 28, Eff 29, and OCaml 5 30 have adopted algebraic effects with varying design trade-offs.
中文翻译
在简单类型 lambda 演算(simply typed lambda calculus, STLC)20, 21 中，一个类型判断(typing judgment) Γ ⊢ 𝑡 : 𝑇 表明：在上下文 Γ 之下，项 𝑡 具有类型 𝑇。效应系统(effect system)对类型加以细化，以描述一个计算可能产生哪些副作用(side effects)，从而得到如下形式的判断：
Γ ⊢ 𝑡 : 𝑇effect (1)
这里，结果类型被一个**效应代数(effect algebra)**中的元素所标注，该元素描述了这个计算可能产生哪些副作用，从而能够对有状态计算(stateful computations)进行组合式推理(compositional reasoning)。这一方法源自 Lucassen 和 Gifford 22，他们引入了一种区分类型(types)、效应(effects)与区域(regions)的带 kind 类型系统(kinded type system)，用以发现并行程序中的调度约束(scheduling constraints)。
单子效应(Monadic effects)。 Moggi 16 首次通过单子(monad)从范畴论角度对计算效应进行建模；Wadler 23 在 Haskell 中推广了这一方法。一个范畴 𝒞 上的单子 (𝑇, 𝜂, 𝜇) 把一个带效应的计算封装(encapsulates)为类型 𝑇(𝐴) 的值，其中 𝜂 : 𝐴 → 𝑇(𝐴) 把纯值(pure values)提升(lift)进来，𝜇 : 𝑇(𝑇(𝐴)) → 𝑇(𝐴) 把嵌套的计算串联(sequencing)起来。经典的实例包括 Maybe 单子（用于偏函数/部分性 partiality）、State 单子（用于可变状态 mutable state）以及 IO 单子（用于与外部交互 external interaction）。
代数效应(Algebraic effects)。 Plotkin 和 Power 17, 24 证明了代数运算(algebraic operations)可以确定单子，由此建立了一个框架，使效应接口(effect interfaces)与其实现(implementations)解耦(decoupled) 。一个效应签名(effect signature) Σ 声明一组运算（例如用于状态的 get : () → 𝑆、put : 𝑆 → ()）；程序可以自由地调用这些运算，而无需承诺(committing)某种特定的解释(interpretation)。Plotkin 和 Pretnar 25 随后引入了效应处理器(effect handlers)，它通过提供续延语义(continuation semantics)来解释运算：
handle 𝑒 with { op(𝑣, 𝜅) ↦ ... } (2)
处理器接收到运算的参数 𝑣 与界定续延(delimited continuation) 𝜅，它可以调用这个续延零次、一次或多次，从而在一个统一的框架内实现异常(exceptions)、协程(coroutines)与非确定性(non-determinism)26。诸如 Koka 27, 28、Eff 29 和 OCaml 5 30 等语言都以各自的设计取舍采用了代数效应。
详细解释
这一节是论文两根理论支柱中的第一根------效应，分三个层次递进介绍：先是最基础的"效应类型判断"，再是"单子效应"，最后是更现代的"代数效应+处理器"。理解这三个层次，是理解第 3 章把效应"可逆化"的前提。
第一层：效应类型判断（公式 1）。 在普通的简单类型 lambda 演算里，判断 Γ ⊢ 𝑡 : 𝑇 只说"项 t 在上下文 Γ 下是类型 T"。效应系统在类型 T 上再挂一个"effect 标签"，变成 Γ ⊢ 𝑡 : T 的 effect------这个标签来自一个"效应代数"，描述"这个计算会动到什么"（读状态？写状态？抛异常？做 IO？）。这样你就能对有状态计算做组合式推理：两个计算串起来，它们的效应标签也能按代数规则组合，从而静态推出组合后整体的效应。类比：就像给每段代码贴一张"会产生哪些副作用"的标签，把两段拼起来时，标签也按规则拼，你不用真跑就能知道整体副作用。Lucassen-Gifford 的原始工作是为了在并行程序里发现调度约束（哪些效应不能并行、哪些可以），这是效应系统的历史起点。
第二层：单子效应（monad）。 这是最经典的效应建模方式。一个单子 (𝑇, 𝜂, 𝜇) 是三件套：一个类型构造子 𝑇（把普通类型 A 包成"带效应的类型" T(A)）、一个 unit 𝜂（把纯值塞进盒子里：A → T(A)）、一个 multiply 𝜇（把"盒中盒" T(T(A)) 压扁成一层 T(A)，这就是"串联"两步带效应计算的机制）。通俗类比：单子就像一个带标签的盒子 。Maybe 单子是"可能空的盒子"------盒子里要么有值要么没有，天然表达"计算可能失败"；State 单子是"盒子里同时装着值和一份状态"------每步计算都把旧状态变换成新状态；IO 单子是"盒子上写着'此值来自外部世界'"------把与外界的交互包起来。𝜂 是"把一个普通值放进盒子"，𝜇 是"把盒子里的盒子拆成一层盒子"------后者正是把"先做 A 再做 B"这种嵌套串联起来的关键。Moggi 用范畴论建模、Wadler 在 Haskell 落地，是这一脉的两块里程碑。这一层对论文的意义在于：Cordis 的"可逆效应"本质上是给每一次 𝜂/𝜇 操作都配一个"逆"------单子是论文形式化的范畴论底座。
第三层：代数效应 + 处理器。 这是比单子更现代、也更契合论文需求的一层，核心创见是接口与实现解耦 。效应签名 Σ 只声明"有哪些运算"（比如 get/put），程序里随便调用这些运算，但不关心这些运算到底怎么实现 ；真正给运算赋予含义的是处理器(handler) ，它按 handle e with { op(v, κ) ↦ ... } 的形式逐个解释每个运算。处理器拿到的不只是运算参数 v，还有一个界定续延 κ ------即"运算被发起那一刻、剩下还没跑的那部分计算"。这个续延可以被调用零次（抛异常：直接抛弃续延）、一次（普通返回）、多次（非确定性/协程：把续延复制多份分别跑）。类比：代数效应就像声明了一组"按钮"，程序只管按按钮，不关心按钮背后接的是什么电路；处理器就是那块"驱动板"，决定每个按钮按下后具体做什么，而且它手里攥着"按完按钮之后本该继续执行的剩余程序"，所以它可以决定是继续、中止、还是把剩余程序复制几份分别继续。 这种"接口/实现分离 + 续延"的组合，让异常、协程、非确定性这些看似不同的控制流都能用同一个框架表达。Koka、Eff、OCaml 5 都落地了它。
这一层对 Cordis 尤其关键：第 3 章的"可逆效应"可以看作是给代数效应的处理器装上"撤销语义"------每一次运算(创建副作用)都对应一个逆运算(撤销副作用)，由运行时记下来。代数效应"接口与实现分离"的特性，恰好让"跟踪+撤销"可以作为一层独立的处理器插入，而不必改动效应接口本身。这也是为什么论文选择从代数效应出发、而不是从更死板的单子出发------代数效应的解耦性给了运行时插桩的空间。
2.2 Coeffects / 2.2 协效应
原文 (English)
Dually to effects, a coeffect system 18, 31 enriches the context rather than the type, yielding judgments of the form
Γcoeffect ⊢ 𝑡 : 𝑇 (3)
Here, the context is annotated with an element of a coeffect algebra describing what the computation requires from its environment, such as resources to access, permissions to hold, or services to depend on. While effects model a program's impact on the world, coeffects model the world's constraints on the program.
Comonadic coeffects. The idea of using comonads to structure context-dependent computation was first developed by Uustalu and Vene 32, who proposed symmetric (semi)monoidal comonads as the dual of Moggi's monadic framework for effects, capturing notions such as dataflow and attribute evaluation. Petricek et al. 18 built on this foundation to propose coeffects as a unified static analysis of context-dependence. A comonad (𝐷, 𝜀, 𝛿) captures context-dependent computation: 𝜀 : 𝐷(𝐴) → 𝐴 extracts the current value from a context, and 𝛿 : 𝐷(𝐴) → 𝐷(𝐷(𝐴)) duplicates context for nested access. The Environment comonad 𝐷(𝑋) = 𝐸 × 𝑋 models dependence on a fixed environment 𝐸; the Stream comonad 𝐷(𝑋) = ℕ → 𝑋 models dependence on temporal data.
Graded coeffects. For finer-grained tracking, graded coeffect systems use a pre-ordered semiring 𝒮 = (𝑆, ≤, +, ×, 0, 1) as the coeffect algebra 33, a discipline later unified with graded effects by Gaboardi et al. 19. Elements of 𝑆 annotate each variable binding to quantify its usage: 0 for unused, 1 for linear use, 𝑛 for bounded use, ∞ for unrestricted use. The semiring operations compose coeffects sequentially (×) and in parallel (+), enabling precise resource tracking, sensitivity analysis 34, and information-flow control 35, 36 within a unified algebraic framework 37.
中文翻译
与效应对偶地(dually)，协效应系统(coeffect system)18, 31 丰富的是上下文而非类型，从而得到如下形式的判断：
Γcoeffect ⊢ 𝑡 : 𝑇 (3)
这里，被标注的是上下文 ------用一个协效应代数(coeffect algebra)中的元素来描述该计算从其环境中要求什么，例如要访问的资源(resources to access)、要持有的权限(permissions to hold)、或要依赖的服务(services to depend on)。效应建模的是一个程序对世界的影响(impact)，而协效应建模的是世界对程序的约束(constraints)。
余单子协效应(Comonadic coeffects)。 用余单子(comonad)来组织依赖上下文的计算(context-dependent computation)，这一想法最早由 Uustalu 和 Vene 32 发展，他们提出了对称（半）单子对称的((semi)monoidal)余单子，作为 Moggi 效应单子框架的对偶(dual)，用以刻画数据流(dataflow)与属性求值(attribute evaluation)等概念。Petricek 等人 18 在此基础上提出把协效应作为对上下文依赖性(context-dependence)的一种统一静态分析。一个余单子 (𝐷, 𝜀, 𝛿) 刻画依赖上下文的计算：𝜀 : 𝐷(𝐴) → 𝐴 从上下文中**抽取(extracts)当前值，𝛿 : 𝐷(𝐴) → 𝐷(𝐷(𝐴)) 为嵌套访问复制(duplicates)**上下文。Environment 余单子 𝐷(𝑋) = 𝐸 × 𝑋 建模对一个固定环境 𝐸 的依赖；Stream 余单子 𝐷(𝑋) = ℕ → 𝑋 建模对时序数据(temporal data)的依赖。
分级协效应(Graded coeffects)。 为了更细粒度的跟踪，分级协效应系统用一个预序半环(pre-ordered semiring) 𝒮 = (𝑆, ≤, +, ×, 0, 1) 作为协效应代数 33，这一做法后来由 Gaboardi 等人 19 与分级效应(graded effects)统一。𝑆 中的元素标注每一个变量绑定(variable binding)以量化其使用(usage)：0 表示未使用(unused)、1 表示线性使用(linear use)、𝑛 表示有界使用(bounded use)、∞ 表示无限制使用(unrestricted use)。半环运算把协效应顺序(sequentially)组合(×)和并行(in parallel)组合(+)，从而在一个统一的代数框架 37 内实现精确的资源跟踪(resource tracking)、敏感性分析(sensitivity analysis)34 与信息流控制(information-flow control)35, 36。
详细解释
这一节是论文两根理论支柱中的第二根------协效应，它和 2.1 节的效应是严格的**对偶(dual)**关系。理解协效应的关键，是始终记住那句话："效应建模程序对世界的影响，协效应建模世界对程序的约束。"------一个朝外(我做了什么)，一个朝里(我需要什么)。这一节同样分三层递进。
第一层：协效应类型判断（公式 3）。 对比公式 1 和公式 3 就能一眼看出对偶：效应系统把标签挂在类型 上（Γ ⊢ t : T 的 effect），协效应系统把标签挂在上下文 上（Γ 的 coeffect ⊢ t : T）。这个位置之差意义重大------它意味着协效应描述的不是"这个计算会产出什么副作用"，而是"这个计算要跑起来，环境得先给它准备好什么"：要访问的资源、要持有的权限、要依赖的服务。用类比说：效应像是"我出门会弄脏哪些地方"，协效应像是"我出门前得先准备好钥匙、钱包、地图哪些东西"。这种"朝内"的视角正是 Cordis 空间可组合性要用的------组件要声明"我依赖哪些其他组件"，这正是协效应的天然领地。
第二层：余单子协效应（comonad）。 余单子是单子的范畴论对偶。单子 (𝑇, 𝜂, 𝜇) 是"把值包进带效应的盒子"，余单子 (𝐷, 𝜀, 𝛿) 反过来是"给值配上它所处的上下文"。三件套里 𝜀（counit / extract）是把"带上下文的值"剥回"纯值"------D(A) → A，取出当前值；𝛿（comultiplication / duplicate）是把上下文复制一份供嵌套访问------D(A) → D(D(A))。通俗类比：余单子就像一个"自带周围环境的值" 。𝜀 是"撇开环境，只看此刻这个值本身"；𝛿 是"把环境再展开一层，好让你看到这个值所处的更大环境"。论文举两个经典实例：Environment 余单子 D(X) = E × X------值 X 永远配着一个固定环境 E，建模"我依赖一个固定的环境"；Stream 余单子 D(X) = ℕ → X------值 X 依赖一个时间下标（自然数 ℕ），即"这个值随时间变化"，建模对时序数据的依赖。Uustalu-Vene 首先把余单子用作单子的对偶来刻画上下文依赖计算，Petricek 等人把它发展成统一的"协效应"静态分析。这一层对论文的意义在于：Cordis 的"响应式协效应"以余单子为范畴论底座------组件"依赖上下文"这件事，在数学上就是余单子结构，第 3 章会把它从静态分析提升为运行时的依赖声明与响应。
第三层：分级协效应（graded coeffects）。 这是比余单子更精细的一层。普通的协效应只说"这个变量依赖环境"，但不量化"依赖多少"；分级协效应引入一个预序半环 𝒮 = (𝑆, ≤, +, ×, 0, 1) 作为协效应代数，给每个变量绑定打一个量化的"使用量"标签：0（完全没用）、1（线性使用，恰好用一次）、n（有界使用，最多 n 次）、∞（无限制使用）。半环的两个运算 × 和 + 分别对应"顺序组合"和"并行组合"------把两段计算串起来，使用量按 × 累乘；把两段计算并行，使用量按 + 累加。这就让协效应不仅能定性说"依赖"，还能定量说"依赖几次、用得多狠"。这套机制已被用于精确的资源跟踪、敏感性分析（比如差分隐私里"这条数据被查了几次"）和信息流控制（机密数据的使用次数受限以防泄漏）。通俗类比：分级协效应就像给每个依赖装了一个"使用计量表"------不只是"你用不用这个资源"，而是"你用了 0 次 / 恰好 1 次 / 最多 n 次 / 随便用"，并且组合计算时计量表也按半环规则自动累加。这一层对 Cordis 的意义在于：组件声明协效应规约时，可以用分级的方式精确表达需求强度，运行时在上下文变化时据此判定"激活/失活/中性"也就有了量化依据，而不只是"有/无"的二元判断。
2.3 Relationship to Dynamic Composability / 2.3 与动态可组合性的关系
原文 (English)
Effect and coeffect systems organize reasoning about computation along two complementary directions: effects describe how a computation modifies its environment, whereas coeffects describe how it depends on its environment. These two directions correspond to the two dimensions of dynamic composability identified in Section 1:
• Temporal composability demands that a component's modifications to the shared environment be revertible upon unloading. The relevant effects are the stateful ones, which durably transform that environment; undoing such a transformation requires it to admit an inverse.
• Spatial composability demands that inter-component dependencies be declared and managed reactively. Such dependencies are the very thing coeffects capture, and managing them amounts to resolving each against what the environment supplies.
However, classical effect and coeffect systems are static instruments: effects are tracked within lexically fixed scopes and discharged by compile-time handlers; coeffect annotations are verified against contexts determined before execution. Dynamic composition, by contrast, requires these guarantees to hold for components that arrive and depart at runtime, against contexts that evolve continuously. No fixed lexical scope can delimit a plugin loaded after deployment; no compile-time context can anticipate dependencies that emerge from runtime configuration.
This motivates a shift in perspective: rather than extending static type systems with more annotations, we reify the conceptual structures of effects and coeffects so that a runtime can operate on them directly, establishing dynamically the guarantees these systems provide statically.
中文翻译
效应系统与协效应系统沿着两个互补的方向来组织对计算的推理：效应描述一个计算如何修改 其环境，而协效应描述它如何依赖 其环境。这两个方向正对应第 1 章所识别出的动态可组合性的两个维度：
• 时间可组合性 要求一个组件对共享环境的修改在卸载时是可逆的(revertible) 。这里相关的效应是那些有状态的效应(stateful effects)------它们会持久地(durably)变换该环境；而撤销这样一种变换，就要求该变换容许一个逆(admit an inverse) 。
• 空间可组合性 要求组件间的依赖被声明 并被响应式地管理 。这样的依赖正是协效应所刻画的东西，而管理它们就相当于把每一个依赖拿去与"环境所提供的"进行解析(resolving) 。
然而，经典的效应与协效应系统都是静态 工具：效应在词法固定作用域内被跟踪、并由编译期的处理器予以 discharge；协效应标注则是依据执行之前 就已确定的上下文来验证。动态组合则截然不同------它要求这些保证对那些在运行时到来与离去、且面对持续演化(continuously evolve)的上下文的组件依然成立。没有任何固定的词法作用域能够界定一个在部署之后才被加载的插件；也没有任何编译期上下文能够预见到那些由运行时配置所产生的依赖。
这促使一次视角的转换(shift in perspective)：与其用更多的标注去扩展静态类型系统，我们不如把效应与协效应的概念结构具象化(reify) ，使得一个运行时能够直接对它们进行操作，从而动态地 建立起这些系统静态地提供的那些保证。
详细解释
这是第 2 章的收束之节，也是把"预备知识"和"论文主贡献"焊接在一起的关键一节。它做了三件事：先把效应/协效应和第 1 章的时间/空间两个维度精确对齐，再指出经典理论的静态局限，最后宣布论文的方法论转向。
第一步：对齐。 这一节明确建立了两套对应关系------时间可组合性 ↔ 效应 （更具体地说是"有状态效应"，即那些会持久改变环境的效应；要撤销这种改变，就要求每一次变换都"容许一个逆"）；空间可组合性 ↔ 协效应（组件间依赖正是协效应所刻画的，管理依赖就是把每个依赖拿去和环境当前能提供的东西做"解析"）。这段对齐把第 1 章的工程问题和第 2 章的理论工具一一扣上：你之所以能用 effect/coeffect 这套现成理论来解决动态组合，正因为这两个维度的本质就是效应和协效应。这种"工程问题 ↔ 理论工具"的精确对应，是论文学术合法性的核心论证。
第二步：指出局限。 论文不回避经典理论的短板：效应和协效应都是静态工具------效应在词法作用域内被跟踪、由编译期处理器消化；协效应标注在执行前就定好的上下文上验证。而动态组合恰恰打破了这两个前提：一个部署后才加载的插件，没有任何词法作用域能框住它；一个由运行时配置才产生的依赖，没有任何编译期上下文能预见到。换言之，经典理论的"静态"和动态组合的"动态"是直接冲突的------你不可能靠"给静态类型系统加更多标注"来解决，因为问题的本质就是这些标注在编译期根本拿不到全部信息。这个论证很有力，因为它堵死了"沿用静态路线、打补丁"的退路。
第三步：方法论转向。 这是整章、乃至整篇论文方法论的点睛之笔------"具象化(reify)" 。论文不再走"扩展静态类型系统加标注"的老路，而是把效应和协效应的概念结构本身变成运行时可以直接操作的一等对象(first-class object) 。也就是说，效应不再只是编译期类型上的一个标签，而是运行时实实在在可以记录、可以回放的"改动+逆"对；协效应不再只是编译期的一个上下文标注，而是运行时实实在在可以声明、可以比对的"依赖规约"。运行时直接对它们操作，从而动态地 建立起经典系统只能在静态下给出的那些保证。用一个类比：经典理论像是一张在出发前印好的、固定的路线图（静态）；论文的做法是把"路线规划"这件事变成一个随身的、能实时更新的导航仪（运行时）------地图的"概念"还在，但它从纸面被提升成了一个能跑、能改的活对象。这个"reify 并让运行时直接操作"的思路，正是第 3 章可逆效应与响应式协效应、以及第 5 章 Cordis 实现的共同方法论原点，理解了这一句就抓住了全文的设计哲学。