Какво е AI agent: пет класически типа и две конкуриращи се дефиниции

Най-старият пример в областта е прахосмукачка в свят от две квадратчета, A и B, всяко или чисто, или мръсно.¹ Той оцелява във всеки учебник, защото е най-малкият свят, в който един agent може да бъде прав или да греши.

Възприятието е двойка — къде съм и дали тук е мръсно — а действията са SUCK, LEFT и RIGHT. Цялата програма е един ред.

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";   

Пуснете я срещу всяка начална конфигурация на света с две квадратчета:

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

Това е simple reflex agent: действа само по текущото възприятие, без memory за каквото и да било преди него. Не е играчка категория — термостатът е такъв, както и единичен call към language model без прикачен разговор.

Сега го счупете така, както го прави реалността. Истинският робот-прахосмукачка има сензор за прах и броня, а не квадратче с етикет A под килима. Извадете местоположението от възприятието и не променяйте нищо друго:

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

Същата програма, две квадратчета. От едно начално състояние приключва за три стъпки; от друго се блъска в дясната стена петстотин пъти и би продължила, докато батерията умре. Тя не може да възприеме разликата между двете ситуации, така че не може да действа различно в тях. Russell и Norvig формулират общия резултат в един ред: безкрайните loops често са неизбежни за simple reflex agents в частично наблюдаеми среди.¹

Има поправка, която струва един ред и никаква memory, и си заслужава да я измерим, преди да посегнем към нещо по-умно.

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

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

Две хиляди изпълнения на изцяло мръсен коридор с три размера, с един seeded генератор през цялото време:

Randomisation премахва loop изцяло. Но и струва: осем стаи изискват петнадесет хода, ако знаете какво правите, а този agent прави средно 68,7 и веднъж стигна до 306. Това е цялата глава в миниатюра. Всяка capability, която добавяме, купува коректност в случай, с който предишният agent не можеше да се справи, и таксува за нея във валута, която първо трябва да назовете.

Един agent възприема средата си чрез сензори и действа чрез задвижващи механизми. Agent program е функцията от възприятия към действия — всеки списък по-горе е такава. Поредицата от възприятия е всичко възприето досега, а simple reflex agent игнорира всичко освен последния елемент.

Рационалност е думата, която повечето статии разбират погрешно, а ако я разберем правилно, останалата част от тази глава става използваема. Един agent не е рационален или ирационален сам по себе си. Russell и Norvig дефинират рационален agent като такъв, който за всяка възможна поредица от възприятия избира действието, което се очаква да максимизира неговата мярка за представяне, предвид доказателствата от тази поредица и каквото вградено знание има.¹ Мярката за представяне не е вътре в agent: тя принадлежи на дизайнера, а рационалността се дефинира само спрямо нея.

Спецификацията обичайно се записва като четири неща, PEAS: performance measure, environment, actuators, sensors.

Забележете кой ред е различният. Почти всеки екип, който изгражда agents през 2026 г., записва E, A и S — schemas на tools, integrations, формата на съобщенията — защото кодът няма да тръгне без тях. Почти никой не записва P. Без него „нашият agent се справя добре“ няма проверимо значение, а „рационален“ изобщо не може да се приложи към системата, а само към демонстрация. Глава 29 е за превръщането на P в число и затова съществува.

    ┌───────────────────────── 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

Task environments се класифицират допълнително по седем оси, пет от които решават по-голямата част от трудността тук: напълно или частично наблюдаема, deterministic или не, episodic или sequential, static или dynamic, known или unknown.¹ Agent, който говори с истински tools през истинска мрежа, е в трудния ъгъл и на петте — non-deterministic дори при temperature нула (Глава 17), и, подценяваното, unknown, защото нямате надежден model на това, което вашите собствени tools правят на света. Затова loop от Глава 23 има нужда от error handling повече, отколкото от planning.

Истинските подове не са едномерни, така че повишете света до план. Решетките са стени, звездичките са мръсотия, а роботът започва в средната камера:

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

