Agents et workflows : se demander d'abord s'il faut un agent

« Agent » est l'un des mots les plus en vogue de ces dernières années. On dirait qu'il faut tout transformer en agent pour être assez moderne.

Avant de vous lancer, posez-vous une question : votre tâche a-t-elle vraiment besoin d'un agent ? Cette leçon distingue d'abord clairement agent et workflow, mesure ensuite par une expérience l'écart de coût entre les deux, et propose enfin une liste de contrôle.

La différence

Rappelez-vous comment RepoBot v2 répond à une question : réécrire la question, chercher dans la documentation, donner documents et question au modèle. Ces trois étapes sont écrites en dur dans votre code, dans un ordre fixe, toujours les mêmes. Le modèle ne se charge que du contenu de deux d'entre elles : en quels termes réécrire, et quoi répondre. C'est un workflow (workflow).

Un agent (agent) est différent : vous ne lui donnez qu'un objectif et un ensemble d'outils, et c'est le modèle qui décide de la suite. Il peut chercher d'abord, constater que le résultat ne convient pas et chercher avec d'autres termes ; lire un fichier, le juger insuffisant et en lire un autre ; ou estimer en savoir assez et répondre directement. Le nombre et l'ordre des étapes ne sont pas connus à l'avance.

工作流：                          智能体：
  改写问题（固定）                   ┌─▶ 模型决定：下一步做什么？
     ▼                             │       │
  检索文档（固定）                   │   ┌───┴───┬────────┬────────┐
     ▼                             │  搜索   读文件   列目录    回答 ──▶ 结束
  回答（固定）                       │   │       │        │
                                   └───┴───────┴────────┘

Il n'y a pas de frontière nette entre les deux. Un workflow où, à une étape, le modèle décide « faut-il chercher ? » a déjà un peu de l'agent. La question la plus utile est plutôt : qui détient le contrôle ? Plus le contrôle est confié au modèle, plus le système est souple, et plus il est difficile à prévoir.

Expérience : les mêmes questions, deux méthodes

