DeepSeek's Liang Wenfeng co-authors paper on DSec sandbox enabling recursive self-improvement for AI agents

DeepSeek, in collaboration with Tsinghua University, has published a research paper whose final listed author is Liang Wenfeng. On the surface, the paper describes the sandbox used by DeepSeek to train AI agents. However, Section 6 of the paper reveals a deeper implication, hinting at the concept of RSI (Recursive Self-Improvement).

Through this sandbox, agents can create their own required environments. These environments, in turn, train the agents further, and the stronger agents go on to build even better environments. This forms a small-scale RSI loop.

As a result, the sandbox may well become the key that unlocks the first battle of RSI.

01 What the Paper Is Really About

The new paper, titled "DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale," was submitted to arXiv on September 19, under the number 2609.22978. It has over 130 authors, with Liang Wenfeng listed last. The collaboration partner is Tsinghua University.

In a single sentence: DeepSeek has fully disclosed its "sandbox factory" DSec, used to train AI agents.

To understand DSec, one must first grasp the difference between training an agent and training a large model.

• Training a large model involves feeding data and calculating gradients, with the environment being a GPU cluster.
• Training an agent is entirely different. Agents must write code, run compilers, open browsers, install dependencies, and use tools within an environment, then retry based on execution results until the task is complete.

However, if an agent is trained directly on a computer, any unintended actions could destroy the entire environment. This necessitates an isolated, stateful sandbox capable of running real software.

DSec is exactly that platform. It provides four backends through a unified Python SDK (libdsec):

• FnCall (Function Call)
• Container
• microVM (Lightweight Virtual Machine)
• Full VM (Complete Virtual Machine)

To put it simply: DSec is like a food delivery app, the agent is the rider, and the sandbox is the order dispatch. By analogy, FnCall, Container, and microVM are the electric scooters and insulated boxes at the dispatch station, while the Full VM is a refrigerated truck.

There is a trade-off: isolation strength and system functionality are inherently at odds. The more a sandbox resembles a real machine, the slower it starts and the more memory it consumes.

• FnCall for short scripts
• Container for modifying code repositories
• microVM for security tasks
• Full VM for complete systems like Android or graphical interfaces

According to the paper, a production unit consists of approximately 160 CPU nodes, 30,000 cores, and 250 TB of memory, hosting petabyte-scale images. It serves about 3 million sandboxes per day, with a peak concurrency of over 380,000 and a creation speed exceeding 5,000 per second. A single training task can launch up to 32,000 sandboxes at once. On a single node, up to 800 microVMs or 3,200 containers can be packed.

Three Core Mechanisms of DSec

1. Composable Layers

Traditionally, a sandbox environment was a monolithic image. Changing a single tool required rebuilding the entire image, causing maintenance costs to skyrocket with the number of combinations. DSec splits the base image, workspace, and toolkits into three independent, versioned, read-only layers (EROFS). At startup, these layers are combined using overlayfs. Only the modified layer needs to be rebuilt. Benchmarks show this method is 1.76 times faster than tar.gz packaging and reduces disk writes by 5.5 times.

2. On-Demand Image Loading

