DeepSeek Harness 深度事实核查：Cordis、Session、自扩展、VS Code/Notion 类比与 Pi 对比

deepseek-harness-fact-check.md

DeepSeek Harness：自进化 Agent、插件运行时，还是 Web 版 VS Code？

最近关于 DeepSeek Harness（下文简称 DSH）的讨论，大致分成两派：一派把它看成「Web 版 VS Code + 会修改自己的 Coding Agent」，另一派把它看成下一代「自进化软件」的雏形。

两边都抓到了一部分，但也都把不同层次的问题混在了一起。

这篇文章只讨论能从仓库、文档和论文直接确认的事实，再区分哪些是合理推断，哪些只是比喻或情绪。

研究基线：2026-08-14。DSH 47f9438，论文 948a07b，Pi 2a9b4eb。DSH 使用的是一份固定并带有本地修改的 Cordis 源码，而不是运行时直接跟随上游最新版；DSH 和 Cordis 都在快速变化，结论应绑定版本阅读。

先说结论

DSH 不是「换皮 VS Code」，也还不是成熟的自进化软件。

它真正特殊的地方是：不只允许 Agent 调用工具，而是把模型、工具、Session、Agent Loop、Sandbox 和 UI 都放进同一种可检查、可替换的组件模型里；在显式启用自指工具的 Cordis Preset 中，Agent 还能在运行中临时修改这棵组件树。

因此，更准确的定义是：

DSH 是一个基于 Cordis 的可组合 Agent Runtime，同时附带 Web 与 headless 两套官方产品组合；它已经实现进程内的自扩展实验，但还没有形成可持续、自主、安全的自进化闭环。

这个判断与官方状态一致：DSH 明确写着 Everything is a plugin、由 Cordis 驱动，同时仍处于 developer preview，并明确预告会有破坏性变更。[1]

一张图看懂 DSH

讨论里最容易混淆的是：Cordis、Session、Sandbox 和 Web UI 不是同一层。

flowchart TB
    A[Profile / Bundle / Patch<br/>决定装哪些组件] --> M

    subgraph CORDIS[Cordis 组件树：运行时组合]
      M[模型适配器]
      T[工具注册表]
      L[Agent Loop]
      S[Session 服务]
      X[Sandbox / FS / Shell]
      U[Web / Headless 入口]
    end

    L --> E[Session 追加式事件日志]
    E --> P[模型上下文 / 恢复 / 分支 / UI 投影]
    L --> X
    X --> W[文件、进程、网络和其他外部世界]

    C[Cordis 保证的主要是<br/>组件依赖与已登记效果的撤销] -.-> M
    D[Session 保证的主要是<br/>交互历史可重建] -.-> E
    G[Sandbox 才负责<br/>代码执行边界] -.-> X

Loading

三条边界必须分开：

1. Cordis 管运行中的组件。 谁依赖谁、什么时候启动、卸载时撤销哪些已登记效果。
2. Session 管持久化历史。 哪些消息、流式输出、工具调用会进入模型上下文，如何恢复和分支。
3. Sandbox 管执行权限。 代码能否接触宿主文件、进程、网络和凭证。

「插件能卸载」不等于「代码有安全隔离」，「Session 能回放」也不等于「外部副作用能回滚」。

“一切皆插件”到底意味着什么

DSH 的架构文档明确列出：模型适配器、工具注册表、Session Log 和 Agent Loop 本身都是 Cordis 插件，可以通过配置替换。启动时，Profile、Bundle、用户补丁和命令行补丁逐层叠加，最终得到一棵实际运行的插件树。[2]

实现上，DSH 把 Cordis 源码直接放进自己的 monorepo，固定版本并维护一组本地修改，其中包括生命周期加固和配置更新失败时的回退。也就是说，论文中的形式化模型、Cordis 上游实现和 DSH 实际发布的运行时相关，但不能不加区分地当成同一个东西。[10]

这比普通 Coding Agent 的扩展系统更彻底。普通扩展通常围绕一个固定 Agent 内核增加工具或事件监听；DSH 试图让内核的大部分实现也参与组合。

但「一切皆插件」不能按字面理解成「没有核心」。真正的核心被上移了：

flowchart LR
    subgraph 可替换的应用层
      A[模型]
      B[工具]
      C[Session]
      D[Agent Loop]
      E[UI]
    end

    subgraph 不可绕开的元层
      F[Cordis Runtime]
      G[服务 key 与接口]
      H[事件协议]
      I[生命周期规则]
      J[配置与作用域语义]
    end

    F --> A
    F --> B
    F --> C
    F --> D
    F --> E
    G --> F
    H --> F
    I --> F
    J --> F

