Agenter som verktyg

Föregående sida visade hur kontextprovidrar ger agenter minne och dynamisk kunskap – information som proaktivt matas in före varje anrop. Nu har du en enda agent som kan använda verktyg, läsa in kunskaper, köra mellanprogram och dra nytta av omfattande kontext. Det är kraftfullt, men det är fortfarande en agent som gör allt.

Vad händer när agentens ansvar växer utöver vad en enda uppsättning instruktioner kan hantera väl? När en agent samlar verktyg försämras val av verktyg – modeller är bättre på att välja bland en handfull väl beskrivna verktyg än att sortera igenom dussintals. När instruktionerna breddas försämras fokus – en systemprompt som försöker täcka resebokningar, utgiftsrapportering och kalenderhantering ger modellen för många roller för att jonglera.

Agenter som verktyg löser detta genom att låta dig skapa agenter: en agent (den yttre agenten) kan anropa en annan agent (den inre agenten) som om det vore ett vanligt funktionsverktyg. Varje inre agent har ett nära omfång – sina egna instruktioner, egna verktyg, sin egen expertis. Den yttre agenten bestämmer när den ska delegera och vad som ska efterfrågas – exakt på samma sätt som den bestämmer när ett annat verktyg ska anropas.

När du ska använda detta

Använd agenter som verktyg när:

  • Du vill delegera en specialiserad underavdelning till en fokuserad agent , till exempel en allmän assistent som anropar en dedikerad "resebokningsagent" när användaren frågar om flygresor.
  • Den yttre agenten bör bestämma när och om den inre agenten ska involveras baserat på konversationen – delegeringen är modelldriven, inte hårdkodad.
  • Du behöver inte explicit kontroll över körningsordningen mellan agenter – du är okej med att den yttre agenten samordnar saker genom sitt eget resonemang.

Tips/Råd

Varje agent kan också använda en annan modell beroende på dess specialisering och krav. Mer komplexa agenter kan använda större modeller för resonemang, medan enklare agenter kan använda mindre och snabbare modeller för effektivitet.

Överväganden

Att tänka på Detaljer
Enkelhet Agent-as-tool är det lättaste multiagentmönstret. Du omvandlar en agent till ett verktyg och överlämnar det till en annan agent. Det är det naturliga nästa steget när en agent inte räcker till.
Latency Varje delegering är ett fullvärdigt agentanrop: den yttre agenten anropar den inre agenten, som anropar LLM, som själv kan anropa verktyg. Kapslade anrop summeras. Håll de inre agenterna fokuserade så att de löser sig snabbt.
Routning är modelldriven Den yttre agentens LLM bestämmer när den inre agenten ska anropas, precis som den bestämmer när ett verktyg ska anropas. Det innebär att routning kan vara oförutsägbar – om verktygsbeskrivningen är vag kan modellen anropa fel agent eller hoppa över den helt. Tydliga, specifika beskrivningar är kritiska.
Begränsad synlighet Den yttre agenten ser den inre agentens slutliga textsvar – den ser inte den inre agentens mellanliggande resonemang, verktygsanrop eller kontext. Om du behöver observerbarhet för inre agentbeteende använder du spårning.
Kontextisolering Den inre agenten körs med egna instruktioner och verktyg. Den ärver inte automatiskt den yttre agentens konversationshistorik eller kontext. Du kommunicerar med den via verktygsanropsargumenten, precis som andra funktionsverktyg.

Så här fungerar det

Agenter som verktyg bygger på den verktygsanropsloop som du redan känner till. Den enda skillnaden är att den "funktion" som anropas i sig är en agent.

┌──────────────────────────────────────────────────────────┐
│  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."                                       │
└──────────────────────────────────────────────────────────┘

Viktiga punkter:

  1. Den inre agenten ser ut som ett funktionellt verktyg. Från den yttre agentens perspektiv skiljer sig anropet från en inre agent inte från att anropa get_weather() eller search_database(). Ramverket hanterar konvertering av agenten till ett verktyg med en namn-, beskrivnings- och indataparameter.
  2. Den inre agenten körs oberoende av varandra. Den har egna instruktioner, verktyg och LLM-anrop. Den ser inte den yttre agentens fullständiga konversation – endast indata som skickas via verktygsanropet.
  3. Den yttre agenten ser bara slutresultatet. Den inre agentens mellanliggande steg (verktygsanrop, resonemang, återförsök) är osynliga för den yttre agenten. Det får ett textsvar, precis som alla verktygsresultat.

Nästa steg

Nu när du kan skapa agenter i en enda process är nästa steg Agent-till-Agent (A2A) – vilket gör det möjligt för agenter att kommunicera över tjänst- och organisationsgränser med hjälp av ett standardprotokoll.

Agent-till-agent (A2A)

Gå djupare:

  • Last updated on