Агент на базе LLM: как цикл из модели и инструментов заменил чат-бота

Три даты определяют современного LLM-агента: 2022 год, когда вышла работа про подход ReAct, июнь 2023, когда OpenAI добавила в API вызов функций, и ноябрь 2024, когда Anthropic представила протокол MCP для подключения инструментов. На Habr опубликован материал о том, как устроен агент поверх LLM. Автор сразу оговаривается, что архитектуру трансформеров обсуждать не будет, и смотрит на систему с прикладной стороны. В RSS-анонсе доступно только вступление, поэтому ниже разобрана общая схема, на которой держится большинство агентов, без пересказа деталей самой статьи.

Цикл вместо одного ответа

Обычный чат устроен просто: пользователь задаёт вопрос, модель отвечает. Агент работает иначе. Модель получает задачу и список доступных инструментов, а затем решает, что сделать: ответить сразу или вызвать функцию. Результат вызова возвращается в контекст, и модель делает следующий шаг. Так продолжается до тех пор, пока она не сочтёт задачу выполненной или пока внешний код не оборвёт цикл.

Сама модель при этом ничего не исполняет. Она выдаёт структурированный запрос, например имя функции и аргументы в JSON. Выполняет его обычная программа, которую называют оркестратором или рантаймом. Именно там живёт логика повторов, таймаутов и ограничений.

Из чего собран агент

Набор компонентов у большинства реализаций похож, будь то самописный код или готовый фреймворк:

• Модель: принимает контекст и возвращает либо текст, либо вызов инструмента.
• Инструменты: функции с текстовым описанием и схемой аргументов. Поиск, SQL, shell, браузер, внутренние API.
• Память: история шагов внутри контекстного окна плюс внешнее хранилище, например векторная база или файлы.
• Оркестратор: обычный код, который гоняет цикл, валидирует вызовы и ведёт логи.
• Условие остановки: финальный ответ модели, лимит шагов или бюджет токенов.

Отдельно стоит сказать про MCP. Протокол задаёт единый способ описывать инструменты и ресурсы, и один и тот же сервер можно подключить к разным клиентам. Для разработчика это снижает стоимость интеграций: описание инструмента пишется один раз.

Где агенты ломаются

Проблемы обычно возникают не в самой модели, а вокруг неё. Первая типичная беда состоит в том, что агент зацикливается: вызывает один и тот же инструмент с теми же аргументами и ждёт другого результата. Вторая в том, что контекст растёт с каждым шагом. Ответы инструментов, особенно длинные выгрузки, вытесняют важные инструкции, а стоимость каждого следующего шага увеличивается. Третья в том, что ошибки накапливаются. Если вероятность верного шага 95%, то из десяти подряд шагов без ошибок пройдут примерно 60% запусков. Поэтому длинные цепочки без проверок работают заметно хуже коротких.

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

Как собирать свой

Начинать стоит с минимального цикла на одной модели и двух-трёх инструментах. Жёсткий лимит шагов и бюджет токенов нужны с первого дня, как и журнал каждого вызова с аргументами и ответом: без него отладка превращается в гадание. Опасные действия, такие как запись, удаление и платежи, лучше пускать через подтверждение человека. Результаты инструментов стоит обрезать и суммировать до того, как они попадут в контекст. Фреймворки пригодятся позже, когда станет ясно, какие части цикла действительно нужно усложнять. Полный разбор с примерами автор публикует на Habr, и именно оттуда стоит брать конкретику по реализации.