Що таке 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

Це простий рефлексний agent: він діє лише за поточним перцептом, без пам’яті про все, що було до нього. І це не іграшкова категорія — термостат саме такий, як і один виклик мовної моделі без доданої розмови.

Тепер зламаймо його так, як це робить реальність. Справжній робот-пилосос має датчик бруду й бампер, а не квадрат із написом 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

Та сама програма, два квадрати. З одного початкового стану вона завершує за три кроки; з іншого — п’ятсот разів їде в праву стіну й продовжувала б, доки не сів би акумулятор. Вона не може сприйняти різницю між двома ситуаціями, тому не може діяти в них по-різному. Рассел і Норвіг формулюють загальний результат одним рядком: нескінченні цикли часто неминучі для простих рефлексних agents у частково спостережуваних середовищах.¹

Є виправлення, яке коштує одного рядка й не потребує пам’яті; його варто виміряти, перш ніж братися за щось розумніше.

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

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

Дві тисячі запусків повністю брудного коридору трьох розмірів, один засіяний генератор на всіх:

Рандомізація повністю прибирає цикл. Вона також коштує: для восьми кімнат потрібно п’ятнадцять ходів, якщо ви знаєте, що робите, а цей agent у середньому витрачає 68,7 і одного разу витратив 306. Це весь розділ у мініатюрі. Кожна здатність, яку ми додаємо, купує коректність у випадку, з яким попередній agent не міг упоратися, і стягує за це плату у валюті, яку спершу треба назвати.

agent сприймає середовище через сенсори й діє через актуатори. Програма agent — це функція від перцептів до дій; кожен лістинг вище є такою програмою. Послідовність перцептів — усе, що було сприйнято досі, а простий рефлексний agent ігнорує все, крім останнього елемента.

Раціональність — слово, яке більшість статей розуміє неправильно, і якщо зрозуміти його правильно, решта розділу стає придатною до використання. agent не є раціональним або ірраціональним сам по собі. Рассел і Норвіг визначають раціонального agent як такого, що для кожної можливої послідовності перцептів вибирає дію, яка, як очікується, максимізує його міру ефективності, з огляду на докази цієї послідовності та будь-які вбудовані знання.¹ Міра ефективності не всередині agent: вона належить дизайнеру, і раціональність визначається лише відносно неї.

Специфікацію традиційно записують як чотири речі, PEAS: performance measure, environment, actuators, sensors.

Зверніть увагу, який рядок тут вибивається. Майже кожна команда, що будує agents у 2026 році, записує E, A і S — схеми інструментів, інтеграції, формат повідомлень, — бо без них код не запуститься. Майже ніхто не записує 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

Середовища задач додатково класифікують за сімома осями, п’ять із яких визначають більшість складності тут: повністю або частково спостережуване, детерміноване чи ні, епізодичне чи послідовне, статичне чи динамічне, відоме чи невідоме.¹ agent, який говорить із реальними інструментами через реальну мережу, перебуває у складному куті всіх п’яти — недетермінований навіть за temperature zero (Розділ 17) і, що недооцінюють найбільше, невідомий, бо у вас немає надійної моделі того, що ваші власні інструменти роблять зі світом. Саме тому циклу з Розділу 23 обробка помилок потрібна більше, ніж планування.

Справжні підлоги не одномірні, тому підвищимо світ до плану. Решітки — це стіни, зірочки — бруд, а робот стартує в центральній кімнаті:

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

Очевидне покращення — пам’ять. agent тримає карту: кожен квадрат, на якому він стояв, і кожен квадрат, де спрацював бампер. Його правило — йти в сусідній квадрат, який він ще не відвідував: праворуч, потім вниз, потім ліворуч, потім угору — і відступати, коли все навколо вже відоме. Це модельно-рефлексний agent: він підтримує внутрішній стан з історії перцептів, тож може діяти щодо того, чого зараз не бачить.

Це справжнє покращення, але все ще недостатнє:

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

