Microsoft abre Orchard, pero el entrenamiento reutilizable de agentes sigue teniendo un problema de escala

Microsoft Research ha abierto Orchard con tres recetas de entrenamiento de agentes, cuestionando la idea de que cada proyecto de agentes necesita su propia infraestructura especializada. El marco abarca ingeniería de software, interacción con navegadores y tareas de asistentes personales. Su promesa central es la reutilización: una capa de entornos puede respaldar la recopilación de datos, el entrenamiento supervisado, el aprendizaje por refuerzo y la evaluación.

Esto importa porque la investigación abierta sobre agentes tiene un problema de infraestructura. Los investigadores pueden examinar muchas bibliotecas de orquestación, pero reproducir los sistemas de entrenamiento que sustentan a agentes capaces sigue siendo difícil. Los entornos aislados, las interfaces de herramientas, las funciones de recompensa y las trayectorias de larga duración suelen quedar estrechamente acoplados a una sola tarea.

Microsoft Orchard intenta separar esas piezas. En lugar de presentar otro marco de aplicaciones, se centra en el entorno donde los agentes actúan y aprenden. Esta distinción lo sitúa más cerca de una plataforma experimental de entrenamiento que de Microsoft Agent Framework o AutoGen, que ayudan principalmente a los desarrolladores a construir y operar aplicaciones de agentes.

Los resultados comunicados son sustanciales. Sin embargo, siguen siendo resultados de investigación del equipo del proyecto, no confirmaciones independientes de rendimiento o accesibilidad. El lanzamiento también plantea una tensión práctica: el software reutilizable puede reducir la duplicación de trabajo de ingeniería, mientras que el entrenamiento de agentes a gran escala sigue exigiendo modelos, capacidad de cómputo, entornos de tareas y experiencia operativa.

Orchard convierte el entorno de los agentes en infraestructura compartida

El cambio importante no es otra interfaz para agentes. Es una capa de entornos reutilizable que acompaña a un agente durante todo su ciclo de entrenamiento.

El proyecto se centra en Orchard Env, un servicio nativo de Kubernetes para gestionar entornos aislados. Un sandbox es un espacio de trabajo controlado en el que un agente puede ejecutar comandos, modificar archivos, explorar aplicaciones y recibir observaciones sin acceso irrestricto al sistema anfitrión.

Según el marco de modelado agéntico del proyecto, este servicio expone operaciones comunes mediante una interfaz REST. Estas operaciones incluyen crear y eliminar sandboxes, ejecutar comandos, leer o escribir archivos y aplicar políticas de red.

El entorno permanece separado del arnés del agente, el software que traduce las salidas del modelo en acciones de herramientas. También permanece separado del sistema de inferencia y del algoritmo de entrenamiento. Por tanto, los investigadores pueden cambiar un modelo o arnés sin reconstruir todos los componentes de gestión de entornos.

Esta separación aborda una fuente recurrente de fricción. Un agente de programación puede necesitar una instantánea de repositorio, herramientas de compilación y pruebas ocultas. Un agente de navegador necesita una interfaz visual y el estado de un sitio web. Un asistente personal necesita API de herramientas y verificación específica de la tarea.

Estos entornos parecen distintos en la capa de aplicación. Sin embargo, por debajo todos requieren un entorno aislado, un gestor de ciclo de vida, un canal de observación y un método para puntuar los resultados. El marco intenta hacer explícitos esos requisitos compartidos.

Microsoft afirma que el servicio promedió 0,28 segundos para la ejecución de comandos en sus pruebas. El artículo adjunto también informa de una prueba de estrés con 1.000 sandboxes y una tasa de éxito del 100 por ciento. Estas mediciones describen la configuración de los investigadores y no deben considerarse garantías universales de producción.

La arquitectura utiliza inyección de agentes en tiempo de ejecución, lo que permite que las imágenes de contenedor específicas de cada tarea permanezcan separadas del servicio de control. También dirige las operaciones de ejecución y archivos directamente a las direcciones de los pods de sandbox. El artículo sostiene que esto evita parte de la sobrecarga asociada a los canales de ejecución de Kubernetes.

