与 DeepSeek Harness 的关系

论文版本948a07b (main)

论文实现 Cordis,DeepSeek Harness 建在 Cordis 之上。但 Cordis、Koishi、DeepSeek Harness 是三个不同项目,不能混淆。

三个项目的关系

【基于原文与官方资料的推断】:

• Cordis:开源 meta-framework(MIT),实现论文描述的 spatiotemporal composability。仓库 github.com/cordiverse/cordis,核心包 cordis 当前版本 4.0.0-rc.x(对应论文 §5 描述的 Cordis v4)。它独立于 DeepSeek,由 cordiverse 组织维护(Shigma 是核心作者)。
• Koishi:开源 chatbot application framework(MIT),建在 Cordis 之上。论文 §5.3 案例研究:Koishi 当前用 Cordis v3,论文描述的是 Cordis v4,"the core compositional model is shared across both versions"。Koishi 有 4000+ 社区插件,是论文的生产案例。
• DeepSeek Harness(DSH):DeepSeek 开源的 Agent Harness(MIT),建在 Cordis 内核之上。仓库 github.com/deepseek-ai/deepseek-harness。官方文档明确:Cordis 内核管理插件挂载/卸载/依赖,Harness 建在 Cordis 插件系统之上,"Everything is a plugin"。

注意论文作者:Tianyi Cui(DeepSeek-AI)即 Shigma,是 Koishi 框架作者。所以 Cordis/Koishi/Harness 三者同源(都关联 Shigma),但论文不是 DeepSeek 独立完成——第一机构是 Peking University,第二机构才是 DeepSeek-AI。

为什么这套机制适合 DeepSeek Harness

【基于原文的推断】DSH 把 Tools / Skills / Sessions / Sandboxes / Storage / Loops / Sub-agent scheduling / UI 全部做成 Cordis 插件,因此:

1. Tool Provider 热替换:Agent 运行中替换某个工具(比如升级文件搜索工具的版本)→ Cordis 卸载旧 fiber、安装新 fiber,依赖该工具的 Session 和 Sub-agent 自动 re-resolve。整个过程由 Ordering 定理 保证:旧 provider 晚于 consumer 卸载,不会出现"用着已释放的工具"。
2. Sub-agent 独立环境:每个子 Agent 用 ctx.isolate 派生独立 context,同一 key(如 'filesystem')在不同子 Agent 中解析为不同实例。子 Agent 之间互不污染,父 Agent 可对子 Agent 施加不同 realm。
3. Sandbox 权限控制:通过 ctx.intercept 给社区插件施加更严格的访问策略(如只读文件系统),不修改插件代码即可限制其能力。
4. Trajectory 追溯:DSH 的 append-only session log 与 Cordis 的 effect accumulator 在精神上一致——都是"可回放的运行轨迹"。但要注意区分:DSH 的 session log 是 emission(§6.1)层面的记录,不可自动撤销;Cordis 的 accumulator 是 acquisition 层面的,可自动恢复。前者是"发生过什么"的日志,后者是"如何撤销已发生的副作用"的逆操作链。

DeepSeek Harness 现状

【基于官方资料的核实,2026-08-15】截至当前,DSH 仍是 Developer Preview,核心插件与 API 会继续演进。官方明确:"core plugins and APIs are expected to continue evolving"。

四种运行模式:

• Standard:完整编码 agent,暴露全部工具集;
• Code:暴露 Code Mode SDK,模型生成 TypeScript 来编排工具调用;
• Minimal:仅 bash + str_replace_editor 两个工具,用于 benchmark;
• Creator:构建自定义 preset,可检视运行时、测试插件、编写 preset。

Trajectory view 支持 resume / fork / search / replay,都基于 append-only session log——这呼应了论文 §1.2.2 对 self-evolving agent harness 的描述(可 fork、可回放、可持续服务请求)。

对其他 Agent Runtime 的启示

【个人评价】这套架构对 DeepSeek Harness、Claude Code、Codex、OpenClaw 等 Agent Runtime 的启示:

• Tool 热替换:Agent 运行中替换工具,不需要重启 session;
• 子 Agent 隔离:ctx.isolate 给每个子 Agent 独立依赖视图;
• 能力声明即权限:fiber.inject 即 capability 请求清单,可在加载时审计;
• Trajectory = Emission:append-only session log 是 emission(§6.1),不可自动撤销;要支持 resume/fork/replay 还需要 emission 层的 compensation 设计;
• 不可信插件:仍需进程/容器/WASM sandbox,Cordis 只提供语言级隔离。

但要注意:论文是 Cordis v4 的理论模型,DeepSeek Harness 是建在 Cordis 之上的 Developer Preview 产品。两者关系是"DSH 建在 Cordis 之上,Cordis 实现论文模型",不是"DSH 已经证明论文的所有结论"。详见 局限与证据强度。