Cómo alojar SandBase Harness en su propio VPS

Qué se obtiene al alojar uno mismo el entorno de ejecución de agentes SandBase

Alojar uno mismo el entorno de ejecución de agentes SandBase significa ejecutar SandBase Harness en un servidor propio, de modo que las sesiones, las credenciales, la memoria y los registros de auditoría se almacenen en el disco propio en lugar de hacerlo en el de terceros. Es un servicio de Node. Escucha en 127.0.0.1:3000, proporciona una API HTTP /v1 y una consola web, y guarda su estado en SQLite junto a los archivos de los agentes.

La API /v1 sigue el modelo de Claude Managed Agents (CMA), la API alojada para agentes gestionados. Esto hace que este entorno de ejecución sea interesante en ambos sentidos: puede escribir código con el SDK de Anthropic y dirigir su baseURL a su propio servidor, y después trasladar el mismo código a una implementación alojada.

SandBase Harness no incluye un modelo. Realiza llamadas a uno. A fecha de 12 de octubre de 2026, admite OpenAI, Anthropic, MiniMax y endpoints compatibles con OpenAI, lo que incluye gateways autoalojados y proveedores como DeepSeek V4. MiniMax se incorporó como proveedor de primer nivel en v0.3.3, con la opción de usar un endpoint global o uno de China continental. Aun así, debe aportar una clave de API o un servidor local que hable la API de OpenAI.

Qué necesita antes de empezar

• Un VPS con Ubuntu 24.04 y al menos 2 GB de RAM. La compilación de TypeScript es el paso que más recursos consume durante la instalación.
• Node.js 22 o posterior y npm 10 o posterior. Son los requisitos mínimos estrictos indicados por el proyecto.
• git, además de una clave de API del proveedor del modelo que vaya a utilizar.
• Docker, sólo si quiere usar sandboxes de contenedor independientes por sesión.

Ubuntu 24.04 incluye Node 18.19 en su propio repositorio, una versión inferior al mínimo requerido. Por eso, instale Node desde NodeSource.

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs git
node -v
npm -v

node -v debería mostrar v22 o una versión posterior, y npm -v debería mostrar 10 o una versión posterior. Si node -v todavía muestra v18.19.1, el paquete de la distribución sigue instalado y tiene prioridad en PATH. Elimínelo antes de continuar, porque la compilación utiliza el node que el shell encuentra primero.

Instalar SandBase desde la etiqueta v0.3.8

Instale desde una etiqueta, nunca desde una rama que cambia. Un clon superficial de main le proporciona lo que se haya incorporado hace una hora, y es posible que las claves de configuración siguientes no coincidan con ello. v0.3.8, publicada el 30 August 2026, es la etiqueta actual a fecha de 12 October 2026 y es la etiqueta que fija la propia documentación de instalación del proyecto.

sudo install -d -o "$USER" -g "$USER" /opt/sandbase
cd /opt/sandbase
git clone --branch v0.3.8 --depth 1 https://github.com/sandbaseai/sandbase-harness.git
cd sandbase-harness
npm ci
npm run build

Use npm ci, no npm install. ci instala las versiones exactas registradas en el archivo de bloqueo confirmado, por lo que el árbol coincide con el árbol que probaron los mantenedores. npm install puede resolver versiones más recientes, y así una etiqueta fijada deja de estar fijada sin que resulte evidente.

Ahora cree un espacio de trabajo. El espacio de trabajo es un directorio independiente que contiene los archivos del agente y todo el estado de ejecución. Mantenerlo fuera del checkout del código fuente permite obtener una etiqueta más reciente sin modificar los datos.

mkdir -p /opt/sandbase/workspace
cd /opt/sandbase/workspace
node /opt/sandbase/sandbase-harness/dist/index.js init
node /opt/sandbase/sandbase-harness/dist/index.js start

init escribe un directorio .managed-agents/ en el espacio de trabajo. start inicia la consola en http://127.0.0.1:3000/dashboard y la API en http://127.0.0.1:3000/v1. Ninguno de los dos es accesible todavía desde su portátil, lo cual es correcto y se explica más adelante. Acceda ahora a la consola mediante SSH:

ssh -N -L 3000:127.0.0.1:3000 you@your-server

Esa ruta larga de node .../dist/index.js resulta incómoda, así que asígnele un nombre.

alias sandbase='node /opt/sandbase/sandbase-harness/dist/index.js'

Los comandos siguientes están escritos como sandbase <command> sobre esa base.

