Multiagent-Sitzungen

Multi-Agenten-Orchestrierung ermöglicht es einem Agenten, mit anderen zu koordinieren, um komplexe Aufgaben zu erledigen. Agenten können parallel mit ihrem eigenen isolierten Kontext arbeiten, was die Ausgabequalität verbessert und die Zeit bis zur Fertigstellung verkürzt.

Funktionsweise

Alle Agenten teilen denselben Container und dasselbe Dateisystem, aber jeder Agent läuft in seinem eigenen Sitzungs-Thread, einem kontextisolierten Ereignisstrom mit seiner eigenen Konversationshistorie. Der Koordinator meldet Aktivitäten im primären Thread (der dem sitzungsweiten Ereignisstrom entspricht); zusätzliche Threads werden zur Laufzeit erzeugt, wenn der Koordinator beschließt zu delegieren.

Threads sind persistent: Der Koordinator kann eine Folgenachricht an einen Agenten senden, den er zuvor aufgerufen hat, und dieser Agent behält alles aus seinen vorherigen Runden.

Jeder Agent verwendet seine eigene Konfiguration (Modell, System-Prompt, Tools, MCP-Server und Skills), wie sie bei der Erstellung des Agenten definiert wurde. Tools und Kontext werden nicht geteilt.

Was delegiert werden sollte

Multiagent-Sitzungen funktionieren am besten, wenn es mehrere klar abgegrenzte, spezialisierte Aufgaben in einem übergeordneten Ziel gibt:

• Code-Review: Ein Reviewer-Agent mit einem fokussierten System-Prompt und schreibgeschützten Tools.
• Testgenerierung: Ein Test-Agent, der Tests schreibt und ausführt, ohne den Produktionscode zu berühren.
• Recherche: Ein Such-Agent mit Web-Tools, der Ergebnisse an den Koordinator zurückmeldet.

Aufrufbare Agenten deklarieren

Wenn Sie Ihren Agenten definieren, listen Sie zusätzliche IDs von Agenten auf, die er aufrufen darf:

Jeder Eintrag in callable_agents muss die ID eines vorhandenen Agenten sein. Es wird nur eine Delegierungsebene unterstützt: Der Koordinator kann andere Agenten aufrufen, aber diese Agenten können keine eigenen Agenten aufrufen.

Erstellen Sie dann eine Sitzung, die auf den Orchestrator verweist:

Die aufrufbaren Agenten werden aus der Konfiguration des Orchestrators aufgelöst. Sie müssen sie bei der Sitzungserstellung nicht referenzieren.

Sitzungs-Threads

Der sitzungsweite Ereignisstrom (/v1/sessions/:id/stream) wird als primärer Thread betrachtet und enthält eine komprimierte Ansicht aller Aktivitäten über alle Threads hinweg. Sie sehen keine individuellen Traces der aufgerufenen Agenten, aber Sie sehen den Beginn und das Ende ihrer Arbeit. Sitzungs-Threads sind der Ort, an dem Sie in die Überlegungen und Tool-Aufrufe eines bestimmten Agenten eintauchen.

Der Sitzungsstatus ist ebenfalls eine Aggregation aller Agentenaktivitäten; wenn mindestens ein Thread running ist, wird der Gesamtsitzungsstatus ebenfalls running sein.

Listen Sie alle Threads in einer Sitzung wie folgt auf:

Ereignisse aus einem bestimmten Thread streamen:

Vergangene Ereignisse für einen Thread auflisten:

Multiagent-Ereignistypen

Diese Ereignisse zeigen Multiagent-Aktivitäten im übergeordneten Sitzungsstrom an.

Tool-Berechtigungen und benutzerdefinierte Tools in Threads

Wenn ein callable_agent-Thread etwas von Ihrem Client benötigt (Berechtigung zum Ausführen eines always_ask-Tools oder das Ergebnis eines benutzerdefinierten Tools), erscheint die Anfrage im Sitzungsstrom mit einem session_thread_id-Feld. Geben Sie dieselbe session_thread_id an, wenn Sie Ihre Antwort senden, damit die Plattform sie an den wartenden Thread weiterleitet.

• session_thread_id ist vorhanden: Das Ereignis stammt aus einem Subagenten-Thread. Geben Sie es in Ihrer Antwort zurück.
• session_thread_id fehlt: Das Ereignis kam vom primären Thread. Antworten Sie ohne das Feld.
• Verwenden Sie tool_use_id, um Anfragen mit Antworten zu verknüpfen.

Das folgende Beispiel erweitert den Tool-Bestätigungs-Handler, um Antworten weiterzuleiten. Dasselbe Muster gilt für user.custom_tool_result.