Очевидният upgrade е memory. Agent пази карта: всяко квадратче, на което е стъпвал, и всяко квадратче, където бронята се е задействала. Правилото му е да влезе в съседно квадратче, което не е посещавал — надясно, после надолу, после наляво, после нагоре — и да се върне, когато всичко около него е известно. Това е model-based reflex agent: поддържа вътрешно състояние от историята на възприятията, така че може да действа спрямо онова, което не вижда в момента.

Това е реално подобрение и все още не е достатъчно:

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

Пет хиляди хода, половината под никога не е видян. Картата е вярна и правилата са верни. Това, което agent не може да направи, е да използва картата, за да отиде някъде: правилата му винаги отговарят само на „в кой от четирите ми съседи да стъпя“, така че щом изчерпи непосетените квадратчета до себе си, няма начин да изрази мисълта има непосетено квадратче на осем хода разстояние и искам да стоя върху него. Той знае къде е. Не знае къде иска да бъде.

Goal-based agent държи, върху своя model на света, описание на ситуацията, която иска да предизвика, и избира действия, като търси върху поредици от тях, докато намери такава, която завършва там. Целите превръщат избора на действие от справка в търсене.

Целта е „да не остане мръсно квадратче“. Търсенето е breadth-first ходене до най-близкото мръсно квадратче, а пътят, който връща, е планът.

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

Двадесет и седем хода, подът е чист. Но погледнете колоната за батерията и последния етап от плана. Колона 0 е покрита с килим: пресичането на квадратче с килим струва шест единици батерия, плочка — една. Agent се прибра по колона 0, защото това са четири хода вместо осем, а тези четири хода по килим струваха 24, докато обходът от осем хода би струвал 13.

Той не може да направи друго. Целта е binary тест: подът е чист или не е. Всеки план, който завършва с чист под, я удовлетворява еднакво, така че когато няколко успяват, agent няма по какво да избере между тях. Предпочитането на един успех пред друг изисква число върху резултатите, а това число е utility function. Agent, който я максимизира, е utility-based agent.

Промяната в кода е един член вътре в търсенето. Breadth-first search брои ходове; накарайте го да брои cost вместо това и имате алгоритъма на Dijkstra и различен 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

Четири допълнителни хода, единадесет по-малко единици батерия: двадесет и един процента по-евтино. Същата цел, същата карта, същият код освен един член. Двата agents се различават само по това в какво се опитват да бъдат добри и поемат по различни маршрути към дома.

Това е и първата точка, в която agent има нужда от нещо, което не може да произведе. Някой трябва да реши колко струва единица батерия спрямо един ход. Utility е мярката за представяне, написана във форма, с която agent може да смята, а написването ѝ е работа на дизайнера. Когато хората казват, че agent „оптимизирал грешното нещо“, почти никога не имат предвид bug. Имат предвид, че този ред е написан небрежно.

Сега нека мръсотията се връща. Четири стаи отново се замърсяват с четири различни скорости, а agent никога не ги научава директно. Той посещава по една стая на tick и вижда само тази стая. Мярката за представяне е room-ticks, прекарани мръсни, за 4.000 ticks — по-ниско е по-добре.

Learning agent, в учебникарската декомпозиция, е всеки от горните плюс три части: learning element, който променя agent, critic, който му казва как се справя agent спрямо фиксиран стандарт за представяне, и problem generator, който предлага действия, които си струва да се пробват заради това, което биха научили.¹ Три policies в една и съща среда. Първата не учи; втората и третата учат едно и също нещо и го използват различно.

Скритите скорости бяха 0,35 за кухнята, 0,05 за коридора, 0,02 за кабинета и 0,01 за тавана — и learner A ги откри. Той правилно идентифицира кухнята като най-мръсната стая в къщата, после ходеше в кухнята на всеки tick до края на симулацията, докато другите три стояха мръсни завинаги. Пет пъти по-лош е от това изобщо да не учи, и не е счупен.

Урокът е този от секцията за utility. Learner A максимизира „вероятността стаята, която ще посетя, да е мръсна“. Мярката за представяне беше „room-ticks, прекарани мръсни“. Различни числа; второто е това, което critic оценяваше, а никой не го каза на agent. Learner B умножава същата научена скорост по времето от последното посещение — мръсотията, която очаква да намери, а не шанса да намери каквато и да е — и побеждава патрула, от който започна.

