Comment les agents planifient les tâches avec des listes de tâches

nous le faisons tous naturellement et régulièrement. Dans notre vie personnelle, nous tenons souvent des listes de choses à faire pour organiser les vacances, les courses et tout le reste.

Au travail, nous nous appuyons sur des suivis de tâches et des plans de projet pour maintenir les équipes alignées. Pour les développeurs, il est également courant de laisser FAIRE commentaires dans le code comme rappels pour les modifications futures.

Sans surprise, les agents LLM bénéficient également de listes de tâches claires pour guider leur planification.

Les listes de tâches aident les agents à planifier et à suivre plus efficacement les tâches complexes, ce qui les rend particulièrement utiles pour la coordination multi-outils et les opérations de longue durée où les progrès doivent être visibles.

Agents de codage comme Codex OpenAI, Clinet Claude Code (que j’utilise régulièrement) sont d’excellents exemples de ce concept.

Ils divisent les demandes complexes en un ensemble initial d’étapes, les organisent sous forme de liste de tâches avec des dépendances et mettent à jour le plan en temps réel à mesure que les tâches sont terminées ou que de nouvelles informations apparaissent.

Cette clarté permet aux agents de gérer de longues séquences d’actions, de se coordonner entre différents outils et de suivre les progrès de manière compréhensible.

Dans cet article, nous examinons comment les agents utilisent les capacités de liste de tâches, analysons les composants sous-jacents du processus de planification et démontrons sa mise en œuvre avec LangChain.

Contenu

(1) Exemple de scénario pour l’agent de planification
(2) Composants clés des capacités de tâches
(3) L’assembler dans un middleware

Le code qui l’accompagne est disponible dans ce dépôt GitHub.

---

(1) Exemple de scénario pour l’agent de planification

Examinons l’exemple de scénario pour ancrer notre procédure pas à pas.

Nous mettrons en place un agent unique pour planifier un itinéraire de voyage et exécuter les tâches de réservation. L’agent a accès à :

Dans cet exemple, ces outils sont simulés et n’effectuent pas de véritables réservations ; ils sont inclus pour illustrer la logique de planification de l’agent et la manière dont il utilise les listes de tâches.

---

Voici le code pour implémenter notre agent de planification dans LangChain :

Nous saisissons une requête utilisateur et visualisons la liste de tâches résultant de la planification de l’agent :

L’utilisation d’une prise de notes structurée via des listes de tâches permet aux agents de conserver une mémoire persistante en dehors de la fenêtre contextuelle. Cette stratégie améliore la capacité d’un agent à gérer et à conserver un contexte pertinent au fil du temps.

---

La configuration du code est simple : create_agent crée l’instance d’agent LLM, nous passons l’invite système, sélectionnons le modèle (GPT-5.1), et liez les outils.

Ce qui est remarquable, c’est le TodoListMiddleware() objet qui est passé dans le middleware paramètre.

Tout d’abord, quel est le intergiciel?

Comme son nom l’indique, il s’agit d’une couche intermédiaire qui vous permet d’exécuter du code personnalisé avant et après les appels LLM.

Considérez le middleware comme une couche programmable qui nous permet d’injecter du code pour surveiller, ajuster ou étendre son comportement.

Cela nous donne le contrôle et la visibilité sur les comportements des agents sans modifier leur logique fondamentale. Il peut être utilisé pour transformer les invites et les sorties, gérer les tentatives ou les sorties anticipées et appliquer des mesures de protection (par exemple, garde-corps, contrôles PII).

TodoListMiddleware est un middleware intégré qui fournit spécifiquement des fonctionnalités de gestion de listes de tâches aux agents. Ensuite, nous explorons comment le TodoListMiddleware fonctionne sous le capot.

---

(2) Composants clés des capacités de tâches

Les capacités de gestion des listes de tâches d’un agent de planification se résument à ceci : quatre éléments clés:

1. Élément de tâche à faire
2. Liste des choses à faire
3. Un outil qui écrit et met à jour la liste de tâches
4. Mise à jour de l’invite système à faire

Le TodoListMiddleware rassemble ces éléments pour activer les capacités de liste de tâches d’un agent.

Examinons de plus près chaque composant et comment il est implémenté dans le code middleware à faire.

(2.1) Élément de tâche à faire

Une tâche à faire est la plus petite unité d’une liste de tâches, représentant une seule tâche. Il est représenté par deux champs : description de la tâche et statut actuel.

Dans LangChain, ceci est modélisé comme un Todo type, défini à l’aide TypedDict:

Le content Le champ représente la description de la tâche que l’agent doit effectuer ensuite, tandis que le champ status permet de savoir si la tâche n’a pas été démarrée (pending), en cours de réalisation (in_progress), ou terminé (completed).

