AI-агенты: хайп или реальный инструмент?

TL;DR: AI-агент — это цикл «модель → вызов инструмента → результат → следующий шаг», который крутится до достижения цели или исчерпания лимитов. Агенты оправданы, когда задача не сводится к одному вызову LLM, нужен доступ к внешним системам и есть способ программно проверить результат. В остальных случаях детерминированный пайплайн дешевле и надёжнее. Главные отказы — зацикливание, вызовы несуществующих инструментов и линейный рост стоимости с числом шагов. Всё это лечится лимитами, схемами и человеком в контуре.

Что такое агент на самом деле

Если отбросить маркетинг, рабочее определение агента короткое: это LLM, помещённая в цикл, где каждая итерация выглядит так:

1. Модель получает текущее состояние (цель, история шагов, результаты прошлых вызовов).
2. Модель решает: либо дать финальный ответ, либо вызвать инструмент — поиск, запрос к API, чтение файла, выполнение кода.
3. Результат инструмента добавляется в контекст.
4. Цикл повторяется.

Всё. Этот паттерн описан ещё в статье ReAct (Reasoning + Acting, 2022) и с тех пор принципиально не изменился — поменялась только инфраструктура вокруг него. Обычный вызов LLM — это одна итерация без инструментов. Агент — это N итераций, где N неизвестно заранее.

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

Когда агент оправдан, а когда — нет

Моя позиция после нескольких внедрений: большинство задач, которые приходят с формулировкой «нам нужен агент», на деле решаются обычным пайплайном из двух-трёх вызовов LLM. Прежде чем строить агента, я проверяю три критерия.

1. Задача не сводится к фиксированной последовательности шагов. Если вы можете нарисовать flowchart процесса на одной странице и он не ветвится непредсказуемо — пишите код, а не агента. Классический RAG с рерайтом запроса и реранкингом — это пайплайн, а не агент, и я подробно разбирал такую схему в статье про RAG-пайплайн для корпоративных документов.

2. Нужен доступ к инструментам, и набор вызовов зависит от данных. Агент имеет смысл, когда модель должна сама решать, что вызвать следующим шагом: поискать в базе, потом, глядя на результат, либо уточнить запрос, либо пойти во внешний API, либо ответить. Исследование по незнакомому кодовому репозиторию, многошаговая диагностика инцидента, сбор информации из разнородных источников — вот его зона.

3. Есть способ проверить результат. Это критерий, о котором почему-то забывают чаще всего. Если корректность ответа нельзя проверить программно (тесты прошли, запрос вернул валидный JSON, число сошлось с источником) или дёшево сэмплирует человек — агент превращается в генератор уверенно звучащего текста, который никто не контролирует.

Обратная сторона: если задача хорошо специфицирована, объёмы большие, а ошибка стоит дорого (платежи, юридические документы, рассылки клиентам) — детерминированный пайплайн с LLM на отдельных узлах выигрывает почти всегда. Он предсказуем по стоимости, тестируется юнит-тестами и не зацикливается.

Компоненты агента без магии

На практике агент состоит из четырёх вещей, и ни одна из них не является «магией».

Модель. Выбирается по задаче, а не по бенчмаркам. Для оркестрации нужна модель, которая стабильно соблюдает формат tool calls и не теряет нить в длинном контексте. Обязательно гоняйте её на своих реальных трассах — публичные бенчмарки агентности слабо коррелируют с вашим доменом.

Инструменты. Обычные функции с описанием схемы аргументов (JSON Schema), которые модель может вызывать. Качество описаний инструментов важнее качества промпта: если у функции search не написано, что она ищет и в каком виде возвращает результат, модель будет использовать её криво.

Память. Краткосрочная — это просто история сообщений в цикле. Долгосрочная — отдельная подсистема, и она почти всегда сложнее, чем кажется: что сохранять, когда забывать, как не загрязнять контекст устаревшими фактами. Я разбирал это отдельно в статье про память AI-систем.

Цикл. Если коротко — это while с условием выхода: модель вернула ответ без вызова инструмента, либо сработал лимит. Всё остальное — детали реализации.

# Минимальный агентный цикл на openai SDK >= 1.x
from openai import OpenAI

client = OpenAI()

def run_agent(goal: str, tools: list, tool_handlers: dict,
              max_steps: int = 10) -> str:
    messages = [{"role": "user", "content": goal}]

    for _ in range(max_steps):
        response = client.chat.completions.create(
            model="gpt-4.1",
            messages=messages,
            tools=tools,
        )
        message = response.choices[0].message
        messages.append(message)

        if not message.tool_calls:
            return message.content  # модель дала финальный ответ

        for call in message.tool_calls:
            handler = tool_handlers.get(call.function.name)
            if handler is None:
                result = {"error": f"unknown tool: {call.function.name}"}
            else:
                result = handler(**call.function.parsed_arguments)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": str(result),
            })

    return "Лимит шагов исчерпан — задача не решена."

Обратите внимание: в цикле уже заложены два механизма безопасности — обработка вызова несуществующего инструмента (модели такое «галлюцинируют» регулярно) и жёсткий лимит шагов. Это не опция, это минимум.

