ИИ агенты: что это и как их использовать

Все говорят про агентов, половина под этим словом понимает что угодно. В этой статье разберем, что такое агент на самом деле, как он устроен внутри, когда он реально нужен, и как собрать своего без магии.

После прочтения статьи вы сможете смотреть на любой агентный фреймворк и понимать, как он работает.

---

1. Что такое агент

Если коротко, агент это LLM, у которой есть инструменты и цикл: модель не просто отвечает текстом, а сама решает, что сделать, делает, смотрит на результат и решает, что дальше.

Обычный чат с моделью это один шаг:

вопрос -> ответ

Агент это цикл:

вопрос -> подумать -> вызвать инструмент -> посмотреть результат
       -> подумать еще -> вызвать другой инструмент -> ... -> ответ

Отсюда

Агент = LLM + инструменты + память + цикл

Никакого самосознания(как некоторые считают). Это цикл while с моделью внутри, которая на каждом шаге решает, какой инструмент использовать.

Разница хорошо видна на примере:

Правило простое: если для ответа нужно взаимодействие с внешним миром и заранее неизвестно, сколько шагов понадобится, это работа для агента.

---

2. Как это работает внутри

Ядро агента это так называемый agent loop. Выглядит примерно так:

messages = [{"role": "system", "content": "Ты агент. У тебя есть инструменты: (какие-то инструменты)"}]

while True:
    response = llm.chat(messages, tools=tools)

    # если модель не хочет вызывать инструменты, значит ответ готов
    if not response.tool_calls:
        break

    for call in response.tool_calls:
        result = execute_tool(call.name, call.arguments)
        messages.append({"role": "tool", "content": result})

print(response.content)

Все. Это весь агент. Дальше только детали, которые превращают этот цикл из игрушки в рабочий продукт:

Инструменты. Обычные функции, которые вы описываете модели в формате tool calling: имя, описание, параметры. Описание критически важно, модель выбирает инструмент по нему. Плохо описанный инструмент, плохо вызванный инструмент.

Системный промпт. Здесь есть правила: что можно, что нельзя, как останавливаться, в каком формате отвечать. Агенты живут на качестве промпта, как ни банально это звучит.

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

Остановка. Максимальное число шагов, стоп-условия, лимиты на токены. Без этого агент однажды уйдет в бесконечный цикл и сожжет вам бюджет за ночь. Это не шутка, и такое бывает.

ReAct

Классический паттерн, на котором агенты и выросли: Reason + Act. Модель на каждом шаге проговаривает рассуждение, потом действие:

Thought: мне нужно узнать цену заказа, вызову get_order
Action: get_order(id="45821")
Observation: заказ в пути, доставка завтра
Thought: теперь могу ответить
Answer: ...

Сейчас явный формат ReAct почти не пишут руками, его заменил нативный tool calling у провайдеров, но суть та же: чередование рассуждений и действий.

---

3. Инструменты и MCP

Инструмент это любая функция, которую модель может вызвать. Типовой набор:

• Поиск (интернет, внутренняя база, RAG)
• Чтение и запись файлов
• Выполнение кода (песочница)
• API вызовы (CRM, почта, календарь, платежки)
• SQL к базе

Пример описания инструмента:

{
  "name": "get_order_status",
  "description": "Возвращает статус заказа по его номеру. Используй, когда клиент спрашивает про доставку.",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {"type": "string", "description": "Номер заказа, например 45821"}
    },
    "required": ["order_id"]
  }
}

Обратите внимание на описание: там прямо написано, когда использовать инструмент. Это не украшение, это половина качества работы агента.

В 2026 стандартом де-факто стал MCP (Model Context Protocol): открытый протокол, по которому модели подключаются к источникам инструментов. Пишете один MCP-сервер, для вашей CRM, и любой совместимый клиент (Claude, Cursor, свой агент) уже умеет с ней работать. Не нужно для каждого клиента отдельно писать интеграции. Если делаете инструменты, смотрите в сторону MCP.

---

4. Уровни автономности

Полезная шкала, прежде чем что-то строить:

Чем выше уровень, тем дороже, медленнее и непредсказуемее.
Главное правило: не делайте уровень 3, если задача решается на уровне 2.

---

5. Мультиагентные системы