П’ять тисяч ходів, половину підлоги так і не побачено. Карта правильна, правила правильні. Чого agent не може зробити — це використати карту, щоб кудись піти: його правила завжди відповідають лише на запитання «в якого з моїх чотирьох сусідів мені ступити», тож коли поруч із ним закінчуються невідвідані квадрати, він не має способу висловити думку за вісім ходів є невідвіданий квадрат, і я хотів би стояти на ньому. Він знає, де він. Він не знає, де хоче бути.

Цілеспрямований agent має, поверх своєї моделі світу, опис ситуації, яку хоче створити, і вибирає дії, шукаючи в послідовностях дій, доки не знайде таку, що там завершується. Цілі перетворюють вибір дії з пошуку в таблиці на пошук.

Ціль — «не залишилося жодного брудного квадрата». Пошук — обхід у ширину до найближчого брудного квадрата, а шлях, який він повертає, — це план.

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.

Інакше він не може. Ціль — це бінарний тест: підлога чиста або ні. Кожен план, що завершується чистою підлогою, задовольняє її однаково, тож коли успішних планів кілька, agent не має чим між ними вибирати. Щоб віддати перевагу одному успіху над іншим, потрібне число над результатами, і це число — функція корисності. agent, який її максимізує, — agent на основі корисності.

Зміна в коді — один член усередині пошуку. Пошук у ширину рахує ходи; змусьте його рахувати вартість — і ви маєте алгоритм Дейкстри та іншого 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 потребує чогось, чого сам виробити не може. Хтось має вирішити, скільки одиниця акумулятора варта відносно ходу. Корисність — це міра ефективності, записана у формі, з якою agent може обчислювати, і написати її — робота дизайнера. Коли люди кажуть, що agent «оптимізував не те», вони майже ніколи не мають на увазі баг. Вони мають на увазі, що цей рядок написали недбало.

Тепер нехай бруд повертається. Чотири кімнати знову брудняться з чотирма різними частотами, і agent їх не знає. Він відвідує одну кімнату за tick і бачить тільки її. Міра ефективності — кімнато-tick, проведені брудними, протягом 4 000 tick; менше — краще.

Навчальний agent, у підручниковому розкладі, — це будь-який із наведених вище плюс три частини: навчальний елемент, який змінює agent, критик, який каже, як agent справляється щодо фіксованого стандарту ефективності, і генератор проблем, який пропонує дії, варті спроби через те, чого вони навчать.¹ Три політики в тому самому середовищі. Перша не навчається; друга й третя навчаються того самого і використовують це по-різному.

Приховані частоти були 0,35 для кухні, 0,05 для холу, 0,02 для кабінету і 0,01 для горища — і учень A їх знайшов. Він правильно визначив кухню як найбруднішу кімнату в домі, а потім ходив на кухню кожен tick до кінця симуляції, тоді як інші три кімнати назавжди лишалися брудними. Це вп’ятеро гірше, ніж узагалі не навчатися, і він не зламаний.

Урок той самий, що в розділі про корисність. Учень A максимізував «ймовірність, що кімната, яку я збираюся відвідати, брудна». Міра ефективності була «кімнато-tick, проведені брудними». Різні числа; друге — те, за чим оцінював критик, і ніхто не сказав про це agent. Учень B множить ту саму вивчену частоту на час від останнього відвідування — бруд, який очікує знайти, а не шанс знайти хоч якийсь, — і перемагає патруль, з якого стартував.

Одна деталь реалізації визначила результат. У першій версії учня B кімната, де за три відвідування не з’явилося бруду, отримувала частоту рівно нуль — а нуль, помножений на будь-що, це нуль, тож її більше ніколи не відвідували, і оцінку неможливо було виправити. Згладжування дробу — успіхи плюс один поверх спроб плюс два — перетворило 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

Кожен із п’яти сьогодні працює в продакшені під іншою назвою.

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

