Mejores harnesses de agentes de código integrables en 2026

Vercel AI SDK es la mejor opción global porque AI SDK 7 sitúa nueve runtimes de código compatibles detrás de una única superficie orientada al producto. Esto puede transformar un cambio de runtime futuro de una reescritura de interfaz a una simple decisión de adaptador, siempre que estés dispuesto a gestionar el sandbox y aceptar una frontera de paquetes experimental.

La respuesta corta

Un harness de agentes de código integrable es la capa de control a la que llama tu aplicación. Gestiona alguna combinación del bucle del agente, herramientas, permisos, sesiones, compresión de contexto, acceso al modelo y entorno de ejecución. Es una decisión de compra distinta a elegir un agente de código que utilizas directamente en un terminal o editor. Si ese es el producto que buscas, empieza con la comparativa más amplia sobre los mejores agentes de IA para programar.

Para un producto nuevo en TypeScript, Vercel AI SDK HarnessAgent es la mejor opción general. Proporciona a la aplicación anfitriona una interfaz unificada entre Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode y Pi. Su valor no reside en que todos los runtimes se vuelvan idénticos, sino en evitar que el streaming, el ciclo de vida de las sesiones, la integración con la UI y el aprovisionamiento de sandboxes contaminen cada funcionalidad del producto; las capacidades específicas de cada adaptador siguen variando.

El resto de la clasificación depende de qué parte del stack desees controlar:

1. Vercel AI SDK HarnessAgent: mejor capa de portabilidad global
2. Claude Agent SDK: mejor runtime completo de proveedor
3. OpenAI Codex SDK: mejor para automatización nativa en Codex
4. Cursor SDK: mejor runtime de proveedor unificado para local y nube
5. OpenHands Software Agent SDK: mejor stack remoto de código abierto
6. OpenCode SDK: mejor superficie cliente/servidor tipada
7. Pi: mejor núcleo mínimo para agentes
8. fx y libfx: mejor opción experimental nativa y para navegadores

La regla de decisión es directa: si poder cambiar el runtime de código en el futuro aporta valor estratégico, elige Vercel. Si la ventaja de tu producto reside en el bucle integrado de un proveedor concreto, utiliza Claude o Codex directamente. Elige Cursor cuando un único SDK deba abarcar tanto agentes locales como agentes en la nube alojados por Cursor. Si necesitas un servicio remoto abierto, opta por OpenHands u OpenCode. Si buscas ensamblar el bucle más pequeño posible, elige Pi. Emplea fx cuando el tamaño del binario nativo o WebAssembly en el navegador sea el experimento en sí mismo, no cuando una fecha de entrega en producción exija un límite de seguridad plenamente consolidado.

Resumen comparativo de agentes de código integrables

Los precios y capacidades se verificaron el 1 de septiembre de 2026. El "Precio inicial" describe primero el SDK o el paquete open source. Los tokens de los modelos, el cómputo, el almacenamiento y las tarifas de red van por separado, ya que dichos costes varían según la arquitectura desplegada.

Cómo se desglosa la factura

La licencia del SDK rara vez representa el gasto principal en el presupuesto. Lo decisivo son los tokens de salida del modelo, los contextos extensos, el tiempo de vida del sandbox, los reintentos y la revisión humana. Un paquete gratuito puede ejecutar un agente costoso, mientras que un plan de hosting de pago puede resultar más económico si elimina suficiente carga operativa.

Usemos una carga de trabajo habitual para ver el orden de magnitud. Asume que cada ejecución consume 20,000 tokens de entrada y 5,000 tokens de salida, se ejecuta 100 veces por día laboral y opera durante 22 días laborales. Eso equivale a 2,200 ejecuciones al mes. Es un marco de análisis, no un benchmark comparativo, y excluye deliberadamente el almacenamiento en caché para mantener la transparencia en los supuestos.

Con los precios actuales de la API de Claude Sonnet 5 de $2 por millón de tokens de entrada y $10 por millón de tokens de salida, el coste del modelo es:

• Entrada: 20,000 / 1,000,000 x $2 = $0.04 por ejecución
• Salida: 5,000 / 1,000,000 x $10 = $0.05 por ejecución
• Total: $0.09 por ejecución, o $198 al mes para 2,200 ejecuciones

Con el precio promocional actual de GPT-5.6 Sol de $4 por millón de tokens de entrada y $20 por millón de tokens de salida, ese mismo escenario supone $0.18 por ejecución, o $396 al mes. Esto no sugiere que ambos modelos produzcan un trabajo idéntico, sino que demuestra por qué el modelo seleccionado y la tendencia del agente a reintentar influyen más que la licencia del software.

