Виртуальные сотрудники в b2b: как мы полгода готовили 1С и Битрикс24 к мультиагентной системе

Про ИИ-агентов в бизнесе написаны сотни манифестов и единицы кейсов. Это кейс. За полгода мы с нуля подготовили архитектуру 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. Интеграционный слой 1С ↔ Битрикс24. Синхронизация справочников и пользователей, очереди уведомлений, смарт-процессы (акты сверки, авансовые, согласование контрагентов), роботы и cron-движок для автоматизаций, оповещения об оплатах клиентов в чаты менеджеров.

2. ВЭД-контур. Учёт факта и плана валютных платежей, графики платежей по контрактам, отчёты по оплатам ГТД, корректировки деклараций, загрузка банковских выписок, НДС по валютным документам, контроль порядка расчётов в договорах.

3. Продажи и взаиморасчёты. Процесс согласования отгрузок и кредитных лимитов (это один из самых больших блоков — только по нему больше десятка задач), акты сверки с выдачей PDF по HTTP-сервису, автозачёты авансов, контроль дебиторки с детализацией просрочки, рублёвые и валютные долги по договорам.

4. Документооборот. ЭДО-контур: УПД, автоадресация, авторассылка отгрузочных документов контрагентам с учётом контактных лиц заказа, ИИ-распознавание входящих сканов, реестр сверки скан-образов, печатные формы (доверенности, транспортные накладные, спецификации — 17+ задач).

5. Логистика и склад. Самый объёмный контур — 30+ задач только по рейсам: привязка водителей и транспорта, контроль веса, «светофоры» готовности заказов, синхронизация дат перемещений, стыковка с WMS, ордерная схема, серии и FEFO, опасные грузы (ДОПОГ).

6. Аналитика и отчётность. Маржинальность по клиентам/менеджерам/направлениям, сверка себестоимости УТ↔БУХ, АБС-анализ клиентов, оборачиваемость и неликвиды, доступность остатков, рентабельность по подразделениям.

7. Права и инфраструктура. Роли и профили доступа (пример: право изменения платёжек сузили с 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. Эталонные ответы посчитаны независимо от агента, плюс негативные сценарии (посторонний, «посчитай в уме» — обязан отказаться и посчитать кодом, недоступная база — обязан честно сказать). Путь нашего аналитика: