Aucune donnée de tableau
Une tâche du monde réel comporte un objectif vérifiable, des contraintes définissant ce qui est acceptable et un état externe susceptible de changer pendant l’exécution du système. Un objectif sans mécanisme de vérification se transforme en une conversation sans fin, car rien dans le système ne permet de confirmer son achèvement.
Le périmètre se limite à la plus petite boucle capable d’agir, de vérifier et de s’arrêter.
Un objectif devient opérationnel uniquement s’il est associé à un signal d’achèvement qu’un programme peut évaluer (par exemple, l’écriture d’un fichier, la mise à jour d’un statut ou le remplissage d’un ensemble de champs). Les contraintes restreignent l’éventail des résultats acceptables ; il peut s’agir d’une date butoir, d’un budget d’appels API, d’un format imposé ou d’une règle bloquant certaines actions.
L’état externe désigne toute dépendance située en dehors de l’appel au modèle, comme une ligne de base de données, une file d’attente de tickets, une page web ou un événement d’agenda. Lorsque l’état externe change, un plan initialement valide peut devenir erroné sans qu’aucune erreur de code ne survienne.
Règle Si vous ne pouvez pas définir une vérification déterministe de l’achèvement, considérez la tâche comme étant à durée indéterminée et ajoutez une limite d’arrêt ainsi qu’une étape de validation humaine.
L’architecture minimale consiste en une boucle qui fait transiter les données à travers des étapes fixes et enregistre les modifications survenues à chaque étape. La boucle part d’une entrée, lit et met à jour l’état, sollicite un modèle pour proposer l’action suivante, exécute les appels d’outils modifiant l’état externe, puis évalue une condition d’arrêt avant de recommencer le cycle.
Interagissez avec le schéma du pipeline pour suivre les données entrant dans chaque étape ainsi que les résultats renvoyés par celle-ci.
Une fois la boucle établie, chaque défaillance peut être localisée. Un échec de récupération se manifeste par des entrées manquantes lors de l’appel au modèle, une erreur d’outil par une exception ou une réponse autre que le code 200, et un bug dans la condition d’arrêt par des itérations répétées sans progression de l’état.
Une tâche de rédaction de rapport de recherche s’achève généralement lorsque le document respecte les exigences de formatage et de citation ainsi qu’une vérification de validation (par exemple, s’assurer que chaque affirmation dispose d’une URL source dans le fichier de notes). Les outils utilisés incluent souvent la recherche, l’analyse de documents et l’écriture de fichiers ; la maîtrise des coûts repose principalement sur la limitation de la navigation et de l’expansion du contexte.
Une tâche de tri de tickets se termine lorsque chaque ticket a été étiqueté, acheminé et accompagné d’un bref commentaire explicatif, et que le système de gestion des tickets a confirmé la mise à jour. Les outils impliquent souvent une API de gestion des tickets, un vérificateur de règles et parfois une consultation de base de connaissances interne ; la fiabilité repose sur la prévention des mises à jour erronées.
Comparez ces deux tâches en sélectionnant les contraintes, les outils et les indicateurs d’achèvement, et observez comment la condition d’arrêt évolue.