DeepAgents in Practice: Unpacking the Execution Mechanism Behind Skills Scripts in Claude Code

Why Is Claude Code Getting Better and Better?

Claude Code (and Open Code-style tools) have been taking the developer community by storm lately. Many attribute this to improvements in the underlying model — a smarter foundation model is certainly part of the story. But Bilibili creator Xiao Bin, in his DeepAgents hands-on sharing session, offered a more fundamental insight: the real reason Claude Code keeps getting better is that the number of available Skills (skill libraries) keeps growing, and those Skills keep getting more powerful.

In other words, model-level progress is the foundation, but what truly pushes a tool from "usable" to "genuinely good" is the skill ecosystem built around it. Data analysis reports that a large model once couldn't handle on its own can now be completed simply by loading the right Skill library. This kind of plug-and-play capability expansion is the direct driver behind the dramatic leap in AI coding tool experience.

What Exactly Are Skills?

As defined in the session, Skills are essentially skill libraries or skill packages — a capability extension mechanism that has emerged in recent times. Their defining characteristic is modularity: each Skill package bundles three types of content — instructions for the large model, metadata, and accompanying script resources. Those script resources are exactly what this discussion focuses on.

These Skill packages come in all shapes and sizes: some contain prompts, others include executable scripts or various code snippets. Functionally, they cover data analysis, data retrieval, code generation, and even dedicated skills for testing and executing code. The agent automatically invokes and runs the appropriate Skill package whenever it's needed.

Think of an agent as a robot onto which you keep mounting extension packs. Mount ten, twenty, a hundred, or even three hundred Skill packages — each functioning correctly — and the agent's overall capability grows exponentially.

This also explains a common observation: why does the experience with the same underlying framework keep improving over time? The richer the ecosystem, the broader the agent's capabilities.

From a technical standpoint, Skills share certain similarities with the MCP (Model Context Protocol) — both aim to provide external capabilities to large models in a standardized way. MCP, proposed by Anthropic, defines a protocol specification for models to safely invoke tools and read resources; Skills, by contrast, lean more toward a "packaged distribution" ecosystem perspective, emphasizing out-of-the-box usability and community sharing. The two are not mutually exclusive — mature agent frameworks often support both extension methods simultaneously, with MCP handling standardized interfaces and Skills powering the capability marketplace.

It's worth noting that the design philosophy of Skills bears a strong resemblance to the VS Code extension marketplace: the core host program stays lean, while capabilities are layered on through plugins/extension packages as needed. The advantage of this architecture is that the iteration cadence of the main program is decoupled from capability expansion — community developers can independently publish new Skill packages, and users gain new capabilities without waiting for a main program update, creating a positive flywheel effect for the ecosystem.

The Core Question: Where Do Skills Scripts Actually Run?

Prompts are straightforward — they're passed directly to the large model. The real question worth digging into is: how exactly are the script code inside Skills executed?

To understand this, one thing must be clear first: Claude Code and Open Code are both, at their core, general-purpose agent programs. When this program runs, it has its own independent process. The natural follow-up question is: do Skills scripts also run in the same process and same thread as the agent?

The answer is almost certainly no. The reason is straightforward: security. If the script code inside a Skill runs within the same process as the agent, any malicious or buggy script could compromise the security of the entire system. Imagine an externally loaded script having direct access to the main agent process's memory and permissions — that's a risk no enterprise environment can tolerate.

The correct architecture must therefore be isolated execution — scripts don't run inside the agent's main process, but are instead placed in a controlled sandbox environment. This is precisely the value of the "sandbox backend in practice" theme: discussing sandboxes in isolation makes no sense; they must be understood in the context of Skills execution. The two are two sides of the same coin.

Why Sandboxing Is Non-Negotiable

The core tension that a sandbox backend resolves is this: agents need the flexibility to invoke an ever-growing number of third-party scripts, yet those scripts must not be allowed to threaten the security of the main system. By isolating script execution inside an independent sandbox process, even if a Skill script misbehaves, the impact is contained within the sandbox and cannot affect the agent itself or the host environment. This mechanism is the prerequisite for a skill ecosystem to safely scale.

Sandbox implementations exist at multiple technical layers. Common approaches include OS-level container isolation (e.g., Docker), where a temporary container is spun up for each Skill script execution and destroyed upon completion; language runtime-level sandboxing, such as blocking dangerous system calls within a restricted Python interpreter; and WebAssembly (Wasm)-based sandboxes, where scripts are compiled to Wasm bytecode and executed in a controlled runtime. Each approach involves different trade-offs between isolation strength, cold-start latency, and resource overhead.

For enterprise self-developed agent scenarios, the container approach is usually the preferred choice: thorough isolation, auditable behavior, flexible resource constraints, and compatibility with existing DevOps infrastructure. The sandbox backend also needs to address communication protocols — how the agent's main process passes inputs to the sandbox and retrieves execution results, typically via local IPC (inter-process communication) or a lightweight HTTP interface, with timeouts and resource quotas set to prevent malicious or runaway scripts from exhausting host resources.

Enterprise Custom Agents: Real-World Pain Points

The third question raised in the session is highly practical: if a security-conscious enterprise wants to develop its own internal, customized agent similar to Open Code, how should it go about it?

This question gets at a dilemma many teams face. For large enterprises — not just state-owned companies, but any organization with data security and compliance requirements — simply installing an external Claude Code directly on production servers is something leadership is often uncomfortable with. Data flow, controllability of script execution, and code auditability are concerns that can't be ignored.

As a result, "building an in-house agent" has become a practical choice for many enterprises. And to build one, two things must be thoroughly understood: first, how to design a Skills-style capability extension mechanism; and second, how to implement secure script execution — that is, the sandbox backend. Only by understanding the underlying logic that makes mainstream tools work well can you replicate and deploy it in a controlled manner within your own environment.

Summary

This DeepAgents hands-on session uses three progressively deeper questions to connect the core threads of today's AI coding tools: the root of Claude Code's improved experience lies in the flourishing of the Skills ecosystem; Skills scripts must be isolated in a sandbox for security reasons; and enterprises that want to build their own controllable agents need to master both Skills and sandbox backend as foundational building blocks. For developers focused on AI coding and agent architecture, this line of thinking — from "why does it work so well" to "how do I build it myself" — offers a clear and actionable entry point.