DEV Community

weiwuji
weiwuji

Posted on

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

#ai #agents #harness #engineering

The Pain: Today's headlines are all "DeepSeek open-sourced its Harness" and "everything is a plugin." But here's what you need to know — a plugin system gives you differentiation space, not success rates. What actually separates agents are the details nobody talks about.
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)
Enter fullscreen mode Exit fullscreen mode

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:

Mode One-liner Who
Standard Full tool suite Regular agent tasks
PTC Model writes code to compose tool calls Complex tasks
Minimal Only shell + file edit Testing models in minimal env
Creation Agent inspects runtime, tries plugins, composes new modes 🔥 Harness developers

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 Hyping "Everything Is a Plugin." That's Not What I See.

Let me pour cold water first.

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.

Architecture converges, gap is in details

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

error-ledger data flywheel

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The four local gaps

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
Enter fullscreen mode Exit fullscreen mode

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.

Unified event stream

2️⃣ Tool-Call Pipeline 

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

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)