Что такое AI-агент и как его классифицировать

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

В лабораторных экспериментах я столкнулся с той же проблемой. Короткие названия ролей помогали ориентироваться внутри конкретной системы. Но за её пределами эти слова уже не объясняли, что именно делает компонент, кто управляет его ходом и какие действия ему разрешены.

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

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

Из чего состоит AI-система

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

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

Вызов модели (model call) — одна операция: система отправляет модели входные данные и получает ответ. Модель может классифицировать текст, извлечь факты или подготовить черновик. Один такой вызов ещё не делает компонент агентом.

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

Сценарий обработки (workflow) организует маршрут. Например: принять файл, извлечь текст, вызвать модель, проверить формат, сохранить результат. Если переходы между шагами определены кодом или правилами, сценарий остаётся заданным, даже когда внутри него несколько моделей и инструментов.

Конвейер обработки (pipeline) описывает устройство маршрута данных. Его стадии могут идти последовательно, параллельно, по ветвям или с повторениями. В разных продуктах слова workflow и pipeline используют по-разному, поэтому важнее не название, а способ управления переходами.

Скрипт (script) — форма реализации. Скрипт может выполнить одну операцию, служить инструментом или запустить весь простой сценарий. По имени файла нельзя определить, есть ли внутри агентный выбор.

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

В какой момент появляется агент

Рабочее определение для этой статьи такое:

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

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

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

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

Степень свободы тоже бывает разной:

код полностью задаёт последовательность;
модель выбирает в одной точке из ограниченного набора действий;
модель строит и пересматривает многошаговый план в пределах лимитов.

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

Инструменты, память и фоновая работа расширяют возможности агента, но не определяют его сами по себе. Чат с десятью инструментами может идти по жёсткому сценарию. Компонент без долговременной памяти может оставаться агентом, если модель выбирает следующий ход.

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

Зачем классифицировать агентов

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

Один компонент отвечает на вопрос пользователя и ничего не сохраняет. Другой работает сутками, меняет план, вызывает внешние сервисы и действует от имени организации. Называть оба просто «автономными агентами» недостаточно.

Классификация нужна не ради правильных ярлыков. Она превращает расплывчатое название в проверяемый архитектурный контракт.

По профилю агента можно решить:

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

Google Cloud Architecture Center предлагает начинать выбор архитектуры с характеристик задачи, требований к задержке, стоимости и участия человека. Для предсказуемых и хорошо структурированных задач Google рекомендует сначала рассматривать неагентные решения. Это практическое следствие классификации: она помогает не строить агента там, где дополнительная свобода не окупает сложность.

Классификация в два шага

Универсального списка видов AI-агентов нет. Термины зависят от архитектуры, продукта и команды. Поэтому классификация начинается не с выбора красивой роли.

Шаг 1. Определить, что именно описывается

Сначала нужно разложить систему на части и связи:

где находится интерфейс;
какие операции выполняет модель;
какие функции доступны как инструменты;
какой маршрут задан кодом;
где модели делегирован выбор следующего действия.

Так становится видна единица анализа. Система целиком может быть рабочим процессом, внутри которого находится один агентный компонент. Один и тот же экран может запускать и обычный сценарий, и агента. Нельзя переносить свойства одной части на всю систему.

Шаг 2. Построить профиль каждого агента

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

Именно сочетание характеристик даёт классификацию. Одна метка этого не показывает.

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

По каким признакам различаются агенты

1. Задача, результат и завершение

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

Рядом указываются критерий принятия и условия остановки. Цикл должен завершаться не только после успеха, но и при ошибке, достижении лимита или передаче человеку.

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

2. Функции и роли

Агенты различаются прежде всего тем, что они делают:

ищут и собирают информацию;
извлекают и преобразуют данные;
создают материал;
проверяют качество и соответствие требованиям;
выбирают или пересматривают план;
распределяют подзадачи;
наблюдают за состоянием системы;
представляют результат человеку.

Для сочетаний функций внутри конкретной системы можно вводить локальные короткие имена. Критик обычно проверяет результат по заданным критериям. Координатор или оркестратор направляет задачи исполнителям и управляет передачами; в некоторых архитектурах он также агрегирует или синтезирует результаты. Наблюдатель следит за состоянием или качеством. Аналитик собирает данные и формирует вывод.

Такие названия не взяты из единого стандарта. Google, например, описывает паттерны проверки и критики, а также координатора, но конкретные полномочия компонентов определяет сама система. Один критик только пишет замечания. Другой может вернуть материал на доработку. Третий сам исправляет результат. Роль совпадает, а поведение и риски — нет.

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

3. Запуск и режим выполнения

Работу агента может запустить:

прямой запрос человека;
вызов другого компонента;
внешнее событие;
задача в очереди;
расписание;
условие в данных или состоянии системы.

Отдельно описывается режим: синхронный ответ, фоновая задача, пакетная обработка или постоянно работающий сервис.

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

