Radar · 12/07/2026 · ocurrido el 07/07/2026 · coding

Un agente en 100 líneas de Lisp

Un post en The Beach muestra un agente completo escrito en 100 líneas de Common Lisp: loop recursivo, llamada al modelo, ejecución de tools. Sin dependencias más allá de HTTP y JSON. El loop entero está en 8 líneas: caso base (el modelo responde), caso recursivo (quiere tools, los ejecuta, se llama a sí mismo). El estado del agente es solo el argumento que fluye a través de la recursión.

Por qué te importa: si seguiste las lecciones del curso sobre tu primer agente o descargaste los scaffolding mínimos, esta implementación es el esqueleto desnudo de lo que hay debajo. El tool es uno solo: eval. El modelo escribe código Lisp como string, el agente lo ejecuta y devuelve el resultado. Sin catálogo de tools, sin framework: el lenguaje mismo se convierte en la interfaz. Para Fibonacci(30), el modelo escribió la función recursiva, la ejecutó con eval, y devolvió 832040. Dos llamadas, cero prompts preconfigurados.

Es un experimento de sandbox (eval abierto es un riesgo de seguridad claro), pero la idea es instructiva: Lisp es homoicónico (el código está hecho de la misma estructura de datos que el programa), así que un programa puede construir y modificar otro código como si fuera una lista de la compra. Es la propiedad que hace 25 años hacía a Lisp “el lenguaje de la IA simbólica”. Hoy esa promesa se materializa de forma diferente: el modelo genera el código, Lisp lo ejecuta, y el loop recursivo lo mantiene todo junto. 114 puntos en Hacker News dicen que la idea ha resonado.

En detalle

El contexto

Alrededor del 2000, Lisp era considerado el lenguaje de la inteligencia artificial simbólica: sistemas expertos, demostradores de teoremas, programas que manipulaban símbolos y reglas. Luego los métodos estadísticos ganaron, el deep learning los enterró, y Lisp quedó como una curiosidad histórica para la mayoría de los desarrolladores. El autor del post cuenta que aprendió Lisp en un curso de IA en la Universidad de Guelph, sin verlo usado nunca después.

Hoy construye una plataforma de agentes de IA y se pregunta: ¿podría Lisp seguir siendo útil para un agent loop? La respuesta es sí, pero por razones diferentes a las del 2000.

La anatomía del agente

La implementación completa (disponible en The Beach) usa SBCL (Steel Bank Common Lisp), dos librerías (dexador para HTTP, shasht para JSON), y nada más. El loop recursivo:

lisp (defun agent-loop (messages) (let* ((message (ref (call-model messages) choices 0 message)) (tool-calls (gethash tool_calls message))) (if (and tool-calls (plusp (length tool-calls))) (agent-loop (append messages (list message) (map list # execute tool-calls))) (append messages (list message)))))

Ocho líneas. Si el modelo responde, devuelve el historial. Si pide tools, los ejecuta, añade los resultados, y se llama a sí mismo. El estado es solo la lista de mensajes que fluye a través de la recursión. Nada de máquinas de estado, nada de variables globales.

El truco: eval como único tool

La mayoría de los agentes tienen un catálogo de tools (búsqueda web, lectura de ficheros, ejecución Python). Este agente tiene un solo tool: eval. El modelo escribe una form Lisp como string, el agente lo lee (read-from-string), lo ejecuta (eval), y devuelve el resultado impreso.

lisp (defun lisp-eval (form-string) (handler-case (format nil “~s” (eval (read-from-string form-string))) (error (e) (format nil “ERROR: ~a” e))))

Esto es posible porque Lisp es homoicónico: el código está escrito en la misma estructura de datos (listas) que el lenguaje manipula. Un programa Lisp puede construir y modificar otro código Lisp con la misma facilidad que construye una lista. En el transcript del post, el agente calculó Fibonacci(30) en dos pasos: primero definió la función en tiempo de ejecución, luego la llamó.

Limitaciones declaradas

El autor lo deja claro: eval abierto es un riesgo de seguridad. El modelo ejecuta código arbitrario en la máquina. Este es un experimento de sandbox, no una receta para producción. El autor mismo solo lo ejecutó en un contenedor Docker local.

Pero la idea es válida como herramienta didáctica: muestra qué hay debajo de un agente sin framework, sin abstracciones, sin dependencias. Es el equivalente a escribir un servidor HTTP en 50 líneas para entender qué hace Express o Flask detrás de escenas.

Por qué ahora

La promesa original de Lisp era “programas que manipulan programas”. En 2000 significaba reglas simbólicas escritas a mano. En 2026 significa: el modelo escribe el código, Lisp proporciona el sustrato donde ese código se ejecuta, y el loop recursivo lo mantiene todo junto. El trabajo simbólico ha sido externalizado al modelo, pero la propiedad homoicónica de Lisp hace la ejecución inmediata.

Si estás construyendo agentes o siguiendo la ruta builder del curso, este post merece la lectura: es una anatomía limpia, sin adornos, de cómo funciona un loop. Y si alguna vez pensaste “me gustaría entender qué hay realmente debajo antes de usar un framework”, este es el tipo de código que te lo muestra.

Escribe para buscar en curso, playbooks, skills, papers…