Temario · lección 68 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
Proyecto 3, continuidad entre sesiones
Controla el alcance con feature_list.json (una función a la vez, sin pass sin evidencia) y mantén el hilo con un diario de progreso, un handoff y un checklist de estado limpio.
Una novela por capítulos sueltos
Imagina escribir una novela donde cada mañana olvidas el capítulo anterior. Sin notas, repites escenas y contradices a los personajes. Un agente trabaja así. Este proyecto le da el cuaderno: un registro de progreso, una lista de funciones con estado y un cierre ordenado de cada sesión. Teoría en el diario progress.md y una cosa a la vez.
Qué construyes
Cuatro funciones sobre la app de los proyectos anteriores:
- Partir los documentos en fragmentos (chunking).
- Extraer metadatos.
- Mostrar el progreso de indexación.
- Preguntas y respuestas con citas.
Y las sigues con feature_list.json: una función a la vez y nada de passing sin evidencia.
Los estados de una función
| Estado | Significa |
|---|---|
not_started | Sin tocar |
in_progress | La única en curso |
blocked | Parada por un bloqueo documentado |
passing | Verificación hecha y evidencia anotada |
Los dos intentos
Primero sin restricciones; luego con reglas estrictas. El punto de partida (starter) trae solo una lista inicial. La solución añade init.sh, session-handoff.md, claude-progress.md y clean-state-checklist.md. Compara si el agente se desvía entre funciones o pierde el estado al reiniciar, y si cada función tiene evidencia concreta antes de aprobarse.
Ejemplo de entrada de evidencia
{
"id": "index-002",
"status": "passing",
"evidence": "init.sh OK; indexé 3 documentos; la barra llegó a 100%; test indexing.test pasa"
}
Una frase como «parece que funciona» no es evidencia. Un comando ejecutado y su resultado, sí.
Cierre limpio de cada sesión
Antes de parar, repasa esta lista (viene en las plantillas del curso):
- El arranque estándar sigue funcionando.
- La verificación estándar sigue ejecutándose.
- El progreso está en el registro.
- El estado de las funciones refleja la realidad, sin falsos
passing. - No hay pasos a medias sin documentar.
- La siguiente sesión puede continuar sin arreglos manuales.
¿Cuándo puede una función pasar a passing?
Fuentes: Learn Harness Engineering, projects/project-03