4. Управление ходом

Здесь фиксируется, кто выбирает следующий шаг и насколько широк этот выбор:

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

Отдельно внутри этого поля фиксируется композиция: один агент, агент внутри заданного рабочего процесса или несколько агентов. Для многоагентной системы дополнительно указывается, кто управляет передачами: код, отдельный агент-координатор или сами агенты. Композиция не является более высоким «классом разумности»: многоагентная схема может быть жёстче одиночного агента, если все передачи заданы кодом.

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

5. Полномочия и субъект действия

Для каждого агента нужно указать, что ему разрешено:

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

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

Наконец, нужен субъект: агент действует от имени пользователя, отдельной сервисной роли или общей учётной записи? Одинаковый инструмент даёт разные последствия в зависимости от используемых полномочий.

6. Участие человека

Фраза «человек контролирует агента» слишком общая. Нужна конкретная точка решения:

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

В Microsoft Agent Framework участие человека в контуре (human-in-the-loop) реализуется через остановку процесса, запрос внешнего решения и продолжение после ответа. Но само наличие такого механизма ещё не отвечает, кто принимает решение и по какому условию.

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

7. Состояние и изменения

Компонент может:

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

Память не равна обучению. Запись факта, изменение инструкции и обновление модели — разные механизмы с разными рисками. В классификации нужно указывать, что именно сохраняется, кто может это изменить и как данные удаляются.

8. Оценка и эксплуатационные ограничения

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

доля принятых результатов;
частота ошибок и передач человеку;
качество выбранных действий;
стоимость и задержка;
число повторных попыток;
нарушения полномочий и других ограничений.

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

Как применить классификацию

Практический разбор системы можно провести в восемь шагов.

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

На выходе получаются два артефакта: карта системы и профиль агента. Карта показывает связи и границы. Профиль объясняет поведение конкретного компонента.

Пример: обработка документа

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

Появление файла запускает заданный сценарий. Конвертер извлекает текст. Модель предлагает тему и метаданные. Код проверяет формат и правила. Готовый результат передаётся специалисту, отвечающему за итоговую классификацию.

Разложим систему:

форма загрузки — интерфейс;
извлечение текста — инструмент;
предложение темы — вызов модели;
последовательность шагов — заданный сценарий;
проверка формата — код.

Агента пока нет. Каждый следующий переход определён заранее.

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

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

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

Результат классификации примера

Сначала карта отделяет сценарий от агентной ветки. Затем профиль описывает найденного агента.

Компактный результат выглядит так:

объект: агентный компонент внутри сценария обработки документов

задача:
  разобрать неоднозначную классификацию
  результат: тема и метаданные без существенных противоречий
  принятие: формат и правила успешно проверены
  остановка: принятый результат / передача человеку / ошибка / исчерпанный лимит

функции:
  искать контекст
  оценивать достаточность данных
  готовить тему и метаданные

запуск:
  неоднозначный случай из заданного сценария
  отдельный вызов внутри текущего процесса

управление ходом:
  модель выбирает поиск / повтор / завершение / передачу человеку
  поиск и повтор продолжают работу
  лимит и ошибка принудительно останавливают её

полномочия:
  субъект действия: отдельная ограниченная сервисная роль
  читать документ и разрешённые открытые источники
  записывать только внутренний черновик
  не публиковать и не удалять данные

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

состояние:
  контекст только внутри одной задачи
  после завершения контекст не сохраняется
  без автоматического изменения инструкций и модели

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

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

Что классификация изменила в примере

Без классификации вся система могла бы называться «агентом для документов». После разбора становятся видны конкретные решения.

Обычные документы не требуют агента. Они проходят дешёвый и проверяемый маршрут.

Модель получает свободу только в неоднозначной ветке и только среди разрешённых действий. Это ограничивает стоимость и упрощает проверку поведения.

Выбор следующего шага не даёт права публиковать или менять исходные данные. Для агента достаточно чтения и внутреннего черновика.

Участие человека перестаёт быть общим обещанием. У него есть две понятные задачи: посмотреть готовый результат и разобрать случай, который система не завершила сама.

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

Слово «агент» полезно как начало разговора, но недостаточно как описание системы. Сначала нужно найти точку делегированного выбора. Затем — раскрыть задачу, функции, запуск, управление ходом, полномочия, участие человека, состояние и оценку. Только после этого название роли начинает что-то значить.

Источники

Anthropic, Building effective agents, 19 декабря 2024 года.
Google Cloud Architecture Center, Choose a design pattern for your agentic AI system, последняя проверка — 28 мая 2026 года.
Microsoft, Microsoft Agent Framework Workflows.
Microsoft Azure Architecture Center, AI Agent Orchestration Patterns.
Microsoft, Human-in-the-loop (HITL).

Короткие апдейты и разборы — в Telegram-канале Mind & Mesh: @takeshi_ku.