Loading

所以 DSH 不是无核心，而是：

应用核心可替换，组合协议成为新的核心。

这也是「DSH 在创造新的 DSL」这个批评成立的地方。cordis.yml、服务依赖、作用域、Profile、Bundle、Preset、事件和 Session Event，合起来就是一套描述 Agent Runtime 的语言。

但任何框架都会引入自己的语言。真正的问题不是「有没有 DSL」，而是它是否换来了可验证的约束。Cordis 当前确实换来了三件具体能力：

• 插件通过 inject 声明依赖；依赖未出现时保持等待，依赖消失时停止，恢复后重新启动。
• 工具、监听器、服务和 Prompt 片段等注册可以归属到插件生命周期，卸载时自动撤销。
• Loader 可以根据配置局部装卸组件，而不必把整个进程内状态全部丢掉。

这不是纯粹换名词；代价则是配置、命名、依赖图和调试模型明显变复杂。[9]

Cordis 能回滚什么，不能回滚什么

Cordis 论文把两个目标称为 Temporal Composability 和 Spatial Composability。去掉术语，就是：

• 一个组件被移除时，撤销它在受控范围内留下的效果。
• 一个服务出现、消失或替换时，只重连真正依赖它的组件。

重点在「受控范围内」。

flowchart LR
    P[插件运行] --> R1[注册工具]
    P --> R2[注册服务]
    P --> R3[注册监听器]
    P --> R4[注册 Prompt 片段]
    P --> O1[写文件]
    P --> O2[发网络请求]
    P --> O3[修改数据库]
    P --> O4[启动脱管进程]

    R1 --> K[由 Cordis 记录 disposer<br/>卸载时可撤销]
    R2 --> K
    R3 --> K
    R4 --> K

    O1 --> Q[不会天然回滚<br/>需要事务、补偿或外部隔离]
    O2 --> Q
    O3 --> Q
    O4 --> Q

Loading

因此，「改炸了就退回隔离墙」是不准确的。Cordis 提供的是副作用归属与生命周期清理，不是容器或虚拟机意义上的安全墙。

论文自己也明确承认这个系统边界：文件内容、网络发送、支付等效果一旦离开系统可独占恢复的范围，只能依靠延迟提交、事务或补偿操作，形式化的自动撤销不再直接成立。[3]

论文中的 Confluence 也不是「随便热更新多少次，最终都一定等于干净重启」。定理要求最终没有失败组件、依赖无环、组件满足完整性要求、相关步骤彼此独立，并比较相同的外部编排输入。它证明的是一个受条件约束的运行时状态性质，不是对任意 JavaScript、外部副作用或 DSH 产品行为的无条件担保。[3]

DSH 当前的“自进化”到底做到了哪一步

DSH 确实提供了五个面向模型的自指工具。它们不是每个会话的默认能力，而是由专门的 Cordis Agent Preset 显式挂载；该 Preset 在 Standard 组合之上增加自指工具和组合编写指导。[12]

• cordis_inspect：查看当前进程中的服务、插件、工具和可用接口。
• cordis_define：定义一个临时组件，可以包含 Host 代码和浏览器端代码。
• cordis_run：运行组件。
• cordis_stop：停止并撤销组件登记的效果。
• cordis_undefine：删除定义。

运行中的组件可以给后续请求增加工具、Prompt 或监听器，也可以向 Web UI 的预留位置插入界面。这个能力是真实存在的。[4]

但当前状态更接近「自扩展实验室」：

flowchart LR
    A[Agent 检查 Runtime] --> B[现场生成组件]
    B --> C[内存中挂载]
    C --> D[后续轮次立即使用]
    D --> E[停止 / 卸载]

    E -. 当前没有自动闭环 .-> F[测试与评分]
    F -.-> G[灰度启用]
    G -.-> H[持久化与版本化]
    H -.-> I[跨重启恢复]
    I -.-> J[自动晋升或淘汰]

Loading

仓库明确写出的限制包括：

