Diseño de Habilidades para Agentes LLM

Hola a todos. Mi nombre es Minko Getschev. Soy líder de IA en el desarrollo web y multiplataforma en Google. Y hoy en esta presentación, me gustaría compartir con ustedes cómo pueden construir y diseñar habilidades para agentes que realmente funcionen. En mis presentaciones, generalmente me gusta comenzar con los primeros principios. Así que por eso voy a empezar presentando a los agentes y los bloques de construcción de los agentes. Veamos cómo se componen juntos para obtener el comportamiento que esperarías.

Vamos a analizar las habilidades y cómo encajan en el panorama. Después de eso, vamos a ver las mejores prácticas para crear habilidades. Y por último, pero no menos importante, vamos a ver la evaluación de habilidades y los bucles de auto-mejora para obtener mejores habilidades. Todos usamos sistemas agénticos todos los días, interactuando con ellos a través de la web, con Gemini o Cloud o chat GPT, o en nuestro entorno de desarrollo. Estos agentes funcionan de manera muy similar a ANR. Todos aceptan una solicitud del usuario, utilizan diferentes prompts y logran la ejecución de estos prompts a través de un conjunto de herramientas.

Utilizando un modelo de lenguaje grande como su cerebro. Tenemos control sobre las herramientas que estos modelos de lenguaje grandes tienen, y también podemos aumentar su contexto. Y probablemente la forma más popular ahora de aumentar las herramientas que tienen los agentes es a través de MCP. MCP tiene sus compensaciones que vamos a analizar en un momento. Pero en general, nos permite proporcionar un conjunto adicional de herramientas que pueden hacer que nuestros agentes sean más efectivos. Los patrones arquitectónicos comunes para los agentes son el bucle React, en el cual el agente consultaría con un modelo de lenguaje grande para ver qué debería hacer.

El modelo de lenguaje grande va a hacer una propuesta, y el agente la va a seguir. Tenemos plan y ejecución en los que creamos un plan al principio. Estoy seguro de que lo has visto en Cloud Codes. Estoy seguro de que lo has visto en Antigravity. Estamos haciendo el plan y luego ejecutándolo paso a paso.

Reflexión. Podemos reflexionar sobre este plan. Podemos revisitarlo con el tiempo. Y agentes basados en máquinas de estados, que están bastante bien de alguna manera. Son estados individuales codificados de manera rígida, y las transiciones entre ellos a menudo dependen de algún resultado no determinista, como una acción, que el agente realiza a través del modelo de lenguaje grande.

Y la gran mayoría de los agentes que estamos usando hoy en día, están usando un enfoque híbrido. Muchas de estas diferentes arquitecturas se combinan juntas. Pero para ver cómo los agentes usan habilidades y acciones o herramientas, quiero que miremos el bucle React, que es una especie de arquitectura agéntica clásica. Primero, recibimos el prompt del usuario, y lo concatenamos con algunas instrucciones del sistema. Después de eso, entramos en el bucle y recopilamos un resumen de todas las herramientas que tenemos disponibles en este momento.

Y le preguntamos al modelo de lenguaje grande, genial, aquí está nuestro contexto que tenemos. Este es el estado del mundo del que estoy al tanto. Y aquí están todas las herramientas que tengo disponibles. ¿Qué hago a continuación? Aquí, el modelo de lenguaje grande puede hacer dos cosas. En primer lugar, puede decirnos, está bien, has terminado. Ejecutaste tu tarea. Podemos terminar. O puede seleccionar herramientas que tenemos disponibles para llamarlas con argumentos específicos para avanzar en la ejecución de la solicitud del usuario. Si aún no hemos terminado, vamos a llamar a estas herramientas y el resultado de sus invocaciones lo vamos a añadir al contexto.

