0Pricing
AI Engineering Academy · Lekcja

Klasyfikowanie trybów awarii agentów

Zbuduj taksonomię awarii agentów: błędy narzędzi, nieprawidłowo sformatowane dane wyjściowe, pętle rozumowania, wyczerpanie kontekstu i niedostępność usług zewnętrznych, a następnie zaprojektuj strategie odzyskiwania dla każdego przypadku.

Klasyfikowanie trybów awarii agentów to bezpłatna lekcja AI Engineering Academy na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AI Engineering Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AI Engineering Academy zawiera 4 lekcji w sumie.

Dlaczego agenci zawodzą w specyficzny sposób

Agenci zawodzą inaczej niż proste wywołania LLM. Pojedyncze wywołanie jednokrokowe albo zwraca odpowiedź, albo zgłasza błąd. Agent wykonujący zadanie wieloetapowe może zawieść w dowolnym momencie, a awaria może nie być widoczna w końcowym wyniku. Zrozumienie taksonomii trybów awarii agentów jest pierwszym krokiem do budowania agentów, którzy wykrywają, diagnozują i naprawiają własne awarie.

Tryb awarii 1: błędy narzędzi

Błędy narzędzi występują, gdy agent wywoła narzędzie z nieprawidłowymi argumentami, narzędzie zgłosi wyjątek albo zwróci pusty lub zniekształcony wynik. Przykłady obejmują wywołanie interfejsu API wyszukiwania z niepoprawnym zapytaniem, odpytanie bazy danych za pomocą nieprawidłowego SQL-a lub wywołanie wykonawcy kodu, który przekroczy limit czasu. Błędy narzędzi najłatwiej wykryć, ponieważ generują jawne sygnały wyjątków, które można przechwycić i obsłużyć.

class ToolError(Exception):
    def __init__(self, tool_name: str, args: dict, error: Exception):
        self.tool_name = tool_name
        self.args = args
        self.original_error = error
        super().__init__(f'Tool {tool_name} failed: {error}')

def safe_tool_call(tool_func, args: dict) -> str:
    try:
        result = tool_func(**args)
        if not result:
            return 'Tool returned empty result. Try a different approach.'
        return str(result)
    except Exception as e:
        raise ToolError(tool_func.__name__, args, e)

Tryb awarii 2: zniekształcone wyniki

Zniekształcone wyniki występują, gdy agent generuje tekst niezgodny z oczekiwanym formatem — na przykład zwraca język naturalny, gdy kolejny krok oczekuje formatu JSON, albo wywołuje narzędzie z argumentami w nieprawidłowej strukturze. Często dzieje się tak, gdy agent myli bieżący krok z poprzednim. Przed użyciem należy zweryfikować format każdego wyniku agenta, a gdy jest nieprawidłowy, ponownie wysłać prompt.

import json

def validate_agent_output(raw_output: str, expected_format: str) -> dict:
    if expected_format == 'json':
        try:
            return json.loads(raw_output)
        except json.JSONDecodeError as e:
            return {
                'valid': False,
                'error': f'Expected JSON but got invalid JSON: {e}',
                'raw': raw_output[:200]
            }
    return {'valid': True, 'data': raw_output}

Tryb awarii 3: pętle rozumowania

Pętle rozumowania występują, gdy agent bez końca powtarza to samo działanie lub tę samą myśl, nie robiąc postępów. Agent może dziesięć razy z rzędu wykonać to samo zapytanie wyszukiwawcze, za każdym razem otrzymując ten sam pusty wynik i nie wiedząc, co zrobić dalej. Pętle należy wykrywać, śledząc ostatnie działania i sprawdzając powtórzenia. Po wykryciu pętli należy wstrzyknąć meta-prompt informujący agenta, aby spróbował innego podejścia.

from collections import Counter

class LoopDetector:
    def __init__(self, window: int = 5, threshold: int = 3):
        self.recent_actions = []
        self.window = window
        self.threshold = threshold

    def record(self, action: str) -> bool:
        self.recent_actions.append(action)
        if len(self.recent_actions) > self.window:
            self.recent_actions.pop(0)
        counts = Counter(self.recent_actions)
        most_common_count = counts.most_common(1)[0][1] if counts else 0
        return most_common_count >= self.threshold  # True = loop detected

Tryb awarii 4: wyczerpanie kontekstu

Wyczerpanie kontekstu występuje, gdy zgromadzona historia agenta (wywołania narzędzi, obserwacje i tok rozumowania) przekracza okno kontekstu modelu. Model albo po cichu skraca historię, tracąc kluczowe informacje, albo zgłasza błąd limitu tokenów. Aby temu zapobiec, należy śledzić zużycie tokenów na kolejnych etapach i kompresować historię (podsumowując wcześniejsze kroki), zanim zostanie osiągnięty limit.

