Czym jest AI agent: pięć klasycznych typów i dwie rywalizujące definicje

Najstarszy przykład w tej dziedzinie to odkurzacz w świecie dwóch pól, A i B, z których każde jest czyste albo brudne.¹ Przetrwał w każdym podręczniku, bo to najmniejszy świat, w którym agent może mieć rację albo się mylić.

Percept to para — gdzie jestem i czy tutaj jest brudno — a akcje to SUCK, LEFT i RIGHT. Cały program to jedna linia.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

Uruchom go dla każdej konfiguracji początkowej świata z dwoma polami:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

To jest simple reflex agent: działa wyłącznie na podstawie bieżącego percept, bez pamięci czegokolwiek sprzed chwili. To nie jest zabawkowa kategoria — termostat jest takim agent, podobnie jak pojedyncze wywołanie modelu językowego bez dołączonej rozmowy.

Teraz zepsujmy go tak, jak robi to rzeczywistość. Prawdziwy robot odkurzający ma czujnik brudu i zderzak, a nie kwadrat z etykietą A pod dywanem. Usuń lokalizację z percept i nie zmieniaj niczego innego:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

Ten sam program, dwa pola. Z jednego stanu początkowego kończy w trzech krokach; z innego wjeżdża w prawą ścianę pięćset razy i jechałby dalej, aż padłaby bateria. Nie potrafi dostrzec różnicy między tymi dwiema sytuacjami, więc nie potrafi zachować się w nich inaczej. Russell i Norvig ujmują ogólny wynik w jednym zdaniu: nieskończone pętle są często nieuniknione dla simple reflex agents w częściowo obserwowalnych środowiskach.¹

Jest poprawka, która kosztuje jedną linię i żadnej pamięci — warto ją zmierzyć, zanim sięgniemy po coś sprytniejszego.

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

Dwa tysiące uruchomień całkowicie brudnego korytarza w trzech rozmiarach, wszędzie ten sam seed generatora:

Losowość całkowicie usuwa pętlę. Ale też kosztuje: osiem pokoi wymaga piętnastu ruchów, jeśli wiesz, co robisz, a ten agent średnio robi 68,7 i raz potrzebował 306. To cały rozdział w miniaturze. Każda zdolność, którą dodamy, kupuje poprawność w przypadku, z którym poprzedni agent sobie nie radził, i pobiera opłatę w walucie, którą najpierw musisz nazwać.

Agent postrzega swoje środowisko przez czujniki i działa przez aktuatory. Program agent to funkcja od percepts do akcji — każdy listing powyżej nią jest. Sekwencja percepts to wszystko, co zostało dotąd postrzeżone, a simple reflex agent ignoruje wszystko poza ostatnim elementem.

Racjonalność to słowo, które większość artykułów rozumie źle, a poprawne zrozumienie sprawia, że reszta tego rozdziału zaczyna być użyteczna. Agent nie jest racjonalny ani irracjonalny sam w sobie. Russell i Norvig definiują racjonalny agent jako taki, który dla każdej możliwej sekwencji percepts wybiera akcję, która ma zmaksymalizować jego miarę wydajności, biorąc pod uwagę dowody z tej sekwencji i całą wbudowaną wiedzę, którą ma.¹ Miara wydajności nie znajduje się wewnątrz agent: należy do projektanta, a racjonalność jest definiowana tylko względem niej.

Specyfikację zwyczajowo zapisuje się jako cztery rzeczy, PEAS: performance measure, environment, actuators, sensors.

Zauważ, który wiersz odstaje. Prawie każdy zespół budujący agents w 2026 roku spisuje E, A i S — schematy narzędzi, integracje, format wiadomości — bo bez nich kod się nie uruchomi. Prawie nikt nie zapisuje P. Bez tego „nasz agent działa dobrze” nie ma znaczenia, które da się sprawdzić, a „racjonalny” nie da się zastosować do systemu w ogóle, tylko do demonstracji. Rozdział 29 jest o zamianie P w liczbę — i właśnie dlatego istnieje.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Środowiska zadań klasyfikuje się dalej według siedmiu osi, z których pięć decyduje tutaj o większości trudności: w pełni albo częściowo obserwowalne, deterministyczne albo nie, epizodyczne albo sekwencyjne, statyczne albo dynamiczne, znane albo nieznane.¹ Agent rozmawiający z prawdziwymi narzędziami przez prawdziwą sieć znajduje się w trudnym rogu wszystkich pięciu — niedeterministyczny nawet przy temperaturze zero (rozdział 17) i, co jest niedoceniane, nieznany, bo nie masz niezawodnego modelu tego, co twoje własne narzędzia robią ze światem. Dlatego pętla z rozdziału 23 bardziej potrzebuje obsługi błędów niż planowania.

