ИИ-операции и инструменты:
как решение модели становится действием
Шесть типовых ИИ-операций, выбор модели, вызов функций и работа с API
Прежде чем строить ИИ-агента, стоит понять, какую работу нужно поручить модели. Разберём шесть типовых ИИ-операций, выбор модели под задачу, вызов функций и описание инструментов. Затем посмотрим, как среда исполнения обращается к внешним системам через API и возвращает результат модели.
Шесть типовых ИИ-операций
Не каждой задаче нужен агент. Иногда достаточно одного вызова ИИ-модели.
Для проектирования полезно выделить шесть типовых ИИ-операций: извлечение информации, классификацию, суммаризацию, генерацию, выбор решения и планирование. Из договора можно извлечь данные, для обращения — определить категорию, длинный текст — сократить до выжимки. Модель также может подготовить ответ, выбрать решение по заданным критериям или составить план действий. Это удобная схема, а не исчерпывающая классификация всех ИИ-задач.
Такую операцию часто можно выполнить одним вызовом модели со структурированным результатом — например, тип обращения в заранее оговорённом поле.
{"тип": "жалоба"}
Модель подбирают под операцию
Для разных операций можно использовать разные модели.
Для простой классификации может подойти быстрая и недорогая модель. Для сложного анализа — модель с более высокими результатами на таких задачах. Выбор стоит проверять на примерах из своего процесса: более дорогая модель не обязательно окажется лучше для каждой операции. Выбирая модель, вы каждый раз ищете баланс между качеством, скоростью, стоимостью и возможностями.
качество · скорость · стоимость · возможности
Порядок проектирования поэтому такой: сначала определяем операцию, затем подбираем для неё достаточную модель — и только если системе нужно самой связывать несколько операций и выбирать следующие действия, появляется ИИ-агент.
Кто вызывает инструмент
Модель выбирает инструмент и его параметры. Сам вызов выполняет программа.
Чтобы агент мог действовать, разрешённые функции описывают заранее: что функция делает, когда её используют, какие параметры она принимает, какого они типа и обязательны ли. Так формируют описание инструмента и схему его параметров. Описание объясняет назначение функции, а схема задаёт структуру входных данных. Само обращение к CRM реализовано в коде инструмента.
Сам механизм называется вызовом функций и работает так: пользователь или процесс ставит задачу, а среда исполнения собирает промт и контекст и передаёт их модели. Модель может вернуть не ответ, а запрос на функцию — например, получить данные клиента по его почте.
Сама модель никуда не обращается. Среда исполнения проверяет вызов, программно обращается к CRM, получает результат, сохраняет его в состоянии и снова передаёт модели.
действует среда исполнения
Получив результат, модель решает, что делать дальше: вызвать другой инструмент, запросить уточнение или завершить задачу. Так получается цикл, в котором вызовы модели чередуются с выполнением инструментов. Он заканчивается, когда задача решена, достигнут лимит шагов, времени или затрат либо требуется помощь человека.
Вызов функций связывает вероятностное решение модели со строго определённым программным действием. Модель выбирает, что сделать, а как именно это делается, заранее задано в самом инструменте.
Понятное назначение инструмента
Для каждого инструмента важно ясно описать назначение, параметры и допустимые условия использования.
Надёжность агента зависит от качества его инструментов. Название «управлять CRM» само по себе мало объясняет: искать клиента, обновлять карточку и удалять запись — разные действия. Без понятного описания и схемы параметров модели сложнее выбрать подходящий вызов.
Например, можно описать отдельные действия: найти клиента, получить историю заказов, создать задачу, получить список транзакций. Для каждого указывают, какие данные передать, что вернётся и какие ограничения действуют. Такое описание помогает модели выбрать действие и заполнить параметры.
Одно общее название для разных действий с CRM.
Без описания действий и параметров непонятно, какой вызов нужен. Полномочия при этом определяются правами доступа и проверками в системе.
Найти клиента. Получить историю заказов. Создать задачу. Получить список транзакций.
Название и описание объясняют, что делает инструмент, когда его вызывать и какие данные передать.
Что агент решает сам
Пространство действий задаём мы. Какой инструмент вызвать и с какими аргументами, агент решает по ходу работы.
Во время работы агент решает две задачи. Сначала выбирает подходящий инструмент из разрешённых. Затем формирует его параметры на основе текущего контекста. Допустим, нужна история транзакций: агент берёт инструмент «получить список транзакций» и сам определяет клиента, период и другие необходимые параметры.
Поэтому у каждого инструмента должны быть понятное назначение, схема параметров и ограничения. Модель предлагает вызов, а система проверяет, допустим ли он для этого пользователя и этой задачи. Чем яснее описаны инструменты и правила их использования, тем проще контролировать работу агента.
API и внешние системы
Хотите строить ИИ-агентов — придётся понимать базовую механику API.
Инструменты агента часто взаимодействуют с внешними системами через API. Проще всего представить его как официанта между гостем и кухней. Вы выбираете действие из меню, передаёте заказ, кухня выполняет его и возвращает результат.
Технически всё похоже: программа-клиент отправляет запрос серверу и получает ответ. Роль меню играет документация — она говорит, какие действия доступны, какие параметры передать и что вернётся.
В HTTP-запросе указывают адрес, метод, заголовки, а при необходимости — параметры и тело. GET обычно используют для получения данных, POST — для отправки данных на обработку, в том числе создания записей, PATCH — для частичного изменения, DELETE — для удаления. Для доступа часто используют API-ключи или токены; OAuth позволяет получить доступ в рамках выданных разрешений. Конкретные правила описаны в документации сервиса.
Код ответа описывает результат обработки запроса: 2xx — успех, 3xx — перенаправления или использование сохранённого ответа, 4xx — ошибки на стороне запроса, 5xx — ошибки сервера. При этом 202 означает, что запрос принят, но операция ещё не завершена. Поэтому проверять нужно и код, и содержимое ответа, а для отложенных операций — их итоговый статус.
Один из способов узнавать о новых событиях — периодически запрашивать данные. Вебхук позволяет внешней системе самой отправить уведомление на заданный адрес, например при появлении заказа. Это сокращает потребность в постоянных проверках.
По сути, API — язык, через который решение агента превращается в реальное действие. Модель выбирает инструмент и аргументы, среда исполнения проверяет вызов, а сам вызов уходит во внешнюю систему через API.
Что важно запомнить
Шесть типовых операций
Извлечение, классификация, суммаризация, генерация, выбор решения и планирование — удобные группы для проектирования. Для отдельной операции часто достаточно одного вызова модели.
Достаточная модель под операцию
Модель выбирают под задачу и проверяют на примерах из своего процесса. Учитывают качество, скорость, стоимость и необходимые возможности.
Инструмент описывают схемой
Название и описание объясняют назначение инструмента. Схема задаёт параметры, их типы и обязательность. Сам вызов реализован в программе.
Модель не вызывает инструменты сама
Она возвращает запрос на функцию. Среда исполнения проверяет вызов, обращается к системе и передаёт результат обратно модели.
Понятное назначение инструмента
У инструмента «управлять CRM» назначение размыто, у «найти клиента» — понятно. Список задаём мы, инструмент и аргументы агент выбирает по контексту.
API превращает решение в действие
Запрос, метод, доступ и ответ — базовая механика взаимодействия. Через вебхук внешняя система может сама сообщать о событиях.
Чем понятнее их назначение и правила использования, тем проще контролировать работу агента.
Читайте также
Всё обучение
Как понять, что ИИ-агент действительно стал лучше
Инженерия обвязки: что делает ИИ-агента управляемым и надёжным
Инженерия контекста: как научить ИИ-агента понимать ситуацию
Почему идеальный промт не спасает плохого агента
Как данные движутся по ИИ-воркфлоу
Архитектура ИИ-агента: от LLM-функции до графа навыков
ИИ-платформа: как собрать агентов в единую систему
Где процессу нужен ИИ-агент, а где хватит правила
Что нужно, чтобы ИИ-автоматизация реально заработала
Как превратить человеческое мышление в работающего ИИ-агента
AI-First компания: какая работа остаётся человеку в мире ИИ-агентов
Как перестроить процесс под ИИ-агентов и не потерять контроль
Как найти точки автоматизации с максимальной отдачей
Как увидеть бизнес-процесс таким, какой он есть на самом деле
Как провести рентген бизнеса и извлечь знания экспертов
Как выбрать правильный процесс для автоматизации
От механизации до ИИ-агентов: как эволюционировала автоматизация
Бизнес как система процессов: как потоки данных создают ценность
AI-First-компания: новые роли и новая оргструктура
AgentOps: шесть шагов от идеи до работающего ИИ-агента
ИИ-стратегия: три уровня внедрения ИИ-агентов в бизнес
Готова ли ваша компания к ИИ-трансформации?
Три трансформации, которые полностью изменили бизнес
Где ИИ-агенты создают бизнесу максимум ценности
Пять уровней эволюции ИИ-агентов
Кто такой ИИ-агент и почему он меняет устройство компании
Что такое AI-First-компания и как она работает
Дальше — практика
Материал основан на третьей лекции курса по автоматизации бизнес-процессов с ИИ-агентами.
В следующей статье — проектирование воркфлоу: как данные движутся между шагами, зачем их преобразовывать, чем ветвление отличается от разветвления и объединения и как устроены циклы, пакеты, ожидание и подпроцессы.
От диагностики бизнеса
— до работающего агента.