Añadamos ahora un ejemplo con los precios de Vercel Sandbox. Un sandbox de 1 GB aprovisionado durante 10 minutos con 2 minutos de CPU activa cuesta unos $0.0078 por ejecución con las tarifas vigentes de $0.128 por hora de CPU activa y $0.0212 por GB-hora aprovisionado. En 2,200 ejecuciones, esto representa unos $17.16 de consumo bruto de CPU y memoria, antes de calcular transferencia de datos y almacenamiento. Vercel Pro cuesta $20 al mes e incluye $20 de crédito de uso, por lo que este perfil de cómputo específico queda cubierto por dicho saldo; 2,200 creaciones añaden unos $0.00132 a la tarifa listada de $0.60 por millón. El plan Hobby incluye 5,000 creaciones, pero es para uso personal no comercial y no permite adquirir consumo adicional.

Criterios de selección

El requisito para ser incluido fue ofrecer control programático desde una aplicación anfitriona a través de un SDK documentado, librería, protocolo o API de servidor. Un comando de terminal aislado no fue suficiente. Un plugin para editor no bastó. Un framework de benchmarking o una colección de prompts no calificaron a menos que ofrecieran una interfaz de integración de producto con soporte formal.

Esto redujo un catálogo amplio a ocho opciones seleccionadas. Las listas extensas suelen mezclar SDKs oficiales de runtimes con colecciones de skills, frameworks de investigación y aplicaciones de usuario final. Evaluar a fondo ocho opciones resulta más práctico que un inventario difuso, ya que el límite operativo es donde estas tecnologías realmente divergen.

Cada opción evaluada se analizó bajo cinco criterios:

• Contrato de integración: qué puede llamar, transmitir en streaming, reanudar y detener la aplicación
• Límite de ejecución: si el código corre en el mismo proceso, como subproceso, detrás de un servidor o en un sandbox
• Propiedad del estado: quién almacena transcripciones, archivos de trabajo, credenciales y datos de reanudación
• Control de políticas: dónde residen los permisos, la admisión de herramientas, el aislamiento multi-inquilino y las reglas de red
• Coste de salida: cuánto código de producto sobrevive a un cambio de modelo o de runtime

No se afirman pruebas manuales del producto. Las clasificaciones se derivan de la documentación oficial actual, precios vigentes, límites de seguridad descritos y el modelo de costes expuesto anteriormente. Este método prioriza un contrato estable sobre una demostración llamativa, ya que una decisión de integración dura mucho más que un vídeo de lanzamiento.

1. Vercel AI SDK HarnessAgent: mejor capa de portabilidad global

Vercel AI SDK HarnessAgent es la mejor opción global para un producto en TypeScript que busca una única superficie operativa frente a múltiples runtimes de programación. AI SDK 7 incluye soporte para Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode y Pi, mientras que el paquete subyacente normaliza sesiones, streaming, permisos, skills, compactación y aprovisionamiento de sandboxes. Un caso claro de uso es un producto de revisión de código que comienza con Claude Code pero desea evaluar Codex más adelante sin tener que rehacer su interfaz de chat ni el ciclo de vida de los procesos. El obstáculo es su madurez: @ai-sdk/harness sigue siendo formalmente experimental, y la mayoría de los adaptadores basados en puente requieren un sandbox de red con puertos expuestos.

Ideal para: Equipos de TypeScript que consideran la portabilidad de runtimes como un seguro de producto
Destacado: Generación y streaming compatibles con AI SDK a través de múltiples runtimes de código
Precios: El paquete Apache-2.0 es open source. Vercel Hobby y Pro cuestan $0 y $20 al mes respectivamente; Pro incluye $20 de crédito de uso y prueba gratuita, mientras que Enterprise es a medida. El uso de Vercel Sandbox comienza en $0.128 por hora de CPU activa y $0.0212 por GB-hora aprovisionado.
Prueba gratuita: Vercel ofrece una prueba Pro gratuita; la librería en sí es de código abierto

El motivo principal para elegir Vercel no es la comodidad, sino la capacidad de maniobra. Si tus prompts, el estado de la UI, los esquemas de salida, los registros de trabajos y los eventos de evaluación se sitúan por encima del adaptador, sustituir el runtime seguirá requiriendo esfuerzo, pero no supondrá reescribir todo el producto. Esto es fundamental cuando un proveedor modifica sus políticas de autenticación, un modelo encarece sus tarifas o un bucle distinto ofrece mejores resultados en tus repositorios.

La abstracción también tiene sus límites prácticos. Los adaptadores basados en puente como Claude Code, Cline, Codex, Cursor, Deep Agents, fx, OpenCode y Pi precisan hoy una sesión en un sandbox de red; Grok Build utiliza un proceso anfitrión. Esto significa que "portable" no equivale a "desplegable en cualquier entorno sin ajustes": significa que el contrato de la aplicación permanece estable mientras que la configuración operativa sigue dependiendo del adaptador.

