Temario · lección 9 de 74
1Por qué fallan los agentes
2Qué es un harness
3Patrones de agentes
4Herramientas
5Ingeniería de contexto
6El repositorio como memoria
7Tareas largas
8Alcance y “hecho” de verdad
9Observabilidad y estado limpio
10Loops y grafos
11Harness reales
12Proyecto final
- Proyecto 1, solo prompt contra harness mínimo
- Proyecto 2, un workspace legible
- Proyecto 3, continuidad entre sesiones
- Proyecto 4, feedback de runtime e indexado
- Proyecto 5, que el agente verifique su trabajo
- Proyecto 6, el harness completo (capstone)
- Proyecto 7, tu primer loop automático
- Proyecto 8, dibuja tu flujo como un grafo
- Checklist final y plantillas
Un turno, paso a paso
Desde que escribes un prompt hasta que ves la respuesta, el harness coordina cinco pasos. El modelo elige las acciones; el harness las ejecuta y las vigila.
Pides algo y pasa mucho más de lo que ves
Escribes en el chat de tu editor: «Arregla el test que falla». Unos segundos después ves cambios en el código y un resumen. Entre medias ocurrió una pequeña coreografía. La documentación de VS Code la describe como un turno con cinco pasos.
Los cinco pasos
- El harness recibe tu petición y el estado de la sesión. Prepara las instrucciones, el contexto y las definiciones de las herramientas disponibles, y se lo pasa al modelo.
- El modelo razona y responde. Puede contestar directamente o pedir llamar a una herramienta («lee este archivo»).
- Si pide una herramienta, el harness la gestiona. Aplica las reglas de permisos y aprobaciones, envía la llamada al entorno donde se ejecuta y recoge el resultado.
- El harness devuelve el resultado al modelo. El modelo decide: ¿llamo a otra herramienta, pregunto algo al usuario o termino?
- El harness guarda todo en la sesión (mensajes, llamadas, resultados, cambios en el código) y muestra el estado actual.
Los pasos 2 a 4 se repiten tantas veces como haga falta. Es el bucle de la primera lección: mirar, decidir, actuar y comprobar.
Dibujémoslo
| Quién | Qué hace |
|---|---|
| Tú | Escribes el prompt |
| Harness | Prepara contexto y herramientas |
| Modelo | Razona; devuelve respuesta o petición de herramienta |
| Harness | Comprueba permisos, ejecuta, recoge el resultado |
| Modelo | Decide el siguiente paso |
| Harness | Registra la sesión y te enseña el estado |
Un ejemplo imaginario
Sigamos con «arregla el test que falla»:
Modelo -> pide: ejecutar los tests
Harness -> pregunta permiso si hace falta, ejecuta, devuelve el fallo
Modelo -> pide: leer src/suma.js
Harness -> lee el archivo y se lo da
Modelo -> pide: editar src/suma.js
Harness -> aplica el cambio y lo anota en la sesión
Modelo -> pide: ejecutar los tests otra vez
Harness -> devuelve "todo pasa"
Modelo -> responde: "Arreglado. El fallo estaba en..."
Observa que en todo el rato el modelo solo ha producido peticiones y texto. Cada acción real la ha hecho el harness, y cada una ha pasado por sus reglas de permisos.
Por qué te conviene saberlo
Si algo sale mal, sabes dónde mirar. ¿El modelo recibió el contexto correcto (paso 1)? ¿Tenía la herramienta que necesitaba (paso 2)? ¿Se bloqueó una acción por permisos (paso 3)? ¿El resultado volvió completo (paso 4)? Es el mapa del bucle diagnóstico del módulo anterior.
¿Quién decide si una llamada a herramienta necesita aprobación y la ejecuta?
Fuentes: VS Code, Understand agent harnesses