feat(workspace): 懒加载沙箱配置 — 将 E2B/Docker 和沙箱的启动推迟到首次工具调用时进行

[dongfeng3692]

@DavdGao 目前，每一个聊天请求都会配置一个完整的沙箱并启动沙箱内的 MCP 网关。
本提案建议：实现懒加载配置——在会话开始时仅加载必要的内容，不初始化sandbox，仅在首次后端调用时才创建沙箱并启动网关。如果此功能尚不在路线图中，我很乐意协助实现。
(ps:我的想法 对于sandbox的mcp，我觉得做成显式配置 更加合理一点，成 MCP 配置就不启动gateway)

[DavdGao]

@dongfeng3692 Do you mean the sandbox pooling functionality? We are working on this in #1755

[dongfeng3692]

我指的不是沙箱池^_^。我想说的是懒加载：简单会话（比如一句 "hello"）很可能只是纯文本问答、用不到沙箱能力，目前却会提前分配并绑定 E2B，造成浪费。希望会话开始时不创建沙箱，只在真正需要代码执行 / 工具调用时才按需创建。

[DavdGao]

@dongfeng3692 That's a fair point. However, in practice, the workspace (or harness) is already part of the agent's context — for example, skill names and descriptions are injected into the system prompt, and long-term memory markdown files may also be loaded into it. Since these resources are all part of the workspace/sandbox, they need to be ready by the time the agent generates a response. This means the sandbox effectively has to be initialized before the first reply anyway.

[lumman0]

@DavdGao ## Proposal: conditional workspace initialization with skills available before sandbox startup

I'd like to expand this proposal with a possible approach to the context-loading concern raised above.

Motivation

I encountered this in actual use: when an agent is configured with a sandbox-backed workspace, even a simple conversational request can trigger sandbox startup before the first response. This adds latency to the chat experience and consumes sandbox resources even when the conversation never needs them.

Could workspace initialization support an optional lazy mode, where the context needed by the agent is prepared first and the actual sandbox is provisioned only when an operation requires it?

Skills before sandbox startup

For skills supplied through an application-accessible source, their names, descriptions, and full SKILL.md content could be loaded into application memory without first uploading them to the sandbox.

This would allow:

• Skill names and descriptions to remain available in the agent's context.
• The Skill tool to return instructions without starting a sandbox.
• Instruction-only skills to work entirely without sandbox provisioning.
• Skills containing scripts or additional resources to defer sandbox startup until those files or execution capabilities are actually needed.

When a sandbox-dependent operation occurs, the workspace would provision the sandbox, materialize the required skill directories, and continue the operation.

This means a skill would not need to be classified permanently as “lightweight” or “heavyweight.” Even a skill containing executable scripts could remain usable without a sandbox while the agent only reads its instructions.

Conditional activation

The activation condition would depend on the operation's requirements.

Operation	Expected behavior in lazy mode
Pure conversation with all required context available outside the sandbox	Keep the sandbox uninitialized
Listing skills or reading externally available SKILL.md content	Keep the sandbox uninitialized
Calling a tool that runs independently of the sandbox	Keep the sandbox uninitialized
Calling an externally accessible MCP service	Keep the sandbox uninitialized unless the operation itself depends on it
Executing commands or accessing files inside the sandbox	Initialize the sandbox
Discovering or calling sandbox-hosted MCP tools	Initialize the sandbox when discovery or execution requires it
Writing context or oversized results to workspace storage	Initialize the sandbox if that storage requires it

For skills, provisioning would include preparing their files before the dependent operation proceeds.

Relationship to MCP gateway initialization

Issue #2113 discusses avoiding unconditional initialization of the in-sandbox MCP gateway. That would complement this proposal.

If no sandbox-hosted MCP service is needed, the gateway should not itself force sandbox startup.

For sandbox-hosted MCP services, tool discovery may require starting the service before the agent can use it. That would be a valid activation condition.

Existing workspace context and compatibility

The concern about workspace-provided context is valid. If required context, such as existing memory files, is available only inside a persisted workspace, initializing that workspace before the first response would remain appropriate.

The proposal is to make this conditional: when the required context is already available outside the sandbox, preparing it should not require provisioning the execution environment.

Two compatibility details seem worth discussing:

• Skill modifications: Skills are currently writable inside the workspace. Lazy loading should preserve that capability and avoid serving an outdated application-side copy after a skill has been edited or deleted.
• Context offloading: Offloading currently writes to the workspace. It could remain an activation condition initially, with independent offload storage considered separately.

Existing eager initialization and supported prewarming options could remain available.

Expected outcome

A conversation using only model inference, skill instructions, and tools independent of the sandbox could finish without ever creating a sandbox.

If the conversation later needs sandbox capabilities, the workspace would initialize it at that point and continue the operation.

Would this separation between preparing agent context and provisioning the execution environment address the concern raised in this discussion?