Desde el 31 de agosto de 2026, el adaptador oficial de Vercel @ai-sdk/harness-fx incorpora fx como el noveno harness compatible, empleando ACP entre HarnessAgent y fx. El adaptador respeta la interfaz común, aunque fx no admite salidas estructuradas, compactación manual, intervención en medio del turno (mid-turn steering) ni filtrado integrado de herramientas a través de esta capa. Los compromisos detallados se analizan en la explicación sobre el adaptador fx para Vercel AI SDK.

El paquete @ai-sdk/harness alcanza actualmente la versión 1.0.96. El avance rápido en las versiones dentro de un entorno experimental exige disciplina: fija las versiones en tu gestor de paquetes, ejecuta pruebas de contrato antes de actualizar y almacena los eventos en bruto del runtime para poder reproducirlos.

1. 1

   Define primero el contrato de producto

   Establece los datos de entrada, el alcance permitido en el repositorio, la salida JSON requerida, las reglas de cancelación y el presupuesto máximo sin mencionar ningún runtime específico. Una buena primera tarea es la corrección acotada de una prueba fallida que deba devolver los archivos modificados, el estado del test y una breve nota de riesgos.

2. 2

   Comienza con un solo adaptador

   Instala AI SDK 7 en un servicio Node.js 22 con ESM, elige un adaptador de runtime y asigna un directorio de trabajo aislado a cada sesión. No desarrolles aún un selector de runtimes en la interfaz.

3. 3

   Asegura el aislamiento formal

   Para un adaptador con puente, aprovisiona un sandbox de red, configura el directorio de trabajo, instala exclusivamente las dependencias reproducibles y gestiona el cierre o destrucción de la sesión mediante el ciclo de vida oficial. Mantén las credenciales fuera del espacio de trabajo del agente.

4. 4

   Registra las cuatro métricas clave

   En cada ejecución, guarda la tasa de finalización, las denegaciones de permisos, el consumo de tokens y el tiempo transcurrido. Estos valores indicarán si cambiar de adaptador ahorra dinero o si simplemente traslada los fallos de sitio.

5. 5

   Reproduce las pruebas con un segundo runtime

   Añade un segundo adaptador bajo el mismo contrato de producto y ejecuta de nuevo las mismas tareas sobre el repositorio. Conserva el primer runtime hasta que el segundo demuestre superioridad en tu propia carga de trabajo, no en un benchmark general.

2. Claude Agent SDK: mejor runtime completo de proveedor

Claude Agent SDK es la opción directa más sólida cuando el bucle completo de Claude Code constituye la funcionalidad principal y no un detalle de implementación. Proporciona el mismo bucle de agente, gestión de contexto, herramientas de archivos, ejecución de comandos, búsqueda web, MCP y controles de permisos en Python y TypeScript. Un servicio de auditoría de seguridad que requiera políticas estrictas de permisos y sesiones prolongadas en repositorios encontrará aquí un comportamiento más maduro que en un núcleo mínimo. El peaje por esta completitud es el acoplamiento con el proveedor y un modelo de aislamiento de procesos que el anfitrión debe gestionar meticulosamente.

Ideal para: Productos cuya diferenciación depende del bucle y las herramientas nativas de Claude Code
Destacado: El mismo bucle de agente y gestión de contexto que Claude Code, programable en Python y TypeScript
Precios: Basado en consumo. Las tarifas actuales de la API de Claude son Fable 5 a $10/$50, Opus 5 a $5/$25, Sonnet 5 a $2/$10 y Haiku 4.5 a $1/$5 por millón de tokens de entrada/salida.
Prueba gratuita: No se lista una prueba independiente para el Agent SDK

Claude representa la mejor elección si buscas reducir el ensamblaje de componentes. El sistema anfitrión recibe un bucle de programación consolidado en lugar de tener que construir desde cero el encadenamiento de herramientas, la presión de contexto y las solicitudes de permisos. Esto disminuye el volumen de código propio, aunque supedita el comportamiento a las actualizaciones del proveedor.

Llevarlo a producción requiere dimensionar bien los procesos. Anthropic recomienda 1 GiB de RAM, 5 GiB de disco y 1 CPU por agente como punto de partida base, no como límite superior. Dado que cada sesión utiliza un subproceso propio, un contenedor que atienda múltiples sesiones simultáneas necesita límites de memoria por sesión y control de admisión bien configurados, en lugar de confiar ciegamente en el escalado automático.

La persistencia presenta otro límite a considerar. SessionStore replica las transcripciones en S3, Redis, Postgres o mediante un adaptador personalizado, pero no sincroniza los archivos de memoria CLAUDE.md ni el contenido del directorio de trabajo. Si la replicación falla, emite un mirror_error y permite que la consulta continúe. Si tu usuario final espera poder reanudar tareas, alertar sobre este evento y sincronizar por separado los archivos del espacio de trabajo resultará indispensable.

El aislamiento entre inquilinos también exige ajustes específicos. De lo contrario, un proceso compartido podría leer la configuración del sistema de archivos y la memoria de una sesión ajena. El patrón de arquitectura recomendado emplea un directorio de configuración y un espacio de trabajo independientes por inquilino, deshabilita la memoria automática, limpia las fuentes de configuración del sistema de archivos y aplica reglas de tráfico de red externas al agente.