No lo instale desde npm

El proyecto lo indica en su propia documentación de instalación: el paquete managed-agents sin ámbito que aparece en npm no pertenece a este proyecto. Por tanto, npx managed-agents y npm install -g managed-agents descargan algo que no está relacionado con el entorno de ejecución que necesita. Instale el proyecto desde el código fuente etiquetado de GitHub hasta que los responsables anuncien un paquete oficial con ámbito. No es una simple nota al pie en el historial del proyecto: v0.3.1 existe principalmente para sustituir el inicio rápido antiguo de npm por el procedimiento fijado que usa el código fuente etiquetado.

Configurar el espacio de trabajo para usar un proveedor de modelos

init escribe .managed-agents/config.yaml. Se configura un proveedor para todo el espacio de trabajo y, después, cada agente elige identificadores de modelo concretos.

model:
  provider: openai
  api_key: ${OPENAI_API_KEY}
storage:
  metadata:
    provider: sqlite
    options: {}
  artifacts:
    provider: local
    options:
      base_path: files

El formulario ${OPENAI_API_KEY} toma el valor del entorno del proceso. Por tanto, la clave queda fuera del archivo de configuración y de todas las copias de seguridad que haga de ese archivo. Guárdela en un archivo de entorno que sólo root pueda leer, ya que systemd lee EnvironmentFile= como root antes de eliminar privilegios.

sudo install -d -m 750 /etc/sandbase
sudo touch /etc/sandbase/runtime.env
sudo chmod 600 /etc/sandbase/runtime.env

Abra ese archivo con un editor y añada una línea: OPENAI_API_KEY=sk-.... Las claves de los proveedores deben guardarse aquí. Los secretos que un agente usa durante una sesión deben guardarse en los almacenes de credenciales del entorno de ejecución. Es un problema distinto, con un alcance de impacto diferente, y conviene leer cómo mantener los secretos fuera de los agentes de IA antes de pegar un token de producción en cualquiera de los dos lugares.

El YAML del agente: mcp_servers, tools y políticas de permisos

Los agentes se definen como archivos YAML en el directorio agents/ del espacio de trabajo. Esta es la parte del entorno de ejecución en la que realmente pasará tiempo. Las claves se entienden mejor después de escribir manualmente un bucle de agente pequeño, porque cada una controla algo que, de otro modo, tendría que programar usted mismo: el prompt del sistema, la lista de herramientas y la comprobación que se ejecuta antes de activar una herramienta.

name: Incident commander
description: Triages alerts and coordinates response.
model: gpt-4o
system: |-
  You are an on-call incident commander.
mcp_servers:
  - name: sentry
    type: url
    url: https://mcp.sentry.dev/mcp
tools:
  - type: agent_toolset_20260401
    default_config:
      permission_policy: { type: always_ask }
    configs:
      - name: bash
        permission_policy: { type: always_ask }
  - type: mcp_toolset
    mcp_server_name: sentry
metadata:
  template: incident-commander

Cárguelo y compruebe que se haya importado:

sandbase reload
sandbase list
sandbase chat agent_assistant --message "hello"

reload importa el YAML inicial en SQLite. list ahora debería mostrar el agente con un ID. Si list no lo muestra, el archivo no se analizó y .managed-agents/logs/runtime.log contiene el motivo.

mcp_servers declara endpoints de MCP (model context protocol). type: url significa que el runtime se comunica por HTTP con un servidor que se ejecuta en otro lugar, por lo que aquí funciona cualquier servicio que ya administre, incluidos los servidores MCP alojados en el mismo VPS que el runtime. La búsqueda web suele ser la primera herramienta que se utiliza, y conviene leer cómo proporcionar al agente su propia instancia de SearXNG antes de conectar una, porque una herramienta que devuelve páginas escritas por terceros introduce texto no confiable directamente en el contexto del modelo. La primera integración más prudente tiene la forma opuesta: un endpoint de solo lectura sobre datos que ya controla. Eso es lo que openGym expone junto al propio registro de entrenamientos, para que el agente pueda responder preguntas sobre su historial de entrenamiento sin poder modificarlo.

Declarar un servidor no entrega sus herramientas al agente. La lista tools se encarga de ello mediante una entrada mcp_toolset cuyo mcp_server_name coincide con el name anterior. Si el agente se comporta como si las herramientas de MCP no existieran, compare esas dos cadenas carácter por carácter antes de buscar en otro sitio.

