ИИ-агенты и использование инструментов (пример)

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

От чата к действию

Чат-бот отвечает на вопросы. Агент решает задачи. Разница — в автономности: агенты сами решают, какие инструменты использовать, в каком порядке и как обрабатывать ошибки.

Рассмотрим разницу на практике. Вы спрашиваете чат-бота: «Какая погода в Токио?» Он может ответить на основе обучающих данных — которым месяцы или годы, и ответ почти наверняка будет неверным. Вы задаёте тот же вопрос агенту, и он вызывает API погоды, получает текущие данные и возвращает точный, актуальный ответ.

Чат-бот генерирует правдоподобный текст. Агент взаимодействует с миром.

Спектр автономности

Не все агенты одинаково автономны. Существует спектр:

1. Чат с инструментами — модель может вызывать инструменты, но только в прямом ответ на запросы пользователя. Один вызов за ход.
2. Многошаговые агенты — модель может цепочкой вызывать несколько инструментов для выполнения задачи, самостоятельно определяя последовательность.
3. Полностью автономные агенты — модель работает независимо в течение продолжительных периодов, принимая решения, обрабатывая ошибки и преследуя цели при минимальном контроле человека.

Большинство продакшен-систем сегодня находятся на уровнях 1-2. Полностью автономные агенты — активная область исследований со значительными нерешёнными проблемами безопасности.

Использование инструментов

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

Как работает использование инструментов

Механика проста:

1. Определение инструмента — вы описываете доступные инструменты модели, включая их имена, параметры и назначение. Обычно это предоставляется как структурированный JSON в системном промпте или через специальное поле API.
2. Решение — при обработке запроса пользователя модель решает, будет ли инструмент полезен. Если да, она генерирует вызов инструмента с соответствующими параметрами.
3. Выполнение — ваше приложение выполняет вызов (модель не выполняет его напрямую) и возвращает результат.
4. Интеграция — модель включает результат инструмента в свой ответ пользователю.

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

{
  "name": "search_documentation",
  "description": "Search the product documentation for relevant articles",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "The search query"
      },
      "max_results": {
        "type": "integer",
        "description": "Maximum number of results to return",
        "default": 5
      }
    },
    "required": ["query"]
  }
}

Модель видит это определение и знает, что может искать по документации. Когда пользователь задаёт вопрос о продукте, модель генерирует вызов вроде search_documentation(query="how to reset password"), ваша система выполняет поиск, а модель использует результаты для составления точного ответа.

Распространённые категории инструментов

Продакшен-агентные системы обычно предлагают инструменты нескольких категорий:

• Извлечение информации — веб-поиск, запросы к БД, чтение файлов, вызовы API
• Выполнение кода — запуск Python, JavaScript или shell-команд в песочнице
• Коммуникация — отправка email, постинг сообщений, создание тикетов
• Работа с файлами — создание, редактирование и организация файлов
• Системные операции — деплой кода, управление инфраструктурой, запуск CI-пайплайнов

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

Агентные циклы

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

Цикл на практике

Рассмотрим агента, которому поручено отладить падающий тест:

1. Планирование — «Сначала нужно прочитать файл теста, чтобы понять, что он проверяет»
2. Выполнение — вызывает read_file("tests/auth.test.ts")
3. Наблюдение — видит, что тест ожидает статус 200, но получает 401
4. Планирование — «Нужно проверить middleware авторизации, чтобы понять, что возвращает 401»
5. Выполнение — вызывает read_file("src/middleware/auth.ts")
6. Наблюдение — находит баг в логике проверки срока действия токена
7. Планирование — «Нужно исправить сравнение сроков»
8. Выполнение — вызывает edit_file(...) с исправлением
9. Наблюдение — подтверждает, что правка применена
10. Планирование — «Нужно запустить тест для проверки исправления»
11. Выполнение — вызывает run_command("pnpm test tests/auth.test.ts")
12. Наблюдение — тест проходит
13. Завершение — сообщает об исправлении пользователю

Каждый шаг включает рассуждение модели о текущем состоянии, принятие решения о дальнейших действиях и адаптацию на основе обнаруженного. Это принципиально отличается от линейного скрипта — агент справляется с неожиданными находками и меняет курс при необходимости.

Обработка ошибок в цикле

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

• Логику повторов — повтор при временных сбоях с экспоненциальной задержкой
• Альтернативные стратегии — если один подход не сработал, попробовать другой
• Изящную деградацию — если задачу нельзя выполнить полностью, выполнить максимум возможного и объяснить, что осталось
• Лимиты цикла — максимальное число итераций для предотвращения бесконечных циклов, когда агент застревает

Проектирование эффективных инструментов

Качество агентной системы сильно зависит от качества инструментов. Плохо спроектированные инструменты ведут к путанице агента и неверным результатам.

Принципы проектирования инструментов

• Понятные имена — search_users лучше, чем query_db_1. Модель использует имя для решения, когда вызывать инструмент.
• Описательные параметры — включайте описания для каждого параметра. Модель читает эти описания, чтобы определить, какие значения передать.
• Узкий фокус — каждый инструмент должен делать одно дело хорошо. read_file и write_file лучше, чем file_operations с параметром режима.
• Полезные ошибки — возвращайте понятные сообщения об ошибках, помогающие модели понять, что пошло не так и что попробовать вместо этого.
• Идемпотентность по возможности — инструменты, которые можно безопасно повторить, упрощают обработку ошибок.

Риски

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

Категории рисков

• Деструктивные действия — агент с доступом к файловой системе может удалить важные файлы. Агент с доступом к БД может удалить таблицы. Песочницы и границы прав необходимы.
• Утечка данных — агент, способный и читать конфиденциальные данные, и делать сетевые запросы, может непреднамеренно (или через prompt injection) передать информацию наружу.
• Неконтролируемые расходы — агент в цикле, вызывающий дорогие API, может быстро накопить значительные затраты. Бюджетные лимиты и ограничение частоты — практическая необходимость.
• Неверные действия, выполненные с уверенностью — агент может неправильно понять запрос и совершить необратимое действие. Для операций с высокими ставками всегда требуйте подтверждения человека.

Паттерны безопасности

Продакшен-агентные системы должны реализовывать несколько паттернов безопасности:

1. Минимальные привилегии — давайте агенту только инструменты, нужные для конкретной задачи, не более
2. Песочница — выполняйте код и файловые операции в изолированных средах
3. Шлюзы подтверждения — требуйте одобрения человека для деструктивных или необратимых действий
4. Журнал аудита — записывайте каждый вызов инструмента и его результат для проверки
5. Аварийное отключение — обеспечьте механизмы немедленной остановки работающего агента
6. Бюджетные лимиты — установите жёсткие ограничения на вызовы API, использование токенов и вычислительное время

Цель — не мешать агентам быть полезными, а обеспечить их полезность в чётко определённых границах.