Observa que seguimos haciendo el contexto más y más grande. Seguimos agregando a este contexto. Así que en grandes bucles React, podemos experimentar caídas de contexto. Podrías estar pensando, sí, pero como Gemini tiene 1 millón de tokens, ventana de contexto. ¿Cómo podemos, como podemos hacer mucho trabajo hasta que alcancemos este límite. Bueno, todos los modelos modernos ahora mismo tienen ventanas de contexto realmente grandes. Algunos de ellos están esforzándose por llegar a una ventana de contexto infinita. Pero la verdad es que después de un cierto umbral, el rendimiento del modelo comienza a degradarse alrededor del 30 al 40 por ciento. Y vamos a experimentar regresión. Usualmente, muchos agentes están haciendo su propia compresión de contexto.

Así que no tenemos que pensar tanto en ello. Pero al final del día, si nos gustaría tener una ejecución eficiente de nuestros bucles agénticos, necesitamos ser conscientes de lo que ponemos en el contexto y deshacernos de las cosas que son innecesarias. Así que tomando todo esto en nuestra mente, agregándolo a nuestro contexto, ¿cómo hacemos a los agentes más poderosos de una manera reflexiva? Bueno, podemos mejorar el contexto cuidadosamente agregando solo información relevante, y podemos hacerlo a través de RAC o a través de habilidades. O alternativamente, también podemos proporcionar herramientas adicionales. De hecho, viste cómo podemos hacer eso con MCP. Y probablemente las dos formas más populares de hacer a los agentes más poderosos que he visto es a través de CLIs y MCPs y agregando habilidades útiles.

A menudo, las personas comparan MCP con simplemente agregar una herramienta CLI que el agente puede usar. Y personalmente encuentro que esta analogía es bastante relevante, especialmente porque MCP comenzó como esta forma universal de expandir las capacidades del agente, y ahora vemos que la gente ha sido un poco más escéptica al usar el protocolo de contexto del modelo por buenas razones.

Por ejemplo, los CLIs en comparación con los MCPs son mejores en la preservación del contexto. No hay sobrecarga de contexto debido a esquemas JSON muy verbales. Además, la autenticación y los permisos se manejan generalmente de manera más fácil con los CLIs porque podemos aprovechar las credenciales de usuario existentes y usar inicio de sesión único. MCP, el protocolo de contexto del modelo, utiliza un servidor MCP que necesita estar disponible, necesita estar en funcionamiento, necesita aceptar solicitudes. Nada de esto es válido para los CLIs.

Los CLIs simplemente existen allí como herramientas de línea de comandos que puedes llamar en cualquier momento. No tienes sobrecarga de infraestructura. Y además, son extremadamente fáciles de depurar ya que se ejecutan en el contexto del usuario. Son solo un script que puedes depurar y para el cual puedes escribir pruebas fácilmente. Y además de eso, los CLIs funcionan muy bien con habilidades.

Así que los CLIs son el mecanismo para lograr algo y las habilidades son el mecanismo para enseñarle al modelo o al agente cómo usar estos CLIs. Las habilidades del agente son simplemente instrucciones procedimentales sobre cómo enseñar a los agentes a hacer algo. Tienen tres partes principales, digamos tres piezas principales. Tenemos el skill.md, que es el punto de entrada principal. Esto es solo la instrucción. Usualmente, la mayoría de las habilidades se capturan honestamente solo en skill.md.

Tenemos scripts que son scripts deterministas que pueden ejecutarse. Pueden ser referenciados por skill.md para que el agente pueda llamarlos en lugar de seguir instrucciones procedimentales escritas en markdown. Y tenemos referencias y activos. La referencia y los activos son muy útiles cuando queremos mantener skill.md algo delgado y muy enfocado en instrucciones paso a paso. Podemos referenciar las referencias en skill.md.

Y así es como se ve skill.md. Es solo un archivo markdown con un YAML desde el principio que contiene la descripción y el nombre de la habilidad y las instrucciones procedimentales después de eso. Cuando hablo de habilidades, la gente a menudo las confunde con CLoT.md. Y estos sirven para propósitos muy diferentes. Primero, las habilidades son un estándar abierto. Creo que se convirtieron en un estándar en algún momento a finales del año pasado.

