There are already plenty of introductory articles on DeepSeek's open-source Agent Harness (DSH): what it is, how to install it, and how elegant its plugin architecture is. Most stop at calling it "yet another agent framework," because the question they answer is "What does DSH look like?"
This article asks a different question: why would a model vendor devote so much effort to building a harness, and what do its design choices mean for enterprises?
The starting point is post-training. Post-training (SFT, RLHF, agentic RL) shapes model behavior through the weights. A harness shapes model behavior through the environment—using toolsets, guardrails, approvals, and feedback to change the policy the model actually exhibits. Both paths lead to the same goal: getting the model to work the way you need it to. The differences lie only in time to effect, reversibility, and blast radius.
Once we view a harness through the lens of post-training, many of DSH's design decisions fall into place. Designs and abstractions that might look like an engineer's obsession with tidiness—the log is the state, everything is derived, capabilities are plugins—collectively follow the principle of agile experimentation and cautious consolidation. They lay out a complete path for enterprise evolution: environment shaping, trajectory accumulation, and weight shaping. This article aims to explain that path and use a self-evolution POC to test whether it works end to end, and where it breaks—interface design, contract form, and feedback quality.
The complete chain through which a model enters an enterprise has three layers:
Layer One: Pre-Training. The general capabilities a model has out of the box: writing code, reasoning, and understanding language. These capabilities are universal and have nothing to do with your enterprise.
Layer Two: Post-Training. Preference data, feedback signals, and interactions with environments are used to "write behavior into the weights." This layer begins to target specific needs: making the model more compliant, better at using tools, and less prone to particular errors. How post-training takes effect has three characteristics worth explaining upfront, because they are the key to understanding "why a harness is necessary":
Training needs large-scale data to be statistically meaningful. Training jobs are inherently outside the live inference request path, and new weights must undergo evaluation and a staged rollout before going live. This is precisely why the third layer—the working environment—exists: not every behavioral problem can wait for the next round of training.
Layer Three: The Working Environment. The runtime environment in which an enterprise actually uses the model: which tools it can see, which constraints will stop it, which actions require approval, and who the approver is. This layer has long been underestimated, yet it means that the same weights, placed in different working environments, can perform anywhere from completely unusable to a perfect score—because the environment provides both a safety net and guidance. The two sets of controlled experiments below measure precisely this gap.
The value of DSH lies in the relationship between Layers Three and Two. Read through this lens, its design choices can be reduced to one proposition:
A harness is a safe testing ground for post-training. New behaviors are first validated reversibly in the environment; frequently recurring patterns approved by humans are then distilled into the weights.
This proposition explains a seemingly counterintuitive design in DSH: a self-evolution pathway based on "agile experimentation, cautious consolidation." The experimentation end has almost no barrier to entry: the model mounts code it has written within a session, with no approval required. The consolidation end must pass through human review: turning an experiment into a persistent capability requires the normal development process and human review. The permissive end ensures that evolution actually happens; the strict end ensures that it does not cause an incident.
Before going further, let us look at DSH's three design pillars. They are the foundation for every mechanism that follows.
First, let us clarify what "log" means here. This is not the kind of application log we normally write. The output of logger.info is a side-channel artifact: it records "what happened" for people to investigate. Delete the entire log file and the system keeps running; you simply lose the ability to investigate when something goes wrong.
The log in DSH belongs to a different category, closer to git's commit history: it is not a record of the state; it is the state itself. The working tree you see is checked out from the commit history. Similarly, conversation history, approval policies, and sandbox modes in DSH are all computed from this log. Delete it, and the session is not merely "missing its records"—it no longer exists. The criterion is simple: application logs can be deleted; delete this log, and the system has no state.
Readers familiar with databases can compare it with a binlog. The form is very similar—logical events, append-only, replayable—but DSH goes one step further. In a DB, table data is the source of truth and the binlog is its accompanying stream. In DSH, there is no "table data" layer: the log is the sole data source.
Inside DSH's Session, there is only one data structure: an append-only log that only grows, to which events can be appended only at the tail; events already written are never modified or deleted. User messages, model replies, tool calls, approval decisions, sandbox mode switches, goal-state changes, and scheduled reminders—all are appended to this log as structured events. Conversation history is not "a second stored record," an approval policy is not a variable, and a sandbox mode is not a state field—they are all projections of the log.
This log has three hard rules: events are deeply frozen when appended—not just the top-level object, but nested fields as well, so no layer can be changed afterward; sequence numbers are contiguous, with each event's position serving as its identity; and crash recovery scans unclosed events at the tail and synthesizes closing events, so an unexpected interruption does not leave the log as an unfinished ledger.
This yields a property that seems unremarkable but is profoundly important: inconsistency between state and log is structurally impossible. State is not stored independently; it is simply the result of folding the log. Most systems face a question during incident investigations: "The state says A, but the log says B—which is true?" In DSH, this problem has been eliminated.
Because the log is the single source of truth, nothing that can be derived should be stored a second time. In this section, "derivation" and "projection" are two ways of describing the same thing: projection emphasizes that these are different views of the same data; derivation emphasizes that all those views are computed. What they share is that none is stored separately. The conversation history the model sees is projected from the log event by event; the "message bubbles" in the interface are an array of indices pointing to positions in the log, not another store;
Even an apparently indispensable cache such as the "mutable session summary" was removed entirely, along with its companion files on disk and the associated columns. The design notes are explicit: everything the summary was meant to provide can be derived from the append-only log. The initial prompt is the first user message; activity is the timestamp of the last event. In that case, dispense with the summary.
The engineering significance of this principle is: there is no second source of truth, so there can be no conflict between two versions of the facts. You never need to write "synchronization logic," because there is simply no second location to synchronize. Consistency is guaranteed by structure, not maintained through discipline.
This pillar answers a very concrete question: how is a capability installed and then removed, and can the model still see it after removal?
Across all 54 packages in the DSH repository, just one contains the "call the model, run tools, repeat" loop. Everything else—the sandbox, approvals, scheduled wake-ups, goal progression, and even new tools written by the model itself—uses the same plugin contract (cordis, the microkernel plugin framework inlined into DSH) and can be assembled into the runtime like components.
Composition is the product: enabling the sandbox means assembling four plugins in the configuration; removing them returns execution to an unrestricted mode. The permission fields in the model's tool table automatically disappear when the sandbox capability is absent. This pillar is the structural prerequisite for "self-evolution": the host itself is an assemblable plugin tree, allowing the model to add things to the runtime in exactly the same way as human developers.
Together, the three pillars paint this picture: DSH turns the "environment" from a static set of configurations into a living, auditable, rollback-capable organism. This is the first link in the evolution path: environment shaping. At the same time, it does something else: it preserves every decision made in that environment as a traceable ledger entry.
Most agent frameworks on the market have guardrails, but most of those guardrails are "interceptors": they step in to stop you when something goes wrong, then disappear. The guardrails in DSH differ in two aspects of their design.
First, all guardrails sit on the same pipeline, and they deny by default (fail-closed). From the moment the model issues a tool call to its actual execution, the call passes through, in order: the policy chain (a series of rules, each deciding allow/deny/ask a human) → approval resolution → monotonic guards (checks that can only veto, never relax constraints) → execution → result finalization (freezing the final result so that it can no longer be changed). The set of approval outcomes is closed: allowed-once (for this invocation only) is the sole outcome that permits execution; rejected, cancelled, and unavailable all deny it. A missing approver, an error, or a return value outside the vocabulary is always treated as a denial. Having no approver—for example, in a headless deployment—means denying everything: the system says no by default, not yes.
This "default no" is not a default value that can be bypassed; two details show that it is structural. First, policy precedes interaction: once the deployment configuration sets an action to never, the service deterministically returns a denial before forwarding the request to any approver. The approver never receives it. Trying afterward to permit the action by "inserting yourself at the front of the approval chain" therefore achieves nothing. Order-dependent fragility such as "who registers first" is structurally excluded. Second, approval requests deliberately carry no tool arguments. They contain only a call ID, attached to the call already streamed for the human to inspect. This prevents any drift between "what was seen at approval time" and "what actually executes" at its root—not by comparing and validating them afterward, but by leaving no room for drift to occur.
Second, every guardrail activation is recorded as a structured event, deliberately stored separately from the model-visible conversation. An approval produces a pair of events: approval/asked and approval/decided, paired by the same approval request ID, and log-only—they do not enter the conversation stream the model sees. On the sandbox side, both denial signatures and the model's stated reasons for requesting elevated permissions occupy structured fields: the former are the denialSignatures reported by the backend; the latter are the permission-request and justification fields in the tool arguments.
Viewed from a post-training perspective, these two design choices take on a very different meaning:
asked/decided approval audit pair is human preference data: which action, with which justification, in which context, was approved or rejected, and by whom. This is precisely the preference signal RLHF/DPO needs, and it arises naturally in production, with no additional annotation cost.In other words, DSH records every human decision about "whether to allow this" as a structured event that can be used directly as training data. The stricter your security mechanisms, the more valuable your data assets. In DSH, these two objectives not only avoid conflict; they share the same event foundation. This is evidence at the mechanism level that "safety" and "getting better with use" do not necessarily crowd each other out architecturally: guardrails are collectors as well as interceptors, and the more frequently they intercept, the richer the accumulated data becomes.
Another sandbox design is worth mentioning: DSH deliberately distinguishes "soft boundaries" from "hard isolation." Soft boundaries are reversible constraints implemented by wrapping execution arguments within the same kernel process. Hard isolation provides a containable blast radius by replacing the entire execution world as a group—for example, moving to a container or remote executor. The criterion is a shared filesystem: if the agent's bash and file tools operate in the same world, wrap the arguments; if they operate in two worlds, with bash in a container and file tools writing to the host, the agent inhabits a split world, and the whole group must be replaced. This criterion directly answers the question enterprises struggle with most in agent security: when should you add a permission layer, and when must you change the execution environment? In the context of this chain, it is a reversible buffer between "experiment" and "incident." Environment shaping can afford to let the model experiment freely because soft boundaries catch problems first, with hard isolation as the final safety net.
The most radical part of DSH is that it gives the model the authority to "modify its own runtime." It provides three kinds of tools: retrieving runtime information for the current process (reading an API catalog generated from the source AST, so the model sees actual signatures with documentation); mounting (executing model-written JS in a restricted evaluation environment and mounting it as a temporary plugin that takes effect immediately); and unmounting (waiting until all mounted components reach a quiescent state before reclaiming them).
"Mounting/unmounting" here describes the semantics. On the tool surface, mounting is completed in two steps, "define + run," and unmounting in two steps, "stop + unregister." In terms of system states, mounting is LOADING→ACTIVE, and unmounting is ACTIVE→UNLOADING→DISPOSED. The event sequences captured by live-system probes correspond one-to-one with the timestamps of the tool responses.
A closed loop therefore emerges: the model discovers that it lacks a tool → writes some code itself → mounts it → the tool is callable on the next turn. Mounted components can register new tools, listen to agent events, and provide services for later mounts. The model can mount components in multiple stages, gradually assembling complex capabilities.
But DSH makes a highly restrained design choice here: runtime experiments are not persisted to disk; consolidation must go through approval.
The design notes state explicitly: there is no pathway for automatic saving, promotion, or installation. Preserving an experiment means asking the agent to implement a real project plugin through the normal development process. Why block automatic promotion completely? Because mounting is a development tool. The evaluation environment guards against accidental contamination; it is not a security boundary. Mounted code receives a context with full permissions. A "one-click promotion" pathway would allow model-written code to bypass human review and enter the persistent configuration surface.
This is the structural implementation of the earlier principle of "agile experimentation, cautious consolidation." Expanded into a complete three-stage process:
The trust level decreases monotonically, while the scope of effect increases monotonically. DSH implements only the first two stages; the third is left to the model vendor. And that model vendor happens to be DeepSeek itself. This boundary "left to the vendor" is a deliberate blank in DSH; from an enterprise platform's perspective, it is precisely the interface for the data flywheel.
There are two complementary mechanisms along the time dimension: scheduled wake-ups (the model can set reminders for itself, but receives them only when completely idle, never interrupting the current turn) and goal progression (automatic continuation of long-running tasks, but after a process restart or session restoration, continuation requires renewed human authorization; cancellation means pausing, preventing "cancel" from becoming a trigger for automatic restart). Together, they answer the question: how can a system that evolves autonomously ensure that humans always retain the final switch?
Using a locally built DSH (0.1.0-rc.5), driven by qwen3-max, with qwen3-coder-plus and qwen3.8-max as additional control arms, we built a "self-evolution arena." The host acts as judge, holding a set of undisclosed acceptance criteria. The model can build new capabilities for itself only by "writing code + mounting plugins," using the failure examples from each round. There is a deliberate design choice here: only the acceptance criteria are hidden—how many characters a mask retains, and the precedence of multiple rules. The task objective itself is public. This mirrors real work: everyone understands "build a data-masking tool," but "which rule applies first when two types of sensitive information overlap" inevitably requires repeated alignment with the audit team. The output excerpts below are taken verbatim from the session event stream.
We do not rely on the model's own account: in testing, it even misjudged the fact that it had already succeeded. A finding of "genuine evolution" must pass four gates:
Only passing all four gates justifies saying "it evolved." Passing only the first two justifies no more than "it built something that runs." These gates are themselves the first output of the POC: they answer the question enterprises are most reluctant to ask—how do you know your agent has genuinely become more capable, rather than merely feeling good about itself?
Comparison One: Interface Design Determines Generalization (V18 Game World). The task: the model writes a game movement-rule engine, which the host uses to traverse a map; a cell lights up only if the engine's judgment is correct. The sole variable between the two experimental runs was one extra field in the probing interface—the destination cell's terrain (toTerrain). The result: on the training side, the evolution curves were almost identical round by round (16 cells → 40 cells → all 51 cells lit). On the hidden maps, however, with the order reversed and all coordinates shifted, the version without terrain input scored 0/146, and the model reported memorizing the training map's coordinates. The version with terrain input achieved a perfect 146/146, and the model reported that it "contained no coordinates whatsoever." A caveat is needed here: on another map containing previously unseen terrain, both versions scored 24/29. Unseen things remain a boundary for either version; the "perfect score" here applies only to new layouts of the same terrain types. The same evolution process produced radically different generalization capabilities: whether the model can learn rather than memorize is determined by interface design. More notably, the model in the no-terrain version actually "knew" the correct answer. Its final report gave a completely correct architectural diagnosis—"a truly general solution needs dungeon state as input"—but with that interface, it had no viable path and could only memorize the map.
Comparison Two: The Contract's Information Form Determines Success or Failure (V19 Agent Empire). The task moved up to the organizational level: Chief does not do the work itself. Every capability must be a dynamic tool it creates, and every worker must be an actual spawned sub-agent session. The four-stage objective was woodcutting, housebuilding, mining, and building a wonder. run1 provided only a contract described in prose: all 97 tool-definition attempts failed, with the model cycling among three API-shape errors and producing nothing from 194 calls. run2 embedded a verified code template verbatim in the prompt: 32 calls, 0 failures, with 4 strategy tools created correctly on the first attempt, 9 actual worker sessions each performing their assigned role, and a wonder completed in 4 turns, lighting up the entire map: 192/192. The same model, the same task, the same engine—the only variable was the contract's information form. The form of a contract matters more than whether a contract exists: a "contract described in prose" is approximately equivalent to no contract at all. A template that runs verbatim is necessary, and smoke tests ensure the template itself is correct.
Comparison Three: Feedback Does Not Equal Capability (V14 vs V15). Both sides received a round budget far beyond what was actually needed. V14 was an unstructured task whose rules could not be inferred: it achieved a perfect 24/24 in the training area, but only 4/16 on the holdout, equivalent to chance. The model's technique was a hard-coded lookup table—classic score gaming, exposed immediately by the hidden probes. V15 was a task with inferable structure, whose hidden rules involved four number-theoretic concepts: it achieved 60/60 in 4 rounds and generalized perfectly to the holdout, scoring 20/20. Neither experiment exhausted its budget. The conclusion: what determines the reachable space is not the round budget, but the information gain in each round's feedback. Whether feedback offers information gain, in turn, depends on whether the task itself has inferable structure. The intuition that "with feedback, evolution can continue indefinitely" has already been falsified.
Mapping each element of the arena to reinforcement learning terminology reveals that it constitutes a complete RL infrastructure:
Behind the trajectories is an empirical finding that runs throughout the POC and deserves separate attention: all the artifacts above—the model conversation transcript (transcript.jsonl), the trajectory dataset (steps.jsonl, 96 model-level step records), the Web replay page (evolution.html), and the empire's live dashboard (game-live.html)—are not independently stored "second copies of the data." They are all derived from the same session event log: export-trajectory.py computes each step's input/output/usage from the session log; build-viewer.py projects an interactive page from the trajectory data; the dashboard's world snapshots are another view of the session event stream. There is no second store, so there is no risk of "conversation history failing to match audit records." Consistency is guaranteed by structure, not maintained through discipline. This is the empirical demonstration of Pillar Two, "everything is derived," throughout the experiment.
Finally, three boundaries must be made explicit. First, this POC performed no weight updates, no multi-episode sampling, and integrated no optimization algorithm. It validated that "a complete closed loop of environment + self-expandable action space + verifiable reward + dense attribution + replayable trajectories can be built on DSH." This establishes feasibility at the RL infrastructure level, not a training result. Second, the combined interception behavior of guardrails (sandbox/approval) and self-evolution was not validated in this round. Third, capabilities do not persist across sessions by default; retaining them requires manual consolidation.
V20/V21 extend the same self-evolution mechanism into a 3D voxel world: V20 Voxel Pioneering (a Three.js 3D dashboard, five capability gate checks, and a lighthouse endgame), and V21 Self-Evolving Pioneering (craft ops inventing new gameplay, with inheritance across games).
In the V20 experiment, using the same capability evolution and the same gate logic, the model directed workers on a three-dimensional island to gather resources and build a lighthouse, continuing all the way to the endgame in which the lighthouse lit up. Every milestone passed validation. This is a preview of "self-evolution" moving from engine validation into gamified applications.
V21's craft ops and cross-game inheritance mechanisms have been implemented, but the intergenerational closed loop has not yet actually been run. One further point must be made explicit: cross-session capability inheritance is a workaround we built ourselves on the host side, not a capability provided by DSH. At present, DSH does not provide automatic continuation of runtime-mounted components across sessions. To an extent, this is precisely what enterprise platforms need to do.
V22 (distillation and consolidation approval, currently in the design phase and awaiting a live run) is the next link in the narrative chain. V11 demonstrated that "without consolidation, it disappears"; V22 aims to demonstrate that "after consolidation, it remains." After the model completes a task in the arena, it consolidates a runtime mount into a workspace skill file, subject to an approval completeness check covering version number, purpose, and test cases. If the requirements are not met, it is rejected with reasons. After consolidation, a holdout in a new session verifies whether the capability transfers. This is the final link of "agile experimentation, cautious consolidation" in the POC.
Today, enterprise agent capability sets are release-driven: the tool surface is written into configuration and fixed before going live. When a requirement is not covered, the agent has only three options: find a workaround, fail, or wait for the next version. The POC demonstrated a new path: an agent can add a missing tool at runtime, taking effect in the same turn; the host uses a capability gate (the host first checks whether the corresponding tool is actually running and rejects the action if it has not been created) to ensure that "each node in the technology tree is not a Boolean flag, but a capability you have actually implemented." But growth must be gated: runtime experiments require no approval; distillation and consolidation must be approved. DSH makes "agile experimentation, cautious consolidation" structural—a prerequisite for self-evolution to enter enterprise production environments.
Today, the vast majority of enterprise agent session logs go unread until an incident occurs, and are deleted once the incident has been investigated. The log model in DSH points to another use: every event type has a corresponding post-training purpose. Approval pairs are preference data; records of attempts to exceed permissions are boundary annotations; goal turns are structural data for long-running tasks; environment switches are ablation-experiment data. Two design details—separate storage of audit data and conversations, and one anchor event for each model invocation—make this log ready to use, with no post hoc cleaning required. Every bit of investment in the safety of an enterprise agent deployment also accumulates training data assets.
Most enterprise systems maintain data consistency through team discipline: agree that "state must match the log," then rely on code review and testing as safeguards. DSH takes a different path: the log is the state, everything is derived, and divergence is structurally impossible. When "conversation history" and "audit records" are two projections of the same events, rather than two tables that need synchronization, this class of bug and its associated compliance risks no longer need to be guarded against. The implication for enterprise platform design is that governance objectives should not be pursued through processes and rules; they should be guaranteed by data structures.
DeepSeek Harness is a model vendor's engineering answer to two questions: how to constrain an agent at runtime, and how to make it more capable over time. Its answer can be distilled into three statements:
From a post-training perspective, it completes two-thirds of the full enterprise evolution path: environment shaping and trajectory accumulation. By leaving the third stage "to the vendor," it makes the handoff point explicit. Our POC ran a minimal closed loop on this foundation, and used holdout tests and controlled experiments to measure where the path breaks—interface design, contract form, and feedback quality.
For enterprises, this article's conclusion can be simple: every log, every approval, and every attempt to exceed permissions that your agent system produces today is the seed of your future training data. The only difference is whether you discard them as waste or, like DSH, build their collection into the architecture. The latter is what "enterprise evolution" means in engineering terms.
Alibaba Cloud DevOps AI Assistant Update: AI at Every Stage of DevOps Collaboration
From Long-Horizon Agents to Super-agents: Unlocking More Scenarios
818 posts | 61 followers
FollowAlibaba Cloud Community - September 14, 2026
Alibaba Cloud Native Community - April 28, 2026
Alibaba Cloud Community - September 22, 2026
Alibaba Cloud Native Community - June 8, 2026
Alibaba Cloud Native Community - November 11, 2026
Alibaba Cloud Community - May 21, 2026
818 posts | 61 followers
Follow
Platform For AI
A platform that provides enterprise-level data modeling services based on machine learning algorithms to quickly meet your needs for data-driven operations.
Learn More
Wan3.0
Unleash Your Creativity Try Wan 3.0 now — longer narratives, greater control, endless creativity.
Learn More
Qoder
From Assisted to Autonomous — Adapting to Every Programming Need
Learn More
AgentCore
AgentCore unifies agent construction, governance, and execution capabilities so enterprises can deploy diverse agents with confidence.
Learn MoreMore Posts by Alibaba Cloud Native Community