Что такое AI agent: пять классических типов и два спорящих определения

Самый старый пример в этой области — пылесос в мире из двух клеток, A и B, каждая из которых либо чистая, либо грязная.¹ Он пережил все учебники, потому что это самый маленький мир, в котором agent может быть прав или ошибаться.

Percept — это пара: где я нахожусь и грязно ли здесь. Actions — 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: он действует только по текущему percept, без памяти о том, что было раньше. Это не игрушечная категория: термостат — такой же, как и один вызов языковой модели без attached conversation.

Теперь сломаем его так, как ломает реальность. У настоящего робота-пылесоса есть датчик грязи и bumper, а не клетка с буквой A под ковром. Уберите location из percept и больше ничего не меняйте:

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

Та же программа, две клетки. Из одного начального состояния она заканчивает за три шага; из другого — пятьсот раз въезжает в правую стену и продолжала бы, пока не села батарея. Она не может perceives разницу между двумя ситуациями, поэтому не может действовать в них по-разному. Russell и Norvig формулируют общий результат одной строкой: бесконечные loops часто неизбежны для simple reflex agents в partially observable environments.¹

Есть исправление ценой в одну строку и без памяти; его стоит измерить, прежде чем тянуться к чему-то умнее.

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 generator для всех:

Рандомизация полностью убирает loop. Но она тоже стоит: для восьми комнат нужно пятнадцать ходов, если вы знаете, что делаете, а этот agent в среднем делает 68,7 и однажды сделал 306. Это вся глава в миниатюре. Каждая добавленная способность покупает корректность в случае, с которым предыдущий agent не справлялся, и выставляет счёт в валюте, которую сначала нужно назвать.

Agent perceives свою environment через sensors и действует через actuators. Agent program — это функция от percepts к actions; каждый листинг выше является такой функцией. Percept sequence — всё, что было perceived до сих пор, а simple reflex agent игнорирует всё, кроме последнего элемента.

Rationality — слово, в котором ошибается большинство статей, и если понять его правильно, остальная глава становится применимой. Agent не бывает рациональным или иррациональным сам по себе. Russell и Norvig определяют rational agent как такого, который для каждой possible percept sequence выбирает action, от которого ожидается максимизация его performance measure, с учётом evidence этой sequence и любых встроенных знаний.¹ Performance measure находится не внутри agent: он принадлежит designer, а rationality определяется только относительно него.

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

Заметьте, какая строка выбивается. Почти каждая команда, строящая agents в 2026 году, записывает E, A и S — схемы tools, integrations, формат сообщений, — потому что без них код не запустится. Почти никто не записывает P. Без него фраза «наш agent хорошо справляется» не имеет проверяемого смысла, а «rational» нельзя применить к системе вообще — только к демонстрации. Глава 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 дальше классифицируют по семи осям, пять из которых определяют большую часть сложности здесь: fully или partially observable, deterministic или нет, episodic или sequential, static или dynamic, known или unknown.¹ Agent, разговаривающий с реальными tools по реальной сети, находится в сложном углу всех пяти — non-deterministic даже при temperature zero (глава 17) и, что недооценивают, unknown, потому что у вас нет надёжной модели того, что ваши собственные tools делают с миром. Поэтому loop из главы 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 хранит карту: каждую клетку, на которой он стоял, и каждую клетку, где сработал bumper. Его правило — идти в соседнюю клетку, где он ещё не был: вправо, затем вниз, затем влево, затем вверх, — и отступать, когда всё вокруг известно. Это model-based reflex agent: он поддерживает internal state из percept history, поэтому может действовать на основе того, чего прямо сейчас не видит.

Это настоящее улучшение — и всё ещё недостаточное:

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

Пять тысяч ходов, половина пола так и не увидена. Карта верна, правила верны. Чего agent не умеет — использовать карту, чтобы куда-то попасть: его правила всегда отвечают только на вопрос «в кого из четырёх соседей мне шагнуть», поэтому, когда рядом не остаётся непосещённых клеток, у него нет способа выразить мысль в восьми ходах отсюда есть непосещённая клетка, и я хочу оказаться на ней. Он знает, где находится. Он не знает, где хочет оказаться.

Goal-based agent поверх своей модели мира хранит описание ситуации, которую хочет получить, и выбирает actions, перебирая их sequences, пока не найдёт ту, которая там заканчивается. Goals превращают выбор action из lookup в search.