Y están específicamente enfocados en tareas y lógica de flujo de trabajo, donde CLoT.md se enfoca en directrices de codificación a nivel de repositorio o subdirectorio. Y obviamente son específicos de CLoT o Entropic. Ahora, sabemos que las habilidades son útiles. ¿Significa eso que ahora necesitamos ir a Gemini o a cualquiera de nuestros proveedores de IA favoritos y simplemente crear habilidades para todo? En realidad, voy a recomendarte que no lo hagas. Si vas a Gemini y creas tus propias habilidades, esto significa que las habilidades probablemente son innecesarias, porque el modelo que el agente utiliza ya posee las capacidades para realizar esta tarea. Así que estas habilidades son solo redundantes y llevarán a una sobrecarga de contexto.

Entonces, ¿cómo funcionan las habilidades? Recuerda nuestro bucle de React. Ahora vamos a integrar las habilidades. Así que cada vez que estamos realizando una tarea en particular, imagina que es solo una iteración diferente del bucle de React, miraremos las habilidades disponibles que tenemos y crearemos un resumen de ellas. Esto será solo la lista de las descripciones y los nombres de las habilidades que tenemos disponibles. Vamos a preguntar a los modelos de lenguaje grande qué habilidades son relevantes para esta tarea en particular, y si hay habilidades relevantes, las añadiremos al contexto. Observa cuántas cosas estamos añadiendo al contexto. Por eso digo que debemos ser muy conscientes sobre las habilidades que estamos añadiendo y también la forma en que estamos expandiendo las capacidades del agente con MCP o con CLIs, porque todo termina siendo parte del contexto, y esto es algo por lo que pagamos y algo que puede hacer que el rendimiento del agente disminuya si crece demasiado.

Ahora, construyendo habilidades durante el último año o así, o seis meses, no sé, cuando sea que el diseño abierto, cuando sea que la especificación de habilidades salió, descubrí cinco mejores prácticas para el desarrollo de habilidades de agentes. En primer lugar, lo que necesitamos poner en skill MD. Necesitan ser instrucciones procedimentales. Te mostraré por qué en un momento. En segundo lugar, la optimización del front matter es realmente importante. Divulgación progresiva, para que podamos mantener nuestro skill.md bastante delgado. Scripting de tareas repetitivas y composición de habilidades. Instrucciones procedimentales. Si estás escribiendo documentación para humanos, puedes proporcionar ejemplos, puedes hacer comparaciones entre tu framework y la cocina, digamos. Puedes hacer diferentes analogías, diferentes pros que podrían ser realmente útiles para que el usuario comprenda cómo funciona tu tecnología. Sin embargo, si estás construyendo habilidades, estas habilidades no son para humanos, son para agentes. Y los agentes, no necesitan pros, necesitan instrucciones procedimentales que sean muy claras en describir al agente lo que necesita hacer. Así que en lugar de decir, para ejecutar pruebas, primero verifica si npm está en, para que puedas buscar paquetes y así sucesivamente, en lugar de hacer eso y hacer que sea difícil para el agente seguir pasos individuales y descubrirlos, puedes simplemente decir, primero busca el archivo package.json. Si el registro yaml está presente, ejecuta esto y aquello. Enfócate en una ejecución predecible y repetible. A continuación, si tienes el mejor skill.md posible, aún podría ser relevante si no tienes un buen front matter. Puedes contaminar tu contexto o tu agente podría no ser capaz de descubrir la habilidad en absoluto.

Aquí está la razón. Aquí tenemos un nombre de habilidad que es muy genérico, TestRunner, ejecutar pruebas de repositorio. Así que esto podría cargarse potencialmente para cada tarea que tengas relacionada con la ejecución de pruebas. Pero podrías estar apuntando solo a la ejecución de tus pruebas de front-end, para Angular o React, en este caso para Angular. Así que pruebas de Angular, ejecuta pruebas unitarias de Angular usando Karma, no lo uses para React o Vue. Este desencadenante negativo es usualmente una mejor práctica para asegurarte de que esta habilidad no termine siendo parte de una ejecución agéntica en la que esto es irrelevante y solo contamina tu contexto.