3. OpenAI Codex SDK: mejor para automatización nativa en Codex

OpenAI Codex SDK es la alternativa directa más limpia para interactuar con hilos de Codex, monitorizar el progreso en streaming y ejecutar operaciones sobre repositorios con restricciones de esquema. El paquete oficial para TypeScript interactúa con la CLI de Codex e intercambia mensajes en JSONL a través de la entrada y salida estándar. Encaja a la perfección en un bot de despliegue que deba generar un objeto JSON estricto con los archivos modificados, el resultado de los tests y una nota de versión. Su restricción proviene de la arquitectura: el SDK instancia un subproceso con la CLI y la política de espacio de trabajo por defecto exige un repositorio Git.

Ideal para: Productos ya comprometidos con Codex y la autenticación de OpenAI
Destacado: Hilos persistentes con streaming de eventos estructurados y salida basada en JSON Schema
Precios: El SDK tiene licencia Apache-2.0. El precio de la API de GPT-5.6 Sol se encuentra actualmente en promoción a $4 por millón de tokens de entrada y $20 por millón de tokens de salida.
Prueba gratuita: No aplica al SDK open source; el acceso al modelo o la suscripción se facturan aparte

Codex figura por detrás de Claude en esta comparativa únicamente porque aquí se valora una infraestructura de ejecución integrada más amplia. Sin embargo, para un producto enfocado en lanzar tareas específicas sobre Codex, puede ser la mejor opción. Su API ofrece los elementos necesarios: los hilos preservan el estado conversacional, runStreamed() expone el avance en tiempo real y los esquemas de salida permiten validar las respuestas de forma programática sin procesar texto libre.

La arquitectura basada en subprocesos tiene sus ventajas: el protocolo JSONL sobre stdin y stdout facilita la depuración, es agnóstico respecto al lenguaje en el límite del sistema y aísla al SDK de los cambios internos de la CLI. No obstante, implica que el tiempo de inicialización, la disponibilidad de la CLI, el control de la salida estándar y la detención de procesos deben contemplarse en las operaciones de producción para evitar subprocesos huérfanos.

En TypeScript, el estado del hilo se guarda por defecto en ~/.codex/sessions. Esta ruta local es práctica durante el desarrollo, pero resulta insuficiente como única estrategia de persistencia en contenedores efímeros. Asocia los identificadores de hilos a los registros de tu aplicación, configura la ruta base de Codex y transfiere el estado a un almacenamiento persistente antes de destruir la instancia.

Si lo que buscas es decidir cómo interactúan los desarrolladores humanos con Codex frente a Claude Code o Cursor, consulta la comparativa entre Codex, Claude Code y Cursor. La decisión en este punto es más concreta: si tu propia aplicación debe crear y supervisar hilos de Codex mediante código.

4. Cursor SDK: mejor runtime de proveedor unificado para local y nube

Cursor SDK ya constituye un contrato de integración completo y no solo un conector para su editor. Sus SDKs para TypeScript y Python permiten controlar el mismo agente bajo dos modalidades de ejecución: los agentes locales se ejecutan junto a la aplicación anfitriona, mientras que los agentes en la nube funcionan dentro de máquinas virtuales aisladas gestionadas por Cursor. Una aplicación puede iniciar un agente en la nube con soporte de estado persistente, recibir sus eventos en streaming y cancelar ejecuciones, o bien utilizar la vía local cuando el código deba permanecer estrictamente en la máquina del desarrollador. Su limitación reside en el ecosistema: ambos modos dependen del runtime de Cursor, y las llamadas a herramientas locales exigen hooks específicos o políticas de sandbox antes de exponerse en un entorno de producción.

Ideal para: Equipos que requieren un único SDK del proveedor para ejecución local y gestionada en la nube
Destacado: Misma interfaz de agente orientada a un proceso local o a un agente persistente alojado por Cursor
Precios: El consumo del SDK depende de los planes y grupos de solicitudes de Cursor. Hobby es gratuito con peticiones de Agent limitadas; Pro cuesta $20 al mes; Teams cuesta $40 por usuario al mes; Enterprise es personalizado.
Prueba gratuita: El nivel Hobby está accesible sin contratar un plan de pago

Cursor se sitúa por detrás de los SDKs directos de Codex y Claude porque su fuerte es la versatilidad de despliegue y no la neutralidad del proveedor. Resulta idóneo para una plataforma de desarrollo que quiera brindar la misma experiencia en local que en una infraestructura cloud administrada. Por el contrario, pierde atractivo si el auto-alojamiento, el control a nivel de código fuente o un contrato desacoplado del proveedor forman parte de los requisitos del proyecto.

5. OpenHands Software Agent SDK: mejor stack remoto de código abierto

