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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

```json
{
  "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, использование токенов и вычислительное время

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