Proyecto: un agente completo sobre un modelo guionizado

Desde la lección sobre el estado y la memoriaBlock 4 · Lesson 6 · In SpanishEstado y memoria: lo que el bucle recuerdaLo que un agente recuerda está en dos sitios. M, la lista de mensajes que el modelo ve, crece con cada observación, tiene que caber en la ventana y se acaba con la conversación. El entorno dura, pero el modelo sólo sabe de él lo que le ha traído una llamada, y desde que se lo trajo., el bloque sabe qué recuerda cada parte del agente, y no le queda ninguna pieza por escribir. Lo que no ha hecho es ponerlas a trabajar a la vez. Esa lección corrió sus celdas sin el permiso, que no le hacía falta, y cada una de las anteriores comprobó su pieza con una conversación escrita para ella, en la que las demás no tenían ocasión de actuar.

Juntar piezas con contrato parece cuestión de copiar y pegar, y no lo es del todo, porque los contratos se cruzan. Una escritura que el usuario rechaza, ¿deja una llamada contestada o un hueco en M? Una llamada mal formada de una herramienta que pregunta, ¿se le enseña al usuario? Detrás hay una pregunta mayor. Con un modelo de verdad, que una conversación salga bien dice muy poco del harness: el modelo pudo no pisar ninguno de sus caminos difíciles. ¿Qué promete el agente entero, responda lo que responda el modelo, y cómo se comprueba que lo cumple?

Mira primero el agente entero, con una conversación en la que el modelo guionizado se equivoca a propósito. El usuario pide Añade a lista.txt lo que falta para la tortilla. En el turno 1, el modelo pide una receta que no existe, recetas/tortilla-de-patatas.txt, y lee la lista con un campo que su esquema no tiene. Corrige las dos cosas, lista la carpeta, lee la receta, y en el turno 4 pide dos escrituras: la lista, que es lo que le han pedido, y una nota con el menú del sábado, que no le ha pedido nadie. Avanza paso a paso y fíjate en qué pasos dejan un error en M, y en quién lo decide.

Los tres errores son de tres piezas distintas. El de t1 es de la función: leer no encuentra el fichero. El de t2 es del esquema, y llega antes de que nadie mire el permiso. El de t7 es del usuario, que ha visto la escritura de la nota y ha dicho que no. Los tres entran en M igual que una lectura que sale bien, y el modelo los lee: su texto final dice que el menú no está apuntado. Prueba ahora un tope de 4. El bucle para con la lista escrita, la nota sin escribir y nada que contarle al usuario.

El agente y lo que promete

Con precisión, el agente del bloque es esta función:

agente(modelo, pedido, entorno, tope=10) -> (motivo, texto, M)

Monta el inicio (el prompt de sistema y el pedido) y llama al bucle. Todo lo demás ya estaba escrito, y cada pieza vive en un fichero:

• modelo, la única que no es del harness: aquí, el modelo guionizado (guionizado.py);
• el entorno, sus cuatro herramientas y el esquema de cada una (entorno.py), de la lección sobre llamar herramientasBlock 4 · Lesson 2 · In SpanishLlamar herramientas: salida estructurada con consecuenciasUna herramienta es lo que el modelo lee de ella: un nombre, una descripción y un esquema. La llamada y la observación pasan a ser bloques unidos por un identificador, y el harness comprueba cada llamada contra su esquema antes de ejecutarla, porque aquí una salida mal formada no se reintenta: se ejecuta.;
• el bucle (harness.py), de la lección que le dio su contratoBlock 4 · Lesson 3 · In SpanishEl bucleEl bucle de un agente llama al modelo con la lista de mensajes, añade lo que responde, ejecuta lo que pide y añade lo que vuelve, hasta que una respuesta no pide nada o se acaba el tope. La lección lo escribe con sus tres maneras de parar y sus invariantes: el modelo sólo ve esa lista, y la lista sólo crece., sin tocar;
• ejecutar (permisos.py), que comprueba el esquema, consulta el permiso y ejecuta la función, con los errores de la lección sobre los erroresBlock 4 · Lesson 4 · In SpanishErrores como observacionesUna llamada que falla deja de ser una excepción que para el programa y vuelve al modelo como una observación marcada con is_error, que dice qué ha fallado. El modelo decide qué hacer con ella, y repetir una llamada es seguro cuando es idempotente o cuando el error dice que no llegó a ejecutarse. y el permiso de la lección sobre los permisosBlock 4 · Lesson 5 · In SpanishPermisos y confianza: la herramienta no es el usuarioAntes de ejecutar una llamada, el harness decide si la permite, le pregunta al usuario o la deniega, según la clase de su herramienta y sin leer ninguna observación. Lo que devuelve una herramienta es contenido no fiable: un fichero puede traer instrucciones para el modelo, y el agente no obedece a los ficheros..

