Un agente que mejora por sí solo: cómo funciona la autoevolución de Orkas

La mayoría de los asistentes de IA son de "usar y olvidar". Hoy corriges un hábito y mañana repite el mismo error; la semana pasada le enseñaste el flujo de trabajo particular de tu equipo y esta semana actúa como si nunca hubiera oído hablar de él. Cada conversación empieza de cero y, por inteligente que sea el modelo, sigue siendo una persona inteligente con amnesia.

Orkas busca algo distinto: permitir que el agente aprenda de su propio uso cotidiano, extrayendo lo esencial de las experiencias recurrentes para aplicarlo por sí solo la próxima vez. En pocas palabras: se vuelve más útil cuanto más lo usas, y esa "utilidad" evoluciona hacia ti, tus preferencias y tu ámbito, en lugar de ajustarse a algo que el proveedor del modelo haya predefinido para todo el mundo.

Este artículo explica cómo está construido ese mecanismo. No es tan simple como "hacer que el modelo recuerde la conversación": detrás hay un ciclo completo: observarse → decidir si reflexionar → reflexionar de verdad → plasmar las conclusiones en algo reutilizable → volver a usarlo la próxima vez. Lo recorreremos parte por parte.

Lo más importante primero: todo lo que se describe a continuación —toda la "observación", el "registro" y la "reflexión"— ocurre íntegramente en tu propio dispositivo. Los datos de ejecución, las habilidades, lo que el agente sabe de sí mismo: todo se guarda localmente como archivos comunes. Nada de ello se sube a los servidores de Orkas ni se utiliza para análisis entre usuarios o para entrenar modelos. "Autoevolución" significa que un programa lee sus propios registros de ejecución localmente y se mejora localmente, no que recopila tus datos. Esta experiencia nunca sale del equipo y solo está a tu servicio, en este único equipo.

El ciclo, de principio a fin

uso real, una y otra vez
      │  registro local: qué herramientas se llamaron, si hubo errores o correcciones
      ▼
   se acumulan señales
      │  señales extraídas de la conversación donde reside, todas conservadas en el dispositivo
      ▼
  decidir si se debe reflexionar
      │  puntuación ponderada de las señales; solo se activa al superar un umbral; los problemas de red no cuentan
      ▼
   reflexionar en segundo plano
      │  no en cada turno: periódicamente, seleccionando los agentes que cumplen los criterios
      ▼
  se condensa en dos cosas
      │  ① "habilidades" reutilizables   ② una "comprensión" de sí mismo
      ▼
  se incorpora automáticamente en el siguiente turno
      └──────────► volver al principio y continuar

Cada paso de este ciclo tiene sus matices. Los puntos en los que resulta más fácil equivocarse son precisamente los dos pasos que a primera vista parecen más sencillos: cuándo reflexionar y qué registrar al hacerlo. Empecemos por el principio.

Paso 1: observarse con un costo casi nulo

Para aprender de la experiencia, primero necesitas "experiencia" que examinar. Al terminar cada ejecución del agente, el programa contabiliza —localmente, en ese mismo momento— unos pocos datos sencillos sobre la ejecución: aproximadamente cuántas herramientas se llamaron en ese turno, si hubo algún error, si fue transitorio (como un problema de red) o un error real, y si el usuario lo corrigió en el momento. Solo unos cuantos conteos e indicadores, todos calculados en el equipo, sin llamar a ningún modelo ni enviarlos a ninguna parte.

Esto importa porque no genera ningún gasto en el modelo. Los datos se cuentan directamente a partir del registro de conversación del turno actual; no hace falta realizar una llamada adicional al modelo solo para "analizarse a sí mismo". Si cada turno requiriera otra llamada al modelo para hacer introspección, el costo y la latencia serían insoportables y el mecanismo nunca llegaría a lanzarse.

El indicador de "si hubo corrección o no" tiene cierto interés. Es un juicio local puramente heurístico, estimado al buscar coincidencias con algunas expresiones del mensaje en tu dispositivo: expresiones en chino como "不对" / "应该是" / "重新", y en inglés como wrong, actually, instead. No pretende ser preciso: es solo una señal, no un veredicto, y un falso positivo ocasional es aceptable porque después se pondera junto con otras señales; nada se decide solo a partir de ella.

Paso 2: cuándo merece realmente la pena reflexionar

Creo que esta es la parte de todo el mecanismo que demuestra más cuidado en el diseño.

