Flux de travail contre agents : qui doit choisir la prochaine étape de recherche ?

Un agent de recherche tombe sur la phrase « LangGraph prend en charge une exécution durable », coche une case dans un tableau de comparaison et recommande ce framework. Vous déployez une application locale ; le processus s’arrête et rien ne reprend. Qu’est-ce qui a échoué ?

Une condition a été ignorée. « Prend en charge la persistance » n’est pas synonyme de « La persistance est intégrée dans cette application ». Un agent d’intelligence de marché digne d’être utilisé devrait remarquer cette différence, aller au-delà des descriptions des fonctionnalités et parfois modifier sa prochaine question en fonction de ce qu’il découvre.

Au début de cette série, c’était le temps d’exécution lui-même qui était au centre de l’attention. Ici, la question porte sur la liberté dont dispose le modèle à l’intérieur de ce temps d’exécution.

Deux manières d’analyser la même mission

Supposons que la mission demande de décrire la relation entre LangGraph et Deep Agents, ainsi que les besoins d’un service de recherche en Python pour se réinitialiser après une panne, en se basant uniquement sur les documents officiels.

Une approche consiste en un processus fixe. Vous fournissez les pages appropriées, extrayez les affirmations clés, comparez leurs réserves et émettez un résumé cité. C’est un flux de travail.

L’autre approche permet au modèle de choisir la prochaine action. Il effectue des recherches, ouvre une page, remarque une condition manquante et décide de ce qu’il faut explorer ensuite. C’est un agent.

Les deux peuvent utiliser des modèles, des outils, des branches et des tentatives répétées. La véritable différence réside dans celui qui décide du parcours. La note de LangGraph sur les flux de travail et les agents clarifie bien cette distinction.

Une règle pratique à retenir :

• Les documents et les étapes sont déjà connus : privilégiez un flux de travail.
• Les sources utiles n’apparaissent que pendant la recherche : essayez un agent délimité.
• La livraison doit être prévisible, l’enquête pas nécessairement : combinez les deux.

Ce projet relève de la troisième catégorie.

Lorsqu’une découverte réécrit la question

À première vue, ce bref aperçu semble être une comparaison entre différents frameworks. Cependant, l’aperçu de Deep Agents montre qu’il s’exécute sur le moteur LangGraph. L’enquête change donc de direction.

Question ancienne : quel framework l’emporte ?

Découverte nouvelle : ils opèrent à des niveaux différents.

Question plus pertinente : quelles tâches relèvent de l’application elle-même et lesquelles relèvent d’un outil de niveau supérieur ?

La persistance nécessite la même attention. Les documents décrivent l’installation des points de contrôle ainsi que l’identité des threads pour les graphes locaux. Ils distinguent également les stockages en mémoire des stockages basés sur une base de données, et précisent que le Agent Server gère seul l’infrastructure de persistance. Voir Persistance et Points de contrôle.

Une réponse utile tient compte de ces conditions. Un simple coché dans une table de fonctionnalités ne suffit pas. Tout ce qui suit provient de la lecture directe des documents, et non d’une transcription d’un agent enregistré.

Forme du système : flux de travail entourant un chercheur

L’application définit les objectifs, les sources autorisées, les limites des demandes ainsi que la manière dont les résultats sont traités. À l’intérieur de ces limites, le modèle sélectionne les recherches et les documents. L’enquête reste flexible ; la livraison reste explicite.

Éléments impliqués :

• LangGraph gère les étapes externes de l’application.
• Le SDK d’Anthropic fournit au modèle des outils natifs de recherche et de récupération d’informations sur le web.
• Un rapport d’audit sauvegardé conserve les sources, les enregistrements de citation, les données d’utilisation ainsi que les erreurs des outils.

Une seule appel à un fournisseur peut regrouper plusieurs actions de recherche et de lecture. LangGraph dirige le processus global ; il ne crée pas chaque requête. Un seul chercheur peut ainsi facilement examiner les limites du système. Les agents avancés peuvent attendre que davantage de gestion du contexte et de délégation soient nécessaires. Changer de fournisseur signifierait également réécrire les contrats relatifs aux outils et aux citations.

La recherche trouve les pages ; la récupération les lit

La requête met à disposition ces deux outils :

