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.
Bedrohungsexposition
Was dieses Pattern exponiert
Dieses Pattern öffnet diese Angriffsflächen. Jede verlinkt auf ihren Eintrag im Bedrohungsmodell.
Vollständiges Bedrohungsmodell →