Ukryta architektura AI agentów: co wszyscy robią źle

Jeśli ostatnio eksperymentujesz z AI agentami, pewnie zauważyłeś dziwną rzecz: czasem wykonują skomplikowane instrukcje bezbłędnie, a czasem ignorują najprostsze zasady, które właśnie napisałeś.

Nie wydaje ci się. Pod każdym AI agentem kryje się fundamentalna architektura, która dokładnie tłumaczy, dlaczego tak się dzieje — i gdy ją zrozumiesz, wszystko inne nabiera sensu.

To tylko pętla while-true

Oto sekret, który brzmi niemal zbyt prosto: AI agent to w gruncie rzeczy pętla while-true, która dopisuje do tablicy.

while True:
    user_input = get_input()
    response = llm.complete(user_input)
    if response.wants_tool:
        result = execute_tool(response.tool_call)
        response = llm.complete(result)
    print(response)

I tyle. To jest rdzeń architektury. Wszystko inne — definicje narzędzi, systemowe prompty, zarządzanie kontekstem — to tylko opakowanie wokół tej pętli.

„Tablica", o której mówimy, to context window. Każde wywołanie API wysyła całą nagromadzoną rozmowę. Każda interakcja dopisuje kolejny wpis. Sam model pozostaje całkowicie bezstanowy między wywołaniami.

Twoje context window zawiera: system prompt, definicje narzędzi, wiadomość użytkownika, odpowiedzi asystenta, wyniki narzędzi i cokolwiek innego tam upchniesz. Tablica rośnie z każdą wymianą zdań.

Problem inteligentnej strefy

I tutaj robi się ciekawie. Większość developerów zakłada, że context window jest jednorodne — wrzucasz informacje, model przetwarza je równomiernie.

Nie jest.

Pierwsze około 40% context window to strefa, w której model myśli klarownie. Nazwijmy to „smart zone". Po przekroczeniu tego progu uwaga się rozprasza. Wybory narzędzi stają się niedbałe. Instrukcje zostają zapomniane. Cel zaczyna dryfować.

To wyjaśnia, dlaczego dodawanie więcej kontekstu może faktycznie pogorszyć działanie agenta. Frontier thinking models konsekwentnie wykonują około 150-200 instrukcji, zanim zaczynają się rozsypywać. Powyżej tego progu nawet jawne reguły na samym szczycie promptu są ignorowane.

Pomyśl o tym: jeśli堆ujesz systemowe prompty, wiele definicji narzędzi, historię rozmowy i dokumenty referencyjne, możesz wypychać swoje kluczowe instrukcje poza punkt, w którym model może je jeszcze wiarygodnie realizować.

Problem alokacji, o którym nikt nie mówi

Statyczne wypełniacze to cichy zabójca wydajności agentów.

Zanim jeszcze twoja rozmowa się zacznie, prawdopodobnie wypełniasz context window rzeczami, które wydają się niezbędne: rozbudowanymi system promptami, obszernymi definicjami narzędzi, bankami pamięci, konfiguracjami MCP, referencjami do dokumentacji.

Cała ta statyczna zawartość zjada twoją smart zone jeszcze przed pierwszą wiadomością użytkownika.

Rezultat? Twoje najważniejsze instrukcje — te, które definiują zachowanie agenta dla tego konkretnego zadania — konkurują o miejsce w kurczącej się inteligentnej strefie.

Dlatego najlepsi agenci zaczynają od zera. Nowa sesja oznacza puste context window. Żadnego nagromadzonego bałaganu. Żadnych konkurujących instrukcji z poprzednich zadań. Tylko to, co potrzebne do bieżącej roboty.

Context rot: cichy tryb awarii

Oto co jest podstępne w zarządzaniu kontekstem: nic nie zawodzi.

W tradycyjnym oprogramowaniu dostajesz błędy. Wyjątki. Awarie, które możesz wykryć i obsłużyć. Ale przy context windows każde wywołanie się udaje. Model odpowiada. Po prostu... robi się gorzej.

To samo okno. Ten sam model. Po prostu się zapełnia.

To jest „context rot" — stopniowa degradacja wydajności agenta w miarę jak context window zapycha się nagromadzoną historią rozmowy, wynikami narzędzi i referencjami dokumentacyjnymi. Nie zobaczysz komunikatu o błędzie. Po prostu zauważysz, że twój agent staje się mniej niezawodny, mniej skupiony, mniej zgodny z twoimi instrukcjami.

To fundamentalnie różni się od typowych bugów oprogramowania. To nie awaria — to problem pojemności. I podchodzi niepostrzeżenie.

Jak wykorzystać smart zone na swoją korzyść

Zrozumienie tych zasad prowadzi do praktycznych strategii:

Zaczynaj od zera dla każdego zadania. Nie używaj zmęczonego okna z poprzedniego projektu. Nowe zadania = nowe sesje. Czysta blacha, pełna smart zone.

Dodawaj tylko to, czego potrzebuje to zadanie. Ta integracja MCP, która przydaje się do innej roboty? Wyłącz ją. Notatki z innego projektu? zajmują tylko miejsce. Bezwzględnie filtruj to, co trafia do context window.

Zrzucaj na dysk. Duże pliki zostają na dysku. Podsumowania idą do okna. Zawsze możesz przeczytać plik, gdy potrzebujesz — po tym, jak już go streścisz dla context window.

Używaj sub-agentów do pobocznych questów. Gdy twój agent musi zbadać coś pobocznego, odpal sub-agenta. Niech zbada i wróci z jednym akapitem. Nie pozwalaj eksploracji zaśmiecać głównego kontekstu.

Zostawiaj miejsce pod kreską. Gdy twój agent skończy główną pracę, wciąż musisz sfinalizować rzeczy — pisać testy, commitować kod, odpalać lintery. Jeśli context jest wypchany po brzegi, nie ma miejsca na ten kluczowy ostatni krok.

Dziel dużą pracę na sesje. Gdy zadanie nie mieści się w jednym oknie, najpierw je zaplanuj. Napisz specyfikację na dysk. Niech kolejni agenci odbierają je tam, gdzie poprzedni skończył.

Prawdziwy wniosek

Każda sesja zaczyna się od zera. Kontekst nie organizuje się sam.

Ktoś musi zająć się alokacją kontekstu, rotacją, kompresją i odzyskiwaniem. Ktoś musi zdecydować, co warto trzymać w smart zone, a co wyląduje na dysku.

Anthropic dostarcza harness agenta — pętlę while-true, wykonywanie narzędzi, core'ową integrację LLM. Ty dostarczasz warstwę wokół niego. Zarządzanie kontekstem. Ramowanie zadania. Projekt system promptu.

Zrozumienie tej architektury nie uczyni cię ekspertem AI z dnia na dzień. Ale da ci framework do diagnozowania, gdy agenci się psują, i słownik do systematycznego myślenia o zarządzaniu kontekstem.

Następnym razem, gdy twój agent zacznie ignorować instrukcje, będziesz dokładnie wiedział, co sprawdzić: ile smart zone pozostało i co ją wypełnia.

To jest ukryta architektura. Teraz idź budować coś.