Стандарт подключения инструментов: MCP

До недавнего времени каждый таскал свои обёртки для подключения инструментов к агенту. Сейчас де-факто стандартом стал Model Context Protocol (MCP) — открытый протокол, который описывает, как сервер публикует инструменты, ресурсы и промпты, а клиент (агент) их обнаруживает и вызывает. Смысл простой: инструмент пишется один раз как MCP-сервер и дальше подключается к любому совместимому клиенту — IDE, десктопному ассистенту, вашему агенту.

Свой инструмент для этой экосистемы я тоже сделал: token-save-mcp — MCP-сервер, который агент использует для экономии контекста: вместо того чтобы таскать в историю целиком большие ответы инструментов, агент складывает их в хранилище и работает со сжатыми представлениями, подтягивая полное содержимое только когда оно реально нужно. Проблема, которую он решает, рано или поздно упирается в каждый агентный проект: после десятка шагов контекст раздувается от сырых результатов инструментов, растёт стоимость и модель начинает терять релевантное.

Типовые отказы и как их ограничивать

Три отказа я встречал практически в каждом агентном проекте.

Зацикливание. Модель вызывает инструмент, получает не тот результат, пробует снова с теми же аргументами — и так до бесконечности. Лечение: жёсткий max_steps, дедупликация вызовов (одинаковый инструмент с одинаковыми аргументами дважды — стоп), и в системном промпте — явное указание «если два шага подряд не дали прогресса, переформулируй подход или остановись».

Вызов несуществующих инструментов и битые аргументы. Модель уверенно вызывает get_user_by_email, хотя у вас есть только find_user. Лечение: узкие схемы с enum и required-полями, валидация аргументов до выполнения, осмысленные ошибки, которые возвращаются модели в контекст — это, как ни странно, хорошо работает: получив внятную ошибку, модель обычно корректируется. Чем уже и точнее специфицирован набор инструментов, тем реже такие отказы.

Рост стоимости с числом шагов. Каждая итерация тащит в запрос всю историю. Грубая оценка: задача на 15 шагов с инструментами легко во много раз дороже одиночного вызова той же модели на той же задаче в пайплайне — плюс латентность складывается последовательно. Лечение: бюджет токенов рядом с лимитом шагов, сжатие истории (тот же token-save-mcp или summarization-узел), дешёвая модель на простых шагах, кэширование результатов инструментов. Оценивайте юнит-экономику до продакшена: стоимость одной решённой задачи против ценности, которую она приносит. Вопросы бюджетов на подобные системы я разбирал в статье «Сколько стоит MVP».

Четвёртый механизм стоит особняком, потому что он не про отказ, а про риск: человек в контуре (human-in-the-loop). Любое действие с необратимыми последствиями — отправка письма, деньги, запись в продакшен-базу — должно требовать подтверждения человеком. Агент готовит черновик действия и план, человек жмёт «да». В фреймворках вроде LangGraph это сделано нативно через прерывания графа; при выборе между стеками ориентируйтесь на это, а не на количество звёзд — больше о трейдоффах в статье про LangChain и LlamaIndex.

Так хайп или инструмент

Мой ответ: инструмент, но узкий. Агенты реально работают там, где выполнены три критерия из раздела выше и выстроены лимиты. Кодовые ассистенты, исследовательские задачи, диагностика, многошаговая работа с инструментами — здесь экономика уже сходится. «Универсальный агент, который ведёт мой бизнес» — это хайп, и он заканчивается зацикливанием на пятом шаге и счётом за токены.

Практический путь, который я рекомендую: начните с детерминированного пайплайна. Те узлы, где LLM должна сама решать, что делать дальше, — единственные кандидаты на агентный цикл. Добавляйте автономность по одному узлу, замеряя стоимость и долю успешно решённых задач на каждом шаге. Если метрика не растёт — возвращайте узел в детерминированный вид. Это скучнее, чем «запустить агента», но это единственный способ, который я видел работающим в продакшене.

FAQ

Чем агент отличается от чат-бота?

Чат-бот отвечает на сообщение одним вызовом модели. Агент крутит цикл: решает, вызывает инструменты, смотрит на результаты и продолжает, пока цель не достигнута или не сработал лимит. Отличие не в интерфейсе, а в наличии цикла и инструментов.

Нужен ли фреймворк для агентов?

Минимальный агентный цикл — это десятки строк кода, как в примере выше. Фреймворк оправдан, когда нужны persistence состояния, human-in-the-loop, параллельные ветки и стриминг — посмотрите на LangGraph как на один из зрелых вариантов. Но фреймворк не заменяет понимания, почему цикл зациклился.

Как понять, что агент в моей задаче заработает?

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

Когда использовать MCP, а когда просто function calling?

Function calling достаточно, пока инструменты живут внутри одного вашего приложения. MCP имеет смысл, когда инструменты должны переиспользоваться между клиентами или вы подключаете сторонние серверы.

Сколько стоит агент в эксплуатации?

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

Хотите внедрить агента и не утопить его в токенах? Напишите мне — обсудим вашу задачу.