До этого мы делали одноразовые запросы. Сегодня — фундаментальный сдвиг мышления: переходим от «модель отвечает» к «модель решает, действует, наблюдает результат и принимает следующее решение». Это и есть агент.
Агент — это не специальный тип модели. Это паттерн использования: вокруг обычной LLM построен цикл «думай → действуй → наблюдай → думай дальше». В этом цикле модель может вызывать инструменты, читать их результаты, корректировать план. Главное концептуальное отличие от Дней 1-5: теперь модель не отвечает один раз — она работает над задачей, итерациями, пока задача не решена.
В Кластере 01 ты работал по схеме: задал вопрос → модель ответила → конец. Один запрос, один ответ. Это нормально для задач типа «классифицируй отзыв», «переведи текст», «дай совет».
Но есть целый класс задач, которые так не решаются. Например: «найди в интернете последние новости о компании X, прочитай три статьи, составь сводку и пришли мне по почте». Эту задачу нельзя выполнить одним запросом — нужно несколько шагов, причём следующий шаг зависит от того, что выяснилось на предыдущем.
Сам человек, выполняя такую задачу, действует не одним «прыжком», а итерациями: вспоминает, что искал → ищет → читает результаты → решает, что важно → читает дальше → составляет сводку → отправляет письмо. Каждое следующее действие — функция от того, что увидел в предыдущем.
Агент — это попытка дать LLM возможность работать так же: не одним ответом, а последовательностью «подумал → сделал → посмотрел → подумал», пока не выполнит задачу или не упрётся в тупик.
Главное концептуальное следствие: агент работает не с запросом, а с задачей. Один запуск агента — это не «один вызов API», а «N вызовов API, пока задача не решена». N может быть 2, может быть 50.
Под капотом любой агентский паттерн (с разными именами — ReAct, Plan-and-Execute, ReWOO и т.д.) сводится к одному циклу. Кратко его называют reason-act-observe.
Разберём каждую фазу подробнее:
На этой фазе модель смотрит на текущее состояние задачи (что уже сделано, что осталось, какие данные собраны) и решает: «что мне нужно сделать на следующем шаге, чтобы приблизиться к решению?»
Это просто LLM-запрос. Никакой магии: тот же самый API, что в Дне 1. Просто в system prompt сказано, что модель — агент с инструментами, и в контексте описаны эти инструменты и история уже сделанных шагов.
Что важно: reason — это часто открытый «внутренний монолог». В современных архитектурах модель явно проговаривает: «пользователь спросил про новости компании X. Сначала мне нужно их найти. Использую инструмент web_search». Это называется «scratchpad» или «thought».
Модель выбирает один из доступных ей инструментов (это набор функций, которые ты описал в system prompt: web_search, read_file, send_email и т.п.) и говорит, с какими параметрами его вызвать.
Технически это работает через tool calling (он же function calling): в ответе модели есть специальное поле, где она называет инструмент и аргументы. Твой код (или фреймворк типа LangChain, LlamaIndex) этот вызов перехватывает, выполняет реальный инструмент в твоей среде и получает результат.
Ключевая идея: модель не выполняет инструменты. Она только говорит, какой инструмент с какими аргументами вызвать. Реальное выполнение — на стороне твоей системы. Об этом будет весь Кластер 04 (MCP).
Твой код выполнил инструмент. Получил результат. Теперь нужно положить этот результат обратно в массив messages, чтобы модель его «увидела» на следующей итерации.
Технически — это просто новое сообщение в массиве, со специальной ролью (обычно tool или function). В нём — то, что вернул инструмент: текст веб-страницы, JSON от API, содержимое файла.
Тонкость, которая решит всё: результат инструмента нужно правильно подать модели. Если веб-страница пришла на 50 000 токенов — модель утонет. Если данные пришли в неудобном формате — будет плохо парсить. Это и есть «управление контекстом», которому посвящён весь этот кластер.
Когда контекст с результатом инструмента готов, ты снова вызываешь модель. Она смотрит на обновлённое состояние и решает: «всё ли я сделал?». Если задача выполнена — модель даёт финальный ответ (без вызова инструмента). Если нужны новые шаги — модель снова вызывает инструмент, и цикл повторяется.
На практике этот шаг часто сливается с Reason — это один и тот же запрос к модели, у которого один из вариантов выхода: «я закончила, вот ответ».
Аварийный выход: чтобы агент не зацикливался бесконечно, в коде всегда ставят лимит итераций (обычно 10-30). Если модель не справилась за это число шагов — задача считается невыполненной, агент останавливается.
Задача: «Найди новости о компании X, составь сводку, пришли по почте». Цикл агента:
web_search("компания X новости") → Observe: получили 10 ссылок.fetch_url(ссылка_1) → Observe: получили текст статьи.fetch_url(ссылка_2)... и так далее.send_email("сводка", текст) → Observe: «отправлено».5 итераций цикла. 5 раз модель «думала». Но для пользователя это выглядит как одна выполненная задача.
В индустрии у тебя сотни «фреймворков для агентов» — LangChain, LlamaIndex, AutoGen, CrewAI, Agno и т.д. Под капотом они все делают одно и то же. Отличаются они по нескольким осям:
Какие функции агенту доступны: только веб-поиск, или ещё чтение файлов, или ещё работа с API, базой данных, кодом. Чем больше инструментов — тем мощнее агент и тем сложнее им управлять.
Решает на каждом шаге («ReAct») или сначала строит план целиком, потом выполняет («Plan-and-Execute»). Первый гибче, второй устойчивее на длинных задачах.
Только текущая задача (stateless между сессиями) или с долгосрочной памятью между запусками. Об этом — весь Кластер 03.
Один агент, делающий всё, или несколько специализированных, которые делегируют друг другу. Multi-agent системы — отдельный класс архитектур.
Главный вопрос, на который многие отвечают неправильно. Агент — это дороже (несколько вызовов вместо одного), медленнее (последовательные итерации), менее предсказуемо (вариативность пути решения). Если задача решается одним вызовом — агент не нужен.
Хороший тест: «Может ли человек решить эту задачу в один присест, или ему нужно идти, что-то проверять, возвращаться?» Если первое — обходись без агента. Если второе — агент оправдан.
Соблазн — дать «всё, что есть»: пусть модель сама разберётся. На практике это ухудшает работу: чем больше инструментов, тем сложнее модели выбрать правильный, и тем чаще она ошибается.
Хороший подход — давать минимальный набор, достаточный для класса задач, которые агент решает. 3-5 инструментов работают лучше, чем 20. Если задач больше — лучше иметь нескольких специализированных агентов, чем одного универсального.
Модель может попасть в петлю: вызывает инструмент → видит, что результат не помогает → пробует тот же инструмент с чуть другими параметрами → опять не помогает → ... и так до конца денег на счёте. Это дорого.
Всегда ставь лимит на число итераций (например, 15). Когда лимит достигнут — агент останавливается с сообщением «не смог решить за N шагов». Лучше получить «не справился», чем счёт на $200 за петлю.
Вызвал web_search — получил 50 KB HTML с рекламой, навигацией, футером. Положил это всё в контекст агента. Через пару итераций контекст забит мусором, модель путается, токены тают.
Правильная привычка: между observe и следующим reason ты можешь (и должен) преобразовать результат инструмента: извлечь главное, отбросить лишнее, ужать. Это часть управления контекстом, и об этом — следующие 4 урока.
«Возьму большую модель, дам ей инструменты — и получится умный агент». Не совсем. Хороший агент — это хорошее окружение вокруг модели: правильный system prompt с описанием инструментов, аккуратное возвращение результатов, чёткие условия остановки.
Маленькая модель в хорошо построенном агенте часто работает лучше, чем большая модель в плохо построенном. Архитектура цикла — важнее модели.
Дал агенту инструмент execute_shell_command или delete_file — и думаешь только о задаче. Но эти инструменты он будет вызывать в реальной системе. Один неудачный вывод модели — и удалена не та папка, отправлено не то письмо.
Возвращайся к Дню 0, раздел «Агенты с инструментами». Все принципы (whitelist, read-only по умолчанию, human-in-the-loop на необратимом, sandbox для кода) — применяются именно здесь.
На этом уроке нет привычного «сядь в плейграунд и попробуй» — настоящий агент требует кода вокруг модели. Но три мысленных упражнения сильно помогут:
Возьми реальную задачу из своей жизни: «забронировать столик в ресторане на пятницу вечером». Распиши её как последовательность фаз агента — что я (как агент) рассуждаю, какой инструмент использую (Google, телефон, приложение), что наблюдаю в результате, как меняется план. Заметишь, что наша обычная деятельность уже устроена как цикл агента — мы просто не задумываемся.
Возьми 10 задач, которые ты делал на работе на этой неделе. Отметь каждую: одношаговая (можно решить одним запросом к LLM) или агентская (нужен цикл с инструментами). У большинства людей соотношение 80/20 или 70/30 в пользу одношаговых — это нормально. Понимание, какие задачи в твоей жизни правда агентские, поможет потом не строить агента там, где он не нужен.
Современные ассистенты — это и есть агенты. Когда ты пишешь в ChatGPT «найди мне последние новости про X» — он не сразу отвечает, а сначала идёт в web_search, потом fetch_url, потом пишет тебе ответ. Включи в интерфейсе показ «инструментов» (в ChatGPT это tools, в Claude — thinking). Сделай 2-3 запроса, требующих поиска. Посмотри, как агент видимо проходит цикл — какие инструменты вызывает, что получает обратно. Это даст тебе живое ощущение паттерна.