第 11 章 · Cordis 与时空可组合性

本篇目标：理解「热插拔插件」为什么在数学上成立，以及它不能撤销什么。 这一章是从「会写插件」到「懂运行时」的分界。

11.1 论文与定位

论文 A Programming Paradigm for Spatiotemporal Composability，arXiv:2608.25512，2026-08-26 提交，92 页。作者 Yifan Shi（北京大学 / DeepSeek-AI）、Wei Zhang（北京大学）、Tianyi Cui（DeepSeek-AI）。

官方 DSH README 明确：项目建立在 everything-is-a-plugin 架构之上，由 Cordis 驱动，其设计即由该论文描述。Cordis 仓库自述为 "A Meta-Framework of Spatiotemporal Composability"，并注明 API 尚未稳定。

论文要解决的问题：从插件系统到自进化 Agent Harness，现代软件越来越需要动态组合，但形式化基础不足。作者识别出两个正交维度：

11.2 两个机制

然后作者把 effect context 与 coeffect context 统一成单一 context 类型，所有 effect / coeffect 都经它中介，称为 context paradigm。中介诱导出一种观测等价性（observational equivalence）：在此意义下，不同组件的效应可以交错而不互相干扰。

最后用 component 概念给出动态组合的演算，其元理论把时空可组合性从单个组件推广到整个交错系统。

工程落地：Cordis 提供 core library（effect tracking + coeffect resolution）与 declarative component loader（configuration reconciliation + hot module replacement）。

这解释了 DSH 为什么敢让「创造模式」在内存中加载插件、试跑、卸载、再改：卸载不是「把对象删掉」，而是运行时按 inverse 逐条撤销注册。没有这套理论保证，热插拔会累积孤儿监听器、重复工具、泄漏的服务，几轮之后行为就不可预测了。

11.3 ctx.effect()：能撤销什么，不能撤销什么

原文 特别拎出这个概念，并给出最重要的边界：

「这不会撤销一个外部动作，比如一条已经执行过的 shell 命令。」

必须分清两类副作用：

一个对照写法：

import type { Context } from '@deepseek-ai/cordis'

export function apply(ctx: Context) {
  // 进程内注册：插件卸载时自动撤销，不会留下孤儿监听器
  ctx.effect(() => {
    const dispose = ctx.on('session/event', handler)
    return dispose
  })

  // 外部动作：卸载时不会回滚，必须自己设计补偿或人工审批
  ctx.on('agent/turn-stopping', async () => {
    await tools.run_bash({ cmd: 'git push' })   // ⚠️ 不可撤销
  })
}

判据 16：把「可逆」当默认，是插件开发的正确直觉；把「不可逆」当默认，是生产安全的正确直觉。二者不矛盾——前者针对注册，后者针对副作用。第 16、17 章要求所有不可逆动作前置人工 gate。

社区 Heym 的一句话可以直接搬过来：「A missing placement fails the build, and a missing sandbox fails the run.」——没有默认值的失败必须显式，静默 fallback 会隐藏决策。

11.4 依赖与激活：为什么改配置不用重启

论文 reactive coeffects 的工程含义：组件声明自己的依赖（coeffect specification），运行时在每次 context 变化后分类，决定哪些组件激活、哪些停用。

官方 DSH docs/architecture.md 里的对应物：

• Service Definition / Provider / Consumer 三元组构成 capability seam
• static inject = ['tools'] / inject: ['tools'] 声明依赖
• super(ctx, '服务名') 把服务注册进共享 context
• YAML 控制 HMR：base 启用 config-only dsh-hmr，headless / sdk / acp 禁用，sdk-minimal 完全不含

于是一个 provider 换掉，消费它的所有工具跟着变。官方 原句：

"Filesystem and subprocess providers share one execution world, so pointing them at a remote sandbox moves Bash, PTY, and LSP with them, with no provider forks."

这是「配置层自由组合」的真正含义：不是有一堆开关，而是依赖图会响应配置变化自动重算。

11.5 自进化 Harness 的边界

论文标题里提到 "self-evolving agent harnesses"，DSH 的创造模式也确实允许「Agent 自己开发/安装/卸载插件」。但必须冷静：

官方 SAFETY.md：项目可执行模型生成代码、加载第三方插件、访问网络/进程/凭据/文件，沙箱不构成隔离保证。所以自进化必须关在笼子里：

1. 只在一disposable 环境 / 测试文件夹里试验
2. 从 GitHub 装的插件，加载前通读代码
3. 审批逐条看清再同意
4. 生产凭据不留在环境里
5. 重要环境固定版本

11.6 本章产出与验收

核心产出：一张自己插件的「副作用清单」——逐条标注可逆 / 不可逆，并对不可逆项写出补偿或审批方案。

验收点：

• 能用自己的话说清 temporal / spatial composability 的区别
• 能解释 ctx.effect() 为何能撤销监听器却不能撤销 git push
• 能说出一个 seam 的三个角色，并举例「换 provider 会连带改变什么」
• 能解释 HMR 为什么在 sdk-minimal 里被刻意省略
• 能列出「自进化」必须被禁止触碰的三样东西

延伸阅读