Everything Is a Plugin: Announcement vs Source
Which files in the deepseek-harness repo match the four modes and plugin ecosystem from the launch post? This lesson maps them one by one.
The demo below turns the four plugin lists into a switchable panel. Hit the four mode buttons and watch cards light up or go dark: green means added, red means removed, amber means same name but different config. The caption at the bottom narrates each step. Play until it clicks — every idea later already ran once on this panel.
What problem it solves.Imagine a monolith Agent product where you want a different session-log format. You fork the repo, hunt the logging code across hundreds of thousands of lines, rebuild, then re-merge patches every upstream release. That’s just a side feature — swapping the agent loop is basically rewriting the product. Capabilities welded to product source turn every deep customization into long-term maintenance debt.
What the idea is.DSH shrinks the kernel to the minimum. The Cordis framework vendored into the repo does only three things: load plugins into a shared context, unload them, and record every registration as a reversible side effect that rolls back on unload. Zero business logic. Every capability moves into packages/ — 49 groups, 219 packages, all plugins: model adapters, tools, session logs, even the agent loop itself. Line 3 of the root AGENTS.md says in bold English “everything is a plugin.” The official docs put it this way:
Cordis is the framework under dsh: plugins contribute services, typed events, and reversible side effects to a shared context. Every part of the product is a plugin — model adapters, the tool registry, session logs, and the agent loop itself — so each part can be replaced from configuration.
There is no privileged kernel you have to patch: you extend dsh by mounting plugins beside other plugins, and every registration is a side effect that is undone when its plugin unloads.
docs/architecture.zh.md · lines 11, 13You can add capabilities to DSH without touching its repo. Out-of-tree plugins (outside the official repo) install into a profile with dsh plugin --profile <name> add <package>, mount at runtime, and roll back registered side effects on unload. The README also asks plugin repos to tag the dsh-plugin topic so they’re discoverable. The launch post invites co-building the ecosystem — the mechanism is already there.
Why it lasts.The microkernel idea is older than this codebase. Mach and L4 from OS class, browser extension systems, VS Code’s plugin ecosystem — same path: fast-changing capabilities on the outer ring, nearly fixed load/unload mechanics in the core. If DSH rewrites the agent loop next year, Cordis’s load/unload logic doesn’t move a line; rewrite the whole harness in another language and the layering still holds. So remembering this course’s structure beats memorizing its code — the code is just one implementation of the idea.
What problem it solves.Most products hard-code modes: scattered branches like if (mode === 'lite'), with the mode count frozen the day the code is written. Adding a mode means change code, pass tests, wait for a release; tweaking one capability inside a mode is the same pipeline. Users get even less choice — pick among a few official packages.
What the idea is.In DSH a mode is a directory under apps/cli/config/agent-presets/ with two files. preset.yml is just 3 lines for UI display name and sort order; agent.cordis.yml is the plugin list — at boot Cordis mounts it line by line and outputs an assembled Agent. Switching modes means swapping lists and reassembling; there are no mode branches in source. The four-mode differences fit on four cards:
Standard mode
agent-presets/standard/ · 251 lines- Who it's for
- People who write code day to day — this is the default tier.
- Relation to other modes
- It’s the baseline: 23 plugins fully on (macOS view) — file edit, shell, search, plan, subagents, workflows. The other three modes are all described as add/drop relative to it.
- The idea behind it
- Define a full-capability reference first; only then can other combos explain themselves in one sentence.
PTC mode
agent-presets/code/ · 262 lines- Who it's for
- People running long multi-step tasks who find one tool-call round-trip at a time too slow.
- What it adds or drops vs standard
- standard untouched; append one tool-presentation with
mode: code. The model writes a small TypeScript program; one run_code executes what used to take five round-trips. - The idea behind it
- Only how tools are presented changes — capabilities stay the same — so the delta only deserves one line.
Minimal mode
agent-presets/minimal/ · 62 lines- Who it's for
- People running model benchmarks.
- What it adds or drops vs standard
- Only 6 plugins left. persona is locked in one sentence (
complete: true— other plugins can’t append prompts), tools are only persistent bash and str_replace_editor, no compaction (context compression). - The idea behind it
- Strip harness variables clean; what’s left is the model itself.
Creative mode
agent-presets/cordis/ · 262 lines- Who it's for
- People who want Agents to build Agents.
- What it adds or drops vs standard
- On top of the full standard set: the tool-cordis toolset, a skill that teaches composition, and a different persona version. The Agent can inspect and mount its own plugins at runtime; compositions can be saved as new presets.
- The idea behind it
- The assembler is itself a plugin, so it can be opened to the Agent. The file-header comment warns you to treat sessions in this mode like shell privileges.
One marketing word to puncture. Line 1 of code/preset.yml says name: PTC 模式, but the directory is code; source comments and docs call the mechanism Code Mode, and there’s no PTC-named implementation anywhere in the repo. PTC lives only in UI copy — when you talk source, say Code Mode so it lines up.
Why it lasts.This idea has a common name: configuration as architecture. Fold behavioral differences between systems into a declarative list, and architecture problems shrink into text problems. Diff two YAMLs to see how modes differ; copy a directory and tweak a few lines for a new mode; roll back the list when things break. Kubernetes declares clusters in YAML, Docker declares images with Dockerfiles — same idea at different layers. Even if every DSH plugin implementation is rewritten someday, the list abstraction still holds.
Everything-is-a-plugin only clicks when you put peers beside it. Same question — add a new capability to an Agent, do you need to touch its repo source — three answers from three shops:
DSH: plugin tree
No repo change neededA capability is an out-of-tree npm package. dsh plugin --profile <name> add <package> installs into a profile, mounts at runtime, rolls back registered side effects on unload. Mode-level differences are just a few YAML lines added or removed.
Source: packages/bundle/README.zh.md line 13; docs/architecture.zh.md line 13
Claude Code: product monolith
It dependsThe restored source is a TypeScript monolith tree (restored-src/src/, entry main.tsx) — changing built-ins means touching product source. It exposes hooks, MCP, Skills as extension points: you can add tools and interceptors, but you can’t swap deep implementations like session logs. Based on public evidence (restored source layout).
Grok Build: Cargo Workspace
Repo change requiredThe root Cargo.toml members array lists 79 workspace members (local count); capabilities are split by crate and composed at compile time. Adding a capability means a new crate, editing the root list, and recompiling. Split details: 12-1 · How 79 Workspace Members Compose the Product.
None of the three is absolutely better. Grok trades compile-time composition for Rust’s type and performance guarantees; Claude Code trades a monolith for product iteration speed; DSH trades a plugin tree for runtime swappability. If you want a replaceable, auditable runtime, DSH is the only one of the three that lets a third party replace deep capabilities without forking the repo.
Infer behavioral differences from the list
Delete the whole id: compaction group in standard/agent.cordis.yml (lines 137–155). Is the resulting session equivalent to Minimal mode under context pressure? Then check the three persona fields in minimal/agent.cordis.yml (lines 8–13) and name the two other gaps besides compression.