Harnesses

Una sesión ejecuta un harness de agente, harness estándar o harness experimental. En esta página se explica cómo selecciona uno un proyecto y qué admite cada uno.

Un arnés es el entorno de ejecución del agente dentro del sandbox de una sesión. Ejecuta el bucle del modelo, llama a las herramientas y produce la transcripción. Beeuni tiene dos: harness estándar (el predeterminado) y harness experimental. Una sesión ejecuta exactamente uno.

Ambos arneses leen el mismo proyecto: beeuni.yaml, los archivos del agente en agents/, las habilidades en skills/, la raíz AGENTS.md y memory/. Los clientes (web, CLI, TUI, móvil y SDK) leen ambos mediante la misma API de sesión. Las diferencias son las funciones de sesión de la matriz siguiente y los archivos que cada arnés lee para su propia configuración.

Cómo selecciona una sesión su arnés

Beeuni decide cuándo se inicia, reinicia o reanuda una sesión. Una sesión en ejecución conserva su arnés hasta entonces.

Regla, en orden	Arnés
El indicador `llm_gateway` del proyecto está desactivado	harness estándar
El indicador `pi_harness` del proyecto está activado	harness experimental
`beeuni.yaml` establece `runtime: pi`	harness experimental
Cualquier otro caso	harness estándar

harness experimental llama a los modelos únicamente mediante la puerta de enlace LLM de Beeuni. Un proyecto con llm_gateway desactivado inicia harness estándar, independientemente de lo que indiquen el indicador o el manifiesto. Consulta Modelos.
runtime es una clave de manifiesto de beeuni_version: 2. Un proyecto heredado beeuni.toml no puede establecerla. Consulta la referencia del manifiesto.
pi_harness es un indicador de funciones por proyecto, desactivado de forma predeterminada. Consulta Indicadores de funciones.

Para ver qué arnés ejecuta una sesión, lee harness.id en la respuesta GET /beeuni/health del demonio del sandbox: opencode o pi.

Qué admite cada arnés

Un arnés enumera las funciones de sesión opcionales que ofrece en el arreglo capabilities de GET /beeuni/health. Un cliente oculta un control cuando capabilities de la sesión no contiene el identificador. La comprobación del SDK es runtimeSupports.

Ambos arneses

Función	harness estándar	harness experimental
Turnos de chat, streaming y detención	Sí	Sí
`.md` del agente: prompt, `model`, `variant`, `mode`, `permission`, `temperature`, `top_p`, `steps`	Sí	Sí. harness experimental no aplica `options` (opciones del proveedor).
Acceso a herramientas por agente (`agents.<name>.tools` en `beeuni.yaml`: `all`, `none`, una lista, `exclude`)	Sí	Sí
Reglas `permission` y solicitudes de permisos por agente	Sí	Sí
Preguntas (herramienta `question`)	Sí	Sí
Archivo de reglas `AGENTS.md` de la raíz del proyecto, o `CLAUDE.md` cuando la raíz no tiene `AGENTS.md`	Sí. harness estándar también lee el archivo de los directorios principales de `/workspace` y lee `/workspace` mientras ejecuta una versión de configuración.	Sí, solo el archivo raíz. Forma parte del prompt del sistema de la sesión y de cada subagente. Con las versiones de configuración activadas, harness experimental lee la copia de la versión.
Subagentes (herramienta `task`), `session.subagents`	Sí	Sí: `general`, `explore` (solo lectura) y cada agente del proyecto con `mode: subagent` o `all`. Un subagente no puede iniciar otro subagente.
Habilidades (`skills/` y las habilidades `beeuni-*` administradas), con la concesión `skills` del agente	Sí. El agente carga una habilidad con la herramienta `skill`.	Sí. El prompt del sistema enumera cada habilidad concedida; el agente lee el archivo.
Herramientas de Beeuni: `web_search`, `image_search`, `scrape_webpage`, `memory`, `show`. Las cinco cuando no hay una clave `tools:` en `beeuni.yaml`; cuando existe, las que enumera como `beeuni:<name>`	Sí	Sí
Herramientas del proyecto (`tools:` en `beeuni.yaml`)	Sí	Sí
Versiones de configuración, `config.release.v1`	Sí	Sí
Compactar (resumir) la conversación, a petición y automáticamente cerca del límite de contexto del modelo, `session.compact`	Sí	Sí. Una solicitud al modelo que desborda la ventana compacta y se reintenta una vez.
Comandos slash del proyecto, `session.commands`	Sí, desde `commands/` en el directorio de configuración de harness estándar.	Sí, desde las plantillas de prompt en `prompts/`, en el directorio de configuración de harness experimental y en los paquetes de harness experimental. harness experimental no lee `commands/` de harness estándar.
Terminal en el sandbox (PTY)	Sí	Sí
Herramientas `bash`, `read`, `write`, `edit`, `glob` y `grep`; secretos en el shell; la CLI `beeuni`	Sí	Sí

