DeepSeek Harness Deep Dive(1): Introduction to Agents and Harness

Over the past few years, the development of artificial intelligence has
mainly revolved around Large Language Models (LLMs). As model scale and
the number of parameters continue to increase, their knowledge and
reasoning abilities have improved continuously. However, from a certain
perspective, what LLMs do is still an evolution from simple "fill in the
blank" into a more complex and longer "fill in the blank" process --- a
user's question is essentially a problem given to the model.

However, this purely conversational interaction is clearly far from
sufficient in real-world applications. For example, when you ask:

"Help me fix the login bug in this project."

A native LLM can list possible causes, suggest solutions, and even
provide code examples, but it cannot truly inspect project files, run
tests, modify code, obtain execution results, or iteratively adjust
itself based on feedback.

Therefore, in order to make LLMs more practically useful, concepts such
as workflows and agents were developed. Today, agents have become one of
the most widely discussed topics in AI.

As the beginning of this series analyzing DeepSeek Harness, let's first
briefly introduce what an Agent is.

---

From LLM to Agent

At the simplest level, an LLM can be represented as:

$$LLM: Context \rightarrow Output$$

In other words:

Given a context:

$$Context$$

the model produces:

$$Output$$

For example:

Input:

User:
Explain Transformer.

Model output:

Transformer is a neural network architecture based on the Attention mechanism...

This process is essentially:

$$Input \rightarrow Model\ Reasoning \rightarrow Text\ Output$$

This pattern works very well for tasks that are fundamentally
text-based, such as question answering, writing, translation,
summarization, and generating papers.

However, it lacks one critical capability:

$$\boxed{Interaction\ with\ the\ Environment}$$

Why is interaction with the environment so important?

The simplest and most practical way to extend the capabilities of models
is not necessarily to build completely new environments, but rather to
allow models to interact with existing tools and systems.

Therefore, with Agents, models are no longer only answering questions.
They can:

• Observe the environment (Observe)
• Make plans (Think)
• Execute actions (Act)
• Receive feedback (Observe)

forming a loop:

$$Observe \rightarrow Think \rightarrow Act \rightarrow Observe \rightarrow ...$$

For example, a Coding Agent:

User:
Fix the failing test.

Agent:

Read project files

↓

Run pytest

↓

Analyze error logs

↓

Modify code

↓

Run tests again

↓

Confirm the fix

As we can see, through interaction with the environment, the Agent gains
much higher practical value.

---

From Agent to Harness

A simple Agent can be represented as:

Where:

• LLM is responsible for understanding the task and generating the next decision.
• Tools provide capabilities such as file operations, search, and API calls.
• Environment is the external world where tools interact, such as file systems, code repositories, databases, and browsers.

However, this structure is still incomplete.

It is missing:

• State persistence
• Context management
• Permission control
• Execution loops

These components together form what is called Harness.

Harness can be understood as:

A complete Agent runtime environment deployed around the model.

In simple terms, if the LLM is the "brain", then Harness provides the
nervous system, sensory system, motor system, and memory system that
allow the brain to actually operate.

Without Harness:

response = llm(prompt)

The model outputs:

Run pytest

But then:

• Who runs pytest?
• Who records the result?
• Who sends the result back to the model?
• Who decides whether the task succeeded?

These responsibilities cannot be handled by the model itself.

Therefore, an external system is required:

Model proposes an action

↓

Harness receives the action

↓

Execute the tool

↓

Receive feedback

↓

Update context

↓

Call the model again

Creating this loop:

$$Context_t \rightarrow LLM \rightarrow Action_t \rightarrow Environment \rightarrow Observation_t \rightarrow Context_{t+1}$$

Therefore, we can define:

$$\boxed{Agent = Model + Harness}$$

A useful analogy is:

If the LLM is the brain, Harness is the nervous system, sensory system,
motor system, and memory system.

Without these systems, the brain cannot act independently.

Therefore, it is easy to understand why the same model can perform
completely differently under different Harness designs.

---

From Harness to DeepSeek Harness

As mentioned above, the LLM itself only performs:

$$Context \rightarrow Output$$

What truly turns it into an Agent is the external runtime mechanism that
continuously executes actions, receives feedback, updates state, and
calls the model again.

Harness is responsible for supporting this entire loop.

The most direct responsibility is Tool Management.

The model may decide:

• "Run pytest"
• "Read this file"
• "Call this API"

But the actual execution, result collection, error handling, and
returning results back to the model are all handled by Harness.

Without this layer, the model's actions remain only text.

However, once tools begin running, another problem immediately appears:

The model needs to know:

• What happened before?
• What actions have already been taken?
• What are the tool results?
• What is the original goal?

Therefore, Harness also needs to manage Context.

It organizes:

• User requirements
• Historical actions
• Tool results
• Current environment state

into the input used for the next model call.

As tasks become longer, Harness must decide:

• Which information should be kept?
• Which information should be compressed?
• Which information can be discarded?

Furthermore, if a task needs to run for a long time, maintaining only
the current Context is not enough.

The Agent also needs to know:

• What it has already done
• Where it currently is
• How to continue after interruption

This is Session Management.

It stores the execution state of the entire task.

Finally, the execution loop itself cannot run forever.

Harness needs to control:

• When a tool can be executed
• When user confirmation is required
• Whether to retry after failure
• Whether to continue
• When to stop

This is Execution Control.

Therefore, a mature Harness can be roughly described as:

$$Harness \approx Tool\ Management + Context\ Management + Session\ Management + Execution\ Control$$

Naturally, as Agent systems develop, the number of tools increases,
Context becomes longer, Sessions become more complex, and additional
capabilities such as permissions, logging, lifecycle management, and
more extensions are introduced.

Once Harness starts taking responsibility for these capabilities, it can
quickly become a complex system itself.

Therefore, a new question naturally emerges:

How can we allow Harness to continuously gain new capabilities without
putting everything into the Runtime core and eventually turning it
into an increasingly bloated and difficult-to-maintain system?

Or, more directly:

How do we manage the growing complexity of Harness itself?

In my view, one of the values of DeepSeek Harness lies exactly here.

Its design philosophy starts from:

Everything is a Plugin