Prawdziwe podłogi nie są jednowymiarowe, więc podnieśmy świat do planu. Kratki to ściany, gwiazdki to brud, a robot startuje w środkowej komorze:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

Oczywiste ulepszenie to pamięć. Agent prowadzi mapę: każde pole, na którym stał, i każde pole, na którym zadziałał zderzak. Jego reguła każe wejść na sąsiednie pole, którego jeszcze nie odwiedził — w prawo, potem w dół, potem w lewo, potem w górę — i wycofać się, gdy wszystko dookoła jest znane. To model-based reflex agent: utrzymuje stan wewnętrzny z historii percepts, więc może działać na podstawie tego, czego aktualnie nie widzi.

To prawdziwa poprawa, ale wciąż za mało:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

Pięć tysięcy ruchów, połowa podłogi nigdy niewidziana. Mapa jest poprawna i reguły są poprawne. Agent nie potrafi użyć mapy, żeby gdzieś pójść: jego reguły odpowiadają tylko na pytanie „na którego z moich czterech sąsiadów mam wejść”, więc gdy skończą mu się nieodwiedzone pola obok niego, nie ma sposobu wyrażenia myśli osiem ruchów stąd jest nieodwiedzone pole i chciałbym na nim stać. Wie, gdzie jest. Nie wie, gdzie chce być.

Goal-based agent ma, oprócz swojego modelu świata, opis sytuacji, którą chce doprowadzić do skutku, i wybiera akcje, przeszukując ich sekwencje, aż znajdzie taką, która tam kończy. Cele zmieniają wybór akcji z odczytu z tabeli w wyszukiwanie.

Cel brzmi: „nie zostaje żadne brudne pole”. Wyszukiwanie to breadth-first przejście do najbliższego brudnego pola, a zwrócona ścieżka jest planem.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

Dwadzieścia siedem ruchów, podłoga czysta. Ale spójrz na kolumnę baterii i ostatni odcinek planu. Kolumna 0 jest pokryta dywanem: przejście przez pole z dywanem kosztuje sześć jednostek baterii, przez kafelki jedną. Agent wrócił do domu kolumną 0, bo to cztery ruchy zamiast ośmiu, a te cztery ruchy po dywanie kosztowały 24, podczas gdy ośmioruchowy objazd kosztowałby 13.

Nie może zrobić inaczej. Cel jest testem binarnym: podłoga jest czysta albo nie. Każdy plan, który kończy się czystą podłogą, spełnia go tak samo, więc gdy udaje się kilka planów, agent nie ma czym między nimi wybierać. Żeby woleć jeden sukces od drugiego, trzeba mieć liczbę nad wynikami, a ta liczba to funkcja użyteczności. Agent, który ją maksymalizuje, to utility-based agent.

Zmiana w kodzie to jeden składnik wewnątrz wyszukiwania. Breadth-first search liczy ruchy; każ mu liczyć koszt, a masz algorytm Dijkstry i inny agent:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

Cztery dodatkowe ruchy, jedenaście jednostek baterii mniej: o dwadzieścia jeden procent taniej. Ten sam cel, ta sama mapa, ten sam kod poza jednym składnikiem. Dwaj agents różnią się tylko tym, w czym próbują być dobrzy, i wybierają różne drogi do domu.

To także pierwszy moment, w którym agent potrzebuje czegoś, czego sam nie potrafi wytworzyć. Ktoś musi zdecydować, ile jednostka baterii jest warta względem ruchu. Użyteczność to miara wydajności zapisana w formie, z którą agent potrafi liczyć, a jej napisanie jest pracą projektanta. Gdy ludzie mówią, że agent „zoptymalizował niewłaściwą rzecz”, prawie nigdy nie mają na myśli błędu. Mają na myśli, że ta linia została napisana niedbale.

