Обычная LLM “просто отвечает текстом”. Агентная система — это когда ИИ не только пишет, но и делает действия: ищет в базе, вызывает API, создаёт задачу, проверяет результат и повторяет цикл. Для бизнеса это путь от “болталки” к автоматизации процессов: заявки, CRM, документы, поддержка, аналитика. Ниже — основные термины, которые помогут понимать, как устроены агенты и почему они иногда “тупят”, зависают или делают лишние действия.
Агент (Agent)
Агент — это ИИ, который умеет не только отвечать, но и выполнять шаги для достижения цели: планировать, вызывать инструменты, проверять результат и продолжать. По сути, агент — это “модель + логика управления”, где модель принимает решения, а система исполняет действия. Важно: агент — не магия, а сценарий с правилами, ограничениями и обработкой ошибок. Чем лучше прописан цикл работы агента, тем меньше неожиданных действий и тем выше стабильность.
- Зачем в бизнесе: автоматизировать цепочки задач (сбор данных → обработка → запись в CRM → ответ клиенту).
- Пример: агент получает заявку, уточняет детали, создаёт лид и ставит задачу менеджеру.
- Частая ошибка: ожидать, что агент сам “догадается”, какие шаги и где делать, без правил и контроля.
Инструмент (Tool)
Инструмент — это внешний “рычаг”, который агент может использовать: поиск по базе, вызов API, калькулятор, отправка в CRM, генерация файла. Инструменты превращают текстовый ИИ в практичный сервис, который влияет на процессы. Но каждый инструмент — это риск: неправильные параметры, неправильный контекст, доступы, ошибки сети. Поэтому инструменты всегда требуют ограничений, валидации входа и логирования.
- Зачем в бизнесе: чтобы ИИ не только писал, но и делал полезные действия в системах.
- Пример: “создай лид в CRM”, “найди пункт регламента”, “рассчитай стоимость”.
- Частая ошибка: давать агенту “слишком мощные” инструменты без ограничений и проверок.
Function Calling / Вызов функций
Function calling — это способ, когда модель не пишет “просто текст”, а возвращает структурированный вызов инструмента: какую функцию вызвать и с какими параметрами. Это снижает хаос: вместо “примерно так” система получает конкретные поля. В агентных системах function calling — база стабильности, потому что позволяет валидировать параметры до выполнения. Для бизнеса это критично: меньше ошибок, меньше ручного исправления, понятнее логирование.
- Зачем в бизнесе: безопасно и предсказуемо подключать CRM, базы, калькуляторы, сервисы.
- Пример: модель возвращает {tool: "createLead", name, phone, comment} вместо свободного текста.
- Частая ошибка: принимать любой текст как команду и выполнять без проверки структуры.
Оркестрация (Orchestration)
Оркестрация — это управление тем, какие компоненты и в каком порядке выполняются: поиск, отбор источников, генерация ответа, проверка, запись в систему. Можно сказать, это “дирижёр” вашего ИИ-конвейера. Оркестрация важна, потому что сама модель не гарантирует правильный порядок действий. В бизнесе оркестрация превращает хаотичные ответы в воспроизводимый процесс.
- Зачем в бизнесе: стабильный сценарий вместо “каждый раз по-разному”.
- Пример: сначала RAG → потом ответ → потом запись результата в CRM → потом лог.
- Частая ошибка: смешать всё в один запрос и получить нестабильные результаты.
Workflow / Процесс (сценарий)
Workflow — это заранее продуманная последовательность шагов: что делать при разных входных данных и результатах. В отличие от “одного промпта”, workflow описывает поведение системы на развилках: если данных нет — уточняем, если инструмент упал — повторяем, если риск — передаём человеку. В бизнесе workflow — это “операционный регламент” для ИИ. Он уменьшает сюрпризы и делает поддержку масштабируемой.
- Зачем в бизнесе: управлять поведением ИИ как процессом, а не как болтовнёй.
- Пример: “если клиент не указал товар — спросить 2 уточнения и не считать стоимость”.
- Частая ошибка: пытаться решить всё “одним идеальным промптом”.
Планировщик (Planner)
Планировщик — компонент, который разбивает цель на шаги: что сделать сначала, что потом, какие инструменты нужны. Планирование особенно полезно в длинных задачах: анализ документа, подготовка отчёта, сбор данных из нескольких систем. Хороший planner делает работу агента “разумной” и экономит токены. Плохой planner — источник бесконечных циклов и лишних действий.
- Зачем в бизнесе: выполнять сложные задачи последовательно и предсказуемо.
- Пример: “1) найти данные в базе 2) сверить 3) сформировать ответ 4) записать в CRM”.
- Частая ошибка: планировать слишком общо (“сделай всё”), без критериев завершения.
Исполнитель (Executor)
Executor — это часть системы, которая реально вызывает инструменты, обрабатывает ответы и возвращает результат агенту. Модель может “хотеть” вызвать инструмент, но исполняет это именно executor. Он отвечает за техническую надёжность: тайм-ауты, повторные попытки, валидацию параметров, ограничения доступа. В бизнесе executor — это ваш слой безопасности и стабильности.
- Зачем в бизнесе: безопасное выполнение действий в реальных системах.
- Пример: повторить запрос к CRM при временной ошибке и не создать дубль лида.
- Частая ошибка: доверять модели выполнение “как есть”, без валидации и защитных правил.
Agent Loop / Цикл агента
Цикл агента — это повторяющаяся схема: “подумал → сделал действие → посмотрел результат → продолжил/завершил”. Именно цикл делает агента агентом, а не просто чат-ботом. Без ограничений цикл может уйти в бесконечные попытки или делать лишние шаги. В бизнесе цикл должен быть контролируемым: лимит шагов, чёткие условия завершения и логирование.
- Зачем в бизнесе: доводить задачу до результата, а не бросать на полпути.
- Пример: агент ищет нужный пункт, если не нашёл — меняет запрос, но максимум 3 попытки.
- Частая ошибка: не ставить лимит шагов и ловить “вечные” зависания.
ReAct (Reason + Act)
ReAct — популярный паттерн, где агент чередует рассуждение и действие: сначала формирует следующий шаг, потом вызывает инструмент, потом опирается на результат. Это дисциплинирует работу: меньше фантазий, больше опоры на факты. В прикладных задачах ReAct помогает снизить галлюцинации, потому что модель чаще “проверяет” себя через инструменты. В бизнесе ReAct — хороший базовый стиль для агентных сценариев.
- Зачем в бизнесе: сделать агента более “деловым”: меньше воды, больше действий и проверок.
- Пример: “не уверен — сначала найди в базе знаний, потом отвечай”.
- Частая ошибка: разрешать агенту отвечать без проверки источников, когда источник есть.
Память агента (Memory)
Память — это способ хранить важные факты между шагами и диалогами: предпочтения, параметры клиента, историю решения. Важно: память должна быть управляемой, иначе агент начинает тащить в работу устаревшие или лишние сведения. В бизнесе память обычно делят на короткую (внутри диалога) и долговременную (в базе/профиле). Правильная память уменьшает повторные вопросы и ускоряет процессы.
- Зачем в бизнесе: меньше уточнений, быстрее обслуживание, единая история клиента.
- Пример: агент запомнил “клиент работает по безналу” и не спрашивает это снова.
- Частая ошибка: хранить “всё подряд” и получать ошибки из-за устаревшей информации.
Состояние (State)
State — это “текущее состояние задачи”: что уже сделано, что осталось, какие данные собраны, какие шаги дальше. Состояние нужно, чтобы агент не повторял одно и то же и мог продолжать после ошибок. В процессах типа “оформление заявки” state критичен: иначе вы получите дубли и путаницу. Для бизнеса state — это база надёжности и воспроизводимости.
- Зачем в бизнесе: устойчивость процесса и отсутствие дублей.
- Пример: status=awaiting_phone, status=lead_created, status=need_manager.
- Частая ошибка: не фиксировать состояние и “гонять по кругу” одни и те же вопросы.
Human-in-the-Loop (HITL) / Человек в контуре
HITL — это когда часть решений подтверждает человек: в спорных случаях, при низкой уверенности или при высоких рисках. Это нормальная практика: сначала ассистент помогает, потом постепенно увеличивают автономность. HITL снижает риск ошибок и даёт данные для улучшения системы. В бизнесе HITL — часто лучший путь к внедрению без “пожаров”.
- Зачем в бизнесе: безопасный запуск и контроль качества на старте.
- Пример: агент предлагает ответ, оператор подтверждает/правит, и это идёт в обучение/правила.
- Частая ошибка: либо сразу “полный автопилот”, либо вечная ручная работа без прогресса.
Escalation / Эскалация
Эскалация — передача задачи человеку или в другой процесс, когда ИИ не должен продолжать сам. Причины: нет данных, конфликт правил, высокий риск, инструмент недоступен. Эскалация — признак зрелости системы: лучше честно передать, чем сделать неправильное действие. В бизнесе эскалация снижает претензии и защищает репутацию.
- Зачем в бизнесе: управлять рисками и не допускать критических ошибок.
- Пример: “не найдено в базе → передать специалисту и приложить найденные фрагменты”.
- Частая ошибка: заставлять ИИ “ответить любой ценой”.
Валидация (Validation)
Валидация — это проверка входных данных и результата: корректность параметров, формат, обязательные поля, допустимые значения. В агентных системах валидация защищает от “кривых” вызовов инструментов и от мусора в CRM. В бизнесе это особенно важно для телефонов, сумм, дат, ИНН, адресов, кодов. Чем больше автоматизации, тем важнее валидация.
- Зачем в бизнесе: меньше ошибок в данных и меньше ручного исправления.
- Пример: телефон должен быть в формате, сумма — числом, обязательные поля — заполнены.
- Частая ошибка: принимать всё как есть и потом чистить базу руками.
Idempotency / Идемпотентность
Идемпотентность — свойство действия “не делать дубликаты”, если его повторили. В агентных системах повторы неизбежны: тайм-аут, повторная попытка, сбой сети. Если действие не идемпотентно, агент может создать 2–3 одинаковых лида или выставить счёт несколько раз. В бизнесе идемпотентность — это защита от дублей и финансовых ошибок.
- Зачем в бизнесе: безопасные ретраи без дублей и хаоса.
- Пример: “создать лид с ключом запроса”, чтобы повтор не создал новый.
- Частая ошибка: делать ретраи без защиты от повторного выполнения.
Retry / Повторная попытка
Retry — повтор выполнения при временной ошибке: сеть, лимит, кратковременная недоступность сервиса. Ретраи повышают надёжность, но могут увеличивать нагрузку и создавать дубли без идемпотентности. В бизнесе ретраи должны быть ограничены: сколько попыток, с какой паузой, в каких ошибках. И обязательно логировать — иначе дебаг превращается в гадание.
- Зачем в бизнесе: стабильность интеграций и меньше “упавших” операций.
- Пример: 3 попытки с паузой 1–2–4 секунды при временной ошибке API.
- Частая ошибка: бесконечные ретраи, которые забивают систему и создают лавину запросов.
Timeout / Тайм-аут
Тайм-аут — максимальное время ожидания ответа от инструмента или внешнего сервиса. Без тайм-аутов агент может зависнуть и “держать” процесс, особенно при пиковых нагрузках. Тайм-ауты важны для UX: лучше быстро признать проблему и эскалировать, чем молчать минутами. В бизнесе тайм-ауты — обязательная гигиена любой автоматизации.
- Зачем в бизнесе: чтобы процессы не зависали и не ломали SLA.
- Пример: если CRM не отвечает 5 секунд — повторить или передать в очередь.
- Частая ошибка: ждать бесконечно и терять заявки/клиентов из-за зависаний.
Rate Limit / Лимиты запросов
Лимиты запросов — ограничения на частоту обращений к API или модели. Их нарушают чаще всего агенты, потому что они могут делать много действий в цикле. В бизнесе лимиты нужно учитывать заранее: очереди, батчи, кэширование, ограничения на шаги. Иначе система будет “падать” именно тогда, когда она нужна больше всего — в пике.
- Зачем в бизнесе: стабильная работа при росте нагрузки.
- Пример: ограничить агента: не больше 10 вызовов инструмента на одну задачу.
- Частая ошибка: не контролировать частоту вызовов и ловить блокировки API.
Логирование и аудит (Logging & Audit)
Логи — это запись того, что агент делал: какие входы видел, какие инструменты вызывал, что получил, что ответил. Аудит — возможность восстановить цепочку действий и понять, где произошла ошибка. Без логов агентные системы невозможно нормально поддерживать: вы не знаете, почему он сделал именно так. В бизнесе логирование — это и про качество, и про безопасность, и про разбор инцидентов.
- Зачем в бизнесе: дебаг, контроль качества, расследование ошибок и претензий.
- Пример: хранить “запрос → найденные источники → действие → результат → ответ”.
- Частая ошибка: логировать только финальный ответ, теряя действия и причины.
Права доступа (Permissions)
Permissions — ограничения, что агенту можно читать и что можно менять. Это критично: ассистент для клиента не должен видеть внутренние документы, а внутренний агент не должен иметь права “удалять всё”. В агентных системах права задают на уровне инструментов и данных, а не “на уровне текста”. Для бизнеса это базовая безопасность: меньше утечек и меньше фатальных действий.
- Зачем в бизнесе: защита данных и предотвращение опасных операций.
- Пример: агент может создавать лид, но не может удалять сделки или выгружать базу клиентов.
- Частая ошибка: давать слишком широкие права “чтобы работало”, а потом тушить риски.
Если подтверждаешь — следующий раздел сделаю “Безопасность ИИ и риски внедрения” в том же формате (H2-термины, 3–4 предложения, буллиты, без лишних блоков).
