Temario · lección 7 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
Señales de fallo y tareas mal especificadas
Una lista corta de preguntas te dice si el fallo es de harness al revisar una ejecución, y una tarea mal especificada es el origen más común.
Como mirar el cuadro de mandos
Un piloto no espera a que el avión se caiga: repasa indicadores. Con un agente puedes hacer lo mismo después de cada ejecución. La lección 01 del repositorio incluye una checklist de cinco preguntas para revisar una ejecución floja.
La checklist de señales
Léela con una ejecución reciente delante:
- ¿El agente preguntó o infirió mal cómo arrancar la app? Si no sabe cómo iniciarla, falta ese dato en el entorno.
- ¿Creó carpetas o abstracciones que no encajan con lo que querías? Falta guía de estructura.
- ¿Se detuvo al tener una interfaz visible sin un flujo completo? Éxito de apariencia: no sabía qué significaba «terminado».
- ¿Dejó notas que ayuden a una ejecución futura? Si no, la próxima sesión empezará de cero.
- ¿Podría una sesión nueva entender qué pasó en menos de cinco minutos? Esta es la prueba definitiva de la memoria.
Cada «no» es una pista de qué capa reforzar.
Una tarea mal especificada, desmontada
Este es el ejemplo de «subespecificación» del repositorio:
Construye una aplicación de escritorio de base de conocimientos
con respuesta a preguntas por IA.
Restricciones:
- Ninguna especificada
- Sin comando de inicio
- Sin guía de estructura de carpetas
- Sin modelo de datos
- Sin criterios de finalización explícitos
Todo lo que falta es margen para que el agente invente. Resultado típico: estructura improvisada, app que compila pero no siempre arranca, interfaz antes de que exista un flujo útil y parada tras un éxito cosmético.
La misma tarea, mejor planteada
Sin cambiar de modelo, añadimos justo lo que faltaba:
Construye una app de escritorio de base de conocimientos.
Cómo arrancar: npm run dev
Estructura: src/ para el código, docs/ para notas.
Datos: cada documento tiene título, texto y fecha.
Terminado cuando:
- Puedo importar un archivo de texto
- Puedo hacer una pregunta y recibir una respuesta con la fuente
- npm test pasa
No es larga. Cada línea responde a una de las preguntas de la checklist.
Qué ganas con esto
Cada dato explícito sustituye una apuesta del agente por una instrucción comprobable. Y al dejar notas y criterios por escrito, también ayudas a la sesión siguiente, que podrá entender el estado en minutos.
Un agente deja una interfaz bonita pero sin flujo completo y dice que ha terminado. ¿Qué señal de fallo es?
Fuentes: Learn Harness Engineering, lección 01 (code/failure-signals-checklist y underspecified-task)