Goal — «не осталось ни одной грязной клетки». Search — breadth-first walk к ближайшей грязной клетке, а возвращённый путь — plan.

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

Двадцать семь ходов, пол чист. Но посмотрите на столбец батареи и последний отрезок plan. Столбец 0 покрыт ковром: пересечение клетки с ковром стоит шесть единиц батареи, плиточной — одну. Agent вернулся домой по столбцу 0, потому что это четыре хода вместо восьми, и эти четыре хода по ковру стоили 24, тогда как обход из восьми ходов стоил бы 13.

Иначе он не может. Goal — это binary test: пол чист или нет. Каждый plan, который заканчивается чистым полом, удовлетворяет ему одинаково, поэтому, когда успешных вариантов несколько, agent не из чего выбирать. Чтобы предпочесть один успех другому, нужно число над outcomes, и это число — utility function. Agent, который её максимизирует, — utility-based agent.

Изменение в коде — один term внутри search. Breadth-first search считает ходы; заставьте его считать cost, и у вас будет Dijkstra's algorithm и другой 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

Четыре дополнительных хода, на одиннадцать единиц батареи меньше: на двадцать один процент дешевле. Та же goal, та же карта, тот же код, кроме одного term. Два agents отличаются только тем, в чём пытаются быть хороши, и выбирают разные маршруты домой.

Это также первая точка, где agent нуждается в чём-то, что сам произвести не может. Кто-то должен решить, сколько стоит единица батареи относительно одного хода. Utility — это performance measure, записанный в форме, с которой agent может вычислять, а записывать его — работа designer. Когда люди говорят, что agent «optimized the wrong thing», они почти никогда не имеют в виду bug. Они имеют в виду, что эта строка была написана небрежно.

Теперь пусть грязь возвращается. Четыре комнаты снова пачкаются с четырьмя разными rates, и agent о них не сообщаетcя. Он посещает одну комнату за tick и видит только её. Performance measure — room-ticks, проведённые грязными, за 4 000 ticks: меньше — лучше.

Learning agent в учебниковом разложении — это любой из перечисленных выше плюс три части: learning element, который меняет agent, critic, который сообщает, как agent справляется относительно фиксированного performance standard, и problem generator, который предлагает actions, стоящие пробы ради того, чему они научат.¹ Три policies в одной environment. Первая не учится; вторая и третья учатся одному и тому же, но используют это по-разному.

Скрытые rates были 0,35 для кухни, 0,05 для прихожей, 0,02 для кабинета и 0,01 для чердака — и learner A их нашёл. Он правильно определил кухню как самую грязную комнату в доме, затем ходил на кухню каждый tick до конца симуляции, пока остальные три навсегда оставались грязными. Он в пять раз хуже, чем вообще не учиться, и он не сломан.

Урок тот же, что в разделе про utility. Learner A максимизировал «вероятность, что комната, которую я сейчас посещу, грязная». Performance measure был «room-ticks, проведённые грязными». Разные числа; второе оценивал critic, и никто не сказал об этом agent. Learner B умножает тот же learned rate на время с последнего визита — ожидаемую грязь, которую он найдёт, а не шанс найти хоть какую-то, — и обгоняет patrol, с которого начинал.

Одна деталь реализации решила результат. В первой версии learner B комната, где за три визита не встретилось грязи, получала rate ровно ноль — а ноль, умноженный на что угодно, остаётся нулём, поэтому туда больше никогда не заходили и estimate уже нельзя было исправить. Smoothing fraction — successes plus one over trials plus two — превратил 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, чья модель не internal. В учебнике state — переменная внутри agent program. В chat это transcript: он живёт на вашей стороне, заново отправляется целиком при каждом вызове и каждый раз восстанавливается внутри модели с нуля. Это квадратичный счёт из главы 16, и это тот же объект, который учебник рисовал как коробку с надписью «state». Вот разница, измеренная на одном follow-up question с двумя предыдущими сообщениями и без них:

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

Та же модель, те же три слова user input, а второй вариант — это робот в коридоре, который въезжает в стену. В этом прогоне не было tools, так что 15 придумано, — но именно state делает follow-up осмысленным. Вы заново строите его каждый раз и платите за него 2,3× input tokens уже в двухходовом conversation. Глава 16 измеряла, до чего этот multiplier доходит к сороковому ходу.

