El código como mundo
El enfoque del código como mundo organiza la interacción con el entorno físico en dos niveles de código. L1 proporciona las operaciones básicas para observar y actuar; L2 combina estas operaciones en procedimientos ejecutables de Python. El control programático forma parte del conjunto más amplio de paradigmas de control corporizado.
El entorno expone cuatro primitivas para leer la tarea, observar la escena, ejecutar una acción y reiniciar el entorno. Estas operaciones conforman la interfaz fija disponible para el agente. Reiniciar solo está permitido en Playground, donde permite volver a intentarlo en la misma escena.
En RoboDojo, las observaciones incluyen imágenes RGB y el estado del robot, incluidos los estados articulares, las poses del efector final y los estados de los comandos de la pinza. Las acciones especifican objetivos articulares o del efector final junto con comandos para la pinza; el controlador nativo se encarga de la cinemática inversa y la interpolación. Esta interfaz no proporciona las poses reales de los objetos, la profundidad ni la calibración de la cámara.
Análisis en profundidad de los fallos de Astra
Para entender dónde tienen dificultades los agentes de programación durante la interacción física, evaluamos GPT-6-Astra con un esfuerzo de razonamiento xhigh en el espacio de trabajo de código. La evaluación se realiza en tareas de RoboDojo-sim de las categorías Generalización, Precisión, Largo horizonte, Memoria y Abiertas, con 5 escenas por tarea. Astra recibe la descripción de la tarea y la documentación de la interfaz del robot, pero no la wiki de la tarea. Cada episodio comienza con un agente, un espacio de trabajo y un simulador nuevos, permite hasta 100 ejecuciones de código aceptadas dentro del límite de acciones propio de la tarea y deshabilita el reinicio.
Astra alcanza una tasa de éxito promedio del 8.50%. Analizamos los programas enviados, las observaciones de la cámara y la retroalimentación para localizar dónde fallan los planes plausibles durante la ejecución física. Dos episodios ilustrativos muestran distintas brechas entre emitir un comando válido y hacer avanzar la tarea.

En el tres en raya, Astra intenta recoger un anillo y colocarlo en el tablero. La pinza alcanza las posiciones objetivo, pero dos intentos consecutivos dejan el anillo sobre la mesa (acciones 216 y 283). Tras inspeccionar una vista de la cámara de muñeca y ajustar el agarre, Astra consigue retener el anillo de forma visible por primera vez en la acción 367, tras consumir un tercio de su presupuesto de 1,100 acciones. Más adelante, el episodio termina por tiempo de espera sin completar el tablero. Este registro muestra cómo construir una rutina de manipulación local puede competir con completar la tarea. Esto motiva conservar un procedimiento parametrizado que combine aproximación, alineación, cierre y verificación de la recogida del objeto, para que los intentos posteriores puedan basarse en una operación que ya funciona.
Auto-mejora mediante la evolución del arnés
Una escena de Playground alberga un ciclo persistente de edición de código, ejecución y retroalimentación. El estado del robot y las definiciones de Python persisten entre envíos; el reinicio permite volver a intentarlo en la misma escena. El agente actualiza las Habilidades y las Lecciones y las aplica en intentos posteriores. Una operación exitosa puede aportar un procedimiento parametrizado; un intento fallido puede revelar una condición útil o sugerir una estrategia de recuperación. Incluso una tarea sin terminar puede ofrecer hallazgos útiles; las explicaciones tentativas siguen siendo hipótesis.

