¿Qué es un harness de agente? Investigación, proyectos de código abierto y prácticas de la industria

Dos agentes pueden usar exactamente el mismo modelo y obtener resultados muy distintos en el mismo benchmark. OpenAI lo midió directamente: en SWE-bench Lite, GPT-4 obtuvo 2.7% con un harness y 28.3% con otro, una diferencia de 10 veces generada por completo por el harness. A medida que la industria pasó de preguntar «qué modelo es más inteligente» a «qué agente realmente completa el trabajo», el harness de agente se convirtió en la capa donde se gana o se pierde la confiabilidad. Sigue leyendo para conocer qué es un harness de agente, qué dicen los artículos y benchmarks más recientes sobre su diseño, qué harnesses de código abierto valen tu tiempo y cómo los principales laboratorios de IA diseñan los suyos, incluido Kimi K3.1 Pro, el modelo de pesos abiertos que Moonshot AI combina con sus propios harnesses.

Un harness de agente es la infraestructura circundante que permite a un modelo de lenguaje grande operar como agente dentro de un entorno real. Mientras el modelo produce tokens, el harness hace todo lo demás: construye el prompt en cada paso, define qué herramientas existen y cómo se invocan, ejecuta acciones en un entorno aislado o una terminal, devuelve las observaciones al modelo, aplica límites de pasos y costos, y registra la trayectoria completa para evaluación o depuración.

El término proviene del ámbito de la evaluación: un "test harness" es el sistema que ejecuta un sistema en condiciones controladas. En la IA agéntica, la misma idea se extendió a la producción: un harness es tanto el sistema utilizado para medir un agente (como en SWE-bench o Terminal-Bench) como el utilizado para ejecutar un agente (como en SWE-agent, OpenHands o Claude Code).

La propia investigación de Anthropic sobre SWE-bench lo expresa claramente: el benchmark "no solo evalúa el modelo de IA de forma aislada, sino un sistema completo de 'agente'", donde el agente es "la combinación de un modelo de IA y la infraestructura de software que lo rodea". Su Claude 3.5 Sonnet mejorado alcanzó 49% en SWE-bench Verified no con un framework complejo, sino con un harness mínimo de un prompt y dos herramientas de propósito general (una herramienta Bash y una herramienta Edit).

Durante años, las mejoras en las tablas de clasificación se atribuyeron a la escala del modelo. Investigaciones recientes cuestionaron esa suposición desde dos direcciones.

Primero, el resultado de "menos es más": en julio de 2025, el equipo de SWE-bench lanzó mini-SWE-agent, un harness de unas 100 líneas de Python sin herramientas aparte de bash, con un historial de mensajes completamente lineal y cada acción ejecutada como una llamada independiente a subprocess.run. Alcanzó puntajes de benchmark competitivos frente a frameworks mucho más complejos (tratados en la sección de investigación más adelante). La conclusión fue provocadora: cuando el modelo es lo suficientemente potente, un harness extremadamente simple y predecible puede superar a uno pesado. Meta, NVIDIA, IBM, Princeton y Stanford ya lo usan como referencia.

Segundo, el resultado de "más es menos": un harness deficiente —salidas de herramientas con ruido, ciclos sin límites, mala recuperación ante errores— puede hacer que un modelo de vanguardia parezca mediocre. OpenAI descubrió que depurar las tareas defectuosas de SWE-bench (detalladas en la sección de OpenAI más adelante) más que duplicó el rendimiento medido de los modelos.

Por eso la ingeniería de harnesses se ha convertido en una disciplina propia. El harness determina:

• Lo que ve el modelo: la estructura del prompt, los esquemas de herramientas y cuánto del estado del entorno y del historial se incluye en la ventana de contexto.

• Lo que puede hacer el modelo: qué herramientas están disponibles (shell, editor de archivos, navegador, búsqueda) y cómo se analizan y validan las acciones antes de ejecutarlas.

• Cómo se manejan las fallas: reintentos, tiempos de espera, compactación del contexto cuando se llena la ventana y finalización ordenada.

• Cómo se mide el trabajo: registro de trayectorias, evaluación y contabilización de costos; sin ello no hay evaluación ni ciclo de mejora.

Ya sea un sistema de benchmark de investigación o un asistente de programación para producción, casi todos los harnesses de agentes implementan el mismo ciclo central:

1. Recepción de la tarea: leer el problema, la instrucción o el objetivo, e iniciar un entorno aislado (normalmente un contenedor Docker o una instantánea de VM).

2. Ensamblaje del prompt: combinar el prompt del sistema, las definiciones de herramientas, la descripción de la tarea y el historial acumulado de acciones y observaciones.

3. Análisis de acciones: convertir la salida del modelo en una llamada concreta a una herramienta —un comando de bash, una edición de archivo, una solicitud de API— y rechazar las acciones malformadas.

4. Ejecución y observación: ejecutar la acción en el entorno, capturar stdout/stderr o el estado de la UI, y truncarlo para ajustarse al presupuesto de contexto.

5. Flujo de control: aplicar límites de pasos, costos y condiciones de detención; decidir cuándo consultar a una persona o terminar el episodio.

6. Registro y evaluación: guardar la trayectoria completa y evaluar el estado final; por ejemplo, ejecutando la suite de pruebas del repositorio en SWE-bench.

Las decisiones de diseño en cada paso se acumulan. La estrategia de truncamiento por sí sola puede alterar notablemente las puntuaciones en tareas de horizonte largo, por lo que los equipos serios tratan el harness como software versionado y comprobable, no como código de integración.

La literatura académica sobre harnesses de agentes ha llegado a un pequeño número de conclusiones obtenidas con esfuerzo. En lugar de catalogar cada benchmark, esta sección recorre las preguntas de investigación que obligaron al campo a tomar en serio el harness.

Antes de los artículos, una introducción rápida. Un benchmark es un conjunto fijo de tareas junto con una regla de puntuación, diseñado para comparar distintos sistemas en condiciones idénticas. En la evaluación de agentes, un benchmark tiene tres componentes: un conjunto de tareas (issues reales de GitHub, comandos de terminal, tareas web), un entorno de ejecución (un contenedor Docker, un navegador, una terminal) y un evaluador (una suite de pruebas, una verificación de estado, una revisión humana). El harness se sitúa entre el modelo y los tres: es la variable que determina si la capacidad del modelo se refleja en la puntuación.

La forma en que se miden realmente las puntuaciones importa más que la cifra principal. En SWE-bench, un agente genera un parche de código; luego, el benchmark ejecuta dos suites de pruebas: FAIL_TO_PASS (pruebas que fallaban antes de la corrección y ahora deben pasar) y PASS_TO_PASS (pruebas que funcionaban antes y no deben dejar de funcionar). Una tarea solo se considera resuelta si ambas pasan. Por eso, las funciones del harness, como la ejecución de pruebas y la generación de diffs, no son extras opcionales: ahí es donde se ganan o pierden puntos.

Tres reglas para interpretar cualquier puntuación de benchmark:

1. Pregunte qué oculta la puntuación. Un modelo entrenado con datos públicos de GitHub puede haber visto los mismos issues en los que se le evalúa; la contaminación de datos puede inflar las puntuaciones sin que haya una mejora real de capacidad. Los entornos reproducibles y los conjuntos de tareas reservados para evaluación son el antídoto.

2. Cuidado con la ley de Goodhart: cuando una medida se convierte en un objetivo, deja de ser una buena medida. Un harness ajustado para sobresalir en un benchmark puede estar aprendiendo trucos específicos de ese benchmark en lugar de capacidad general; por eso los equipos serios evalúan con más de uno.

3. Revise el harness, no solo el modelo. Como muestra el resto de esta sección, el mismo modelo puede obtener 2.7% o 28.3% según la infraestructura de apoyo. Una puntuación sin un harness identificado es una anécdota, no una medición.

El artículo original de SWE-bench ("Can Language Models Resolve Real-World GitHub Issues?") presentó la evaluación hoy canónica: dar a un modelo un issue real de GitHub y el repositorio completo, y evaluar si su parche logra que pasen las pruebas que fallaban. Su resultado más citado suele malinterpretarse: el mejor modelo de la época, Claude 2, resolvió apenas el 1.96% de las tareas. Los propios autores plantearon que el benchmark evaluaba un "razonamiento complejo que va mucho más allá de la generación de código tradicional", pero los trabajos posteriores dejaron claro que una parte importante de la brecha no era capacidad de razonamiento, sino la ausencia de un harness capaz de navegar un repositorio, ejecutar pruebas e iterar. En otras palabras, SWE-bench no solo midió modelos; reveló que faltaba la pieza del harness que los rodea.