Otros detalles operativos revelan cuánta infraestructura requiere el entrenamiento de agentes. El sistema incluye creación asíncrona de sandboxes, supervisión de disponibilidad, limpieza basada en señales de vida, aislamiento de red, reintentos y escalado de recursos. No son funciones llamativas, pero los fallos en cualquiera de ellas pueden invalidar o detener una ejecución de entrenamiento.

Esa amplitud explica el valor del proyecto para la investigación. Los equipos que estudian distintas tareas de agentes pueden reutilizar la misma capa de control y conservar sus propios modelos, herramientas y sistemas de recompensa. En principio, los experimentos resultan más fáciles de comparar porque cambian menos variables de infraestructura entre ellos.

El marco no elimina el diseño especializado de tareas. Los investigadores aún deben crear entornos válidos, definir acciones permitidas, proteger los sandboxes y desarrollar evaluadores significativos. Reduce la ingeniería repetida en torno a esas decisiones, en lugar de hacer que las decisiones desaparezcan.

La presión real recae sobre las pilas de entrenamiento específicas de cada tarea

Orchard cuestiona la premisa de que los agentes de programación, navegador y asistentes requieren sistemas de entrenamiento separados de extremo a extremo.

La mayoría de los marcos públicos para agentes se concentran en la orquestación. Ayudan a los modelos a llamar herramientas, intercambiar mensajes, seguir flujos de trabajo o coordinar múltiples agentes. Estas capacidades son importantes para las aplicaciones, pero no producen automáticamente los datos y la retroalimentación necesarios para mejorar un modelo.

El entrenamiento añade otra capa. Un agente debe intentar tareas en un entorno controlado, generar trayectorias de múltiples pasos, recibir recompensas fiables y convertir esas interacciones en actualizaciones del modelo. Cada etapa puede depender de software e infraestructura distintos.

Una trayectoria es la secuencia completa de razonamiento, acciones, respuestas de herramientas y estados del entorno generada durante una tarea. Estos registros pueden convertirse en ejemplos de entrenamiento, pero solo cuando el sistema conserva su estructura y determina qué comportamiento ayudó.

El desafío se acentúa con tareas de horizonte largo. Un agente de programación puede inspeccionar varios archivos, intentar un parche, ejecutar pruebas, revisar su enfoque y aun así fracasar al final. Una simple etiqueta de éxito o fracaso no explica qué decisiones intermedias fueron útiles.

La respuesta del proyecto es reutilizar tanto los entornos como las trayectorias entre las etapas de la canalización. El mismo servicio de entornos admite recopilación de datos con modelos docentes, ajuste fino supervisado, despliegues de aprendizaje por refuerzo y evaluación final. Los investigadores no necesitan sistemas de sandbox separados para cada etapa.

Este diseño contrasta con la orquestación orientada a producción. El marco de aplicaciones para agentes independiente de Microsoft se dirige a la construcción y el despliegue de agentes en Python y .NET. AutoGen también estableció patrones comunes para conversaciones multiagente y uso de herramientas.

La nueva pila de investigación aborda una pregunta distinta: ¿cómo pueden los equipos entrenar la política subyacente que decide qué debe hacer un agente a continuación? Esta diferencia impide una comparación directa de productos. Un marco de aplicaciones y un entorno de entrenamiento pueden complementarse.

La presión recae, en cambio, sobre las canalizaciones de investigación cerradas e integradas verticalmente. Si la misma capa abierta de entornos funciona en múltiples dominios, los equipos tienen menos motivos para aceptar un paquete inseparable de modelo, arnés, sandbox y evaluador.

En teoría, los grupos de investigación más pequeños son los más beneficiados. Pueden empezar con primitivas de entorno compartidas y recetas publicadas, en lugar de desarrollar un servicio distribuido completo de sandboxes. También pueden probar modelos más pequeños en tareas antes asociadas con sistemas mucho mayores.

Sin embargo, “más pequeños” sigue siendo un término relativo. Ejecutar sandboxes de Kubernetes, servidores de inferencia, modelos docentes y trabajos de aprendizaje por refuerzo todavía exige profundidad técnica. El lanzamiento reduce una categoría de complejidad sin convertir el entrenamiento de agentes en un flujo de trabajo corriente de portátil.