• 动态组件只存在于当前 DSH 进程内存，重启后消失。
• 不会创建正式插件文件，不会修改 cordis.yml，也不能自动晋升为永久插件。
• 组件可能影响同一进程中的其他 Session。
• 纯 Host 组件会直接在当前进程运行；包含浏览器代码的组件需要页面上的人批准。没有页面连接时，请求会一直等待，直到该轮被取消。
• VM 只隔离部分全局对象，不是安全边界；官方要求把这套工具当成 bash 权限看待。
• 当前动态组件公开的 façade 甚至没有通用 ctx.effect()，只能依赖受支持的注册路径完成自动清理。
• 改变工具或 Prompt 会改变后续模型请求前缀，可能降低 KV Cache 复用。

这些限制不是推测，分别写在自指工具和 Host Runner 的契约里。[4] [11]

因此，称它为「自进化软件的雏形」可以；称它已经实现安全、持续的自进化则不符合事实。

论文同样把 self-evolving agent harnesses 写成未来验证方向，不是 Cordis 已经完成的实证结论。论文仍是持续修订中的预印本。[3]

Session Event Sourcing 是另一条轴

DSH 的 Session 使用追加式事件日志。官方架构文档的原话是：Session Log 是模型上下文的来源，deriveMessages() 从日志投影模型历史，原始 assistant/chunk 用于保持回放和 UI 的完整性；“Model-visible means logged”。[2]

这解决的是：

• 请求历史如何重建；
• Session 如何恢复和分支；
• Web UI、转录和遥测如何从同一历史生成。

它不解决：

• 动态插件是不是安全；
• 文件和网络副作用能否回滚；
• Agent 修改 Runtime 后是否语义正确。

把 Session Event Sourcing 与 Cordis 的可逆组件混在一起，会产生一种错误印象：仿佛 DSH 已经拥有统一的「时间机器」。实际上，一个负责持久化交互历史，另一个负责进程内组件生命周期。

DSH 是不是 Web 版 VS Code

这个类比有一半成立：

• 两者都有可扩展宿主、编辑/执行环境和插件生态。
• DSH 的官方主要交互界面确实是 Web，浏览器端组件也可以动态插入 UI。
• 从工程上推断，Web 架构减少了桌面原生适配工作，也容易再封装成桌面客户端；但这是合理推断，不是仓库给出的作者动机。

但核心差异也很明确：

• VS Code 的 Agent 或编辑器内核不是由同一种扩展协议完整组成。
• Cordis 专门研究组件的独立卸载、依赖消失后的重新解析以及局部热替换。
• Cordis 论文本身就把 VS Code extension host 的实时卸载和依赖表达限制当成动机之一，而不是隐藏这种亲缘关系。[3]

所以更准确的说法是：

DSH 借用了 IDE/插件宿主的产品形态，但它的研究重点是把这种动态组合继续推进到 Agent Runtime 内部。

「DeepSeek 要干翻 VS Code」「为了避嫌才把 extension 叫 plugin」都找不到一手证据，只能算段子，不能当成作者动机。

另外，说 DSH「没有 CLI」也不准确。它有 dsh 启动器，官方提供 Web 和 headless 两个 Profile；Web 是主要交互界面，headless 是一次性运行器，外部也可以安装其他 Profile。[5]

和 Notion 的类比为什么比较弱

Notion 和 DSH 都有「用统一基本单元拼出产品」的倾向，因此在产品哲学上确实有一点亲缘关系。

但技术对象不同：

• Notion 主要组合文档、数据库和 UI 内容块。
• DSH/Cordis 组合的是带依赖、资源和生命周期的运行中服务。

Notion 做得好不好，不能直接证明 Cordis 的组件模型是否成立。这个类比可以帮助描述气质，不能承担架构论证。

DSH 和 Pi 的准确关系

「Pi 是最小核心，DSH 是完整可组合 Runtime」大体正确，但真正的差别不只是默认工具多少。

维度	Pi	DeepSeek Harness
官方定位	Minimal terminal coding harness	Everything-is-a-plugin Agent Runtime
稳定中心	清晰的 Agent/Core + Extension API	Cordis 元运行时与组件协议
默认形态	TUI，默认四个工具	Web/headless，多套 Bundle 与 Agent Preset
扩展对象	工具、事件、UI、Provider 等 Agent 周边能力	模型、工具、Session、Loop、UI 等 Runtime 组成部分
重载粒度	关闭旧扩展实例，重建并重新绑定扩展运行时	依赖驱动地装卸组件并重启受影响的消费者
自扩展	Agent 可以编写 Extension，通常落到文件后 reload	Agent 可检查并直接挂载进程内临时 Host/UI 组件
主要代价	深度替换内核时需要进入 SDK 或修改实现	概念、配置、依赖图和调试复杂度更高

