Как я собирал AI-агентную команду для реального бизнеса, а не ассистента в чате

Немного оффтоп)

Большинство демо AI-агентов выглядят одинаково: есть чат, пользователь пишет задачу, модель красиво отвечает. Для презентации этого достаточно. Для реального бизнеса — нет.

В бизнесе задача редко заканчивается текстовым ответом.

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

• Нужно не просто «посмотреть сервер», а понять текущую конфигурацию, не сломать доступы, внести правку, проверить сервис и оставить след в документации.

• Нужно не просто «ответить клиенту», а понять контекст, границы полномочий и последствия действия.

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

  В этой статье расскажу, как я подходил к сборке AI-агентов для рабочих процессов: какие слои нужны, где агенты должен действовать сами, где останавливаться, зачем им память, почему статус «ok» ничего не доказывает и почему браузерная автоматизация иногда важнее API.

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

ИИ-ассистент и рабочий ИИ-агент решают разные задачи

ИИ-ассистент живет в таком цикле:

~text
пользователь написал -> модель ответила -> показали текст
~

ИИ-агент живет в другом цикле:

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

Разница принципиальная. В первом случае качество оценивается по ответу. Во втором — по завершенной задаче.

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

Именно поэтому агентную систему для бизнеса нельзя строить как «чат плюс промпт». Нужна система вокруг моделей.

Входной интерфейс может быть простым

В моем случае был выбран простой мессенджер. Это удобно: человек пишет так же, как писал бы сотруднику.

Например:

~text
сделай статью на таком-то сайте про качественный детейлинг в Москве
~

Для человека это короткая фраза. Для агента за ней стоит много решений:

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

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

Память — это дисциплина

Многие обсуждения памяти AI-агентов быстро уходят в embeddings, vector DB и knowledge graph. Это полезные инструменты, но в реальной эксплуатации часто важнее простой вопрос: где агент хранит решения, правила и уроки?

Например, агенты должны помнить:

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

Для этого не всегда нужна сложная база. Иногда достаточно Markdown-файлов и JSON-состояний, если есть правила:

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

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

Отдельно стоит codebase memory: индексатор кода, который знает функции, классы, вызовы, маршруты и зависимости. Это другой слой. Он помогает в больших кодовых базах, но не заменяет память о бизнес-процессах. Knowledge graph может подсказать, где вызывается метод. Но он не знает, что владельцу нельзя слать отчет с внутренними логами или что конкретный сайт публикуется через отдельный профиль браузера.

Правила важнее длинного промта

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

Правило должно быть:

— коротким;
— конкретным;
— привязанным к действию;
— проверяемым;
— записанным там, где агент его найдет.

Плохое правило:

~text
Будь аккуратен с публикациями.
~~~

Хорошее правило:

~~~text
Перед отчетом об успешной публикации проверь публичный URL, наличие заголовка, cover-изображения и отсутствие служебного мусора. Статус ok из админки не считать достаточным.
~~~

Еще пример:

~~~text
Не отправлять пользователю отчеты с raw JSON, путями локальных файлов, внутренними логами и tool dump. В ...-отчете по публикации должен быть только короткий человеческий статус: URL/ID, QA, блокер.
~

Такие правила скучнее промпт-инжиниринга, зато они работают ближе к инженерии.

У агента должны быть границы полномочий

AI-агент для бизнеса может делать разные типы действий:

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

Все это нельзя считать одинаковыми «командами».

Я делю действия по уровню риску:

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

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

Хороший рабочий агент не просто «умеет действовать». Он понимает, когда надо остановиться.

Роли помогают не превращать агентов в кашу

В реальном бизнесе задачи разнородные. Один и тот же сотрудник может попросить:

— написать SEO-статью;
— сгенерировать обложку;
— починить сервер;
— выложить материал в CMS;
— проверить cron;
— подготовить рекламную аудиторию;
— сделать конфиг WireGuard.

Если все это делает один универсальный агент без ролей, качество быстро уходит в ноль. Для текстов нужен редакторский подход. Для картинок — визуальный QA. Для инфраструктуры — аккуратность с сервисами, firewall и доступами. Для публикаций — знание конкретной CMS и финальная проверка.

Поэтому я сделал систему агентов через роли:

— редактор отвечает за текст;

— дизайнер отвечает за визуал;

— контент-менеджер размещает материал;

— сисадмин занимается инфраструктурой;

— программист пишет код;

— мелкие агенты общаются с клиентами;

— видеограф монтирует видео;

— консультанты составляют карты автоматизации;

— смм-щики ведут социальные сети;

— аналитики оценивают текущий результат и выстраивают план развития;

— основной агент координирует и проверяет результат.

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

Так меньше риска, что «текстовый» агент полезет чинить nginx, а «инфраструктурный» начнет писать продающий пост)))

Фоновые задачи — отдельный класс проблем

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

— ежедневная статья;

— проверка публикации;

— напоминание;

— мониторинг сайта;

— отчет;

— повторная попытка после ошибки.

Для этого нужен cron или похожий механизм. Но простого «запустить по расписанию» мало.

У фоновой задачи должны быть:

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

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

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

Браузерная автоматизация никуда не делась

В идеальном мире у каждого сервиса есть стабильный API, документация, webhooks и тестовый контур.

В реальном мире у малого и среднего бизнеса часто есть:

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

Поэтому агенту иногда приходится работать через браузер почти как человеку. Это не красиво, зато практично.

Но браузерная автоматизация требует гигиены:

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

Самая опасная ошибка здесь — принять состояние админки за состояние результата. В админке может быть сохранено поле cover, но на публичной странице картинка не отрисовалась. Или CMS сказала «успешно», но URL отдает 404. Для бизнеса это не успех.

QA должен быть частью выполнения, а не отдельной надеждой

Если агент пишет «готово», он должен иметь основание.

Для разных задач основание разное:

— файл существует и не пустой;
— тесты прошли;
— сервис отвечает;
— публичный URL открывается;
— изображение загружается и относится к теме;
— в статье нет raw Markdown, JSON или служебных фраз;
— сообщение отправлено именно в нужный чат;
— конфиг применился и handshake появился.

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

Примеры ложного успеха:

— модель сгенерировала текст, но файл не сохранен;
— картинка создана, но не загружена в статью;
— админка приняла форму, но публичная страница без cover;
— cron завершился ok, но отчет не отправлен;
— агент дошел до страницы, но не нажал нужную кнопку;
— VPN-конфиг создан, но peer не добавлен на сервере.

Минимальный QA часто можно сделать простыми средствами: HTTP-код, наличие текста, размер файла, grep по нежелательным фразам, проверка DOM, системный статус, smoke test. Не все требует отдельной LLM.

Отчеты должны быть человеческими

Одна из неожиданных проблем в агентных системах — отчеты.

Агенту легко вывалить пользователю все:

— внутренний анализ;
— JSON состояния;
— пути файлов;
— названия скриптов;
— куски логов;
— tool output;
— полные промты;
— служебные предупреждения.

Для программиста это иногда полезно. Для сотрудника в мессенджере — мусор.

Хороший отчет должен отвечать на вопрос пользователя:

~text
Что сделано?
Где результат?
Есть ли блокер?
Что нужно от меня?
~~~

Например:

~~~text

Статья сохранена в черновик: ID 12345. QA пройден: заголовок, cover и публичный предпросмотр на месте. Можно проверять.
~~~

Если есть ошибка:

~~~text
Не опубликовано: админка просит повторную авторизацию. Текст и картинка готовы, черновик не создан.
~

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

Почему просто создать агентов недостаточно

Когда появляется несколько агентов, возникает новая проблема: координация.

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

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

Поэтому multi-agent схема требует простых, но жестких договоренностей:

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

Иначе несколько агентов не ускоряют процесс, а создают распределенную неразбериху.

Что получилось как базовая архитектура

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

~text
Мессенджер / интерфейс
  -> основной агент
    -> память и правила
    -> инструменты: shell, browser, files, web, media
    -> роли / subagents
    -> cron / фоновые задачи
    -> QA-проверки
    -> короткий отчет пользователю
~

Важные элементы:

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

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

Какие выводы я сделал

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

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

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

Четвертый: QA — обязательная часть задачи. «Процесс завершился» не равно «результат готов».

Пятый: агенты должны уметь останавливаться. Публичные, destructive, финансовые и чувствительные действия требуют отдельной дисциплины.

Вывод

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

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

Именно это, на мой взгляд, отличает AI-агентов для реального бизнеса от ИИ-ассистентов)))

P.S.: Спасибо, что дочитали статью до конца. Делитесь вашими мыслями на этот счет, буду рад почитать и ответить. И спасибо компании XelaGroup, которая разрешила мне «приоткрыть их внутреннюю кухню» по схеме работы с ИИ-агентами.