
WikiSkill es un framework de Google Research que da a un agente de IA una memoria persistente parecida a una wiki, para que deje de desechar lo aprendido tras cada tarea. Divide el espacio de trabajo del agente en tres capas: un registro en bruto de lo ocurrido, una wiki que destila esas ejecuciones en patrones de fallo documentados y estrategias ganadoras, y un conjunto de archivos de habilidades que el agente realmente lee. La wiki solo crece, mientras que las habilidades individuales se revierten si no mejoran una puntuación de validación.
Los resultados son reales. En cinco benchmarks, Gemini-3.5-Flash pasó de 49,5 % a 68,1 % de precisión media, y un modelo más pequeño con WikiSkill superó a uno mayor sin ninguna habilidad. Las habilidades incluso se transfieren entre modelos.
La salvedad honesta: esto no hace que el modelo sea más listo. Como lo expresó un medio, el agente "escribe mejores instrucciones para sí mismo" en lugar de aprender de verdad. Es un apaño, pero bien medido.
Si diriges un equipo de soporte, lo útil es el patrón, no el artículo. Un agente de IA que compila tu historial real de tickets en conocimiento reutilizable es exactamente lo que eesel AI ya hace para el helpdesk, y puedes simularlo con tus tickets pasados antes de que responda a un solo cliente.
Qué es realmente WikiSkill
La mayoría de los agentes de IA tienen amnesia. Les das una tarea, la resuelven, y todo lo que descubrieron por el camino, el truco ingenioso, el callejón sin salida en el que perdieron diez pasos, desaparece en cuanto termina la ejecución. La siguiente tarea empieza de cero. Eso está bien para algo puntual, pero es una forma pésima de mejorar en un trabajo que haces miles de veces.
WikiSkill es la respuesta de Google Research. Publicado en arXiv el 27 de agosto de 2026 por Liyan Tang, Cyrus Rashtchian y cuatro colegas, es un framework que co-evoluciona las habilidades de un agente junto con una base de conocimiento persistente, una "wiki", que se acumula a lo largo de las ejecuciones. La pregunta central de los autores es directa: ¿puede la experiencia de un agente compilarse en conocimiento persistente que apoye la evolución de habilidades a largo plazo?
Primero, una definición rápida, porque "habilidad" tiene aquí un significado específico. Una habilidad de agente es un módulo reutilizable basado en archivos, una carpeta organizada con un SKILL.md que contiene instrucciones de procedimiento y las condiciones para aplicarlas. Amplía lo que un agente puede hacer sin tocar los pesos del modelo. Investigaciones previas ya intentaron descubrir estas habilidades automáticamente a partir de ejecuciones de agentes. La aportación de WikiSkill es lo que se sitúa entre la experiencia en bruto y esas habilidades: una wiki estructurada y en crecimiento.

La idea tiene un linaje conocido. El artículo reconoce la perspectiva de "LLM Wiki" de Andrej Karpathy en 2026, el argumento de que deberíamos compilar la experiencia del modelo en conocimiento persistente y acumulativo en lugar de dejar que se disperse. elvis (@omarsar0), fundador de DAIR.AI, hizo la misma conexión cuando salió el artículo:
"This WikiSkill paper from Google is a must-read. At a high level, it shows the effectiveness of persistent agents, knowledge bases, and skills. @karpathy popularized LLM Wikis. But this paper provides an actual framework for how agents can tap into a wiki of skills that evolve."
Las tres capas: raw, wiki y skill
Todo el diseño se reduce a mantener separadas tres cosas que la mayoría de los sistemas mezclan: lo que ocurrió, lo que aprendiste y lo que haces a continuación. WikiSkill da a cada una su propia capa.

La capa Raw (raw/) es el diario. Almacena trazas de ejecución completas de cada ejecución: el razonamiento del agente, cada llamada a herramientas, cada resultado, la respuesta final. Es inmutable, así que nada se reescribe después. Es la materia prima de la que se construye todo lo demás.
La capa Wiki (wiki/) es donde la experiencia se convierte en conocimiento, y es el corazón del framework. Contiene un directorio de páginas de patrones, cada una documentando un modo de fallo o una estrategia exitosa con una solución concreta, además de un registro de evolución y un seguimiento del impacto de las habilidades. La regla fundamental: la wiki nunca se reinicia ni se revierte. Solo acumula. Incluso cuando falla un experimento con una habilidad, la lección queda escrita.
La capa Skill (skills/) es la parte que el agente realmente lee mientras trabaja. Cada carpeta de habilidad tiene un SKILL.md con las instrucciones y un PURPOSE.md que vincula la habilidad con los patrones de la wiki que la motivaron. A diferencia de la wiki, aquí las habilidades son reversibles. Un cambio que perjudica el rendimiento se revierte.
Esa división, memoria permanente frente a acción reversible, es lo ingenioso, y es fácil pasarla por alto. Aquí está la misma idea en imagen.