Avec le déroulé RAG du module 04 (réécriture, recherche hybride, réponse avec citations) et l'agent que nous allons écrire à la leçon suivante (qui décide lui-même d'utiliser grep_docs, read_doc et list_docs pour consulter la documentation), on répond aux trois mêmes questions. Code dans code/05-agents/workflow_vs_agent.py ; mon résultat (au milieu, la trace de chaque étape de l'agent) :

问：httpx 默认会自动跟随重定向吗？
  固定流程：1 次回答调用，2.2 秒，输入 831 词元，输出 109 词元
    不会。与 `requests` 不同，HTTPX 默认不跟随重定向 [1]。默认情况下，HTTPX 对所有 HTTP 方法都不会跟随重定向 [2]。
[第 1 步] grep_docs({"keyword": "follow_redirects"}) → compatibility.md:19: response = client.get(url, follow_redirects=True) | compatibility.md:
[第 1 步] grep_docs({"keyword": "redirect"}) → advanced/transports.md:178: Or this example, which uses a custom transport and `httpx.Moun
[第 2 步] read_doc({"path": "compatibility.md", "start": 8, "end": 30}) → 8: ## Redirects | 9:  | 10: Unlike `requests`, HTTPX does **not follow redirects by defaul
[第 2 步] read_doc({"path": "quickstart.md", "start": 430, "end": 445}) → 430: [] | 431: >>> r.next_request | 432: <Request('GET', 'https://github.com/')> | 433: ``
  智能体：  3 次调用，3.8 秒，输入 3261 词元，输出 457 词元
    **不会。httpx 默认不自动跟随重定向。**

问：怎么给 httpx 设置代理？
  固定流程：1 次回答调用，3.7 秒，输入 1550 词元，输出 518 词元
    可以，以下是文档中提到的几种设置代理的方式。
（智能体的轨迹省略）
  智能体：  4 次调用，5.8 秒，输入 6756 词元，输出 732 词元
    httpx 设置代理主要有三种方式：

问：httpx 的超时分成哪几种？每种管什么？
  固定流程：1 次回答调用，2.6 秒，输入 991 词元，输出 208 词元
    httpx 的超时分为四种：**connect**、**read**、**write** 和 **pool** [1]。
（智能体的轨迹省略）
  智能体：  3 次调用，4.1 秒，输入 3731 词元，输出 546 词元
    httpx 的超时一共分成 **四种**（依据 `advanced/timeouts.md:45-61`）：

(Pour le déroulé fixe, seul l'appel de réponse est compté ; les réécritures étaient déjà en cache.)

Les deux méthodes ont répondu juste aux trois questions. Mais l'agent a eu besoin de 3 à 4 appels de modèle par question, d'environ 4 fois plus de tokens d'entrée que le déroulé fixe, et d'une à deux secondes de plus.

La raison est facile à comprendre : chaque étape de l'agent renvoie toutes les étapes précédentes. Si l'étape 1 a lu un résultat de grep, l'entrée de l'étape 2 le contient ; si l'étape 2 a lu deux fichiers, l'entrée de l'étape 3 contient leur contenu. Plus il y a d'étapes, plus l'entrée s'allonge.

Pour ce type de question « chercher un fait », une seule recherche trouve la réponse ; la souplesse de l'agent ne sert à rien, il ne reste que l'argent et le temps en plus.

Le coût d'un agent

• Plus cher, plus lent. Plusieurs appels, et un contexte qui s'allonge à chaque étape.
• Imprévisible. La même question prend 3 étapes cette fois, peut-être 6 la prochaine ; cette fois il trouve le bon fichier, la prochaine il s'enfonce peut-être dans une mauvaise direction.
• Difficile à tester et à déboguer. Dans un workflow, l'entrée et la sortie de chaque étape sont déterminées et testables séparément ; les problèmes d'un agent ne se trouvent qu'en fouillant sa trace d'exécution.
• Plus risqué. Le modèle peut décider seul d'appeler des outils ; si ces outils peuvent modifier des données, envoyer des messages ou dépenser de l'argent, une mauvaise décision ou une attaque réussie (leçon 8) a des conséquences réelles.

La valeur d'un agent

Un agent vaut la peine pour les tâches dont les étapes ne peuvent pas être fixées à l'avance :

• Ce qu'il faut chercher dépend de ce que l'étape précédente a trouvé. Par exemple, diagnostiquer une erreur : regarder d'abord le message d'erreur, puis chercher le code source correspondant, puis la configuration liée à ce code.
• Il faut peut-être essayer plusieurs pistes. La première recherche ne donne rien, on change de mot-clé, d'endroit.
• Les tâches varient à l'infini, impossible d'écrire un déroulé fixe pour chacune. Par exemple, un assistant de programmation : l'utilisateur peut lui faire corriger un bug, ajouter une fonctionnalité, écrire des tests, modifier la documentation.

RepoBot v2 ne sait pas répondre à « combien de redirections au maximum par défaut ? », parce que la réponse n'est pas dans la documentation, seulement dans le code source. Un déroulé fixe « chercher dans la documentation puis répondre » ne peut, par nature, pas faire « si ce n'est pas dans la documentation, aller chercher dans le code source ». C'est là qu'il faut un agent, et la leçon 9 le construira.

Liste de contrôle

Avant de construire une nouvelle fonctionnalité, posez-vous dans l'ordre :

1. Un seul appel de modèle suffit-il ? Beaucoup de tâches ne demandent qu'un prompt bien écrit et les bons documents. Si oui, arrêtez-vous là.
2. Les étapes peuvent-elles être écrites en dur à l'avance ? Si vous pouvez dessiner un organigramme fixe (d'abord A, puis B, si X alors C), écrivez-le en code sous forme de workflow. Chaque étape peut appeler le modèle, mais c'est votre code qui contrôle le déroulé.
3. Faut-il décider de l'étape suivante d'après des résultats intermédiaires ? Seulement si oui, et si les cas sont trop nombreux pour être écrits en branches, envisagez un agent.
4. Le coût d'une erreur est-il supportable ? Un agent se trompera. Quelles conséquences ses outils peuvent-ils avoir ? Peut-on faire valider d'abord les opérations dangereuses par un humain ?
5. Le coût et la latence sont-ils acceptables ? Une tâche d'agent peut coûter plusieurs fois le prix et le temps d'un workflow.

Une stratégie pratique : construire d'abord un workflow, et ne confier à un agent que les cas qu'il ne sait pas traiter. RepoBot, par exemple, peut suivre d'abord le déroulé RAG fixe, et ne lancer un agent capable de fouiller le code source que quand la recherche montre que « ce n'est pas dans la documentation ».

Idées reçues

« Qui utilise l'appel d'outils a un agent. » Le programme de la leçon 3 du module 03 utilisait aussi l'appel d'outils, mais seulement sur le mode « si le modèle veut la version, on cherche une fois », un déroulé très fixe. Ce ne sont pas les outils qui comptent, mais le fait que les étapes soient décidées dynamiquement par le modèle.

« Les agents sont plus avancés, donc meilleurs. » Dans l'expérience de cette leçon, déroulé fixe et agent ont répondu juste aux trois questions, mais l'agent a coûté quatre fois plus. Sur des tâches aux étapes fixes, un agent n'est pas plus précis, seulement plus cher, plus lent et moins prévisible.

« Faisons d'abord un agent universel, capable de tout. » Plus il y a d'outils et plus la tâche est large, plus le modèle choisit facilement le mauvais outil ou la mauvaise direction. Dans les vrais projets, il est plus fiable qu'un agent ne soit chargé que d'un type de tâche, avec seulement les outils de ce type de tâche.

Exercices

1. Ajoutez à workflow_vs_agent.py la question « combien de redirections httpx suit-il au maximum par défaut ? » (la réponse est dans le code source, pas dans la documentation). Comment les deux méthodes répondent-elles ?
2. Pensez à une tâche de votre travail (par exemple traiter des tickets clients, préparer un rapport hebdomadaire), passez-la au crible de la liste de contrôle de cette leçon et notez votre conclusion : appel unique, workflow ou agent ? Pourquoi ? Il n'y a pas de réponse type.

Auto-test

1. Quelle est la différence fondamentale entre un workflow et un agent ?

Qui détient le contrôle. Dans un workflow, les étapes et leur ordre sont écrits en dur dans le code, et le modèle ne se charge que du contenu de chaque étape ; dans un agent, seuls l'objectif et les outils sont donnés, le modèle décide lui-même de la suite, et le nombre et l'ordre des étapes ne sont pas connus à l'avance.

2. Pourquoi un agent consomme-t-il plusieurs fois plus de tokens d'entrée qu'un workflow pour la même question ?

L'agent appelle le modèle plusieurs fois, et chaque appel emporte toutes les étapes précédentes : les demandes d'appel d'outils et les résultats renvoyés. Plus il y a d'étapes, plus l'entrée de chaque étape est longue, et le total dépasse de loin un appel unique.

3. Quelles tâches méritent un agent ?

Les tâches dont les étapes ne peuvent pas être fixées à l'avance : l'étape suivante dépend du résultat de la précédente, plusieurs essais peuvent être nécessaires, et les cas sont trop nombreux pour être écrits en branches fixes. Les tâches qu'un appel unique ou un déroulé fixe accomplit bien ne doivent pas être confiées à un agent.