Der Recherche-Agent fand das Kundenkonto, bestätigte den Plan und zog die letzten vier Rechnungen. Er übergab an den Abrechnungs-Agenten mit einer einzeiligen Zusammenfassung: „Kunde möchte eine Rückerstattung.“ Der Abrechnungs-Agent, der nun nichts über das Konto, den Plan oder die Rechnungen weiß, beginnt mit der Frage nach der Konto-ID.
Jede Tatsache, die der erste Agent gesammelt hatte, wurde an der Schnittstelle verworfen. Das ist das Übergabeproblem, und es kostet Sie doppelt: einmal durch doppelte API-Aufrufe, einmal durch die Fehler, die entstehen, wenn der zweite Agent mit weniger Informationen arbeitet als der erste.
Dieser Leitfaden behandelt, was eine Übergabe überstehen muss, die drei Arten, wie Teams Zustände übergeben und wann jede funktioniert, warum Zusammenfassungen mehr verlieren, als man erwartet, und wie man testet, ob eine Übergabe das übertragen hat, was sie vorgab. Unser Beitrag über warum Agenten in der Produktion ausfallen betrachtet verlorene Zustände als einen zentralen Fehlerursache; dies ist die Multi-Agent-Version davon.
Apidog taucht auf, weil die günstigste Lösung in der Regel darin besteht, überhaupt keine Daten mehr zu übergeben und stattdessen Identifikatoren zu übergeben, was nur funktioniert, wenn jeder Agent denselben Datensatz auf die gleiche Weise abrufen kann.
Was tatsächlich die Schnittstelle überqueren muss
Nicht alles. Eine Übergabe, die das gesamte Gespräch kopiert, ist genauso fehlerhaft wie eine, die nichts kopiert, nur in die andere Richtung: Der zweite Agent erbt ein vollständiges Kontextfenster und muss herausfinden, welche Teile relevant sind.
Vier Kategorien sind es wert, unterschieden zu werden.
Identifikatoren. Konto-IDs, Bestell-IDs, Job-IDs, Ticketnummern. Diese sind klein, stabil und ermöglichen es dem empfangenden Agenten, alles zu holen, was er benötigt. Sie sind das Wertvollste, was man übergeben kann, und das, was am häufigsten verloren geht.
Bereits getroffene Entscheidungen. „Der Kunde ist gemäß Richtlinie 3 für eine Rückerstattung berechtigt.“ Der empfangende Agent darf dies nicht neu verhandeln. Tut er dies, haben Sie zwei Agenten, die innerhalb einer Aufgabe unterschiedlicher Meinung sind.
Einschränkungen. Budgetgrenzen, erteilte Genehmigungen, bereits durchgeführte Aktionen. Der Verlust dieser Informationen führt dazu, dass eine Aufgabe doppelt abgerechnet wird oder dieselbe Genehmigung ein zweites Mal angefordert wird. Dies passt direkt zu unserem Beitrag über Idempotenz für KI-Agenten.
Offene Fragen. Was der erste Agent nicht klären konnte. Die explizite Weitergabe verhindert, dass der zweite Agent stillschweigend Annahmen trifft.
Was nicht übertragen werden muss: rohe API-Antworten, das Begründungsprotokoll und alles, was der empfangende Agent selbst in einem einzigen Aufruf abrufen kann.
Drei Wege zur Zustandsübergabe
Das gesamte Gespräch übergeben. Einfach, und es funktioniert für zwei Agenten in einer kurzen Aufgabe. Es scheitert, sobald das Transkript lang ist, weil der empfangende Agent den Großteil seines Budgets mit dem Lesen der Historie verbringt und die relevanten Fakten in der Mitte vergraben sind. Unser Beitrag über das Heraushalten von Tool-Antworten aus dem Kontextfenster erklärt, warum genau in dieser Mitte Modelle Dinge verlieren.
Eine Zusammenfassung übergeben. Der erste Agent schreibt eine Übergabenachricht; der zweite beginnt damit. Dies ist der Standard in den meisten Frameworks und es ist auf eine bestimmte Weise verlustbehaftet: Modelle fassen in Richtung Erzählung zusammen und weg von Identifikatoren. Bitten Sie um eine Zusammenfassung und Sie erhalten „der Kunde ist seit zwei Jahren Abonnent und frustriert“ anstatt „Konto 8812, Plan Pro, vier Rechnungen, Rückerstattung genehmigt für Rechnung inv_44.“
Ein strukturiertes Übergabeobjekt übergeben. Der erste Agent füllt ein Schema. Der zweite liest Felder, keine Prosa. Dies ist aufwändiger einzurichten und hält am besten stand.
{
"task_id": "task_2026_08_26_0031",
"from_agent": "research",
"to_agent": "billing",
"entities": {
"customer_id": "cus_8812",
"invoice_ids": ["inv_41", "inv_42", "inv_43", "inv_44"],
"subscription_id": "sub_119"
},
"decisions": [
{ "decision": "refund_eligible", "value": true, "basis": "policy 3.2, charged twice in one cycle" }
],
"constraints": {
"max_refund_cents": 4900,
"human_approval_granted": false,
"actions_taken": ["read_invoices"]
},
"open_questions": ["Customer has not confirmed which invoice to refund"],
"summary": "Customer cus_8812 was double-charged in August. Refund of one invoice is approved under policy 3.2, up to 4900 cents. Awaiting the customer's choice of invoice."
}
Prosa erscheint immer noch im Feld summary, weil sie Nuancen enthält, die das Schema nicht abdeckt. Sie steht neben den strukturierten Feldern, anstatt sie zu ersetzen, was der ganze Sinn der Sache ist.
Validieren Sie das Objekt, bevor die Übergabe erfolgt. Wenn customer_id fehlt, schlagen Sie an der Schnittstelle laut Alarm, anstatt den zweiten Agenten dies erst drei Aufrufe später entdecken zu lassen.
Referenzen übergeben, nicht Nutzdaten
Die stärkste Version einer Übergabe übermittelt fast keine Daten. Sie übergibt IDs, und der empfangende Agent ruft ab, was er benötigt.
Dies funktioniert aus drei Gründen. Der Zustand bleibt aktuell, so dass, wenn sich etwas zwischen den beiden Agenten geändert hat, der zweite Agent den aktuellen Wert und nicht eine veraltete Kopie sieht. Die Übergabe bleibt klein, ein paar hundert Bytes anstelle von Zehntausenden von Tokens. Und der Audit-Trail verbessert sich, weil jeder Lesezugriff als API-Aufruf und nicht als zwischen Prompts kopierter Text erscheint.
Es erfordert eines: Jeder Agent kann dieselbe API mit den richtigen Berechtigungen erreichen. Das ist nicht kostenlos. Jeder Agent benötigt eigene Zugangsdaten, die auf seine Aufgaben zugeschnitten sind, was das Argument in unserem Beitrag über API-Schlüssel mit geringsten Rechten für Agenten ist. Ein Abrechnungs-Agent, der einen schreibgeschützten Recherche-Token besitzt, kann die Rückerstattung nicht ausführen, und ein Recherche-Agent, der den Abrechnungs-Token besitzt, stellt ein Problem des Schadensausmaßes dar.
Wenn ein erneutes Abrufen teuer oder langsam wäre, cachen Sie den Datensatz in Ihrem Orchestrator und übergeben Sie eine Referenz auf den Cache-Eintrag. Der empfangende Agent fordert die Daten immer noch explizit an, so dass das Muster dasselbe bleibt, aber der zweite Lesezugriff ist günstig.
Wo Übergaben tatsächlich scheitern
Vier Fehler decken die meisten Vorfälle ab.
Der verlorene Identifikator. Die Zusammenfassung sagt „der Kunde“ und gibt nie eine ID an, so dass der zweite Agent nach Namen sucht, zwei Übereinstimmungen findet und die falsche auswählt. Verhindern Sie dies, indem Sie vor der Übergabe überprüfen, dass die erforderlichen Entitäts-IDs vorhanden sind.
Die wiederholte Aktion. Der erste Agent hat die E-Mail bereits gesendet. Die Übergabe vermerkt dies nicht. Der zweite Agent sendet sie erneut. Erfassen Sie actions_taken im Übergabeobjekt und überprüfen Sie es vor jedem Schreibvorgang, unterstützt durch Idempotenzschlüssel, die eine Wiederholung harmlos machen.
Die verlorene Genehmigung. Ein Mensch hat eine Rückerstattung genehmigt, während der erste Agent lief. Der zweite Agent, der dies nicht weiß, fragt erneut. Benutzer interpretieren die zweite Aufforderung als ein System, das nicht zuhört. Tragen Sie Genehmigungen als explizite Einschränkungen und behandeln Sie sie als auf die Aufgabe und nicht auf den Agenten bezogen.
Die selbstbewusste Erfindung. Der empfangende Agent benötigt einen Wert, den die Übergabe nicht enthielt, und anstatt zu fragen, erfindet er einen, der zur Erzählung passt. Dies ist der gefährlichste Fehler, weil er wie eine abgeschlossene Aufgabe aussieht. Die Abwehr ist das Feld open_questions plus eine strenge Regel im Prompt des empfangenden Agenten: Wenn ein erforderlicher Identifikator fehlt, anhalten und fragen.
Schleifen machen alle vier schlimmer. Wenn Agent A an B übergibt und B an A zurückübergibt, zerfällt der Zustand bei jedem Durchlauf, so wie eine Fotokopie einer Fotokopie. Begrenzen Sie die Anzahl der Sprünge und führen Sie das ursprüngliche Aufgabenobjekt durch jeden von ihnen, anstatt es an jeder Grenze neu aufzubauen.
Testen Sie die Schnittstelle, nicht nur die Agenten
Übergaben sind Integrationspunkte, daher sollten Sie sie als solche testen.
Assert auf das Übergabeobjekt. Führen Sie den ersten Agenten in einem festen Szenario aus und überprüfen Sie das von ihm erzeugte Objekt: erforderliche Identifikatoren vorhanden, Entscheidungen aufgezeichnet, Aktionen aufgelistet. Dies ist eine deterministische Assertion für eine strukturierte Nutzlast, auch wenn der Agent, der sie erzeugt hat, nicht deterministisch ist, was sie zu einem brauchbaren Test macht. Der allgemeine Ansatz ist in unserem Leitfaden zum Testen nicht-deterministischer Agenten beschrieben.
Testen Sie den Empfänger isoliert. Geben Sie dem Abrechnungs-Agenten ein handgefertigtes Übergabeobjekt und überprüfen Sie, was er tut. Geben Sie ihm dann ein absichtlich fehlerhaftes, bei dem die Kunden-ID entfernt wurde, und bestätigen Sie, dass er fragt, anstatt zu raten. Dieser zweite Test ist derjenige, der Erfindungen aufdeckt.
Führen Sie beide gegen Mocks aus. Ein Übergabetest, der echte Rückerstattungen auslöst, ist ein Test, den Sie einmal ausführen werden. Richten Sie beide Agenten auf gemockte Endpunkte, damit die Suite bei jeder Änderung ausgeführt werden kann, gemäß unserem Beitrag zum Ausführen von Agenten gegen Mocks anstelle der Produktion. In Apidog stammen die Mocks aus derselben API-Definition, die beide Agenten aufrufen, so dass die beiden nie auseinanderdriften.
Protokollieren Sie jede Übergabe. Zeichnen Sie das vollständige Objekt an jeder Grenze mit der Aufgaben-ID auf. Wenn ein Multi-Agenten-Lauf schiefgeht, zeigt Ihnen das Übergabeprotokoll, welcher Agent die Informationen hatte und welcher sie verloren hat, was normalerweise die gesamte Untersuchung ausmacht. Unser Beitrag über das Tracing von Agenten-Tool-Aufrufen behandelt, was sonst noch in diesen Datensatz gehört.
Was die Frameworks Ihnen bieten
Die meisten Orchestrierungs-Frameworks liefern ein Übergabe-Primitiv, und es hilft zu wissen, was jedes davon tatsächlich über die Grenze bewegt, bevor Sie sich darauf verlassen.
Die OpenAI Agents SDK Übergabedokumentation modelliert eine Übergabe als ein Werkzeug, das der Agent aufrufen kann, was bedeutet, dass das Modell entscheidet, wann die Kontrolle übergeht. Das ist praktisch, und es platziert die Entscheidung im am wenigsten deterministischen Teil Ihres Systems, daher sollten Sie es mit einer Validierung beim Verlassen kombinieren.
LangGraphs Multi-Agenten-Anleitung verfolgt den entgegengesetzten Ansatz: Der Zustand ist ein explizites Graphenobjekt, das jeder Knoten liest und schreibt. Dies entspricht eng der oben beschriebenen strukturierten Übergabe, und die Hauptaufgabe, die Ihnen bleibt, ist zu entscheiden, welche Felder erforderlich sind.
Anthropic’s Artikel über den Aufbau eines Multi-Agenten-Forschungssystems ist lesenswert für die operativen Details, insbesondere wie viele Anweisungen ein Unteragent benötigt, bevor er eigenständig nützlich arbeiten kann.
Der rote Faden: Jedes Framework wird etwas bewegen. Keines davon entscheidet für Sie, welche Fakten tragend sind. Diese Liste müssen Sie selbst erstellen, und sie ist das, was es wert ist, überprüft zu werden, wenn ein Lauf schiefgeht.
Das Aufgabenobjekt außerhalb des Gesprächs halten
Eine strukturelle Änderung verhindert eine ganze Reihe von Fehlern. Speichern Sie den Aufgabenstatus dauerhaft, mit der Aufgaben-ID als Schlüssel, und lassen Sie jeden Agenten ihn lesen und schreiben, anstatt ihn über Nachrichten weiterzugeben.
Das Gespräch ist ein schlechter Container für den Zustand. Es wird durch Zusammenfassung komprimiert, gekürzt und neu geschrieben, und keine dieser Operationen weiß, welche Felder Sie nicht verlieren dürfen. Eine Zeile in einer Datenbank hat dieses Problem nicht.
Das Muster ist klein. Zu Beginn eines Zuges lädt der Agent das Aufgabenobjekt. Wenn er eine Aktion ausführt, hängt er sie an actions_taken an und speichert. Bei der Übergabe übergibt er die Aufgaben-ID, und der empfangende Agent lädt dasselbe Objekt. Nichts Wichtiges wird im Prompt übermittelt, daher kann nichts Wichtiges wegzusammengefasst werden.
Dies bietet Ihnen auch einen Wiederaufnahmepunkt. Wenn ein Lauf bei Schritt vier abbricht, enthält das Aufgabenobjekt immer noch alles, was die ersten drei Schritte etabliert haben, und der erneute Versuch beginnt von dort aus, anstatt von Null.
Wo die Plattform den Zustand halten kann
Wenn Ihre Agenten als CLI-Laufzeiten auf Entwicklerrechnern laufen, ist das oben beschriebene dauerhafte Aufgabenobjekt etwas, das Sie selbst erstellen. Einige Agenten-Arbeitsmanagement-Plattformen modellieren es bereits, und es lohnt sich zu wissen, wie das aussieht, bevor Sie Ihr eigenes schreiben.
Sharkly ist ein Arbeitsverwaltungssystem für Menschen und Agenten, das genau auf dieser Einheit aufbaut. Eine Aufgabe trägt das Ziel, den Status, die verantwortliche Person, den Agenten oder das Team, das mit der Ausführung beauftragt ist, die Kommentare sowie den Ausführungszustand und das Ergebnis des Agenten. Ein Team (Crew) koppelt einen leitenden Agenten mit anderen Agenten und Personen, so dass eine Aufgabe, die mehrere Spezialisten benötigt, einer wiederverwendbaren Gruppe zugewiesen wird, anstatt von Hand zu Hand durch Prompts weitergegeben zu werden. Da der Zustand auf der Aufgabe und nicht in einem Gespräch liegt, hängt eine Übergabe zwischen zwei Agenten nicht davon ab, dass einer von ihnen gut zusammenfasst.
Die Laufzeiten bleiben, was Sie bereits verwenden. Claude Code, Codex und die anderen führen die Arbeit auf einem von Ihnen registrierten Computer aus; die Plattform stellt den Aufgabendatensatz, die Zuweisung und den Überprüfungszyklus um sie herum bereit. Wenn Sie das Muster der dauerhaften Aufgabe selbst erstellen, ist die Sharkly-Dokumentation eine nützliche Referenz dafür, welche Felder sich als wichtig erweisen.
Eine Checkliste für Übergaben
- Ein definiertes Schema für die Übergabe existiert und wird an der Schnittstelle validiert.
- Entitätsidentifikatoren sind Pflichtfelder, keine optionalen.
- Entscheidungen enthalten ihre Grundlage, damit der Empfänger die Argumentation nicht wiederholen muss.
- Bereits durchgeführte Aktionen werden aufgezeichnet und vor jedem Schreibvorgang überprüft.
- Genehmigungen und Budgets werden mit der Aufgabe übermittelt, nicht mit dem Agenten.
- Offene Fragen sind explizit, und der Empfänger fragt, anstatt Annahmen zu treffen.
- Daten werden per Referenz übergeben, wo ein erneutes Abrufen günstig ist.
- Die Sprunganzahl ist begrenzt, und das ursprüngliche Aufgabenobjekt überlebt jeden Sprung.
- Jede Übergabe wird mit der Aufgaben-ID protokolliert.
- Grenztests laufen in CI gegen Mocks, einschließlich einer absichtlich unvollständigen Übergabe.
Die meisten Multi-Agenten-Fehler sind keine Denkfehler. Es handelt sich um eine Tatsache, die in einem Agenten existierte und nicht im nächsten. Gestalten Sie die Schnittstelle als eine Schnittstelle mit einem Schema und Tests, und der zweite Agent hört auf, Fragen zu stellen, die der erste bereits beantwortet hat. Laden Sie Apidog herunter, um die Mocks und Grenztests neben der API zu halten, von der beide Agenten abhängen.
Häufig gestellte Fragen
Lohnt sich eine strukturierte Übergabe für zwei Agenten? Für zwei Agenten in einer kurzen Aufgabe ist die Übergabe des Gesprächs in der Regel in Ordnung. Das strukturierte Objekt bewährt sich bei drei oder mehr Agenten, bei langen Aufgaben oder überall dort, wo eine Übergabe eine Prozess- oder Laufgrenze überschreitet.
Sollte das Modell das Übergabeobjekt schreiben oder sollte Code es erstellen? Code, wo es möglich ist. Identifikatoren, durchgeführte Aktionen und Genehmigungen sollten von Ihrem Orchestrator aus dem, was tatsächlich geschehen ist, gefüllt werden, nicht aus der Erinnerung des Modells. Lassen Sie das Modell nur die summary und die offenen Fragen schreiben.
Wie verhindere ich den Kontextverlust in einer Schleife? Führen Sie ein einziges Aufgabenobjekt durch den gesamten Lauf und aktualisieren Sie es, anstatt es an jeder Grenze neu zu generieren. Begrenzen Sie dann die Sprünge. Wenn eine Aufgabe mehr als eine Handvoll benötigt, ist die Zerlegung wahrscheinlich falsch.
Was ist mit Frameworks mit integrierter Übergabe-Unterstützung? Nutzen Sie diese und prüfen Sie, was sie tatsächlich übertragen. Viele übergeben den Nachrichtenverlauf und nichts anderes, was bedeutet, dass Identifikatoren nur dann überleben, wenn sie zufällig im Text erscheinen. Fügen Sie neben dem, was das Framework überträgt, eine strukturierte Nutzlast hinzu.
Benötigen Sub-Agenten separate API-Zugangsdaten? Ja, auf ihre jeweiligen Aufgaben zugeschnitten. Das Teilen eines einzigen leistungsstarken Schlüssels über Agenten hinweg nimmt Ihnen die Möglichkeit, Schäden zu begrenzen und festzustellen, welcher Agent einen Aufruf getätigt hat. Unser Beitrag über API-Schlüssel mit geringsten Rechten für Agenten behandelt die Einrichtung.
Wie viel sollte das Zusammenfassungsfeld enthalten? Ein paar Sätze, die Absicht und Nuancen abdecken, die die strukturierten Felder nicht aufnehmen können. Wenn es anfängt, IDs und Beträge aufzulisten, gehören diese in die strukturierten Felder, wo sie validiert werden können.