What Is an Agent: Loop, Tools, Memory

Главное отличие агента от обычного вызова LLM — то, у кого находится управление. В чат-боте управление всегда у вашего кода: отправили запрос, получили текст, показали пользователю, конец. В workflow управление у заранее нарисованного графа: шаг A, потом шаг B, потом ветвление — маршрут известен до запуска, модель лишь заполняет узлы. В агенте управление передаётся модели: она сама решает, какой инструмент вызвать следующим, глядя на результат предыдущего шага. Anthropic в статье «Building effective agents» проводит именно эту границу: workflow — это LLM внутри предопределённого кода, агент — это LLM, который динамически управляет собственным процессом.

Формула агента укладывается в четыре строки псевдокода:

история = [задача]
пока не готово:
    решение = модель(история)          # текст ИЛИ вызов инструмента
    если решение — вызов инструмента:
        результат = выполнить(решение)  # это делает ВАШ код
        история += [решение, результат]
    иначе: вернуть решение              # финальный ответ

Всё остальное — обвязка вокруг этого цикла: какие инструменты доступны, как хранится история, когда цикл обязан остановиться. Заметьте важную деталь: модель никогда ничего не исполняет сама. Она лишь выражает намерение — «вызови поиск с таким-то запросом», — а исполняет намерение ваш код. Это и рычаг контроля: между намерением и исполнением вы можете вставить проверку, лимит или вопрос человеку.

В литературе этот цикл называют по-разному — ReAct, agent loop, orchestration loop, — но суть одна: чередование рассуждения и действия с наблюдением результата. Запомните слово «наблюдение»: именно возврат результата инструмента обратно в историю превращает набор разрозненных вызовов в поведение, способное корректировать курс.

Инструмент — это обычная функция вашего кода, о существовании которой модель знает из описания. Вы передаёте провайдеру список инструментов: имя, назначение и JSON-схему аргументов. Модель, решив воспользоваться инструментом, возвращает не текст, а структурированный вызов — имя функции плюс аргументы в JSON. Ваш код исполняет функцию и кладёт результат обратно в историю сообщений, после чего модель продолжает рассуждение уже с учётом результата.

Из этого устройства следуют три практических вывода. Первый: качество описания инструмента напрямую определяет, будет ли модель им пользоваться и правильно ли. Описание «ищет данные» бесполезно; описание «полнотекстовый поиск по базе тикетов поддержки, возвращает до 10 совпадений с id и заголовком» — рабочее. Второй: набор инструментов — это и есть граница возможностей агента. Агент без инструмента «отправить письмо» физически не может отправить письмо, сколько бы его ни просили, — и это способ проектировать безопасность, а не ограничение. Третий: инструменты бывают читающими (поиск, чтение файла, HTTP GET) и пишущими (создать тикет, изменить метку, отправить сообщение). Читающие можно давать агенту щедро, пишущие — скупо и под контролем; к этому разделению мы будем возвращаться весь курс, особенно в уроке про guardrails.

У агента по умолчанию только одна память — массив сообщений, который вы передаёте в каждый вызов модели. Это и есть short-term память: задача пользователя, рассуждения модели, вызовы инструментов и их результаты, всё подряд. Она бесплатна в реализации, но у неё два жёстких ограничения: она стирается между запусками и она упирается в контекстное окно. Агент, сделавший сорок шагов с многокилобайтными результатами инструментов, просто перестанет помещаться в контекст — и придётся решать, что выбрасывать.

Поэтому в зрелых агентах память расслаивается. Scratchpad — явные рабочие заметки: план из пунктов, список уже проверенных гипотез, промежуточные выводы. Его агент ведёт сам, через инструмент или структурированное поле состояния, и он переживает обрезку истории. Long-term память — внешнее хранилище (файл, база, векторный индекс), куда агент откладывает знания между запусками: «пользователь предпочитает ответы по-русски», «в этом репозитории тесты запускаются командой make test».

На старте достаточно запомнить иерархию: массив сообщений — рабочий стол, scratchpad — пришпиленная к монитору бумажка с планом, long-term — архив в шкафу. Урок 4 разберёт каждый слой с кодом; пока важно одно — «память агента» это не магия, а решения о том, какие байты вы кладёте в контекст следующего вызова.

Самая частая ошибка новичка — строить агента там, где хватит функции. Правило из практики: автономия — это цена, которую платят за неизвестный заранее маршрут. Если маршрут известен — платить незачем.

Три проверочных вопроса перед стартом. Первый: детерминирована ли задача? «Извлечь сумму и дату из счёта» — это один вызов модели со structured output, цикл не нужен. Второй: известна ли последовательность шагов заранее? «Получить текст → перевести → саммаризировать → отправить» — это workflow: три вызова, склеенные обычным кодом; он дешевле, быстрее и предсказуемее агента. Третий: нужен ли вообще LLM? Отфильтровать строки по регулярному выражению агентом — профессиональный позор.

Агент оправдан, когда путь к результату зависит от того, что выяснится по дороге: отладка («запусти тесты, посмотри, что упало, почини, повтори»), исследование («найди, в каких файлах используется этот API, и оцени масштаб миграции»), triage («прочитай issue, поищи дубликаты, реши, какие метки поставить»). Общий знаменатель — ветвление по промежуточным результатам, которое нельзя зашить в код заранее.

За автономию вы платите трижды: латентность (каждый шаг — полный проход модели), деньги (история растёт, токены дорожают с каждым шагом) и недетерминизм (один и тот же запуск может пойти разными путями). Начинайте с простейшего решения и добавляйте автономию только под давлением реальной задачи — это прямой совет из «Building effective agents», и он самый ценный в статье.