Модель, context и агентный цикл

Модель умеет одно: продолжать текст

LLM (large language model, большая языковая модель) получает текст и предсказывает, какой token (кусок слова, единица текста для модели) идёт дальше. Чат, рассуждение и вызов инструментов построены поверх этой одной способности. Из неё следуют три свойства, на которые опирается вся инженерия агентов.

1. Модель случайна. Один и тот же вопрос в разных прогонах даёт разные ответы. Поэтому агента проверяют многими прогонами, а не одним.
2. Модель знает только две вещи: то, что выучила в training (обучении), замороженное на дату cutoff (дату среза знаний) и, возможно, устаревшее, и то, что лежит перед ней прямо сейчас — context. Другого доступа к миру у неё нет.
3. Модель звучит уверенно, даже когда ошибается. Она назовёт комиссию за досрочное погашение спокойным тоном и ошибётся. Гладкость текста — не доказательство. Отсюда hallucination (галлюцинация, уверенная выдумка).

Context: всё, что модель видит за один вызов

Context (контекст) — это весь вход одного вызова модели: system prompt (системная инструкция), разговор до этого места, результаты tools, найденные документы. У него есть предел, context window (окно контекста), который меряют в tokens; в английском тексте один token — примерно ¾ слова. Каждый token в context стоит денег и времени, а лишний token ещё и отвлекает модель. Поэтому большая часть работы инженера агентов — решить, что положить в context, а что оставить снаружи. У этой работы есть имя, context engineering (подбор содержимого context), ему посвящён урок a2-7.

От chatbot к agent: цикл

Chatbot отвечает. Agent действует. Разница — в цикле:

1. Модель читает цель и context.
2. Решает: ответить сейчас или вызвать tool (инструмент, функцию, которую модель может попросить выполнить)?
3. Если tool — программа вокруг модели выполняет его и кладёт результат в context.
4. Снова шаг 1, пока модель не скажет «готово» или цикл не остановит лимит.

Anthropic в статье «Building effective agents» различает два вида систем. Workflow (заданный процесс) — LLM и tools связаны путями, которые заранее написал программист. Agent — модель сама выбирает следующий шаг и tool. Совет оттуда же: начинать с самого простого решения и усложнять, только когда это нужно. Где путь известен заранее (заблокировать карту: проверить личность, спросить подтверждение, вызвать блокировку), пиши workflow. Агент нужен там, где число и порядок шагов заранее не предскажешь.

Модель и harness: кто что делает

Harness (обвязка) — программа, которая крутит цикл: подаёт описания tools, собирает context, проверяет права, выполняет вызовы, делает retries (повторы), следит за timeouts (пределами времени) и лимитами, пишет traces (журнал каждого шага). Claude Code и Codex — это harnesses. Удобная аналогия — автомобиль:

Главное разделение ролей: модель только предлагает, harness исполняет. Модель пишет «вызови block_card»; проверить право, выполнить вызов, положить результат в context и остановить цикл по лимиту — работа harness. Цикл останавливает тоже harness, и причин остановки больше одной: модель дала итоговый ответ; кончился лимит шагов; кончилось время или деньги на запрос; tool вернул ошибку, которую нельзя исправить; действие требует человека, и цикл ждёт его решения. Для каждой причины заранее решают, что увидит клиент: честный частичный ответ, передачу оператору или просьбу подтвердить. Отсюда правило, которое пройдёт через весь модуль: всё, что нужно гарантировать, живёт в коде harness и tools, а не в тексте инструкции для модели.

Пример с числами: почему один успех мало значит

Агент отвечает клиенту банка на вопрос «почему с меня списали комиссию?» за шесть шагов: найти операцию, найти тариф, проверить дату договора и так далее. Допустим, на каждом шаге модель выбирает верное действие в 95% случаев, и шаги независимы. Тогда вся цепочка проходит верно с вероятностью 0,95⁶ ≈ 0,74, то есть примерно в 74% прогонов. Каждый четвёртый прогон где-то сворачивает не туда. Удачная демонстрация показала тебе одну из удачных трёх четвертей. Чтобы узнать реальную долю успеха, нужны десятки задач и несколько прогонов каждой (это тема модуля Evaluation).

Второе следствие цикла: context растёт с каждым шагом. Если system prompt и описания tools занимают 3 000 tokens, а каждый шаг добавляет вызов и результат по 800 tokens, то к шестому шагу модель читает уже около 7 800 tokens, и каждый следующий вызов дороже предыдущего. Поэтому tools должны возвращать коротко и по делу (урок a2-4).

Облачный API или локальная модель

Это решение принимают до первой строки кода. Облачный API даёт сильнейшие модели без своего железа, но данные клиента уходят к поставщику, и для банка это вопрос закона о данных и data residency (требования хранить данные в своей стране или регионе). Локальная open-weight модель (модель с открытыми весами) держит данные внутри периметра, но слабее лучших облачных и требует своих GPU и людей, которые их обслуживают. Частый компромисс — облачная модель через регион поставщика внутри нужной юрисдикции плюс маскировка персональных данных до вызова.