PricingLoginStart free
Claude Architect · Lektion

Antimönster för verktyg och fel

Minimala beskrivningar, för många verktyg och generiska fel.

Lektion 2 av 413 steg

Antimönster för verktyg och fel är en gratis lektion i Claude Architect på CoddyKit. Detta är lektion 2 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Claude Architect, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Claude Architect innehåller totalt 4 lektioner.

Varför verktyg och fel misslyckas i det tysta

De flesta agentfel är inga dramatiska krascher. De är tysta felroutningar: modellen väljer fel verktyg eller så misslyckas ett verktyg med ett vagt meddelande som modellen inte kan återhämta sig från. Agenten improviserar, hittar på eller överger uppgiften i tysthet.

Den här lektionen dissekerar tre antimönster som ständigt hamnar i produktion:

  • Minimala verktygsbeskrivningar som lämnar modellen åt gissningar
  • För många verktyg per agent, vilket försämrar tillförlitligheten i valet
  • Generiska felstatusar som hindrar intelligent återhämtning

Alla tre är vanliga felaktiga svar på provet. Lär er att upptäcka och åtgärda dem.

Beskrivningar är mekanismen för val

En vanlig missuppfattning är att modellen dirigerar utifrån verktygets namn. Det gör den inte. Verktygets beskrivning är den primära mekanismen för valet. Namn är etiketter; det är i beskrivningarna modellen avgör om ett verktyg passar situationen.

En minimal beskrivning som "Looks up an order" säger nästan ingenting till modellen. När två verktyg har korta beskrivningar som överlappar varandra gör modellen en felroutning — den anropar lookup_order när den behövde get_customer, och hela agentloopen börjar driva iväg.

Anatomin hos en bra beskrivning

En bra verktygsbeskrivning innehåller fem saker:

  • Syfte — vad verktyget gör och när det ska användas
  • Returvärden — formen på det som returneras
  • Indataformat med exempel — konkreta, inte abstrakta
  • Kantfall — tomma resultat, tvetydighet och flera träffar
  • Gränser för användbarhet — när verktyget INTE ska användas

Den sista punkten skiljer verktyg som överlappar varandra åt. Nedan visas den svaga version som de flesta team levererar.

lookup_order = {
    "name": "lookup_order",
    # Anti-pattern: minimal, ambiguous description
    "description": "Looks up an order.",
    "input_schema": {
        "type": "object",
        "properties": {"id": {"type": "string"}},
        "required": ["id"],
    },
}

Omskrivning för att undanröja tvetydighet

Nu den starka versionen. Lägg märke till hur beskrivningen anger indataformatet med ett exempel, returformatet, fallet med tomt resultat och en uttrycklig gräns som förhindrar kollision med get_customer.

Detta är den enskilt mest effektiva åtgärden mot felroutning: ni ändrar beskrivningen, inte modellen.

lookup_order = {
    "name": "lookup_order",
    "description": (
        "Retrieve a single order by its order ID. "
        "Input: order_id as a string like 'ORD-48213' (NOT a customer ID). "
        "Returns: {order_id, status, items[], total, placed_at}. "
        "If no order matches, returns an empty result (not an error). "
        "Use get_customer first if you only have a name or email; "
        "do NOT use this to look up a customer's full order history."
    ),
    "input_schema": {
        "type": "object",
        "properties": {
            "order_id": {"type": "string", "description": "e.g. 'ORD-48213'"}
        },
        "required": ["order_id"],
    },
}

För många verktyg försämrar valet

Det andra antimönstret är att ge en agent en enorm verktygslåda. Tillförlitligheten i valet är inte konstant — den försämras när antalet verktyg växer.

  • 4–5 verktyg per agent är det optimala intervallet
  • 18 eller fler verktyg försämrar mätbart tillförlitligheten i valet

Fler verktyg innebär fler möjligheter till överlappande beskrivningar, större yta för tvetydighet och en längre lista som modellen måste resonera över vid varje tur. Bredd är ingen fördel här — det är en belastning.

Begränsa verktygen efter rollen

Lösningen är arkitektonisk: begränsa verktygen efter rollen i stället för att ge varje agent alla funktioner. I ett multiagentsystem med hub-and-spoke delar koordinatorn upp arbetet och delegerar till underagenter — varje underagent får endast den handfull verktyg som dess uppgift kräver, enligt principen om minsta privilegium.

En fokuserad supportagent med 4 verktyg presterar bättre än en generalist med 20 verktyg, eftersom varje verktyg är entydigt inom den lilla, rollbegränsade uppsättningen.

support_agent = AgentDefinition(
    name="order_support",
    description="Handles order status and refund requests for a verified customer.",
    system_prompt="You resolve order issues. Verify identity before any refund.",
    # 4 tools, scoped to the role — not the whole company API
    allowed_tools=[
        "get_customer",
        "lookup_order",
        "process_refund",
        "escalate_to_human",
    ],
)

Dela upp, fyll inte på

När ett arbetsflöde faktiskt behöver många funktioner är svaret inte en överlastad agent — det är uppdelning. Fördela ansvaret mellan rollbegränsade underagenter och låt koordinatorn dirigera mellan dem.

Kom ihåg regeln för multiagentsystem: underagenter ärver inte koordinatorns konversationshistorik. När ni delegerar måste ni därför skicka all nödvändig kontext explicit i underagentprompten. En tydlig uppdelning håller varje agents verktygsuppsättning liten OCH dess kontext fokuserad.