Hablando de habilidades, he notado que muchas personas instalarían muchas habilidades y se olvidarían de ellas. Terminarán teniendo cientos de habilidades, y esto hará que el rendimiento de sus sesiones retroceda y les haría gastar más en créditos o en sus herramientas de IA. Hay investigaciones activas que muestran que entre 20 y 30 habilidades es ideal. Si estás construyendo agentes personalizados o si estás consumiendo agentes y has instalado muchas de tus habilidades, asegúrate de mantenerlas, digamos, bajo 50 idealmente. Si alcanzan 200, ya comenzarás a experimentar una caída en la precisión, y con 500 mejor elimínalas todas. Solo estás consumiendo muchos tokens innecesarios en ejecuciones agénticas pobres.

Otra cosa, para mantener tu skill.md bastante pequeño, te recomendaré que aproveches la divulgación progresiva. En skill.md, asegúrate de mantenerlo bastante delgado, bajo 500 líneas, y asegúrate de tener columnas cortas, tamaño de línea corto. De esta manera, puedes referenciar cualquier otro recurso que el agente pueda querer cargar condicionalmente en tus referencias. Puedes simplemente referenciar tus referencias en tu skill.md para que puedas mantener skill.md más delgado. Tareas repetitivas, asegúrate de usar scripts. Mira el ejemplo en el lado izquierdo. Es solo inglés. Estoy diciendo busca estadísticas, reemplaza con estadísticas, establece esta variable de entorno, verifica. Hay ambigüedad aquí. Esto es inglés. Esto no es un código que necesariamente se ejecutaría en el orden que he especificado. Con modelos recientes, sí, son realmente buenos siguiendo instrucciones, pero aún no tenemos una garantía del 100% de que las seguirán en el orden que especificamos. Además, cada una de estas líneas está asociada con múltiples llamadas a herramientas. Esto podría ser potencialmente un viaje de ida y vuelta al modelo. Podría ser significativamente menos eficiente en comparación con simplemente encapsular estos pasos en un script determinista que estamos referenciando en skill.md. Esa será mi penúltima mejor práctica, tareas repetitivas, scripting, usa scripts para tareas repetitivas. Eso es todo. La última es la composición de habilidades.

Aquí tenemos un proyecto de construcción. Esta es nuestra habilidad de enrutador que está haciendo referencia a nuestra compilación de cliente y nuestra compilación de servidor. Ahora, el agente puede cargar condicionalmente ya sea la compilación de cliente si está interesado en construir el cliente o la compilación de servidor. De esta manera, mantenemos nuestra habilidad de proyecto de construcción bastante ligera, y tenemos estas otras habilidades específicas que el agente podría potencialmente cargar condicionalmente bajo demanda.

Pasé mucho tiempo hablando sobre scripts versus estas instrucciones procedimentales. Puedes ver que aquí en el lado izquierdo, tenemos una habilidad que está haciendo algo con algún portal de socios de Salesforce, y tenemos un script equivalente. Hay diferencias obvias aquí. Primero, si podemos automatizar algo, si podemos hacerlo determinista, deberíamos hacerlo determinista y crear un script porque podemos probarlo significativamente más fácil. Pero también hay cierta similitud entre ellos. Ambos expresan algún tipo de computación que necesitamos asegurarnos de probar para asegurarnos de que funcione.

Sé que con los agentes, no es obvio que el inglés que escribimos también necesita ser probado para asegurarnos de que proporciona buenas instrucciones al modelo. Es por eso que me gustaría hablar un poco sobre la prueba de habilidades o evaluaciones de habilidades. Necesitamos evaluar habilidades solo para asegurarnos de que sean útiles. Si ejecutar un flujo de trabajo con y sin habilidades produce los mismos resultados, probablemente deberíamos eliminar la habilidad. También necesitamos asegurarnos de que probamos habilidades para prevenir regresiones. Imagina que eliminamos un párrafo. ¿Cómo sabemos si esto es un resultado positivo o negativo para esta habilidad específica? Realmente no hay manera.

Necesitamos evaluar nuestras habilidades y probar con y sin, y tener estas evaluaciones continuas que nos den información procesable. De la misma manera, podemos eliminar habilidades no utilizadas o incluso implementar algo llamado hill climbing o habilidades auto-mejorables de las que voy a hablar al final.