Чат — це модельно-рефлексний agent, модель якого не внутрішня. У підручнику стан — змінна всередині програми agent. У чаті це транскрипт: він живе на вашому боці, щоразу повністю повторно надсилається і щоразу перебудовується всередині моделі з нуля. Це квадратичний рахунок із Розділу 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."

Та сама модель, ті самі три слова користувацького вводу, і другий варіант — це коридорний робот, що їде в стіну. Інструментів у тому запуску не було, тому 15 вигадано — але саме стан робить follow-up взагалі осмисленим. Ви щоразу перебудовуєте його й платите за це у 2,3× input token на двоходову розмову. Розділ 16 виміряв, яким стає цей множник до сорокового ходу.

Reflexion — це навчальний agent, який змінює свій input, а не програму. У підручниковому розкладі навчальний елемент модифікує елемент ефективності. Reflexion залишає ваги незмінними й записує рефлексивний текст в епізодичний буфер, який читає наступна спроба.³ Навчальний елемент — prompt, пам’ять — рядок бази даних, елемент ефективності — заморожена модель, а діаграма — підручникова, без змін.

І ось чесна межа цієї відповідності. П’ять типів класифікують програму agent. У 2026 році ця програма розколота посередині: частина у вашому коді, частина всередині ваг, яких ви не тренували. Коли модель сама вирішує викликати інструмент, тест цілі у вашій програмі чи в моделі? Таксономія не має відповіді, бо коли її писали, йому більше ніде було бути — і саме в цьому питанні дві сучасні дефініції розходяться.

Визначення — це суперечки про поведінку, і їх значно легше оцінювати, коли перед очима є trace.

Цикл нижче надсилає розмову до моделі; якщо відповідь містить виклик інструмента, він виконує інструмент, додає результат і надсилає все знову. Він працює проти локальної Qwen2.5-0.5B-Instruct за endpoint у формі OpenAI на цій машині — той самий шов із Розділу 14, тож циклу байдуже, що стоїть за портом.

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

Два рядки несуть усю ідею, і обидва позначені; решта — облік. Усі три поведінки видно в одному запуску. Коли питають те, що модель може зробити сама, вона відповідає. Коли питають те, чого не може, вона викликає:

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

І вона зупиняється — третя поведінка, яку найлегше пропустити, бо вона виглядає як ніщо. Цикл завершується, бо хід 2 повернувся без виклику інструмента. Ніхто цього не вирішував; це зробила модель, видавши прозу. Умова завершення цієї програми — ознака відсутності.

Ще два запуски варті місця. Коли її просять порівняти два міста, модель видає обидва виклики інструмента за один хід, отримує обидва показники назад і помиляється в порівнянні:

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

Інструменти спрацювали. Паралельний виклик спрацював. Цикл спрацював. Відповідь хибна, хоча обидва правильні числа лежать у транскрипті. Обгорнути модель у цикл не означає змусити її міркувати; це дає моделі, яка помиляється, здатність діяти на основі своєї помилки — це заздалегідь Розділ 30 і половина Розділу 29.

Тепер видаліть позначений return і нехай цикл біжить до свого ліміту. Те саме запитання, та сама модель:

  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 token, у чотири рази більше wall clock, і фінал, у якому agent забув, про що його спитали, та допитує користувача щодо питання, на яке той відповів на першому ході. Правильна відповідь була на екрані на ході 2, а кожен наступний хід погіршував транскрипт.

Отже, agent — це не цикл. Це цикл плюс правило виходу з нього, і тут є рівно одне таке правило. Розділ 23 ламає його п’ять разів і показує, що ламається, коли кожного правила бракує.

Обидва процитовані, а не переказані, бо плутанина виробляється саме в переказах.

Перше визначення ставить межу там, хто керує потоком. Anthropic у Building effective agents називає неоднозначність і ухвалює рішення:

«At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents: Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.»⁴

Тест — це запитання до вашого вихідного коду: хто вибрав наступний крок? switch у вашій програмі: workflow. Модель: agent. Той самий документ каже, що agents «зазвичай є просто LLM, які використовують інструменти на основі зворотного зв’язку з середовища в циклі» — саме таким є лістинг вище.