Generiska fel hindrar återhämtning

Det tredje antimönstret finns i felhanteringen. Ett verktyg som misslyckas med "Operation failed" eller ett ensamt isError: true ger modellen inget att agera på. Den kan inte skilja ett tillfälligt nätverksproblem från ett valideringsfel eller ett tomt resultat — så den försöker antingen blint igen, ger upp eller hittar på ett svar.

Generiska felstatusar blockerar intelligent dirigering. Strukturerade fel möjliggör den.

# Anti-pattern: generic, unrecoverable error
return {
    "isError": True,
    "message": "Operation failed",
}

Strukturerade MCP-fel

Ett återställbart fel innehåller struktur. MCP-konventionen samlar de fält som modellen behöver för att avgöra vad den ska göra härnäst:

  • isError: true samt en errorCategory: transient / validation / business / permission
  • isRetryable — bör modellen försöka igen över huvud taget?
  • message, attempted_query och partial_results

Med dessa fält dirigerar modellen intelligent: försöker igen vid ett tillfälligt fel, rättar ett valideringsfel, eskalerar ett nekande av behörighet eller visar delresultat i stället för ingenting.

# Structured error: enables intelligent routing
return {
    "isError": True,
    "errorCategory": "transient",      # transient|validation|business|permission
    "isRetryable": True,
    "message": "Order DB timed out after 5s",
    "attempted_query": {"order_id": "ORD-48213"},
    "partial_results": [],
}

Fel är inte samma sak som tomt resultat

En subtil skillnad som tentan gärna testar: ett åtkomstFEL (verktyget kunde inte köras – timeout, behörighet) är inte samma sak som ett giltigt TOMT resultat (frågan kördes utan problem men gav inga träffar).

Att slå ihop båda till ett generiskt fel förstör möjligheten till återhämtning. Ett fel kan vara värt att försöka igen; ett tomt resultat betyder "inga träffar" och ska rapporteras som ett faktum, inte försöka om för evigt. lookup_order tidigare hanterade detta rätt: ingen träff returnerar ett tomt resultat, inte ett fel.

Återhämta lokalt, eskalera med kontext

Sätt ihop detta till en strategi för felpropagering:

  • Återhämta tillfälliga fel lokalt i underagenten – försök igen vid timeout i stället för att propagera felet
  • Eskalera fel som inte kan återhämtas med strukturerad kontext: feltyp, försökt fråga, partiella resultat och alternativ
  • Undertryck aldrig fel i tysthet och avbryt aldrig hela arbetsflödet för att en underagent misslyckades

Koordinatorn kan då ta en annan väg runt en enskild misslyckad gren och ändå sammanställa ett användbart svar – vilket är precis vad generiska fel gör omöjligt.

# Subagent error handling
if err["errorCategory"] == "transient" and err["isRetryable"]:
    result = retry(call)              # recover locally
else:
    return {                          # escalate WITH context
        "status": "failed",
        "failure_type": err["errorCategory"],
        "attempted_query": err["attempted_query"],
        "partial_results": err["partial_results"],
        "alternatives": ["try search_orders by date range"],
    }

Snabbtest: åtgärda felaktig dirigering

Tillämpa lektionen på ett konkret fel.

Besvara frågan i den interaktiva lektionen

Sammanfattning: tre antipatterns, tre lösningar

Ni kan nu upptäcka och åtgärda de antipatterns för verktyg och fel som leder till felaktiga svar på tentan:

  • Minimala beskrivningar leder till felaktig dirigering. Lösning: beskrivningarna är urvalsmekanismen – ange syfte, returvärden, indat format med exempel, gränsfall och begränsningar för när verktyget kan användas.
  • För många verktyg försämrar urvalet. Lösning: 4–5 verktyg per agent är optimalt, medan 18+ försämrar tillförlitligheten – begränsa verktygen till rollen och dela upp dem mellan underagenter enligt principen om minsta behörighet.
  • Generiska fel hindrar återhämtning. Lösning: strukturerade fel med errorCategory (transient/validation/business/permission), isRetryable, attempted_query och partial_results – skilj åt åtkomstfel från ett giltigt tomt resultat, återhämta tillfälliga fel lokalt, eskalera resten med kontext och undertryck eller avbryt aldrig hela arbetsflödet i tysthet.
Gratis att börja

Lär dig Python med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
26
Lektioner
104
Börja lära dig gratisVisa hela kursen

Vanliga frågor

Är lektionen ”Antimönster för verktyg och fel” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Claude Architect, inklusive ”Antimönster för verktyg och fel”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Claude Architect innehåller totalt 4 lektioner.

Vad lär jag mig i ”Antimönster för verktyg och fel”?

Minimala beskrivningar, för många verktyg och generiska fel. Ni övar på Claude Architect med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Claude Architect?

Du behöver inga förkunskaper. Utbildningen i Claude Architect på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.

Hur lång tid tar lektionen ”Antimönster för verktyg och fel”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Claude Architect-lektionen?

Ja. Varje Claude Architect-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Antimönster för loopar och orkestrering
  2. Antimönster för verktyg och fel
  3. Antimönster för prompts och granskning
  4. Antimönster för eskalering och mätvärden
← Tillbaka till Claude Architect