DSH 也不总是给模型一套庞大工具。它同时提供 Minimal、Standard、Code 和 Cordis 等 Agent Preset：Minimal 只有固定 Prompt、持久 Bash 和字符串编辑器，而且不启用压缩；Code 则在 Standard 上增加程序化工具编排。因此所谓「DSH 更重」主要指 Runtime 和控制面的概念更多，不等于每种 Preset 的模型工具面都更大。[13]

Pi 也允许 Agent 编写 Extension，也支持热重载。所以「Agent 写代码扩展自己」本身不是 DSH 独有的创新。DSH 更特别的赌注是：让产品内部组件和模型现场生成的组件服从同一套运行时组合规则。 [6]

DSH 确实复用了 pi-ai，但只是在一个 LLM Adapter 插件中使用它的多 Provider、协议和模型目录能力。Agent Loop、Session、工具、Sandbox 和 Web UI 仍是 DSH/Cordis 自己的体系。[7]

为什么模型经常绕过 Plugin，直接改代码

这是很重要的现实问题。

对模型来说，下面这条路径在训练数据中非常常见：

读文件 → 改文件 → 跑命令 → 看结果

而 DSH 希望它学习的是：

检查运行时
→ 区分 Host / Agent 平面
→ 找到服务和 UI slot
→ 声明依赖与作用域
→ 定义组件
→ 挂载并观察生命周期

如果两条路径能完成相同任务，模型自然偏向更短、更熟悉的一条。这不证明 Plugin 没价值，但说明 DSH 的结构优势还没有完全转化成模型的操作优势。

一个实用判断是：

• **一次性任务或独立自动化：**脚本通常更简单。
• **需要持续参与 Agent Loop、注册工具、修改 Prompt、提供 UI、替换服务并随组件自动清理：**Plugin 才真正值得。

如果所有功能都不加区分地包装成 Plugin，「一切皆插件」就会从统一机制变成额外仪式。

论文和宣传中最容易被说大的部分

说法	基于事实的判断
DSH 基于 Cordis	确定为真。 当前 README 和架构文档明确写明。
所有重要能力都能配置替换	基本为真。 但 Cordis、协议和启动器仍构成元核心。
Cordis 是天然隔离墙	错误。 它主要管理生命周期，不是安全 Sandbox。
改坏插件后所有影响都能自动回滚	错误。 只覆盖被追踪、且仍在系统边界内的效果。
Confluence 证明任意热更新都等于干净重启	错误。 定理有无失败、无环、独立性等明确条件。
DSH 已经实现自进化	夸大。 当前是进程内、临时、不可自动晋升的自扩展。
Koishi 的 4000+ 插件证明 Cordis v4 已成熟	不成立。 论文注明 Koishi 当前使用 Cordis v3；v4 继承核心模型但重做了部分语义与 Loader。
DSH 没有 CLI，只是网页	错误。 有 CLI 启动器，并提供 Web/headless Profile。
DSH 整体基于 Pi	错误。 只是一个 LLM Adapter 复用了 pi-ai。
DSH 很快	可能是体验事实，但不是架构事实。 没有统一基准不能推广。
DSH 可观测性很强	有代码和 UI 测试支持。 当前界面确实展示 Duration、Turns、Calls、TTFT、吞吐和 Cache hit 等信息。[8]
DSH 代码很“函数式”，不懂 OCaml/Haskell 很难读	影响存在，但说大了。 论文使用 effect、coeffect 和形式化演算；实现则是 TypeScript 的服务容器、事件、Fiber 和可变生命周期。难点主要是 Cordis 的运行时模型，不是先会 OCaml/Haskell。[3] [9]
Turn / Step 来自 Claude Code	没有足够证据。 DSH 确实有明确的 Turn/Step 流程，但命名和流程相似只能说明 Coding Agent 的问题结构接近，不能证明代码或设计来源。[2]
“Plugin”是为了避开 VS Code 的 Extension 命名	没有证据。 Cordis/Koishi 本来就使用 Plugin 这个词，沿用传统是更简单的解释，但作者动机仍不可由此确认。
最近一个月增长了上万 commits	按仓库历史基本属实。 在固定 commit 上执行 git rev-list --count --since=2026-07-14 HEAD 得到 10,557；但 commit 数受拆分习惯影响，不能直接代表功能量或工程质量。[14]
DSH 就是 Agent OS	可以当比喻，不能当事实。 Cordis 本身不是 OS 级安全或故障边界；DSH 的工具进程可以换用 Sandbox Provider，但动态组件的 VM 明确不是安全边界。