El artículo de SWE-agent ("Agent-Computer Interfaces Enable Automated Software Engineering") es el documento fundacional del campo sobre diseño de harnesses. Su afirmación central es que el diseño de la interfaz es una variable de primer orden: los autores introdujeron el término Agent-Computer Interface (ACI) y mostraron que una interfaz diseñada específicamente —un editor de archivos con protección de linter, retroalimentación concisa de la shell y mecanismos de protección contra comandos malformados— elevó pass@1 en SWE-bench de unos pocos puntos porcentuales a 12.5%, el estado del arte en ese momento. La contribución duradera del artículo es el argumento de que los "agentes de LM representan una nueva categoría de usuarios finales" que necesitan software diseñado para ellos, igual que las personas necesitan IDEs. Todos los artículos posteriores sobre harnesses citan este resultado.

Dos artículos de 2024 extendieron la investigación sobre harnesses desde los repositorios de código a la computadora completa. OSWorld creó el primer entorno escalable de computadora real en Ubuntu, Windows y macOS, con 369 tareas que abarcan aplicaciones web y de escritorio. Su cifra principal —las personas completan el 72.36% de las tareas y el mejor modelo, el 12.24%— identificó el anclaje en la GUI (convertir la salida del modelo en clics y pulsaciones de teclas correctos) como el modo de falla dominante: un problema del harness, no de conocimiento. WebArena adoptó otro enfoque: un entorno web autoalojado y totalmente reproducible (comercio electrónico, foros, GitLab, CMS), donde GPT-4 alcanzó apenas un 14.41% de éxito de extremo a extremo frente al 78.24% de las personas. Ambos artículos establecieron que la evaluación de harnesses debe basarse en la ejecución (verificar el estado final del entorno), no en la coincidencia de patrones con las salidas del modelo.

τ-bench de Sierra ("A Benchmark for Tool-Agent-User Interaction in Real-World Domains") planteó un punto más sutil: en producción, el harness no solo envuelve al modelo y al entorno, también media al usuario. El benchmark simula conversaciones dinámicas entre un usuario de modelo de lenguaje y un agente con API de dominio y directrices de políticas, y luego evalúa el estado final de la base de datos. Su métrica principal, pass^k (éxito en k pruebas independientes), reveló cuán inconsistentes son los agentes: GPT-4o resolvió menos del 50% de las tareas una vez, y pass^8 cayó por debajo del 25% en comercio minorista. La lección para quienes construyen harnesses es que la confiabilidad es una propiedad distribucional, no una propiedad de una sola ejecución: un harness que funciona una vez no es un harness que funciona.

El artículo de METR "Measuring AI Ability to Complete Long Software Tasks" introdujo el horizonte temporal de finalización del 50% de las tareas: la duración de tarea (medida por el tiempo que tarda una persona en completarla) que un modelo termina con una confiabilidad del 50%. Los modelos de frontera pasaron de minutos a aproximadamente una hora entre 2019 y 2025, duplicándose cerca de cada siete meses. Para la ingeniería de harnesses, este es el hallazgo más trascendente de la década: el harness que restringe a un modelo de 2024 es lastre inútil para un modelo de 2026. El planteamiento de Anthropic es que cada componente de un harness codifica una suposición sobre lo que el modelo no puede hacer, y esas suposiciones quedan obsoletas a medida que los modelos mejoran.

El benchmark original se ha convertido en un ecosistema que pone en práctica estas lecciones:

• SWE-bench Verified (con OpenAI, 2024): un subconjunto de 500 instancias filtrado por personas que eliminó tareas insuficientemente especificadas o evaluadas de forma injusta; se filtró el 68.3% del conjunto original, lo que más que duplicó las puntuaciones medidas y lo convirtió en la tabla de clasificación predeterminada.

• SWE-smith (2025): una canalización para generar tareas de entrenamiento sintéticas, de modo que los modelos puedan entrenarse para harnesses de agentes, no solo evaluarse con ellos.