Teraz pozwól brudowi wracać. Cztery pokoje brudzą się ponownie w czterech różnych tempach, a agent nigdy ich nie poznaje. Odwiedza jeden pokój na tick i widzi tylko ten pokój. Miara wydajności to room-ticks spędzone w stanie brudnym przez 4 000 ticków — im mniej, tym lepiej.

Learning agent, w podręcznikowym rozkładzie, to dowolny z powyższych plus trzy części: learning element, który zmienia agent, critic, który mówi mu, jak agent wypada względem stałego standardu wydajności, oraz problem generator, który proponuje akcje warte spróbowania ze względu na to, czego mogłyby nauczyć.¹ Trzy polityki w tym samym środowisku. Pierwsza się nie uczy; druga i trzecia uczą się tego samego i używają tego inaczej.

Ukryte tempa wynosiły 0,35 dla kuchni, 0,05 dla holu, 0,02 dla gabinetu i 0,01 dla strychu — a learner A je znalazł. Poprawnie zidentyfikował kuchnię jako najbrudniejszy pokój w domu, po czym chodził do kuchni w każdym ticku przez resztę symulacji, gdy pozostałe trzy pokoje siedziały brudne już zawsze. Jest pięć razy gorszy niż brak uczenia w ogóle i nie jest zepsuty.

Lekcja jest ta sama co w sekcji o użyteczności. Learner A maksymalizował „prawdopodobieństwo, że pokój, który zaraz odwiedzę, jest brudny”. Miara wydajności brzmiała „room-ticks spędzone w stanie brudnym”. Różne liczby; druga jest tym, co oceniał critic, a nikt nie powiedział o niej agent. Learner B mnoży to samo wyuczone tempo przez czas od ostatniej wizyty — oczekiwany brud, który znajdzie, a nie szansę znalezienia jakiegokolwiek — i pokonuje patrol, od którego zaczął.

Jeden szczegół implementacyjny zdecydował o wyniku. W pierwszej wersji learner B pokój, w którym przez trzy wizyty nie pojawił się brud, dostawał tempo dokładnie zero — a zero razy cokolwiek to zero, więc nigdy więcej go nie odwiedzano i estymaty nie dało się poprawić. Wygładzenie ułamka, sukcesy plus jeden przez próby plus dwa, zmieniło 11 895 w 1 576. „Jeszcze nie zaobserwowano” i „zmierzono i wyszło zero” to różne twierdzenia, a system, który zapisuje je w tym samym polu, podejmuje decyzje, których nie potrafi odwrócić.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

Każdy z pięciu działa dziś na produkcji pod inną nazwą.

Dwa wiersze są bliżej niż analogia — w sposób, który kosztuje pieniądze.

Chat jest model-based reflex agent, którego model nie jest wewnętrzny. W podręczniku stan jest zmienną wewnątrz programu agent. W chacie jest transkryptem: żyje po twojej stronie, jest ponownie wysyłany w całości przy każdym wywołaniu i za każdym razem odtwarzany od zera wewnątrz modelu. To kwadratowy rachunek z rozdziału 16 i ten sam obiekt, który podręcznik narysował jako pudełko z etykietą „state”. Oto różnica, zmierzona na jednym pytaniu uzupełniającym z dwiema poprzednimi wiadomościami i bez nich:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

Ten sam model, te same trzy słowa inputu użytkownika, a drugie uruchomienie to robot w korytarzu wjeżdżający w ścianę. W tym przebiegu nie było narzędzi, więc 15 jest zmyślone — ale to stan sprawia, że follow-up w ogóle coś znaczy. Odtwarzasz go za każdym razem i płacisz za niego 2,3× input tokens w rozmowie dwuturowej. Rozdział 16 zmierzył, dokąd ten mnożnik dochodzi przy turze czterdziestej.

Reflexion jest learning agent, który zmienia swój input, a nie program. W podręcznikowym rozkładzie learning element modyfikuje performance element. Reflexion zostawia wagi w spokoju i zapisuje refleksyjny tekst do bufora epizodycznego, który czyta następna próba.³ Learning element to prompt, pamięć to wiersz w bazie danych, performance element to zamrożony model — a diagram jest podręcznikowy, bez zmian.