Las organizaciones también necesitan una gestión disciplinada del conocimiento en torno a estos experimentos. Las trayectorias, los fallos de evaluación, los cambios de configuración y las definiciones de tareas se vuelven rápidamente difíciles de buscar. Una base de conocimientos técnica puede preservar el razonamiento detrás de los resultados, no solo la puntuación final de referencia.

Por tanto, el cambio estratégico tiene que ver con la modularidad. Los investigadores pueden mantener su modelo preferido y su interfaz de agentes mientras sustituyen un backend de entorno personalizado. Si este patrón gana adopción, la reutilización de infraestructura podría convertirse en una expectativa básica de la investigación abierta sobre agentes.

Microsoft Orchard aprende de las partes útiles del fracaso

La idea más sólida del marco es que una ejecución fallida de un agente todavía puede contener evidencia valiosa para el entrenamiento.

La receta de ingeniería de software, llamada Orchard-SWE, comienza con aproximadamente 107.000 trayectorias destiladas de MiniMax-M2.5 y Qwen3.5-397B. Microsoft informa que el corpus abarca 2.788 repositorios de GitHub.

El conjunto de datos de trayectorias del proyecto describe 107.185 registros de ingeniería de software. Enumera 74.649 trayectorias resueltas y 32.536 trayectorias no resueltas. Un registro resuelto significa que el parche final superó la batería de pruebas ocultas de la tarea.

El ajuste fino supervisado tradicional favorece los ejemplos exitosos. Tiene sentido de forma intuitiva porque el modelo aprende a reproducir comportamientos que alcanzaron el resultado correcto. Sin embargo, descartar cada trayectoria fallida puede desperdiciar trabajo intermedio útil.

Una ejecución fallida de programación podría localizar correctamente el módulo relevante, identificar una condición defectuosa y escribir la mayor parte de un parche válido. Una edición posterior podría romper la solución. Considerar toda la trayectoria como inútil pierde el progreso anterior.

La receta introduce ajuste fino supervisado con asignación de crédito para recuperar esa señal. La asignación de crédito consiste en identificar qué acciones contribuyeron al progreso, en vez de atribuir un único resultado a cada paso.

Para las ejecuciones no resueltas, un modelo docente revisa la trayectoria completa junto con el resultado final de las pruebas. Estima cómo cambió la probabilidad de resolver la tarea después de cada paso. A continuación, la canalización selecciona segmentos contiguos en los que esa probabilidad estimada aumentó.

Esos segmentos ascendentes se convierten en objetivos supervisados. Las observaciones anteriores siguen disponibles como contexto, mientras que la pérdida de entrenamiento se centra en el razonamiento y las acciones generados por el asistente que se consideran representativos de progreso. Las respuestas de herramientas se excluyen de la pérdida de predicción.

Esta técnica no convierte el fracaso en éxito. Formula una afirmación más acotada: algunas partes de un intento fallido pueden enseñar a un modelo cómo es una exploración productiva. La fiabilidad de esa lección depende de las estimaciones retrospectivas del modelo docente.

La receta añade después aprendizaje por refuerzo, en el que el modelo genera nuevos intentos y recibe recompensas a nivel de tarea. La parte difícil es obtener grupos de intentos informativos sin gastar la mayor parte del presupuesto en resultados uniformes.

Si todos los intentos tienen éxito, el grupo aporta poca información sobre qué elecciones de política fueron mejores. El mismo problema ocurre cuando todos los intentos fracasan. El muestreo estándar de tamaño fijo puede consumir una cantidad considerable de cómputo al generar estos grupos de baja varianza.

Microsoft llama a su alternativa Balanced Adaptive Rollout. El método genera intentos progresivamente e intenta formar un grupo de entrenamiento con un equilibrio útil de recompensas positivas y negativas. Puede detenerse después de encontrar un grupo informativo o continuar dentro de un presupuesto máximo fijo.

El enfoque busca eficiencia, no solo precisión. Asigna más muestreo a los prompts que necesitan intentos adicionales para producir una comparación significativa. Los grupos que siguen siendo inadecuados pueden filtrarse y reponerse con otras tareas.

El proyecto informa que un modelo inicializado a partir de Qwen3-30B-A3B-Thinking alcanzó un 64,3 por ciento en SWE-bench Verified tras el ajuste fino supervisado. Alcanzó un 67,5 por ciento después del aprendizaje por refuerzo.

