Plusieurs agents travaillent ensemble

Un travail trop gros pour une personne peut être réparti entre plusieurs. Pour les agents, c'est pareil : un « superviseur » découpe une grande tâche en plusieurs petites, les distribue à plusieurs agents « ouvriers », puis rassemble le tout quand chacun a fini. C'est un système multi-agents (multi-agent).

Cela paraît naturel et séduisant, et beaucoup de frameworks sont conçus exprès pour cela. Mais avant de confier une tâche à un groupe d'agents, il faut comprendre : quel problème les agents multiples résolvent-ils vraiment ? Qu'est-ce que cela coûte ? Cette leçon fait la comparaison sur la tâche de la leçon 4.

Quelques organisations courantes

• Superviseur et ouvriers : le superviseur découpe la tâche, distribue et rassemble ; chaque ouvrier accomplit une sous-tâche. Idéal quand les sous-tâches sont indépendantes les unes des autres.
• Chaîne de production : la sortie du premier agent est l'entrée du deuxième, par exemple « le chercheur rassemble la documentation → le rédacteur écrit un premier jet → le relecteur vérifie ». C'est en fait plutôt un workflow, dont chaque étape est accomplie par un agent.
• Débat : plusieurs agents donnent chacun une réponse à la même question, se contestent mutuellement, puis on vote ou un arbitre tranche.

Cette leçon réalise la première, parce qu'elle illustre le mieux l'avantage central des agents multiples.

Expérience : un superviseur et trois ouvriers

La tâche est toujours celle de la leçon 4 : « Compare si le Client et l'AsyncClient de httpx se configurent de la même façon pour trois choses : le délai d'expiration, le proxy, HTTP/2. Présente le résultat sous forme de tableau, en indiquant dans chaque case la source dans la documentation. »

Cette tâche se découpe naturellement : délai, proxy et HTTP/2 n'ont rien à voir entre eux et peuvent être cherchés séparément.

Le travail du superviseur se fait en trois étapes :

def supervisor():
    # 1. 主管拆任务：只输出 JSON，不调用工具
    plan, usage = model([{"role": "user", "content":
                          TASK + '\n\n把这个任务拆成互相独立、可以同时进行的子任务，每个子任务只查一件事。'
                                 '输出 json：{"subtasks": ["子任务1", ...]}'}], None)
    subtasks = json.loads(plan.content[plan.content.find("{"):plan.content.rfind("}") + 1])["subtasks"]

    # 2. 工人并行执行，每个工人都从空白的上下文开始，只看得到自己的子任务
    def work(subtask):
        return run_agent(model, subtask + "\n只回答这一件事，写清楚结论和文档出处（文件名和行号），不超过 150 字。",
                         max_steps=8, verbose=False)

    with ThreadPoolExecutor(len(subtasks)) as pool:
        results = list(pool.map(work, subtasks))

    # 3. 主管汇总：只看工人交回的简短结论，看不到工人查过的原文
    reports = "\n\n".join(f"子任务：{s}\n结论：{a}" for s, (a, _) in zip(subtasks, results))
    final, usage = model([{"role": "user", "content": TASK + "\n\n下面是各子任务的调查结论，据此完成任务：\n\n" + reports}], None)
    ……

Les ouvriers sont simplement le run_agent de la leçon 2, sans aucune modification. Chaque ouvrier part d'une liste de messages vide et ne connaît que sa sous-tâche. Leur imposer « pas plus de 150 caractères » garantit que ce qu'ils rendent au superviseur est assez concis.

Le groupe témoin est un agent seul qui fait directement toute la tâche. Code complet dans code/05-agents/multi_agent.py.

Résultats

Agent seul :

