Planifier et réviser

Ce que vous saurez faire

Laissez l’agent écrire les étapes qu’il lui reste à faire, pour pouvoir vérifier chacune. Observez ensuite comment il les change quand un résultat d’outil montre que sa première idée était fausse.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 50 minutes

Ce que vous devez savoir

• Le TaskState d’une exécution et ses événements, présentés dans Un état de tâche explicite.
• Les outils de lecture et leurs refus, présentés dans Contrats d’outils.
• La boucle et ses raisons d’arrêt (max_steps, repeated_call, too_many_errors …), présentées dans Contrôler la boucle d’exécution.

Ce qu’il vous faut sur votre ordinateur

• Le projet resolution-workflow à la fin du module 2, après Contrôler la boucle d’exécution : faire terminer la boucle dans le projet, avec son environnement virtuel activé. python -m pytest affiche 35 passed (35 tests réussis).
• Si vous avez sauté le module 2, copiez l’instantané end-of-m02 du dépôt d’exercices (nextia-learning-labs/C10/snapshots/). Créez l’environnement virtuel comme l’indique son README.
• Si vous avez conservé tests/test_my_loop.py de l’exercice du module 2, chaque compte de tests de ce module augmente de 4 : 39 passed ici.

Cette leçon ajoute un fichier de tests. Vous n’avez besoin ni de compte ni de clé : chaque décision du modèle ci-dessous est un enregistrement.

Une liste de courses pour le samedi

Samedi matin, vous écrivez une courte liste : poster le colis, récupérer les médicaments, acheter la nourriture de la semaine. Chaque ligne a une fin claire. Vous avez un reçu, vous avez un sac en papier, le réfrigérateur est plein. Vous savez donc à tout moment quelles lignes sont terminées.

Au bureau de poste, une affiche indique « Fermé aujourd’hui ». Vous ne rentrez pas chez vous. Vous changez la liste : « poster le colis au magasin sur Elm Road ». Vous placez cette étape en dernier, car ce magasin est près du supermarché. Le but reste le même. La liste a changé, parce que le monde vous a appris quelque chose.

Deux choses rendaient cette liste utile. Chaque ligne pouvait être vérifiée, et vous l’avez changée quand un fait vous a surpris. Une liste qui dit « être utile aujourd’hui » n’a ni l’une ni l’autre. Personne ne peut dire quand elle est terminée, et aucune porte fermée ne peut la changer.

Le problème : des étapes que personne ne peut vérifier

L’agent de ce cours décide lui-même de ses lectures. Avec chat-strong et le modèle local gemma3:4b, le projet utilise la conception agent_structured. À chaque étape, le modèle répond avec un seul objet JSON. Un de ses champs est plan, « les étapes restantes, en bref ». Vous l’avez vu dans la trace de Contrôler la boucle d’exécution.

Voici le billet de soutien de cette leçon, T-80009, tiré du cours Créer des applications fiables avec les API de LLM :

My order LK-55190 never arrived. It was a bag of potting soil and two trowels. Can you check?

L’identifiant de commande a cinq chiffres, pas six. Les identifiants de Larkfield comprennent LK- et six chiffres, donc get_order le refusera. La vraie commande du client est LK-551906. Voici l’exécution enregistrée de gemma3:4b, un petit modèle qui fonctionne sur votre ordinateur :

python -m resolver run T-80009 --variant agent_structured --model gemma3:4b --trace

Run T-80009-agent_structured-gemma3:4b | single agent with one JSON step per call (for models without tool calling) | gemma3:4b
Stopped: repeated_call. No proposal: the ticket goes to a person.