Несколько агентов, каждый со своей ролью, общаются между собой.

В 90% случаев один хороший агент с нормальными инструментами работает лучше, чем три агента, которые перебрасывают задачу друг другу и теряют контекст. Мультиагентщина добавляет: рост стоимости (каждый переход это вызовы модели), потерю контекста, каскадные ошибки.

Когда она все-таки оправдана:

• Задачи реально декомпозируются на независимые подзадачи (например, параллельный анализ 50 документов)
• Нужны разные роли с разными правами: агент-исследователь ищет, агент-критик проверяет, агент-редактор пишет
• Контекст физически не влезает в один процесс

Если все же делаете, начинайте с простых топологий: оркестратор + воркеры, а не демократия из десяти агентов, которые спорят.

---

6. Фреймворки

Мой практический совет: первого агента напишите без фреймворка. Просто цикл, как в разделе 2, плюс 2–3 инструмента. Вы за вечер поймете про агентов больше, чем за неделю туториалов по LangChain. А фреймворк возьмете потом, когда точно знаете, что именно вам от него надо.

---

7. Собираем рабочего агента

Минимальный агент поддержки, который умеет смотреть заказы и базу знаний:

import json
from openai import OpenAI

client = OpenAI()

# Инструменты, обычные питон функции
def get_order_status(order_id: str) -> str:
    # тут был бы реальный запрос в базу
    orders = {"45821": "в пути, доставка завтра до 18:00",
              "45822": "доставлен 20.09"}
    return orders.get(order_id, "заказ не найден")

def search_kb(query: str) -> str:
    # тут был бы поиск по базе знаний / RAG
    return "Возврат возможен в течение 14 дней с момента получения."

tools = [
    {"type": "function", "function": {
        "name": "get_order_status",
        "description": "Статус заказа по номеру. Зови, когда клиент спрашивает про заказ или доставку.",
        "parameters": {"type": "object", "properties": {
            "order_id": {"type": "string"}}}},
    },
    {"type": "function", "function": {
        "name": "search_kb",
        "description": "Поиск по базе знаний магазина: возврат, оплата, гарантия.",
        "parameters": {"type": "object", "properties": {
            "query": {"type": "string"}}}},
    },
]

SYSTEM = """Ты агент поддержки магазина.
Правила:
- Отвечай коротко и по-человечески.
- Прежде чем отвечать про заказ, вызови get_order_status.
- Не выдумывай информацию, если что-то не знаешь, вызывай search_kb.
- Максимум 5 вызовов инструментов на вопрос.
"""

def run_agent(user_msg: str, max_steps: int = 5):
    messages = [{"role": "system", "content": SYSTEM},
                {"role": "user", "content": user_msg}]

    for _ in range(max_steps):
        resp = client.chat.completions.create(
            model="gpt-4o-mini",
            messages=messages,
            tools=tools,
        )
        msg = resp.choices[0].message
        messages.append(msg)

        if not msg.tool_calls:
            return msg.content

        for call in msg.tool_calls:
            fn = {"get_order_status": get_order_status,
                  "search_kb": search_kb}[call.function.name]
            result = fn(**json.loads(call.function.arguments))
            messages.append({"role": "tool", "tool_call_id": call.id,
                             "content": result})

    return "Не смог решить задачу за отведенное число шагов."

print(run_agent("Где мой заказ 45821? И можно ли его вернуть?"))

Заметьте, что здесь есть все, о чем говорили: инструменты с внятными описаниями, системный промпт с правилами, лимит шагов и честное не смог вместо зависания. Это каркас, на который навешиваются реальные функции.

---

8. Частые ошибки

1. Агент там, где хватит пайплайна. Если шаги известны заранее, просто напишите обычный код с парой вызовов модели. Агент нужен, когда последовательность заранее неизвестна.
2. Слишком много инструментов. 40 инструментов в одном агенте, и модель начинает путаться. Дробите на специализаций или убирайте лишнее.
3. Нет лимитов. Без max_steps и бюджетов агент рано или поздно уйдет в цикл. В проде это деньги и инциденты.
4. Слепая вера в ответ модели. Агент сказал готово, а на самом деле файл не записался. Проверяйте результаты инструментов и заставляйте агента подтверждать успех.
5. Нет логирования шагов. Отлаживать агента без трейса (что он думал, что вызывал, что получил) невозможно. Логируйте все.
6. Давать агенту права рута. Инструменты должны быть минимально достаточными: read-only где можно, подтверждение человека перед опасными действиями (удаление, отправка писем).
7. Не тестируют на кривых входах. Пустая база, опечатки в номере заказа, попытки инъекций через пользовательский текст. Агент ломается именно там.