agent_toolset_20260401 es el conjunto de herramientas integrado. El sufijo con fecha es una versión del esquema, por lo que un agente fijado en ella conserva las definiciones de herramientas contra las que se escribió. default_config establece la política para todas las herramientas del conjunto, y cada entrada de configs sustituye esa política para una herramienta concreta por nombre, bash en el ejemplo.

permission_policy es donde un entorno de ejecución ofrece una ventaja frente a una simple llamada al modelo. always_ask pausa la sesión y espera a que una persona apruebe la llamada antes de ejecutarla. always_allow permite ejecutarla. Establecer bash en always_ask significa que el agente no puede ejecutar un comando de shell sin que usted vea primero el comando exacto. Es el mismo control que usaría al ejecutar Claude Code de forma segura en un VPS. Si también ejecuta DeepSeek Harness, los mismos controles están disponibles allí como complementos y no como claves YAML, y los plugins que limitan los presupuestos y controlan las llamadas a herramientas son el equivalente más cercano a este bloque.

Los cuatro modos de sandbox y cuándo conviene usar cada uno

Las llamadas de herramientas que ejecutan código se ejecutan dentro de un sandbox. El backend se elige por entorno mediante sandbox_provider en el objeto config del entorno, o se establece como valor predeterminado del workspace en la consola, en Settings, dentro del editor Sandbox, en Advanced. Los entornos se crean mediante la API en POST /v1/environments.

local ejecuta el código como un proceso secundario del runtime, en el host y con el usuario del propio runtime. Es el valor predeterminado cuando un entorno no especifica ningún backend. Es razonable mientras usted sea el único usuario y el agente sólo lea archivos que le pertenecen. Si un entorno especifica un backend que el runtime no puede cargar, se rechaza en lugar de ejecutarse silenciosamente aquí. Este modo no proporciona aislamiento. Una llamada de herramienta que elimina archivos elimina sus archivos, y una llamada que lee /etc/sandbase/runtime.env lee su clave del proveedor.

docker inicia un contenedor por sesión.

{
  "sandbox_provider": "docker",
  "image": "node:22-slim",
  "resources": { "memory": "1g", "cpu": 1 }
}

La sesión obtiene su propio sistema de archivos y el contenedor se elimina junto con la sesión. Los límites de memoria y CPU no forman parte del modo. El runtime sólo añade --memory y --cpus al contenedor cuando el bloque resources del entorno los establece, como en el ejemplo. Por tanto, un entorno sin ese bloque obtiene un contenedor sin un límite propio. Omita image y el runtime usará ghcr.io/sandbaseai/sandbase-harness-sandbox:latest. Cambie a este modo en cuanto un agente ejecute código que usted no haya escrito. El coste es que el usuario del runtime necesita acceso al socket de Docker, y pertenecer al grupo docker equivale a tener root en el host. Los contenedores por sesión tienen la misma configuración que los sandboxes de agentes autogestionados con un contenedor por ejecución, por lo que el razonamiento sobre lo que podría alcanzar un proceso que escape del sandbox se aplica aquí sin cambios.

kubernetes ejecuta la carga de trabajo de la sesión como un pod y la administra con kubectl exec y kubectl cp. La imagen del runtime necesita que kubectl esté presente, y su ServiceAccount necesita permisos RBAC (control de acceso basado en roles) para crear, eliminar, obtener, listar y monitorizar pods en el namespace de destino, además del subrecurso exec. Este modo sólo merece el trabajo de configuración si ya ejecuta un clúster.

self-hosted worker se denomina remote en Settings y self_hosted en un Environment. No ejecuta el código de las herramientas en este equipo. El runtime coloca el trabajo en una cola, y un worker externo, al que se proporcionan la URL y la clave de la API del worker desde Settings, reclama y completa los elementos en cola fuera del host. Es adecuado cuando el código debe ejecutarse en una máquina que no contiene su clave del proveedor. Los límites de recursos sólo se aplican mediante docker y kubernetes, por lo que limitar un worker es responsabilidad del host del worker.

¿Por qué el runtime está vinculado a 127.0.0.1?

Porque se inicia con la autenticación desactivada. El runtime habilita la autenticación mediante bearer token cuando existe al menos una API key, y una instancia nueva de init no crea ninguna. Vincularse a 0.0.0.0 con esa configuración predeterminada expondría en Internet un runtime de agente sin autenticación, con acceso a herramientas de shell y a la clave de su proveedor.

Por tanto, si quiere que sea accesible, deje intacta la dirección de vinculación y haga otras dos cosas.