SWE-bench Verified evalúa si los agentes pueden resolver incidencias reales de GitHub en entornos de repositorio reproducibles. Las puntuaciones dependen de la versión del benchmark, el harness, la configuración de inferencia y los procedimientos de evaluación, por lo que las comparaciones requieren una estrecha alineación metodológica.

Microsoft describe su resultado como un nuevo máximo entre los modelos abiertos de tamaño comparable. Esa salvedad es importante. El resultado no establece superioridad frente a todos los sistemas de agentes, en particular los modelos cerrados que usan presupuestos de cómputo distintos o andamiajes no divulgados.

Aun así, el mecanismo es más interesante que la posición en la clasificación. El entrenamiento a partir de progreso parcial y el muestreo para obtener variación informativa de recompensa son técnicas que otros equipos pueden probar de forma independiente. Su valor no depende por completo de una única puntuación reportada.

Un Entorno Da Soporte a Tres Agentes Muy Diferentes

Las tres recetas prueban si la reutilización de infraestructura resiste cambios en el tamaño del modelo, la interfaz, la estructura de tareas y el diseño de recompensas.

La programación es la demostración más amplia, pero no es la única. Orchard-GUI aplica la misma abstracción de entorno a un modelo visión-lenguaje de 4.000 millones de parámetros que interactúa con interfaces de navegador.

Según se informa, la receta utiliza unas 400 trayectorias depuradas y 2.200 tareas abiertas. Microsoft afirma que el modelo resultante logró una tasa de éxito del 74,1 por ciento en WebVoyager, del 67,0 por ciento en Online-Mind2Web y del 64,0 por ciento en DeepShop.

Esos benchmarks cubren distintas formas de interacción web. Un agente de navegador debe interpretar el estado visual, elegir acciones y adaptarse cuando un sitio web responde. A diferencia de una tarea de programación, el éxito podría depender de navegar por interfaces dinámicas en lugar de producir un parche comprobable.

El volumen de datos reportado es destacable porque es mucho menor que el corpus de ingeniería de software. Respalda el argumento de Microsoft de que una receta enfocada y un entorno estable pueden ayudar a un modelo más pequeño a competir sin igualar en número de parámetros a los mayores sistemas propietarios.

Sin embargo, el éxito en benchmarks no garantiza una navegación fiable fuera de la distribución de prueba. Los sitios web cambian, las interfaces exponen estados ambiguos y pequeñas diferencias visuales pueden desviar a un agente. Los evaluadores también necesitan una definición precisa de finalización de la tarea.

La tercera receta, Orchard-Claw, se dirige a agentes de asistente personal. Según el artículo, utiliza una base Qwen3-30B-A3B-Thinking y aproximadamente 200 tareas sintéticas.

Microsoft informa un 59,6 por ciento de pass@3 en Claw-Eval. Pass@3 da al agente hasta tres intentos y considera la tarea exitosa cuando al menos uno de ellos la supera. El resultado asciende al 73,9 por ciento cuando el modelo opera con el harness ZeroClaw más potente.

Esa diferencia ilustra una lección esencial sobre los benchmarks de agentes. El modelo es solo una parte de un sistema de agentes. El diseño del harness, el formato de las herramientas, el comportamiento de reintento, la gestión del contexto y las reglas de evaluación pueden afectar significativamente al resultado final.

También complica las afirmaciones sobre los modelos más pequeños. Una política compacta puede rendir bien rodeada de una infraestructura eficaz, pero el sistema total podría seguir siendo exigente desde el punto de vista operativo. El número de parámetros por sí solo no mide el coste ni la complejidad del despliegue.

En conjunto, las tres recetas crean una prueba de portabilidad más creíble que tres variantes de un único benchmark de programación. Abarcan texto y visión, pruebas deterministas e interfaces abiertas, además de distintas escalas de modelos.

La capa común no hace que todos los dominios sean idénticos. Cada receta sigue teniendo su propia recopilación de datos, cálculo de recompensas, modelo base y harness de agente. La reutilización se produce por debajo de esas decisiones específicas de cada tarea.

Ese límite tiene sentido. Un servicio de entorno universal debería estandarizar las primitivas de ciclo de vida y comunicación sin pretender que una tarea de navegador y una reparación de repositorio tienen los mismos criterios de éxito.

