Antywzorce pętli agenta: czego nie robić
Po tej lekcji rozpoznasz pięć błędów, przez które pętla agenta kończy się za wcześnie, kręci bez końca albo gubi dane — i wiesz, czym każdy z nich zastąpić.
W jednej minucie
O tym, czy pętla kręci się dalej, decyduje stop_reason. Tekst odpowiedzi, liczba obrotów i pierwszy blok treści to złe sygnały.
Każde wywołanie dostaje swój wynik — zawsze, w całości albo sensownie skrócony, w jednej wiadomości.
Wszystkie pięć błędów z tej lekcji działa „prawie dobrze” w prostym teście. Wychodzą dopiero przy dłuższych zadaniach, więc testuj na scenariuszach z wieloma krokami.
Koniec rozpoznawany po tekście
Najczęstszy błąd: kod uznaje zadanie za skończone, bo w odpowiedzi pojawił się tekst albo słowo „gotowe”.
Tymczasem Claude często pisze coś od siebie, zanim wywoła narzędzie1. Tekst trzeba traktować jak każdy inny tekst modelu, bez polegania na jego formacie1.
# ŹLE: pierwszy blok to tekst, więc „koniec”?
if response.content[0].type == "text":
return response
# ŹLE: szukanie słów w odpowiedzi
if "gotowe" in response.content[0].text.lower():
return response
# DOBRZE: decyduje stop_reason
if response.stop_reason != "tool_use":
return response
Ta sama odpowiedź może zawierać i tekst, i prośbę o narzędzie. Wartość tool_use mówi jednoznacznie, że Claude woła narzędzie2:
{
"stop_reason": "tool_use",
"content": [
{ "type": "text",
"text": "Gotowe, sprawdzam jeszcze pogodę." },
{ "type": "tool_use",
"id": "toolu_01",
"name": "get_weather",
"input": { "location": "Zakopane" } }
]
}
{
"koniec?": false,
"powod": "stop_reason == tool_use",
"dalej": "uruchom get_weather i odeślij tool_result"
}
Limit to bezpiecznik, nie kierownica
Drugi błąd: pętla kończy się po stałej liczbie obrotów, zamiast słuchać modelu.
Limit iteracji jest potrzebny — to Warunek stopu, który pozwala zachować kontrolę3. Ale jako główny sygnał końca przerywa zadania, które potrzebują więcej kroków.
| Sygnał | Rola | Jako koniec zadania |
|---|---|---|
stop_reason | Mówi, czy model czeka na narzędzie | główny sygnał |
| Limit iteracji | Chroni przed pętlą bez końca | tylko awaryjnie |
| Tekst odpowiedzi | Treść dla użytkownika | nigdy |
Ocena w ostatniej kolumnie to nasza rada, oparta na źródłach z tej lekcji.
Gdy limit się wyczerpie, nie zwracaj ostatniej odpowiedzi jak wyniku. Powiedz wprost, że zadanie przerwano po N krokach, i zapisz to w logach.
Nie gub wyników narzędzi
Trzeci błąd: wynik narzędzia nie wraca do modelu, bo był za duży, nieudany albo „niepotrzebny”.
Agent ocenia postęp na podstawie tego, co w każdym kroku dostaje ze środowiska — to jego punkt odniesienia3. Bez wyniku zgaduje.
- Odeślij go zawsze — zaraz po prośbie, bez wiadomości pomiędzy4.
- Duży wynik skróć u źródła: stronicowanie, filtrowanie albo obcięcie z rozsądnymi domyślnymi wartościami5.
- Powiedz modelowi, że obcięto i jak dostać resztę5.
- Nieuruchomione wywołanie też dostaje wynik — z
is_error: truei krótkim wyjaśnieniem6.
Podmiana historii na streszczenie w środku pętli, „żeby oszczędzić tokeny”, zabiera modelowi wyniki, na których opiera następny krok. Skracaj pojedyncze wyniki, nie całą rozmowę.
Kilka wywołań naraz
Czwarty błąd dotyczy równoległych wywołań: Claude prosi o kilka narzędzi w jednej odpowiedzi, a kod odsyła wyniki w osobnych wiadomościach.
Poprawnie wszystkie wyniki idą razem, w jednej wiadomości użytkownika6. Inaczej uczysz Claude, żeby unikał równoległych wywołań6.
[
{ "role": "assistant",
"content": ["tool_use A", "tool_use B"] },
{ "role": "user",
"content": ["tool_result A"] },
{ "role": "user",
"content": ["tool_result B"] }
]
[
{ "role": "assistant",
"content": ["tool_use A", "tool_use B"] },
{ "role": "user",
"content": ["tool_result A",
"tool_result B"] }
]
Odpowiedź ucięta w połowie narzędzia
Piąty błąd: kod próbuje wykonać wywołanie, którego model nie zdążył dokończyć.
Gdy odpowiedź urwała się na limicie max_tokens w środku bloku tool_use, ponów żądanie z wyższym max_tokens, żeby dostać całe wywołanie2.
Narzędzie dostaje długi tekst jako input, a max_tokens to 1024. Odpowiedź kończy się w połowie JSON-a. Zamiast wykonywać urwane wywołanie, ponów żądanie z większym limitem.
Pytania sprawdzające
Pierwszy blok odpowiedzi to tekst „Gotowe”, a stop_reason to tool_use. Czy pętla się kończy?
Nie. Claude często pisze tekst przed wywołaniem narzędzia; decyduje stop_reason, a tool_use znaczy, że czeka na wynik.
Dlaczego limit iteracji nie powinien być głównym sygnałem końca?
Bo przerywa zadania, które potrzebują więcej kroków. To bezpiecznik przed pętlą bez końca; koniec zadania wyznacza stop_reason.
Narzędzie zwróciło 2 MB tekstu. Co robisz?
Skracasz wynik u źródła (stronicowanie, filtrowanie, obcięcie), mówisz modelowi, że obcięto i jak dostać resztę, i odsyłasz to jako tool_result.
Claude poprosił o dwa narzędzia naraz. Jak odsyłasz wyniki?
Oba tool_result w jednej wiadomości użytkownika. Osobne wiadomości uczą Claude, żeby unikał równoległych wywołań.
Podsumowanie
- Tekst w odpowiedzi nie znaczy „koniec”; decyduje
stop_reason. - Limit iteracji to bezpiecznik, nie sposób kończenia zadań.
- Każde wywołanie dostaje wynik — duży skróć u źródła i powiedz, że obcięto.
- Wyniki równoległych wywołań idą razem, w jednej wiadomości.
- Wywołanie urwane na
max_tokensponawiasz z wyższym limitem, nie wykonujesz.
Źródła
- Define tools — Claude Docssprawdzone 2026-11-02
- Stop reasons and fallback — Claude Docssprawdzone 2026-11-02
- Building effective agents — Anthropic Engineeringopublikowano 2024-12-19 · sprawdzone 2026-11-02
- Handle tool calls — Claude Docssprawdzone 2026-11-02
- Writing effective tools for AI agents — Anthropic Engineeringsprawdzone 2026-11-02
- Parallel tool use — Claude Docssprawdzone 2026-11-02