WikiSkill: cómo los agentes evolucionan SKILL.md con experiencia

WikiSkill es una arquitectura de evolución de skills que transforma trazas de ejecución de agentes en evidencia persistente y usa esa evidencia para proponer y validar cambios en skills reutilizables. En el promedio de cinco benchmarks del paper, Qwen-3.5-9B con WikiSkill obtuvo 47,4 %, mientras que Qwen-3.6-27B, de mayor tamaño, obtuvo 39,4 % sin skills. No hubo fine-tuning.

Fecha de investigación: 19 de septiembre de 2026. La fuente es un preprint de arXiv de investigadores afiliados a Google Research y Virginia Tech, no un estudio de producción revisado por pares. El resultado importa porque convierte la experiencia en un activo de software externo y comprobable, en lugar de asumir que aumentar el modelo es la única vía de mejora. Paper de WikiSkill y registro de autores

Esta página cubre una intención concreta: qué demuestra el paper de WikiSkill y cómo adaptar su arquitectura de wiki persistente a la evolución de SKILL.md. Para comparar Agent Skills, MCP, RAG y Custom GPTs, consulta nuestra comparativa de Agent Skills. Para manuales entre modelos sin una wiki del optimizador, lee la guía de transferencia de conocimiento entre agentes. Una wiki empresarial resuelve otro problema, explicado en la guía de wiki empresarial preparada para IA.

¿Qué es WikiSkill?

WikiSkill es un optimizador de bucle externo para skills procedimentales de agentes. El agente de tareas ejecuta ejemplos con los skills actuales. Un Wiki Maintainer convierte trazas correctas y fallidas en patrones duraderos. Un Skill Proposer lee esos patrones y propone un único cambio. Una puerta de validación conserva el cambio solo cuando mejora el rendimiento en ejemplos reservados.

La decisión clave es separar capas. Las trazas sin procesar siguen siendo evidencia. La wiki se convierte en un diagnóstico acumulado de lo que funciona, lo que falla y qué cambios ya fueron rechazados. El skill activo permanece lo bastante conciso para guiar la ejecución. Cuando un cambio propuesto falla, el skill vuelve a la versión anterior, pero la wiki conserva el experimento fallido para no tener que redescubrirlo.

Eso diferencia WikiSkill de pedir a un LLM que reescriba un prompt después de cada error. El sistema tiene un historial auditable, un conjunto de validación separado y dos memorias con ciclos de vida distintos: instrucciones reversibles e historial de aprendizaje persistente.

¿Cómo funciona la arquitectura de tres capas de WikiSkill?

El paper divide el espacio de trabajo en raw/, wiki/ y skills/. El agente de inferencia puede usar los skills activos para resolver tareas, pero no lee la wiki durante esas ejecuciones. El mantenedor y el proponente sí pueden inspeccionar la evidencia y la wiki. Esta restricción importa porque dar acceso directo a la wiki al agente de tareas redujo la calidad final de los skills en la ablación.

Cada iteración sigue una secuencia controlada: ejecutar tareas de entrenamiento, muestrear aciertos y fallos, actualizar la wiki, proponer una creación o edición atómica, ejecutar el candidato sobre tareas de validación y aceptar solo una mejora estricta. El paper usa hasta ocho iteraciones de evolución y publica promedios de tres ejecuciones completas e independientes. Método, tablas y limitaciones completas de WikiSkill

La palabra “wiki” puede confundir. No es un corpus RAG para el usuario ni un almacén de todos los documentos. Es memoria del optimizador: patrones compactos de causa raíz, trazas de soporte, diffs de propuestas y decisiones de aceptación que permiten que el siguiente cambio parta de evidencia acumulada.

¿Qué puntuación obtuvo WikiSkill en los cinco benchmarks?

WikiSkill logró el mejor promedio para cada modelo probado y superó al método de evolución de skills rival más fuerte por entre 3,3 y 12,0 puntos porcentuales. La suite incluyó matemáticas recientes, búsqueda web, manipulación de hojas de cálculo, preguntas sobre documentos largos y tareas interactivas con entorno.

