Wann man dazu greift
- Spezialisten gekapselt werden müssen.
- Der Hauptagent absolute Kontrolle behalten muss.
- Sicherheitsgrenzen strikt getrennt sein müssen.
Agents-as-Tools.
Einen Spezialisten wie jedes andere Tool aufrufen.
Ein orchestrierender Agent ruft andere Agenten genau wie Tools auf und verbirgt deren interne Logik und Koordination hinter einer standardisierten Tool-Schnittstelle.
Wann es nach hinten losgeht
- Gleichberechtigte Zusammenarbeit erforderlich ist.
- Spezialisten langfristige Autonomie benötigen.
- Schnittstellenverträge instabil sind.
Die Abwägung
Hervorragende Kapselung wird auf Kosten eingeschränkter Unabhängigkeit der Sub-Agenten erreicht.
Eine Form, die du auf eine Serviette zeichnen kannst.
Ein aufrufender Agent ruft einen Tool-Agenten über eine Standard-Tool-Schnittstelle auf. Die eingebettete Agentensemantik ist hinter dem Aufruf verborgen.
Zwei Wege, wie dieses Pattern Probleme verursachen kann.
Latenz des Tool-Agenten für den Aufrufer unsichtbar
Der Aufrufer behandelt den Tool-Agenten als sofort reagierend, obwohl dieser eine vollständige interne Schleife ausführt. Timeouts greifen, bevor der Tool-Agent fertig ist.
Lösung · Erwartete Latenz im Tool-Schema angeben. Für langfristig laufende Tool-Agenten asynchrone Callbacks oder Streaming verwenden.
Tool-Agenten-Fehler erscheinen als generische Tool-Fehler
Der Tool-Agent wirft eine interne Exception, der Aufrufer sieht aber nur 'Tool execution failed.' Das Debugging erfordert die Logs des Tool-Agenten.
Lösung · Strukturierte Fehler-Payloads mit einer trace_id zurückgeben. Den Aufrufer zu einem Diagnoseknoten routen, der den vollständigen Trace abrufen und anzeigen kann.