¿Cómo evita el circuit breaker que una herramienta externa defectuosa se propague en un flujo de trabajo de un agente local?
El circuit breaker contiene una herramienta externa que está fallando al detener las llamadas repetidas, devolver un resultado controlado y comprobar la recuperación antes de restablecer el tráfico normal.
Un agente local puede depender de un modelo en la nube, una API de búsqueda, un servicio de notificaciones o un puente remoto para hogares inteligentes, mientras el resto de su flujo de trabajo funciona correctamente. Sin un límite de contención, una dependencia lenta puede consumir el presupuesto de tiempo del agente y provocar más reintentos. Un circuit breaker convierte esa condición remota incierta en un estado local explícito que el orquestador puede analizar.
El circuit breaker se sitúa entre la selección de la herramienta y la ejecución externa
Normalmente, un agente selecciona una herramienta, valida sus argumentos y entrega la llamada a un ejecutor, mientras que el circuit breaker añade un envoltorio con estado en ese último límite. No cambia lo que solicitó el modelo; decide si el ejecutor debe contactar con la dependencia, rechazar el intento localmente o admitir una sonda de recuperación limitada.
El envoltorio observa las llamadas completadas y clasifica resultados como éxito, tiempo de espera agotado, fallo de transporte, limitación de velocidad u otra señal de fallo configurada. Un patrón de circuit breaker convencional envuelve las llamadas remotas, registra los fallos, se abre después de alcanzar un umbral y posteriormente permite solicitudes de prueba, manteniendo la salud de la dependencia fuera del criterio del modelo al nivel del prompt.
Por tanto, el resultado inmediato no es simplemente una excepción de la herramienta. Es un resultado de orquestación estructurado que contiene el estado del circuit breaker, indica si se intentó la ejecución y especifica qué rutas de continuación siguen permitidas.
Los fallos recientes se comprimen en una transición de estado
Mientras está cerrado, el circuit breaker permite las llamadas y registra solo los resultados relevantes para su política, de modo que un único tiempo de espera agotado no desactive necesariamente una herramienta útil. Las implementaciones suelen evaluar un recuento, una tasa o una ventana temporal recientes, y solo se abren cuando esa evidencia local supera el umbral configurado de fallos o llamadas lentas.
El umbral convierte muchos eventos ruidosos en una decisión de control estable. Un umbral de tasa de errores puede limitar la saturación de conexiones durante un fallo de red, en lugar de permitir que cada operación solicitada establezca otra conexión condenada a fallar.
Lo que cuenta como fallo debe coincidir con el contrato de la herramienta. La denegación de autenticación, los argumentos mal formados y un recurso que falta permanentemente suelen requerir un tratamiento distinto al de la latencia, la indisponibilidad temporal o la limitación de velocidad.
Un umbral porcentual también necesita suficientes observaciones para ser significativo. Abrirse después de un solo fallo vuelve inestable una herramienta de uso ocasional, mientras que esperar una muestra grande puede mantener activa demasiado tiempo una dependencia que falla con frecuencia. Por eso, la ventana de muestreo y el requisito de llamadas mínimas deben formar parte de la política del circuit breaker, no del modelo de lenguaje.
Un circuito abierto convierte la espera remota en un fallo local
Después de que el circuit breaker se abre, el ejecutor deja de contactar con esa dependencia durante un intervalo de enfriamiento explícito, por lo que los nuevos intentos fallan localmente en lugar de esperar otro tiempo de espera remoto. Las herramientas locales saludables, los pasos de recuperación y las rondas de razonamiento pueden continuar sin heredar la latencia de la dependencia fallida.
Esta ruta de fallo rápido contiene tanto la presión sobre los recursos como el retraso, porque las llamadas remotas repetidas pueden mantener ocupados sockets, puestos de trabajo, memoria o tareas en cola mientras esperan. Rechazar las operaciones antes de que asignen más capacidad para llamadas externas reduce el agotamiento de recursos durante una interrupción persistente.
La contención es selectiva, no global. Normalmente, un circuit breaker debe estar limitado a una sola dependencia y, a menudo, a una clase de operación, porque las lecturas y las escrituras pueden tener costes de fallo diferentes.
Los reintentos y los tiempos de espera cambian lo que observa el circuit breaker
Un reintento gestiona un fallo que se considera transitorio, mientras que un circuit breaker recuerda que los fallos se han vuelto lo bastante persistentes como para dejar de intentarlo; por eso, su orden modifica la evidencia que observa el circuit breaker. Los reintentos dentro de una ejecución protegida pueden contabilizarse como una sola llamada lógica, mientras que los reintentos situados fuera del circuit breaker pueden añadir cada uno otra muestra de fallo.
Los tiempos de espera también determinan cuándo una llamada lenta se convierte en una muestra de fallo. Los patrones de resiliencia separan los tiempos de espera, los reintentos y los circuit breakers porque cada control gestiona un límite de fallo diferente.
Esta separación se vuelve fundamental cuando la herramienta tiene efectos secundarios no idempotentes. Los mismos bucles repetidos de llamadas a herramientas pueden originarse en decisiones del modelo o en capas de reintento inferiores al modelo, y un circuit breaker no puede demostrar si una escritura cuyo tiempo de espera se agotó ya modificó el sistema externo.
Por tanto, una ruta de ejecución segura registra por separado el presupuesto de reintentos y el estado del circuit breaker, para que el orquestador pueda explicar si una acción nunca se intentó, se intentó una vez o se bloqueó después de varios fallos de la dependencia.
Las alternativas preservan el significado del flujo sin fingir que la herramienta funcionó
Abrir el circuito solo responde a si puede ejecutarse la herramienta principal, mientras que el orquestador sigue necesitando una política de continuación que preserve la intención del usuario. Según la tarea, puede devolver resultados parciales, usar datos de lectura almacenados en caché, cambiar de proveedor, poner la tarea en cola, solicitar revisión humana o detenerse.
Una alternativa debe incluir metadatos de degradación en lugar de hacerse pasar por el resultado original. Los pasos posteriores pueden restringir las acciones de gran impacto cuando operan con contenido almacenado en caché obsoleto o evidencia sustituida.
Algunas llamadas no tienen una alternativa segura. Una notificación puede ponerse en cola, pero un comando para controlar una puerta no debe sustituirse por un estado supuesto, y una eliminación de copias de seguridad no debe inferirse del inventario almacenado en caché.
Las sondas en estado semiabierto restauran el acceso sin liberar una oleada de reintentos
Un circuito abierto no puede permanecer cerrado al tráfico indefinidamente porque la herramienta externa puede recuperarse; por eso, después de un intervalo de enfriamiento, el circuit breaker admite solo un pequeño número de llamadas de prueba. La carga de trabajo normal sigue bloqueada hasta que esas sondas proporcionan evidencia de que la dependencia puede aceptar tráfico de forma segura otra vez.
Las sondas exitosas hacen que el circuit breaker avance hacia el estado cerrado, mientras que las fallidas vuelven a abrirlo y reinician el periodo de espera. Supervisar los estados del circuit breaker hace visibles las aperturas repetidas y los largos periodos de recuperación, en lugar de ocultarlos dentro de los errores de las herramientas.
Una sonda de estado exitosa no equivale automáticamente a una repetición segura de una escritura anterior. La dependencia puede responder a una comprobación de lectura mientras un efecto secundario anterior sigue siendo ambiguo, por lo que las claves de idempotencia, los puntos de control, la conciliación y los límites de aprobación siguen determinando si las acciones interrumpidas pueden reanudarse.
La admisión de sondas es intencionadamente más limitada que el tráfico normal porque la evidencia de recuperación resulta menos útil si cientos de solicitudes pendientes llegan a la dependencia al mismo tiempo. Limitar las sondas simultáneas evita que el propio circuit breaker provoque la avalancha que haga que una herramienta recién recuperada vuelva a parecer poco saludable.
Productos recomendados
Centro de Tecnología e IA
Más para leer
Estado de ejecución frente a estado persistente en Home Assistant: ¿qué debe sobrevivir al reinicio?
Home Assistant no conserva todos los valores en tiempo real; la configuración, los registros, los estados restaurados seleccionados, el historial y los datos de...
¿Cómo autentica Home Assistant las sesiones locales y remotas?
Las sesiones locales y remotas de Home Assistant utilizan el mismo modelo de identidad del servidor; el acceso remoto cambia la ruta y el...
¿Por qué pueden volverse lentas las consultas del historial de Home Assistant a medida que crecen los datos del grabador?
El crecimiento del grabador puede aumentar el costo de las consultas del historial cuando el rango solicitado abarca más filas, aumentan los fallos de...