La cuestión más amplia es si los equipos externos pueden reproducir esa separación. Los sistemas internos de investigación suelen parecer modulares en los diagramas, pero dependen de convenciones no documentadas, configuraciones en la nube o pasos de preparación de datos. El uso por parte de la comunidad revelará si las interfaces son realmente portátiles.

La Afirmación de Código Abierto Aún Enfrenta una Prueba de Reproducibilidad

Una arquitectura publicada y resultados sólidos en benchmarks son solo el comienzo de una publicación de investigación abierta.

El artículo proporciona amplios detalles de implementación, descripciones de algoritmos y configuraciones experimentales. Los materiales del proyecto de Microsoft también identifican a los investigadores, modelos, fuentes de tareas y principales resultados de evaluación.

Sin embargo, la apertura práctica tiene varias capas. Los investigadores necesitan código accesible, instrucciones de instalación, conjuntos de datos compatibles, checkpoints de modelos, imágenes de entorno, licencias y suficiente detalle de configuración para recrear los experimentos.

La página del conjunto de datos muestra actualmente un aviso de que su publicación está en pausa y señala que los datos se volverán a cargar. Indica que el esquema documentado es preciso, pero podría no representar la forma final. Los equipos deberían verificar el estado de la página antes de diseñar un pipeline en torno a ella.

Esa pausa no invalida la investigación. Sí limita la reproducibilidad inmediata, especialmente para la receta de ingeniería de software cuyo valor depende en gran medida de la recopilación de trayectorias.

Las licencias también requieren atención cuidadosa. La documentación del conjunto de datos advierte que las trayectorias hacen referencia a repositorios upstream con sus propias licencias. Los investigadores que redistribuyan parches, material de pruebas o artefactos derivados deben examinar esas condiciones individualmente.

La seguridad es otra restricción. El entrenamiento de agentes ejecuta deliberadamente acciones generadas por modelos. Incluso los entornos aislados requieren políticas de red, límites de recursos, controles de credenciales, análisis de imágenes y procedimientos de limpieza.

El artículo describe mecanismos de aislamiento de red y manejo de fallos, pero cada despliegue controla su propio límite de amenazas. Un clúster de investigación que maneja repositorios públicos enfrenta riesgos distintos a los de un entorno empresarial que contiene código privado o herramientas internas.

La contaminación de benchmarks sigue siendo difícil de excluir de forma concluyente. Los modelos docentes podrían haber encontrado incidencias públicas, parches o código relacionado durante el preentrenamiento. Las pruebas de evaluación ocultas reducen algunos riesgos, pero no resuelven todas las dudas sobre la memorización.

El método retrospectivo de asignación de crédito añade otra incertidumbre. Un modelo docente estima si los pasos intermedios mejoraron la probabilidad de éxito. Esas estimaciones solo son etiquetas útiles cuando el docente puede interpretar de forma fiable la trayectoria y el resultado de la prueba.

Una estimación equivocada puede recompensar un comportamiento plausible pero irrelevante. También puede pasar por alto un paso cuyo valor solo se hace evidente más adelante. Las ablaciones independientes deberían comprobar qué parte del rendimiento procede de los datos de fallos parciales en lugar de la escala del modelo, la calidad del docente o la composición del conjunto de datos.

Balanced Adaptive Rollout necesita un escrutinio similar. Seleccionar grupos con variación útil de recompensa puede mejorar la eficiencia del entrenamiento, pero los fallos reales del entorno pueden parecer fallos de la política. Los tiempos de espera agotados, errores de contenedor o pruebas rotas no deben convertirse en recompensas engañosas.

Microsoft informa lógica de reintento, controles de tiempo de espera y filtros para grupos inutilizables. Los equipos externos deben determinar si esas salvaguardas siguen siendo eficaces en distintos clústeres, cargas de trabajo y distribuciones de tareas.

Por tanto, las cifras reportadas deberían leerse como evidencia que respalda un diseño, no como una prueba final de generalidad. La reproducción en infraestructura independiente reforzaría el argumento. Los resultados en nuevos dominios pondrían a prueba si la abstracción de entorno se extiende más allá de las tres recetas preparadas.