• mini-SWE-agent (2025): el harness de unas 100 líneas que ahora supera el 74% en SWE-bench Verified, demostrando que un ciclo mínimo basado únicamente en bash con un historial lineal es suficiente cuando el modelo es sólido, y convirtiéndose en la referencia predeterminada de la comunidad.

• Terminal-Bench (Stanford × Laude, 2025): evaluación de tareas de terminal basada en el framework Harbor, que lleva los harnesses más allá de la edición de código hacia la administración de sistemas.

• CodeClash (2025) y ProgramBench (2026): creación de software orientada a objetivos y desde cero, que extiende los harnesses de correcciones de un solo issue al desarrollo abierto.

El hilo conductor de todos estos trabajos es consistente: el harness no es infraestructura secundaria, es el objeto de estudio. Informe el harness junto con la puntuación, mantenga el entorno reproducible y desconfíe de cualquier resultado cuyo harness no pueda inspeccionarse.

Los harnesses de código abierto son donde comienzan la mayoría de los equipos. Los siguientes proyectos combinan grandes comunidades en GitHub —decenas de miles de estrellas en los líderes— con mantenimiento activo:

Al elegir entre ellos, la heurística de la comunidad es usar el entorno mínimo que exprese tu tarea (la filosofía de mini-SWE-agent) y añadir complejidad solo cuando un fallo medido lo exija. DeepSeek Harness ocupa el extremo opuesto del espectro: una plataforma totalmente basada en plugins para equipos que quieren que cada capa sea reemplazable; pero ambos comparten una disciplina: un registro de sesión duradero, de solo anexado, como única fuente de verdad sobre lo que vio el modelo.

Los laboratorios de vanguardia consideran la ingeniería de entornos como propiedad intelectual central, y varios han publicado su enfoque con un nivel de detalle inusual.

Anthropic ha publicado el registro público más completo sobre ingeniería de entornos, y su arquitectura —detallada en Building Effective Agents (2024), la publicación sobre el entorno de SWE-bench (2024) y Managed Agents (2026)— puede entenderse como tres capas concéntricas.

La capa de ejecución es deliberadamente mínima: una herramienta Bash para ejecutar comandos y una herramienta de edición para ver y modificar archivos. El esfuerzo de diseño se centró en hacer que esas herramientas fueran resistentes a errores —exigiendo rutas absolutas, truncando resultados extensos y aplicando ediciones solo cuando hay una coincidencia de cadena única—, para que el modelo rara vez tenga que recuperarse de fallos evitables de las herramientas.

La capa de sesión es un registro de eventos duradero, de solo anexado, que existe fuera de la ventana de contexto del modelo. Todas las acciones y observaciones se registran allí; el contexto del modelo es una proyección de ese registro, no el registro en sí. Esta separación permite reiniciar y reanudar a mitad de una tarea un proceso de entorno que haya fallado, y hace que el entorno sea ganado desechable en vez de una mascota.

La capa de orquestación —lo que Anthropic llama el "meta-entorno"— desacopla el "cerebro" (el modelo y su ciclo) de las "manos" (sandboxes y herramientas) mediante interfaces explícitas. Como el cerebro ya no reside dentro del contenedor de ejecución, los sandboxes pueden aprovisionarse bajo demanda y las credenciales pueden guardarse en una bóveda a la que el sandbox nunca accede. El beneficio que reportan es estructural, no cosmético: el p50 del tiempo hasta el primer token bajó aproximadamente un 60 % y el p95 más de un 90 %, porque las sesiones ya no esperan contenedores que quizá nunca usen.

Tres documentos trazan esta evolución: Building Effective Agents (2024), la publicación sobre el entorno de SWE-bench (2024) y Managed Agents (2026).

OpenAI se asoció con el equipo de SWE-bench para crear la división Verified validada por humanos, precisamente porque los entornos necesitan tareas limpias: su campaña de anotación (93 desarrolladores, 1,699 muestras) determinó que el 68.3 % de las tareas del benchmark original eran problemáticas, y eliminarlas más que duplicó el rendimiento medido. La misma publicación señala que la sola elección del entorno llevó a GPT-4 de 2.7 % a 28.3 % en SWE-bench Lite, una diferencia que citan para sostener que las evaluaciones deben considerar el progreso de los entornos creados por la comunidad.