===== 单个智能体
[第 1 步] grep_docs({"keyword": "AsyncClient"}) → ……
[第 1 步] grep_docs({"keyword": "timeout"}) → ……
[第 1 步] grep_docs({"keyword": "proxy"}) → ……
[第 1 步] grep_docs({"keyword": "http2"}) → ……
[第 2 步] read_doc({"path": "advanced/timeouts.md", "start": 1, "end": 70}) → ……
[第 2 步] read_doc({"path": "advanced/proxies.md", "start": 1, "end": 50}) → ……
[第 2 步] read_doc({"path": "http2.md", "start": 20, "end": 75}) → ……
[第 3 步] read_doc({"path": "advanced/timeouts.md", "start": 70, "end": 120}) → ……
[第 3 步] grep_docs({"keyword": "AsyncClient(proxy"}) → 没有找到 AsyncClient(proxy
[第 3 步] grep_docs({"keyword": "AsyncClient(timeout"}) → 没有找到 AsyncClient(timeout
[第 3 步] read_doc({"path": "advanced/clients.md", "start": 1, "end": 40}) → ……
[第 4 步] read_doc({"path": "async.md", "start": 1, "end": 50}) → ……
[第 4 步] read_doc({"path": "api.md", "start": 30, "end": 50}) → ……
  共 5 次模型调用，21047 词元，9 秒

Un superviseur et trois ouvriers :

===== 主管 + 工人
  主管拆出了 3 个子任务：
    - 调查 httpx.Client 和 AsyncClient 在超时（timeout）配置上的方式是否一样，并记录文档文件名和行号
    - 调查 httpx.Client 和 AsyncClient 在代理（proxy）配置上的方式是否一样，并记录文档文件名和行号
    - 调查 httpx.Client 和 AsyncClient 在 HTTP/2 配置上的方式是否一样，并记录文档文件名和行号
  工人「调查 httpx.Client 和 As…」：3 次调用，3943 词元，交回 222 字
  工人「调查 httpx.Client 和 As…」：3 次调用，4506 词元，交回 208 字
  工人「调查 httpx.Client 和 As…」：3 次调用，4094 词元，交回 253 字
  主管汇总时的输入：472 词元
  共 11 次模型调用，13720 词元，8 秒

Les conclusions des deux réponses finales concordent pour l'essentiel : HTTP/2 est clairement étayé dans la documentation (ligne 50 de http2.md : « HTTP/2 support is available on both Client and AsyncClient »), les exemples de délai et de proxy n'utilisent que Client, et qu'AsyncClient accepte les mêmes paramètres est une déduction.

Lire les résultats

Un tiers de tokens en moins. Le système multi-agents a fait 11 appels de modèle, plus du double des 5 de l'agent seul, et pourtant moins de tokens au total : 13 720 contre 21 047.

La raison tient à la façon dont le contexte grandit. Quand l'agent seul arrive à l'étape 4, sa liste de messages contient déjà tous les résultats de recherche et le contenu des documents sur le délai, le proxy et HTTP/2, et chaque étape appelle le modèle avec tout ce tas. Chaque ouvrier, lui, ne contient que le contenu de son propre sujet ; son contexte reste petit. Trois petits contextes réunis coûtent moins cher qu'un grand contexte qui ne cesse d'enfler.

Le contexte du superviseur est propre. Pour la synthèse, l'entrée du superviseur ne fait que 472 tokens : trois conclusions d'un peu plus de deux cents caractères chacune. Il ne voit pas les textes d'origine lus par les ouvriers. C'est l'avantage central des agents multiples : l'isolation du contexte. Chaque agent ne voit que ce qu'il doit voir, et le superviseur n'est pas noyé sous les détails. Sur des tâches plus longues et plus complexes, cet avantage est encore plus net.

Temps à peu près identique. Les trois ouvriers travaillent en parallèle ; malgré plus d'appels, le temps total (8 secondes) est à peu près celui de l'agent seul (9 secondes). En série, ce serait bien plus lent.

La réponse de l'agent seul commence encore en anglais. La première phrase de sa réponse finale est « I have enough evidence. Let me summarize. », avant de passer au chinois. Quand le contexte est plein de documentation anglaise, la langue du modèle dérive facilement, comme une fois à la leçon 4. Le contexte du superviseur ne contient presque que des conclusions en chinois, et le problème disparaît.

Le coût

• Des détails se perdent. Les ouvriers ne rendent qu'une conclusion de 150 caractères ; le superviseur n'a pas les textes d'origine. Si un ouvrier rédige une conclusion vague ou oublie une source clé, le superviseur ne peut ni s'en apercevoir ni corriger. Plus le format de retour des ouvriers est précis (conclusion, appui, source, points incertains), plus ce problème diminue.
• Le découpage lui-même peut être faux. Ici, la tâche se découpait facilement, trois sujets indépendants. Si les sous-tâches dépendent les unes des autres, par exemple « trouver d'abord la fonction fautive, puis examiner ses appelants », le découpage parallèle ne fonctionne pas.
• Plus d'appels, un système plus complexe. Chaque agent de plus, c'est un prompt de plus à écrire et une trace d'exécution de plus à lire. En cas de problème, il faut d'abord savoir s'il vient du découpage, d'un ouvrier ou de la synthèse.

Quand l'utiliser

• Les sous-tâches sont indépendantes et chacune demande de lire beaucoup de matériau. L'isolation du contexte économise et rend chaque agent plus concentré.
• On veut garder claire la ligne principale d'une longue tâche. Des agents de programmation comme Claude Code confient à un sous-agent des sous-tâches comme « chercher quelque chose dans la base de code » ; le sous-agent parcourt des dizaines de fichiers et ne rend que ce qu'il a trouvé, sans encombrer la conversation principale avec les étapes intermédiaires de la recherche.
• Différentes sous-tâches demandent des outils ou des prompts différents. Donner à chaque ouvrier uniquement les outils dont il a besoin est moins sujet aux erreurs que donner un tas d'outils à un seul agent (la leçon 3 a traité des problèmes liés à trop d'outils).

Pour la plupart des tâches, un seul agent suffit. Commencez par un seul ; n'envisagez de découper que si le contexte enfle trop, ou si la tâche se prête naturellement à un découpage parallèle.

Exercices

1. Remplacez le « pas plus de 150 caractères » des ouvriers par « pas plus de 50 caractères » et relancez. Les sources de la réponse finale sont-elles encore complètes ?
2. Faites rendre aux ouvriers leur conclusion dans un format fixe : Conclusion : … Texte d'appui : … Source : … Points incertains : …. La qualité de la réponse synthétisée change-t-elle ?
3. Concevez une question dont les sous-tâches dépendent les unes des autres (par exemple « trouve la fonction de httpx qui lève ReadTimeout, puis explique quelles API publiques l'appellent »), faites-la découper par le superviseur, et voyez s'il la découpe correctement.

Auto-test

1. Un système multi-agents fait plus d'appels qu'un agent seul : pourquoi consomme-t-il pourtant moins de tokens au total ?

Le contexte d'un agent seul accumule sans cesse les résultats de recherche et les documents de tous les sous-sujets, et chaque étape suivante appelle le modèle avec ce contenu. Dans un système multi-agents, chaque ouvrier ne contient que le contenu de sa sous-tâche, son contexte reste petit, et le superviseur ne voit que des conclusions brèves. Plusieurs petits contextes réunis coûtent moins cher qu'un grand contexte qui enfle continuellement.

2. Que signifie « l'isolation du contexte » dans un système multi-agents ? Quels en sont les avantages et les inconvénients ?

Chaque agent ne voit que les informations dont il a besoin : les ouvriers ne voient que leur sous-tâche et le matériau trouvé, le superviseur ne voit que les conclusions rendues par les ouvriers. Avantage : chaque contexte est petit et concentré, on économise, et le superviseur n'est pas noyé sous les détails. Inconvénient : des informations se perdent lors des transmissions, et le superviseur ne peut pas vérifier les détails que les ouvriers n'ont pas rendus.

3. Quelles tâches ne conviennent pas à un découpage entre plusieurs ouvriers travaillant en parallèle ?

Les tâches dont les sous-tâches dépendent les unes des autres. Si une étape s'appuie sur ce que la précédente a trouvé, on ne peut pas paralléliser ; en découpant de force, les ouvriers suivants manquent des informations des précédents. De plus, quand la tâche est simple et qu'un seul agent l'accomplit en quelques étapes, découper ne fait qu'ajouter des appels et de la complexité.