Boucle d'agent AI SDK : prouvez pourquoi elle s'est arrêtée

UnAI SDKla boucle d'agent n'est pas saine simplement parce qu'elle est revenue. Un retour prouve qu'un chemin de flux de contrôle s'est terminé : le modèle s'est terminé sans autre appel d'outil, un outil n'a pas pu s'exécuter, une approbation a été requise ou une condition d'arrêt configurée a été déclenchée. Aucun de ces faits ne prouve que la facture a été créée, que le ticket a été mis à jour ou que le rapport est arrivé à destination. La méthode par défaut pratique consiste à conserver la boucle délimitée du SDK, à enregistrer une cause d'arrêt explicite et à vérifier séparément le résultat externe prévu. Traitez une demande d'approbation comme une attente, une étape ou un plafond budgétaire comme un arrêt limité et une arrivée naturelle sans reçu de résultat comme un faux achèvement. Ce guide épingle le comportement à la version publiée [email protected] paquet etNode.js22.23.1. La rediffusion sans contenu qui l'accompagne a utilisé les fonctions de condition d'arrêt réellement exportées dans onze cas opérationnels. Les onze classifications et quatre assertions directes du SDK ont été réussies. Le SDK peut s'arrêter pour plusieurs raisons légitimes LeGuide de contrôle de boucle du SDK AInomme quatre itinéraires de terminaison : 1. le modèle renvoie une raison de fin autre que tool calls ; 2. un outil appelé n'a pas execute fonction; 3. un appel d'outil doit être approuvé ; 4. une condition d'arrêt configurée renvoie vrai. Ces routes ne devraient pas être fusionnées en une seule completed: true champ. Ils impliquent différentes actions de l’opérateur. Une finition naturelle sans outil peut être parfaitement valable pour une réponse de recherche, mais incomplète pour un workflow dont le contrat nécessite un fichier en stockage objet. Un outil sans execute peut délibérément agir comme un organisme structuré done signal, mais le signal contient ce que le modèle prétendait : pas une preuve indépendante qu'un effet secondaire a réussi. Une demande d'approbation est une pause intentionnelle. Un plafond de marche signifie que la limite de sécurité a fonctionné, et non que la tâche a échoué ou réussi. La documentation actuelle dit ToolLoopAgent par défaut isStepCount(20) . Le remplacer par isLoopFinished() supprime cette condition d’arrêt du nombre de pas. Cela peut être raisonnable pour une expérience locale étroitement contrôlée, mais cela supprime également une simple limite sur les appels de modèle et le coût. Si la candidature ne peut pas expliquer ses contrôles indépendants de délai, de budget et d’annulation, conserver le plafond par défaut est la décision la plus sûre. Trois petits détails de mise en œuvre changent le diagnostic La version épingléesource de condition d'arrêtest suffisamment court pour auditer directement : isStepCount(n) est vrai quand steps.length === n , pas lorsque le nombre est supérieur ou égal à n . hasToolCall(name) inspecte les appels d’outils lors de l’étape terminée la plus récente. isLoopFinished() renvoie toujours false comme condition d'arrêt, laissant une terminaison naturelle, un outil non exécuté ou une approbation pour terminer la boucle. Cette sémantique est importante lors de la reconstruction d’un incident. Supposons qu'une application conserve uniquement le texte final et le nombre total d'étapes. Une course en trois étapes qui a appelé done à sa deuxième étape ne peut pas prouver plus tard que hasToolCall("done") a provoqué l'arrêt, car la condition pertinente vérifie la dernière étape. De même, une observation de 21 étapes ne montre pas que isStepCount(20) licencié; cela prouve que la politique configurée, le nombre enregistré ou la limite d’exécution diffèrent de l’hypothèse. Conservez les entrées de condition et la version de stratégie sélectionnée avec l’exécution. Ne les déduisez pas d’un tableau de bord après coup. Construire un reçu d'opposition avant de choisir un état de santé Un reçu utile est petit. Il n'a pas besoin d'invites, de réponses de modèle ou de charges utiles d'outils bruts : Le stopCause devrait provenir de la limite d’intégration, et non d’une supposition basée sur la prose finale. Enregistrez si l'exécution a atteint une fin sans outil, a répondu à une condition d'arrêt nommée, a émis une demande d'approbation, a appelé un outil d'achèvement non exécuté, a été abandonnée, a expiré ou a échoué dans l'exécution de l'outil. Appliquez ensuite une règle de priorité : Preuve État Décision de l'opérateur L'exécution de l'outil a échoué FAILED Diagnostiquer la limite de l'outil ; ne réessayez pas aveuglément un effet secondaire incertain. L'approbation est en attente avec le propriétaire, la date limite et le jeton de reprise WAITING Acheminez la décision et préservez la possibilité de reprise. L'approbation est en attente sans données de routage WAITING UNROUTED Ajoutez un propriétaire et un chemin d’escalade avant que l’attente ne devienne invisible. Délai d'attente expiré sans progrès utile STUCK Inspectez les derniers progrès durables et choisissez une récupération limitée. Déclenchement d'une étape, d'un jeton ou d'un abandon par l'utilisateur BOUNDED STOP Préserver le travail partiel ; décider si une nouvelle exécution limitée est justifiée. Finition naturelle ou explicite done plus reçu du résultat VERIFIED COMPLETE Fermez la course. Finition naturelle ou explicite done sans reçu de résultat FALSE COMPLETE Vérifiez la destination ou rouvrez la tâche. Les signaux ne sont pas d'accord ou la cause n'a pas été enregistrée UNCERTAIN Demandez avant d'agir. L’ordre compte. Un délai d'attente sur la quatrième étape reste un délai d'attente même si le nombre d'étapes est égal à quatre. Une demande d’approbation doit rester en attente plutôt que d’être entraînée dans un état générique incomplet. Une finition naturelle sans livrable doit rester faussement complète même lorsque son texte semble confiant. Rejouer la politique sans appeler de modèle L'audit a importé les données publiées isStepCount , hasToolCall , et isLoopFinished fonctions. Il transmettait des tableaux sans contenu d'enregistrements d'étapes terminées et joignait leur sortie au classificateur de reçus. Aucun appel de modèle, invite, secret ou effet d'outil externe n'était nécessaire. Quatre affirmations ont établi la limite du SDK : Le luminaire à onze boîtiers a ensuite recouvert une finition naturelle avec et sans résultat, done avec et sans résultat, plafond d'étape, budget de jetons, approbation acheminée et non acheminée, erreur d'outil, délai d'attente et abandon de l'utilisateur. Les paires révélatrices n’étaient pas des échecs exotiques. Les deux luminaires à finition naturelle avaient des causes de contrôle de flux identiques ; seul celui porteur d'un récépissé de destination est devenu VERIFIED COMPLETE . La même scission est apparue pour le done outil. C'est le résultat principal falsifiable : si la terminaison de la boucle à elle seule s'est avérée utile, ces appareils appariés auraient dû recevoir le même verdict sain. Ils ne l’ont pas fait. Vérifier la destination après l'arrêt du flux de contrôle LeRéférence de ToolLoopAgentexpose les étapes terminées sur le résultat généré et accepte abortSignal et des contrôles de délai d'attente. Ces champs sont des preuves utiles, mais l’application possède toujours la définition du succès. Choisissez la vérification déterministe la moins chère qui répond à la demande réelle de l'utilisateur : pour un fichier, vérifiez le chemin d'accès ou la clé d'objet attendu, le type de contenu, la taille minimale et un hachage ou un schéma spécifique à la tâche ; pour une mutation de base de données, lire l'enregistrement de destination et comparer les champs prévus ; pour un message, conserver le reçu du fournisseur et l'identité de la destination ; pour un déploiement, vérifiez la version immuable, la réponse de santé publique et l'itinéraire destiné à l'utilisateur ; pour une analyse, validez les sections requises, la couverture des sources et la sortie lisible par machine avant d'accepter la prose. Ne faites pas du reçu de résultat une deuxième copie de l'assertion du modèle. {"status":"done"} émis par la même boucle n’est pas une vérification indépendante. Le reçu doit provenir de la destination, d'un validateur déterministe ou d'une décision humaine lorsque le résultat ne peut pas être vérifié en toute sécurité par code. L'approbation nécessite également une limite distincte. La documentation du SDK montre qu'une demande d'approbation peut être collectée, ajoutée à la conversation en tant que réponse d'approbation et transmise à un appel ultérieur. Sur le plan opérationnel, cela signifie que l'attente doit conserver suffisamment de contexte pour reprendre la même décision. Un propriétaire sans jeton de CV crée un travail de reconstruction manuel ; un jeton sans propriétaire crée une file d'attente invisible. Ce que cette rediffusion ne prouve pas L’expérience n’a pas invoqué de modèle de fournisseur, n’a pas diffusé de sortie partielle ni exécuté d’outil externe. Il n’établit donc pas de comportement de motif d’arrivée spécifique au fournisseur, de délai d’annulation du réseau ou d’idempotence des effets secondaires. Ceux ci appartiennent aux tests d’intégration autour du modèle, des outils et de la destination réels. Il ne recommande pas non plus une étape universelle ou une limite de jetons. Une recherche en quatre étapes et une migration en quarante étapes ont des enveloppes différentes. L'exigence opérationnelle est que les limites sélectionnées soient explicites, enregistrées et liées à une action sûre une fois atteintes. La règle est plus étroite et plus durable : préserver la raison pour laquelle la boucle s'est arrêtée, distinguer les attentes légitimes des échecs et exiger des preuves de destination avant de déclarer un achèvement utile. Sidewispest une plateforme d'intégrité des agents d'IA destinée à faciliter l'inspection des preuves, des états d'attente, de la récupération limitée et de la vérification des résultats dans les environnements d'exécution existants. Agent de production collecte sanitaire etAI SDKLes produits de surveillance ne sont généralement pas expédiés aujourd'hui. Sidewisp est actuellement en préversion privée. Si ce reçu de résiliation correspond à un mode de défaillance de vos propres agents, la liste d'attente en préversion privée est l'endroit approprié pour partager le temps d'exécution et les limites de preuves dont vous avez besoin.