Run T-80009-agent_structured-gemma3:4b: agent_structured, gemma3:4b, ticket T-80009, status stopped
6 model call(s), 13940 tokens in, 244 out, US$0.00000, 10.484 s waiting for the model

  1  plan      ["check order status"]
  1  model     gemma3:4b: get_order({"order_id": "LK-55190"})  (1899 in, 39 out, 1.594 s)
  1  tool      get_order({"order_id": "LK-55190"}) -> REFUSED invalid_arguments: Invalid arguments for get_order: order_id: String should ma…
  2  model     gemma3:4b: search_policy({"query": "invalid order id"})  (1982 in, 37 out, 1.436 s)
  2  tool      search_policy({"query": "invalid order id"}) -> ok
  3  plan      ["w3 lost"]
  3  model     gemma3:4b: get_order({"order_id": "LK-55190"})  (2294 in, 41 out, 2.065 s)
  3  tool      get_order({"order_id": "LK-55190"}) -> REFUSED invalid_arguments: Invalid arguments for get_order: order_id: String should ma…
  4  plan      ["ask_customer"]
  4  model     gemma3:4b: get_customer_orders({})  (2383 in, 43 out, 1.523 s)
  4  tool      get_customer_orders({}) -> ok
  5  plan      ["w3 lost"]
  5  model     gemma3:4b: get_order({"order_id": "LK-551906"})  (2507 in, 42 out, 1.705 s)
  5  tool      get_order({"order_id": "LK-551906"}) -> ok
  6  plan      ["w2 late"]
  6  model     gemma3:4b: get_order({"order_id": "LK-551906"})  (2875 in, 42 out, 2.161 s)
  6  stop      repeated_call
  6  stop      repeated_call

C’est l’enregistrement de T-80009 dans le projet, celui que la commande rejoue. Cette exécution diffère de celle de l’explorateur de Contrôler la boucle d’exécution, donc ses appels diffèrent. Une trace affiche une ligne plan seulement quand le plan change. L’étape 2 conserve donc le plan de l’étape 1.

Lisez les lignes du plan de haut en bas. « w3 lost » est une hypothèse sur une règle, pas une étape : aucun résultat d’outil ne peut la terminer. À l’étape 4, le plan dit « ask_customer », mais l’appel est get_customer_orders. À l’étape 3, le modèle envoie encore l’identifiant refusé. Le plan et les actions ne concordent pas. La règle des appels répétés a arrêté l’exécution après six appels, et une personne reçoit le billet. La boucle a fait son travail; le plan n’a pas aidé.

L’idée : des étapes vérifiables, révisées selon les preuves

Un plan est la liste des étapes que l’agent compte encore faire, écrite dans un texte que vous pouvez lire. Planifier, c’est écrire cette liste avant d’agir. Réviser (ou replanifier), c’est changer la liste quand un résultat montre qu’une hypothèse était fausse.

Une étape est utile quand elle peut être vérifiée : vous pouvez nommer le résultat d’outil qui la termine. « Vérifier la commande et les détails de livraison » se termine quand get_order renvoie la commande avec sa date expected_by. « w3 lost » ne nomme aucune preuve, donc rien ne peut la terminer.

Le plan est un champ de la réponse du modèle, comme le nom de l’outil. Ce n’est pas le raisonnement caché du modèle. Certains modèles réfléchissent avec des jetons (tokens) que vous ne voyez jamais. Ce cours ne les utilise pas et n’en a pas besoin. Tout dans cette leçon est observable : le texte du plan, l’appel d’outil, le résultat.

Les modèles changent vite, et un petit modèle plus récent pourrait mieux planifier que gemma3:4b. La méthode de cette leçon reste valable : lisez le plan à côté des preuves, étape par étape.

Un petit exemple détaillé : T-80009 avec chat-strong

Voici le même billet avec chat-strong (gpt-6.1-sol sur Azure), dans le premier de ses enregistrements répétés. Lancez-le :

python -m resolver run T-80009 --variant agent_structured --model chat-strong --trace