import tiktoken

CONTEXT_LIMIT = 100_000  # tokens
COMPRESS_AT = 80_000     # trigger compression with headroom

enc = tiktoken.encoding_for_model('gpt-4o')

def total_tokens(messages: list) -> int:
    return sum(len(enc.encode(str(m))) for m in messages)

def check_context(messages: list) -> str:
    tokens = total_tokens(messages)
    if tokens > COMPRESS_AT:
        return 'compress'
    if tokens > CONTEXT_LIMIT:
        return 'critical'
    return 'ok'

Tryb awarii 5: niedostępność zewnętrznej usługi

Awarie usług zewnętrznych występują, gdy usługa będąca podstawą działania narzędzia jest niedostępna, ogranicza liczbę żądań lub zwraca nieoczekiwane błędy. Agent, który nie może połączyć się z potrzebną mu bazą danych, utknie. W przeciwieństwie do pętli rozumowania, które wynikają z działania agenta, awarie zewnętrzne są awariami środowiska. Należy obsługiwać je za pomocą ponowień z wykładniczym czasem oczekiwania oraz narzędzi zapasowych, które mogą przybliżyć wynik, korzystając z innych źródeł danych.

import asyncio

async def resilient_tool_call(tool_func, args: dict, max_retries: int = 3) -> str:
    for attempt in range(max_retries):
        try:
            return await tool_func(**args)
        except (ConnectionError, TimeoutError) as e:
            if attempt == max_retries - 1:
                return f'Service unavailable after {max_retries} attempts. Error: {e}'
            wait = 2 ** attempt  # 1s, 2s, 4s
            await asyncio.sleep(wait)
    return 'Unexpected error in resilient_tool_call'

Tryb awarii 6: niezrozumienie celu

Niezrozumienie celu występuje, gdy agent błędnie interpretuje zadanie i dąży do nieco innego celu. Jest to najtrudniejsza do wykrycia awaria, ponieważ agent może pomyślnie zakończyć działanie — tyle że nie wykona zadania, które użytkownik miał na myśli. Należy ograniczać to ryzyko, prosząc agenta na początku o przedstawienie celu własnymi słowami oraz wdrażając końcowy etap weryfikacji sprawdzający, czy wynik rzeczywiście odpowiada na pierwotne pytanie.

async def confirm_goal_understanding(original_task: str) -> str:
    resp = await client.chat.completions.create(
        model='gpt-4o',
        messages=[
            {'role': 'system', 'content': 'Restate the task in your own words. Be specific about what the final deliverable should be.'},
            {'role': 'user', 'content': f'Task: {original_task}'}
        ]
    )
    return resp.choices[0].message.content

# Use the restatement as the first step of the agent
# to catch misunderstandings before any tools are called

Tworzenie systemu klasyfikacji awarii

Należy utworzyć strukturalny klasyfikator awarii, który przypisuje każdemu wyjątkowi agenta etykietę typu. Umożliwia to automatyczne kierowanie awarii do odpowiedniej strategii odzyskiwania. Dzienniki awarii należy przechowywać wraz z etykietami typów, aby można było analizować, które tryby awarii występują najczęściej, i ustalać priorytety działań naprawczych. Błędy narzędzi i pętle są zazwyczaj najczęstsze oraz najłatwiejsze do naprawienia.

from enum import Enum
from dataclasses import dataclass

class FailureType(Enum):
    TOOL_ERROR = 'tool_error'
    MALFORMED_OUTPUT = 'malformed_output'
    REASONING_LOOP = 'reasoning_loop'
    CONTEXT_EXHAUSTION = 'context_exhaustion'
    EXTERNAL_SERVICE = 'external_service'
    GOAL_MISUNDERSTANDING = 'goal_misunderstanding'
    MAX_ITERATIONS = 'max_iterations'
    UNKNOWN = 'unknown'

@dataclass
class AgentFailure:
    failure_type: FailureType
    step: int
    tool_name: str | None
    error_message: str
    recoverable: bool

Mapowanie awarii na działania naprawcze

Każdy typ awarii ma odpowiednie działanie naprawcze. Błędy narzędzi wymagają ponowienia wywołania ze zmodyfikowanymi argumentami. Pętle wymagają promptu zwiększającego różnorodność i nakazującego agentowi spróbować czegoś nowego. Wyczerpanie kontekstu wymaga kompresji. Awarie usług zewnętrznych wymagają narzędzi zapasowych. Niezrozumienie celu wymaga prośby o wyjaśnienie. Należy jawnie zmapować te przypadki w routerze odzyskiwania, który środowisko uruchomieniowe agenta wywołuje w razie awarii.

