Typowe awarie pętli agenta
Nieskończone pętle, powtarzanie tego samego wywołania narzędzia i brak dotarcia do końcowej odpowiedzi.
Typowe awarie pętli agenta to bezpłatna lekcja AI Agents 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 Agents, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AI Agents zawiera 4 lekcji w sumie.
Pętla agenta i jej tryby awarii
Pętla agenta wykonuje się wielokrotnie: rozumowanie → wywołanie narzędzia → obserwacja wyniku → ponowne rozumowanie. Ta pętla jest potężna, ale podatna na awarie. Istnieje kilka dobrze znanych trybów awarii, które mogą uwięzić agenta, zmarnować tokeny i doprowadzić do braku użytecznych wyników.
Zrozumienie tych awarii to pierwszy krok do ochrony przed nimi.
Awaria 1: Pętle nieskończone
Pętla nieskończona występuje, gdy agent wielokrotnie wywołuje to samo narzędzie z tymi samymi argumentami, nie robiąc postępów. Może się tak zdarzyć, gdy narzędzie zwraca nieprzydatny wynik, a agent nie potrafi znaleźć wyjścia za pomocą rozumowania.
# Example of an agent in an infinite loop:
# Step 1: reasoning='Need to search for Python docs'
# tool='search_web', args={'query': 'Python documentation'}
# Step 2: reasoning='Search result was unhelpful, try again'
# tool='search_web', args={'query': 'Python documentation'}
# Step 3: reasoning='Search result was unhelpful, try again'
# tool='search_web', args={'query': 'Python documentation'}
# ... repeats until max_iterations or token budget is exhausted
print('Symptom: same tool + same arguments appearing repeatedly in steps')
print('Fix: detect repeated (tool, args) pairs and break the loop')Awaria 2: Zablokowany stan
Zablokowany stan to subtelniejsza wersja pętli nieskończonej. Agent nadal rozumuje i wywołuje różne narzędzia, ale nie potrafi dojść do odpowiedzi końcowej. Przechodzi między różnymi podejściami, nie robiąc postępów.
# Example of a stuck agent:
# Step 1: tool='search_web', args={'query': 'topic A'}
# Step 2: tool='search_web', args={'query': 'topic B'} # different args
# Step 3: tool='search_web', args={'query': 'topic A'} # back to first
# Step 4: tool='read_document', args={'url': '...'}
# Step 5: tool='search_web', args={'query': 'topic A'}
# ... no FINAL_ANSWER ever produced
print('Symptom: agent takes many steps but never calls FINAL_ANSWER')
print('Fix: max_iterations guard + force final answer if limit is near')Awaria 3: Brak odpowiedzi końcowej
Niektóre agenty zapętlają się, nie uznając nigdy zadania za ukończone. Gromadzą informacje, ale nie zatrzymują się, aby je podsumować i zwrócić. Prowadzi to do marnowania tokenów i czasu.
# An agent that never concludes:
def run_agent_bad(query: str, max_steps: int = 20) -> str:
for step in range(max_steps):
action = llm_decide_action(query, history)
if action['type'] == 'tool':
result = execute_tool(action)
history.append(result)
# BUG: No check for 'final_answer' type!
# The agent loops until max_steps, returning None
return None # never actually returns an answer
# Fix: explicitly check for final_answer signal
def run_agent_good(query: str, max_steps: int = 20) -> str:
for step in range(max_steps):
action = llm_decide_action(query, history)
if action['type'] == 'final_answer':
return action['answer'] # exit cleanly
execute_tool(action)
return 'Reached step limit without a conclusion.'Awaria 4: Błędy parsowania wywołań narzędzi
Gdy LLM generuje niepoprawny JSON dla wywołania funkcji, moduł wykonujący narzędzia nie może go sparsować. Źle napisany agent ulega awarii lub po cichu pomija ten krok. Solidny agent przechwytuje błędy parsowania i przekazuje informację o błędzie z powrotem do LLM.
import json
def safe_parse_tool_call(arguments_str: str) -> dict:
try:
return json.loads(arguments_str)
except json.JSONDecodeError as e:
print(f'Failed to parse tool arguments: {e}')
print(f'Raw: {arguments_str}')
return None
def execute_step(tool_call) -> str:
args = safe_parse_tool_call(tool_call.function.arguments)
if args is None:
# Feed the error back to the LLM in the next step
return f'ERROR: Could not parse tool arguments. Raw: {tool_call.function.arguments}'
return run_tool(tool_call.function.name, args)Awaria 5: Narzędzie nie zwraca użytecznych danych
Narzędzie może zakończyć działanie technicznie pomyślnie, czyli bez wyjątku, ale zwrócić puste lub bezużyteczne dane. Agent musi obsługiwać taki przypadek i nie zakładać, że każde wywołanie narzędzia zwraca informacje możliwe do wykorzystania.
def run_agent_with_empty_result_handling(query: str) -> str:
for step in range(20):
action = decide_next_action(query, history)
if action['type'] == 'final_answer':
return action['answer']
result = execute_tool(action['tool'], action['args'])
# Detect empty results and provide context
if not result or result.strip() == '':
observation = f'Tool {action["tool"]} returned no data. Try a different approach or different arguments.'
elif 'error' in result.lower():
observation = f'Tool error: {result}. Consider a different tool or query.'
else:
observation = result
history.append({'tool': action['tool'], 'result': observation})
return 'Could not complete task within step limit.'Awaria 6: Halucynowane nazwy narzędzi
LLM czasami generuje nazwy narzędzi, które nie istnieją. Przed próbą wywołania narzędzia należy zawsze zweryfikować jego nazwę na podstawie zarejestrowanych narzędzi. Gdy to nastąpi, należy zwrócić agentowi zrozumiały komunikat o błędzie.
REGISTERED_TOOLS = {
'search_web': search_web_function,
'get_weather': get_weather_function,
'calculate': calculate_function
}
def dispatch_tool(tool_name: str, args: dict) -> str:
if tool_name not in REGISTERED_TOOLS:
available = ', '.join(REGISTERED_TOOLS.keys())
return (
f'ERROR: Unknown tool "{tool_name}". '
f'Available tools: {available}. '
f'Please use one of the available tools.'
)
tool_fn = REGISTERED_TOOLS[tool_name]
return tool_fn(**args)Awaria 7: Wyczerpanie budżetu tokenów
Długotrwały agent, który przechowuje w swoim kontekście pełne wyniki narzędzi, może osiągnąć limit okna kontekstu LLM. Przed dodaniem dużych wyników narzędzi do historii należy je podsumować lub obciąć.
def truncate_tool_result(result: str, max_chars: int = 2000) -> str:
if len(result) <= max_chars:
return result
truncated = result[:max_chars]
return f'{truncated}\n... [result truncated to {max_chars} chars]'
def add_observation_to_history(history: list, tool_name: str, result: str):
safe_result = truncate_tool_result(result, max_chars=2000)
history.append({
'role': 'tool',
'content': safe_result,
'tool_name': tool_name
})
print(f'[Step] Tool={tool_name}, Result length={len(result)} (stored {len(safe_result)})')
if __name__ == '__main__':
demo_history = []
add_observation_to_history(demo_history, 'search_web', 'x' * 3000)
Programowe wykrywanie trybu awarii
Należy napisać funkcję diagnostyczną, która analizuje historię kroków agenta, aby określić, który tryb awarii wystąpił. Jest to niezwykle przydatne podczas debugowania.
def diagnose_agent_failure(steps: list) -> str:
if not steps:
return 'No steps recorded'
# Check for infinite loop: same (tool, args) repeated
seen = {}
for s in steps:
key = (s.get('tool'), str(s.get('args')))
seen[key] = seen.get(key, 0) + 1
repeated = {k: v for k, v in seen.items() if v > 2}
if repeated:
return f'INFINITE_LOOP: repeated actions: {repeated}'
# Check for missing final answer
has_answer = any(s.get('type') == 'final_answer' for s in steps)
if not has_answer and len(steps) >= 15:
return 'STUCK_STATE: many steps taken but no final answer'
# Check for parse errors
errors = [s for s in steps if 'ERROR' in str(s.get('result', ''))]
if len(errors) > 2:
return f'TOOL_ERROR: {len(errors)} tool errors in pipeline'
return 'OK'
if __name__ == '__main__':
demo_steps = [{'tool': 'search_web', 'args': {'q': 'weather'}} for _ in range(3)]
print('Diagnosis:', diagnose_agent_failure(demo_steps))
Implementowanie prostego budżetu kroków
Każda pętla agenta działająca w środowisku produkcyjnym musi mieć sztywny limit kroków. To najważniejszy mechanizm ochronny — gwarantuje zakończenie pętli niezależnie od decyzji LLM.
def run_agent_with_budget(query: str, max_steps: int = 15) -> dict:
history = []
for step in range(1, max_steps + 1):
print(f'[Step {step}/{max_steps}]')
action = decide_next_action(query, history)
if action['type'] == 'final_answer':
return {
'status': 'success',
'answer': action['answer'],
'steps_taken': step
}
result = execute_tool(action['tool'], action['args'])
history.append({'step': step, 'tool': action['tool'], 'result': result})
if step == max_steps - 1:
# Warn the agent it must conclude
history.append({'role': 'system',
'content': 'You must provide a FINAL_ANSWER on the next step.'})
return {'status': 'timeout', 'answer': None, 'steps_taken': max_steps}Szybkie zestawienie: tryby awarii i rozwiązania
Podsumowanie sześciu trybów awarii pętli agenta i sposobów ich naprawy:
- Pętla nieskończona: wykrywać powtarzające się pary (tool, args); przerywać działanie i przekazywać informację o błędzie
- Zablokowany stan: stosować zabezpieczenie max_iterations; wymuszać odpowiedź końcową w pobliżu limitu
- Brak odpowiedzi końcowej: jawnie sprawdzać sygnał `final_answer` w działaniu
- Błędy parsowania: opakować parsowanie JSON w try/except; przekazywać błąd z powrotem do LLM
- Puste wyniki narzędzi: wykrywać puste ciągi znaków; przekazywać informację zwrotną „brak danych”
- Halucynowane nazwy narzędzi: weryfikować je na podstawie zarejestrowanych narzędzi; zwracać komunikat o błędzie
Sprawdzenie wiedzy: awarie pętli agenta
Sprawdź swoje rozumienie typowych trybów awarii pętli agenta.
Podsumowanie: typowe awarie pętli agenta
Mogą Państwo teraz rozpoznawać główne tryby awarii pętli agenta i chronić się przed nimi:
- Pętle nieskończone, zablokowane stany i brak odpowiedzi końcowych wymagają mechanizmu ochronnego maksymalnej liczby iteracji
- Błędy parsowania wywołań narzędzi wymagają zastosowania try/except wokół parsowania JSON
- Puste wyniki narzędzi wymagają wykrywania i przekazywania LLM zrozumiałych informacji zwrotnych
- Halucynowane nazwy narzędzi wymagają weryfikacji na podstawie listy zarejestrowanych narzędzi
- Wyczerpanie budżetu tokenów wymaga obcinania wyników
Solidna pętla agenta przewiduje wszystkie te tryby awarii i obsługuje je w kontrolowany sposób.
Często zadawane pytania
Czy lekcja „Typowe awarie pętli agenta” jest bezpłatna?
Tak — pełny tekst „Typowe awarie pętli agenta” 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 Agents, przejdź na CoddyKit PRO. Kurs AI Agents zawiera 4 lekcji w sumie.
Co nauczysz się w „Typowe awarie pętli agenta”?
Nieskończone pętle, powtarzanie tego samego wywołania narzędzia i brak dotarcia do końcowej odpowiedzi. Ćwiczysz AI Agents 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 Agents?
Nie wymagamy żadnego doświadczenia. AI Agents 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 „Typowe awarie pętli agenta”?
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 Agents?
Tak. Każda lekcja AI Agents 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
- Typowe awarie pętli agenta
- Logowanie śledzenia kroków agenta
- Wykrywanie i przerywanie nieskończonych pętli
- Techniki debugowania krok po kroku