Hay una sensación particular cuando dos equipos de investigación separados, trabajando de manera independiente, llegan a la misma conclusión incómoda.
Soy Lena. Me detuve cuando leí EvoSkills y EvoSkill uno tras otro. No porque los resultados fueran sorprendentemente inesperados, sino porque ninguno de los artículos se echó atrás de decir lo que los datos realmente mostraban: las habilidades que los humanos escriben para los agentes de IA tienen un límite, y los agentes pueden evolucionar más allá de él por sí mismos.
Eso no es una afirmación menor. Y la pregunta que sigue — ¿y qué hacemos con eso? — es una en la que no he podido dejar de pensar.
Lo que EvoSkills y EvoSkill Realmente Mostraron
Dos artículos de investigación independientes, misma conclusión: las habilidades creadas manualmente tienen un límite, los agentes pueden evolucionar más allá de éste de forma autónoma.
El Problema de Desalineación Cognitiva Humano-Máquina
Esta es la parte que me tomó desprevenida.
EvoSkills no solo mostró que las habilidades evolucionadas funcionan mejor. Cuantificó por qué las habilidades creadas por humanos tienen un rendimiento inferior, y la respuesta es más estructural de lo que la mayoría de la gente asume. Los diseñadores humanos tienden a escribir flujos de trabajo que coinciden con cómo nosotros pensamos sobre un problema: pasos lineales, abstracciones claras, árboles de decisión ordenados. Pero el razonamiento de los LLM no funciona así.
En SkillsBench, el benchmark construido específicamente para probar esto, la brecha no fue marginal. Las habilidades curadas por humanos tenían una desalineación cognitiva medible con la forma en que los modelos de lenguaje grandes realmente navegan tareas de múltiples pasos. Las habilidades no estaban mal — simplemente no estaban diseñadas para el motor de razonamiento que las ejecuta.
Volvía una y otra vez a esto. No es que los humanos sean malos escribiendo instrucciones. Es que estamos optimizando para la legibilidad humana, no para los patrones de ejecución de los LLM. Esos son objetivos diferentes.
Lo que la Autoevolución Realmente Produjo
Los números merecen un momento de reflexión:
| Métrica | Línea base (sin habilidad) | Habilidad curada por humanos | Habilidad evolucionada (ronda 5) |
|---|---|---|---|
| Tasa de aprobados en EvoSkills | ~34,5% | ~60% (aprox.) | 75% |
| Rondas para superar a los humanos | — | — | Ronda 3 |
| Ganancia sobre la falta de habilidad | — | — | +40,5 pp |
| EvoSkill OfficeQA | Línea base | — | 0,073 |
| EvoSkill SealQA | Línea base | — | 0,121 |
Partiendo del 32%, el agente alcanzó un 75% de aprobación en cinco rondas de evolución. Para la tercera ronda, ya había superado el techo curado por humanos. Esa es la parte que realmente me cuesta racionalizar: el agente no solo estaba cerrando una brecha — estaba abriendo una en la otra dirección.
EvoSkill, operando en un dominio de tarea diferente (QA de documentos de Office e investigación web), mostró el mismo resultado direccional. Ganancias absolutas menores, pero consistentes. +7,3% en OfficeQA, +12,1% en SealQA. Ambos superaron las referencias basales hechas por humanos.
Transferencia entre modelos y tareas cruzadas
Este es el detalle que casi pasé por alto, y no debería haberlo hecho.
Las habilidades evolucionadas para un LLM se transferían entre +35pp y +44pp entre seis modelos diferentes. Eso no es una pequeña ventaja en portabilidad: es la habilidad que codifica algo de la estructura de tareas, no solo las peculiaridades específicas del modelo.
Aún más interesante: las habilidades de SealQA transfirieron el cero disparo a BrowseComp con un aumento del +5,3%. La habilidad nunca fue diseñada para BrowseComp. Simplemente funcionó ahí. Eso sugiere que lo que se está evolucionando es algo más parecido a una estrategia de ejecución generalizable que a un ajuste de prompt muy específico.
Aún no tengo muy claro qué pensar de eso. Pero lo he anotado.
El límite que ambos periódicos alcanzaron
Aquí es donde bajé bastante el ritmo.
Ambos artículos demostraron avances reales y reproducibles. Y ambos, leídos con atención, chocan contra el mismo muro en aproximadamente el mismo punto. El muro no es exactamente técnico — es arquitectónico.
Alcance de agente único
Cada habilidad evolucionada en ambos estudios reside dentro del contexto de ejecución de un agente. Prácticamente: una carpeta en el sistema de archivos local del agente, un artefacto versionado con alcance a la sesión de ese agente.
Cuando el agente es reemplazado, actualizado o redeployado, la evolución no se transfiere a menos que alguien la migre explícitamente. No hay un mecanismo de herencia incorporado en la configuración de investigación. La evolución es real. La persistencia es frágil.
Sin Propagación en Red
Cada nuevo agente, en ambos artículos, inicia su propio ciclo de evolución desde cero.
Piensa en lo que eso significa a cualquier escala de despliegue razonable. Diez agentes ejecutando ciclos al estilo EvoSkill producen diez historias de evolución separados. Esas historias no se fusionan. No resuelven conflictos. La ganancia acumulativa que hace que los resultados dentro de un agente sean tan llamativos — esa trayectoria de 32% → 75% — se reinicia a cero para cada nuevo agente que se active.
La mejora es local. El punto de partida es siempre el mismo.
Lo Que los Artículos Dejaron Abierto Explícitamente
EvoSkill señala esto directamente como trabajo futuro, no como un descuido: bibliotecas de habilidades compartidas donde las habilidades descubiertas en una tarea son navegables, componibles y reutilizables por otros agentes y usuarios.
Esa frase importa. Los investigadores no pasaron por alto este problema — lo nombraron. Es una pregunta de investigación abierta, no un detalle de implementación esperando ser lanzado. El problema de generación (¿pueden los agentes evolucionar habilidades mejores?) tiene ahora una respuesta empírica sólida. El problema de propagación (¿cómo se mueven habilidades validadas y evolucionadas entre agentes a escala?) no la tiene.
Lo Que los Artículos Dejan Abierto en la Capa de Sistemas
Quiero ser cuidadoso aquí, porque esta sección se puede malinterpretar fácilmente como un anuncio de producto. No lo es. Es una cuestión de ingeniería, y creo que vale la pena tomarla en serio por sus propios méritos.
La Brecha Entre Evolución Local y Herencia Compartida
Las habilidades auto-evolutivas resuelven un problema de manera clara: para un solo agente ejecutando tareas repetidas, la evolución automatizada produce mejores artefactos de ejecución que la autoría humana. Eso ahora está bien respaldado.
Lo que no resuelven: el problema de propagación. ¿Cómo se mueve una habilidad validada y evolucionada entre agentes? ¿Cómo evalúa una red si una habilidad dada es confiable antes de permitir que se propague? ¿Cómo se acumulan las señales de aptitud — evidencia de que una habilidad realmente funciona en diversas tareas y modelos — a una escala mayor que la historia de una sesión de un agente?
Estas no son preguntas retóricas. Son la brecha entre un resultado de investigación y un primitivo de infraestructura desplegable.
Lo Que Un Protocolo a Nivel de Red Necesitaría Manejar
Si estuvieras diseñando infraestructura para cerrar esta brecha — y me refiero a diseñarla genuinamente, no a hacer marketing — necesitarías como mínimo:
- Una capa de validación: habilidades evolucionadas evaluadas por calidad antes de la propagación, no después
- Un modelo de ciclo de vida: seguimiento de promoción, rechazo y revocación a lo largo de la historia de la habilidad
- Un mecanismo de obtención: agentes recuperando capacidades probadas sin reconstruirlas desde cero
- Un enfoque de resolución de conflictos: cuando dos habilidades evolucionadas de manera independiente para la misma tarea divergen, ¿cómo arbitra el sistema?
Ninguno de estos problemas está resuelto por la arquitectura EvoSkills o EvoSkill. Ambos artículos son explícitos al respecto. El Protocolo de Contexto de Modelos aborda la conectividad de herramientas en la capa de interfaz del agente, pero no define un ciclo de vida de evolución o herencia de habilidades. Estos son problemas genuinamente separados en distintas capas de la pila.
Para contexto sobre cómo se está abordando más ampliamente la compartición de capacidades de los agentes, vale la pena leer la especificación del protocolo de Agente a Agente (A2A) de Google, que define patrones de comunicación entre agentes, aunque la semántica de propagación de habilidades queda fuera de su alcance.
Por qué esta brecha es importante para los equipos de desarrollo
Un equipo que despliega diez agentes ejecutando bucles de evolución estilo EvoSkill obtiene diez repositorios de habilidades separados. Actualmente no existe una forma definida de:
- Fusionar esos repositorios
- Identificar cuáles habilidades evolucionadas son más confiables
- Evitar que habilidades evolucionadas de menor calidad se propaguen a otros agentes
- Rastrear qué versión de una habilidad sigue siendo válida a medida que cambia el modelo subyacente o el contexto de la tarea
Ese es un problema de infraestructura sin resolver. No es menor.
Qué significa esto para cómo construir flujos de trabajo de agentes ahora
No creo que la respuesta correcta a todo esto sea paralizarse. La investigación es lo suficientemente clara en algunos aspectos como para actuar ahora.
Dejar de escribir habilidades a mano para tareas complejas
En esto me siento bastante seguro.
Para tareas profesionales de múltiples pasos —análisis de documentos, investigación web, cadenas de razonamiento estructuradas— los resultados de EvoSkills y EvoSkill sugieren que la evolución automatizada produce mejores artefactos de ejecución que la autoría humana. No marginalmente mejores. Sustancialmente mejores, a través de múltiples modelos y de manera que se transfieren a nuevas tareas.
La documentación de LangChain sobre memoria de agentes y andamiaje de habilidades ofrece una base razonable para pensar en dónde se pueden introducir bucles de evolución en arquitecturas de agentes existentes. La versión corta: si todavía estás afinando manualmente las instrucciones de habilidades para tareas complejas y te preguntas por qué el rendimiento se estanca, ese estancamiento puede ser estructural, no solucionable mediante iteración.
Piensa en Dónde Viven las Habilidades Evolucionadas
Una habilidad evolucionada local que se mantiene local es un activo privado. Útil, pero limitado.
La comunidad investigadora está trabajando activamente en lo que viene después: capacidades validadas, compartibles y heredables a escala de red. El marco AutoGen de Microsoft Research es uno de los proyectos de código abierto más maduros que exploran patrones de coordinación multiagente, y su desarrollo continuo merece seguimiento, especialmente respecto a cómo maneja la transferencia de capacidades evolucionadas entre agentes.
Por ahora, la implicación práctica es: diseña tus ciclos de evolución pensando en la portabilidad, incluso si la infraestructura de portabilidad aún no existe completamente. Eso significa registrar las versiones de habilidades evolucionadas, rastrear qué benchmarks de evaluación aprobaron y mantener los artefactos de evolución separados del tiempo de ejecución del agente.
Preguntas que Vale la Pena Hacer Antes de Construir
Antes de comprometerte con una arquitectura de agente particular para un nuevo proyecto, creo que estas preguntas merecen reflexión:
- ¿Dónde vivirán las habilidades evolucionadas después de que termine la sesión? Si la respuesta es "en el sistema de archivos local del agente sin una ruta de exportación", estás construyendo un activo privado sin camino hacia un valor compuesto.
- ¿Quién las valida antes de que otros agentes las usen? Los benchmarks de validación automatizados son una respuesta; las revisiones humanas son otra. Ninguna es sin costo.
- ¿Cómo rastreas qué versión de una habilidad sigue siendo confiable? A medida que el modelo subyacente se actualiza y el contexto de la tarea cambia, una habilidad que funcionó en febrero puede no funcionar en agosto. El rastreo de versiones y la reevaluación no son opcionales si estás construyendo algo que tenga que funcionar durante meses.
La investigación de OpenAI sobre el uso de herramientas y patrones de llamadas a funciones es relevante aquí para entender cómo se registra y rastrea la invocación de habilidades a nivel de API, lo cual es un prerequisito para cualquier seguimiento significativo de la confiabilidad de habilidades.
Preguntas Frecuentes
¿Cuál es la diferencia entre una herramienta y una habilidad en los sistemas de agentes?
Una herramienta es típicamente una capacidad discreta con una interfaz de entrada/salida definida: una llamada a función, un endpoint de API, un ejecutor de código. Una habilidad es un artefacto de orden superior: un flujo de trabajo estructurado, una estrategia de razonamiento o un patrón de ejecución de múltiples pasos que orquesta el uso de herramientas. Las herramientas son atómicas. Las habilidades son composicionales. Los artículos EvoSkills y EvoSkill apuntan específicamente a la capa de la habilidad: la parte que determina cómo un agente aborda una tarea, no solo qué capacidades puede invocar.
¿En qué se diferencia EvoSkills de EvoSkill?
EvoSkills se centró en la evolución de habilidades independientes de la tarea, evaluadas en SkillsBench, un punto de referencia multidominio que cubre diversas tareas profesionales. Mostró una mejora en la tasa de aprobación del 32% → 75% a lo largo de cinco rondas y demostró que las habilidades evolucionadas superan a las curadas por humanos desde la tercera ronda. EvoSkill se centró más estrechamente en tareas de QA intensivas en conocimiento (OfficeQA, SealQA) y enfatizó la transferencia cero-shot entre tareas, es decir, el hallazgo de que las habilidades evolucionadas para SealQA se transferían a BrowseComp sin necesidad de reentrenamiento. Ambos artículos demuestran que la evolución automatizada supera la autoría humana; difieren en el alcance y en las propiedades específicas de transferencia que caracterizan.
¿Se pueden usar las habilidades evolucionadas de EvoSkills o EvoSkill con cualquier agente?
Los resultados de transferencia entre modelos (+35pp a +44pp en seis LLMs) sugieren que las habilidades evolucionadas codifican información estructural de la tarea que se generaliza a diferentes arquitecturas de modelos. En la práctica, "cualquier agente" es demasiado fuerte: ambos artículos operaron dentro de marcos y benchmarks específicos. La afirmación más precisa es: las habilidades evolucionadas bajo un modelo se transfirieron de manera significativa a otros modelos en evaluaciones controladas. La portabilidad en entornos reales entre diferentes agentes sigue siendo una cuestión abierta de implementación.
¿Qué es SkillsBench y qué tan confiables son sus resultados?
SkillsBench es un benchmark introducido en el artículo de EvoSkills diseñado para evaluar la calidad de las habilidades de los agentes en tareas profesionales de múltiples pasos. Está estructurado para medir tanto la finalización de la tarea como la calidad del artefacto de la habilidad en sí, no solo si el agente obtuvo la respuesta correcta, sino si la habilidad que utilizó se generalizaría. Como con cualquier benchmark de investigación, los resultados deben interpretarse en contexto: SkillsBench fue diseñado por el mismo equipo que creó EvoSkills, lo cual vale la pena considerar al evaluar la independencia de la evaluación. La validación cruzada de benchmarks (la transferencia SealQA → BrowseComp) proporciona alguna señal externa, pero el campo se beneficiaría de marcos de evaluación más diversos e independientes.
¿Qué necesitaría realmente una biblioteca de habilidades compartida para funcionar a escala de red?
Como mínimo: un mecanismo de validación que pruebe las habilidades evolucionadas antes de que se propaguen, un sistema de versionado y ciclo de vida que rastree la promoción y revocación, una capa de indexación semántica para que los agentes puedan identificar habilidades relevantes sin una búsqueda exhaustiva, y un enfoque de resolución de conflictos para cuando habilidades evolucionadas independientemente para la misma tarea divergen. Los problemas más difíciles son la gobernanza (¿quién decide cuándo una habilidad es "suficientemente buena" para compartir?) y la degradación de la calidad (¿cómo se detecta cuando una habilidad previamente confiable se deteriora a medida que cambia el contexto?). Ningún artículo aborda estas preguntas — se señalan explícitamente como trabajo futuro.
¿Qué significa la transferencia de habilidades zero-shot en el contexto de EvoSkill?
La transferencia zero-shot significa que una habilidad evolucionada para una tarea se aplicó a una tarea diferente sin entrenamiento adicional, ajuste fino o adaptación. En el caso de EvoSkill: las habilidades evolucionadas en SealQA se aplicaron directamente a BrowseComp, una tarea de investigación basada en la web con estructura y dominio diferentes, y produjeron un aumento del +5.3% sin ningún reentrenamiento específico de la tarea. "Zero-shot" aquí se refiere al artefacto de la habilidad, no al modelo subyacente. El modelo no se está ajustando; el prompt/flujo de trabajo de la habilidad se reutiliza tal cual. Que la reutilización produjera ganancias positivas sugiere que la habilidad codificó algo sobre la estructura de las tareas de investigación que generalizó, en lugar de algo específicamente limitado al formato de SealQA.
Publicaciones anteriores:
