Архитектура ИИ-агентов: из чего реально состоит работающий агент для бизнеса
Архитектура ИИ-агентов — то, что бизнес пропускает, когда покупает подписку на модный чат-бот и ждёт, что заказы начнут обрабатываться сами. Через месяц обычно приходит один из двух результатов. Первый: бот вежливо беседует и ничего не делает. Второй хуже: агент делает слишком много — отменяет заказы, правит суммы, пишет клиентам то, что писать не стоило.
Причина в обоих случаях одна. Никто не спроектировал память, инструменты и контроль. Просто «подключили ИИ» и стали ждать чуда.
Нейросеть без архитектуры — это стажёр с доступом к кассе и без начальника.
Чат-бот и агент: в чём разница
Чат-бот отвечает на реплику и забывает разговор. Всё.
Агент устроен иначе. Он разбирает запрос, решает, что делать, вызывает внешний инструмент — скажем, API учётной системы, — смотрит на результат и уже по нему выбирает следующий шаг. По сути, это система вокруг языковой модели: данные, инструменты, правила, контроль.
Забавно, что модель внутри может быть одна и та же. Одна и та же нейросеть бывает и болтливым ботом, и рабочим агентом. Разница — в обвязке. Покупая «самую умную модель», вы покупаете двигатель. Колёса, руль и тормоза придётся делать отдельно.
Пять деталей, без которых агент не поедет
Минимальный набор — модель, системные инструкции, память, инструменты, планирование. Плюс оркестратор, который всем этим дирижирует и пишет журнал.
| Блок | Что делает | Что будет, если его забыть |
|---|---|---|
| Модель (LLM) | Понимает задачу, строит план, пишет ответ | Без рамок «додумывает» факты и даже инструменты |
| Память | Держит контекст задачи и историю | Агент переспрашивает то, что ему сказали минуту назад |
| Инструменты | Вызывает API, базу, почту, расчёты | Агент только рассказывает, что «надо бы сделать» |
| Планирование | Режет сложное на шаги и проверяет каждый | Пытается решить всё одним махом и промахивается в деталях |
| Оркестратор и журнал | Управляет циклом, ловит ошибки, логирует | После сбоя никто не понимает, что произошло |
Пропустили строку — получили конкретную болезнь из правой колонки. Это не теория, это диагноз.
Модель: гениальный собеседник с амнезией
Языковая модель — мозг агента. Только у этого мозга нет собственной долгой памяти между обращениями. Сама по себе модель прошлые разговоры не помнит. Окно контекста переполнилось — старое вылетает.
Это не дефект конкретного поставщика. Так устроены большие языковые модели вообще. И если в проекте звучит фраза «модель умная, сама всё запомнит», ошибка архитектуры уже заложена. В первый же день.
Память: что держать под рукой, а что — в архиве
Рабочему агенту нужны два вида памяти. Краткосрочная — контекст текущей задачи и последние реплики. Долгосрочная — то, что пригодится потом: предпочтения клиента, решения по прошлым обращениям, накопленный опыт.
Без такого разделения вы ловите одну из двух крайностей. Либо агент тащит в каждый запрос всю историю переписки за год и начинает путаться в трёх соснах. Либо помнит ровно одно сообщение и в пятый раз спрашивает у клиента номер заказа. Клиент, к слову, на пятый раз уже не отвечает. Он уходит.
Инструменты: руки агента
Инструменты — это действия во внешнем мире: вызвать API, сходить в базу, отправить письмо, запустить расчёт. Механизм вызова функций (tool calling, function calling) позволяет агенту реально нажимать кнопки, а не писать сочинение «заказ необходимо обработать».
Вот здесь и рвётся ожидание. Компания думает, что купила автоматизацию заказов. А купила собеседника без рук. Никаких подключений к складу или учёту нет, значит, агент физически ничего изменить не может. Его текст читает человек и делает всё вручную. Как раньше. Только теперь ещё и за подписку.
MCP: единый разъём для инструментов
Model Context Protocol, MCP, — открытый стандарт подключения ИИ к внешним данным и инструментам. Раньше каждая интеграция агента с CRM, базой или учётной программой писалась с нуля и в другой проект не переносилась. Дорого и одноразово.
MCP задаёт общий формат: как описать инструмент, как агенту его обнаружить, как обмениваться данными. Подключать новые системы становится проще, а главное — вы не прирастаете к одному поставщику навсегда.
Интеграция, которую нельзя перенести, — это не актив. Это ипотека.
Планирование: подумай, сделай, проверь
Один из ходовых паттернов называется ReAct: рассуждение → действие → наблюдение. Агент формулирует промежуточную мысль, вызывает инструмент, смотрит на результат и только потом решает, что дальше.
Зачем такие церемонии? Возьмите задачу «принять заказ, проверить остаток, подтвердить клиенту срок». Три шага, три системы. Если модель пытается ответить одним махом, ошибка на втором шаге гарантирована. Хуже — её никто не заметит до звонка недовольного покупателя.
Оркестрация: когда агентов несколько
Оркестратор управляет потоком: что делать на следующем шаге, куда передать результат, что делать при ошибке. Пока задача простая, хватает одного агента. Когда процесс сквозной — от заявки до отчёта, — в ход идут схемы с несколькими агентами.
- Последовательная: агенты передают работу по цепочке в заданном порядке.
- Параллельная: несколько агентов разбирают одну задачу одновременно и независимо.
- Иерархическая: старший агент раздаёт подзадачи младшим и собирает итог.
Мультиагентная система на пальцах
Мультиагентная система — команда узких специалистов вместо одного «универсального гения». Первый агент классифицирует обращение. Второй ищет ответ в базе знаний. Третий собирает итоговый ответ. Оркестратор следит, чтобы эстафетная палочка не потерялась.
Это не усложнение ради красивой схемы на слайде. В комплексных процессах распределение ролей снижает число ошибок по сравнению с попыткой заставить одну модель делать всё сразу. Вы же не просите бухгалтера заодно чинить сервер. Хотя, признаюсь, видел и такое.
Права и человек в контуре: ремни безопасности
Самая важная деталь — вовсе не технологическая. Агент получает минимальные права, ровно под свою задачу. Не «как у менеджера». Не «на всякий случай пошире».
На критичных шагах — платёж, отмена заказа, юридически значимый документ — нужен режим human-in-the-loop. Агент останавливается и передаёт решение человеку.
А теперь жёстко. Подрядчик, который выдаёт ИИ-агенту права администратора CRM, потому что «так быстрее настроить», должен сам объяснять вашим клиентам, куда делись их заказы. Это не смелое внедрение инноваций. Это халатность с красивой презентацией. Агент с широкими правами — это открытая дверь для несанкционированного доступа и действий, которых никто не заказывал. И когда он ошибётся (а он ошибётся, вопрос только когда), отвечать будете вы, а не подрядчик и не нейросеть.
ИИ не несёт материальной ответственности. Поэтому давать ему больше прав, чем стажёру, — странная идея.
Журнал действий: бортовой самописец агента
Когда что-то пошло не так, первый вопрос всегда один: «А почему он так сделал?» Без журнала ответа нет. Есть только версии, обиды и совещание на полтора часа.
Нормальный журнал агента фиксирует каждый шаг: какой запрос пришёл, что модель решила, какой инструмент вызвала, с какими параметрами, что получила в ответ. По такой записи сбой разбирается за минуты. Видно, где агент неправильно понял клиента, где инструмент вернул ошибку, а где виноват кривой справочник в самой CRM.
Ещё одна польза журнала — спокойствие юристов и бухгалтерии. Когда агент трогает деньги или документы, любое действие должно быть объяснимо задним числом. «Нейросеть так решила» — не объяснение. Это признание, что за системой никто не смотрел.
Пилот: начинайте с одного процесса
Самая частая ошибка запуска — желание автоматизировать всё и сразу. Продажи, поддержку, закупки, документооборот. К пятнице.
Я предлагаю обратное. Берём один процесс с понятным входом и выходом — например, приём типовых заявок. Даём агенту узкий набор инструментов. Две-три недели он работает под присмотром: каждое значимое действие подтверждает человек, журнал читается ежедневно. Видим, где агент ошибается, правим инструкции и права. И только потом расширяем зону ответственности.
Скучно? Зато дёшево. Ошибка пилота стоит один исправленный заказ. Ошибка «большого запуска» стоит недели разбора и пару ушедших клиентов.
Сценарий: агент с правами менеджера
Компания подключает агента к CRM. Задача: обновлять статусы заказов, выставлять счета, отправлять подтверждения. Формулировка в ТЗ — «пусть всё делает сам». Права выдали как у обычного менеджера, включая правку сумм и отмену заказов.
Клиент пишет: «Отмените этот пункт в заказе». Фраза двусмысленная. Агент понимает её по-своему и отменяет заказ целиком. Подтверждения человеком нет. Ограничений нет. Менеджер узнаёт обо всём из звонка — громкого, на повышенных тонах.
Что бы спасло? Две вещи. Агенту не нужна была отмена целого заказа. А любая отмена должна была уходить человеку на подтверждение. Десять минут настройки против потерянного клиента.
Сценарий: подписка есть, автоматизации нет
Руководитель небольшой фирмы оплачивает облачный ИИ-сервис и настраивает бота на типовые вопросы. Про сроки доставки бот отвечает бойко — эти сведения лежат в инструкциях. А вот проверить наличие на складе, поменять статус заказа или оформить возврат он не может. Ни одного инструмента. Ни капли памяти о прошлых обращениях клиента.
Итог через месяц: деньги за подписку списаны, сотрудники делают всё руками и вдобавок читают переписку бота, чтобы понять, что он уже наобещал. Автоматизация наоборот.
Что делаем мы и чем это отличается
Типичный ИТ-подрядчик продаёт подключение к готовому боту и закрывает задачу словами «ИИ внедрён». Работает ли это как автоматизация — дальше ваши проблемы. Дешёвый облачный сервис вообще продаёт универсальную коробку. Ваш склад, ваш регламент согласования платежей и ваши права доступа ему неинтересны.
Мы в АйТи Фреш идём от процесса:
- описываем, что агент должен помнить в диалоге и между обращениями;
- составляем список конкретных инструментов и права на каждый — по минимуму;
- размечаем шаги, где решение принимает человек;
- настраиваем журнал действий, чтобы любой сбой разбирался по шагам, а не гаданием;
- берём на обслуживание инфраструктуру, на которой всё работает, — от сервера до интеграций.
Обслуживание сервера у нас стоит от 7 000 ₽ в месяц. Агент, за которым кто-то реально присматривает, перестаёт быть чёрным ящиком.
Чек-лист перед запуском агента
- Описана ли память: что агент держит в рамках диалога, что — между обращениями.
- Перечислены ли инструменты поимённо, или в ТЗ стоит «пусть сам разберётся».
- Урезаны ли права до минимально нужных.
- Отмечены ли действия, требующие подтверждения человеком: платежи, отмены, договоры.
- Пишется ли журнал действий агента.
- Понимает ли команда, что заказала — бота без рук или агента с инструментами.
- Для многошаговых процессов: рассматривали ли вариант с несколькими узкими агентами.
Пора проектировать, а не надеяться
Пробовали «подключить ИИ» и получили либо бездельника, либо агента, который натворил дел? Напишите нам в АйТи Фреш. Спроектируем архитектуру под вашу задачу: инструменты, память, права, контроль на критичных шагах. Чтобы агент работал на процесс, а не создавал вам новую должность — «человек, который проверяет за ботом».
Частые вопросы
Чем агент отличается от чат-бота поддержки?
Бот пишет текст. Агент вызывает инструменты и меняет данные в ваших системах. Для этого ему нужны отдельно спроектированные инструменты, память и ограничение прав — у обычного бота этого нет.
Почему агент «забывает», что клиент только что сказал?
У языковой модели нет встроенной долгой памяти. Если архитектура не предусматривает внешнего хранения контекста, сведения теряются сразу после обращения.
Нужен ли MCP маленькой компании?
Для одного простого сценария — необязательно. Если агент будет расти и подключаться к нескольким системам, открытый стандарт избавит от переписывания интеграций каждый раз.
Один агент или несколько?
Однотипная задача — один агент с нужными инструментами. Сквозной процесс с разными подзадачами — несколько узких агентов под оркестратором.
Можно ли доверить агенту всё без человека?
Рутину с низким риском — можно. Платежи, отмены заказов, договоры — только с подтверждением человека. Без исключений.
Мы уже купили бота, а автоматизации нет. С чего начать?
Проверьте две вещи: подключены ли инструменты к вашим системам и есть ли у бота память между обращениями. Чаще всего проблема именно здесь, а не в модели.