---

9. Как оценивать агента

Тут все сложнее, чем у обычной модели, потому что у агента есть и путь, и результат.

• Итоговый ответ правильный или нет (LLM-as-a-judge хорошо работает)
• Траектория: правильные ли инструменты вызывал, не делал ли лишнего
• Стоимость и латентность: сколько токенов и секунд на задачу
• Процент задач, решенных без человека

Практический сетап: соберите 50–100 реальных задач, прогоняйте на них агента после каждого изменения промпта или инструментов, и смотрите не только на итог, но и на траектории. Увидите много интересного, например, что агент в 30% случаев вызывает инструмент с выдуманным аргументом, который в проде молча вернет не найдено.

---

10. Стоимость и оптимизация

Агент дороже обычного чата. Не потому что модель дороже, а потому что вызовов больше. Один запрос пользователя — это 3–10 вызовов модели, а то и больше.

Почему:

• Многошаговые циклы: каждый шаг, полный контекст заново
• Большие ответы инструментов: JSON на 50К токенов в истории умножается на количество шагов
• Долосрочная память: каждый раз подкладываем факты в промпт
• Крутая модель на простых шагах: Gpt 6 astra там, где хватило бы luna

Как экономить:

• Разные модели для разных шагов: Дешевая модель для простых решений (выбрать инструмент), дорогая для сложных (финальный ответ, планирование).
• Кэширование: Результаты инструментов, системный промпт, эмбеддинги, все что не меняется не должно пересчитываться.
• Обрезка истории: Не кладите весь диалог в каждый шаг. Суммаризируйте.
• Уменьшение инструментов: Меньше инструментов -> короче промпт -> дешевле вызов.
• Батчинг: Если задача параллелится, делайте параллельно, а не последовательно.
• Prompt caching: Провайдеры дают скидки за кэшированный префикс промпта.

---

11. Как выбрать модель, и какие есть агенты

Не все модели умеют использовать инструменты. Фронтирные модели обучены на огромных агентных датасетах, но если вы берете маленькие локальные модели могут быть проблемы.

Критерии выбора модели, смотрим на пять вещей:

1. Поддержка tool calling: Есть ли нативный формат вызова функций. Если нет, придется парсить текст регулярками, а это боль и страдания. Модель без умения вызывать инструменты для агента почти бесполезна.

2. Надежность вызова: Модель должна стабильно вызывать правильный инструмент с правильными аргументами. Не иногда угадывать, а стабильно. Проверяется только тестами на ваших задачах.

3. Длина контекста: Агент накапливает историю: сообщения, ответы инструментов, рассуждения. 16К контекста хватит на 2–3 шага, дальше начнет забывать. Для нормальной работы нужно 256К+, а для сложных задач 1М+.

4. Стоимость: Агент делает 3–10 вызовов на задачу, как я и писал в 10м пункте. Если модель дорогая, счет вырастет быстро. Часто дешевле взять модель попроще, но с хорошим промптом.

5. Скорость: Пользователь ждет. Если один шаг занимает 10 секунд, а шагов десять, это две минуты. Не всегда критично, но для интерактива важно.

---

12. Когда агент точно нужен, а когда нет

Нужен:

• Задача требует действий во внешних системах, и заранее неизвестно, каких
• Число шагов варьируется от запроса к запросу
• Человек тратит на это часы, а ошибка не фатальна или проверяема

Не нужен:

• Это просто «дай ответ по документам», RAG решает проще и дешевле
• Пайплайн фиксированный: спарси, обработай, запиши, обычный код надежнее

И последнее: агент это усилитель. Он делает быстрее то, что у вас уже работает как процесс. Если процесс бредовый, агент просто сделает бред быстрее и дороже. Сначала разберитесь с задачей, потом давайте ее машине.