Frontend · Artificial Intelligence · Agent

DeepSeek Harness Runs on an Engine Where the Agent Loop Itself Is a Replaceable Plugin

By 一拳不是超人 · Aug 15, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Agent frameworks are still evolving fast, and locking scheduling logic into a fixed core forces teams to fork and maintain diffs. Cordis makes every component swappable through service keys and reversible side effects, so replacing the agent loop, filesystem, or tool pipeline is a plugin swap—not a rewrite.

Summary

DeepSeek Harness (DSH) rejects the fixed-core architecture of LangChain and AutoGen by building on Cordis, a meta-framework validated by over 4,000 community plugins. In DSH, the model adapter, tool registry, session log, and even the agent loop itself are all ordinary plugins—no component is irreplaceable, and no fork is required to change core scheduling logic. The system ships with 159 default plugins, all collaborating through service keys and typed events rather than hardcoded imports.

Cordis enforces automatic cleanup through a single primitive, `ctx.effect()`, which tracks every side effect and rolls them back in LIFO order when a plugin unloads. This makes hot-reloading safe: modifying a tool plugin automatically disposes the old instance and reloads the new one without other plugins noticing. Dependencies are declared via `inject`, and the framework handles loading order and lifecycle linkage—when a service disappears, its consumers pause; when it returns, they reload.

Product modes—Standard, PTC, Minimal, Creative—differ only in which plugin set a YAML profile loads. Swapping the local filesystem for a remote sandbox requires only a new Seam provider; Bash, PTY, and LSP tools migrate automatically because they consume the `ctx.fs` service key, not a concrete import. The architecture turns product configuration into plugin-tree assembly, letting one codebase spawn development tools, CI bots, and benchmarking platforms without maintaining multiple forks.

Takeaways

— Every component in DSH—model adapter, tool registry, session log, agent loop—is an ordinary plugin; no component has privileged access to the framework.

— Cordis wraps each plugin in a Fiber state machine that tracks dependencies and automatically pauses or resumes plugins as services appear or disappear.

— The `ctx.effect()` primitive registers side effects with a teardown function; on unload, Cordis calls all teardowns in LIFO order, preventing memory leaks without manual cleanup code.

— Plugins collaborate exclusively through Seams—service keys on `ctx`—so replacing a provider like the filesystem migrates all consumers automatically with zero code changes.

— Four built-in product modes (Standard, PTC, Minimal, Creative) differ only in which plugin set a YAML profile loads; no `if` branches exist in the codebase.

— Hot-reloading a tool plugin disposes the old instance, rolls back all its listeners and timers, then loads the new instance—other plugins only see the tool list change.

— External resources like timers, database connections, and file watchers must be wrapped in `ctx.effect()`; Cordis APIs like `ctx.on()` and `ctx.provide()` clean up automatically.

Conclusions

The claim that 'even the agent loop is a plugin' is not marketing—DSH's `agentLoop` service key is provided by a plugin that can be disabled and replaced, which is architecturally impossible in LangChain or AutoGen without forking.

Cordis's `ctx.effect()` LIFO rollback is a stronger guarantee than React's `useEffect` cleanup because it is enforced by the framework's Fiber disposal, not left to developer discipline.

The Seam model turns what would be a major refactor in other frameworks—swapping local filesystem for remote sandbox—into a single `ctx.provide('fs', newImpl)` call that automatically propagates to Bash, PTY, and LSP tools.

DSH's four product modes being pure configuration files means the same codebase can produce a web UI, a headless CI bot, and a benchmarking harness just by loading different plugin trees—no feature flags or build-time conditionals.

The 159 default plugins suggest DSH is already a substantial system, but the architecture's real test will be whether third-party plugin ecosystems form around it the way Koishi's 4,000+ plugins validated Cordis in the chatbot domain.

Concepts & terms

Cordis

A meta-framework that manages plugin loading/unloading, service dependencies, and event distribution. It provides no agent logic itself; all behavior comes from plugins mounted on it.

Fiber

Cordis's lifecycle container for each plugin, with a state machine (PENDING → LOADING → ACTIVE → DISPOSING → DISPOSED) that tracks dependencies and automatically pauses or resumes plugins.

ctx.effect()

A Cordis primitive that registers a side effect and its teardown function. On plugin unload, all teardowns execute in LIFO order, ensuring automatic cleanup of timers, listeners, and connections.

Seam

Cordis's sole cross-plugin collaboration model. Plugins provide capabilities via `ctx.provide('key', impl)` and consume them via `ctx.key`; the framework only recognizes service keys, not concrete implementations, so any provider can be swapped without changing consumers.

Waterfall event

A Cordis event mode where listeners form a chain, each receiving the previous listener's result and calling `next()` to pass control forward. Not calling `next()` short-circuits the chain, enabling interception and rejection patterns.

Profile

A YAML configuration that defines which plugin set loads for a given product mode. DSH ships Standard, PTC, Minimal, and Creative profiles; switching modes means loading a different plugin tree with no code changes.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