dshbase
中文

Blog · Architecture

The most ambitious agent open source of the year: an agent that modifies itself

August 14, 2026 · dshbase

DeepSeek isn't shipping a finished product — it's shipping a framework where the agent can rebuild itself. That reads like marketing until you run it. We did, on dsh 0.1.0-rc.6, and the architecture holds up in ways that are genuinely different from Claude Code or Codex. Here's the breakdown — including the parts that don't work as smoothly as the README implies.

Agent = Model + Harness

Every AI coding agent is two things bolted together: the model (the reasoning brain) and the harness (everything that connects the brain to files, terminals, tools, and the network). What makes DeepSeek Harness different is where it draws that line. In Claude Code and Codex, the harness is a fixed shell you can extend through MCP or an API but never replace. In DSH, the harness itself is made of plugins — so the line between "product" and "extension" doesn't exist. For the naming thesis behind this, see why it's called a harness.

Everything is a plugin

Every part of the harness is a plugin — tools, skills, sessions, sandboxes, the agent loop, sub-agents, workflows, even the UI. The only real core is Cordis: a minimal kernel that does exactly one job — load plugins, unload plugins, and resolve their dependencies. It has no opinion about models, tools, or even what an "agent" is. Everything you'd think of as core behavior is a plugin sitting on top.

Why the kernel matters: self-modifying agents

Cordis buys you two guarantees that a normal app never gives you:

  • Temporal composability — unloading a plugin fully undoes its side effects. Remove a capability and the system returns to the state before it was added.
  • Spatial composability — a plugin re-resolves its dependencies as its siblings change. Swap a tool and everything that used it picks up the change without a restart.

Those two properties are why the agent can extend itself while running: it notices it lacks a capability, builds the plugin, and hot-attaches it to its own flow without corrupting state. We verified the happy path directly — running dsh plugin add dsh-memory installs the package, records it in the profile's package.json, and on the next launch the plugin is already in the config tree. No rebuild, no manual wiring. The kernel discovers and loads it.

The contract that makes it work: dsh.bundle

The flip side of that magic is a manifest contract, and it's where most of the field failures live. A plugin must ship a dsh.bundle manifest (a cordis.patch.yml plus a dsh.bundle.patch declaration in package.json). Without it, dsh plugin add installs the package silently as a plain dependency — it never activates. We hit this repeatedly when auditing plugins: the package installs, the directory lists it, and the agent never loads it.

This is the detail you only learn by running it. When we tested 101 community plugins on dsh 0.1.0-rc.6, the results mapped directly onto this architecture:

  • 11 installed cleanly from npm and worked out of the box.
  • 4 needed a Web/TUI runtime you have to launch alongside the agent.
  • 3 failed to install outright — usually a missing or broken manifest, or a dependency that isn't published yet.
  • 81 never shipped to npm at all — they live on GitHub, installed with dsh plugin add github:owner/repo.

That 81 is the telling number: it means "everything is a plugin" isn't a theory, it's a live distribution channel. But the 3 failures and the silent non-activations are the cost of an ecosystem with no gatekeeper. The full results are in the plugin directory, and each failure mode is documented in the troubleshooting guide.

Create mode: the "make your own wrench" pattern

The architecture's payoff is Create mode. Tell it "build a read-only, security-audit-only mode" or "build a research agent with company search and three skills" — or let it inspect its own loaded plugins, notice one is missing, create it, and hot-attach it. Because unloading is clean (temporal composability), the agent can experiment without permanently polluting its own state. The metaphor: it realizes it has no wrench, forges one on the spot, attaches it to its hand, and keeps working.

There's a real safety rail here worth naming. When a plugin installed from GitHub ships a prepare build script, pnpm blocks it and prompts for allowBuilds confirmation. It feels like friction, but for a self-modifying agent it's the difference between "the agent extended itself" and "the agent ran arbitrary code with your permissions." Treat that prompt as a feature, not a bug.

Even the UI is a plugin

Community members have swapped in custom skins without touching core capabilities — one-command install, one-click restore. It's a small thing, but it's the cleanest demonstration that "everything is a plugin" isn't an aspiration. When the UI itself is a swappable plugin, the claim is load-bearing, not cosmetic.

FAQ

Do I need to understand Cordis to use DSH? No. You can run it as a normal coding agent and never think about the kernel. Cordis only matters when you write plugins, swap core parts, or debug why a plugin isn't activating.

Why do so many plugins only ship on GitHub instead of npm? Publishing to npm is one extra step most weekend authors skip. DSH handles it with dsh plugin add github:owner/repo, so a GitHub repo is a valid distribution target — but GitHub-source plugins are also where we saw the most install failures.

Is self-modification safe? Only as safe as the rails you keep on. The allowBuilds prompt and the clean-unload guarantee help, but treat self-modification as a scoped, logged experiment — not free rein.

Resources

All articles →