Един implementation detail реши резултата. В първата версия на learner B стая, в която не се беше появила мръсотия за три посещения, получаваше rate точно нула — а нула по каквото и да било е нула, така че тя никога повече не беше посещавана и оценката никога не можеше да бъде коригирана. Smoothing на дробта, успехи плюс едно върху опити плюс две, превърна 11.895 в 1.576. „Все още не е наблюдавано“ и „измерено е и излезе нула“ са различни твърдения, а система, която ги съхранява в едно и също поле, взема решения, които не може да отмени.

  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

Всеки от петте е в production днес под друго име.

Два реда са по-близо от аналогия — по начин, който струва пари.

Chat е model-based reflex agent, чийто model не е вътрешен. В учебника състоянието е променлива вътре в agent program. В chat то е transcript: живее при вас, изпраща се наново целият при всеки call и се изгражда от нулата вътре в model всеки път. Това е квадратната сметка от Глава 16 и е същият обект, който учебникът рисува като кутия с етикет „state“. Ето разликата, измерена върху един follow-up въпрос със и без двете съобщения преди него:

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."

Същият model, същите три думи user input, а вторият е роботът в коридора, който се блъска в стената. В това изпълнение нямаше tools, така че 15 е измислено — но състоянието е това, което кара follow-up да означава нещо. Възстановявате го всеки път и плащате 2,3× input tokens за него при разговор от два turns. Глава 16 измери докъде стига този множител при turn четиридесет.

Reflexion е learning agent, който променя input си, а не програмата си. В учебникарската декомпозиция learning element модифицира performance element. Reflexion оставя weights на мира и записва reflective text в episodic buffer, който следващият опит чете.³ Learning element е prompt, memory е ред в база данни, performance element е замразен model — а диаграмата е учебникарската, непроменена.

И ето честното ограничение на съпоставянето. Петте типа класифицират agent program. През 2026 г. тази програма е разделена през средата: част от нея е вашият код, част от нея е вътре в weights, които не сте обучили. Когато model реши сам да извика tool, goal test във вашата програма ли е, или в model? Таксономията няма отговор, защото когато е писана, нямаше къде другаде да бъде — а този въпрос е точно мястото, където двете модерни дефиниции се разделят.

Дефинициите са спорове за поведение и се преценяват много по-лесно с trace пред очите.

Loop по-долу изпраща разговора към model; ако reply съдържа tool call, изпълнява tool, добавя резултата и изпраща всичко отново. Работи срещу локален Qwen2.5-0.5B-Instruct зад endpoint с форма на OpenAI на тази машина — шевът от Глава 14, така че loop нито знае, нито го интересува какво има зад порта.

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");                       
}

Два реда носят цялата идея и и двата са маркирани; останалото е bookkeeping. И трите поведения се виждат в едно изпълнение. Попитан за нещо, което може да направи сам, model отговаря. Попитан за нещо, което не може, той извиква:

=== 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

И спира — третото поведение и най-лесното за пропускане, защото изглежда като нищо да не се случва. Loop приключва, защото turn 2 се върна без tool call. Никой не реши това; model го реши, като излъчи проза. Termination condition на тази програма е знакът на едно отсъствие.

Още две изпълнения си заслужават мястото. Попитан да сравни два града, model издава и двата tool calls в един turn, получава и двете измервания обратно и греши в сравнението:

  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."

Tools работеха. Parallel call работеше. Loop работеше. Отговорът е false, с двете верни числа, седящи в transcript. Опаковането на model в loop не го кара да разсъждава; то дава на model, който греши, способността да действа върху грешката си — което е Глава 30 предварително и половината от Глава 29.

Сега изтрийте маркирания return и оставете loop да тече до cap. Същият въпрос, същият 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

Четири пъти input tokens, четири пъти wall clock и край, в който agent е забравил какво са го питали и разпитва потребителя за въпрос, на който той е отговорил още на turn едно. Правилният отговор беше на екрана при turn 2 и всеки turn след него влошаваше transcript.

Значи agent не е loop. Той е loop плюс правило за напускането му, а този има точно едно такова правило. Глава 23 намира пет и показва какво се чупи, когато всяко липсва.