El resultado más trascendental podría no ser otro récord de benchmark. Podría ser un sustrato experimental compartido que permita a los investigadores comparar métodos de entrenamiento sin reconstruir la maquinaria que sustenta cada experimento.

Qué Deberían Observar los Investigadores a Continuación

Tres señales determinarán si Orchard se convierte en infraestructura habitual de investigación o sigue siendo una impresionante implementación de referencia de Microsoft.

La primera señal es la integridad de la publicación. Los investigadores deberían estar atentos a la restauración del acceso al conjunto de datos, repositorios de código estables, instrucciones de instalación reproducibles, artefactos de modelos y definiciones versionadas de entornos.

Una publicación completa reforzaría la afirmación de Microsoft de que los equipos más pequeños pueden reutilizar el sistema. Las brechas persistentes la debilitarían, porque las partes más difíciles del entrenamiento de agentes suelen residir en la preparación de datos y la configuración operativa.

La segunda señal es la reproducción independiente. Una prueba creíble utilizaría las recetas publicadas en infraestructura gestionada por separado e informaría tanto de los resultados de benchmark como de los requisitos totales de recursos.

Igualar exactamente la puntuación principal no es el único resultado útil. Los investigadores deberían documentar el tiempo de configuración, las tasas de fallo del sandbox, el rendimiento de trayectorias, el consumo de cómputo y la sensibilidad a las decisiones de harness. Esas mediciones revelan si la reutilización genera ahorros significativos.

Los experimentos independientes también deberían aislar la contribución del ajuste fino de asignación de crédito. Las comparaciones pueden entrenar modelos equivalentes únicamente con trayectorias exitosas, trayectorias completas sin resolver y segmentos de progreso seleccionados.

El mismo enfoque se aplica a los rollouts adaptativos. Los investigadores pueden comparar el muestreo fijo con el muestreo equilibrado manteniendo constantes los modelos, las tareas, las funciones de recompensa y los presupuestos. Eso mostraría si el método produce más señal de aprendizaje por trayectoria generada.

La tercera señal es la adopción más allá de los dominios preparados por Microsoft. Un entorno nuevo ofrecería la prueba más sólida, en especial uno con herramientas y estructuras de recompensa diferentes.

El análisis de seguridad, el trabajo con datos, los flujos de trabajo científicos y las aplicaciones de oficina son candidatos plausibles. Cada uno introduce requisitos de entorno que difieren de la reparación de repositorios o la navegación por navegador. Una reutilización exitosa respaldaría la afirmación de que la abstracción es realmente independiente del harness.

Las respuestas de los competidores también importan, aunque deberían seguir siendo evidencia de apoyo y no la historia principal. Otros proyectos de entrenamiento de agentes podrían adoptar interfaces de entorno compatibles, publicar backends alternativos o estandarizar formatos de trayectorias.

La interoperabilidad crearía más valor que la proliferación de frameworks. Los investigadores podrían mover conjuntos de datos, políticas y evaluadores entre sistemas sin traducir cada formato de acción y observación.

Mientras tanto, los desarrolladores deberían evitar interpretar la publicación como un agente de producción listo para usar. El proyecto es infraestructura de investigación para crear y evaluar políticas. Los sistemas de producción aún necesitan lógica de aplicación, permisos de usuario, supervisión, comportamiento de respaldo y revisión de seguridad.

Para los compradores empresariales, la pregunta relevante no es si el framework gana un benchmark. Es si una infraestructura de entrenamiento modular reduce la dependencia de un único modelo propietario o de una pila de evaluación controlada por el proveedor.

Para los investigadores, el siguiente paso práctico es más acotado. Examinen el artículo de investigación, verifiquen qué artefactos están disponibles y elijan una receta que coincida con un entorno de evaluación existente. Midan el coste operativo junto con el rendimiento de las tareas.

Microsoft ha planteado una propuesta clara: la investigación abierta sobre agentes mejora cuando los entornos se convierten en infraestructura reutilizable en lugar de ser una implementación oculta de cada proyecto. Ahora la comunidad debe poner a prueba la parte más difícil de esa propuesta. ¿Podrán equipos independientes reproducir los resultados, trasladar esta infraestructura a nuevas tareas y mantener la eficiencia prometida fuera del propio entorno de Microsoft?