OpenHands Software Agent SDK es la mejor alternativa open source cuando requieres tanto una API para agentes como una infraestructura de ejecución remota lista para desplegar. Sus interfaces en Python y REST contemplan entornos locales, Docker y Kubernetes, mientras que el Agent Server transmite los eventos vía WebSocket. Esto permite que una plataforma corporativa mantenga los espacios de trabajo en su propia infraestructura segura y ofrezca, a la vez, un endpoint compatible con OpenAI a sus aplicaciones internas. La contrapartida es su envergadura: cliente, servidor de agentes, aislamiento de espacios de trabajo, enrutamiento de modelos y persistencia se convierten en sistemas bajo tu directa administración.

Ideal para: Equipos de Python que precisan un servicio de agentes de código abierto y auto-alojado
Destacado: Idéntica API de conversación para entornos de trabajo locales, en Docker y remotos
Precios: Gratuito con licencia MIT; los costes de modelos, contenedores, red y almacenamiento son independientes
Prueba gratuita: No aplica; el SDK es gratuito y de código abierto

OpenHands destaca cuando "auto-alojado" implica algo más que instalar una librería en local. Su arquitectura remota se estructura en tres capas claras: un cliente Python, un Agent Server accesible mediante HTTP y WebSocket, y un espacio de trabajo aislado. Migrar de una ejecución local a Docker o a una API remota solo requiere modificar el objeto del entorno de trabajo sin tocar la lógica de la conversación.

Esta disposición resulta muy práctica para múltiples clientes. Un navegador web, un IDE, un bot de soporte o cualquier cliente compatible con OpenAI pueden interactuar con el endpoint sin necesidad de importar librerías de Python. Esto permite centralizar autenticación, control de consumo, registros de auditoría y residencia de datos en el perímetro del servicio, siendo la base abierta más completa de la lista para una plataforma interna.

No obstante, esta robustez requiere dedicación técnica. Será necesario actualizar imágenes de contenedores, delimitar recursos por tarea, rotar credenciales, vigilar conexiones WebSocket y definir políticas de retención para los repositorios. La licencia MIT resuelve los derechos de uso del software, pero no asume el coste total de propiedad.

Frente a Vercel, la diferencia reside en el grado de gestión de la infraestructura. Vercel proporciona una capa de control en TypeScript y sandboxes administrados. OpenHands ofrece acceso al código fuente y libertad de despliegue, a cambio de mantener más infraestructura propia. Si el cumplimiento normativo o la independencia de modelos son imperativos legales, el esfuerzo estará justificado; si solo buscas incorporar una función en una app el próximo mes, puede añadir demasiada complejidad.

6. OpenCode SDK: mejor superficie cliente/servidor tipada

OpenCode SDK es la opción independiente más adecuada para aplicaciones en JavaScript o TypeScript que buscan un cliente fuertemente tipado para interactuar con un servidor OpenCode específico. La función createOpencode() arranca ambos componentes, mientras que createOpencodeClient() se enlaza a un servidor ya existente. Esto permite que una herramienta de escritorio o un portal interno creen sesiones, reciban eventos por streaming, gestionen permisos, ejecuten comandos, analicen archivos y obtengan respuestas estructuradas a través de tipos generados. Su contrapartida va ligada a su diseño: al basarse en un modelo cliente/servidor, el ciclo de vida del servidor, la apertura de puertos, el aislamiento y la autenticación recaen en el desarrollador.

Ideal para: Aplicaciones en JavaScript y TypeScript que requieren un servidor de agentes explícito y tipado
Destacado: Tipos generados a partir de OpenAPI para sesiones, archivos, comandos, permisos y eventos
Precios: Gratuito con licencia MIT; modelos e infraestructura de servidores por separado
Prueba gratuita: No aplica; el SDK es gratuito y de código abierto

La configuración local por defecto es muy directa: 127.0.0.1, puerto 4096 y un tiempo límite de arranque de 5,000 ms. Estos valores son útiles en aplicaciones Electron, automatizaciones locales o herramientas para desarrolladores, pero no deben trasladarse tal cual a producción. Un servidor accesible por distintos usuarios o procesos requiere autenticación previa, políticas de aislamiento por tarea y restricciones claras sobre los comandos de shell y rutas de archivos permitidos.

La principal ventaja de OpenCode en un producto es su transparencia e inspección. Métodos como la creación de sesiones, envío de prompts, cancelación, compartición, resúmenes, ejecución de comandos en shell, respuestas a permisos, operaciones de archivos, configuración y suscripción a eventos son directamente accesibles. Esto simplifica construir paneles de monitorización frente a librerías cuya única interfaz es enviar un texto y esperar la respuesta.

Al compararlo con OpenHands, la diferencia radica en el lenguaje y el enfoque. OpenCode proporciona un cliente muy estructurado en JS/TS para su servidor, mientras que OpenHands ofrece un SDK centrado en Python con un modelo más maduro para la orquestación de espacios de trabajo remotos. Escoge OpenCode si tu stack se apoya en TypeScript y el servidor de OpenCode cubre tus necesidades. Decántate por OpenHands si priorizas una plataforma abierta para agentes con independencia de entornos sobre un cliente nativo en TypeScript.