Su contrato son cinco garantías, y ninguna depende de lo que responda el modelo:

1. Termina. Llama al modelo como mucho tope veces.
2. Cada llamada tiene su observación, una sola, en el mensaje que sigue a la respuesta que la pidió: también la que no se ejecuta, y también al salir por el tope.
3. Sólo una llamada permitida cambia el entorno. Antes de llegar a su función, la llamada ha cumplido su esquema y, si su herramienta es de escritura, el usuario ha dicho que sí. En ese orden, así que a nadie se le pregunta por una llamada que no se puede ejecutar.
4. Ninguna llamada para el bucle. Lo que falla en el esquema o en la función vuelve como error, y lo único que sale del bucle como excepción es un fallo de modelo.
5. El modelo ve M y nada más, y nada de lo que hay en M decide un permiso.

Y tres cosas que no promete. Que la tarea se haga, porque eso lo decide el modelo. Que su texto final diga la verdad sobre el entorno: en la lección sobre los permisos el texto callaba la nota, y aquí la cuenta porque he escrito así el guion. Y que M quepa en la ventana de contexto, que es una garantía del bloque siguiente.

Un test fija el modelo y prueba el harness

Un test del agente es una conversación con su desenlace escrito de antemano: el entorno, el pedido, el tope, las respuestas del modelo turno a turno, las observaciones que el harness tiene que contestar a cada una, lo que contesta el usuario a cada pregunta, y lo que el agente tiene que devolver y dejar en el entorno. Pasa cuando el agente hace exactamente eso.

Se comprueba en dos sitios. El modelo guionizado compara cada M que recibe con el que espera, mensaje a mensaje, así que una observación distinta, un mensaje de más o uno de menos paran el test en el turno en que aparecen. Al final se mira lo que el modelo no ve: lo que devuelve el agente, el entorno, y por qué llamadas se le ha preguntado al usuario.

Dos reglas hacen que un test pruebe lo que dice probar. La primera es que las respuestas son del guion. Con el modelo fijado, la única pieza que puede hacer otra cosa es el harness, y un test que no pasa señala al harness y a nada más.

La segunda es que las observaciones esperadas se escriben a mano. Las lecciones anteriores las calculaban ejecutando las llamadas del guion con el propio ejecutar sobre una copia del entorno, y para enseñar una pieza servía. Como test no sirve, porque compara ejecutar consigo mismo. Un ejecutar que escribiera sin preguntar produciría la observación de la escritura, el guion la esperaría y el modelo guionizado no notaría nada. Escritas a partir del contrato de cada herramienta y del de ejecutar, las observaciones dicen lo que tiene que pasar, no lo que pasa.

Queda una pregunta sobre los tests mismos: ¿cómo se sabe que una batería detecta algo? Rompiendo el harness. Un harness roto es el agente con una sola pieza cambiada por una versión con un defecto. Si ningún test de la batería deja de pasar con él, a la batería le falta un test: hay un camino del contrato que ningún guion recorre. La técnica se llama mutation testing, y tiene casi cincuenta años.

El agente, sobre el modelo guionizado