Cómo funciona el bucle de evolución
Cada ronda de aprendizaje ejecuta un bucle de cuatro pasos, y uno de ellos es realmente contraintuitivo.
- Inference Agent. Ejecuta las habilidades actuales sobre tareas de entrenamiento y produce las trazas en bruto. Cabe destacar que el artículo bloquea deliberadamente a este agente para que no lea la wiki durante el entrenamiento. Una ablación mostró que dejarle mirar la wiki aquí en realidad perjudica la calidad final de las habilidades, bajando la media de 63,7 % a 60,9 %. La hipótesis: si el agente obtiene sus respuestas de la wiki en lugar de las habilidades, sus trazas dejan de servir como evidencia para mejorar las habilidades.
- Wiki Maintainer. Lee una muestra de trazas exitosas y fallidas, hace un análisis de causa raíz de los fallos, extrae estrategias de los aciertos y lo escribe todo en la wiki como páginas de patrones.
- Skill Proposer. Un agente de varios turnos que parte del índice de la wiki y del historial en curso, y luego lee páginas de patrones concretas bajo demanda. Propone exactamente un cambio atómico, ya sea una habilidad nueva o una edición de una existente.
- Control y reversión. El conjunto de habilidades propuesto se puntúa en una partición de validación separada. Si supera al mejor en curso, se acepta; si no, se revierte. En ambos casos, la wiki conserva el registro de lo que se intentó.
El estudio de caso del propio equipo de Google lo concreta. En el benchmark ALFWorld, el primer intento del proposer de una habilidad "goal-directed-action" fue rechazado por ser demasiado abstracto. Como el rechazo y su razonamiento quedaron preservados en la wiki, la siguiente iteración escribió una habilidad más afilada y aceptada con una regla específica ("Never return an item to its origin location"), y la refinó aún más varias iteraciones después a medida que aparecían nuevas variantes de fallo.

Una ablación del artículo respalda por qué la wiki se gana su sitio: dar al Skill Proposer acceso a la wiki persistente elevó el rendimiento medio en los benchmarks de 48,7 % a 63,7 %, un salto de 15 puntos. La memoria no es decoración; es de donde viene la mayor parte de la mejora.
¿Funciona de verdad? Los números
Sí, y de forma consistente, que es lo que lo distingue de la habitual salvedad de las demos de investigación. El equipo probó cinco modelos en cinco benchmarks (matemáticas, búsqueda web, hojas de cálculo, preguntas y respuestas sobre documentos largos y tareas interactivas), cada uno promediado en tres ejecuciones completas.
| Modelo | Media, sin habilidades | Media, con WikiSkill |
|---|---|---|
| Qwen-3.5-4B | 26,2 % | 38,5 % |
| Qwen-3.5-9B | 29,9 % | 47,4 % |
| Qwen-3.6-27B | 39,4 % | 63,3 % |
| Gemma-4-31B | 41,3 % | 54,9 % |
| Gemini-3.5-Flash | 49,5 % | 68,1 % |
Fuente: Tang et al., 2026. Algunos saltos en benchmarks individuales fueron aún mayores: Gemini-3.5-Flash en el benchmark de matemáticas pasó de 33,0 % a 72,6 %, y Qwen-3.6-27B en hojas de cálculo subió de 40,8 % a 81,7 %.
WikiSkill también superó de media a todos los métodos competidores de evolución de habilidades (Trace2Skill, EvoSkill y SkillOpt) en los cinco modelos y, a diferencia de ellos, rara vez empeoró algún benchmark concreto. Esa fiabilidad es el titular discreto. Un método que ayuda de media pero fracasa en una de cada tres tareas es difícil de confiar en producción, y es la misma razón por la que los equipos de soporte se preocupan tanto de que las tasas de resolución de tickets con IA se mantengan en todos los tipos de consulta, no solo en los fáciles.
El hallazgo al que no dejo de volver: las habilidades pueden sustituir a la escala. Qwen-3.5-9B con WikiSkill (47,4 %) superó al mucho mayor Qwen-3.6-27B sin habilidades (39,4 %). El conocimiento procedimental y el tamaño bruto del modelo resultan ser complementarios, no intercambiables.