И двете са цитирани, а не преразказани, защото объркването се произвежда в преразказите.

Първата дефиниция поставя границата при това кой контролира потока. Building effective agents на Anthropic назовава неяснотата и се произнася по нея:

„В Anthropic категоризираме всички тези вариации като agentic systems, но правим важно архитектурно разграничение между workflows и agents: Workflows са системи, в които LLMs и tools се оркестрират чрез предварително дефинирани code paths. Agents, от друга страна, са системи, в които LLMs динамично насочват собствените си процеси и използването на tools, запазвайки контрол върху това как изпълняват tasks.“⁴

Тестът е въпрос за вашия source code: кой избра следващата стъпка? switch във вашата програма: workflow. Model: agent. Същият документ казва, че agents „обикновено са просто LLMs, които използват tools въз основа на обратна връзка от средата в loop“ — което е точно списъкът по-горе.

Втората дефиниция поставя границата при независимостта от потребителя. A practical guide to building agents на OpenAI започва дефиниционната си страница така:

„Докато конвенционалният софтуер позволява на потребителите да оптимизират и автоматизират workflows, agents могат да изпълняват същите workflows от името на потребителите с висока степен на независимост. Agents са системи, които независимо изпълняват tasks от ваше име.“⁵

Две изречения по-късно, на същата страница, изключва:

„Приложения, които интегрират LLMs, но не ги използват за контрол на изпълнението на workflow — помислете за simple chatbots, single-turn LLMs или sentiment classifiers — не са agents.“⁵

Прочетете тези цитати поред. Началните изречения чертаят линията при независимост: отива ли това нещо да свърши задачата без мен? Четвъртото я чертае при контрол върху изпълнението, което е точно линията на Anthropic. Различни тестове, една и съща страница, и има реални системи, за които не са съгласни.

Отдолу има сблъсък на речници и той причинява спорове в истински срещи. В първия документ workflow е архитектура и е нещото, което не е agent. Във втория workflow е „поредица от стъпки, които трябва да бъдат изпълнени, за да се постигне целта на потребителя“ — самата работа, от която всеки agent има една. „Заменихме workflow с agent“ е смислено под първата дефиниция и почти безсмислено под втората.

Три системи, които съществуват през 2026 г., под двете дефиниции.

Две от трите сменят страните. Това не е провал на нито един документ. Това е предупреждение за вид среща, в която двама души, напълно съгласни какво прави една система, прекарват час в несъгласие как да я нарекат.

Дефинициите се сблъскват, защото всяка свива два независими въпроса в една дума. Разделете ги и несъгласието става таблица, която е по-полезна от присъда.

Всяка дефиниция оспорва различна клетка, а другите две изобщо не са спорни. Така че когато етикетът има значение — в договор, risk review, postmortem — двете изречения, които си струва да се напишат, не са „това agent ли е“, а кой избра следващата стъпка и кой наблюдаваше. И на двете може да се отговори чрез четене на код, нито едното не се нуждае от нечия дефиниция, и заедно носят всяко последствие, за което етикетът беше заместител.

Нищо от това не е ново. Wooldridge и Jennings разглеждат конкуриращите се значения на „agent“ през 1995 г.;⁶ Franklin и Graesser задават въпроса на тази глава през 1996 г., събират тогавашните дефиниции и откриват, че не са съгласни.⁷ Проучване от 2023 г. все още дефинира agents от първи принципи — „изкуствени същности, които усещат средата си, вземат решения и предприемат действия“⁸ — защото не е имало нищо установено за цитиране, а CoALA описва части, вместо изобщо да чертае граница.⁹ Тридесет години отказ да се постигне съгласие казват, че думата върши повече от една работа.

Сега последствието, което пристига преди философията: сметката.

Всяко измерване тук има същата форма. Единичният call струваше 39 input tokens; същият въпрос с един tool струваше 420 през два calls; loop с премахнато stopping rule струваше 1.688 през шест. Растежът е по-лош от линеен, защото turn n носи всеки предишен turn със себе си: prompt колоната на това шест-turn изпълнение гласи 187, 238, 261, 302, 327, 373. Глава 16 изведе, че общото е $\Theta(n^2)$, и напасна кривата върху реален разговор. Agent превръща всяка task в такъв разговор, независимо дали човек някога го вижда.

