Про ИИ-агентов в бизнесе написаны сотни манифестов и единицы кейсов. Это кейс. За полгода мы с нуля подготовили архитектуру b2b-компании к внедрению виртуальных сотрудников: построили полностью ИИ-автоматизированный пайплайн разработки для 1С, выполнили на нём 1100 подзадач доработки 1С и Битрикс24, спроектировали и вывели в прод первого виртуального сотрудника — финансового аналитика. Сейчас идёт третий этап: пилоты ассистента менеджера по продажам и виртуального закупщика ВЭД. Ниже — архитектура, этапы, цифры и главное: грабли, на которые мы наступили, чтобы вам не пришлось.
Это третья статья цикла. Первая — почему учётным системам не нужен интерфейс; вторая — что экономика агентов сделает с b2b-рынком.
Контекст Я CTO в b2b-компании: дистрибуция с внешнеэкономической деятельностью. Учётный контур классический: 1С:УТ 11.5 и 1С:Бухгалтерия, Битрикс24 как CRM и портал, десятки человек в бэкофисе, десятки тысяч номенклатур, ~28 тысяч контрагентов, документооборот через ЭДО, валютные контракты, склады, рейсы, WMS.
Цель была сформулирована не как «внедрить ИИ», а как оргструктура: виртуальные сотрудники — агенты, закрывающие роли целиком:
ассистент менеджера по продажам — остатки, долги и лимиты клиента, статусы заказов и отгрузок, черновики писем и документов — в чате, мгновенно; виртуальный аналитик — ответы на управленческие вопросы цифрами из живой базы: продажи, маржа, деньги, дебиторка; первым сделали финансовый профиль; виртуальный закупщик ВЭД — контроль валютных платежей по графикам контрактов, отслеживание поставок и ГТД, планирование закупок от остатков и оборачиваемости. Почему нельзя «просто подключить GPT к 1С», стало ясно в первую же неделю: грязные справочники, логика в модулях форм, регламенты в головах, у LLM нет инструментов к базе. Про то, почему учётная система в принципе устроена неудобно для агента, я подробно писал в первой статье цикла. Отсюда план: сначала полгода перестройки фундамента, потом агенты. Забегая вперёд — это оказалось самым важным решением проекта.
Этап 0 (месяцы 1–2): пайплайн разработки 1С на ИИ Чтобы перестроить учётный контур в разумные сроки, нужна способность дёшево и быстро вносить изменения. Мы построили конвейер, в котором разработку для 1С ведёт ИИ-агент, а человек ставит задачи и принимает результат.
Прямые коннекторы в живые системы (MCP):
метаданные — индекс по ~25 тысячам объектов конфигураций (УТ + БУХ), агент находит нужные регистры и реквизиты без «угадывания»; живая база 1С — выполнение запросов и кода в тестовой и рабочей базах: агент проверяет каждый написанный запрос на реальных данных до того, как тот попадёт в код; исходники расширения — структурированные операции над XML и модулями (создать объект, реквизит, форму, записать модуль) вместо ручной правки файлов; конфигуратор — автоматическая загрузка расширения в тестовую базу и выгрузка поставки; тест-клиент 1С — UI-автотесты: агент прогоняет сценарий на живой форме и сверяет результат с базой; Битрикс24 — REST: задачи, смарт-процессы, роботы, чаты. Дисциплина качества (quality gates), выстраданная практикой:
Каждый SDBL-запрос проверяется на живой базе. Линтер BSL ловит синтаксис, но не выдуманные метаданные. Прецедент: в одной задаче линтер сказал «всё ок», а прогон на базе нашёл три критических бага — несуществующий справочник, несуществующее поле табличной части и функцию, которая шесть лет молча возвращала пустой результат из-за проглоченного исключения. Верификация после каждой записи — целостность XML расширения проверяется автоматически, иначе кривой файл вешает конфигуратор. Адверсариальное ревью вторым ИИ — независимая модель получает бриф и diff и ищет проблемы; спорит с первой, а не поддакивает. Автотест после деплоя — сценарий на тест-клиенте плюс контрольный запрос-«оракул» в базу. Память проекта — каждая найденная грабля (несуществующая функция платформы, коварное поведение регистра, ограничение API) фиксируется в базе знаний и подмешивается агенту в контекст следующих задач. Через полгода это сотни записей — фактически «опыт сеньора», накопленный конвейером. Итоговый цикл: задача из Битрикса → анализ и план → код → линтер + проверка запросов на базе → ревью → автозагрузка в тест → UI-автотест → приёмка человеком → перенос в прод. Большая часть цикла проходит без участия человека.
Этапы 1–2 (месяцы 2–6): 1100 подзадач по семи контурам Дальше был вал работы, ради которого конвейер и строился. Сухая статистика за полгода: 1100 подзадач доработки и развития, 1182 коммита, 680 папок задач в репозитории. Ни одна команда классической разработки, которую я могу себе позволить, такой объём за полгода не вывезла бы — и в этом весь смысл: пайплайн изменил не скорость на проценты, а класс доступного объёма.
Что именно делалось — семь контуров:
-
Интеграционный слой 1С ↔ Битрикс24. Синхронизация справочников и пользователей, очереди уведомлений, смарт-процессы (акты сверки, авансовые, согласование контрагентов), роботы и cron-движок для автоматизаций, оповещения об оплатах клиентов в чаты менеджеров.
-
ВЭД-контур. Учёт факта и плана валютных платежей, графики платежей по контрактам, отчёты по оплатам ГТД, корректировки деклараций, загрузка банковских выписок, НДС по валютным документам, контроль порядка расчётов в договорах.
-
Продажи и взаиморасчёты. Процесс согласования отгрузок и кредитных лимитов (это один из самых больших блоков — только по нему больше десятка задач), акты сверки с выдачей PDF по HTTP-сервису, автозачёты авансов, контроль дебиторки с детализацией просрочки, рублёвые и валютные долги по договорам.
-
Документооборот. ЭДО-контур: УПД, автоадресация, авторассылка отгрузочных документов контрагентам с учётом контактных лиц заказа, ИИ-распознавание входящих сканов, реестр сверки скан-образов, печатные формы (доверенности, транспортные накладные, спецификации — 17+ задач).
-
Логистика и склад. Самый объёмный контур — 30+ задач только по рейсам: привязка водителей и транспорта, контроль веса, «светофоры» готовности заказов, синхронизация дат перемещений, стыковка с WMS, ордерная схема, серии и FEFO, опасные грузы (ДОПОГ).
-
Аналитика и отчётность. Маржинальность по клиентам/менеджерам/направлениям, сверка себестоимости УТ↔БУХ, АБС-анализ клиентов, оборачиваемость и неликвиды, доступность остатков, рентабельность по подразделениям.
-
Права и инфраструктура. Роли и профили доступа (пример: право изменения платёжек сузили с 211 пользователей до 23), HTTP-сервисы, COM-обмены между базами, событийный мониторинг журнала регистрации, тома хранения файлов.
Заметьте: в списке нет ни слова «ИИ». Это обычная, скучная автоматизация процессов — та самая перестройка бизнес-процессов и архитектуры, без которой агентам не на что опираться (почему её почти никто не делает и чем это заканчивается — во второй статье цикла). Агент не может контролировать согласование отгрузок, пока согласование живёт в устных договорённостях; мы сначала сделали процесс, потом он стал доступен агенту как данные.
Этап 3 (месяцы 6+): первый виртуальный сотрудник В июле собрали первого виртуального сотрудника — финансового аналитика — и провели его через приёмку как найм человека. Архитектура получилась такой:
Руководитель (чат Битрикс24, голос → расшифровка) │ Чат-мост: очередь входящих, файлы, транскрипция, единая точка исходящего форматирования │ Хаб-оркестратор (agentic loop): скилы ролей · песочница для расчётов · staging датасетов · планировщик (утренняя сводка) · генерация docx/pdf/графиков │ Коннектор 1С: readonly-профиль, мультибаза (тест/прод), нормализация грязных наименований на транспорте │ 1С:УТ (боевая) — реестр источников данных: 12 паспортизированных источников + серверные функции Ключевые решения, каждое из которых оплачено ошибкой:
Реестр источников данных вместо «LLM пишет SQL». В 1С появился регистр, где каждый источник — функция, шаблон запроса или отчёт — описан паспортом: параметры, примеры вызова и ответа, версия, особенности. Агент выбирает источник по паспорту и получает данные в едином конверте. Цифры считает код 1С, детерминированно; модель решает «что спросить» и «как интерпретировать». Результат на приёмках: ноль выдуманных цифр за все прогоны — не благодаря промптам, а потому что модели негде выдумывать.
Логика — из форм в API. Серверные функции (маржа по разрезам, деньги с валютной переоценкой, старение дебиторки/кредиторки, стоимость запасов) инкапсулируют все подводные камни: правильный источник себестоимости, канон «своих юрлиц», ключи аналитики. Интерфейсный отчёт и агент зовут один и тот же код — цифры совпадают копейка в копейку по построению.
Безопасность deny-by-default, четыре линии. Финансовые инструменты видны только пользователям из allowlist; финансовые скилы не выдаются посторонним; коннектор — readonly-профиль (мутирующие операции физически не опубликованы); отдельная учётка 1С «только чтение». Негативный тест приёмки: посторонний в чате получает ноль инструментов и ноль цифр. Для внешних контуров спроектирована псевдонимизация: модель видит «KA_00123», реальные наименования подставляются только на границе с человеком.
Приёмка как найм: golden-тесты и вердикты GO/NO-GO. Эталонные ответы посчитаны независимо от агента, плюс негативные сценарии (посторонний, «посчитай в уме» — обязан отказаться и посчитать кодом, недоступная база — обязан честно сказать). Путь нашего аналитика: 🟡 GO с ограничениями → 🔴 NO-GO на проде (нашли критику: остатки валют показывались без пересчёта — 137 млн вместо 211) → шесть итераций фиксов → 🟢 GO. Сейчас он в проде: отвечает на вопросы естественным языком, шлёт утреннюю сводку, делает факторный анализ маржи и честно отказывается, когда данных нет.
Уроки, оплаченные полугодом Структура сильнее прозы. Правило, записанное в промпт, модель рано или поздно перебьёт. Правило, зашитое в источник данных, код или схему, — нет. Всё важное мы переносили из инструкций в структуру: канон «своих юрлиц» — из текста скила в функцию; полноту выборки — из просьбы «не пропускай» в код источника. Грязная НСИ — системная угроза, а не неудобство. Позиция номенклатуры с 19 табуляциями в хвосте наименования стоила 4 млн потерянной выручки в аналитике агента. Дубли ИНН, два конкурирующих реестра «своих» компаний. Лечение — нормализация на транспорте (грязь не доезжает до модели) плюс мастер-справочники с алиасами, а не разовая чистка. База — расходник, истина — в git. Тестовую базу перезаливают из прода — и все доработки в ней гибнут. Выжили потому, что исходники и реестры живут в репозитории, восстановление — по ранбуку за 13 минут. Проверено внезапными учениями. Агент найдёт лазейку, которую вы задокументировали. Служебный флаг «разрешить полный прогон», честно описанный в паспорте источника, модель однажды прочитала и использовала. Гарды тоже должны быть структурными — паспорт читают все. Приёмку строить от первичных принципов, а не от шаблона проверяемого. Наш 🔴 NO-GO случился потому, что первые эталоны считались «по мотивам» тех же источников. Пересобрали golden-набор от принципов финдира — сразу нашли расхождение на 74 млн. Экономика агентов — это роутер моделей. Токены — реальная статья затрат. Классификация и маршрутизация — дешёвым моделям, типовые операции — средним, суждение и анализ — дорогим, массовые ночные прогоны — батчами. Плюс структурные экономии: агрегация на стороне 1С (не гонять 28 тысяч строк через контекст), расчёты в песочнице, бюджеты ходов/времени/токенов с честной деградацией («вот что успел, вот чего не хватило»). Что дальше: тираж ролей Дорожная карта третьего этапа — из проверенных кирпичей:
Ассистент менеджера по продажам. Все данные уже структурированы на этапах 1–2: лимиты, согласования, статусы отгрузок, взаиморасчёты. Роль = те же источники + скилы роли + канал в чате менеджера. Плюс approve-контур на действия (создать заявку, зарезервировать) — первые операции записи, каждая с подтверждением человеком. Виртуальный закупщик ВЭД. Ниша, по которой в рунете буквально нечего нагуглить. Контроль валютных платежей по графикам контрактов (контур готов на этапе 1), сверка поставок и ГТД, черновики платёжных заявок, мониторинг курсов и сроков. Это самый «денежный» агент: цена ошибки в валютном контракте несопоставима со стоимостью токенов. Среда управления агентами. Оргструктура (кто кому подчиняется, у кого какие бюджеты токенов), тикеты с трассировкой «зачем», approvals, аудит. Плюс ночной цикл самоулучшения: журнал инцидентов → разбор → патчи скилов и паспортов автоматически, правки кода — с утренним утверждением. Ожидания по эффективности формулирую осторожно, как цели пилотов, а не отчёт: ответ на управленческий вопрос — секунды вместо часов; типовые запросы к аналитике — 90% без человека; контроль платежей и поставок — непрерывный вместо выборочного; стоимость операции бэкофиса — на порядок ниже человеко-минут. Что уже не прогноз, а факт: объём изменений учётного контура ×10 за те же деньги — сам пайплайн разработки и есть первый «виртуальный сотрудник», окупивший всё остальное.
Вывод Полгода назад у нас была обычная 1С с обычным Битриксом и планы «внедрить ИИ». Сегодня — конвейер, который перестроил учётный контур (1100 подзадач), работающий в проде виртуальный финансовый аналитик и понятная технология тиража ролей. Главное, что я понял за это время: виртуальный сотрудник — это на 20% модель и на 80% архитектура вокруг неё. Данные, источники, права, приёмка, память. Модель можно поменять за вечер; архитектуру не купить — её можно только построить.
Если соберёте свой стек — начинайте не с агента, а с пайплайна изменений и чистки данных. Агент будет лишь настолько хорош, насколько хорош фундамент под ним.
Вопросы по архитектуре, коннекторам, приёмке — welcome в комментарии: расскажу детали, которые не влезли в статью. Что бы вы отдали виртуальному сотруднику первым — аналитику, продажи или закупки?
Примеры работы агента — datastaff.ru. Большинство не верит, что такие системы возможны уже сейчас, я понимаю, что статьёй я никого не смогу переубедить, я могу сделать демонстрацию в любое время, работающих уже сейчас решений.
ссылка на оригинал статьи https://habr.com/ru/articles/1068350/