Las tres celdas corren sobre el modelo guionizado, como todo el bloque, y su modelo se equivoca porque lo he escrito así. Cargan cuatro ficheros, uno por pieza: los tres de las lecciones anteriores y permisos.py, la solución del desafío de la lección sobre los permisos, congelada como los demás. Su ejecutar sustituye al de harness.py, y el bucle, que llama al ejecutar que encuentre, no cambia. La primera celda escribe agente y corre la conversación del explorable, con las observaciones esperadas escritas a mano.

El agente termina en 5 turnos con 11 mensajes en M: los dos del inicio, dos por cada turno que pide algo y la respuesta final. La lista tiene los huevos y la cebolla, y la nota dice lo que decía. El modelo guionizado ha aceptado los cinco M que ha recibido, así que cada observación que ha contestado ejecutar es, carácter a carácter, la que escribí a mano. Eso ya es casi un test. Le falta decir qué espera al final.

La segunda celda lo convierte en test y le añade otros dos. probar pone en lugar de preguntar al usuario del test, que contesta lo que el test dice y apunta por qué se le pregunta, corre el agente y devuelve None si todo es lo esperado, o en qué se ha desviado. Los otros dos tests son conversaciones que se equivocaban en lecciones anteriores: la receta copiada de la web que trae una orden para el modelo, y el modelo terco que lista la carpeta sin parar, ahora con un tope de 3.

Pasan los tres. El de la receta pasa porque el modelo obedece a la receta y el harness no: la escritura de la nota llega al usuario, que dice que no, y el test exige justo esa pregunta. El terco pasa porque el bucle para en el turno 3 y devuelve tope, sin pedirle al guion una cuarta respuesta que no tiene.

La tercera celda rompe el harness cuatro veces, una pieza cada vez, y corre la batería contra cada versión: un bucle sin tope, uno que no le da al modelo las observaciones, un ejecutar que ejecuta a ciegas (sin esquema, sin permiso y sin try) y uno que consulta el permiso antes que el esquema. Cada versión rota ocupa el sitio de la buena con el mismo nombre, que es lo que hace el bucle con ejecutar, y la buena vuelve a su sitio al acabar.

Mira qué test detecta cada uno. El bucle sin tope sólo lo ve el terco, cuando el harness le pide al guion una cuarta respuesta: los otros dos terminan antes de que el tope importe. Las observaciones olvidadas las ven los tres en el turno 1, en el mensaje 3, que es donde tenían que estar. La ejecución a ciegas la ve la tortilla, por la excepción de t1 que atraviesa el bucle, y la receta, por la nota que se escribe sin preguntar. El terco la pasa, porque listar ni falla ni pregunta.

El cuarto pasa los tres tests, y no cumple el contrato. Le pregunta al usuario por una llamada antes de saber si se puede ejecutar: el usuario aprueba algo que no va a pasar, o lo rechaza y el modelo recibe un motivo que no es el verdadero. Ningún test lo ve, porque la única llamada mal formada de la batería es la lectura de t2, y una lectura no pregunta. El test que falta es el desafío de abajo.

Comprueba tu intuición

Tres preguntas (por qué las observaciones esperadas se escriben a mano, qué les pasa a los tests cuando cambia el modelo y qué dice una batería que pasa) y un desafío: el test que le falta a la batería.

El agente está entero y probado: cumple su contrato en cada camino que recorren sus tests, y cuatro harness rotos dicen que esos tests miran algo. Lo único que no es de verdad es el modelo. El guion se equivoca donde yo lo he escrito y de las formas que yo he pensado, y en ningún otro sitio. Un modelo de verdad pide rutas que no existen sin que nadie se lo haya escrito, llena argumentos que ningún test esperaba y a veces no para de pedir.

Ponerlo es cambiar una sola pieza. La lección siguiente, la primera del último bloque, prepara la máquina: un modelo local, servido en tu ordenador, que habla el protocolo de los bloques tool_use y tool_result que este bloque ha usado desde el principio. Detrás de modelo, el bucle, ejecutar, el permiso y el entorno no cambian, y los tests de esta lección siguen corriendo sobre el guion. Por eso el bucle se escribió primero, y se probó sobre un guion: cuando el modelo de verdad haga algo inesperado, lo que el harness haga con ello ya tendrá sus tests.