En el ámbito de código abierto, Codex CLI se ofrece como un entorno de referencia completo. Su arquitectura está organizada en capas, de forma similar a los demás sistemas de esta sección: un ciclo central de agentes se encarga de la planificación y las llamadas a herramientas; una capa de sandbox aísla la ejecución con políticas configurables por tarea; una capa de sesión conserva las conversaciones para poder reanudarlas, bifurcarlas o compactarlas; y una capa de herramientas expone tanto acceso al shell local como herramientas externas basadas en MCP. En lugar de codificar una sola interfaz, el mismo motor se expone a través de tres superficies: una UI de terminal para trabajo interactivo, un servidor de aplicaciones JSON-RPC para clientes enriquecidos como VS Code y un servicio remoto de ejecución de código para sandboxes en la nube, de modo que el entorno puede ejecutarse localmente o controlarse mediante programación. El diseño adopta las mismas decisiones que recomienda la literatura de investigación: un ciclo mínimo, un sandbox sólido, gestión explícita del contexto y un límite claro entre el modelo y el mundo exterior.

Con el kit de desarrollo de agentes (ADK) y el protocolo Agent2Agent (A2A), lanzados en abril de 2025 junto con más de 50 socios tecnológicos, entre ellos Atlassian, Salesforce, SAP y ServiceNow, Google está convirtiendo la capa de infraestructura de ejecución en un producto. A2A estandariza cómo los agentes anuncian sus capacidades (mediante "Agent Cards" en JSON), gestionan tareas de larga duración, intercambian artefactos y negocian formatos de UI, de modo que estas infraestructuras se conviertan en componentes interoperables en lugar de integraciones a medida. Está diseñado explícitamente para complementar el Model Context Protocol (MCP) de Anthropic, que estandariza el lado de las herramientas de la infraestructura de ejecución.

AutoGen y Magentic-One de Microsoft incluyen infraestructuras de ejecución en las que un agente orquestador gestiona un registro de hechos y avances, un diseño publicado para evitar los bucles sin límite que afectan a las infraestructuras ingenuas. GAIA de Meta y Hugging Face creó un benchmark de asistentes generales cuya infraestructura evalúa preguntas del mundo real que requieren navegación web y manejo de archivos; el Open Agent Leaderboard de Hugging Face mantiene el impulso hacia clasificaciones comparables y conscientes de la infraestructura de ejecución.

DeepSeek Harness (dsh) retoma la idea de una metainfraestructura de ejecución y la vuelve componible. Su arquitectura se basa en el framework Cordis, y su premisa central es que cada parte de la infraestructura de ejecución es un plugin reemplazable, incluido el adaptador de modelo, el registro de herramientas, el registro de sesión y el propio bucle del agente.

El diseño se apoya en tres elementos básicos. Primero, un registro de sesión persistente que es la única fuente de verdad sobre lo que vio el modelo; todo lo que llega al modelo debe poder reconstruirse a partir del registro, como invariante de tiempo de ejecución. Segundo, puntos de integración de capacidades: una interfaz de proveedor intercambiable entre el agente y el mundo exterior, de manera que dirigir los proveedores de sistema de archivos y subprocesos a un sandbox remoto traslada también el acceso a Bash, la terminal y el servidor de lenguaje, sin bifurcar la infraestructura de ejecución. Tercero, un ciclo de vida explícito de turnos y pasos con eventos de extensión nombrados (agent/pre-step, tools/execute, agent/turn-stopping) que permiten a los plugins interceptar o reescribir el bucle sin modificar el código central.

El resultado es la implementación de código abierto más cercana a la metainfraestructura de ejecución de Anthropic: una infraestructura cuya estructura no es un framework fijo, sino una composición de plugins que pueden intercambiarse desde la configuración. Con más de 170 mil estrellas en GitHub durante sus primeros meses, señala que la infraestructura de ejecución para agentes se está convirtiendo en una categoría de producto por derecho propio.

El patrón compartido entre todos ellos: mantener el bucle simple, aislar todo en un sandbox, registrar cada paso y nunca confiar en una puntuación sin la infraestructura de ejecución que la produjo.

Todo lo tratado hasta ahora en esta sección —los bucles mínimos, los registros de sesión persistentes, la ejecución aislada en sandbox, las arquitecturas de plugins— comparte una suposición: el entorno del agente es una computadora. Una terminal, un navegador, un sistema de archivos, un repositorio. La infraestructura de ejecución existe para que el agente pueda operar esa máquina de forma confiable.

