Vigilar a un agente con un modelo de decisión
Los agentes de código son donde más densamente se usan estos modelos, y los usos se agrupan en tres lugares. Los tres comparten una misma estructura: saca el juicio del modelo generativo, dáselo a algo más barato y rápido, y deja que el código actúe sobre una respuesta tipada.
1. Antes de una llamada a herramienta: permitir o no
El punto más directo. Un hook PreToolUse de Claude Code hace esto:
Pregúntale a un
Noul: ¿este comando de shell es estrictamente de solo lectura? Aprueba automáticamente con 0.95; de lo contrario, vuelve al aviso de permiso normal — y nunca deniegues.
Merece la pena nombrar tres decisiones de diseño:
- 0.95 es alto. El listón para aprobar automáticamente está muy por encima del listón de «esto parece riesgoso». Un permiso en falso puede costar una máquina; un bloqueo en falso cuesta una confirmación extra. Los costes asimétricos van en umbrales asimétricos.
- Nunca deniega. Solo añade una aprobación; todo lo demás vuelve al sistema original. Una puerta que solo añade capacidad es mucho más fácil de probar: su peor caso es no haber servido de ayuda.
- Los comandos peligrosos nunca llegan al modelo. Una lista local de prohibiciones estrictas y un filtro de inyección los atrapan primero. Esto importa más que el umbral — ver Lo que tiene que vivir en el código.
Resultado medido: 0 de 8 comandos que cambian el estado se aprobaron automáticamente.
2. Cuando el agente quiere parar: ¿ya terminó?
Otro punto frecuente. Un hook Stop le pregunta al modelo de decisión si el agente está terminando demasiado pronto, presentándole sus reglas de finalización en lenguaje natural.
La versión más contenida funciona así:
Gasta una llamada de cuatro preguntas solo cuando cambiaron archivos y no se ha ejecutado ninguna comprobación correcta desde entonces. Ante cualquier error, deja pasar.
«Preguntar solo cuando vale la pena preguntar» es la clave para esta clase — estos hooks se ejecutan en cada turno, y llamar sin condición multiplica el coste por el número de turnos. La condición de arriba es «cambios sin verificar», que es exactamente el momento en que un agente tiene más probabilidades de declarar victoria sin haber comprobado.
Un hook relacionado evita que un agente termine antes de tiempo juzgando reglas de finalización en lenguaje natural, en lugar de confiar en lo que el propio agente afirma.
3. Cuando el contexto se llena: ¿qué hace falta todavía?
El tercer punto es la compactación de contexto, donde los enfoques más divergen.
La compactación tradicional resume: le entregas un tramo de conversación a un modelo y recibes prosa de vuelta. El original se pierde, y resumir es irreversible.
El enfoque con modelo de decisión no reescribe: solo puntúa:
| Enfoque | Qué se conserva |
|---|---|
| Puntuar cada llamada a herramienta y su resultado por «todavía necesario» | Las líneas que se juzgan dignas de conservar se quedan literalmente |
Mover las puntuaciones bajas a un almacén y dejar un puntero expand() en su lugar |
No se borra nada, solo se pliega |
| Un prefijo congelado de solo anexado | La caché del prompt nunca se rompe |
| Recortar la salida larga de Bash antes de que el modelo la vea | El ruido de la terminal nunca entra en la ventana |
La frase que comparten: la tarea del modelo de decisión aquí es una decisión binaria de conservar o descartar, no una reescritura. Eso es justo lo que hace bien y lo que los modelos generativos hacen mal — y «plegar en lugar de borrar» convierte un juicio equivocado de «información perdida para siempre» en «un expand de más».
El contrapunto: las puertas de seguridad y las de eficiencia fallan en direcciones opuestas
El contraste más instructivo en esta parte del ecosistema: ante la misma pregunta, «qué pasa cuando hay un error», los proyectos eligieron respuestas opuestas, y ambas son correctas.
- Un juez de permisos: deniega ante error o timeout.
- Un hook Stop: permite ante cualquier error.
El criterio no es «cuál es más seguro», sino si esta puerta protege contra el riesgo o protege el rendimiento. Las puertas que protegen contra el riesgo (permisos, secretos, comandos peligrosos) deberían más bien bloquear algo bueno que dejar pasar algo malo; las puertas que protegen el rendimiento (comprobaciones de finalización, de formato) deberían más bien dejar pasar algo que bloquear todo el flujo.
En una frase
Los agentes son el hogar más natural para estos modelos porque necesitan muchísimas decisiones baratas cuyos resultados el código consume de inmediato. Pero en cada uno de esos puntos, decide primero: ¿hacia qué lado debería caer esta puerta cuando se rompe?