DeepSeek Harness Stunningly Open-Sourced Now: Everything Becomes a Plugin

We have already conducted the internal beta test in advance.

Earlier this morning, the official version of DeepSeek V4 Pro was released, setting off a wave of excitement. Now, just half a day later, DeepSeek Harness (Developer Preview) is here!

This hardly comes as a surprise, as the project has been in the works for a long time. For instance, Cui Tianyi from the DeepSeek Harness team has been posting previews on social platforms and recruiting talent for the team.

We also obtained the internal test access to DeepSeek Harness in early August, getting an early experience of this agent framework that is destined to bring new transformations to the AI community.

Open source repository: https://github.com/deepseek-ai/deepseek-harness

For example, we used DeepSeek Harness configured with the official DeepSeek-V4-Flash to build a first-person zombie shooting game. Without any manual intervention midway, we got a fairly playable finished product in just over 30 minutes, even if it is not perfectly polished.

Considering that Andrej Karpathy's recent idea of generating 3D worlds with AI has gone viral, we also challenged DeepSeek Harness (V4-Flash) with the classic benchmark "Huang Qiang Buying Watermelon": to recreate the classic "Huang Qiang Buying Watermelon" clip into a 3D animation based on text description (this is also the result of one-shot prompting):

Overall, although it is still far from perfect, the general plot of this animation is largely restored, and the character relationships are also clearly recognizable. In comparison, the animation we produced using the exact same prompt with Codex configured with GPT-5.6 sol-xhigh is far less satisfactory:

It should be noted that the parameter scale of DeepSeek-V4-Flash is much smaller than that of GPT-5.6 sol. It is easy to imagine that DeepSeek Harness has played a huge role in delivering such performance.

Today, with the release of the official version of DeepSeek V4 Pro, we have also connected this model to DeepSeek Harness and run the test again:

The performance is indeed noticeably better.

Next, let's take a look at the project structure, which is quite impressive: the repository already contains more than 230 workspace members, with code distributed in directories including packages/, apps/, examples/, python/, native/, vendor/, website/ and more. File system, terminal, subprocess, PTY, language server, web access, skills, sub-agents, workflows, planning mode, session persistence, settings, credentials, telemetry - almost every single capability has its own dedicated package.

If we compare an ordinary Agent project to a fully assembled pre-built computer, DeepSeek Harness is more like a massive breadboard: models, tools, interfaces, storage, security policies and context management can all be plugged in, and they can also be unplugged whenever needed.

It provides a default assembly solution, but it is clear that what DeepSeek really wants to create is not a fixed-form "DeepSeek coding assistant", but a universal way to assemble agents.

What is DeepSeek Harness?

Let's first clarify a common point of confusion: DeepSeek Harness is not a new DeepSeek model, nor a simple API client. It is a complete set of SDK and application framework for building, running and extending agents. By default, it can connect to DeepSeek models (and can also be easily customized to connect to other models), allowing the model to read projects, modify files, run commands, manage tasks, assign subtasks, and interact with users through Web UI, full-screen terminal, Headless commands or automation protocols.

The web version of DeepSeek Harness provides a convenient entry for directly configuring other model services, so users do not need to manually edit configuration files.

The AI community is already very familiar with the term "Harness". Its original meaning refers to horse harness, wiring harness, restraint devices and similar items. At a higher level of abstraction, its function is to connect power to a working mechanism, while preventing that power from getting out of control. Specifically for AI, Harness is responsible for connecting the model to the file system, Shell, code editor, web pages and other Agents, while recording what the model does, restricting what it is allowed to do, and deciding whether to retry, cancel, compress the context, or return the problem to the user when an error occurs.

This may also explain why the project has such a huge codebase and large number of packages: it covers a huge range of task and tool choices, including whether tool calls can be executed in parallel, whether cancel commands can truly stop subprocesses, whether tool results will pollute the context, where new messages from users arriving while the model is running should be inserted, how to reconstruct the model input at that time after session recovery, what tools sub-agents have access to, whether file writing crosses the workspace boundary, and whether the content seen during interface playback can be consistent with real-time execution.

DeepSeek Harness attempts to turn all these issues into formal system capabilities.

Everything is a Plugin

The most striking design proposition of DeepSeek Harness is "Everything is a Plugin", and even the Agent Loop itself is treated as a plugin.

The project is built on the Cordis microkernel, and the running Harness is essentially a Cordis Context. Different packages register services, events and capabilities to the Context, and finally the configuration file combines them into a fully functional runnable agent.

packages/core/ is the core of the entire system, containing Session, System Prompt, Tools, Agent and Agent Loop. They solve the most fundamental problems: what a session is, how system prompts are assembled, how tools are registered and called, how Agents are created, and how a single conversation round goes from user input to model request, tool execution and final response.

A large number of capability packages are built outside the core:

packages/llm/ is responsible for model adapters and streaming output;
packages/shell/, packages/subprocess/ and packages/terminal/ are responsible for one-off commands, process trees and persistent terminals;
packages/fs/ handles file reading and writing, editing, searching and policy restrictions;
packages/lsp/ connects to language servers, allowing Agents not only to perform text search, but also to access semantic-level code navigation;
packages/web/ is responsible for search and web scraping;
packages/skill/ manages reusable skills;
packages/subagent/ and packages/workflow/ extend a single Agent into a multi-agent system that supports delegation and orchestration.

Looking further outward, planning, goals, to-do items, background tasks, context compression, session queries, session titles, credentials, user settings, approval mechanisms and telemetry are all split into independent capabilities. The most interesting part of this structure is that it embodies an almost obsessive sense of boundary awareness: who owns the interface, who is responsible for implementation, and who presents capabilities to the model are strictly separated as much as possible.

The project documentation divides typical capabilities into three layers: interface, implementation and consumer.

Take Bash as an example: the interface defines what "execute command" means, the local implementation is responsible for actually creating the process, and the model-facing toolkit is responsible for turning this capability into a model-understandable schema and result. In the future, if the local Shell needs to be replaced with a remote container, cloud sandbox or enterprise execution platform, theoretically you only need to replace the implementation layer, without rewriting the model tools and Agent Loop.

This is a typical framework-oriented mindset. It will make the repository seem very large in the early stage, but it also shows that the goal of DeepSeek Harness is not to make a finished product that only the official team can maintain, but to allow different deployers to replace models, swap storage, change security policies, add tools, and even replace the agent loop entirely.

Here, we also see the True Open Source that DeepSeek has always adhered to!

cordis.yml

One Configuration to Assemble Different Agents

The plugin-based architecture is ultimately delivered to developers through cordis.yml. The configuration file lists plugin names, stable IDs and parameters, determining exactly which set of capabilities the current Agent has.

The same set of code can be assembled into completely different product forms. Adding the DeepSeek LLM adapter, file system, Bash and TUI gives you a coding agent that runs in the terminal; replacing the interactive interface with a web plugin gives you a browser application; using the Headless entry, it accepts a task, completes the rounds of model and tool interaction, prints the answer and exits; replacing it with an ACP or JSON-RPC front door, it becomes an automation service that can be driven by other programs.

The configuration also supports overlay layers. TUI and Web UI can share a base configuration, and then add their own interface plugins and parameters on top of it; personal configuration is located at the last layer. This way, deployers do not need to copy the entire configuration tree, only need to replace the specified plugins. However, there is one detail to note here: configuration patches replace the entire config of the target plugin, not perform deep merging. If you only write a new field, the original API Key, base URL and other parameters may disappear together. This design is very explicit, but it may not necessarily align with the intuition of first-time users.

The project also allows reading environment variables and runtime expressions in YAML through !!js, for example, retrieving the secret key from DEEPSEEK_API_KEY. The configuration only references the credential name, and the secret key is parsed at the time of actual invocation. The Web UI will write the secret key to $DSH_HOME/.credentials.yaml, while environment variables and .env can be used as fallback sources for automation or local development; secret keys should never be written directly to cordis.yml or included in session logs.

Agent Loop

Not a Single Loop, but a Complete Set of Traffic Rules

The core code of many early Agent projects can be simplified to a few lines: send the message to the model, if the model returns a tool call, execute the tool, then send the result back to the model, until the model outputs plain text. DeepSeek Harness of course does this too, but it splits this process into strict lifecycles.

A single user input starts a Turn, and one Turn can contain multiple Steps; one Step corresponds to one model request and its subsequent tool execution. Before the request, the system assembles a stable system prompt, current runtime environment, tool schema and session messages; after the request, the model's streaming chunks, complete messages, tool calls, tool results and end reasons all enter the event stream.

The above zombie shooting game executed 3 turns and 127 steps

Tools are not "called as soon as you get the function name". They go through pre-policies, irreversible security guards, actual execution, post-processing, content organization and result notification. Permission granting or denial, timeout, retry, metric statistics, and additional context attachment can all be accessed from different positions in the pipeline. A tool can declare that calls under certain types of parameters are concurrently safe, and the scheduler will run consecutive read-only tasks in parallel; once it encounters a call that modifies state or whose safety cannot be confirmed, it will treat it as a barrier, and wait for all previous tasks to finish before executing it exclusively.

This design may seem a bit like installing an air traffic control system on a country road, but when the Agent starts searching ten files at the same time, running tests, accepting additional user instructions, and also allowing cancellation at any time, these rules will quickly change from "over-engineering" to "the thing you wish you had implemented earlier in the incident investigation report".

It also carefully handles the destination of messages sent during runtime. New content sent by the user while the Agent is working can be the next task, or a steering instruction for the current ongoing work. The system distinguishes between queued messages, injected context and Steering, and confirms through receipts whether a certain steering instruction has actually entered a specific model request. In other words, it does not only care that "the message was received", but also "at exactly which step the model saw it".