Run T-80009-agent_structured-chat-strong | single agent with one JSON step per call (for models without tool calling) | chat-strong
Outcome: reply_only (rule W1) | 4 model call(s), 3 tool call(s) | 9464 tokens in, 326 out | US$0.02219
Reply draft: I found your order as LK-551906, containing one 40 L bag of potting soil and two trowels. It shipped on September 29 and is still marked in transit. Its expected delivery date was October 6, so it is now 3 business days late. The latest tracking scan was September 29. Please allow a little more time; if it still hasn’t arrived after it is more than 5 business days late, contact us again so we can review the next steps.

Run T-80009-agent_structured-chat-strong: agent_structured, chat-strong, ticket T-80009, status done
4 model call(s), 9464 tokens in, 326 out, US$0.02219, 9.497 s waiting for the model

  1  plan      ["Check the order and delivery details.", "Apply the delivery policy and draft a reply."]
  1  model     chat-strong: get_order({"order_id": "LK-55190"})  (2163 in, 48 out, 2.352 s)
  1  tool      get_order({"order_id": "LK-55190"}) -> REFUSED invalid_arguments: Invalid arguments for get_order: order_id: String should ma…
  2  plan      ["Find the customer's order using the products mentioned.", "Check delivery details and apply the delivery po…
  2  model     chat-strong: get_customer_orders({})  (2253 in, 48 out, 1.662 s)
  2  tool      get_customer_orders({}) -> ok
  3  plan      ["Check delivery details for the matching order.", "Apply the delivery policy and draft a reply."]
  3  model     chat-strong: get_order({"order_id": "LK-551906"})  (2367 in, 49 out, 1.589 s)
  3  tool      get_order({"order_id": "LK-551906"}) -> ok
  4  plan      []
  4  model     chat-strong: finish({"outcome": "reply_only", "rule": "W1",…)  (2681 in, 181 out, 3.894 s)
  4  proposal  reply_only (W1): no change
  4  stop      finished

L’image suit l’exécution de gauche à droite. Chaque case représente une étape : le plan écrit par le modèle, son appel et le résultat renvoyé par l’application.

T-80009 avec chat-strong (gpt-6.1-sol sur Azure, enregistré) : le plan change deux fois, chaque fois après un résultat d'outil. La case en pointillé est l'appel refusé.

Description textuelle du diagramme

Étape 1. Le plan a deux étapes : vérifier la commande et les détails de livraison; appliquer la politique de livraison et rédiger une réponse. L’appel get_order avec LK-55190 est refusé, car l’identifiant ne comprend pas LK- et 6 chiffres.

Étape 2. Un nouveau plan : trouver la commande du client à partir des produits mentionnés; vérifier les détails de livraison et appliquer la politique de livraison. L’appel get_customer_orders renvoie une commande, LK-551906, avec du terreau et un transplantoir.

Étape 3. Le plan : vérifier les détails de livraison de la commande correspondante; appliquer la politique de livraison et rédiger une réponse. L’appel get_order avec LK-551906 renvoie la commande : livraison prévue au plus tard le 6 octobre, 3 jours ouvrables de retard.

Étape 4. Le modèle termine avec reply_only, règle W1. Le plan est maintenant vide.

Suivez les preuves qui ont changé chaque plan :

1. Étape 1. Le plan suppose que LK-55190 est une vraie commande. L’application refuse l’identifiant avant toute recherche.
2. Étape 2. Ce refus invalide l’hypothèse, donc la première étape change. « Trouver la commande du client à partir des produits mentionnés » peut être vérifié. get_customer_orders renvoie la liste, et une commande contient du terreau et un transplantoir.
3. Étape 3. La commande est maintenant connue, donc le plan nomme « la commande correspondante ». get_order termine l’étape avec business_days_late: 3.
4. Étape 4. Il ne reste rien, donc le plan est vide et le modèle termine. La règle W2 exige plus de 5 jours ouvrables de retard. Un retard de 3 jours donne donc une réponse sur l’état de la commande (W1).

La trace coupe les longs plans à 110 caractères. Pour lire chaque plan au complet, consultez le TaskState de l’exécution. Lancez Python dans le dossier du projet avec python, puis collez ces lignes. Appuyez sur Entrée jusqu’au retour de l’invite >>> :

from resolver.data import load_task
from resolver.evaluate import run_and_score
from resolver.providers import MockProvider
task = load_task("T-80009")
score, state = run_and_score(task, "agent_structured", "chat-strong", MockProvider().complete)
for event in state.events:
    if event.kind == "plan":
        print(event.step, event.detail["plan"])

print("Current plan:", state.plan)

1 ['Check the order and delivery details.', 'Apply the delivery policy and draft a reply.']
2 ["Find the customer's order using the products mentioned.", 'Check delivery details and apply the delivery policy.']
3 ['Check delivery details for the matching order.', 'Apply the delivery policy and draft a reply.']
4 []
Current plan: []

Tapez exit() pour quitter Python. run_and_score exécute la tâche sur une nouvelle copie de la base de données d’exercice, comme le fait eval. La boucle enregistre un événement plan seulement quand le plan change. Les quatre lignes sont donc les quatre versions du plan, et state.plan contient la dernière.

Voici la même idée sous forme de tableau. Chaque étape d’un bon plan nomme la preuve qui la termine :

Étape du plan (chat-strong)	Se termine quand	Terminée dans cette exécution?
Vérifier la commande et les détails de livraison	get_order renvoie la commande	non : l’identifiant a été refusé
Trouver la commande du client à partir des produits mentionnés	get_customer_orders liste une commande contenant ces produits	oui, LK-551906
Vérifier les détails de livraison de la commande correspondante	get_order renvoie expected_by et business_days_late	oui, 3 jours de retard
Appliquer la politique de livraison et rédiger une réponse	finish avec une résolution que l’application accepte	oui, W1

Un plan est une hypothèse

Les enregistrements comprennent trois répétitions de chat-strong pour chaque billet. La répétition 3 de T-80009 n’a même pas essayé l’identifiant trop court :

python -m resolver run T-80009 --variant agent_structured --model chat-strong --repeat 3 --trace

La partie de la sortie contenant la trace :

  1  plan      ["Find the customer's order because the supplied ID is incomplete.", "Check delivery evidence and apply the a…
  1  model     chat-strong: get_customer_orders({})  (2163 in, 50 out, 1.716 s)
  1  tool      get_customer_orders({}) -> ok
  2  plan      ["Check the order's tracking and delivery dates.", "Determine the appropriate delivery resolution."]
  2  model     chat-strong: get_order({"order_id": "LK-551906"})  (2279 in, 47 out, 1.698 s)
  2  tool      get_order({"order_id": "LK-551906"}) -> ok
  3  plan      []
  3  model     chat-strong: finish({"outcome": "reply_only", "rule": "W1",…)  (2591 in, 183 out, 3.716 s)
  3  proposal  reply_only (W1): no change
  3  stop      finished

Cette exécution a immédiatement remarqué l’identifiant trop court et économisé un appel : 7 033 jetons d’entrée au lieu de 9 464. Les deux exécutions ont produit la même réponse correcte. Un plan est la meilleure hypothèse du modèle au départ. Un bon agent n’a pas besoin d’une première hypothèse parfaite. Il a besoin d’étapes qu’un résultat peut confirmer ou invalider.

À quelle fréquence les plans changent

Les plans ne changent pas toujours beaucoup. Sur les 210 exécutions enregistrées de chat-strong (70 billets, trois répétitions), la plupart ont écrit un seul plan sans le changer :

Plans non vides par exécution, chat-strong comme agent structuré, 210 exécutions enregistrées. Aucun plan : l'exécution s'est terminée ou arrêtée à sa première étape.

Description textuelle du graphique

Un graphique à colonnes. Aucun plan : 46 exécutions. Un plan : 124 exécutions. Deux plans : 36 exécutions. Trois plans : 4 exécutions.

Les 46 exécutions sans plan se sont terminées à l’étape 1. Dans 42 cas, le modèle a immédiatement transmis le billet à une personne. Les règles H1 à H5 s’appliquaient, ou la demande ne correspondait pas aux six types du flux de travail. Une exécution a répondu, et le filtre de contenu du fournisseur en a arrêté trois. Ensuite, 124 exécutions ont conservé leur premier plan jusqu’à la fin.

Dans 40 exécutions, le modèle a remplacé un plan non vide par un autre. Certaines l’ont révisé deux fois, ce qui donne 44 révisions. Parmi elles, 11 suivaient immédiatement un résultat d’outil en échec ou refusé, comme pour T-80009. Les 33 autres suivaient un résultat réussi qui changeait la situation.

T-90201 est l’un de ces 33 cas. Le client pose une question sur deux commandes. Après le premier get_order, le plan gagne une étape : « Proposer le remboursement admissible pour livraison tardive et rédiger une réponse couvrant les deux commandes. » La première commande avait 13 jours ouvrables de retard. C’est plus de 5, donc la règle W2 s’applique et les frais sont remboursés.

Qui vérifie le plan

Le plan est un texte écrit par un modèle. L’application ne le traite jamais comme un fait. Trois éléments du projet font plutôt la vérification :

• Les contrats d’outils vérifient chaque appel, peu importe ce que dit le plan (Contrats d’outils).
• Les preuves dans TaskState contiennent seulement les résultats que l’application a réellement reçus. Le modèle ne peut pas ajouter de preuve en écrivant « terminé » dans un plan.
• La vérification de la résolution refuse une action sur une commande qu’aucun outil n’a renvoyée dans cette tâche.

À quoi sert donc le plan? D’abord, il sert aux personnes qui lisent la trace. Grace, qui approuve les changements de Larkfield, veut savoir pourquoi l’agent a consulté LK-551906 alors que le client avait écrit LK-55190. Le plan répond en une ligne : « Trouver la commande du client à partir des produits mentionnés ». Ensuite, il aide le modèle, car ses propres réponses précédentes restent devant lui lors du prochain appel. La prochaine leçon examine ce contexte.

Quand planifier, quand s’en passer et à quel coût

Le flux de travail fixe et le routeur de Modèles courants n’ont pas de plan. Le code choisit leurs étapes, qui restent donc toujours identiques et vérifiables. Choisissez-les quand le chemin ne dépend pas de ce que vous trouvez.

Un plan est utile quand la prochaine lecture dépend du dernier résultat : un mauvais identifiant, deux commandes, un service défaillant. T-90602 montre ce dernier cas. Le service de paiement répond HTTP 503 (une défaillance simulée). Le nouveau plan de chat-strong a deux étapes. La première est « Réessayer la vérification du paiement une fois ». La seconde est « Appliquer la politique de double facturation si des preuves sont disponibles; sinon transmettre à une personne ». Il réessaie une fois, échoue encore et transmet le billet à une personne. Ce plan nomme sa propre sortie.

Un plan coûte des jetons de sortie. Dans T-80009, le plan occupe 88 des 169 caractères de la première réponse du modèle. Surtout, planifier davantage ne donne pas un meilleur travail. gemma3:4b a changé son plan dans 69 de ses 70 exécutions et correctement traité 28 billets sur 70. chat-strong l’a changé dans 40 de ses 210 exécutions et en a correctement traité 70, 69 et 69. Comptez les preuves qu’un plan utilise, pas le nombre de plans.

Exercice guidé : lire les plans et vérifier leur fiabilité

1. Vérifiez votre point de départ. Dans le dossier du projet, avec l’environnement virtuel activé, lancez :

   python -m pytest

   La commande affiche 35 passed.

2. Lancez les trois traces de T-80009 de cette leçon, si vous ne l’avez pas encore fait. Ce sont chat-strong répétition 1, chat-strong répétition 3 et gemma3:4b. Comparez les lignes du plan aux lignes des outils.

3. Créez le fichier tests/test_context.py avec ce test. Il vérifie une règle de TaskState : l’état contient seulement le plan actuel, et la trace conserve les anciens.

   tests/test_context.py

   """Working context: the ticket is marked as data, and the state keeps only the current plan."""
   
   from resolver.data import load_task
   from resolver.evaluate import run_and_score
   from resolver.providers import MockProvider
   
   
   def test_the_state_keeps_the_current_plan_and_the_trace_keeps_the_old_ones():
       """chat-strong writes a plan at every step (recorded); the state holds only the last one."""
       task = load_task("T-90201")
       _, state = run_and_score(task, "agent_structured", "chat-strong", MockProvider().complete)
       plans = [e for e in state.events if e.kind == "plan"]
       assert len(plans) >= 2
       assert state.plan == plans[-1].detail["plan"]

4. Relancez les tests :

   python -m pytest

   La commande affiche 36 passed (36 tests réussis).

La prochaine leçon ajoute un deuxième test au même fichier et explique pourquoi l’état conserve seulement un plan.

À vous de jouer : placer chaque plan à côté de son action

Écrivez une petite fonction plan_and_actions(task_id, model, repeat=1). Elle affiche une ligne par appel d’outil : la première étape du plan à ce moment, l’outil et ok (réussite) ou le code de refus. Lancez-la dans Python pour T-80009 avec chat-strong et avec gemma3:4b. Avant de la lancer, faites une prédiction : à quelles étapes le plan et l’action de gemma3:4b seront-ils en désaccord?

Afficher un exemple de réponse

Collez ceci dans Python, dans le dossier du projet :

from resolver.data import load_task
from resolver.evaluate import run_and_score
from resolver.providers import MockProvider
def plan_and_actions(task_id, model, repeat=1):
    task = load_task(task_id)
    _, state = run_and_score(task, "agent_structured", model, MockProvider().complete, repeat=repeat)
    plan = []
    for event in state.events:
        if event.kind == "plan":
            plan = event.detail["plan"]
        elif event.kind == "tool":
            first = plan[0] if plan else "(no plan)"
            result = "ok" if event.detail["ok"] else event.detail["code"]
            print(f"step {event.step}: {first!r:<62} -> {event.name} {result}")
    print("Stopped:" if state.stop_reason != "finished" else "Finished:", state.stop_reason, state.status)

plan_and_actions("T-80009", "chat-strong")
plan_and_actions("T-80009", "gemma3:4b")

step 1: 'Check the order and delivery details.'                        -> get_order invalid_arguments
step 2: "Find the customer's order using the products mentioned."      -> get_customer_orders ok
step 3: 'Check delivery details for the matching order.'               -> get_order ok
Finished: finished done
step 1: 'check order status'                                           -> get_order invalid_arguments
step 2: 'check order status'                                           -> search_policy ok
step 3: 'w3 lost'                                                      -> get_order invalid_arguments
step 4: 'ask_customer'                                                 -> get_customer_orders ok
step 5: 'w3 lost'                                                      -> get_order ok
Stopped: repeated_call stopped

Le plan et les actions de chat-strong concordent à chaque étape. Ceux de gemma3:4b divergent aux étapes 2, 3 et 4. À l’étape 2, le plan n’a pas changé après le refus, mais le modèle a cherché dans la politique. À l’étape 3, le plan nomme une règle, et l’appel répète l’identifiant refusé. À l’étape 4, le plan dit « ask_customer », et l’appel recherche des commandes. Essayez aussi T-90602 et T-90201 avec chat-strong. Chaque plan change après un résultat, et la nouvelle première étape correspond à l’appel suivant.

Erreur courante

« Le plan dit que la commande a été vérifiée »

Symptôme : Tomás veut montrer le plan à la personne qui approuve comme une liste de vérification. « L’agent a écrit “Vérifier les détails de livraison”, puis a retiré cette étape. Les détails de livraison ont donc été vérifiés. » Mais dans l’exécution de gemma3:4b, l’étape 4 dit « ask_customer » alors que l’appel est get_customer_orders. Le plan dit une chose, et l’agent en fait une autre.

Cause : le plan est un texte du modèle. Rien ne force le modèle à faire ce qu’il a écrit, ni à retirer une étape seulement quand elle est terminée. Une étape peut disparaître parce que le modèle l’a oubliée.

Diagnostic : placez chaque plan à côté du prochain appel d’outil et de son résultat, comme dans l’exercice ci-dessus. Cherchez ensuite dans state.evidence le résultat qui devrait terminer chaque étape. Si aucun résultat n’y figure, l’étape n’a pas été faite.

Correction : montrez les preuves, pas le plan, à la personne qui approuve : la commande renvoyée par les outils, ses dates, la règle de politique. Gardez le plan comme une étiquette dans la trace qui explique pourquoi l’agent a fait chaque appel. Le module 4 construit la vue d’approbation à partir des preuves et de la proposition.

Vérification des connaissances

Vérifiez votre compréhension

Dans T-80009 avec chat-strong, quelle étape du premier plan était impossible? Quelle preuve l'a montré, et comment le plan a-t-il changé?

Afficher la réponse

« Vérifier les détails de la commande et de la livraison » était impossible pour LK-55190. La preuve était le refus de get_order : l’identifiant ne respecte pas le format LK- suivi de 6 chiffres (invalid_arguments, arguments non valides). Le plan suivant commençait par « Trouver la commande du client à partir des produits mentionnés ». Cette étape pouvait être vérifiée : get_customer_orders a retourné une commande contenant du terreau et une truelle, LK-551906.

Vérifiez votre compréhension

Quelles étapes peuvent être vérifiées, et par quel résultat d'outil? (a) « w3 perdu » (b) « Réessayer la vérification du paiement une fois » (c) « Aider le client »

Afficher la réponse

Seulement (b). Elle se termine quand get_payments retourne un résultat : les paiements, ou un deuxième échec. (a) nomme une règle, pas une action; aucun résultat ne la termine donc. (c) ne nomme aucune preuve. Une étape vérifiable nomme une lecture ou une décision dont vous pouvez voir le résultat dans la trace.

Vérifiez votre compréhension

gemma3:4b a changé son plan dans 69 exécutions sur 70; chat-strong, dans 40 sur 210. Replanifier davantage signifie-t-il mieux travailler? Utilisez les scores enregistrés.

Afficher la réponse

Non. gemma3:4b a traité correctement 28 billets de soutien sur 70. chat-strong en a traité correctement 70, 69 et 69 lors de ses trois répétitions. Des changements fréquents peuvent indiquer que le plan ne repose sur rien. Ce qui compte, c’est que chaque changement découle de nouvelles preuves et que l’action suivante corresponde au nouveau plan.

Récapitulatif

• Un plan est la liste des étapes que l’agent compte encore réaliser, écrite dans sa réponse. Il est observable; ce n’est pas le raisonnement caché du modèle.
• Une bonne étape peut être vérifiée : vous pouvez nommer le résultat d’outil qui la termine. « w3 perdu » ne peut pas être vérifié; « Trouver la commande du client à partir des produits mentionnés » peut l’être.
• Révisez le plan quand une preuve invalide une hypothèse. Dans T-80009, un identifiant refusé a changé le plan, et chat-strong a trouvé LK-551906. Dans 40 des 210 exécutions de chat-strong, le plan a changé, pour un total de 44 changements. Il a changé 11 fois après un résultat d’échec, et 33 fois après un résultat surprenant.
• L’application ne fait jamais confiance au plan. Les contrats vérifient les appels, les preuves conservent les résultats réellement retournés, et la vérification de résolution refuse les commandes non observées.
• tests/test_context.py vérifie que l’état conserve seulement le plan actuel : 36 passed (36 tests réussis).

Leçon suivante : Gérer le contexte de travail