7. Pi: mejor núcleo mínimo para agentes

Pi es la mejor opción cuando lo que tu producto demanda es un bucle de ejecución compacto más que una plataforma de programación prefabricada. El paquete @earendil-works/pi-agent-core se encarga del estado, ejecución de herramientas, streaming de eventos, alternancia de modelos, intervención en turnos, colas de seguimiento y eventos de herramientas; el proyecto general ofrece además un SDK para Node.js y un canal RPC mediante JSONL. Un servicio especializado en migración de código puede definir únicamente las herramientas y eventos que utiliza, evitando la sobrecarga de un agente de terminal integral. El límite está en la integración: la persistencia, las herramientas de desarrollo, el aislamiento y las políticas operativas correrán por tu cuenta.

Ideal para: Equipos que prefieren diseñar el bucle del agente y la política de herramientas desde la base
Destacado: Núcleo con gestión de estado, streaming de eventos y control de herramientas, sin imponer un servidor
Precios: Gratuito y con licencia MIT; modelos, almacenamiento y computación independientes
Prueba gratuita: No aplica; Pi es gratuito y de código abierto

El atractivo de Pi radica en su contención: no impone decisiones innecesarias. Su núcleo es capaz de emitir mensajes del modelo, ejecutar herramientas, admitir interrupciones, gestionar turnos adicionales, modificar el contexto antes de llamar al modelo y detenerse al concluir el turno. Proporciona lo suficiente para diseñar un flujo adaptado a tus necesidades sin tener que gestionar llamadas directas y desestructuradas a la API del LLM.

Esa ligereza define también el tipo de integración. La persistencia a largo plazo y las pautas de sandbox no forman parte del núcleo; las herramientas las define la aplicación que lo invoca. Un equipo puede mantener su runtime reducido y altamente portable, pero cada aspecto omitido requerirá una definición técnica propia.

Esto convierte a Pi en una excelente pieza para construir agentes especializados. Si tu servicio únicamente analiza dependencias en un manifiesto, actualiza versiones en archivos de configuración, ejecuta un comando de test y genera un reporte firmado, disponer de cuatro herramientas estrictas y un adaptador de persistencia simple resultará más seguro que operar un runtime generalista sobredimensionado. Por el contrario, este minimalismo es menos adecuado para una herramienta similar a un IDE que requiera sesiones complejas, permisos avanzados, terminales interactivos y paneles de control desde el primer día.

Pi también cuenta con un adaptador oficial dentro del ecosistema de Vercel. Si tu equipo busca el bucle de Pi hoy pero quiere reservarse la opción de contrastarlo con otros runtimes más adelante, Vercel puede actuar como el contrato de cara al producto. Si el objetivo es usar Pi precisamente para prescindir de capas intermedias, integrar su núcleo directamente es el camino lógico.

8. fx y libfx: mejor opción experimental nativa y para navegadores

fx y libfx representan la alternativa experimental más interesante si buscas un binario nativo ligero, integración con ACP, uso embebido en Node, ejecución del bucle dentro de un navegador moderno o el despliegue de fx a través de Vercel HarnessAgent. El sitio oficial de fx describe la versión v0.0.7 como un agente de código de 6.19 MiB, independiente del modelo y bajo licencia Apache-2.0, mientras que libfx expone un agente headless y un terminal interactivo mediante complementos nativos de Node o WebAssembly. Una herramienta de desarrollo local-first que requiera un núcleo nativo compacto junto a una demostración funcional en el navegador encontrará aquí una opción atractiva. La advertencia es clara: fx está en fase experimental, el soporte en navegador exige JSPI, la compilación en WASM prescinde de capacidades nativas fundamentales y los controles de sandbox para comandos del anfitrión desaparecieron en la v0.0.5.

Ideal para: Investigación controlada de agentes ligeros en binario nativo, ACP, Node o directamente en el navegador
Destacado: Un solo núcleo en Zig compilado como binario nativo, módulos para Node, fx-core.wasm y fx-term.wasm
Precios: Gratuito bajo licencia Apache-2.0; credenciales de modelos o recursos locales independientes
Prueba gratuita: No aplica; fx es gratuito y de código abierto

La versión actual 0.0.7 añade intervención durante el turno activo (turn steering), configuración de MCP a nivel de proyecto, detección de capacidades MCP y controles de confianza más estrictos. Sin embargo, el límite operativo crucial persiste: desde la v0.0.5, los comandos aprobados en segundo plano, monitorizados o capturados se ejecutan como subprocesos corrientes del sistema operativo anfitrión, habiendo retirado la configuración, estados y comandos de sandbox anteriores.