RECOVERY_ACTIONS = {
    FailureType.TOOL_ERROR:           'retry_with_corrected_args',
    FailureType.MALFORMED_OUTPUT:     'reformat_output',
    FailureType.REASONING_LOOP:       'inject_diversity_prompt',
    FailureType.CONTEXT_EXHAUSTION:   'compress_history',
    FailureType.EXTERNAL_SERVICE:     'use_fallback_tool',
    FailureType.GOAL_MISUNDERSTANDING:'request_clarification',
    FailureType.MAX_ITERATIONS:       'escalate_to_human',
    FailureType.UNKNOWN:              'escalate_to_human'
}

Ustalanie maksymalnych limitów iteracji

Każdy agent musi mieć maksymalny limit iteracji stanowiący nieprzekraczalną granicę bezpieczeństwa. Bez niego agent zapętlony będzie działać bez końca, zużywając tokeny i pieniądze. Limit należy ustalić na podstawie oczekiwanej złożoności zadania: prosty agent odpowiadający na pytania może mieć limit 5 kroków, podczas gdy złożony agent badawczy może mieć ich 20. Po osiągnięciu limitu należy zapisać awarię, zachować częściowe wyniki i przekazać sprawę człowiekowi albo zwrócić częściową odpowiedź.

MAX_ITERATIONS = 15

async def run_agent(task: str) -> str:
    messages = [{'role': 'user', 'content': task}]
    loop_detector = LoopDetector()
    for iteration in range(MAX_ITERATIONS):
        response = await get_agent_action(messages)
        if response.is_final:
            return response.answer
        action_key = f'{response.tool}:{response.args}'
        if loop_detector.record(action_key):
            messages.append({'role': 'system', 'content': 'You are repeating yourself. Try a completely different approach.'})
            continue
        result = await execute_tool(response.tool, response.args)
        messages.append({'role': 'tool', 'content': result})
    return 'Task exceeded maximum iterations. Partial results: ' + get_partial_result(messages)

Rejestrowanie awarii na potrzeby analizy po fakcie

Każdą awarię agenta należy rejestrować z wystarczającym kontekstem, aby można było zdiagnozować ją później: pełnym opisem zadania, kompletną historią działań do momentu awarii, typem awarii i komunikatem błędu, liczbą iteracji oraz zużyciem tokenów. Dane te należy przechowywać w tabeli failures z indeksem na failure_type i task_id. Dzienniki awarii należy regularnie przeglądać, aby ustalić, które typy zadań są najbardziej podatne na określone tryby awarii, i odpowiednio ustalać priorytety poprawek.

import json
from dataclasses import asdict

async def log_agent_failure(task_id: str, failure: AgentFailure, history: list, pool):
    async with pool.acquire() as conn:
        await conn.execute('''
            INSERT INTO agent_failures
            (task_id, failure_type, step, tool_name, error_message,
             recoverable, action_history, failed_at)
            VALUES ($1, $2, $3, $4, $5, $6, $7, NOW())
        ''',
            task_id,
            failure.failure_type.value,
            failure.step,
            failure.tool_name,
            failure.error_message,
            failure.recoverable,
            json.dumps(history)
        )

Szybkie sprawdzenie

Sprawdź swoją wiedzę na temat klasyfikacji trybów awarii agentów.

Podsumowanie lekcji

W tej lekcji nauczyłeś się, że sześć głównych trybów awarii agentów obejmuje błędy narzędzi, zniekształcone wyniki, pętle rozumowania, wyczerpanie kontekstu, awarie usług zewnętrznych i niezrozumienie celu, wykrywanie pętli na podstawie historii działań pozwala wychwycić powtarzalne wzorce, zanim wyczerpią budżet iteracji, a mapowanie typów awarii na działania naprawcze umożliwia automatyczne samonaprawianie. Następnie zaimplementujemy samokorektę i refleksyjne tworzenie promptów.

Często zadawane pytania

Czy lekcja „Klasyfikowanie trybów awarii agentów” jest bezpłatna?

Tak — pełny tekst „Klasyfikowanie trybów awarii agentów” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AI Engineering Academy, przejdź na CoddyKit PRO. Kurs AI Engineering Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Klasyfikowanie trybów awarii agentów”?

Zbuduj taksonomię awarii agentów: błędy narzędzi, nieprawidłowo sformatowane dane wyjściowe, pętle rozumowania, wyczerpanie kontekstu i niedostępność usług zewnętrznych, a następnie zaprojektuj strat… Ćwiczysz AI Engineering Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AI Engineering Academy?

Nie wymagamy żadnego doświadczenia. AI Engineering Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „Klasyfikowanie trybów awarii agentów”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AI Engineering Academy?

Tak. Każda lekcja AI Engineering Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Klasyfikowanie trybów awarii agentów
  2. Samokorekta i refleksyjne promptowanie
  3. Punkty kontrolne i wznawianie zadań
  4. Eskalacja z udziałem człowieka
← Powrót do AI Engineering Academy