El enfoque ingenuo es "reflexionar una vez acumuladas N ocurrencias". Pero es rudimentario: tres tiempos de espera de red agotados seguidos y tres correcciones consecutivas del usuario son claramente cosas distintas y no deberían tratarse igual. Orkas utiliza una puntuación ponderada de múltiples señales: cada fenómeno relevante es una señal con un peso; se suman los pesos de las señales activadas en ese turno y solo se reflexiona si el total supera un umbral (0.7 de forma predeterminada).

Las señales principales son, aproximadamente, estas:

Por ejemplo: un turno con una corrección del usuario (0.9) y cierta complejidad (0.5) suma 1.4, muy por encima de 0.7, así que se reflexiona; un turno que solo es algo complejo (0.5) no llega al umbral y se deja pasar. La ponderación también refleja una decisión de criterio: una corrección directa del usuario recibe el peso más alto, 0.9, porque es la respuesta con mayor relación señal/ruido que existe: el usuario ha dicho claramente que te equivocas, por lo que es muy probable que merezca la pena registrarlo.

La excepción crucial

En toda la lógica de puntuación hay una regla que considero decisiva para que este mecanismo "aprenda lo correcto": los errores transitorios nunca cuentan.

Tiempos de espera de red agotados, conexiones interrumpidas, límites de frecuencia: son problemas del entorno, no carencias en la capacidad del propio agente. Si no se excluyen, ocurre algo perjudicial: una herramienta falla por un problema de red fortuito y el mecanismo de reflexión lo registra como "esta herramienta no es fiable, úsala menos", o incluso estropea o elimina una habilidad que funcionaba perfectamente. A partir de entonces, el agente ha aprendido una lección equivocada y ese error lo acompaña.

Por eso, las señales de "recuperación de un error", "habilidad ineficaz" y "se encontró una debilidad conocida" excluyen explícitamente los errores puramente transitorios. Las instrucciones de reflexión también repiten el recordatorio: los errores de red son del entorno, no los registres como debilidades ni modifiques las habilidades relacionadas. Lo que más debería temer un sistema que se mejora a sí mismo no es aprender despacio, sino aprender en la dirección equivocada. Esta excepción protege precisamente contra eso.

Paso 3: la reflexión ocurre en segundo plano, sin interrumpirte

Una trampa fácil: en cuanto detectas que "es hora de reflexionar", detenerte y hacerlo en ese mismo momento. Eso hace que el agente parezca trabarse de vez en cuando, desviándose para "meditar sobre la vida": una mala experiencia.

Orkas traslada la reflexión al segundo plano, con una periodicidad fija. Las reglas de programación son, aproximadamente:

• Iniciar un ciclo de reflexión cada cierto tiempo (por ejemplo, algo más de doce horas).
• Exigir una espera mínima entre dos reflexiones del mismo agente (unas horas), para que no se ejecute con demasiada frecuencia.
• Pero, si lleva demasiado tiempo sin reflexionar (por ejemplo, más de una semana), forzar una reflexión para que no se posponga indefinidamente.
• Limitar el número de agentes seleccionados por ciclo para no repartir demasiado los recursos de una sola vez.

Hay un pequeño detalle de diseño que me gusta, llamado filtro de cambios pendientes: al comenzar un ciclo, primero se comprueba si el agente tiene alguna novedad desde su última reflexión, como señales nuevas o registros de conversación actualizados. Si no ha habido ningún cambio, se omite esta vez y no se desperdicia una reflexión (que tiene un costo de modelo). Es sencillo, pero ahorra mucho en la práctica.

Paso 4: cómo funciona realmente la reflexión

Cuando de verdad llega el momento de reflexionar, el proceso es este: primero se organiza la actividad reciente en un "paquete"; después se combina con unas instrucciones cuidadosamente redactadas y se entrega al modelo para que lo lea y lo resuma.

El paquete tiene un presupuesto: se toman, como máximo, unas pocas conversaciones recientes, se añaden algunas clases de eventos del sistema, se intercalan cronológicamente y se mantiene el total por debajo de un límite de tokens (por ejemplo, algo más de diez mil). No se vuelca todo el historial: no cabría y la relación señal/ruido sería mala.

Lo que realmente exige cuidado son las instrucciones. Se pide al modelo que produzca órdenes ejecutables, no "descripciones". La diferencia parece pequeña, pero importa muchísimo. Comparemos:

✗ "Las respuestas del agente a veces son demasiado extensas; tenlo en cuenta."