Pero la trayectoria de investigación descrita antes apunta a otro lugar. τ-bench incorporó al usuario en la infraestructura de ejecución. METR mostró agentes que asumen trabajos que duran días, no minutos. OSWorld y WebArena trasladaron el entorno de un repositorio limpio al desordenado mundo real. La dirección es consistente: a medida que los agentes pasan de ser herramientas de programación a asistentes para el trabajo real, el entorno que deben recorrer ya no es solo silicio, sino personas. Usuarios con expectativas, equipos con historia, organizaciones con permisos y conocimiento institucional.

Ese cambio recae sobre un subsistema de la infraestructura de ejecución por encima de todos los demás: la gestión del contexto. Una sesión de terminal tiene un operador y un historial acotado; una colaboración prolongada tiene diez partes interesadas, meses de decisiones y un repositorio que no deja de crecer. Un sistema de archivos es pasivo; una relación de trabajo es un flujo de compromisos implícitos, ideas a medio terminar y decisiones tomadas al pasar. Todo debe resumirse, compactarse o descartarse antes de llegar al modelo, y cada una de esas decisiones es un punto en el que el agente pierde algo que la tarea necesitaba.

Una infraestructura de ejecución puede comprimir, pero no puede hacerlo de manera arbitraria. Por eso, el tamaño de la ventana de contexto dejó de ser una especificación del modelo y pasó a ser un parámetro de diseño de la infraestructura de ejecución.

La cartera de infraestructuras de ejecución de Moonshot AI aplica a una pila administrada la anatomía definida anteriormente en este artículo. Para el problema Agente × Computadora, sus infraestructuras amplían el bucle estándar: Kimi Browser Extension controla una sesión real del navegador mediante Chrome DevTools Protocol en lugar de un sandbox estéril, un punto de integración de preguntar antes de actuar exige consentimiento a nivel del sistema de archivos y un Agent Swarm amplía la orquestación a 300 subagentes para tareas de largo horizonte.

Lo que impulsa ese bucle es Kimi K3.1 Pro: el primer modelo de la serie K3.1 y el modelo de pesos abiertos de clase 3T más capaz de Moonshot AI hasta la fecha, con una ventana de contexto de 1,048,576 tokens. Tres de sus propiedades inciden directamente en el diseño de la infraestructura de ejecución:

• Una ventana lo bastante grande para posponer la compactación. Un millón de tokens puede contener al mismo tiempo un repositorio de trabajo, la trayectoria en curso y los documentos de referencia. La infraestructura de ejecución sigue truncando —siempre debe hacerlo—, pero el umbral a partir del cual el resumen empieza a destruir información se aleja lo suficiente como para que las tareas de largo horizonte dejen de degradarse silenciosamente a mitad de camino.

• El esfuerzo de razonamiento como un control de la infraestructura de ejecución. K3.1 Pro siempre razona, y reasoning_effort acepta low, high o max, siendo max el valor predeterminado. Esto convierte el costo de razonamiento del modelo en un presupuesto por tarea que establece la infraestructura de ejecución, en lugar de un costo fijo de entrada.

• Herramientas que llegan a mitad de un episodio. La carga dinámica de herramientas permite que la infraestructura de ejecución inyecte una definición completa de herramienta dentro de un mensaje del sistema, de modo que una herramienta está disponible a partir de ese mensaje: sin reiniciar y sin pagar por su esquema en cada turno de una conversación que nunca la utiliza.

Moonshot presenta la infraestructura de ejecución junto con el modelo, que es la disciplina que defiende el resto de este artículo. En Terminal-Bench 4.0, que evalúa agentes de programación en tareas realistas de terminal con recursos limitados bajo pruebas estrictas y específicas para cada tarea, K3.1 Pro alcanza el 65.7 %, por delante de GPT-6 Astra (58.2 %) y apenas por detrás de Claude Opus 5.5 (66.4 %). En Kimi Code Bench 3.0 Long-horizon, un benchmark interno para ejecución de varios pasos, uso de herramientas y resolución integral de problemas, obtiene 61.2 % frente al 55.95 % de K3. La documentación es igual de explícita sobre la relación en sentido inverso: los parámetros de muestreo como temperature y top_p son fijos y deben omitirse de las solicitudes, y el mensaje completo del asistente debe devolverse sin cambios entre turnos; una infraestructura de ejecución que reescribe el mensaje pierde el razonamiento del que depende la siguiente llamada a herramienta.