Este detalle es de suma importancia. En una aplicación de escritorio, un comando autorizado afectará directamente al sistema operativo a menos que la aplicación anfitriona implemente sus propios límites de contención. En términos de costes, esto obliga a presupuestar el desarrollo de filtros de admisión de comandos, límites de procesos, perímetros de carpetas, auditoría de ejecuciones y, muy probablemente, un sandbox externo. No debe confundirse un "callback de confirmación de permisos" con un "mecanismo de sandbox".

El uso en navegadores presenta otras restricciones. libfx exige Chrome o Edge 137 o superior y soporte para JSPI al ejecutar WebAssembly en el navegador. Además, el entorno WASM prescinde deliberadamente de procesos del sistema operativo, sandboxing a nivel de SO, servidores MCP nativos, subagentes, skills, actualizaciones automáticas, acceso al sistema de archivos mediante WASI y salidas de red generales. Aunque el anfitrión puede habilitar una interfaz de comandos limitada, deberá asumir la validación, límites de ejecución y filtrado de las salidas generadas.

La seguridad en las credenciales es crítica incluso en entornos de prueba. La documentación desaconseja expresamente exponer claves de API de larga duración en código cliente de navegador. Lo aconsejable es usar credenciales de corta vigencia o un proxy autenticado en el servidor. Si no dispones previamente de dicho proxy, del adaptador de almacenamiento y de las políticas de ejecución, el módulo en el navegador no constituye una solución lista para producción por sí solo.

Su uso más razonable hoy en día son prototipos internos sobre repositorios que no contengan datos sensibles y bajo políticas de herramientas muy estrictas. La peor aproximación sería publicar una aplicación web para usuarios finales que incluya una clave de API persistente, abra la ejecución de comandos y asuma erróneamente que WebAssembly provee aislamiento suficiente. fx merece atención por su versatilidad técnica, pero su estado evolutivo actual justifica su posición al final del ranking.

Cuál deberías elegir según tu caso

Elige Vercel AI SDK HarnessAgent si tu producto debe estar protegido ante la necesidad de cambiar de runtime en el futuro. El cambio nunca es trivial, pero un contrato único orientado al producto preserva la UI, los esquemas de datos, el historial de sesiones y las pruebas de evaluación por encima del adaptador. Descarta Vercel si tu empresa prohíbe el uso de paquetes experimentales o si el adaptador enmascara una funcionalidad avanzada del proveedor que necesitas aprovechar de inmediato.

Elige Claude Agent SDK cuando el bucle de Claude Code sea el factor diferenciador de tu servicio y tu infraestructura soporte la operativa de un subproceso por sesión activa. Es la solución integrada más completa del mercado. Pasa a Codex si la automatización estructurada con hilos nativos y la autenticación existente de OpenAI son prioritarias, o a Vercel si necesitas garantizar una ruta de salida del proveedor.

Elige OpenAI Codex SDK si vas a construir un sistema nativo en el entorno de OpenAI que requiera hilos persistentes, emisión de eventos en streaming estructurado y salidas validadas con JSON Schema. Descarta esta opción si deseas evitar la gestión de subprocesos CLI o si prefieres un contrato desacoplado del proveedor.

Elige Cursor SDK si el flujo de tu producto debe funcionar de idéntica manera tanto en el equipo local del programador como en agentes cloud gestionados en la infraestructura de Cursor. Descarta este enfoque si el auto-alojamiento o la total neutralidad técnica son condiciones obligatorias.

Elige OpenHands si necesitas una plataforma centralizada y abierta de agentes para múltiples clientes bajo las políticas de tu propia infraestructura. La separación entre cliente, servidor y entorno de trabajo aislado es idónea para equipos de plataforma interna. Opta por OpenCode si prefieres un cliente tipado para TypeScript, o por Pi si una arquitectura remota completa sobrepasa tus necesidades actuales.

Elige OpenCode SDK si buscas un cliente tipado claro que interactúe con un servidor OpenCode específico. Funciona muy bien en herramientas de escritorio y portales internos. Descarta esta alternativa si tu aplicación no puede asumir la gestión operativa del servidor y su configuración de red.

Elige Pi si requieres un bucle pequeño, componible y flexible, donde tu equipo tenga el control total sobre las herramientas, la memoria y las reglas de ejecución. Pasa a un runtime más robusto si construir esas piezas no aporta diferenciación real a tu producto.

Elige fx únicamente si tu objetivo es investigar la viabilidad de binarios ultraligeros, ACP o WebAssembly en el navegador. Su modelo de contención actual requiere más trabajo de arquitectura propio de lo que su reducido tamaño aparenta a primera vista.

Si lo que buscas es una implantación corporativa para uso de los empleados en vez de una integración en el código de tu producto, revisa la guía de agentes de IA para programar en empresas, donde las compras de licencias, identidades compartidas, auditoría y adopción pesan más que las APIs técnicas.

Opciones a evitar