tools = [
    {
        "type": "web_search_20250305",
        "name": "web_search",
        "max_uses": 3,
    },
    {
        "type": "web_fetch_20250910",
        "name": "web_fetch",
        "max_uses": 4,
        "max_content_tokens": 6000,
        "citations": {"enabled": True},
    },
]

Ces définitions proviennent du code d’accompagnement et ne constituent pas un programme complet. Le modèle que vous choisissez doit prendre en charge les versions des outils décrites. Anthropic documente ces deux outils sous les rubriques Agents et Tools sur son site de développement ; consultez ces pages pour obtenir les spécifications actuelles relatives aux recherches et aux récupérations de données.

Trois contraintes influencent la conception.

1. Les limites s’appliquent par requête. Au maximum deux appels au SDK sont autorisés, y compris une continuation après une pause, et les tentatives de réessai du SDK sont interdites.
2. Les citations lors des récupérations de données sont activées délibérément afin que les enregistrements de citation natifs soient conservés, et non seulement le texte de la réponse.
3. Un code HTTP 200 n’est pas une preuve de disponibilité des données. L’API peut réussir tandis qu’une opération de récupération à l’intérieur échoue, il est donc nécessaire d’examiner également les blocs contenant les résultats de l’outil.

Ces limites restreignent le nombre de requêtes et d’outils utilisés. Elles ne représentent ni un plafond de dépenses ni une échéance stricte.

Les citations peuvent encore aider à surmonter certaines difficultés

Imaginez un rapport affirmant que l’application se rétablira automatiquement après une panne, en se référant à une page concernant la persistance configurable. Le lien est réel. Cependant, cette affirmation dépasse les preuves disponibles.

Un audit de base pose quatre questions oui/non : Le modèle a-t-il fonctionné normalement ? A-t-il récupéré au moins un document ? A-t-il renvoyé du texte de réponse ? La réponse finale contient-elle des citations natives ? En cas de réussite, on obtient needs_review ; en cas d’échec sur une vérification obligatoire, on obtient incomplete.

Aucune de ces étiquettes ne signifie que les affirmations sont vraies. Les citations peuvent indiquer des index ou des emplacements de passages plutôt que des URL, et le prototype stocke ces enregistrements sans définir comment ils correspondent entre eux.

Une bonne habitude de révision : prenez une affirmation concrète et consultez sa source. Quelle condition, exception ou qualification pourrait changer la recommandation ?

Augmentez la complexité uniquement lorsque vous pouvez mesurer les avantages

Des investigations prolongées pourraient nécessiter un chargement sélectif du contexte, des notes compactes ou des chercheurs indépendants pour des branches distinctes. Ces idées apparaissent dans les articles d’Anthropic sur l’organisation du contexte pour les agents et sur les systèmes de recherche multi-agents. Pour cette application, il s’agit de options à évaluer, et non d’améliorations à intégrer par défaut.

Quatre vérifications constituent un premier critère équitable :

1. Explique-t-il la relation entre LangGraph et Deep Agents ?
2. Préserve-t-il les conditions nécessaires à la récupération après redémarrage ?
3. Détecte-t-il lorsqu’une récupération de document échoue ?
4. Admet-il que les seuls documents ne permettent pas de déterminer l’option de déploiement la moins chère ?

Placer le flux de travail de document fourni à côté de la recherche dirigée par modèle. Maintenir le modèle et les exigences de réponse fixes, préciser clairement quelles sources chaque partie peut consulter et enregistrer l’utilisation réelle. Évaluer les résultats obtenus, les conditions manquantes ainsi que l’incertitude réelle, et non seulement le nombre de citations.

État actuel : dix tests d’intégration réussissent avec le SDK réel et l’environnement de exécution de LangGraph utilisant des requêtes HTTP simulées. Aucune exécution en temps réel de l’API n’a encore été effectuée, car les identifiants n’ont pas été définis, ce qui signifie qu’il n’y a pas de chiffres mesurés concernant la qualité, la latence ou les coûts.

Perspectives futures

Il existe désormais un concept méritant d’être testé : un chercheur capable de suivre les preuves, intégré à un logiciel qui laisse une trace inspectable. Le prochain problème apparaît lorsque le processus s’arrête en cours de route. Les fichiers de réponse sauvegardés vous aident à comprendre ce qui s’est passé, mais ils ne relancent pas le processus. La partie suivante introduit un état d’exécution persistant et teste la capacité de récupération dans un nouveau processus, tout en continuant d’utiliser cette application de recherche web.