CubeSandbox

English

简体中文

English

简体中文

Appearance

OUC Online: Session Isolation and Lifecycle Practices for an Agent Code Execution Layer ​

Business Context ​

OUC Online is building a Manus-like Agent platform for education and office scenarios, supporting user-defined Agents, Skills, Tools, knowledge bases, and MCPs. Typical tasks include knowledge-base-driven XLSX reports, PPTX courseware generation and validation, document parsing and re-processing, scripted data analysis, and multi-Agent collaboration. The platform has five layers: lea-agent (LLM main loop), lea-config (configuration), lea-tools (tool gateway + sandbox session management), CubeSandbox (isolated execution), and NFS/OBS (session workspace and deliverable storage). It is currently in evaluation, not yet in production.

Key Challenges ​

  • Execution boundary for untrusted code: arbitrary Python/Shell/Node scripts may be generated by the model; ordinary containers/shared VMs are unfit as the boundary.
  • The lifecycle dilemma: deleting a session sandbox immediately makes the next message pay a cold start again; keeping it long-term consumes sandbox slots and host resources.
  • Mistaken reclamation under multi-replica: app-local timestamps only reflect what one replica has seen, and service restarts zero them out.
  • Deployment freeze at documented resources: on 4C8G/16G machines, loading the PVM KVM module via modprobe kvm_pvm froze the server with system-level OOM.

Solution with Cube Sandbox ​

  • Three-stage lifecycle: create (on first code execution, tagged with lea.session_id / lea.tenant_id) → keep-alive (auto-pause after 15 idle minutes via on_timeout=pause + auto_resume=true; auto-resume on the next message with the working directory intact) → reclaim (a platform loop scans Cube every 60 seconds, reclaiming only sandboxes carrying the platform session tag and already paused).
  • Reclamation criteria converge on platform-side state: using Cube-returned state and endAt instead of app-local timestamps — all replicas see the same facts, eliminating mistaken deletion.
  • Data outlives the sandbox: the session /workspace persists independently via NFS host-mount; long-term deliverables stay in OBS.
  • Deployment troubleshooting: lowering kmem_cache.max_num from the default 16000 to 2000 let the module load — pinpointed to system-level memory exhaustion during module loading (without journald persistence, the root cause could only be confirmed down to "memory exhaustion").

Results and Benefits ​

  • After warm-up, sandbox creation takes 0.3–0.6s; first execution ~2.8s end-to-end (light samples, no stress test).
  • Four distilled evaluation-stage suggestions: verify the resource floor yourself; base lifecycle criteria on platform-side state; finish log persistence before deploying; design the reclamation strategy during evaluation.

References ​