Reflexion — это learning agent, который меняет input, а не program. В учебниковом разложении learning element изменяет performance element. Reflexion оставляет weights в покое и пишет reflective text в episodic buffer, который читает следующая попытка.³ Learning element — prompt, memory — строка базы данных, performance element — frozen model, а diagram остаётся учебниковой, без изменений.

И вот честный предел такого сопоставления. Пять типов классифицируют agent program. В 2026 году эта program разрезана посередине: часть — ваш код, часть — внутри weights, которые вы не обучали. Когда модель сама решает вызвать tool, goal test находится в вашей program или в модели? У таксономии нет ответа, потому что, когда её писали, ему негде было быть ещё, — и именно в этом вопросе расходятся два современных определения.

Определения спорят о поведении, и судить о них гораздо проще, когда перед глазами trace.

Loop ниже отправляет conversation в модель; если reply содержит tool call, он выполняет tool, добавляет result и отправляет всё снова. Он работает против локального Qwen2.5-0.5B-Instruct за OpenAI-shaped endpoint на этой машине — тот самый seam из главы 14, поэтому loop не знает и не интересуется, что находится за port.

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. Все три поведения видны в одном прогоне. Когда спрашивают то, что модель может сделать сама, она отвечает. Когда спрашивают то, чего не может, она вызывает:

=== 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. Никто этого не решал; это решила модель, выдав prose. Termination condition этой program — признак отсутствия.

Ещё два прогона стоят места. Когда её просят сравнить два города, модель выдаёт оба tool calls за один turn, получает оба readings обратно и ошибается в сравнении:

  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 сработал. Ответ ложный, при том что оба правильных числа лежат в transcript. Обернуть модель в loop не значит заставить её reasoning; это даёт ошибающейся модели способность действовать на основе своей ошибки — заранее глава 30 и половина главы 29.

Теперь удалите отмеченный return и дайте loop дойти до cap. Тот же вопрос, та же модель:

  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 находит пять и показывает, что ломается, когда каждого не хватает.

Оба цитируются, а не пересказываются, потому что путаница производится именно в пересказах.

Первое определение проводит границу по тому, кто управляет flow. Anthropic в Building effective agents называет неоднозначность и принимает по ней решение:

«В Anthropic мы относим все эти варианты к agentic systems, но проводим важное архитектурное различие между workflows и agents: workflows — это системы, где LLMs и tools orchestrated через предопределённые пути в коде. Agents, напротив, — это системы, где LLMs динамически направляют собственные процессы и использование tools, сохраняя контроль над тем, как они выполняют tasks».⁴

Тест — вопрос о вашем исходном коде: кто выбрал следующий шаг? switch в вашей program: workflow. Модель: agent. В том же документе сказано, что agents «обычно просто LLMs, использующие tools на основе feedback из environment в loop», — то есть ровно листинг выше.

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

«В то время как обычное software позволяет пользователям упрощать и автоматизировать workflows, agents способны выполнять те же workflows от имени пользователей с высокой степенью независимости. Agents — это системы, которые independently accomplish tasks on your behalf».⁵

Через два предложения на той же странице оно исключает:

«Applications, которые integrate LLMs, но не используют их для control workflow execution — например, simple chatbots, single-turn LLMs или sentiment classifiers, — не являются agents».⁵

Прочитайте эти цитаты по порядку. Первые предложения проводят линию по independence: уходит ли эта штука и заканчивает ли работу без меня? Четвёртое проводит её по control of execution, то есть ровно по линии Anthropic. Разные тесты, одна страница, и есть реальные системы, по которым они расходятся.

Под этим лежит столкновение словаря, и оно вызывает споры на реальных встречах. В первом документе workflow — это architecture, и это то, что не agent. Во втором workflow — «sequence of steps that must be executed to meet the user's goal», то есть сама работа, которая есть у каждого agent. «Мы заменили workflow на agent» осмысленно в первом определении и почти бессмысленно во втором.

Три системы, существующие в 2026 году, под обоими определениями.

Две из трёх меняют сторону. Это не провал ни одного документа. Это предупреждение о типе встречи, где два человека, полностью согласные о том, что делает система, час спорят о том, как её назвать.

Определения сталкиваются, потому что каждое сжимает два независимых вопроса в одно слово. Разделите их, и несогласие станет таблицей, что полезнее вердикта.

Каждое определение спорит с другой клеткой, а две оставшиеся вообще не спорны. Поэтому, когда label важен — в contract, risk review, postmortem, — стоит писать не «это agent или нет», а два предложения: кто выбрал следующий шаг и кто смотрел. На оба можно ответить, прочитав код; ни одному не нужно чужое определение, и вместе они несут все последствия, ради которых использовали label.

