Lección 5: Intervención y dirección: interrumpir, redirigir, human-in-the-loop
Objetivos de aprendizaje:
- Decir por qué un bucle autónomo necesita a una persona dentro, y dejar claro el vínculo causal: la agencia excesiva es la razón por la que un bucle más autónomo necesita más compuerta manual
- Distinguir interrumpir, dirigir y aprobar — dónde corta cada uno en el bucle, y qué cambia cada uno
- Decidir si un punto de aprobación humana para una acción de alto impacto va antes o después de la ejecución, y enunciar la regla de «antes de que se vuelva irreversible»
Requisitos: Termina las Lecciones 3 y 4, sabe que un bucle tiene condiciones de parada y que los bucles muertos y el giro en vacío necesitan salvaguardas, y entiende el arnés como el código de control alrededor del modelo | Anterior: Lección 4 << | Siguiente: Lección 6 >>
Las primeras cuatro lecciones administraron el bucle mismo; esta mete a una persona
A estas alturas el bucle que tienes en las manos funciona, se detiene y tiene salvaguardas debajo. La Lección 3 le dio condiciones de parada explícitas. La Lección 4 le enseñó a reconocer bucles muertos y giro en vacío para que no queme el presupuesto hasta el suelo. Todos esos controles comparten algo: son el arnés forcejeando con el bucle por su cuenta, de principio a fin, sin que nadie intervenga.
Los agentes reales rara vez se ejecutan de punta a punta sin vigilancia. A mitad de una tarea podrías querer cancelar todo el asunto — la dirección está completamente equivocada, deja de gastar. Podrías querer cambiar el objetivo sin detener el proceso: «suelta el refactor, ve a encontrar y arreglar ese bug de producción primero». O un paso en particular es lo bastante peligroso como para que quieras verlo y asentir antes de que ocurra. El modelo no puede decidir ninguna de estas cosas por sí solo, y la detención automática y las salvaguardas de las Lecciones 3 y 4 tampoco las alcanzan — estas son cosas que una persona mete desde fuera del bucle para hacer. Esta lección es esa capa: cómo interviene una persona a mitad del bucle, y dónde va el código de esa intervención.
Cuanto más autónomo el bucle, más necesita una compuerta humana
Resolvamos una pregunta primero: después de todo ese trabajo para lograr que el bucle gire solo, ¿por qué volver a meter a una persona?
La respuesta se esconde al otro lado de la palabra «autónomo». Un agente es un sistema donde el modelo decide por sí mismo, dentro de un bucle, qué hacer a continuación y qué herramienta usar. Esa autonomía es exactamente lo que lo hace útil — y exactamente lo que lo hace peligroso. La comunidad de seguridad tiene un nombre para el riesgo: agencia excesiva. OWASP lo pone así: "Excessive Agency is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous, or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction."1 (La Agencia Excesiva es la vulnerabilidad que permite ejecutar acciones dañinas en respuesta a salidas inesperadas, ambiguas o manipuladas de un LLM, sin importar qué esté causando que el LLM funcione mal.)
Superpón esa oración sobre el bucle y se vuelve concreta. En un turno cualquiera el modelo podría leer mal lo que devolvió una herramienta, podría tomar por el lado equivocado una oración vaga del usuario, podría ser arrastrado fuera de rumbo por una instrucción maliciosa enterrada en una página web que lee. Los modos de desbocamiento de la Lección 4 rompían el ritmo del bucle — no se detenía, giraba en el sitio. Lo que se rompe aquí es la acción del bucle: fue e hizo de verdad algo que no debía. Y cuanto más permiso y autonomía carga el bucle, más daño hace un solo mal juicio. Así que junto a las compuertas automáticas propias del arnés — condiciones de parada, salvaguardas — el puñado de puntos donde un error no puede deshacerse necesitan una compuerta más, una humana, que le dé a una persona la oportunidad de decir «espera» antes de que la acción aterrice.
Esto no es desconfianza de la automatización. Es una admisión. El modelo puede operar durante un tramo largo de turnos, y como dice la guía de Anthropic, "The LLM will potentially operate for many turns, and you must have some level of trust in its decision-making."2 (El LLM operará potencialmente durante muchos turnos, y debes tener cierto nivel de confianza en su toma de decisiones.) Confiar no es lo mismo que dar rienda suelta todo el camino, sin embargo. La confianza es lo que le permite caminar la mayoría de los pasos por sí mismo; la compuerta humana vigila los pocos cruces donde el giro equivocado no puede deshacerse.
Tres clases de intervención: interrumpir, dirigir, aprobar
Meter la mano en un bucle no es siempre solo «hacer que se detenga». Ordenadas por lo que el bucle hace después, hay tres movimientos, cada uno cortando en un punto distinto y cambiando algo distinto.
Interrumpir — cancelar todo el bucle. El más brusco de los tres: haga lo que haga el modelo este turno, el bucle termina y no sale ninguna petición más. Se parece a las condiciones de parada de la Lección 3; la diferencia es quién jala el gatillo. Una condición de parada es el arnés jalándose de vuelta por su cuenta según una regla predefinida. Una interrupción es una persona fuera del bucle apretando stop a mano. La usas una vez que puedes ver que la dirección está enteramente equivocada y que continuar solo quema tokens. Después de una interrupción el bucle terminó — no hay «y luego».
Dirigir — cambiar el objetivo o pasarle instrucciones nuevas, y luego dejarlo seguir en marcha. Este no termina nada. Empuja un mensaje humano fresco dentro de la conversación, cambiando hacia qué se inclina el modelo a continuación, y el bucle carga esa instrucción hacia adelante. Digamos que el agente está moliendo un refactor de algún módulo y detectas un bug de producción más urgente. Sin reiniciar el proceso, puedes meter: «pausa el refactor, primero rastrea y arregla ese 500 en el endpoint de login». Dirigir cambia el objetivo del bucle, no si el bucle vive.
Aprobar — dar luz verde a un solo paso; sin asentimiento, no hay acción. Los dos primeros actúan sobre todo el bucle. La aprobación actúa sobre una acción específica: el bucle llega a una operación de alto impacto, se detiene, expone «esto es lo que estoy por hacer», y ejecuta solo si una persona dice que sí — saltándola o cancelándola si dice que no. En realidad es apenas una clase muy disciplinada de pausa: "Agents can then pause for human feedback at checkpoints or when encountering blockers."2 (Los agentes pueden entonces pausar para recibir retroalimentación humana en puntos de control o al encontrar bloqueos.) La aprobación es ese punto de control, clavado con precisión justo delante de las acciones peligrosas. Una vez que la aprobación pasa, el bucle vuelve a su ritmo normal. Es también el más rutinario de los tres, y el que mejor se presta a dejarlo encendido de forma permanente.
Una línea para no confundirlos: una interrupción decide si el bucle vive, dirigir decide hacia dónde apunta el bucle, la aprobación decide si una acción pasa. El arnés mínimo de la Lección 6 es donde la aprobación de verdad se escribe en código.
Escribir la válvula de aprobación en el bucle: detente antes de que la acción aterrice
De los tres, la aprobación es el que más necesita vivir en el código del arnés. Interrumpir y dirigir suelen poder dispararse con una persona tecleando algo en una terminal; la aprobación tiene que ser el arnés deteniéndose activamente en el punto correcto y esperando. Déjala fuera y el bucle simplemente hace la cosa peligrosa.
Una de las mitigaciones de OWASP para la agencia excesiva dice: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken."1 (Utiliza control human-in-the-loop para exigir que una persona apruebe las acciones de alto impacto antes de que se ejecuten.) Fíjate en el orden en esa oración — aprobar antes de que se ejecuten. Aprobar primero, ejecutar segundo; no ejecutar primero y recoger una firma después. Dónde va físicamente la válvula, el estándar lo deja bien abierto: "This may be implemented in a downstream system (outside the scope of the LLM application) or within the LLM extension itself."1 (Esto puede implementarse en un sistema aguas abajo, fuera del alcance de la aplicación del LLM, o dentro de la extensión del LLM misma.) Aterrizada sobre nuestro bucle, la casa natural es el despacho de herramientas — una pausa insertada justo antes de que cualquier herramienta marcada como de alto impacto de verdad se llame.
En código, es una bifurcación puesta delante de la línea que ejecuta la herramienta:
Tres puntos merecen una mirada. Primero, la verificación se sienta antes de executeTool — la pausa tiene que ocurrir antes de que la acción aterrice, para que mientras esperas a una persona, la operación peligrosa todavía no se haya ejecutado. Segundo, una denegación no es un salto silencioso; devuelve un tool_result con is_error puesto (¿recuerdas ese campo de la Lección 2?), para que el modelo aprenda que ese camino está bloqueado y salga a buscar otro enfoque en lugar de proponer la acción idéntica de nuevo el siguiente turno. Tercero, isHighImpact solo detiene las operaciones de alto impacto — leer un archivo, revisar un log y otros movimientos inofensivos pasan intactos. De lo contrario cada paso necesitaría un asentimiento humano y el agente degeneraría en una herramienta manual carísima.
Dónde va la compuerta: antes de que la acción se vuelva irreversible, no después
Esa válvula de aprobación funciona enteramente porque se para en el lugar correcto. Esta sección saca esa regla de ubicación por su cuenta, porque es lo de esta lección que más fácil se recuerda al revés — y lo más costoso de tener al revés.
La regla en una oración: la pausa de aprobación va antes de que la acción se vuelva irreversible, no después. Ya conociste esta idea en el curso anterior «Llamado de herramientas del agente: lograr que los agentes de verdad hagan cosas» — cuanto mayor el radio de impacto de una acción y menos pueda deshacerse, más temprano tiene que sentarse su punto de confirmación. Así aterriza sobre el bucle: la verificación va en la línea de arriba de executeTool, para que durante la espera por una persona la acción destructiva todavía no haya ocurrido. Muévela abajo, y para cuando reaccionas la tabla está eliminada, el correo salió para todos, la config de producción ya cambió — y por más preciso que sea el registro, todo lo que ha hecho es tomarle una foto a los escombros.
¿Cómo detectas lo «irreversible»? Date una prueba contrafactual: si esta acción se ejecuta y está mal, ¿puedo deshacerla en un solo paso? Las cosas que se revierten barato — escribir un archivo temporal, guardar un borrador interno — no necesitan compuerta, o una muy floja. Las cosas que no puedes deshacer, o que solo puedes deshacer a un costo enorme — eliminar una base de datos, mover dinero, publicar hacia afuera, cambiar la config de producción — necesitan la compuerta temprano, y necesitan que sea «aprobado primero, luego hecho». Eso también empalma limpiamente con la Lección 4: aquella lección se trataba de evitar que el bucle queme recursos, esta se trata de evitar que el bucle haga algo que no puede retirarse. La primera es un ritmo saliéndose de control, la segunda es una acción saliéndose de control, y ambas necesitan su compuerta puesta antes de que llegue el «demasiado tarde».
Un detalle que la gente rutinariamente pasa por alto: la compuerta va en el paso más cercano a donde la acción de verdad aterriza. Supón que eliminar la tabla pasa por varias manos — el modelo propone, el arnés despacha, drop_table se llama. No basta con poner la aprobación en el paso «el modelo propone», porque la propuesta misma no hace daño ninguno. Como dijo la Lección 1, "The model never executes anything on its own."3 (El modelo nunca ejecuta nada por sí mismo.) El daño vive en esa llamada final a executeTool. Empuja la compuerta tan hacia el extremo de la ejecución como puedas, y el modelo puede cambiar de opinión y rehacer sus argumentos tantas veces como quiera — todo eso sigue de este lado de la compuerta, donde nadie sale lastimado.
Cómo la Lección 6 pliega las tres en un solo bucle
Alinea esta lección contra las anteriores y el conjunto de controles del arnés queda completo: las condiciones de parada de la Lección 3 (jalarse de vuelta automáticamente cuando es hora), las salvaguardas de desbocamiento de la Lección 4 (detectar bucles muertos y giro en vacío, no quemar el presupuesto), y la aprobación human-in-the-loop de esta lección (una compuerta manual antes de que aterricen acciones peligrosas). No son un elige-una-de-tres. Son tres capas apiladas sobre el mismo bucle — las condiciones de parada gobiernan cuánto dura, las salvaguardas gobiernan qué pasa cuando se sale de rumbo, la aprobación gobierna si este movimiento en particular llega a ocurrir siquiera.
La Lección 6 suelda las tres en un solo arnés mínimo ejecutable: un bucle while con un tope de turnos, detección de giro en vacío, y una válvula de aprobación sobre operaciones de alto impacto. Verás ahí cómo la bifurcación isHighImpact de esta lección, el contador de la Lección 3, y la verificación de progreso de la Lección 4 toman cada uno su propia posición dentro de un solo cuerpo de bucle sin pelearse. Para esta lección, con sostener dos cosas basta: qué cambia cada una de las tres intervenciones, y que la compuerta de aprobación tiene que pararse antes del punto de no retorno.
Resumen
- Cuanto más autónomo el bucle, más necesita una compuerta humana en los puntos críticos: la agencia excesiva significa que la salida inesperada, ambigua o manipulada del modelo puede disparar acciones dañinas que no pueden retirarse1; confiar en un modelo que puede operar durante muchos turnos2 no es lo mismo que darle rienda suelta, y la compuerta humana vigila los pocos cruces donde un giro equivocado no puede deshacerse
- Las tres intervenciones gobiernan cada una una capa distinta: interrumpir actúa sobre si el bucle vive (una persona cancela todo el bucle desde afuera), dirigir actúa sobre hacia dónde apunta (empuja una instrucción nueva, cambia el objetivo, sigue en marcha), aprobar actúa sobre si una acción pasa (pausa antes de una operación peligrosa y espera un asentimiento); la última de esas es exactamente la idea de «pausar para retroalimentación humana en puntos de control»2 clavada delante de las acciones de alto impacto
- La regla dura de la aprobación human-in-the-loop es aprobar primero, ejecutar segundo: las acciones de alto impacto requieren que una persona las apruebe antes de que se ejecuten1, y la válvula puede vivir en un sistema aguas abajo o dentro de la extensión del agente misma1
- La compuerta va antes de que la acción se vuelva irreversible, no después: sentada arriba de
executeTool, la acción destructiva todavía no ha ocurrido mientras esperas a una persona; movida debajo de la ejecución, hasta el log más preciso es rastreo posterior al hecho y no detiene nada de lo que ya aterrizó. Usa la prueba contrafactual para detectar lo «irreversible» — si sale mal, ¿puedo deshacerlo en un solo paso?
- La aprobación de esta lección, las condiciones de parada de la Lección 3, y las salvaguardas de desbocamiento de la Lección 4 son tres capas apiladas sobre el mismo bucle, y la Lección 6 las suelda juntas en un arnés mínimo ejecutable
Lección 6 >>