Descartar una herramienta en este análisis no significa que sea ineficaz programando, sino que no ofrece el contrato adecuado para ser integrada en una aplicación.

Aider como dependencia embebida de un producto. Aider es una excelente herramienta para pair programming desde el terminal y conecta fácilmente con modelos locales o cloud. Aunque una CLI puede ejecutarse mediante scripts, la automatización por subprocesos no equivale a un contrato documentado y estable para integración en productos, con garantías sobre sesiones, permisos, ciclos de vida y salidas estructuradas. Emplea Aider directamente en tu terminal; para desarrollar una aplicación, apóyate en un SDK o una API de servidor oficial.

SWE-agent para integraciones nuevas. El propio repositorio oficial de SWE-agent señala que mini-SWE-agent lo ha sucedido y recomienda el nuevo desarrollo para nuevos usos. SWE-agent sigue teniendo valor para investigación y reproducción de benchmarks académicos, pero iniciar la arquitectura de un producto comercial sobre un proyecto ya reemplazado genera una deuda técnica evitable.

Evita asimismo cualquier envoltorio o wrapper cuya única propuesta de valor sea el acceso a un modelo específico. Los modelos evolucionan con mucha más rapidez que los esquemas de sesión, las políticas de seguridad, los conjuntos de pruebas de evaluación y los flujos operativos de tus clientes. Una buena capa de control debe dar visibilidad y estabilidad a estos últimos activos.

Qué hacer el lunes

No intentes integrar ocho SDKs a la vez al empezar la semana. Comienza definiendo un contrato de aceptación neutro respecto al runtime y ejecútalo sobre dos alternativas.

Selecciona tres casos de prueba reales en repositorios que reflejen el trabajo de tu producto:

• Un test unitario que falla y requiere un arreglo acotado
• Una actualización de dependencias con su correspondiente nota de migración
• Una revisión de código en modo solo lectura que deba señalar los archivos exactos sin aplicar ningún parche

Para cada caso, determina el alcance de archivos permitido, los comandos autorizados, el tiempo máximo de ejecución, el límite de tokens, el esquema de datos exigido y las condiciones para escalar a un humano. Registra si la tarea concluyó con éxito, el resultado de las pruebas, los archivos editados, las herramientas rechazadas, los tokens gastados, los reintentos requeridos y los minutos transcurridos hasta la validación humana. Lanza estas pruebas primero en la herramienta preferida y luego en su competidor más directo.

El resultado debe ser un informe de decisión interno claro, no una comparativa teórica. Si Vercel preserva el contrato funcional y los runtimes arrojan métricas similares, la portabilidad resultará ganadora. Si Claude resuelve las tareas más complejas con menos reintentos, el acoplamiento con su servicio puede compensar los costes operativos. Si OpenHands garantiza el aislamiento exigido sin depender de terceros, el equipo de sistemas aceptará el despliegue de su infraestructura. Y si fx exige desarrollar un sandbox personalizado antes de atender al primer cliente, ese esfuerzo deberá integrarse en el presupuesto de salida desde ya.

Preguntas frecuentes

¿Cuál es el mejor harness de agentes de código para LLMs locales?

OpenHands es la suite open source más robusta cuando los modelos locales precisan un servidor remoto y espacios de trabajo aislados. Pi resulta más conveniente si buscas un bucle ligero y vas a encargarte de las herramientas, la persistencia y el sandbox. fx también es agnóstico respecto al modelo, pero su carácter experimental lo orienta más hacia la investigación que hacia entornos de producción.

¿Qué harness de agentes de código ofrece el mejor rendimiento en benchmarks?

Ningún benchmark generalista mide con precisión la idoneidad para una integración embebida. Los benchmarks miden tareas bajo sus propias herramientas, instrucciones, repositorios y restricciones. Los equipos de producto deben evaluar repositorios representativos de su entorno real aplicando sus propias reglas de seguridad, comparando tasas de éxito, reintentos, consumo de tokens y tiempo de supervisión humana.

¿Es OpenCode un harness integrable para agentes de código?

Sí. El SDK oficial de OpenCode permite levantar el servidor y el cliente de forma conjunta o enlazar un cliente tipado a un servidor ya existente. Por tanto, su contrato de integración opera a nivel de cliente/servidor y no como un bucle interno dentro del proceso.

¿Cuál es el mejor harness gratuito de agentes de código integrables?

OpenHands es la solución de código abierto con licencia MIT más completa; Pi representa el núcleo mínimo más sólido bajo la misma licencia MIT. OpenCode y fx también son proyectos abiertos. Debe recordarse que "gratuito" alude a la licencia del código, no al consumo de tokens en los modelos, servidores, almacenamiento, ancho de banda ni las horas de ingeniería dedicadas a operarlo.

Lista de comprobación para auditar flujos de trabajo de IA

Utiliza esta plantilla gratuita para identificar qué procesos de desarrollo están listos para un agente y cuáles siguen necesitando supervisión humana.