Deep Dive into DeepSeek Harness: Core Design of a Self-Evolving Agent Architecture

From Model to Runtime: The Fifth Step of Agent Evolution

While most people are still discussing how "a large model plus a few tools" can complete tasks, DeepSeek Harness (DSH) shifts attention away from the model itself to the runtime environment surrounding it. According to in-depth research analysis by a Bilibili content creator, DSH is likely not just another ordinary Agent product, but rather a fundamentally new approach pointing toward next-generation Agent architecture.

An Agent (intelligent agent) refers to a system with autonomous decision-making and action capabilities in the AI field. Unlike traditional "input-output" large language models, Agents can perceive their environment, make plans, invoke tools, and adjust behavior based on feedback. Since 2023, with the capability leaps of large models like GPT-4 and Claude, Agents have become one of the hottest directions in the AI application layer. Early projects like AutoGPT and BabyAGI demonstrated the basic form of Agents, but they commonly faced issues such as poor reliability, chaotic context management, and unstable tool invocation. The root cause of these problems often lies not in the model itself, but in the runtime architecture beyond the model—precisely the core problem DSH aims to solve.

The core question DSH addresses is quite fundamental: if an AI needs new tools, new rules, or even an entirely different workflow during task execution, then "who" exactly changes its runtime environment? DSH's answer isn't to give the model sudden self-awareness, but to place the model inside a system that can run continuously, change, and be recombined.

Can AI Modify Its Own Runtime Environment?

The notion of "modifying itself" needs careful interpretation—it's neither the model awakening consciousness like a human, nor the model immediately rewriting all its code. A more accurate understanding is: can an AI system change its own working environment during execution?

For example, it originally had only one tool, then gained a second; it could initially see only the current conversation, then gained access to an entire task log; its original rules changed, and the next step executes under new rules. If all these changes can be uniformly managed by the system, then AI is no longer "ask once, answer once"—it possesses a continuously evolving runtime.

The concept of "Runtime" here is fundamental to computer science, referring to the environment and infrastructure a program depends on during execution. For instance, Java programs need the JVM (Java Virtual Machine) as their runtime, and JavaScript needs a browser engine or Node.js. Runtimes handle memory management, resource scheduling, exception handling, and other low-level operations. DSH introduces this concept into the Agent domain, meaning AI Agents are no longer scripts that "finish and terminate," but possess a persistent, dynamically adjustable execution environment. Just as different runtimes determine the execution behavior and capability boundaries of the same code, different Harnesses determine the intelligence level that the same model can exhibit.

Core Formula: Intelligence = Model + Harness

DSH proposes a key assertion: Intelligence = Model + Harness.

The Model only does three things: understand what we said, make judgments, and propose what to do next. But the model doesn't inherently possess tools, file permissions, task logs, or knowledge of what the previous step caused. It's like a very intelligent person locked in an empty room—without materials, a phone, or tools, their intellect can hardly affect the real world.

The Harness is this person's working environment and work system—it's responsible for bringing in tools, storing tasks, informing the model of rules, executing the model's actions in the real environment, and bringing results back.

The Dynamic Loop Behind the Plus Sign

The "plus sign" here isn't simple mathematical addition, but a dynamic loop: first the model decides what to do next, then the Harness makes that step actually happen and feeds the result into the next step's input.

This also explains why DSH isn't a fixed loop—it cares more about whether the loop itself can be disassembled, replaced, and recombined during execution. When asked whether "Harness is a necessary and sufficient condition for AGI," AI experts have responded: most likely not, but it's probably an important component.

Five Stages of Agent Evolution

Behind DSH lies a clear conceptual evolution timeline, describing not a product release sequence, but how the "Harness" concept was built layer by layer:

• Step One: Model. Initially we only had models—they give you a piece of text, an answer (like daily conversations with chatbots).
• Step Two: Tool Calling. Equipped with tools, the model can take action—read files, call APIs, affect external events.
• Step Three: State Management. Tasks have multiple steps; the system must remember what it just did, what happened, and where things went wrong.
• Step Four: Harness Integration. Organizing model, tools, and records together long-term, handling permissions, rules, loops, errors, and different working modes.
• Step Five: Autonomous Evolution. The system not only completes tasks but can change the tools, rules, and execution modes that carry those tasks.

A key detail: DSH hasn't achieved self-evolution—it's building the infrastructure for self-evolution. Currently, the vast majority of tools (including Claude Code) remain at Step Four, while DSH is clearly exploring the possibilities of Step Five.

Three-Layer Structure of the Harness

To understand how the Harness works, we need to decompose three core conceptual layers:

Model Layer, Harness Layer, and Environment Layer

• Model Layer: Responsible for judging "what should be done next."
• Harness Layer: Responsible for turning ideas into actions, checking whether tools or permissions are authorized for invocation, and determining where results are written.
• Environment Layer: The real user working environment, which may include files, networks, databases, or other systems.

For example: the model needs to read a file. The Harness first confirms whether the current task has file-reading capability and whether the file is readable; then the environment provides the actual result—the file exists or doesn't; finally, the result returns to the Harness and enters the model's next input.

So an Agent isn't a lone loop—it's a complete system composed of the model, runtime environment, and external world together.

Component-Based Engineering Design

DSH made a critical engineering choice: rather than welding all capabilities into a single super-core, it designs capabilities as independent components (think of them as functional plugins within the runtime):

• Model Adapter: Unifies the integration of different models
• Tool Registry: Declares the currently available set of tools
• System Prompt: Organizes roles, rules, and context into instructions the model can understand
• Session Log: Saves all events that occur during task execution
• Agent: Single-step, single-turn dialogue processing
• Agent Loop: The common ReAct loop—continuously observing the environment and advancing tasks

ReAct (Reasoning + Acting) is an Agent reasoning framework proposed in 2022 by Princeton University and Google's research team. Its core idea is to have large language models alternate between reasoning and acting during task execution: the model first thinks about the current state and next-step plan, then executes a concrete action (like calling an API or searching for information), observes the execution result, and then enters the next round of reasoning. This loop enables models to continuously refine strategies based on real feedback rather than giving all answers at once. ReAct has become the foundational pattern for current mainstream Agent frameworks (such as LangChain and AutoGen), but its limitation is that the loop structure is typically fixed—DSH further explores whether the loop itself can be dynamically recombined.

This component-based design inherits mature architectural traditions from software engineering. Plugin Architecture was first widely applied in systems like the Eclipse IDE and WordPress, with the core idea of decomposing system functionality into modules that can be independently loaded and unloaded. Dependency Injection is the core design pattern of enterprise systems like the Spring framework, achieving loose coupling and high testability by externalizing the management of component dependencies. DSH's Codis mechanism combines both traditions—supporting dynamic loading and unloading of plugins while managing inter-component dependencies through Service and Context mechanisms.

The benefits of this component-based design are: models can be replaced without rewriting the entire logic; tools only appear within specific tasks or scopes; prompts can be composed on demand; and when a capability exits, the system knows what impact it left behind and can clean up properly.

Codis: The Underlying Mechanism for Composable and Reversible Capabilities

How do plugins get installed into the system? This relies on DSH's underlying core—Codis. In the plainest terms, Codis is a set of underlying mechanisms within the runtime environment that can be assembled, changed, and cleaned up. It's not business logic, nor the brain—it's more like a workplace management system responsible for coordinating all the parts together.

Key concepts of Codis:

• Plugin: A functional component, such as file-reading capability or a model adapter
• Service: Think of it as an API interface, exposed for other components to call
• Context: What capabilities, rules, and objects are currently active in the workspace
• Event: Like a bell ringing in the workplace—when something happens, other components can hear it and decide whether to respond
• Effect: Changes left behind when a component enters the system—registering services, adding listeners, modifying configuration