Ако тези измерени token counts бяха отишли към commercial endpoint по тарифите, които Глава 16 прочете на 6 септември 2026 г. — $2,00 за милион input tokens и $12,00 за милион output — четирите изпълнения се оценяват така:

Ред две срещу ред едно е числото, което трябва да запомните. Седем и половина пъти цената за по-лош отговор на въпрос, който model вече знаеше. Нищо не беше misconfigured: съществуваше tool, така че model го използва — и изводът от Глава 18, че цената на каталога, а не неговата точност, е това, което боли, получава най-евтината си демонстрация тук с каталог от един.

Затова полезната половина и на двата документа е половината за това да не строите това. Anthropic е директен: намерете възможно най-простото решение и добавяйте complexity само когато е нужно, което „може да означава изобщо да не изграждате agentic systems“, тъй като agentic systems „разменят latency и cost за по-добро task performance“ и „за много приложения оптимизирането на single LLM calls с retrieval и in-context examples обикновено е достатъчно“.⁴ Аргументът му за agent е тесен: open-ended problems, при които не можете да предвидите броя стъпки и не можете да hardcode-нете път, в среда, на която имате доверие, приемайки „по-високи разходи и потенциал за натрупващи се грешки“.⁴ Филтърът на OpenAI е огледален образ — complex judgement, unmaintainable rule sets, unstructured data — и завършва по същия начин: „иначе deterministic solution може да е достатъчно“.⁵

Така че в таксономията на тази глава: фиксиран брой стъпки във фиксиран ред е pipeline, и това да го наречете agent няма да го направи по-бърз. Ако броят стъпки зависи от това, което намерите по пътя, искате loop — и купувате тази гъвкавост с N calls, quadratic transcript и система, която може да греши N пъти вместо веднъж.

Сега имате таксономията, и двете модерни дефиниции, двете оси, които ги правят съвместими, и кратък loop, който отговаря, извиква и спира.

Този loop има един начин да приключи: model спира да иска tools. Глава 23 го чупи нарочно, седем пъти, и всяка повреда добавя част. Невъзможна task и той никога не свършва — turn cap. Нощ на работа и сметката пристига — budget в долари. Tool, който се проваля — error, върху която model може да действа. Същият call два пъти — idempotency key. Файл, който не е трябвало да докосва — human approval. Restart по средата — session persistence. Tool, който отнема три минути в тишина — progress и cancellation. Това, което излиза, е harness, файлът, върху който работи останалата част от този курс.

Остава въпросът, за който спорният диагонал на тази глава всъщност беше. Loop, който решава собствената си следваща стъпка, трябва да реши кога да спре, а току-що видяхме какво става, когато не може: шест turns, четири пъти сметката и agent, който разпитва потребителя за въпрос, на който вече е отговорил. Спирането не е едно condition. Колко са и кое се задейства първо?

LLM Powered Autonomous Agents (2023) на Lilian Weng е най-известната декомпозиция на language agent на planning, memory и tool use и е правилното следващо четиво редом с двата vendor documents; трите му компонента са Глави 23, 24 и 18 от този курс, в този ред.

Всяко число в тази глава беше произведено на тази машина и нищо не беше estimated. Коридорът, floor plan, четирите agents, които го обхождат, и трите patrol policies са TypeScript по-горе, пуснат на Node 22; figures на randomised agent са means върху по 2.000 seeded runs, а patrol figures са single seeded runs от 4.000 ticks. Model traces идват от Qwen2.5-0.5B-Instruct във float32 на CPU с greedy decoding, served over loopback от малък локален Python endpoint, който зарежда weights и говори във формата OpenAI chat-completions — отново шевът, с tensors от Python страната и loop от TypeScript страната — така че token counts са tokenizer на този model, а latencies са на тази машина. Единствените figures, взети от другаде, са двете цени в cost table, които са тарифите, прочетени от Глава 16 от pricing page на OpenAI на 6 септември 2026 г., приложени тук към локално измерени token counts като илюстрация, а не като наблюдавана фактура.