DeepSeek Open-Sourced Its Harness: Everything Is a Plugin, But the Real Gap Is in the Details

The Pain: Today everyone is talking about "DeepSeek open-sourced its Harness" and "everything is a plugin" — and those discussions are valuable. But beyond the buzz, I want to share another angle: a plugin system gives you differentiation space, not success rates. What actually separates agents are the less visible details.
What You'll Learn: What DeepSeek Harness is really worth and where its boundaries are — seen from a production system running in real business scenarios. What to steal, and what's actually your moat.

Let's Align on Facts: What Happened Today

On August 13, 2026, DeepSeek open-sourced its Harness. v0.1 developer preview, MIT license, full source code.

One sentence summarizes its architecture philosophy: everything is a plugin.

Models, tools, skills, sessions, sandbox, storage,
Agent Loop, orchestration, UI
        ↓
all replaceable (Cordis plugin system)

Note: this isn't "you can swap a search tool." Even how the agent loops, how it spawns sub-agents, how it saves sessions — all replaceable. The whole runtime is a Lego base.

Four run modes = four plugin combinations:

Plus two core designs:

• Append-only session log: every trace flows into one event stream
• Multi-agent built-in: Spawn/Fork/Pipeline/Ralph Loop

You don't need to memorize these terms. Just remember one sentence — DeepSeek turned "how an agent works" into a plugin system you can freely assemble.

Everyone's Talking About "Everything Is a Plugin." Let Me Share Another View.

First, let me be clear: "everything is a plugin" is genuinely good news — for the first time, an agent runtime can be freely assembled, and that's a real liberation for developers.

But beyond that angle, I want to explore a different view — after architecture converges, where does the real gap actually lie?

Architecture convergence is inevitable. When everyone can plugin-ify tools, loops, and orchestration, those stop being moats. Spawn, Fork, Pipeline, Ralph Loop all have mature precedents — DeepSeek's real innovation is making them config-replaceable plugins.

An industry expert told InfoQ:

Looking at the full harness pipeline, tool calling, memory management, and task planning directions are basically settled. The real innovation will happen in the local details.

He named four:

1. Memory compression: accumulated memory needs compressing
2. Conflict cleanup: conflicting memories need organizing
3. Path reuse: similar tasks reuse existing planning paths
4. Plan validation: post-generation "compile-style" checks (complete error branches? executable ops? steps within permissions?)

This is where the real gap is. Plugin systems provide differentiation space, not success rates.

My Practice: I've Actually Run All Four

Not armchair theory. I've run all four in real business scenarios — just not on DeepSeek Harness, on our own production system.

1. Memory Compression → My Cognition Distillery

Uncompressed memory drowns the agent.

My approach is "cognition distillation": after every completed piece of work, I don't keep a log — I distill into nodes (problem + insight + practice + links) into a cognition library.

Published articles → distilled into nodes → cognition library (28 nodes)
  ↓
Writing selects precise nodes → articles stay focused

That's memory compression in practice — not deleting memory, but turning it into a higher-density form. DeepSeek confirms this direction.

2. Conflict Cleanup → My Correction Flywheel

The classic symptom of memory conflict: rules fighting each other, agent doesn't know which to obey.

My approach is "correction sedimentation": every error → error-ledger → extract lesson → sediment as rule → gate intercepts.

Production → audit → errors logged (31 entries)
  → rule sedimentation → gate interception → flywheel spins

The key to conflict cleanup isn't cleanup itself — it's building an error-to-rule conversion pipeline so conflicts surface and resolve automatically.

3. Path Reuse → My Scenario Routing

Agents shouldn't plan from scratch every time. Similar tasks follow similar paths.

My approach is "scenario routing": different scenarios → different agent configs/tool sets, reusing proven paths.

Scenario detection → route to matching agent
  → reuse proven path (no replanning from scratch)

4. Plan Validation → My Physical Pipeline Gates

No validation after planning = letting the agent run naked.

My approach is "physical pipeline": every task output must pass gate verification before delivery.

validate_article → check_series → article_checker → publish_gate
        ↓
4 gates, all physical, no LLM self-discipline

What to Steal: Three Things DeepSeek Harness Does Better

Despite the gap being in details, DeepSeek Harness does three things better than us. Worth stealing:

1️⃣ Append-Only Unified Event Stream (Steal This First)

DeepSeek: everything the model sees → one append-only log
  system prompt / reasoning / tool calls / sub-agent orchestration / context injection
Value: shared observability ledger, session forking, replayable evals

Our observability trio (Gate/Audit/Correction) stores separately; their unified event stream is more thorough — all traces in one stream, evals/debugging/replay all based on it.

This directly connects to Trajectory Evals — the evaluator eats traces, and a unified stream makes traces more complete and replayable.

2️⃣ Tool-Call Pipeline

DeepSeek: tool call = request → Hook → approval → permissions → sandbox → timeout → execute → rewrite → log → UI

Our tool whitelist is a static check; theirs is a pluggable pipeline — every stage independently replaceable/composable. Security goes from "switch" to "pipeline."

3️⃣ Creation Mode Thinking

DeepSeek: agent can inspect runtime, try plugins, compose new run modes
Meaning: the harness config itself becomes an object the agent can operate on

This is "nurture-style AI" engineering — letting the agent participate in its own config. We already have correction sedimentation; we can go further: let the agent read/modify its own rule files through tools (we have this capability, can systematize it).

What NOT to Steal: DeepSeek Harness's Boundaries

Cold water again. Three problems:

1. "Everything replaceable" ≠ higher success rates — plugins give differentiation space; the final effect needs high-quality default plugins, stable composition patterns, and credible eval results
2. v0.1 migration cost is high — core plugins and interfaces will change fast; entering the ecosystem now means absorbing high migration cost
3. Multi-agent has no paradigm breakthrough — it's a pluggable hierarchical Supervisor-Worker, far from true Swarm (autonomous discovery/negotiation/competition/dynamic takeover)

Conclusion: you can swap the base. You can't stop the flywheel.

Where You Are Now

You're no longer the developer who gets excited every time "everything is a plugin" trends.

You're becoming the strict engineer who — sees architecture convergence, watches the local gaps, and validates everything in real business scenarios.

DeepSeek solves "how to build." We prove "how to use" with a production system.

Remember: the Harness is the base; the production system is the answer. Plugin systems provide differentiation space. What actually decides success — memory compression, conflict cleanup, path reuse, plan validation — only real business scenarios can force you to build.

About the author: Wu Ji (无记) — AI / Agent / digital transformation practitioner. I only write about things I've actually built and run — no concepts without practice. Follow along, and let's turn cognition into income.