Relationship with DeepSeek Harness

论文版本948a07b (main)

The paper implements Cordis, and DeepSeek Harness is built on Cordis. But Cordis, Koishi, and DeepSeek Harness are three distinct projects; do not conflate them.

The three projects and how they relate

[Inference based on the paper and official sources]:

• Cordis: an open-source meta-framework (MIT) that implements the spatiotemporal composability described in the paper. Repository github.com/cordiverse/cordis; the core package cordis is currently at version 4.0.0-rc.x (corresponding to Cordis v4 described in the paper §5). It is independent of DeepSeek and maintained by the cordiverse organization (Shigma is a core author).
• Koishi: an open-source chatbot application framework (MIT) built on Cordis. Paper §5.3 case study: Koishi currently uses Cordis v3, and the paper describes Cordis v4; "the core compositional model is shared across both versions". Koishi has 4000+ community plugins and is the paper's production case.
• DeepSeek Harness (DSH): an open-source Agent Harness (MIT) from DeepSeek, built on top of the Cordis core. Repository github.com/deepseek-ai/deepseek-harness. The official docs are explicit: the Cordis core manages plugin mount/unmount/dependencies; the Harness is built on top of the Cordis plugin system, "Everything is a plugin".

Note the paper's authors: Tianyi Cui (DeepSeek-AI), i.e. Shigma, is the author of the Koishi framework. So Cordis / Koishi / Harness are all of the same lineage (all connected to Shigma), but the paper is not solely a DeepSeek effort — the first institution is Peking University; the second institution is DeepSeek-AI.

Why this mechanism suits DeepSeek Harness

[Inference based on the paper] DSH makes Tools / Skills / Sessions / Sandboxes / Storage / Loops / Sub-agent scheduling / UI into Cordis plugins, so:

1. Tool Provider hot replacement: replace a tool while the Agent is running (e.g. upgrade the file-search tool's version) → Cordis unloads the old fiber, installs the new fiber, and Sessions and sub-Agents that depend on that tool automatically re-resolve. The whole process is guaranteed by the Ordering theorem: the old provider unloads after its consumers, so there is no "using a tool that has already been released".
2. Sub-Agent independent environment: each sub-Agent uses ctx.isolate to derive an independent context, and the same key (e.g. 'filesystem') resolves to different instances in different sub-Agents. Sub-Agents do not pollute each other; the parent Agent can apply different realms to different sub-Agents.
3. Sandbox permission control: apply stricter access policies to community plugins (e.g. read-only filesystem) via ctx.intercept, restricting their capabilities without modifying plugin code.
4. Trajectory tracing: DSH's append-only session log and Cordis's effect accumulator are in the same spirit — both are "replayable run traces". But note the distinction: DSH's session log records at the emission level (§6.1) and cannot be automatically reverted; Cordis's accumulator is at the acquisition level and can be automatically recovered. The former is a log of "what happened"; the latter is an inverse-operation chain of "how to revert the side effects that happened".

DeepSeek Harness current status

[Verified based on official sources, 2026-08-15] As of now, DSH is still in Developer Preview, and core plugins and APIs will continue to evolve. The official statement: "core plugins and APIs are expected to continue evolving".

Four run modes:

• Standard: full coding agent exposing the complete toolset;
• Code: exposes the Code Mode SDK; the model generates TypeScript to orchestrate tool calls;
• Minimal: only bash + str_replace_editor tools, for benchmarking;
• Creator: build custom presets, inspect the runtime, test plugins, write presets.

The Trajectory view supports resume / fork / search / replay, all based on the append-only session log — echoing the paper §1.2.2's description of a self-evolving agent harness (forkable, replayable, able to serve requests continuously).

Implications for other Agent Runtimes

[Personal evaluation] The implications of this architecture for Agent Runtimes like DeepSeek Harness, Claude Code, Codex, OpenClaw, etc.:

• Tool hot replacement: replace a tool while the Agent runs, without restarting the session;
• Sub-Agent isolation: ctx.isolate gives each sub-Agent an independent dependency view;
• Capability declaration is permission: fiber.inject is the capability request list and can be audited at load time;
• Trajectory = Emission: the append-only session log is an emission (§6.1) and cannot be automatically reverted; supporting resume/fork/replay still requires compensation design at the emission layer;
• Untrusted plugins: still need process/container/WASM sandbox; Cordis only provides language-level isolation.

But note: the paper is the theoretical model of Cordis v4, and DeepSeek Harness is a Developer Preview product built on Cordis. The relationship is "DSH is built on Cordis, and Cordis implements the paper's model", not "DSH has already proven all of the paper's conclusions". See Limits and evidence strength.