Mehrere Agenten arbeiten zusammen

Arbeit, die einer allein nicht schafft, kann man auf mehrere verteilen. Bei Agenten ist es genauso: Ein „Leiter“ zerlegt eine große Aufgabe in mehrere kleine, verteilt sie an mehrere „Arbeiter“-Agenten, und wenn alle fertig sind, wird zusammengefasst. Das nennt man ein Mehr-Agenten-System (multi-agent).

Das klingt natürlich und verlockend, und viele Frameworks sind eigens dafür gebaut. Bevor man eine Aufgabe aber einer Gruppe von Agenten gibt, sollte man klären: Welches Problem lösen mehrere Agenten eigentlich? Was kostet es? Diese Lektion vergleicht es an der Aufgabe aus Lektion 4.

Einige gängige Organisationsformen

• Leiter und Arbeiter: Der Leiter zerlegt, verteilt und fasst zusammen, jeder Arbeiter erledigt eine Teilaufgabe. Am besten geeignet, wenn die Teilaufgaben voneinander unabhängig sind.
• Fließband: Die Ausgabe des ersten Agenten ist die Eingabe des zweiten, etwa „Rechercheur sucht Material → Autor schreibt Entwurf → Lektor prüft“. Das ist eigentlich eher ein Workflow, bei dem jeder Schritt von einem Agenten erledigt wird.
• Debatte: Mehrere Agenten geben jeweils eine Antwort auf dieselbe Frage, stellen sich gegenseitig in Frage, und am Ende wird abgestimmt oder ein Schiedsrichter entscheidet.

Diese Lektion baut die erste Form, weil sie den Kernnutzen mehrerer Agenten am besten zeigt.

Experiment: ein Leiter und drei Arbeiter

Die Aufgabe ist wieder die aus Lektion 4: „Vergleiche, ob httpx' Client und AsyncClient bei drei Dingen gleich konfiguriert werden: Timeout, Proxy, HTTP/2. Stelle es als Tabelle dar und gib in jeder Zelle die Quelle in der Dokumentation an.“

Diese Aufgabe lässt sich natürlich zerlegen: Timeout, Proxy und HTTP/2 haben nichts miteinander zu tun und können einzeln nachgeschlagen werden.

Die Arbeit des Leiters hat drei Schritte:

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)
    ……

Die Arbeiter sind einfach run_agent aus Lektion 2, ohne jede Änderung. Jeder Arbeiter beginnt mit einer leeren Nachrichtenliste und kennt nur seine Teilaufgabe. Die Vorgabe „höchstens 150 Zeichen“ sorgt dafür, dass das, was an den Leiter zurückgeht, knapp genug ist.

Die Vergleichsgruppe ist ein einzelner Agent, der die ganze Aufgabe direkt erledigt. Vollständiger Code in code/05-agents/multi_agent.py.

Ergebnisse

Einzelner Agent:

===== 单个智能体
[第 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 秒

Ein Leiter und drei Arbeiter:

===== 主管 + 工人
  主管拆出了 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 秒

Die Aussagen beider Endantworten stimmen im Wesentlichen überein: HTTP/2 ist in der Dokumentation klar belegt (http2.md, Zeile 50: „HTTP/2 support is available on both Client and AsyncClient“), die Beispiele zu Timeout und Proxy zeigen nur Client, und dass AsyncClient dieselben Parameter nutzt, ist eine Schlussfolgerung.

Die Ergebnisse lesen

Ein Drittel weniger Tokens. Das Mehr-Agenten-System brauchte 11 Modellaufrufe, mehr als doppelt so viele wie die 5 des einzelnen Agenten, und trotzdem insgesamt weniger Tokens: 13720 gegen 21047.

Der Grund liegt darin, wie der Kontext wächst. Wenn der einzelne Agent bei Schritt 4 angekommen ist, enthält seine Nachrichtenliste bereits alle Suchergebnisse und Dokumentinhalte zu Timeout, Proxy und HTTP/2, und jeder Schritt ruft das Modell mit diesem ganzen Haufen auf. Jeder Arbeiter dagegen enthält nur Inhalte zu seinem einen Thema; sein Kontext bleibt klein. Drei kleine Kontexte zusammen sind billiger als ein großer, ständig wachsender.

Der Kontext des Leiters ist sauber. Beim Zusammenfassen hatte der Leiter nur 472 Eingabe-Tokens: drei Ergebnisse von je gut zweihundert Zeichen. Die Originaltexte, die die Arbeiter gelesen haben, sieht er nicht. Das ist der Kernnutzen mehrerer Agenten: Kontexttrennung. Jeder Agent sieht nur, was er sehen muss, und der Leiter geht nicht in Details unter. Bei längeren, komplexeren Aufgaben wird dieser Vorteil noch deutlicher.

Etwa gleich schnell. Die drei Arbeiter laufen parallel, daher ist die Gesamtzeit trotz mehr Aufrufen (8 Sekunden) etwa gleich wie beim einzelnen Agenten (9 Sekunden). Nacheinander ausgeführt wäre es viel langsamer.

Die Antwort des einzelnen Agenten begann wieder auf Englisch. Der erste Satz seiner Endantwort lautete „I have enough evidence. Let me summarize.“, erst danach kam Chinesisch. Ist der Kontext voller englischer Dokumentation, rutscht die Sprache des Modells leicht ab; in Lektion 4 kam das auch einmal vor. Im Kontext des Leiters stehen fast nur chinesische Ergebnisse, dort gibt es dieses Problem nicht.

Die Kosten

• Details gehen verloren. Die Arbeiter geben nur 150 Zeichen Ergebnis zurück, der Leiter bekommt keinen Originaltext. Formuliert ein Arbeiter sein Ergebnis vage oder lässt eine wichtige Quelle weg, kann der Leiter das weder bemerken noch korrigieren. Je genauer das Rückgabeformat der Arbeiter vorgegeben ist (Ergebnis, Beleg, Quelle, Unsicherheiten), desto kleiner das Problem.
• Das Zerlegen selbst kann schiefgehen. Diese Aufgabe war leicht zu zerlegen, drei unabhängige Themen. Hängen Teilaufgaben voneinander ab, etwa „erst die fehlerhafte Funktion finden, dann ihre Aufrufer ansehen“, funktioniert paralleles Zerlegen nicht.
• Mehr Aufrufe, komplexeres System. Jeder zusätzliche Agent bedeutet einen weiteren Prompt, den man schreiben, und eine weitere Ausführungsspur, die man lesen muss. Bei Problemen muss man erst klären, ob es am Zerlegen, an einem Arbeiter oder am Zusammenfassen liegt.

Wann man es einsetzt

• Die Teilaufgaben sind unabhängig und erfordern jeweils viel Lesestoff. Kontexttrennung spart Geld und lässt jeden Agenten fokussierter arbeiten.
• Der Hauptstrang einer langen Aufgabe soll übersichtlich bleiben. Programmieragenten wie Claude Code geben Teilaufgaben wie „etwas in der Codebasis suchen“ an einen Sub-Agenten; der geht Dutzende Dateien durch und gibt nur das Gefundene zurück, und das Hauptgespräch wird nicht mit Zwischenschritten der Suche vollgestopft.
• Verschiedene Teilaufgaben brauchen verschiedene Tools oder Prompts. Jeden Arbeiter nur mit den Tools auszustatten, die er braucht, ist weniger fehleranfällig, als einem Agenten einen ganzen Haufen Tools zu geben (Lektion 3 hat die Probleme vieler Tools behandelt).

Für die meisten Aufgaben reicht ein Agent. Erst einen nehmen; erst wenn der Kontext zu stark anschwillt oder die Aufgabe sich von Natur aus parallel zerlegen lässt, ans Aufteilen denken.

Übungen

1. Ändere bei den Arbeitern „höchstens 150 Zeichen“ in „höchstens 50 Zeichen“ und führ es erneut aus. Sind die Quellenangaben der Endantwort noch vollständig?
2. Lass die Arbeiter ihr Ergebnis in einem festen Format zurückgeben: Ergebnis: … Beleg im Originaltext: … Quelle: … Unsicherheiten: …. Ändert sich die Qualität der zusammengefassten Antwort?
3. Entwirf eine Frage, deren Teilaufgaben voneinander abhängen (etwa „Finde die Funktion in httpx, die ReadTimeout auslöst, und erkläre, von welchen öffentlichen APIs sie aufgerufen wird“), lass den Leiter sie zerlegen und sieh nach, ob er richtig zerlegt.

Selbsttest

1. Ein Mehr-Agenten-System macht mehr Aufrufe als ein einzelner Agent. Warum ist die Gesamtzahl der Tokens trotzdem kleiner?

Der Kontext eines einzelnen Agenten sammelt ständig die Suchergebnisse und Dokumente aller Teilthemen an, und jeder weitere Schritt ruft das Modell mit diesen Inhalten auf. Im Mehr-Agenten-System enthält jeder Arbeiter nur die Inhalte seiner Teilaufgabe, sein Kontext bleibt klein, und auch der Leiter sieht nur kurze Ergebnisse. Mehrere kleine Kontexte zusammen sind billiger als ein ständig wachsender großer.

2. Was bedeutet „Kontexttrennung“ bei mehreren Agenten? Welche Vor- und Nachteile hat sie?

Jeder Agent sieht nur die Informationen, die er braucht: Die Arbeiter sehen nur ihre Teilaufgabe und das gefundene Material, der Leiter nur die zurückgegebenen Ergebnisse der Arbeiter. Vorteil: Jeder Kontext ist klein und fokussiert, das spart Geld, und der Leiter geht nicht in Details unter. Nachteil: Bei der Übergabe gehen Informationen verloren, und der Leiter kann Details, die die Arbeiter nicht zurückgeben, nicht prüfen.

3. Welche Aufgaben eignen sich nicht dazu, sie auf mehrere parallel arbeitende Arbeiter aufzuteilen?

Aufgaben, deren Teilaufgaben voneinander abhängen. Baut ein späterer Schritt auf dem Ergebnis eines früheren auf, geht es nicht parallel; zerlegt man trotzdem, fehlen den späteren Arbeitern die Informationen der früheren. Außerdem: Ist die Aufgabe einfach und von einem Agenten in wenigen Schritten erledigt, erhöht das Zerlegen nur die Zahl der Aufrufe und die Komplexität.