Voici un exemple d’élément de tâche :

{
   "content": "Compare flight options from Singapore to Tokyo",
   "status": "completed"
},

---

(2.2) Liste des tâches à effectuer

Maintenant que nous avons défini la structure d’un Todo élément, nous explorons comment un ensemble d’éléments de tâches est stocké et suivi dans le cadre du plan global.

Nous définissons un State objet (PlanningState) pour capturer le plan comme un liste d’éléments à faire, qui seront mis à jour au fur et à mesure que les tâches sont effectuées :

Le todos le champ est facultatif (NotRequired), ce qui signifie qu’il peut être absent lors de la première initialisation (c’est-à-dire que l’agent peut n’avoir encore aucune tâche dans son plan).

OmitFromInput signifie que todos est géré en interne par le middleware et ne doit pas être fourni directement en tant qu’entrée utilisateur.

L’état est la mémoire à court terme de l’agent, capturant les conversations récentes et les informations clés afin qu’il puisse agir de manière appropriée en fonction du contexte et des informations antérieures.

Dans ce cas, la liste de tâches reste dans l’état permettant à l’agent de référencer et de mettre à jour les tâches de manière cohérente tout au long de la session.

Voici un exemple de liste de tâches :

todos: list[Todo] = [
    {
        "content": "Research visa requirements for Singapore passport holders visiting Japan",
        "status": "completed"
    },
    {
        "content": "Compare flight options from Singapore to Tokyo",
        "status": "in_progress"
    },
    {
        "content": "Book flights and hotels once itinerary is finalized",
        "status": "pending"
    }
]

---

(2.3) Outil pour rédiger et mettre à jour les tâches

Une fois la structure de base de la liste de tâches établie, nous avons maintenant besoin d’un outil permettant à l’agent LLM de la gérer et de la mettre à jour au fur et à mesure de l’exécution des tâches.

Voici la manière standard de définir notre outil (write_todos) :

Le write_todos l’outil renvoie un Command qui demande à l’agent de mettre à jour sa liste de tâches et d’ajouter un message enregistrant la modification.

Alors que le write_todos la structure est simple, la magie réside dans la description (WRITE_TODOS_TOOL_DESCRIPTION) de l’outil.

Lorsque l’agent appelle l’outil, la description de l’outil sert d’invite supplémentaire critique, le guider sur la manière de l’utiliser correctement et les éléments à fournir.

Voici l’expression (assez longue) de LangChain de la description de l’outil :

On constate que la description est très structurée et précise, définissant quand et comment utiliser l’outil, les états des tâches et les règles de gestion.

Il fournit également des directives claires pour suivre les tâches complexes, les diviser en étapes claires et les mettre à jour systématiquement.

N’hésitez pas à consulter l’interprétation plus succincte de la description d’un outil de tâche par Deepagents ici

---

(2.4) Mise à jour de l’invite du système

Le dernier élément de la configuration de la fonctionnalité de tâche consiste à mettre à jour l’invite système de l’agent.

Cela se fait par injection WRITE_TODOS_SYSTEM_PROMPT dans l’invite principale, informant explicitement l’agent que le write_todos l’outil existe.

Il guide l’agent sur quand et pourquoi utiliser l’outilfournit un contexte pour les tâches complexes en plusieurs étapes et décrit les meilleures pratiques pour maintenir et mettre à jour la liste de tâches :

---

(3) L’assembler dans un middleware

Enfin, les quatre composants clés sont regroupés dans une seule classe appelée TodoListMiddlewarequi regroupe les fonctionnalités de tâches dans un flux cohérent pour l’agent :

• Définir PlanningState pour suivre les tâches dans le cadre d’une liste de tâches
• Créer dynamiquement write_todos outil permettant de mettre à jour la liste et de la rendre accessible au LLM
• Injecter WRITE_TODOS_SYSTEM_PROMPT pour guider la planification et le raisonnement de l’agent

Le WRITE_TODOS_SYSTEM_PROMPT est injecté via le middleware wrap_model_call (et awrap_model_call), qui l’ajoute au message système de l’agent pour chaque appel de modèle, comme indiqué ci-dessous :

---

L’emballer

Tout comme les humains, les agents utilisent des listes de tâches pour décomposer des problèmes complexes, rester organisés et s’adapter en temps réel, leur permettant ainsi de résoudre les problèmes avec plus d’efficacité et de précision.

Grâce à la mise en œuvre du middleware de LangChain, nous obtenons également des informations plus approfondies sur la manière dont les tâches planifiées peuvent être structurées, suivies et exécutées par les agents.

Vérifier ce dépôt GitHub pour l’implémentation du code.