Las ganancias no fueron uniformes. Qwen-3.6-27B mejoró 40,9 puntos en SpreadsheetBench y solo 11,6 en OfficeQA. Qwen-3.5-4B empeoró ligeramente en OfficeQA porque tuvo dificultades para ejecutar el flujo de búsqueda en contexto largo codificado en el skill. Por tanto, la conclusión útil no es “los skills siempre ayudan”. El conocimiento procedimental validado mejoró la mayoría de combinaciones evaluadas, pero ejecutar un skill sofisticado sigue dependiendo del modelo y de la tarea.

La comparación estuvo razonablemente controlada para un paper: todos los métodos empezaron con un conjunto vacío, el skill evolucionado se insertó en el prompt de inferencia y la significancia se comprobó con bootstrap pareado. Aun así, sigue siendo un estudio de benchmarks, no evidencia de menor coste, latencia o tasa de error en cualquier agente de producción.

¿De verdad un modelo de 9B superó a uno de 27B?

Sí en el promedio informado de cinco benchmarks, pero el titular necesita contexto. Qwen-3.5-9B con WikiSkill promedió 47,4 %, frente a 39,4 % de Qwen-3.6-27B sin skills. Ambos son Qwen, pero pertenecen a versiones diferentes además de tener tamaños distintos. El experimento no demuestra que cualquier modelo de 9B con cualquier skill supere a todos los modelos de 27B en cualquier carga.

Sí demuestra algo más útil para ingeniería: capacidad de modelo y contexto procedimental son palancas separadas. Un modelo pequeño con instrucciones comprobadas puede superar a uno grande obligado a redescubrir el proceso en cada ejecución. A la vez, escala y evolución fueron complementarias. El modelo de 27B obtuvo la mayor ganancia, con 23,9 puntos adicionales hasta 63,3.

Antes de pagar por un modelo mayor como opción predeterminada, congela un set de evaluación y compara cuatro variantes: modelo actual sin skill, modelo actual con skill manual, modelo actual con skill evolucionado y modelo mayor sin ese skill. Mide resultados aceptados, no solo precio por token. Una llamada barata no sirve si sus fallos generan reintentos o reparación manual.

¿Los skills evolucionados se transfieren entre modelos?

A menudo sí, y en algunos casos un skill evolucionado por otro modelo superó al skill propio del receptor. En SpreadsheetBench, Qwen-3.5-9B obtuvo 24,3 sin skill, 33,6 con su skill propio y 50,5 con un skill evolucionado por Qwen-3.6-27B. En ALFWorld, el mismo receptor pasó de 63,4 con su skill a 70,2 con el skill del modelo de 27B.

El resultado negativo es crucial. Un skill portable debe codificar un procedimiento general, no un truco para los hábitos de un modelo concreto. Trata cada transferencia como una nueva versión: vuelve a ejecutar la evaluación del receptor, compara contra ausencia de skill y skill propio, y rechaza la importación si degrada una categoría relevante aunque el texto parezca sensato.

Este hallazgo complementa el patrón de transferencia desde un modelo frontier a uno más barato. WikiSkill añade historial persistente del optimizador y un bucle de validación; no se limita a entregar notas de un modelo a otro.

¿Por qué la wiki persistente explica gran parte de la mejora?

La ablación más clara aisló la contribución de la wiki. Con Gemini-3.5-Flash y sin acceso del Skill Proposer a la wiki, el promedio de cuatro benchmarks fue 48,7 %. Al darle acceso a la wiki persistente, subió a 63,7 %, una mejora de 15,0 puntos. Dar acceso directo también al agente de inferencia redujo el valor a 60,9 %.

El resultado respalda una frontera arquitectónica limpia:

• La ejecución recibe el skill publicado. El agente de tareas debe demostrar que el propio skill basta.
• La optimización recibe el historial de evidencia. El proponente necesita fallos recurrentes, estrategias exitosas, diffs rechazados y resultados de validación.
• La publicación sigue bajo control. Una edición plausible no se convierte en instrucción de producción hasta mejorar una métrica reservada.

La wiki es útil porque, de otro modo, el historial del optimizador desaparece en conversaciones y lotes temporales de trazas. Convierte “ya lo intentamos” en estado inspeccionable. También reduce propuestas fallidas repetidas: el caso del paper registra un cambio rechazado contra bucles, usa esa evidencia en la siguiente iteración para crear una regla aceptada y la refina más adelante.

