¿Qué es un harness de agentes?
Un harness de agentes es la capa que rodea a un modelo de lenguaje y convierte llamadas sueltas al modelo en un agente: ejecuta el bucle, ejecuta las herramientas que pide el modelo, gestiona la ventana de contexto y decide qué puede hacer el modelo.
Dónde están los límites
El término se define más fácilmente por descarte. Un agente de código en marcha tiene cuatro capas, y solo dos de ellas son el harness. Por debajo hay un modelo que no has entrenado y una API HTTP que no controlas; por encima, lo que sea que dibuja la salida en una pantalla. El harness es todo lo que queda en medio, es decir: todo lo que hay que decidir.
| Capa | Responsable | Qué decide |
|---|---|---|
| Pesos del modelo e inferencia | El proveedor | Anthropic, OpenAI, Google o un runtime en tu propio equipo. |
| Formato de transmisión | El proveedor | La forma HTTP propia de cada proveedor para mensajes, herramientas y streaming. |
| Bucle del agente | El harness | Llamar, leer la respuesta, ejecutar lo que pidió, volver a llamar y parar cuando termina. |
| Ejecución de herramientas | El harness | Validar argumentos, ejecutar la herramienta y decidir qué se ejecuta en paralelo. |
| Herramientas externas (MCP) | El harness | Descubrir servidores, dar espacio de nombres a sus herramientas y hablarles en JSON-RPC. |
| Contexto | El harness | Qué se queda en la ventana, qué se compacta y qué se recupera de antes. |
| Permisos | El harness | Qué puede hacer el agente sin preguntar y sobre qué debe preguntar primero. |
| Renderizado | La interfaz | Una terminal, un navegador, una ventana de escritorio o ninguna pantalla. |
Lee la tabla de arriba abajo y el motivo de que exista el término resulta evidente: las dos filas de arriba cambian cada pocos meses, la de abajo es cuestión de gustos, y las cinco del medio son donde viven de verdad todas las decisiones difíciles de un agente. Ponerle nombre a ese medio es lo que hace la palabra.
Por qué ser independiente del modelo es lo difícil
Casi todos los harness se escriben para un proveedor y se adaptan a otros después. Ese orden es el problema: las suposiciones del primer proveedor acaban en el almacén de conversaciones, en el esquema de herramientas, en cómo se interpreta una respuesta en streaming, sitios donde nadie piensa mirar más tarde. Cambiar implica entonces una migración, y una migración a mitad de sesión significa que no cambias.
La alternativa es guardar el historial en un formato que no pertenezca a ningún proveedor y renderizarlo al formato de transmisión del proveedor en el momento en que sale la solicitud. No se convierte nada al cambiar de modelo, porque nada tuvo nunca la forma del modelo anterior. Esa es la decisión de diseño en torno a la que está construido OHarness, y la página de arquitectura describe cómo se impone esa separación en capas, en lugar de quedarse en una intención.
Harness, framework, SDK
- Un SDK lleva una solicitud a un modelo y trae una respuesta. Una llamada, un proveedor, sin memoria de la anterior.
- Un framework te da piezas para montar un agente. Sigues decidiendo tú el bucle, los reintentos, la política de compactación, y después te toca mantenerlos.
- Un harness es la pieza ya montada. El bucle, la ejecución de herramientas, la gestión del contexto y los permisos ya están decididos; tú aportas herramientas, un modelo y una política.
La prueba práctica es qué pasa el día que quieres otro modelo. Con un SDK, reescribes la llamada. Con un framework, descubres cuántas de tus propias piezas daban por hecho el proveedor anterior. Con un harness pensado para ello, cambias un ajuste.
Preguntas frecuentes
¿Un harness de agentes es lo mismo que un framework de agentes?
Se solapan, y la distinción útil es qué tienes en las manos al final. Un framework te pide construir un agente con sus piezas: tú escribes el bucle, el grafo, los reintentos. Un harness es el bucle ya escrito: le das herramientas, un modelo y un conjunto de permisos, y funciona. Con la mayoría de los frameworks se puede construir un harness; un harness es lo que, si no, habrías construido tú.
Si un proveedor ya ofrece un SDK, ¿necesito un harness?
El SDK de un proveedor te lleva hasta la llamada al modelo y ahí se queda. No tiene opinión sobre cuándo volver a llamar, qué hacer con el resultado de una herramienta, qué descartar cuando se llena la ventana de contexto o si un comando de shell debe ejecutarse sin preguntar. Esas decisiones son el harness, y si no adoptas uno acabarás escribiéndolo, normalmente sin querer, repartido por todo el código y atado a un único proveedor.
¿Un mismo harness puede hablar con más de un proveedor de modelos?
Puede, pero solo si se diseñó así desde el principio. Lo difícil no es el HTTP: es que el historial de la conversación, las definiciones de herramientas y la salida en streaming tienen todos una forma marcada por el proveedor, y un harness que guarda el historial con la forma de un proveedor tiene que migrarlo para cambiar. Guardar el historial en una forma neutral y renderizarlo al formato de transmisión del proveedor en el momento de la solicitud es lo que hace que cambiar no cueste nada.
¿Existe un harness de agentes de código abierto?
Varios publican su código, entre ellos OpenCode, Cline y Gemini CLI. OHarness es gratis y sus paquetes npm se publican con licencia MIT, pero su repositorio de código es privado por ahora. Habla de forma nativa con Anthropic, OpenAI y Google Gemini, con cualquier endpoint compatible con OpenAI y con runtimes locales como Ollama, LM Studio y vLLM, y funciona en una terminal, un navegador, una aplicación de escritorio y en modo headless, todo con el mismo motor.
Prueba la implementación
OHarness es un harness de agentes independiente del modelo y gratuito: dos dependencias de runtime, todos los proveedores accesibles con fetch y SSE simples, y su propio cliente MCP. La documentación está escrita junto al código que describe, y la página de descarga tiene las versiones de escritorio y la línea de comandos.