The most critical aspect of Codis is: these changes aren't just added and forgotten—they can be reversed. When a plugin leaves, the system can clear away all its impacts together.

This "reversible changes" mechanism corresponds to the concept of Transactionality in software engineering. Database systems ensure operation atomicity through ACID transactions—either everything succeeds, or everything rolls back. In distributed systems, the Saga pattern achieves similar reversibility by defining compensation operations for each action. Codis applies this thinking to Agent runtime management: all Effects produced when a plugin enters the system are recorded, and when the plugin exits, these Effects can be reversed and cleared. This is crucial in practical scenarios—for example, if an Agent temporarily loads a plugin with file-write permissions during a complex task, those permissions must be thoroughly revoked after the task completes, or security risks may arise.

Understanding Codis Through a Concert Venue

Think of Codis as the management system for a temporarily assembled concert venue: it's not just about bringing equipment in, but knowing where the wires are connected, what song the monitors are playing, and after the show, everything must be taken down and the site restored to its original state. This is Codis's core value—it no longer deals with spatial "how to install" questions, but with temporal ones: "when does something join, when does it change, when does it exit."

Every Step Regenerates the Current World

The most distinctive architectural feature of DSH manifests before each model invocation.

The common Agent approach is: prompts are static files written before the task starts, tool lists are fixed, and afterward you just keep appending content to the conversation. In current mainstream Agent implementations, the System Prompt is typically set once at the beginning of the conversation, and the dialogue progresses only by continuously appending user messages and assistant replies. The problem with this approach is that as conversation turns increase, early context information may be truncated due to token window limitations, causing the model to "forget" key information. Additionally, meta-information like tool lists and permission rules may have already changed during task execution, but static prompts cannot reflect these changes. The world the model sees easily becomes a "snapshot of the past" that cannot reflect the latest state.

DSH's approach is: before each request to the model, reorganize and reassemble the current workspace. It checks what the current task log is, what rules and tools are currently available, what happened in the previous step, and which capabilities and permissions are still active. After organizing all this, it hands the model a completely fresh context description. This "regenerate context at every step" strategy essentially performs a complete state snapshot before each model call—while this increases computational overhead, it ensures the model makes decisions based on the most current and accurate information at every step. This design philosophy shares a striking similarity with React's frontend framework concept of "every render is a new snapshot."

Three Dimensions of Dynamic Context Change

The context here is more like "printed current work instructions"—when the environment changes and tools change, the instructions change accordingly. Specifically, changes form a chain:

• State Changes: Tool return results, execution errors, and intermediate facts are all recorded—the next step won't forget
• Prompt Changes: Because records and environment have changed, the instructions given to the model next time will also be reorganized
• Tool Changes: Visible tools dynamically change with plugin loading, task scope, and permission settings

This is what "self-evolution infrastructure" means—it's not that model parameters are retrained, nor that new knowledge is acquired from thin air, but that the Harness changes what the model can see next, what it can do, and what rules it must follow.

Conclusion: Intelligence Lives Beyond the Model

Two sentences summarize the core value of DeepSeek Harness: First, DSH is not a fixed Agent, but a runtime system whose capabilities can be reassembled; Second, Codis is not execution logic, but the underlying infrastructure that enables plugins, services, the current workspace, and changes to coexist.

Compressed into one sentence: The model decides what to do; the Harness decides how to let it exist. The model can propose an action, but the Harness determines whether that tool execution will be remembered, what the next step can see, and whether the task can cleanly contract when finished.

The truly valuable aspect of DeepSeek Harness isn't making Agents perform a few more actions, but replacing the runtime environment behind Agents with a system that can be observed, changed, substituted, and restored. As for whether AI will truly modify itself—that remains a more distant question. But from the architectural direction of DSH and Codis, the answer no longer hides in model parameters—it hides in that layer of Harness outside the model.