Всё это не ново. Wooldridge и Jennings обозревали конкурирующие смыслы слова «agent» в 1995 году;⁶ Franklin и Graesser задали вопрос этой главы в 1996-м, собрали ходившие тогда определения и обнаружили, что они расходятся.⁷ Обзор 2023 года всё ещё определяет agents с первых принципов — «artificial entities that sense their environment, make decisions, and take actions»⁸, — потому что не существовало согласованного современного определения, на которое можно было сослаться, а CoALA описывает части, а не проводит границу.⁹ Тридцать лет отказа договориться говорят, что слово выполняет больше одной работы.

Теперь следствие, которое приходит раньше философии, — счёт.

Каждое измерение здесь имеет одну форму. Один вызов стоил 39 input tokens; тот же вопрос с одним tool стоил 420 в двух вызовах; loop без stopping rule стоил 1 688 в шести. Рост хуже линейного, потому что turn n несёт с собой все предыдущие turns: колонка prompt в том шестиходовом прогоне выглядит так: 187, 238, 261, 302, 327, 373. Глава 16 вывела, что total равен $\Theta(n^2)$, и подогнала curve на реальном conversation. Agent превращает каждую task в этот conversation, видит его человек или нет.

Если бы эти измеренные token counts ушли в коммерческий endpoint по rates, которые глава 16 прочитала 6 сентября 2026 года — $2,00 за миллион input tokens и $12,00 за миллион output, — четыре прогона стоили бы так:

Строка два против строки один — число, которое нужно запомнить. В семь с половиной раз дороже — за худший ответ на вопрос, который модель и так знала. Ничего не было настроено неправильно: tool существовал, значит модель им воспользовалась — и вывод главы 18 о том, что больно бьёт цена каталога, а не его точность, получает здесь самую дешёвую демонстрацию с каталогом из одного элемента.

Вот почему полезная половина обоих документов — та, где говорится, как этого не строить. Anthropic прямолинеен: найдите самое простое возможное решение и добавляйте complexity только при необходимости; это «может означать вообще не строить agentic systems», поскольку agentic systems «обменивают latency и cost на лучшую task performance», а «для многих applications обычно достаточно optimized single LLM calls with retrieval и in-context examples».⁴ Его аргумент за agent узок: open-ended problems, где вы не можете предсказать число steps и не можете hardcode path, в environment, которой доверяете, принимая «higher costs, and the potential for compounding errors».⁴ Экран OpenAI — зеркальное отражение: complex judgement, unmaintainable rule sets, unstructured data — и заканчивается так же: «otherwise, a deterministic solution may suffice».⁵

Итак, в таксономии этой главы: фиксированное число шагов в фиксированном порядке — это pipeline, и если назвать его agent, быстрее он не станет. Если число steps зависит от того, что вы найдёте по дороге, вам нужен loop — и эту гибкость вы покупаете N вызовами, квадратичным transcript и системой, которая может ошибиться N раз вместо одного.

Теперь у вас есть таксономия, оба современных определения, две оси, которые делают их совместимыми, и короткий loop, который отвечает, вызывает и останавливается.

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

Остаётся вопрос, которым на самом деле занималась спорная диагональ этой главы. Loop, который сам решает следующий шаг, должен решить, когда остановиться, и мы только что видели, что происходит, когда он не может: шесть turns, счёт в четыре раза больше и agent, который допрашивает пользователя о вопросе, на который уже ответил. Остановка — это не одно condition. Сколько их, и какое срабатывает первым?

Lilian Weng, LLM Powered Autonomous Agents (2023), — самое известное разложение language agent на planning, memory и tool use, и это правильное следующее чтение рядом с двумя vendor documents; его три components — это главы 23, 24 и 18 этого курса именно в таком порядке.

Каждое число в этой главе было получено на этой машине, ничего не оценивалось приблизительно. Коридор, 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 небольшим local Python endpoint, который loads weights и speaks OpenAI chat-completions shape — снова seam, с tensors на стороне Python и loop на стороне TypeScript, — поэтому token counts принадлежат tokenizer этой модели, а latencies — этой машине. Единственные figures, взятые извне, — две prices в cost table: rates, которые глава 16 прочитала на pricing page OpenAI 6 сентября 2026 года, применённые здесь к locally measured token counts как illustration, а не как observed invoice.