昨天，DeepSeek 接连发布了 DeepSeek V4 Pro 正式版模型和 DeepSeek Harness 开发者预览版，AI 社区宛如过年，褒奖、评测、争吵接连不断。截至本文发稿，开源仅一天的 DeepSeek Harness，star 数已接近 9.5 万，fork 数也达到了 8.8k，并仍在持续上涨。

是的，DeepSeek Harness 非常受欢迎。而它受欢迎的一大原因，藏在一个很多人还没注意到的名字里：Cordis。

先说 Harness 本身。它是一个跑在本地的编程智能体，可简称 dsh，读文件、跑命令、改代码、查资料，差不多就类似于 Claude Code。

真正让它区别于同类的是设计方式：一切皆插件。

模型接入、工具注册表、会话日志、审批策略，连驱动智能体运转的主循环本身，全都是插件。

想换搜索引擎、接自己公司的模型服务，改配置就行，不用动框架代码；给系统加功能就是挂一个新插件，卸载时注册的一切自动撤销，不留残余。

支撑这件事的就是 Cordis。它是一套以依赖注入和可逆副作用为核心的插件与上下文内核，来自 Koishi 生态，只负责插件的加载、卸载和依赖关系。dsh 的所有具体组件都是不同插件，靠服务与事件协作，在配置层自由组合。

这套底座的一大用法，从界面的模式选择器里就能看到。

四档模式里，标准模式功能最全，PTC 模式让模型生成一段代码来组合多轮工具调用，极简模式只留一个终端和一个文本编辑器、系统提示词只有一句话，适合跑基准测试。它们都是在既有的插件树上做加减法。

而第四档「创造模式」不一样，它是一组自指的 Cordis 工具，是高级入口：选择这一预设后，Agent 可以检查当前运行时的插件树，并动态挂载或卸载临时插件。模型可以临时写一个事件监听器、注册一个新工具、提供一个服务，任务完成后再把它卸掉。

DeepSeek Harness 默认的四个模式以及使用创造模式构建的 Obsidian 笔记模式

这听上去有点像让汽车在高速公路上给自己换发动机，所以项目没有默认打开它，信任等级被标注为等同于 shell 访问权限。临时插件只存在于进程内存里，不写文件、不装包、不改配置，重启即消失。

自修改式 Agent 的难点之一是写完之后怎么把组件干净地拿下来：一次自我修改留下的事件监听器、打开的连接、注册进去的服务，如果没有一条明确的回收路径，系统运行几个小时就会变成一堆无人认领的残留。dsh 的做法是把动态插件仍然放进已有的插件生命周期里，跑在 Cordis 的 Context 和 Effect 机制下，注册项有确定的清理路径。

这套机制的设计依据，已经写在 DeepSeek 同步发布的一篇论文里：《A Programming Paradigm for Spatiotemporal Composability（时空可组合性的一种编程范式）》。作者包括北京大学的 Yifan Shi（同时属 DeepSeek）、张伟（Wei Zhang），以及 DeepSeek 的崔添翼（Tianyi Cui）。这不是一篇 Agent 论文，甚至几乎不谈模型，它是一篇编程语言理论的论文，八十页，正文里有二十多个定理和证明。

论文地址：https://github.com/cordiverse/paper

软件工程的基石是组合

论文开篇提出的问题已经颇有历史：软件工程的基石是组合，把复杂系统拆成简单部件再拼起来。但传统的组合是静态的：函数调用、模块导入、类继承，编译期就确定，运行期不再变化，这套东西有极其丰富的形式化基础。

而现代软件越来越需要动态组合：组件在运行时被加载、卸载、重新配置。

论文的判断是，相比静态组合，动态组合方向的理论基础仍然欠缺，工业界的通行做法是绕开它。

作者拿 VSCode 做了实证。VSCode 的所有扩展跑在一个共享进程里，虽然扩展可以动态安装，但这个 Host 没有提供任何在运行时卸载单个扩展代码的机制。一旦某个扩展的 activate 执行过，禁用或卸载它就要重启整个 Host，影响所有已加载的扩展。论文统计了安装量前 100 的扩展，其中 87 个包含可执行代码，也就是说移除它们都需要一次重启。

VSCode 确实提供了 deactivate 钩子，但它只是 Host 进程终止时的优雅关闭回调，无法用于在线移除；而且这个钩子把副作用的销毁和副作用的产生（在 activate 里）分开了，破坏了关注点的局部性，完整清理很难被验证。

依赖那一侧也很稀薄。VSCode 提供了 extensionDep

来源：机器之心