Habilidades que se mueven entre modelos
Este es el resultado que más atención recibió. Las habilidades desarrolladas por un modelo se transfieren a otros modelos y familias, y las habilidades transferidas con frecuencia superan tanto a no tener habilidades como a las habilidades autoevolucionadas del propio modelo. En ALFWorld, Qwen-3.5-9B alcanzó 70,2 % usando una habilidad que Qwen-3.6-27B había desarrollado, frente a 63,4 % con la suya. De pequeño a grande también funciona: las habilidades del diminuto Qwen-3.5-4B mejoraron al mucho mayor Gemma-4-31B en los benchmarks de matemáticas e interactivos.
Mark Kretschmann (@mark_k) señaló esto como lo más interesante:
"'WikiSkill' lets agents turn their own experience into persistent knowledge that compounds over time... Even more interesting: skills transfer between models. In some cases, a model performed better using skills learned by another model than skills it developed itself."
La lectura de los autores es que descubrir una buena habilidad y ejecutarla son dos capacidades distintas, y la autoevolución normalmente las confunde. Es un replanteamiento útil si estás eligiendo un LLM para trabajo de soporte: el mejor modelo ejecutando un manual no es automáticamente el mejor escribiéndolo.
La transferencia no es gratis, sin embargo. Las habilidades que incorporan apaños específicos de un modelo pueden resultar contraproducentes. Las habilidades de hojas de cálculo del diminuto Qwen-3.5-4B, llenas de trucos de Python de bajo nivel, redujeron a Gemini-3.5-Flash de 50,5 % a 18,1 %, porque limitaban a un modelo más potente a la hora de escribir código de extremo a extremo más limpio. Así que "las habilidades se transfieren" es una propiedad real, pero que conviene probar caso por caso en lugar de dar por supuesta.
La salvedad honesta: es un apaño, no aprendizaje real
Esta es la parte que la mayoría de la cobertura suaviza, y vale la pena verla con claridad. WikiSkill no hace que el modelo subyacente aprenda. Los pesos nunca cambian. THE DECODER lo dijo sin rodeos: el agente "doesn't truly learn in a continuous sense, which remains an unsolved problem." En cambio, "it writes better instructions for itself after each run and can pull them up the next time around." Su veredicto sobre el enfoque fue que es "not elegant, and it's probably more error-prone than real learning, but the study shows it's an effective workaround."
Ese enfoque es el correcto para llevarlo a cualquier decisión de compra. Un sistema así es tan bueno como el conocimiento que escribe y el filtro que lo controla. El artículo también es claro sobre los límites:
- Sin poda de la wiki. La wiki solo crece, así que en ejecuciones muy largas necesitará una forma de olvidar patrones obsoletos, que aún no existe.
- Control estricto. Una habilidad propuesta tiene que mejorar la puntuación de validación para conservarse, lo que descarta cambios neutros que quizá habrían dado fruto más adelante.
- Sin recuperación de habilidades probada. Para aislar la calidad de las habilidades, el estudio inyectó todas las habilidades directamente en el prompt en lugar de recuperar las relevantes, algo que importa cuando hay muchas.
- Sin código oficial. A septiembre de 2026, Google no ha publicado código de WikiSkill. Un desarrollador independiente lo reimplementó a partir del artículo, y señaló que el control de validación detectó dos habilidades dañinas en su ejecución, lo que corrobora que la comprobación de seguridad hace un trabajo real.
Nada de esto hace a WikiSkill menos interesante. Lo hace honesto, y una descripción honesta de lo que un sistema de IA hace y no hace es justo lo que busco antes de confiarle trabajo real, el mismo listón que aplicaría al sopesar la IA frente a los agentes humanos.
Qué significa esto para los agentes de soporte con IA
Quita los benchmarks y WikiSkill describe una forma que los equipos de soporte y CX deberían reconocer de inmediato: un agente que mejora de forma medible en un trabajo repetido al compilar su propia experiencia en conocimiento reutilizable y comprobable. Es un patrón en el que se apoyan las empresas que ya usan IA para soporte, no una curiosidad de laboratorio. Es el objetivo central.
elvis dio el mismo salto de la investigación a la práctica:
"The practical takeaway here is that we should all be thinking about how to build persistent knowledge bases across our companies and projects. And how to use that to upgrade and evolve our skills."
Una cola de soporte es el hogar ideal para este patrón. Tus tickets pasados son la capa raw. Tus macros, el centro de ayuda y los hilos resueltos son la wiki. Y la idea de "comprobar antes de aceptar un cambio" es lo único que la mayoría de los despliegues de soporte con IA se salta y luego lamenta, porque activan un bot y esperan lo mejor. Aquí es donde la investigación y la realidad de la automatización del soporte al cliente se encuentran: los equipos que ganan son los que miden antes de confiar, igual que el control de WikiSkill comprueba una habilidad antes de conservarla. También es la razón por la que la comparación honesta de costes entre agentes de IA y humanos siempre acaba en "mide primero la tasa de resolución".
Prueba eesel para un soporte que aprende de tus tickets
La razón por la que WikiSkill me resulta familiar es que el compañero de IA para helpdesk de eesel ya funciona con este principio. No es un chatbot genérico pegado a tu sitio; se entrena con tu conocimiento existente, tickets pasados, centro de ayuda y documentación, y se une a la cola dentro del helpdesk que ya usas, sea Zendesk, Freshdesk, Gorgias o Help Scout, a través de más de 1000 integraciones.
El diferenciador que se corresponde más directamente con el control de WikiSkill es la simulación. Antes de que un compañero de eesel responda a un solo cliente real, puedes ejecutarlo contra tus tickets históricos y ver cómo los habría gestionado, de modo que la tasa de resolución es un número que compruebas, no una promesa que aceptas por fe. Es la disciplina de "validar antes de aceptar", aplicada a tu propio historial de soporte. Puedes probar eesel gratis, sin llamada de ventas, y un cliente, Global Pay, informó de hasta un 80 % de ahorro de tiempo una vez en marcha.