Al final de Playground, solo las Habilidades y las Lecciones se trasladan a Test como artefactos de solo lectura. A la derecha, cada escena no vista de la misma tarea comienza con un agente, un espacio de trabajo, un espacio de nombres de Python y un simulador nuevos. El agente utiliza el arnés congelado para construir código y lo adapta mediante la retroalimentación de la ejecución. El reinicio está deshabilitado y los episodios de Test no actualizan el arnés ni comparten nuevas experiencias. Así se separa la adaptación dentro de cada escena de la contribución del conocimiento adquirido durante Playground.
Los mismos artefactos congelados pueden proporcionarse a otro ejecutor porque su contenido consiste en procedimientos y directrices explícitos. La reutilización entre modelos no requiere exploración adicional en Playground, actualizaciones de parámetros ni un adaptador aprendido. Comparamos arneses autogenerados y transferidos con el mismo ejecutor y en las mismas condiciones de Test para evaluar si el conocimiento adquirido sigue siendo útil entre modelos.
Experimentos
Evaluamos EmbodiedEvo en RoboDojo-Sim para abordar las siguientes preguntas de investigación:
- ¿Qué rendimiento alcanza EmbodiedEvo en comparación con los métodos basados en VLA y WAM?
- ¿Qué capacidades mejoran con la evolución del arnés y qué tareas siguen siendo difíciles?
- ¿Se puede transferir la experiencia adquirida entre modelos y tareas?
Configuración experimental
RoboDojo-Sim es un benchmark exigente para evaluar políticas generalistas de manipulación robótica. Consta de 12 tareas de Generalización, 8 de Precisión, 8 de Largo horizonte, 6 de Memoria y 8 Abiertas. Cada arnés (Habilidades + Lecciones) se adquiere en una disposición de escena de Playground distinta de las disposiciones de Test.
Los ejecutores son GPT-6-Astra con esfuerzo xhigh y medio, GPT-5.6-sol con esfuerzo xhigh y GPT-5.6-luna con esfuerzo xhigh, abreviados como Astra, Sol y Luna.
Discusión
El código expone los parámetros, las comprobaciones y el flujo de control mediante los cuales se ejecuta una estrategia física. Esto proporciona a la retroalimentación un objetivo concreto para la revisión: después de que se caiga una carga, el agente de apilamiento conserva el movimiento acotado y comprueba la retención del objeto durante las ejecuciones posteriores. Los procedimientos parametrizados pueden conservar una operación útil y, a la vez, permitir que sus objetivos cambien según la escena. Las Lecciones complementan esta representación al registrar cuándo aplicar la operación o reconsiderarla. El Historial sin procesar alcanza un éxito observado similar, mientras que Habilidades/Lecciones reducen en un 11.3% el uso total de tokens en Test. Esto sugiere que organizar la interacción en procedimientos y directrices accesibles es una ventaja práctica de la representación; el código por sí solo no garantiza que las suposiciones físicas sean válidas.
Conclusión
Presentamos EmbodiedEvo, un marco que permite a los agentes de programación convertir la interacción física en Habilidades y Lecciones reutilizables sin actualizar los parámetros del modelo. En RoboDojo-Sim, EmbodiedEvo alcanza una puntuación promedio de 44.48 y un SR del 37.82%. Las evaluaciones pareadas muestran mejoras consistentes con distintos ajustes de entrada. Las Habilidades y las Lecciones alcanzan un rendimiento observado comparable al del historial de interacción sin procesar, con un coste de ejecución en Test un 53.0% menor. Estos hallazgos sugieren que la evolución del arnés mejora el punto de partida para resolver tareas al conservar operaciones ejecutables y las condiciones para aplicarlas. El contacto preciso y la ejecución fiable de tareas de largo horizonte siguen siendo áreas importantes para ampliar este enfoque.
Cambios en las capacidades
Los registros de ejecución sustentan el análisis de capacidades. Todos los casos usan Astra/xhigh; las comparaciones pareadas utilizan la misma escena. El conjunto de evidencias conserva los programas originales, la retroalimentación, las lecturas de archivos y los fotogramas de cámara. Estos casos seleccionados ilustran mecanismos, no frecuencias de fallo ni efectos causales aislados.
Reutilización de la experiencia y sus límites
Se comparan la reutilización exitosa, la transferencia entre modelos y un retroceso en el rendimiento. También se incluyen la función de agarre completa conservada y dos Lecciones utilizadas en el caso de apilamiento exitoso.
La Lección congelada registra: «El brazo alcanzó su objetivo, pero falló la retención de la carga». La ejecución 2 de Test incluye ee_move.py y pick_from_above.py literalmente. La ejecución 9 utiliza un límite de traslación de 8 mm después de comprobar visualmente la retención; la ejecución 15 completa la pila. Esto demuestra una reutilización efectiva, sin aislar la contribución causal del límite.
Preguntas frecuentes
¿Qué son las Habilidades y las Lecciones en EmbodiedEvo? Las Habilidades son procedimientos parametrizados reutilizables, mientras que las Lecciones registran las condiciones para aplicarlos o reconsiderarlos.
¿Qué información proporciona la interfaz de RoboDojo? Proporciona imágenes RGB y el estado del robot, incluidos los estados articulares, las poses del efector final y los estados de los comandos de la pinza. No proporciona las poses reales de los objetos, la profundidad ni la calibración de la cámara.
¿Cómo separa EmbodiedEvo el aprendizaje de las pruebas? Las Habilidades y las Lecciones se adquieren en Playground y se congelan como artefactos de solo lectura para Test. Las escenas de Test utilizan agentes, espacios de trabajo, espacios de nombres de Python y simuladores nuevos, con el reinicio deshabilitado.
¿Qué limitaciones persisten en EmbodiedEvo? El contacto preciso y la ejecución fiable de tareas de largo horizonte siguen siendo áreas importantes para ampliar el enfoque.