Primero, active la autenticación. Establezca MANAGED_AGENTS_API_KEY en el archivo de entorno del servicio o cree una clave con POST /v1/api-keys. El comando devuelve un campo secret_key una sola vez y no vuelve a mostrarlo. Después, los clientes envían Authorization: Bearer <key> en cada solicitud de API o la misma clave como x-api-key, pero nunca ambas opciones a la vez. La clave protege la API, no la consola: las páginas del dashboard y sus recursos estáticos se cargan sin ella, al igual que /v1/x/health y /v1/x/metrics. Una clave representa una única identidad compartida. Si en realidad quiere un agente aislado independiente para cada miembro del equipo, con las claves del proveedor almacenadas en un gateway central, OneCLI está diseñado para ese modelo.

Segundo, coloque un reverse proxy delante y termine allí TLS (seguridad de la capa de transporte). El runtime sirve HTTP sin cifrar de forma deliberada y espera que otro componente gestione los certificados.

server {
    listen 443 ssl;
    server_name agents.example.com;

    ssl_certificate     /etc/letsencrypt/live/agents.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/agents.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

Dos de esas líneas no son decorativas. proxy_buffering off es importante porque las sesiones se transmiten mediante eventos enviados por el servidor (SSE). Con el buffering activado, nginx retiene la respuesta hasta que se llena su búfer. Por eso la consola no muestra nada mientras trabaja el agente y después muestra todo de golpe al final. proxy_read_timeout 3600s también es importante porque el valor predeterminado es 60 segundos. Si una transmisión permanece inactiva más de un minuto, el proxy la cierra en mitad de un turno y el fallo parece un bloqueo del runtime.

En el firewall, abra 22 y 443. Mantenga cerrado 3000, porque el proxy accede a él mediante loopback y ningún componente externo debe hacerlo. Como /v1/x/metrics responde sin una clave, añada location = /v1/x/metrics { return 404; } al bloque del servidor si prefiere no publicar las métricas del runtime.

Indique el SDK de Anthropic a su propio servidor

El runtime implementa una superficie con formato CMA /v1, por lo que un cliente del SDK de Anthropic puede comunicarse con él cambiando un solo campo.

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic({
  apiKey: process.env.MANAGED_AGENTS_API_KEY ?? 'local-dev-key',
  baseURL: 'http://127.0.0.1:3000'
});

También acepta las cabeceras beta que envían los clientes de Claude Managed Agents, anthropic-beta: managed-agents-2026-04-01 y anthropic-beta: agent-memory-2026-07-22. Una solicitud normal sin ninguna cabecera de compatibilidad se acepta como una solicitud local. Una solicitud que incluya x-api-key, anthropic-version o anthropic-beta se somete a las reglas del servicio alojado: se requieren la versión 2023-06-01 y la beta de managed-agents, excepto que las rutas /v1/memory_stores necesitan la beta de agent-memory y rechazan la combinación de ambas. Estas cabeceras permiten que el código escrito para una implementación alojada se ejecute aquí sin cambios.

La compatibilidad es amplia, pero no total. Consulte docs/api-matrix.md en el checkout antes de asumir que una superficie está disponible, porque el proyecto documenta allí sus propias limitaciones, incluidas las herramientas personalizadas del cliente, que todavía requieren un registro con nombre por encima del protocolo actual de resultados de eventos.

HTTP sin TLS también funciona y es la forma más rápida de comprobar que el runtime está activo:

curl -N -X POST http://127.0.0.1:3000/v1/sessions/SESSION_ID/messages \
  -H "Content-Type: application/json" \
  -d '{"content": "Hello", "stream": true}'

Una respuesta correcta es un flujo de eventos que sigue llegando. Si la conexión se interrumpe, reanude desde el último evento recibido en lugar de repetir todo el turno:

curl -N http://127.0.0.1:3000/v1/sessions/SESSION_ID/events/stream \
  -H "Last-Event-ID: EVENT_ID"

Este flujo reanudable permite que una sesión sobreviva al cierre del portátil. Los eventos se conservan en el servidor, por lo que el cliente reproduce un registro en lugar de mantener la única copia.

Dónde se almacenan en disco las credenciales, la memoria y los registros de auditoría

Todo lo que administra el runtime se encuentra en .managed-agents/ dentro del workspace.

.managed-agents/
├── config.yaml
├── data.db
├── logs/runtime.log
├── files/
├── skills/
├── snapshots/
└── sandbox/

• data.db contiene los metadatos de SQLite: agentes, sesiones, entradas del almacén de credenciales, entradas del almacén de memoria y claves de API.
• files/ contiene los bytes de los archivos subidos y skills/ contiene los paquetes de habilidades subidos.
• snapshots/ contiene las instantáneas del workspace de las sesiones, y sandbox/ contiene los directorios de trabajo de las sesiones en modo local.
• logs/runtime.log es el primer lugar que debe revisar cuando algo no hace nada de forma silenciosa.

Los almacenes de credenciales son grupos de secretos. Cada uno se añade con un auth_type, como environment_variable, y se asocia a una sesión mediante vault_ids cuando se crea la sesión. Los almacenes de memoria contienen entradas con nombre que se montan en una sesión como un memory_store, con su propia configuración de acceso e instrucciones. Ambos se encuentran en data.db. Esta es precisamente la diferencia frente a una llamada directa al modelo: el runtime conserva información entre sesiones y registra lo que ocurrió.

Como todo está en un solo directorio, haga una copia de seguridad del directorio completo.

sudo systemctl stop sandbase
sudo tar czf /root/sandbase-$(date +%F).tgz -C /opt/sandbase/workspace .managed-agents
sudo systemctl start sandbase

Detenga primero el servicio. Copiar una base de datos SQLite mientras el runtime escribe en ella puede generar un archivo que no se podrá abrir al restaurarlo. Puede descubrirlo justo el día que necesite la copia. Si prefiere mantener el YAML de los agentes en git y el estado en otra ubicación, la documentación de despliegue permite fijar la ubicación del estado mediante --data-dir en start.

La restauración se realiza en orden inverso: compruebe la misma etiqueta en un equipo nuevo, desempaquete el archivo en el workspace e inicie el servicio. La clave del proveedor no estará en el archivo si utilizó el formato ${OPENAI_API_KEY}, por lo que debe conservarla en un lugar al que todavía tenga acceso.

Ejecútelo con systemd

Asigne al entorno de ejecución un usuario propio para que una llamada a una herramienta en modo de sandbox local no pueda actuar como usted.

sudo adduser --system --group --no-create-home --home /opt/sandbase sandbase
sudo chown -R sandbase:sandbase /opt/sandbase

Guarde esto como /etc/systemd/system/sandbase.service.

[Unit]
Description=SandBase Harness runtime
After=network-online.target

[Service]
User=sandbase
Group=sandbase
WorkingDirectory=/opt/sandbase/workspace
EnvironmentFile=/etc/sandbase/runtime.env
ExecStart=/usr/bin/node /opt/sandbase/sandbase-harness/dist/index.js start --host 127.0.0.1 --port 3000
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

El ejemplo de despliegue del proyecto llama a un binario managed-agents en PATH. Una instalación desde el código fuente etiquetado no crea uno, por lo que ExecStart ejecuta node contra el punto de entrada compilado.

sudo systemctl daemon-reload
sudo systemctl enable --now sandbase
sudo systemctl status sandbase
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/dashboard

Un resultado correcto es active (running) de status y 200 de curl. Para cualquier otro resultado, lea primero journalctl -u sandbase -n 50 y después .managed-agents/logs/runtime.log. enable --now es la mitad importante, porque un proceso iniciado manualmente desaparece después del siguiente reinicio.

Qué falla y qué mensaje verá

npm run build termina con un error de memoria, sin ningún mensaje de npm. En un VPS de 1 GB, el kernel detiene la compilación de TypeScript mediante el terminador de procesos por falta de memoria. El kernel registra el evento en sus propios registros, no en npm. Confírmelo con journalctl -k | grep -i "out of memory", que muestra una línea con el nombre del proceso node terminado. Añada swap, o compile en una instancia más grande y copie dist/.

Error: listen EADDRINUSE: address already in use 127.0.0.1:3000. Otro proceso ya usa el puerto. sudo ss -lntp | grep 3000 muestra cuál es. Detenga ese proceso o inicie el runtime con --port 3001 y actualice el proxy.

El dashboard no carga desde su portátil. Es el comportamiento previsto, porque el runtime está enlazado a loopback. Use el túnel SSH anterior o termine de configurar el reverse proxy. No lo solucione con --host 0.0.0.0, porque la autenticación está desactivada hasta que exista una key.

Los sandboxes de Docker fallan con permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock. El usuario sandbase no pertenece al grupo docker. Corríjalo con sudo usermod -aG docker sandbase y reinicie el servicio. Tenga en cuenta lo que ha concedido: ese grupo equivale a root en el host, por lo que anula parte del motivo para asignar al runtime su propio usuario.

Los sandboxes de Kubernetes fallan con Error from server (Forbidden). Al ServiceAccount le faltan permisos sobre pods o sobre el subrecurso exec. Compruébelo directamente con kubectl auth can-i create pods/exec -n <namespace>, que responde yes o no.

Las solicitudes a la API devuelven 401 después de añadir una API key. La autenticación se activa cuando existe la primera key y cubre la API, pero no la consola: las páginas del dashboard y sus recursos estáticos siguen siendo públicos. Por eso la consola continúa cargando y después necesita la key para sus llamadas a la API. Envíe Authorization: Bearer <key> o x-api-key: <key>, pero no ambos, porque una solicitud que incluye ambas cabeceras se rechaza con 401 incluso cuando la autenticación está desactivada. Si ha perdido la key, cree otra, porque secret_key se devuelve una sola vez y sólo se almacena como hash.

Las herramientas de un servidor MCP nunca aparecen en una sesión. Compare el mcp_server_name del bloque tools con el name de mcp_servers. Después, compruebe que el runtime pueda acceder a la URL desde el propio servidor mediante curl -i <url>. Un servidor MCP de tipo URL es una dependencia de red. Un VPS resuelve nombres y encamina el tráfico de forma distinta que su portátil.

FAQ

¿Puedo ejecutar SandBase Harness sin una clave de OpenAI o Anthropic?

Sí, con una clave de MiniMax o un endpoint compatible con OpenAI. El runtime admite proveedores OpenAI, Anthropic, MiniMax y compatibles con OpenAI, por lo que funciona un servidor local que implemente la API de OpenAI. Configure el proveedor del workspace en .managed-agents/config.yaml y apunte api_key y el endpoint a él. El runtime no incluye ningún modelo propio, por lo que algún servicio debe responder a las llamadas.

¿Es seguro exponer el runtime en un puerto público?

No con la configuración instalada. Se enlaza a 127.0.0.1:3000 y arranca con la autenticación desactivada; la solución no es cambiar la dirección de enlace. Cree una API key o establezca MANAGED_AGENTS_API_KEY para activar la autenticación mediante bearer token en la API. Después, coloque nginx o Caddy delante para gestionar TLS y mantenga cerrado el puerto 3000 en el firewall, de modo que el único acceso pase por el proxy.

¿Cuál es la diferencia entre los sandboxes local, Docker y Kubernetes?

local ejecuta el código de las herramientas como un proceso hijo del runtime en el host, con los permisos del usuario del runtime y sin aislamiento. docker asigna a cada sesión su propio contenedor y sistema de archivos, y lo elimina cuando termina la sesión. También limita la memoria y la CPU sólo si el bloque resources del entorno define esos límites. kubernetes ejecuta la sesión como un pod y lo administra con kubectl exec, que necesita kubectl dentro de la imagen del runtime, además de RBAC sobre los pods y el subrecurso exec en el namespace de destino. Existe un cuarto backend, el worker autogestionado, que pone el trabajo en cola para un worker externo, de modo que el código se ejecuta fuera del host.

¿Qué debo incluir exactamente en la copia de seguridad?

El directorio .managed-agents/ del workspace. Contiene config.yaml, la base de datos SQLite data.db con los agentes, las sesiones, las entradas del almacén de credenciales y las entradas de memoria, además de los archivos subidos, los paquetes de skills y las instantáneas de las sesiones. Detenga el servicio antes de copiarlo para evitar que SQLite se escriba durante la creación del archivo. Las API keys de los proveedores referenciadas como ${OPENAI_API_KEY} no están dentro de la copia de seguridad, por lo que debe almacenarlas por separado.

¿Por qué clonar el tag v0.3.8 en lugar de main?

Un tag es un árbol fijo, por lo que las claves de configuración y los comandos de la CLI que se describen son los que realmente obtiene. main cambia, y una clave de configuración puede cambiar de nombre entre el momento en que se escribe una guía y el momento en que se ejecuta. El proyecto también advierte que el paquete managed-agents sin ámbito en npm no pertenece a este proyecto, por lo que npx managed-agents instala algo no relacionado. La versión v0.3.1 existe principalmente para sustituir ese inicio rápido de npm por el procedimiento basado en el código fuente etiquetado y fijado.