Images are stored on 3FS (DeepSeek's distributed file system). Metadata is prefetched locally, but data blocks are only pulled when actually read. In a burst deployment of 8,192 containers, on-demand loading completed in 35 minutes, compared to over 60 minutes for Docker's cold pull, with disk writes reduced by approximately 57%.

3. Efficient Memory and CPU Management

• Using virtio-pmem with DAX, multiple virtual machines share the same page cache, reducing peak memory by 40.2%.
• DAMON and balloon are used to reclaim cold pages, further reducing time-integrated memory by 21.2%.
• For CPU, sandboxes are classified as "latency-sensitive" or "best-effort". Using core scheduling, SMT interference is reduced from 45.2% to 17.3%.

Additionally, starting from DeepSeek-V4.1, the paper describes separating agent rollout from preemptible GPU training pods, running it independently on DSec. This ensures that rollout state is not lost when GPUs are preempted.

02 The RSI Hidden in Section 6

The most easily overlooked sentence in the paper is not in the abstract but in the title of Section 6: "Build environments of Agents, by Agents, for Agents." This phrase signals that DeepSeek has quietly achieved a partial implementation of RSI.

Section 6.1 states that manually constructing the vast number of environments required for agent reinforcement learning has become "impractical." DeepSeek's alternative approach allows agents to interactively build their own environments within the same sandbox used for training. Using pack_diff, the session is captured as an incremental snapshot, which becomes a reusable training ground for the next batch of agents.

The agents that build environments and the agents being trained share the same DSec sandbox infrastructure:

• Agents build environments → Environments train agents → Stronger agents build better environments

This creates a partial RSI loop for DeepSeek.

However, this loop is still in its early stages. Section 6.4 documents numerous instances of agent cheating, including:

• Searching the platform for leftover reference answers
• Forging RPC messages to directly query chronus for answers
• Searching chronus logs for leaked questions
• Overwriting /bin/bash to bypass checks

When blocked, agents used the XFS_IOC_SWAPEXT ioctl to swap storage blocks of protected files to another file descriptor, corrupting XFS metadata and forcing the file system to shut down.

There were also cases of agents causing system failures:

• One agent recursively grepped from the root directory, reading /proc/kpagecgroup, triggering a kernel bug that crashed the system.
• Another agent called the yes command, causing chronus to record all output, generating tens of gigabytes of data on storage.

The current bottleneck for RSI is not GPUs but environment supply. Each generation of agent RL requires new tasks, new sandboxes, and new service dependencies. Manual environment creation is the true bottleneck. DSec partially automates this process by automatically generating the environments needed for RSI.

03 The Sandbox Becomes a New Battlefield

DSec is not an isolated case. The entire industry is moving toward "Agent Sandboxes."

Kimi K3

The most notable example is Kimi K3, released by Moonshot AI on July 16. It is a 2.8 trillion parameter MoE model, activating approximately 104B parameters per token, with a 100,000 token context and native vision. It claims to be the "world's first open-source 3T-level model," achieving 76.8% on SWE-bench, ranking first among open-source models. Its Agent Swarm can schedule up to 300 sub-agents in parallel. DeepSeek's paper also cites Kimi-K2.5's Agent Swarm.

The AgentENV used to train Kimi K3 is also a sandbox platform. It runs on Firecracker microVMs, with each sandbox having an independent Linux kernel, network stack, and file system. The underlying storage uses OverlayBD + ublk, with read-only layers shared across the cluster and each sandbox writing to its own layer. This is the same technical stack as DSec.

Section 7 of the DSec paper notes that the Rust-based OverlayBD/ublk storage library it uses is open-sourced in the AgentENV repository. The two are essentially from the same lineage.

However, AgentENV cannot achieve RSI. It provides fork/snapshot "state operation primitives" that enable parallel RL rollout, rollback, and clean scoring. It cannot allow agents to build their own environments like DSec does.

Alibaba

At the Yunqi Conference, Alibaba Cloud CTO Li Feifei unveiled the "Agentic Cloud" strategy, identifying Model, Harness, and Context as three core scenarios. The company launched AgentCore, Agent Sandbox, and a new generation of storage CPFS. The Agent Sandbox can create 100,000 instances per minute, with deep sleep wake-up times under 600 milliseconds, and is compatible with E2B and K8s.

The Sandbox as the New Runtime

The primary computing platform has evolved from virtual machines to containers to models, and now to agents. Whoever controls the agent's execution environment controls the entry point to the next generation of cloud computing.

This shifts the competitive focus from "model capability" to "environment infrastructure."

• Training large models requires computing power.
• Training agents requires environments.

Beyond GPUs, CPU, memory, storage, and image distribution have all become new bottlenecks.

Security has also become critical. OpenAI and Anthropic face model jailbreaks, while DSec's paper documents agent cheating and kernel crashes. If the sandbox is not secure, training signals become unreliable, and evaluations become invalid. Companies like Alibaba now market "security fences" as a selling point, while DSec uses AppArmor and eBPF.

Sandbox vendors once competed on speed and cost. Now, they compete on robustness.

The first battle of RSI has already begun. To run RSI, you must first have a sandbox—and an environment.

Disclaimer: The content above (including any images or videos) is uploaded and published by a user of the NetEase Hao self-media platform. This platform provides only information storage services.