Bucle del agente AI SDK: demuestre por qué se detuvo

UnAI SDKEl bucle del agente no está en buen estado simplemente porque regresó. Una devolución demuestra que una ruta de flujo de control finalizó: el modelo finalizó sin otra llamada a la herramienta, una herramienta no se pudo ejecutar, se requirió aprobación o se activó una condición de parada configurada. Ninguno de esos hechos prueba que la factura fue creada, el boleto fue actualizado o el informe llegó a su destino. El valor predeterminado práctico es mantener el bucle limitado del SDK, registrar una causa de detención explícita y verificar el resultado externo previsto por separado. Trate una solicitud de aprobación como una espera, un paso o un límite de presupuesto como una parada limitada y un final natural sin una recepción de resultados como una finalización falsa. Esta guía fija el comportamiento en la versión publicada. [email protected] paquete yNode.js22.23.1. La repetición sin contenido adjunta ejerció las funciones de condición de parada exportadas reales en once casos operativos. Se aprobaron las once clasificaciones y cuatro afirmaciones directas del SDK. El SDK puede detenerse por varios motivos legítimos ElGuía de control de bucle AI SDKnombra cuatro rutas de terminación: 1. el modelo devuelve un motivo de finalización distinto a tool calls ; 2. una herramienta llamada no tiene execute función; 3. una llamada de herramienta necesita aprobación; 4. una condición de parada configurada devuelve verdadero. Esas rutas no deberían fusionarse en una completed: true campo. Implican diferentes acciones del operador. Un acabado natural sin herramienta puede ser perfectamente válido para una respuesta de investigación, pero incompleto para un flujo de trabajo cuyo contrato requiere un archivo en el almacenamiento de objetos. una herramienta sin execute puede actuar deliberadamente como una estructura done señal, pero la señal contiene lo que afirma el modelo, no evidencia independiente de que un efecto secundario haya tenido éxito. Una solicitud de aprobación es una pausa intencional. Un límite de paso significa que el límite de seguridad funcionó, no que la tarea falló o tuvo éxito. La documentación actual dice ToolLoopAgent por defecto es isStepCount(20) . Reemplazándolo con isLoopFinished() elimina esa condición de parada del conteo de pasos. Esto puede ser razonable para un experimento local estrictamente controlado, pero también elimina un límite simple en las llamadas y el costo del modelo. Si la solicitud no puede explicar sus controles independientes de fecha límite, presupuesto y cancelación, mantener el límite predeterminado es la decisión más segura. Tres pequeños detalles de implementación cambian el diagnóstico La versión fijadafuente de condición de paradaes lo suficientemente breve como para auditarlo directamente: isStepCount(n) es cierto cuando steps.length === n , no cuando el recuento es mayor o igual a n . hasToolCall(name) inspecciona las llamadas a herramientas en el paso completado más reciente. isLoopFinished() siempre devuelve falso como condición de parada, lo que deja una terminación natural, una herramienta no ejecutada o una aprobación para finalizar el ciclo. Esta semántica es importante a la hora de reconstruir un incidente. Supongamos que una aplicación conserva solo el texto final y el recuento total de pasos. Una carrera de tres pasos que llamó done en su segundo paso no puede demostrar posteriormente que hasToolCall("done") causó la terminación, porque la condición relevante verifica el último paso. Asimismo, una observación de 21 pasos no muestra que isStepCount(20) despedido; es evidencia de que la política configurada, el recuento registrado o el límite de ejecución difieren de la suposición. Mantenga las entradas de condición y la versión de política seleccionada con la ejecución. No los infieras a partir de un panel de control después del hecho. Cree un recibo de parada antes de elegir un estado de salud Un recibo útil es pequeño. No necesita indicaciones, respuestas de modelo ni cargas útiles de herramientas sin procesar: El stopCause debería surgir de la frontera de integración, no de una suposición basada en la prosa final. Registre si la ejecución alcanzó un final sin herramienta, coincidió con una condición de parada especificada, emitió una solicitud de aprobación, invocó una herramienta de finalización no ejecutada, se canceló, se agotó el tiempo de espera o falló en la ejecución de la herramienta. Luego aplique una regla de precedencia: Evidencia Estado Decisión del operador La ejecución de la herramienta falló FAILED Diagnosticar el límite de la herramienta; No vuelva a intentar a ciegas un efecto secundario incierto. La aprobación está pendiente con el propietario, la fecha límite y el token de currículum. WAITING Enrutar la decisión y preservar la reanudabilidad. La aprobación está pendiente sin datos de ruta WAITING UNROUTED Agregue un propietario y una ruta de derivación antes de que la espera se vuelva invisible. El tiempo de espera expiró sin progreso útil STUCK Inspeccione el último progreso duradero y elija una recuperación limitada. Paso, token o aborto de usuario activado rápidamente BOUNDED STOP Preservar el trabajo parcial; decidir si se justifica una nueva ejecución acotada. Acabado natural o explícito done más recibo de resultado VERIFIED COMPLETE Cierra la carrera. Acabado natural o explícito done sin recibo de resultado FALSE COMPLETE Verifique el destino o vuelva a abrir la tarea. Las señales no están de acuerdo o la causa no fue registrada UNCERTAIN Pregunta antes de actuar. El orden importa. Un tiempo de espera en el cuarto paso sigue siendo un tiempo de espera incluso si el recuento de pasos llega a ser cuatro. Una solicitud de aprobación debe permanecer en espera en lugar de caer en un estado genérico incompleto. Un final natural sin entregable debe permanecer falso completo incluso cuando su texto parezca seguro. Reproducir la política sin llamar a un modelo La auditoría importó lo publicado isStepCount , hasToolCall , y isLoopFinished funciones. Pasó matrices sin contenido de registros de pasos completados y unió su salida al clasificador de recibos. No se necesitaba ningún efecto de llamada de modelo, aviso, secreto o herramienta externa. Cuatro afirmaciones establecieron los límites del SDK: La luminaria de once cajas recubrió luego un acabado natural con y sin desenlace, done con y sin resultado, límite de pasos, presupuesto de token, aprobación enrutada y no enrutada, error de herramienta, tiempo de espera y cancelación del usuario. Las parejas reveladoras no fueron fracasos exóticos. Ambos accesorios con acabado natural tenían causas idénticas de control de flujo; sólo el que llevaba un recibo de destino pasó a ser VERIFIED COMPLETE . La misma división apareció para el done herramienta. Ese es el resultado central falsificable: si la terminación del bucle por sí sola demostró ser una finalización útil, esos dispositivos emparejados deberían haber recibido el mismo veredicto saludable. No lo hicieron. Verificar el destino después de que se detenga el flujo de control ElReferencia de ToolLoopAgentexpone los pasos completados en el resultado generado y acepta abortSignal y controles de tiempo de espera. Esos campos son evidencia útil, pero la aplicación aún posee la definición de éxito. Elija el cheque determinista más barato que responda a la solicitud real del usuario: para un archivo, verifique la ruta esperada o la clave de objeto, el tipo de contenido, el tamaño mínimo y un hash o esquema específico de la tarea; para una mutación de base de datos, lea el registro de destino y compare los campos previstos; para un mensaje, conservar el recibo del proveedor y la identidad del destino; para una implementación, verificar la versión inmutable, la respuesta de salud pública y la ruta orientada al usuario; para un análisis, valide las secciones requeridas, la cobertura de la fuente y la salida legible por máquina antes de aceptar la prosa. No haga del recibo de resultado una segunda copia de la afirmación del modelo. {"status":"done"} emitido por el mismo bucle no es una verificación independiente. El recibo debe provenir del destino, de un validador determinista o de una decisión humana cuando el resultado no se puede verificar de forma segura mediante un código. La aprobación también necesita un límite separado. La documentación del SDK muestra que se puede recopilar una solicitud de aprobación, agregarla a la conversación como respuesta de aprobación y pasar a una llamada posterior. Operacionalmente, eso significa que la espera debe conservar suficiente contexto para retomar la misma decisión. Un propietario sin un token de currículum crea un trabajo de reconstrucción manual; un token sin propietario crea una cola invisible. Lo que esta repetición no prueba El experimento no invocó un modelo de proveedor, no transmitió resultados parciales ni ejecutó una herramienta externa. Por lo tanto, no establece un comportamiento de motivo de finalización específico del proveedor, un momento de cancelación de la red o una idempotencia de efectos secundarios. Estos pertenecen a las pruebas de integración en torno al modelo, las herramientas y el destino reales. Tampoco recomienda un paso universal o un límite de token. Una búsqueda de cuatro pasos y una migración de cuarenta pasos tienen envolventes diferentes. El requisito operativo es que los límites seleccionados sean explícitos, registrados y vinculados a una acción segura cuando se alcancen. La regla es más estrecha y duradera: preservar el motivo por el que se detuvo el ciclo, mantener las esperas legítimas distintas de las fallas y exigir evidencia del destino antes de declarar una finalización útil. Sidewispes una plataforma de estado del agente de IA destinada a facilitar la inspección de pruebas, estados de espera, recuperación limitada y verificación de resultados en los tiempos de ejecución existentes. Agente de producción recolección de salud yAI SDKEl monitoreo generalmente no se envía hoy. Sidewisp se encuentra actualmente en versión preliminar privada. Si este recibo de terminación coincide con un modo de falla en sus propios agentes, la lista de espera de vista previa privada es el lugar apropiado para compartir el tiempo de ejecución y el límite de evidencia que necesita.