Друге визначення ставить межу там, наскільки система незалежна від користувача. OpenAI у A practical guide to building agents відкриває сторінку з визначенням так:

«While conventional software enables users to streamline and automate workflows, agents are able to perform the same workflows on the users' behalf with a high degree of independence. Agents are systems that independently accomplish tasks on your behalf.»⁵

Через два речення, на тій самій сторінці, воно виключає:

«Applications that integrate LLMs but don't use them to control workflow execution—think simple chatbots, single-turn LLMs, or sentiment classifiers—are not agents.»⁵

Прочитайте ці цитати по порядку. Початкові речення проводять межу за незалежністю: чи ця штука йде й завершує роботу без мене? Четверте проводить її за контролем виконання, що є рівно лінією Anthropic. Різні тести, та сама сторінка, і є реальні системи, щодо яких вони не погоджуються.

Під цим лежить зіткнення словника, і воно спричиняє суперечки на справжніх зустрічах. У першому документі workflow — це архітектура, і саме вона не є agent. У другому workflow — це «послідовність кроків, які потрібно виконати, щоб досягти цілі користувача» — сама робота, яка є в кожного agent. «Ми замінили workflow на agent» узгоджується з першим визначенням і майже нічого не означає за другим.

Три системи, що існують у 2026 році, за обома визначеннями.

Дві з трьох систем змінюють бік. Це не провал жодного документа. Це попередження про тип зустрічі, на якій двоє людей, що повністю погоджуються щодо того, що система робить, годину сперечаються про те, як її назвати.

Визначення конфліктують, бо кожне стискає два незалежні запитання в одне слово. Розділіть їх, і незгода стає таблицею, кориснішою за вердикт.

Кожне визначення оскаржує іншу клітинку, а дві інші взагалі не є спірними. Тому коли ярлик має значення — у контракті, ризик-рев’ю, postmortem — варто писати не «чи це agent», а хто вибрав наступний крок і хто спостерігав. На обидва можна відповісти, читаючи код; жодне не потребує чиїхось визначень; разом вони несуть усі наслідки, які мав заміняти ярлик.

Усе це не нове. Вулдрідж і Дженнінгс оглядали конкурентні значення «agent» у 1995 році;⁶ Франклін і Ґрессер поставили запитання цього розділу в 1996-му, зібрали тодішні визначення й виявили, що вони не погоджуються.⁷ Огляд 2023 року досі визначає agents з перших принципів — «штучні сутності, які відчувають своє середовище, ухвалюють рішення й діють»⁸ — бо не було усталеного визначення, яке можна процитувати, а CoALA описує частини, а не проводить межу взагалі.⁹ Тридцять років відмови домовитися означають, що це слово виконує більше ніж одну роботу.

Тепер наслідок, який приходить раніше за філософію, — рахунок.

Кожне вимірювання тут має ту саму форму. Один виклик коштував 39 input token; те саме запитання з одним інструментом коштувало 420 за два виклики; цикл із прибраним правилом зупинки коштував 1 688 за шість. Зростання гірше за лінійне, бо хід n несе з собою кожен попередній хід: стовпець prompt у тому шестиходовому запуску читається як 187, 238, 261, 302, 327, 373. Розділ 16 вивів, що загальна сума дорівнює $\Theta(n^2)$, і підігнав криву на реальній розмові. agent перетворює кожну задачу на таку розмову, незалежно від того, бачить її колись людина чи ні.

Якби ці виміряні кількості token пішли до комерційного endpoint за тарифами, які Розділ 16 прочитав 6 вересня 2026 року — $2,00 за мільйон input token і $12,00 за мільйон output, — чотири запуски коштували б так:

Другий рядок проти першого — число, яке треба запам’ятати. У сім із половиною разів більша вартість за гіршу відповідь на запитання, яке модель уже знала. Нічого не було налаштовано неправильно: інструмент існував, тож модель ним скористалася — і висновок Розділу 18, що болить ціна каталогу, а не його точність, має тут найдешевшу демонстрацію з каталогом з одного елемента.

Саме тому корисна половина обох документів — та, що про те, як цього не будувати. Anthropic говорить прямо: знайдіть найпростіше можливе рішення й додавайте складність лише за потреби, що «може означати взагалі не будувати agentic systems», бо agentic systems «міняють затримку й вартість на кращу ефективність задачі», а «для багатьох застосунків зазвичай достатньо оптимізувати одиничні виклики LLM із retrieval та in-context examples».⁴ Їхній аргумент за agent вузький: відкриті проблеми, де ви не можете передбачити кількість кроків і не можете жорстко закодувати шлях, у середовищі, якому довіряєте, приймаючи «вищі витрати й потенціал накопичуваних помилок».⁴ Фільтр OpenAI — дзеркальний: складне судження, непідтримувані набори правил, неструктуровані дані — і завершується так само: «інакше детермінованого рішення може бути достатньо».⁵

Отже, у таксономії цього розділу: фіксована кількість кроків у фіксованому порядку — це pipeline, і назва agent не зробить його швидшим. Якщо кількість кроків залежить від того, що ви знайдете дорогою, вам потрібен цикл — і ви купуєте цю гнучкість за N викликів, квадратичний транскрипт і систему, яка може помилитися N разів замість одного.

Тепер у вас є таксономія, обидва сучасні визначення, дві осі, які роблять їх сумісними, і короткий цикл, що відповідає, викликає й зупиняється.

У цього циклу є один спосіб завершитися: модель перестає просити інструменти. Розділ 23 навмисно ламає його сім разів, і кожна поломка додає деталь. Неможлива задача, і він не завершується — ліміт ходів. Ніч роботи, і приходить рахунок — бюджет у доларах. Інструмент, що падає, — помилка, на яку модель може відреагувати. Той самий виклик двічі — idempotency key. Файл, якого він не мав торкатися, — human approval. Перезапуск посередині — persistence сесії. Інструмент, що мовчки триває три хвилини, — прогрес і скасування. На виході — harness, файл, на якому працює решта цього курсу.

Залишається запитання, про яке насправді була спірна діагональ цього розділу. Цикл, який сам вирішує свій наступний крок, має вирішити, коли зупинитися, і ми щойно побачили, що стається, коли він не може: шість ходів, учетверо більший рахунок і agent, який допитує користувача про запитання, на яке вже відповів. Зупинка — це не одна умова. Скільки їх і яка спрацьовує першою?

Lilian Weng, LLM Powered Autonomous Agents (2023), — найвідоміший розклад language agent на планування, пам’ять і використання інструментів, і це правильне наступне читання поряд із двома документами постачальників; її три компоненти — це Розділи 23, 24 і 18 цього курсу саме в такому порядку.

Кожне число в цьому розділі було отримане на цій машині, і нічого не оцінювалося приблизно. Коридор, план підлоги, чотири agents, що ним ходять, і три патрульні політики — це наведений вище TypeScript, запущений на Node 22; числа рандомізованого agent — це середні за 2 000 засіяних запусків кожне, а патрульні числа — окремі засіяні запуски по 4 000 tick. Трасування моделі походять із Qwen2.5-0.5B-Instruct у float32 на CPU з жадібним декодуванням, поданого через loopback невеликим локальним Python endpoint, який завантажує ваги й говорить у формі OpenAI chat-completions — знову той самий шов, із tensors на боці Python і циклом на боці TypeScript, — тож кількості token належать tokenizer цієї моделі, а затримки — цій машині. Єдині числа, взяті звідкись іще, — дві ціни в таблиці вартості: тарифи, які Розділ 16 прочитав зі сторінки цін OpenAI 6 вересня 2026 року, застосовані тут до локально виміряних кількостей token як ілюстрація, а не як спостережений invoice.