El mismo modelo opera toda la superficie. Puedes probar la versión web administrada mediante Kimi Agent, ejecutar la infraestructura local completa con Kimi Work, trabajar en la terminal con Kimi Code o llamar directamente a kimi-k3.1-pro mediante la Kimi API. Una variante kimi-k3.1-pro-highspeed intercambia aproximadamente el doble del precio por token por una velocidad de salida de dos a tres veces mayor.

Ya sea que evalúes modelos o lances un producto, se aplica la misma lista de verificación:

1. Parte de la tarea, no del framework. Si tus agentes editan código, está comprobada una infraestructura de ejecución de Bash y editor como ACI de SWE-agent. Si controlan GUI o la web en vivo, necesitas observaciones de sesiones reales y acciones a nivel de clic.

2. Haz que los entornos sean reproducibles. Las imágenes de Docker, las dependencias fijadas y los datos con semilla marcan la diferencia entre un benchmark y una anécdota.

3. Presupuesta deliberadamente la ventana de contexto. El truncamiento de observaciones, el resumen del historial y la compactación son funciones de la infraestructura de ejecución que afectan directamente las puntuaciones y los costos, y explican por qué los modelos de contexto largo reducen cuánto debe descartar la infraestructura.

4. Impón límites estrictos. Los límites de pasos, los tiempos máximos de reloj y los presupuestos en dólares por episodio mantienen a los agentes seguros y las evaluaciones comparables.

5. Registra trayectorias completas desde el primer día. Todo ciclo serio de mejora —revisión humana, agrupación de fallas, ajuste fino— consume datos de trayectorias. Managed Agents de Anthropic y DeepSeek Harness van aún más lejos: mantienen el registro de sesión fuera del bucle de la infraestructura de ejecución como un flujo de eventos de solo adición, de modo que la infraestructura misma es desechable y el contexto del modelo siempre puede reconstruirse.

6. Evalúa en más de una infraestructura de ejecución. Si tu agente solo funciona dentro de una infraestructura, has creado comportamiento específico de esa infraestructura, no capacidad.

7. Mantén las credenciales fuera del sandbox, o completamente fuera de la nube. Trata el entorno de ejecución del agente como no confiable; guarda los tokens en una bóveda e inyéctalos mediante un proxy, o ejecuta toda la sesión de forma local para que las credenciales y el contenido de las páginas nunca salgan del dispositivo, el enfoque que adopta Kimi con sus infraestructuras locales.

La infraestructura de ejecución para agentes se ha convertido discretamente en la capa más importante de la pila agéntica. Las investigaciones de SWE-bench, mini-SWE-agent, Terminal-Bench y METR muestran que el diseño de esta infraestructura puede rivalizar con las mejoras de modelos en impacto; proyectos de código abierto como DeepSeek Harness, OpenHands, SWE-agent y Aider ponen infraestructuras listas para producción al alcance de todos; y Anthropic, OpenAI, Google, Microsoft y Moonshot AI ahora tratan la ingeniería de infraestructuras de ejecución como trabajo de primer nivel.

Pero el cambio más profundo es conceptual. La primera generación de infraestructuras resolvió Agente × Computadora: dar a un modelo manos confiables para una terminal, un navegador y un sistema de archivos. La siguiente generación está resolviendo el problema de contexto que crean esos entornos: trabajo que abarca días, partes interesadas y repositorios que ningún resumidor puede comprimir sin pérdidas. La infraestructura de ejecución evoluciona de andamiaje a entorno operativo, y la línea entre lo que debe gestionar y lo que el modelo puede simplemente retener sigue desplazándose. La ventana de un millón de tokens de Kimi K3.1 Pro es el ejemplo actual más claro: un cambio de modelo que elimina trabajo que antes tenía que hacer la infraestructura de ejecución.

Ya sea que construyas la tuya, adoptes un framework de código abierto u operes una infraestructura de ejecución en producción, los equipos que tratan esta infraestructura como software diseñado, versionado y medible son los que logran que sus agentes realmente terminen el trabajo.