La pirámide de pruebas que tenemos del desarrollo de software con la que estás muy familiarizado es muy relevante para los flujos de trabajo agénticos también. Ahora mismo, vamos a mirar la parte inferior de esta pirámide, las evaluaciones de habilidades. Sobre las evaluaciones de habilidades, hay algunos buenos artículos escritos, como por ejemplo, Skill Bench, que es un gran documento que solo prueba habilidades, qué tan bien se desempeñan en un conjunto diverso de tareas. Hay un gran documento, un gran artículo de blog por Entropiq, también desmitificando las evaluaciones para agentes de IA, que a un nivel muy alto describe que para crear una evaluación, necesitamos identificar objetivos.

Alrededor de estos objetivos, necesitamos crear tareas. Y necesitamos ejecutar estas tareas múltiples veces para verificar si nuestros agentes lo hicieron bien. Podemos evaluar el rendimiento del agente con scripts o calificadores deterministas y con calificadores no deterministas o agentes ALM aquí. También podemos utilizar humanos para el propósito. Basado en estos dos documentos, creé una herramienta llamada SkillGrade que estoy describiendo como pruebas unitarias para tus habilidades de agente.

SkillGrade es, diría yo, probablemente la forma más fácil de crear evaluaciones para tus habilidades. Todo lo que necesitas hacer es instalar SkillGrade con NPM o PMPM. Después de eso, ejecuta {{^}}SkillGrade en él. Asegúrate de proporcionar un token de API para tu AI SDK o proveedor favorito como Entropiq, OpenAI o Google, y ejecuta SkillGrade. Y eso es prácticamente todo.

Veámoslo en acción. Aquí he proporcionado la clave API de Gemini y he ejecutado SkillGrade en él. Esto lee automáticamente mi archivo de habilidades y, basado en lo que estoy describiendo, genera una evaluación. Una vez que he generado esta evaluación, ejecuto SkillGrade smoke para poder ejecutar una prueba de humo con cinco llamadas de esta evaluación.

Todas ellas se ejecutan de manera segura en un contenedor y tengo mis calificadores deterministas y no deterministas para asegurarme de que la habilidad fue realmente útil y encontrar brechas en ella. Una vez que termino con la ejecución, obtengo un informe similar a este que puedo previsualizar en el navegador web. Así que crea el esquema de usuario aquí. Esta habilidad en particular tiene una tasa de éxito del 80%.

Y realicé cinco ejecuciones del flujo de trabajo. Una falló, así que puedo previsualizar el resultado de la rúbrica determinista y la LM. Veo por qué falló. Y puedo previsualizar el registro de la ejecución del agente, lo cual es realmente poderoso. Porque más tarde, puedo analizar este registro de ejecución, y realmente puedo hacer mejoras significativas en mi habilidad. Déjame mostrarte cómo.

Así que aquí, estoy configurando la habilidad. Y estoy ejecutando la tarea asignada en un sandbox, en un sandbox seguro. Así que esto se está ejecutando en un contenedor Docker. Esta es la ejecución. Asegúrate, mira el registro de trayectoria. Enumera todo lo que está sucediendo. Estoy ejecutando diferentes comandos. Estos son los comandos o las herramientas que ya mencioné al principio del bucle React. Estos son los pensamientos del modelo de lenguaje grande.

Esto es como todo. Que más tarde, las calificaciones de habilidades pueden auditar. Y puede encontrar cuáles son las cosas que faltan que causaron que mi habilidad fallara. Por último, pero no menos importante, puedo aplicar estos cambios, y puedo volver a ejecutar mi flujo de trabajo agéntico nuevamente con estas dos nuevas adiciones que agregué. Y una vez que lo ejecuto de nuevo, puedes ver que pasamos por los mismos pasos. Agente, ejecución, registro de trayectoria. Estamos mirando todo lo que sucedió a lo largo de la ejecución de esta tarea en particular. Estamos evaluando, y vemos que todo pasó, así que tuvimos éxito.