真正困难的工程问题

DSH 的方向有价值，但要从实验性 Runtime 走到可靠的自进化系统，至少要正面解决下面这些问题。

1. 效果覆盖率

只要插件能绕过 Cordis 直接写全局状态、文件或网络，自动撤销就不完整。系统必须让正确路径比绕过框架更容易，并能检测未登记资源。

2. 安全边界

当前动态组件被明确视为 bash 等级权限。真正的不可信自修改需要独立进程、容器、虚拟机或其他受限 Runtime 等外部边界，以及精确的能力授权。

3. 行为正确性

「能卸载」只说明资源可以清理，不说明新组件做对了。自进化还需要测试、评估、回归比较、预算、人工审批和自动降级。

4. 持久化和晋升

临时组件如何变成可审计的正式插件？需要源码归档、依赖锁定、版本、签名、迁移、回滚点和跨重启恢复。DSH 当前明确没有自动晋升。

5. 依赖与版本兼容

论文承认当前依赖主要通过 key 身份连接。独立插件可能遇到接口漂移、key 冲突和语义版本不可信等问题；Cordis 目前主要依靠包管理器 peer dependency 与 semver，不能证明运行时行为兼容。

6. 共享进程的爆炸半径

动态组件可以影响同进程其他 Session。作用域和 realm 能减少冲突，但 Host/Agent 平面的配置规则本身已经相当复杂；错误归属可能把局部修改变成进程级修改。

7. 模型认知成本和缓存成本

模型必须学习新的服务、事件、作用域和 UI slot 协议。动态修改工具 Schema 或 Prompt 还可能破坏请求前缀稳定性，降低 KV Cache 命中率。框架越开放，模型可选择的错误路径也越多。

8. 诊断复杂度

依赖缺失时组件可能合法地保持 PENDING；热替换还涉及异步卸载、依赖重启和跨页面 UI 状态。DSH 的强可观测性不是装饰，而是这种架构能够被调试的必要条件。

最后的判断

几种流行评价里：

• 「Web VS Code」讽刺版准确看到了产品形态并不全新，也看到了模型更偏爱直接改文件；但它把组件生命周期、Sandbox 和安全回滚混为一谈，对作者动机的描述没有证据。
• 「乐高汽车」版最接近仓库事实；但从可插拔直接推导到自进化，跳过了评估、隔离、持久化和晋升四个关键环节。
• 「PL 人写 OS」版抓住了 DSH 对依赖、能力和生命周期的关注；但 DSH 当前更像进程内组件 Runtime，而不是拥有安全与资源边界的 OS。
• **「技术理想主义玩具」**作为成熟度判断有一定依据：项目确实是 developer preview，接口和生态都不稳定；如果用它否定架构价值，则过于草率。

最值得保留的一句话是：

DSH 的新意不在于 Agent 会写代码，而在于它试图让 Agent 修改自身运行时拓扑，并让这些修改具备可检查的依赖和可撤销的生命周期。

这项尝试是真实而有技术含量的；但截至当前版本，它证明的是「自扩展 Runtime 可以怎样构造」，还没有证明「自进化软件已经可用」。

资料来源

1. DeepSeek Harness README，固定于 47f9438
2. DeepSeek Harness Architecture，固定于 47f9438
3. A Programming Paradigm for Spatiotemporal Composability，2026-08-13 预印本：重点见 pp. 5–6、49–53、66、69–72、79。
4. DSH Self-referential Cordis Toolset
5. DSH CLI、Profile 与 Bundle
6. Pi Coding Agent README 与 Philosophy，固定于 2a9b4eb；Pi Extension 生命周期
7. DSH 的 pi-ai LLM Adapter
8. DSH Web trajectory UI 快照；调用统计快照
9. DSH Cordis Primer：服务、依赖、事件与可撤销注册；服务消失与恢复时的生命周期
10. DSH Vendored Packages：固定的 Cordis 来源与本地修改
11. DSH Cordis Host Runner：动态组件的运行、人工批准和信任边界
12. DSH Cordis Agent Preset：在 Standard 组合上显式加入自指能力
13. DSH Minimal Preset；DSH Code Preset
14. DSH 固定版本的提交历史。计数命令见正文，基于完整非 shallow checkout。