¿Qué no demuestra el paper de WikiSkill?

El paper justifica experimentos, no un despliegue ciego. Sus propias limitaciones marcan varias fronteras.

• No prueba recuperación de skills. Los skills activos se insertaron directamente en el prompt del sistema. Se aísla su calidad, pero no cómo elegir el correcto dentro de una biblioteca grande.
• La mejora estricta puede bloquear pasos intermedios. Cada parche aceptado debía superar inmediatamente el mejor resultado de validación. Una refactorización neutra que habilitase una mejora posterior sería rechazada.
• La wiki solo crece. No existe poda automática, retirada de contradicciones ni caducidad de evidencia.
• No evalúa horizontes muy largos. Hay herramientas multi-step y documentos extensos, pero no flujos de cientos de acciones o varias horas.
• Los sets de validación pequeños pueden introducir ruido. Tienen entre 10 y 40 ejemplos. Una puerta de producción necesita segmentos más representativos y repeticiones.
• No hay contabilidad completa de costes. El optimizador añade ejecuciones, una llamada del mantenedor, trabajo multi-turn del proponente y validaciones. Mejor puntuación no equivale automáticamente a menor coste.

Además, el estudio mantiene fijo el resto del harness. Contratos de herramientas, routing, permisos, memoria, ensamblaje de contexto y observabilidad siguen siendo problemas independientes. Usa un harness de agentes para controlar esas fronteras y el patrón de LLM como verificador independiente cuando un único score no representa toda la corrección.

¿Cómo pilotar una evolución al estilo WikiSkill?

Empieza con una tarea repetida cuyo éxito pueda medirse de forma independiente. La especificación de Agent Skills define SKILL.md como el archivo obligatorio dentro del directorio de un skill, con frontmatter para nombre y descripción y scripts o recursos opcionales. Ese contrato de archivos es una unidad práctica de publicación para un skill evolucionado. Especificación de Agent Skills

No optimices contra unos pocos ejemplos atractivos. La guía de evaluación de Agent Skills recomienda tests de activación y evaluaciones de calidad con resultados esperados. Para una evolución al estilo WikiSkill, añade segmentos de regresión, tareas adversariales y un test final congelado que el proponente nunca pueda ver. Guía de evaluación de Agent Skills

La seguridad forma parte del optimizador. Un documento recuperado envenenado, una salida de herramienta comprometida o una tarea maliciosa pueden compilarse en instrucciones duraderas. SkillJack muestra que un skill derivado de experiencia puede conservar una puerta trasera después de desaparecer la fuente envenenada. Etiqueta contenido no confiable, exige procedencia para cada patrón, ejecuta candidatos en sandbox, revisa cambios de permisos o red y no permitas que el mismo modelo proponga y autorice una ampliación de capacidad de alto impacto. Preprint SkillJack sobre envenenamiento persistente de skills

Nuestra checklist de evaluación y sandbox para agentes cubre los controles circundantes. El trabajo de Wavect en ingeniería de agentes de IA puede convertir un flujo repetido en una pipeline de trazas, wiki, skills y releases. Usa la checklist de QA antes del lanzamiento o compártenos el flujo y sus trazas de fallo actuales.

Nuestro veredicto: evoluciona el procedimiento antes de sustituir el modelo

La idea más valiosa de WikiSkill no es que un agente edite Markdown. Es que la mejora procedimental necesita una arquitectura de evidencia propia. Las trazas preservan lo ocurrido. Una wiki persistente compila causas recurrentes e intervenciones fallidas. Un skill conciso lleva a ejecución solo el procedimiento publicado. La validación decide si avanza.

El titular del benchmark es real: un Qwen de 9B con skills evolucionados superó a un Qwen de 27B sin skills en el promedio del estudio. El resultado profundo es que los modelos grandes ganaron aún más, la transferencia a veces funcionó y la wiki persistente explicó una parte importante de la mejora. Los skills no sustituyen calidad de modelo. Son un segundo eje de escalado.

El siguiente paso de producción es medible: selecciona una tarea repetida, congela la evaluación, versiona el SKILL.md actual, conserva trazas inmutables, propone parches atómicos y promueve solo mejoras demostradas. Prueba eso antes de convertir un modelo mayor en la respuesta predeterminada a cada fallo.