A oto uczciwe ograniczenie tego mapowania. Pięć typów klasyfikuje program agent. W 2026 roku ten program jest rozcięty na pół: część jest twoim kodem, część znajduje się w wagach, których nie trenowałeś. Gdy model sam decyduje, żeby wywołać narzędzie, czy test celu jest w twoim programie, czy w modelu? Taksonomia nie ma odpowiedzi, bo gdy powstawała, nie było innego miejsca, w którym mógłby być — i właśnie przy tym pytaniu dwie współczesne definicje się rozchodzą.

Definicje są sporami o zachowanie, a dużo łatwiej je oceniać, mając przed sobą trace.

Pętla poniżej wysyła rozmowę do modelu; jeśli odpowiedź zawiera tool call, wykonuje narzędzie, dopisuje wynik i wysyła całość ponownie. Działa na lokalnym Qwen2.5-0.5B-Instruct za endpointem w kształcie OpenAI na tej maszynie — to szew z rozdziału 14, więc pętla ani nie wie, ani jej nie obchodzi, co jest za portem.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

Dwie linie niosą cały pomysł i obie są oznaczone; reszta to księgowość. Wszystkie trzy zachowania widać w jednym przebiegu. Zapytany o coś, co potrafi zrobić sam, model odpowiada. Zapytany o coś, czego nie potrafi, wywołuje:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

I zatrzymuje się — trzecie zachowanie, najłatwiejsze do przeoczenia, bo wygląda jak brak zdarzenia. Pętla kończy się, bo tura 2 wróciła bez tool call. Nikt tego nie zdecydował; zrobił to model, emitując prozę. Warunek zakończenia tego programu jest znakiem nieobecności.

Dwa kolejne przebiegi są warte miejsca. Poproszony o porównanie dwóch miast, model wykonuje oba tool calls w jednej turze, dostaje oba odczyty z powrotem i myli porównanie:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

Narzędzia zadziałały. Wywołanie równoległe zadziałało. Pętla zadziałała. Odpowiedź jest fałszywa, choć obie poprawne liczby leżą w transkrypcie. Owinięcie modelu pętlą nie sprawia, że rozumuje; daje modelowi, który się myli, zdolność działania na podstawie tej pomyłki — co zapowiada rozdział 30 i połowę rozdziału 29.

Teraz usuń oznaczone return i pozwól pętli biec do limitu. To samo pytanie, ten sam model:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

Cztery razy więcej input tokens, cztery razy więcej czasu zegarowego i zakończenie, w którym agent zapomniał, o co go zapytano, i przesłuchuje użytkownika w sprawie pytania, na które ten odpowiedział w turze pierwszej. Poprawna odpowiedź była na ekranie w turze 2, a każda kolejna tura pogarszała transkrypt.

Agent nie jest więc pętlą. Jest pętlą plus regułą wyjścia z niej, a ta ma dokładnie jedną taką regułę. Rozdział 23 znajduje ich pięć i pokazuje, co się psuje, gdy każdej brakuje.

Obie cytowane, a nie parafrazowane, bo to w parafrazach produkuje się zamieszanie.

Definicja pierwsza stawia granicę tam, gdzie leży kontrola przepływu. Anthropic w Building effective agents nazywa niejednoznaczność i rozstrzyga ją tak:

„W Anthropic kategoryzujemy wszystkie te warianty jako agentic systems, ale rysujemy ważne rozróżnienie architektoniczne między workflows a agents: Workflows to systemy, w których LLMs i narzędzia są orkiestracji przez z góry zdefiniowane ścieżki kodu. Agents natomiast to systemy, w których LLMs dynamicznie kierują własnymi procesami i użyciem narzędzi, zachowując kontrolę nad tym, jak wykonują zadania.”⁴

Test jest pytaniem o twój kod źródłowy: kto wybrał następny krok? switch w twoim programie: workflow. Model: agent. Ten sam dokument mówi, że agents „są zazwyczaj po prostu LLMs używającymi narzędzi na podstawie feedbacku środowiska w pętli” — czyli dokładnie listing powyżej.

Definicja druga stawia granicę na niezależności od użytkownika. OpenAI w A practical guide to building agents otwiera stronę definicyjną tak:

„Podczas gdy konwencjonalne oprogramowanie pozwala użytkownikom usprawniać i automatyzować workflows, agents potrafią wykonywać te same workflows w imieniu użytkowników z wysokim stopniem niezależności. Agents to systemy, które niezależnie wykonują zadania w twoim imieniu.”⁵

Dwa zdania dalej, na tej samej stronie, wyklucza:

„Aplikacje, które integrują LLMs, ale nie używają ich do kontrolowania wykonywania workflow — na przykład proste chatboty, single-turn LLMs albo klasyfikatory sentymentu — nie są agents.”⁵

Przeczytaj te cytaty po kolei. Zdania otwierające rysują granicę na niezależności: czy to coś odchodzi i kończy robotę beze mnie? Czwarte rysuje ją na kontroli wykonania, czyli dokładnie na linii Anthropic. Różne testy, ta sama strona, i istnieją prawdziwe systemy, co do których się nie zgadzają.

Pod spodem jest kolizja słownictwa, która powoduje spory na prawdziwych spotkaniach. W pierwszym dokumencie workflow jest architekturą i jest tym, co nie jest agent. W drugim workflow to „sekwencja kroków, które trzeba wykonać, aby osiągnąć cel użytkownika” — sama praca, którą każdy agent ma. „Zastąpiliśmy workflow agent” jest spójne w pierwszej definicji i bliskie bezsensu w drugiej.

Trzy systemy istniejące w 2026 roku, według obu definicji.

Dwa z trzech zmieniają stronę. To nie jest porażka żadnego dokumentu. To ostrzeżenie przed takim spotkaniem, na którym dwie osoby całkowicie zgadzające się co do tego, co system robi, spędzają godzinę, nie zgadzając się, jak go nazwać.

Definicje zderzają się, bo każda zwija dwa niezależne pytania w jedno słowo. Rozdziel je, a spór staje się tabelą — bardziej użyteczną niż werdykt.

Każda definicja kwestionuje inną komórkę, a pozostałe dwie w ogóle nie są sporne. Więc gdy etykieta ma znaczenie — w umowie, przeglądzie ryzyka, postmortem — dwa zdania warte zapisania nie brzmią „czy to agent”, tylko kto wybrał następny krok i kto obserwował. Na oba da się odpowiedzieć, czytając kod, żadne nie potrzebuje cudzej definicji, a razem niosą każdą konsekwencję, za którą miała stać etykieta.

Nic z tego nie jest nowe. Wooldridge i Jennings opisali konkurujące sensy „agent” w 1995 roku;⁶ Franklin i Graesser zadali pytanie z tego rozdziału w 1996 roku, zebrali definicje będące wtedy w obiegu i odkryli, że się nie zgadzają.⁷ Przegląd z 2023 roku wciąż definiuje agents od pierwszych zasad — „sztuczne byty, które postrzegają swoje środowisko, podejmują decyzje i wykonują akcje”⁸ — bo nie istniało nic ustalonego, co można by zacytować, a CoALA opisuje części, zamiast w ogóle rysować granicę.⁹ Trzydzieści lat odmowy uzgodnienia mówi, że to słowo wykonuje więcej niż jedną pracę.

Teraz konsekwencja, która przychodzi przed filozofią, czyli rachunek.

Każdy pomiar tutaj ma ten sam kształt. Pojedyncze wywołanie kosztowało 39 input tokens; to samo pytanie z jednym narzędziem kosztowało 420 w dwóch wywołaniach; pętla z usuniętą regułą zatrzymania kosztowała 1 688 w sześciu. Wzrost jest gorszy niż liniowy, bo tura n niesie ze sobą każdą poprzednią turę: kolumna prompt w sześcioturowym przebiegu brzmi 187, 238, 261, 302, 327, 373. Rozdział 16 wyprowadził, że suma to $\Theta(n^2)$, i dopasował krzywą na prawdziwej rozmowie. Agent zmienia każde zadanie w taką rozmowę, niezależnie od tego, czy człowiek kiedykolwiek ją widzi.

Gdyby te zmierzone liczby token trafiły do komercyjnego endpointu po stawkach, które rozdział 16 odczytał 6 września 2026 roku — $2,00 za milion input tokens i $12,00 za milion output — cztery przebiegi wyceniają się tak:

Wiersz drugi względem pierwszego to liczba do zapamiętania. Siedem i pół raza większy koszt za gorszą odpowiedź na pytanie, które model już znał. Nic nie było źle skonfigurowane: narzędzie istniało, więc model go użył — a ustalenie z rozdziału 18, że boli cena katalogu, a nie jego dokładność, ma tu najtańszą demonstrację z katalogiem jednoelementowym.

