今天凌晨 V4 Pro 正式版的热度还没过去，半天后 DeepSeek Harness 开发者预览版也开源了。
先澄清一个容易混淆的点：Harness 不是新模型，也不是 API 客户端。它是一套用来构建、运行和扩展智能体的 SDK 与应用框架，默认连接 DeepSeek 模型，也支持自定义接入其他模型。
开源地址：https://github.com/deepseek-ai/deepseek-harness
同步发布的还有一篇 DeepSeek-AI 与北大合作的论文《A Programming Paradigm for Spatiotemporal Composability》，给 Harness 的底层设计提供了形式化基础。这篇论文值得单独聊，后面说。
核心设计：一切皆插件
模型、工具、界面、存储、安全策略、上下文管理，甚至 Agent Loop 本身，统统是可插拔的。
项目建立在 Cordis 微内核之上。运行中的 Harness 本质上是一个 Cordis Context，不同包向 Context 注册服务、事件和能力，最终由配置文件组装成一套可运行的智能体。
仓库规模不小，超过 230 个 workspace 成员，代码分布在 packages/、apps/、examples/、python/、native/ 等多个区域。文件系统、Shell、子进程、终端、语言服务器、网页访问、技能、子智能体、工作流，几乎每一项能力都有独立包。
四种预设模式
Web UI 提供四种模式，本质上是同一套 Harness 宿主装配不同能力组合：
标准模式：全功能通用编码 Agent，文件编辑、Shell、搜索、子 Agent、工作流一应俱全。
PTC 模式：保留标准能力，额外支持 Code Mode。模型可以写 TypeScript 在一次 run_code 中组合多步操作，减少往返开销。
极简模式：只有持久 Bash 和 str_replace_editor 两个工具，适合路径明确、直接动手的编码任务。
创造模式：Agent 可以检查当前运行时插件树，动态挂载或卸载临时插件。相当于让车在高速上给自己换发动机，面向高级用户。
安全策略
默认采用 workspace-write 模式，命令执行和文件修改限制在当前工作区，配合 ask 审批策略处理需要扩大权限的操作。采用「失败关闭」原则：如果系统无法确认隔离机制真正生效，直接拒绝执行，不会悄悄退化为无保护运行。
多种入口与三层架构
除了 Web UI，还提供 TUI（终端用户界面）、Headless（脚本/CI）和 ACP/JSON-RPC/Python SDK 等多种入口。它们共享核心能力模型和会话事件语义，通过不同 bundle 组装出不同产品形态。
项目文档将典型能力拆成三层：接口、实现、消费者。以 Bash 为例，接口定义「执行命令」是什么，本地实现负责真正创建进程，面向模型的工具包负责把能力变成模型可理解的 schema。将来本地 Shell 换成远程容器或云端沙箱，只需替换实现层。
这个设计意味着 Harness 不绑定在任何特定运行环境上。模型可以换，工具实现可以换，界面可以换，连 Agent Loop 本身也能换。
从仓库结构看，DeepSeek 的目标显然不只是做一个对标 Codex 的产品。成品 Agent 更像是这套 SDK 的第一位客户。模型决定智能上限，Harness 决定这些智能如何进入真实环境、如何使用工具、如何在权限边界内工作。
快速上手
需要 Node.js，然后一行命令：
npx @deepseek-ai/dsh webWeb UI 默认跑在 http://127.0.0.1:3080。也可以从源码构建：
git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web目前是开发者预览版，团队明确说了会有兼容性破坏性变更，迭代速度很快。
附：Cordis 论文到底说了什么
这篇论文《A Programming Paradigm for Spatiotemporal Composability》是 Harness 的形式化基础。全文不短，但结构清晰：先构造理论（可逆效应 + 反应式协效应），再组装成带操作语义的演算并证明元理论，最后落到工程实现。相关工作部分写得极其扎实，几乎是一份效应/协效应系统的文献综述。
问题：动态组合缺一套数学基础
论文识别了两个正交维度的问题。
时间可组合性：组件卸载后，它对共享环境做的每一次修改都要能完全撤销，回到组合前的状态。
空间可组合性：组件之间要能声明、发现、验证彼此的依赖关系，并在依赖拓扑变化时做出反应。
静态场景下，时间维度对应词法作用域（RAII、bracket pattern），空间维度对应模块导入解析。但动态场景下，组件在运行时到达和离开，两者都变难了：时间维度要处理生命周期不受词法约束的长期有状态效应；空间维度要处理运行时才出现、消失、换身份的依赖。
论文用 VSCode 扩展系统做了实证说明。VSCode 所有扩展跑在同一个 extension host 进程里，100 个热门扩展里 87 个含可执行代码，一旦 activate 跑过，卸载就得重启整个 host，影响所有已加载扩展。虽然有 deactivate 钩子，但只是关闭回调，不支持热卸载，而且清理逻辑和创建逻辑分离，难以验证完整清理。依赖方面，虽然有 extensionDependencies API，但 100 个热门扩展里只有 7 个声明了对非内置扩展的依赖，因为扩展 API 本身只暴露固定的浅层扩展点，扩展之间几乎不产生依赖。
更关键的动机是自演化 Agent Harness。未来的 agent 可能在持续服务请求的同时对自己的组件生成并部署修改。没有时间可组合性，每次自我修改都要重启，丢弃进程内累积状态；没有空间可组合性，每个模块只能临时检测依赖变化，天真的代码替换策略可能悄悄破坏依赖方或引入循环依赖。
核心洞察很简洁：效应系统描述计算如何修改环境，协效应系统描述计算如何依赖环境，这正好对应时间和空间两个维度。但经典效应/协效应系统都是编译期静态工具，作用于词法固定的作用域。论文的贡献就是把这两套概念从「类型标注」提升为「运行时可操作的机制」。
理论核心：可逆效应与反应式协效应
这是全文最硬核的部分。
可逆效应的思路是：把任意不纯函数转成纯函数形式，所有副作用表示成上下文状态上的变换。然后给每个变换配一个「逆」（左逆，只保证 g∘f = id），通过一种 twisted composition 机制，逆的复合顺序反过来，形成可追踪的效应链。运行时维护一个 Effect Context，记录当前状态和累加器（所有效应逆的复合），应用累加器就能恢复到初始状态。
但这还不够。真实场景中逆往往要在应用点才能确定（比如释放刚分配的具体资源），所以论文升级到 Witnessed Effect Functions：每次应用效应时返回新状态和「就地见证」的逆，只需在当前状态下有效。按应用顺序的反序撤销，永远能精确恢复每一步。
更关键的是独立性概念。LIFO 顺序撤销不需要任何假设就成立，但真实系统里经常需要非 LIFO 顺序撤销（卸载一个组件时其他组件效应仍在，或多个组件的效应交织在一条序列里）。这时逆要面对「被别的效应挪动过的状态」还能不能正确撤销。论文证明：如果一族效应两两独立（变换两两交换，互不干扰对方产生的逆），那么无论以什么顺序撤销，最终都能回到初始状态。这才是支撑多组件交织运行、任意顺序卸载场景的关键定理。
反应式协效应方面，论文把协效应建模为键值偏函数表，每个键绑定值类型、等价关系和操作集合。组件声明依赖规格（需要哪些键存在），运行时检查状态变化并分类：规格从不满足到满足触发激活，从满足到不满足触发去激活。论文还引入了隔离（同一键在不同 realm 下解析到不同绑定，实现运行时多租户）和拦截（给每个键附加可合并的元数据，外层 context 在不改动组件代码的前提下约束其如何使用某个协效应）。
最精妙的一步是：时间维度的效应独立性，可以从协效应的可交换性推出来。如果两个效应函数都是协效应中介的（由协效应操作组成），且它们共同涉及的每个键都是可交换的（操作两两独立，不干扰彼此产生的逆和结果），那么这两个效应函数就是独立的。路由表/事件监听器登记是「可交换键」的典型——两个注册以任意顺序进行，结果一样。而中间件插入形成有序链就不可交换。
论文把这种范式定位在函数式（显式状态穿线，组合保证强但人体工程学成本高）和命令式/OOP（隐式变异，依赖关系散落各处，重构脆弱）之间。开发者只需为每个原子操作提供逆，复合的逆自动导出；协效应方面开发者只声明依赖，运行时自动解析和重连。两个方向上，原本依赖开发者纪律的正确性变成了范式的结构性质。
动态组合演算：从局部到全局
理论核心只建立了局部保证（单个组件的效应/协效应）。论文第四部分把保证扩展到整个系统。
组件被建模为三元组（依赖规格、提供集合、见证效应函数）。Fiber 是组件的一次实例化，携带生命周期状态。协效应上下文定义为所有 Active fiber 表的并集——只有激活的 fiber 才对外提供绑定。
基础演算定义了五条规则：插入、标记退休、移除（前提是已退休且已 Inactive）、加载（应用效应函数激活）、卸载（应用累加器去激活）。这是理论上最干净的版本，假设每次转换是原子的、立即的、绝不失败的。
然后论文依次放松这三个假设，处理四个真实工程维度：
撤离：把去激活拆成两步，先标记开始离开、立刻停止提供协效应，然后等待所有依赖方都完成拆卸后才真正应用累加器。这保证了消费者能在自己拆卸的整个过程中继续读取即将被撤走的依赖。
迭代：效应函数从单步升级为迭代器，可以在多次迭代之间被打断，对应真实运行时 async generator/yield 语义。
异步：引入 Future 抽象，核心性质是惯性——一旦一次迭代发起就必须落地，不能中途取消，只是落地后如果目标已变化，紧接着触发反向转换。
失败：效应函数可以抛出错误，失败走卸载路径先回收已装效应，再落到错误结局。失败记录在单个 fiber 上，不传播给父组件，兄弟 fiber 继续运行——这正是插件宿主想要的行为。
元理论部分给出了五大定理，分量极重：
- Preservation：十条规则都保持 registry 的良构性
- Temporal Composability：在效应两两独立的前提下，即使别的 fiber 动过状态，逆仍然精确撤销自身贡献的部分
- Spatial Composability：依赖方必须在提供方之后激活；绑定在整个依赖方 episode 内保持不变；一次转换的所有迭代针对同一个 resolution 运行
- Progress：在无循环依赖的前提下，系统不会死锁，且会终止在静止状态
- Confluence（全文高潮）：在效应独立、组件 provision 完整的前提下，无论编排者以什么顺序插入/移除、无论运行时以什么调度交织多个 fiber 的转换，系统最终收敛到的静止状态，与「按依赖顺序、静态一次性组装、从不卸载」得到的规范形式同构
Confluence 定理的实际意义很大：一个不断增删改组件、替换提供者、又撤销替换的编排系统，保证最终落在「把最终配置从头写一遍」得到的同一个状态。组件作者可以只推理静止状态下的依赖关系，不用操心中间过程的调度顺序。
Cordis 实现：理论与代码的对照
论文用一张表把每个数学符号映射到具体 API：ctx.effect、ctx.get/set、fiber.state、fiber.dispose 等。
核心库中，所有 context 变异都走单一原语 ctx.effect，内部用 execute 引擎驱动 effect iterator，每步把新逆 LIFO 折叠进累加器。dispose 自带自毁标志防止重复触发，并把自己的 dispose 前置到父 context 的累加器上，实现递归的父子组合。
协效应方面，ctx.get/set 实现两层解析（先查 realm，再查绑定）。notify 遍历所有 fiber，检查声明的键是否命中变化且 realm 匹配。isolate 和 intercept 都是派生 context，不需要显式逆——回收时直接丢弃派生部分即可。
组件生命周期的核心是 refresh/reload/unload 三个互相递归的函数，实现惯性状态机。refresh 检测目标变化决定发起哪个方向的转换；reload 记录 committed view、执行效应、完成后检查目标是否仍匹配；unload 先等待所有依赖方都到达 Inactive，再跑累加器。三行代码位置直接对应理论部分的三个排序保证：commit-before-run、标记 UNLOADING 在逆之前、等待依赖方完成。
组件加载器支持声明式配置，字段包括 id/url/isolate/intercept/config/disabled。增量协调的可靠性直接引用四条元理论保证：Confluence 保证最终状态只取决于最终配置，Progress 保证一定会收敛，Terminal Recovery 保证撤走一个 fiber 不留痕迹，Ordering 保证不需要人工排列加载顺序。字段级最小化操作分发：id/url 变就重建，isolate 变就重分配 realm，intercept 变就原地更新，config 变就转交组件自己 diff，disabled 变就卸载/重载。
HMR（热模块替换）也有三阶段算法：从改动文件出发做不动点计算标记依赖子图为 accepted 或 declined；遍历每个 entry 的依赖树检测陈旧条目；事务性重载（失效缓存前先备份，中途失败则恢复缓存，保证系统绝不停留在半重载状态）。这套 HMR 不需要开发者手动标注接受边界，因为 fiber 本身已经完整界定了组件的所有效应和协效应。
论文还用了 Koishi（4 年开发、4000+ 社区插件的聊天机器人框架）作为案例研究，验证了同一套模型跨越两个完全不同运行时（服务端和 Web console）、普通开发者不需要手写卸载路径、不同作者独立开发的插件通过共享 coeffect key 形成真实依赖拓扑。
关注公众号回复“进群”入群讨论