✓ "Al responder preguntas sobre oficinas de gestión patrimonial familiar, nunca superes los 5 puntos en una lista."

✗ "El usuario parece preferir respuestas concisas."

✓ "Al responder en el contexto de una oficina de gestión patrimonial familiar, presenta siempre primero la conclusión y después el razonamiento."

Las instrucciones orientan explícitamente al modelo hacia estructuras de "nunca / siempre / cuando-entonces" con condiciones de activación concretas. La razón es práctica: una nota que diga "procura ser conciso" no le indica al agente ninguna acción concreta la próxima vez que la lea, mientras que "nunca superes los 5 puntos en una lista" se puede seguir directamente. Para que la mejora autónoma sea útil, lo que se extraiga debe ser una instrucción aplicable, no una obviedad correcta.

Después de reflexionar, el modelo puede hacer varias cosas: crear o modificar una habilidad, actualizar lo que sabe de sí mismo o, si realmente no hay nada que merezca registrarse en ese período, limitarse a decir "nada que guardar". Permitirle no hacer nada es, en sí mismo, una decisión de diseño importante: no hay que forzar un resultado de aprendizaje, para evitar acumular un montón de ruido inútil.

El resultado se concreta en dos cosas

El resultado de la reflexión se guarda en dos lugares.

Uno son las habilidades. Cada habilidad es un documento Markdown con metadatos: un bloque de cabecera que registra el nombre, la descripción, las fechas de creación y actualización, cuántas veces se ha modificado y cuándo se usó por última vez, seguido de los pasos o puntos clave:

---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---

## Steps
1. ...
2. ...

Guardar las habilidades como archivos es una elección práctica: una persona puede leerlas y editarlas directamente, sin que queden encerradas en una base de datos opaca.

El otro es el conocimiento de sí mismo. Esta parte se parece más a una nota que el agente se escribe a sí mismo, dividida en dos: una recoge "en qué soy bueno y dónde suelo tropezar"; la otra, "las estrategias que he desarrollado para este usuario y este ámbito". Ambas tienen un límite de longitud que las obliga a ser concisas: no importa que sean más largas, sino más fieles a la realidad. Al inicio de la siguiente conversación, este contenido se incorpora a las instrucciones del sistema, de modo que el agente llega con "conocimiento de sí mismo".

Las habilidades no solo se escriben

Si solo se crean habilidades, con el tiempo se acumula un depósito de chatarra. Por eso las habilidades tienen un ciclo de vida completo.

Más allá de crearlas, la operación más habitual es en realidad aplicar modificaciones puntuales: cambiar un pequeño fragmento de una habilidad existente en lugar de desecharla y reescribirla. Cada modificación incrementa un contador y actualiza la fecha de modificación. Esto permite que una habilidad crezca gradualmente con la experiencia, en vez de reescribirse por completo en cada turno.

También hay un límite de cantidad. El número total de habilidades está limitado (por ejemplo, a 200); una vez alcanzado, añadir una nueva elimina una antigua mediante LRU (la utilizada menos recientemente) para hacer espacio. La eliminación tiene una preferencia: primero se descartan las que nunca se han usado desde su creación. Una habilidad que nunca se ha leído probablemente no se extrajo bien desde el principio, y conviene que deje espacio.

Cada vez que el agente lee una habilidad, se actualiza su "fecha de último uso". Esta marca de tiempo sirve tanto para decidir qué elimina LRU como para que el mecanismo local distinga qué habilidades se usan de verdad y cuáles solo ocupan espacio.

Cómo saber si una habilidad es realmente útil

Este es el paso que muchos sistemas de "aprendizaje automático autónomo" se saltan por comodidad: aprendió algo, pero ¿sirve de algo? Orkas lo convierte en unas pocas métricas, localmente. Estas métricas se calculan para uso del propio mecanismo de evolución del equipo —decidir qué habilidad revisar o eliminar— y tampoco salen nunca de este equipo.

El mecanismo es el siguiente: al comienzo de cada turno, las habilidades disponibles aparecen en el índice de las instrucciones del sistema; eso cuenta como una "impresión". Si el agente lee realmente una habilidad en ese turno, cuenta como una "invocación". Al comparar ambas se obtiene la primera métrica:

• Tasa de invocación = invocaciones / impresiones. Una habilidad que permanece ahí día tras día sin que nadie la use tiene una tasa de invocación baja, lo que significa que es inútil o que su descripción no permite saber cuándo utilizarla.
• Tasa de edición posterior al uso = proporción de veces en que se invocó una habilidad, pero el usuario editó después el resultado a mano. Un valor alto significa que lo producido por la habilidad no se ajusta del todo al gusto del usuario.
• Tasa de ineficacia = proporción de veces en que se invocó una habilidad, pero el turno terminó con un error no transitorio. Un valor alto sugiere que puede haber algún problema en la propia habilidad.

Aquí vuelve a aparecer aquella excepción: al calcular la tasa de ineficacia, los errores transitorios no cuentan, y tampoco los turnos que el usuario detuvo manualmente a mitad de camino. No se puede penalizar una habilidad que funciona perfectamente por un problema de red puntual.

Con estas pocas cifras, las habilidades pasan de "acumularse en una caja negra" a ser "algo que se puede evaluar y optimizar". Decidir qué habilidad revisar o eliminar deja de ser una cuestión de intuición.

Cerrar el ciclo

Al unir todo lo anterior, un ciclo completo funciona así:

El agente trabaja en tareas reales, registra localmente los datos de ejecución y marca las señales sobre la marcha. Cuando llega el ciclo de reflexión en segundo plano, selecciona los agentes que tienen actividad nueva y han cumplido su tiempo de espera, organiza la actividad reciente de cada uno en un paquete y hace que el modelo la revise a la luz de su conocimiento actual de sí mismo: combina lo que debe combinarse, retira lo que debe retirarse y convierte en nuevas habilidades lo que merece extraerse. El resultado de la revisión se convierte en habilidades y conocimiento de sí mismo. En la siguiente conversación, esas habilidades se incorporan al índice de instrucciones y el conocimiento de sí mismo, a las instrucciones del sistema; así, el agente vuelve con lo aprendido en la ronda anterior. A su vez, esta ronda produce nuevas métricas y señales que se devuelven al inicio.

El ciclo continúa, ronda tras ronda. No todas las rondas traen un gran salto, pero la dirección es única: entenderte mejor y repetir menos los mismos errores.

Algunas decisiones y sus contrapartidas

Al repasar este mecanismo, varias decisiones resultan clave.

La introspección debe ser barata. Para observarse, utiliza métricas sin costo de modelo; la reflexión realmente costosa se traslada al segundo plano, se ejecuta con poca frecuencia y pasa primero por la comprobación de cambios pendientes. Limitar estrictamente la parte "costosa" permite que todo el mecanismo funcione en la práctica.

Es mejor no aprender que aprender mal. La excepción para errores transitorios, permitir que la reflexión "no guarde nada" y escribir órdenes ejecutables en lugar de descripciones vagas apuntan al mismo criterio: para un sistema que se mejora a sí mismo, aprender en la dirección equivocada es mucho más peligroso que aprender despacio.

Lo aprendido debe ser visible, editable y estar en tus manos. Las habilidades son archivos de texto sin formato, el conocimiento de sí mismo es una nota de texto sin formato y la eficacia de las habilidades se puede comprobar mediante métricas. Todos estos archivos están en tu propio equipo, no en la nube. No hay ninguna caja negra; una persona puede abrirlos y ajustarlos en cualquier momento.

Hay que poner freno al aprendizaje. Límites de cantidad, eliminación mediante LRU, límites de longitud: sin ellos, el "aprendizaje continuo" acaba convirtiéndose, tarde o temprano, en "crecimiento desmedido continuo". Olvidar, descartar y depurar importan tanto como recordar.

Para terminar

En esencia, la autoevolución de Orkas añade un ciclo lento al agente: el ciclo rápido es la respuesta inmediata de cada conversación; el lento consiste en revisar periódicamente lo ocurrido y convertir la experiencia en algo utilizable la próxima vez. Lo difícil no es "hacer que el modelo recuerde", sino las decisiones de ingeniería que suelen pasarse por alto: cómo distinguir qué experiencias merece la pena registrar, cómo evitar que un fallo fortuito lo desvíe, cómo hacer que lo aprendido sea realmente ejecutable y cómo depurarlo antes de que crezca en exceso.

En conjunto, esas decisiones convierten "se vuelve más útil cuanto más lo usas" de una frase publicitaria en un mecanismo que realmente funciona. Un asistente que aprende de ti —y que no aprende lo equivocado— quizá se acerque más a lo que la mayoría de las personas quiere de verdad que uno que simplemente sea más inteligente.

Para conocer los agentes especialistas en los que se apoya este ciclo lento, explora el equipo de agentes de Orkas.