Las herramientas de Beeuni y del proyecto son neutrales respecto al arnés: el demonio del sandbox ejecuta un módulo por herramienta para ambos arneses, con los mismos nombres, argumentos y resultados. harness experimental las llama en el proceso del demonio; harness estándar las llama mediante un complemento que el demonio escribe. Ambos arneses reciben la misma lista: una herramienta de Beeuni que la clave tools: del proyecto no enumera no está disponible para ninguno. Un proyecto que aún conserve copias de las herramientas de Beeuni en harnesses/opencode/tools/ mantiene sus copias en harness estándar hasta que las elimine.

Las herramientas web siguen las claves de permisos websearch (web_search, image_search) y webfetch (scrape_webpage) en ambos arneses. En harness estándar, estas herramientas no pueden preguntar: una regla ask las deniega. En harness experimental, una regla ask genera una solicitud de permiso. En harness experimental, un comando memory que cambia un archivo sigue edit y view sigue read; en harness estándar, solo una regla memory controla la herramienta.

`AGENTS.md` en harness experimental

harness experimental coloca la raíz AGENTS.md del proyecto en el prompt del sistema como una sección, <project_instructions path="AGENTS.md">, después del prompt del agente. Una raíz sin AGENTS.md proporciona CLAUDE.md, igual que en harness estándar. harness experimental no lee AGENTS.md en un subdirectorio ni en un directorio principal.

Origen. Con las versiones de configuración desactivadas, harness experimental lee /workspace/AGENTS.md. Con ellas activadas, harness experimental lee la copia de la versión y nunca la de /workspace: una edición en /workspace llega a la sesión después de fusionarse con la rama base. Si están activadas y no hay ninguna versión que servir (config.source: image-default), harness experimental no lee AGENTS.md, al igual que no lee ninguna habilidad del proyecto.
Cuándo. harness experimental lee el archivo cuando se inicia el entorno de ejecución, cuando se vuelve a cargar su configuración (una nueva versión, un push de /beeuni/env) y después de actualizar un repositorio. No lo lee antes de cada turno. Una nueva versión llega al siguiente turno sin reiniciar; un turno en curso conserva el archivo anterior.
Omitidos. Un archivo vacío, un archivo que no sea normal y un enlace simbólico que resuelva fuera del repositorio no añaden nada. Los dos últimos escriben una advertencia en el registro del demonio.
Comprobación. harness.details.agentsMd en GET /beeuni/health del demonio indica el archivo que harness experimental cargó: source (release o workspace), path, bytes y sha (los primeros 12 caracteres hexadecimales de su sha256). Es null cuando harness experimental no cargó ninguno.

Solo harness estándar por ahora

Función	Capacidad	harness estándar	harness experimental
Retroceder a un mensaje y restaurarlo. Editar y reenviar usa el retroceso.	`session.rewind`	Sí	No
Servidores MCP (`mcp` en `opencode.jsonc`)	`session.mcp`	Sí	No hay cliente MCP. Los conectores funcionan en ambos arneses mediante la CLI `beeuni connectors`.
Lista de tareas (herramienta `todowrite`) y tarjeta del plan	`session.todo`	Sí	No. La tarjeta del plan permanece vacía.
Conectar el cliente de terminal propio del arnés (`beeuni connect`, TUI `Alt+o`)	`session.attach`	Sí	No. Consulta TUI.
Documento de configuración del entorno de ejecución (`/global/config`)	`session.config`	Sí	No. Los agentes y modelos provienen del proyecto en ambos casos.
Bifurcar una sesión en un mensaje	`session.fork`	Sí	No
Ejecutar un comando de shell como turno	`session.shell`	Sí	No
Proveedores de modelos sin la puerta de enlace LLM	—	Sí	No. harness experimental necesita `llm_gateway` activado.

Una sesión de harness experimental responde a una solicitud de una función que no ofrece con 501 feature_not_supported, o con 404 si se trata de un documento que no tiene (/global/config). No ignora la solicitud.

Archivos de configuración del arnés

Cada arnés tiene un directorio para los archivos que solo lee ese arnés.

	harness estándar	harness experimental
Directorio	`harnesses/opencode/` o `opencode.config_dir`	`harnesses/pi/` o `pi.config_dir`
Directorio heredado	`.beeuni/opencode/`	`.beeuni/pi/`
Contenido	`opencode.jsonc`, `plugins/`, `tools/`, `commands/`	`settings.json`, `extensions/`, `skills/`, `prompts/`
Extensiones	Complementos y herramientas exclusivas de harness estándar en ese directorio	Paquetes de harness experimental en `harnesses.pi.packages` y archivos de extensión en `extensions/`

Una sesión de harness experimental no lee opencode.jsonc, plugins/, tools/ ni commands/. Una sesión de harness estándar no lee el directorio de harness experimental. Una herramienta que necesitan ambos arneses es una herramienta del proyecto, declarada en beeuni.yaml, no un archivo de ninguno de los dos directorios.

Los paquetes de harness experimental provienen de packages. Un paquete puede añadir herramientas que harness experimental no tiene, por ejemplo, un adaptador MCP o una herramienta de tareas. Beeuni carga el paquete; no prueba los paquetes de terceros.