Die Agenten als Werkzeuge

Auf der vorherigen Seite wurde gezeigt, wie Kontextanbieter Agents Arbeitsspeicher und dynamisches Wissen vermitteln – Informationen, die proaktiv vor jedem Aufruf eingefügt werden. An diesem Punkt verfügen Sie über einen einzelnen Agent, der Tools verwenden, Fähigkeiten laden, Middleware durchläuft und auf umfangreiche Kontexte zurückgreifen kann. Das ist mächtig, aber es ist immer noch ein Agent, der alles tut.

Was geschieht, wenn die Verantwortlichkeiten Ihres Agenten darüber hinausgehen, was eine einzige Reihe von Anweisungen gut verarbeiten kann? Da ein Agent Werkzeuge sammelt, verschlechtert sich die Auswahl von Tools – Modelle sind besser bei der Auswahl zwischen einer Handvoll gut beschriebener Tools als das Sortieren nach Dutzenden. Da die Anweisungen erweitert werden, leidet der Fokus – eine Systemaufforderung, die versucht, Reisebuchungen, Spesenabrechnungen und Kalenderverwaltung abzudecken, gibt dem Modell zu viele Rollen, um zu jonglieren.

Agents als Tools lösen dies, indem Sie Agents verfassen können: Ein Agent (der äußere Agent) kann einen anderen Agent (den inneren Agent) aufrufen, als wäre es ein normales Funktionstool. Jeder innere Agent hat einen engen Umfang – seine eigenen Anweisungen, seine eigenen Werkzeuge, sein eigenes Know-how. Der äußere Agent entscheidet, wann delegiert werden soll und was angefragt werden soll – genau so, wie er entscheidet, wann ein anderes Tool verwendet werden soll.

Wann Sie dies verwenden sollten

Verwenden Sie Agents als Tools, wenn:

  • Sie möchten einen spezialisierten Teilvorgang an einen fokussierten Agenten delegieren , z. B. einen allgemeinen Assistenten, der einen dedizierten "Reisebuchungs-Agent" aufruft, wenn der Benutzer nach Flügen fragt.
  • Der äußere Agent sollte entscheiden , wann und ob der innere Agent anhand des Gesprächs einbezogen wird – die Delegierung ist modellgesteuert und nicht hartcodiert.
  • Sie benötigen keine explizite Kontrolle über die Ausführungsreihenfolge zwischen Agenten – es reicht aus, dass der äußere Agent die Vorgänge aufgrund seines eigenen Verständnisses orchestriert.

Tipp

Jeder Agent kann je nach Spezialisierung und Anforderungen auch ein anderes Modell verwenden. Komplexere Agents verwenden möglicherweise größere Modelle zur Begründung, während einfachere Agents kleinere, schnellere Modelle zur Effizienz verwenden können.

Überlegungen

Überlegung Einzelheiten
Einfachheit Agent-as-Tool ist das leichteste Multi-Agent-Muster. Sie konvertieren einen Agent in ein Tool und übergeben ihn an einen anderen Agenten. Es ist der nächste natürliche Schritt, wenn ein Agent nicht ausreicht.
Latenz Jede Delegierung ist ein vollständiger Agentenaufruf: Der äußere Agent ruft den inneren Agenten auf, der die LLM aufruft, die ihre eigenen Werkzeuge aufrufen kann. Verschachtelte Aufrufe summieren sich. Halten Sie interne Prozesse fokussiert, damit sie schnell gelöst werden.
Routing ist modellgesteuert Der LLM des äußeren Agents entscheidet, wann der innere Agent aufgerufen werden soll, genau wie er entscheidet, wann ein beliebiges Werkzeug aufgerufen werden soll. Dies bedeutet, dass Routing unvorhersehbar sein kann – wenn die Toolbeschreibung vage ist, ruft das Modell möglicherweise den falschen Agent auf oder überspringt es vollständig. Klare, spezifische Beschreibungen sind kritisch.
Eingeschränkte Sichtbarkeit Der äußere Agent sieht die endgültige Textantwort des inneren Agents – es wird nicht die zwischengeschaltete Begründung, die Toolanrufe oder der Kontext des inneren Agents angezeigt. Falls Sie Observability in das Verhalten des Agents benötigen, verwenden Sie Tracing.
Kontextisolation Der innere Agent wird mit eigenen Anweisungen und Tools ausgeführt. Es erbt nicht automatisch den Gesprächsverlauf oder den Kontext des externen Agents. Sie kommunizieren mit ihr über die Toolaufrufargumente, genau wie jedes andere Funktionstool.

So funktioniert es

Agents als Werkzeuge basieren auf der Tool-Calling-Schleife, die Sie bereits kennen. Der einzige Unterschied besteht darin, dass die aufgerufene "Funktion" selbst ein Agent ist.

┌──────────────────────────────────────────────────────────┐
│  User: "Book me a flight to Paris and file the expense"  │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent reasons about the request                   │
│  → decides to call the travel-booking agent first        │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Inner agent (travel-booking) runs as a tool:            │
│  • receives: "Book a flight to Paris"                    │
│  • uses its own tools (search_flights, book_flight)      │
│  • returns: "Booked Flight AF123, $450"                  │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent receives the tool result                    │
│  → decides to call the expense-filing agent next         │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Inner agent (expense-filing) runs as a tool:            │
│  • receives: "File expense for Flight AF123, $450"       │
│  • uses its own tools (create_expense, attach_receipt)   │
│  • returns: "Expense report filed"                       │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent synthesizes both results:                   │
│  "Done! Booked Flight AF123 to Paris for $450 and filed  │
│   expense report."                                       │
└──────────────────────────────────────────────────────────┘

Wichtige Punkte:

  1. Der innere Agent sieht wie ein Funktionstool aus. Aus Sicht des äußeren Agenten unterscheidet sich das Anrufen eines inneren Agenten nicht von dem Anrufen von get_weather() oder search_database(). Das Framework behandelt das Konvertieren des Agents in ein Tool mit einem Namen, einer Beschreibung und einem Eingabeparameter.
  2. Der innere Agent läuft eigenständig. Es verfügt über eigene Anleitungen, Werkzeuge und LLM-Aufrufe. Die vollständige Unterhaltung des äußeren Agents wird nicht angezeigt – nur die Eingabe, die über den Toolaufruf übergeben wird.
  3. Der äußere Agent sieht nur das Endergebnis. Die Zwischenschritte des inneren Agents (Toolaufrufe, Gründe, Wiederholungen) sind für den äußeren Agent unsichtbar. Es empfängt eine Textantwort, genau wie jedes Toolergebnis.

Nächste Schritte

Nachdem Sie nun Agents innerhalb eines einzigen Prozesses verfassen können, ist der nächste Schritt Agent-to-Agent (A2A) – damit Agents über ein Standardprotokoll hinweg über Dienst- und Organisationsgrenzen kommunizieren können.

Agent–zu–Agent (A2A)

Gehen Sie tiefer:

  • Last updated on