Dlatego użyteczna połowa obu dokumentów to połowa o tym, żeby tego nie budować. Anthropic mówi wprost: znajdź najprostsze możliwe rozwiązanie i dodawaj złożoność tylko wtedy, gdy jest potrzebna, co „może oznaczać, że w ogóle nie budujesz agentic systems”, ponieważ agentic systems „wymieniają latencję i koszt na lepszą wydajność zadania”, a „dla wielu aplikacji optymalizacja pojedynczych wywołań LLM z retrieval i przykładami in-context zwykle wystarcza”.⁴ Jego argument za agent jest wąski: otwarte problemy, w których nie możesz przewidzieć liczby kroków ani zahardkodować ścieżki, w środowisku, któremu ufasz, akceptując „wyższe koszty i potencjał kumulujących się błędów”.⁴ Filtr OpenAI jest lustrzanym odbiciem — złożony osąd, nieutrzymywalne zestawy reguł, nieustrukturyzowane dane — i kończy tak samo: „w przeciwnym razie rozwiązanie deterministyczne może wystarczyć”.⁵

A więc w taksonomii tego rozdziału: stała liczba kroków w stałej kolejności to pipeline, a nazwanie go agent nie przyspieszy go. Jeśli liczba kroków zależy od tego, co znajdziesz po drodze, chcesz pętli — i kupujesz tę elastyczność za N wywołań, kwadratowy transkrypt i system, który może się mylić N razy zamiast raz.

Masz teraz taksonomię, obie współczesne definicje, dwie osie, które czynią je zgodnymi, oraz krótką pętlę, która odpowiada, wywołuje i zatrzymuje się.

Ta pętla ma jeden sposób zakończenia: model przestaje prosić o narzędzia. Rozdział 23 celowo psuje ją siedem razy, a każda awaria dodaje jeden element. Zadanie niemożliwe i nigdy się nie kończy — limit tur. Noc działania i przychodzi rachunek — budżet w dolarach. Narzędzie zawodzi — błąd, na który model może zareagować. To samo wywołanie dwa razy — klucz idempotencji. Plik, którego nie powinien dotknąć — zgoda człowieka. Restart w połowie — trwałość sesji. Narzędzie, które milczy przez trzy minuty — postęp i anulowanie. Wynikiem jest harness, plik, na którym działa reszta tego kursu.

Zostaje pytanie, którego naprawdę dotyczyła sporna przekątna tego rozdziału. Pętla, która sama decyduje o następnym kroku, musi zdecydować, kiedy się zatrzymać, a właśnie zobaczyliśmy, co się dzieje, gdy nie potrafi: sześć tur, cztery razy większy rachunek i agent przesłuchujący użytkownika o pytanie, na które już odpowiedział. Zatrzymanie nie jest jednym warunkiem. Ile ich jest i który odpala pierwszy?

LLM Powered Autonomous Agents Lilian Weng (2023) to najbardziej znany rozkład language agent na planowanie, pamięć i użycie narzędzi, i właściwa kolejna lektura obok dwóch dokumentów vendorów; jego trzy komponenty to rozdziały 23, 24 i 18 tego kursu, w tej kolejności.

Każda liczba w tym rozdziale została wyprodukowana na tej maszynie i nic nie było estymowane. Korytarz, plan piętra, czterej agents, którzy po nim chodzą, oraz trzy polityki patrolu to TypeScript powyżej, uruchomiony na Node 22; liczby randomised agent to średnie z 2 000 seeded uruchomień każda, a liczby patrolu to pojedyncze seeded uruchomienia po 4 000 ticków. Trace modelu pochodzą z Qwen2.5-0.5B-Instruct w float32 na CPU z zachłannym dekodowaniem, serwowanego przez loopback przez mały lokalny endpoint Pythona, który ładuje wagi i mówi kształtem OpenAI chat-completions — znowu ten szew, z tensorami po stronie Pythona i pętlą po stronie TypeScript — więc liczby token są z tokenizer tego modelu, a latencje z tej maszyny. Jedyne liczby wzięte skądinąd to dwie ceny w tabeli kosztów, czyli stawki, które rozdział 16 odczytał ze strony cennika OpenAI 6 września 2026 roku, zastosowane tutaj do lokalnie zmierzonych liczby token jako ilustracja, a nie jako zaobserwowana faktura.