Локальный ИИ-агент без интернета: как мы собрали помощника инженера на T-Lite и MCP внутри периметра заказчика

Заказчик встретил нас в переговорке словами: «Ребята, всё круто, но наружу — ни байта». За соседней дверью сидела служба безопасности, за ней — режимный отдел. Никакого облака, никакого GigaChat в чужом контуре, никакого VPN до внешнего провайдера. Только их собственная стойка, их сеть, их правила. А задача при этом обычная: сменному инженеру нужен помощник, который за пару секунд найдёт нужный пункт регламента, подскажет параметры допуска и покажет, где в 1С висит нужная деталь. Классическая работа с ИИ-агентами, только без единого запроса в интернет.

Так у нас появился проект, который мы теперь любим показывать всем, кто спрашивает, как сделать ИИ-агента, живущего целиком на железе заказчика. Ниже — история, как мы этого добились, где споткнулись и почему не пожалели.

Почему облако отпало сразу

Сначала мы честно предложили привычный сценарий: GigaChat Pro в приватном сегменте, наш backend рядом, 152-ФЗ прикрыт, всё чинно. Заказчик выслушал и покачал головой. Дело было не в законе — им бы хватило любого сертифицированного контура. Дело было в том, что часть документации имеет собственный гриф, и наружу этот трафик не должен идти вообще. Даже до сертифицированного российского провайдера. Даже по выделенке.

Мы задумались. Локальный ИИ-агент — это красивая фраза в презентации, но за ней стоит цепочка неприятных вопросов. Какая модель влезет в их железо. Как её обслуживать. Что делать, если она начнёт нести ерунду. И главное — будет ли инженеру от этого помощника хоть какая-то польза, или он через неделю снова полезет спрашивать у соседа по цеху.

Первый подход: «возьмём модель побольше»

Первая версия была наивной. У заказчика в стойке нашлась одна карта на 48 гигабайт памяти, и мы решили, что этого хватит на модель класса Qwen 72B в квантованном виде. Развернули, попробовали, приуныли.

Модель отвечала неплохо, но одна карточка вытягивала запрос по десятку секунд, а два инженера подряд её уже клали. Регламенты она обобщала слишком вольно: путала пункты, придумывала номера приложений, а иногда выдавала параметры, которых в документе не было в принципе. Для помощника, к которому ходят с вопросом «какой момент затяжки на этом узле», такое поведение — приговор. Один неверный ответ, и весь проект можно закрывать.

Мы отступили и пересобрали подход. Не «возьмём модель побольше», а «возьмём модель поменьше и построим вокруг неё правильную обвязку».

Второй подход: T-Lite и MCP-сервер как основа

Взяли T-Lite от Т-Технологий — российскую модель, которая честно работает на паре карт попроще, отлично держит русский язык и заточена под инструкции. К ней прикрутили небольшую собственную обвязку и MCP-сервер, который стал единственным способом агента добраться до внутренних систем.

Логика простая: сама модель ничего не «знает» про регламенты. Она умеет только рассуждать и звать инструменты. А инструменты — это MCP-сервер, который живёт на том же сервере и умеет искать по внутренней базе документов, лезть в 1С через штатный HTTP-сервис и подтягивать чертежи из архива. Никаких сюрпризов: если модель говорит «момент затяжки такой-то», значит, она получила это из инструмента, а инструмент — из настоящего документа. Мы даже прокидываем в ответ ссылку на конкретный пункт, чтобы инженер мог перепроверить своими глазами.

Такой AI ИИ-агент оказался куда полезнее большой модели без обвязки. Он реже фантазирует, отвечает быстрее и признаётся, когда не знает, — потому что промпт заставляет его сначала звать инструмент, а уже потом формулировать ответ.

Что помог сделать свежий MCP

Первая версия жила на старой спецификации MCP, и мы честно намучились с сессиями. У инженеров смена короткая, вопросы часто разовые: спросил, получил, забыл. А сервер держал на каждого пользователя контекст, копил его и потихоньку деградировал.

Летний релиз спецификации MCP со stateless-режимом снял с нас эту головную боль. Теперь каждый запрос — самостоятельный, роутинг решается по заголовкам, результаты кэшируются на стороне сервера. Для локального агента это подарок: не надо больше городить хитрое хранилище сессий на редких HDD, не надо думать, что будет, если один инженер уйдёт на обед, а его контекст протухнет. Плюс новая авторизация оказалась заметно строже, а для режимного объекта это не мелочь.

Тот же протокол, кстати, здорово упростил и добавление новых инструментов. Появилась задача — «а можно, чтобы агент ещё и график дежурств смотрел» — мы поднимаем маленький отдельный MCP-модуль, регистрируем его в общем шлюзе, и агент уже видит новый инструмент. Никакого передеплоя основной модели, никаких простоев.

Где грабли лежали особенно больно

Первые пару недель мы каждый день ловили какую-нибудь новую беду.

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

Второй болью стал поиск. Внутренний архив у заказчика — это гремучая смесь из PDF-регламентов, сканов с распознаванием разной степени свежести и «живых» файлов в 1С. Классический RAG на pgvector работал средне: похожие по смыслу пункты часто оказывались из другого документа, и агент их радостно смешивал. Мы отказались от идеи, что поиск обязателен для каждого запроса, и переложили решение на саму модель — пусть звала инструмент поиска, только когда действительно нужно, а не превентивно на каждый чих. Это соответствует общему тренду: retrieval как один из инструментов агента, а не обязательная стадия. И, что важно, это сильно снизило нагрузку на GPU — модель перестала делать лишние проходы.

Третья проблема была почти комической. Инженеры писали агенту так, будто пишут коллеге в мессенджер: «слушай а вот этот узел на 12й позиции, чё там с моментом». Модель на T-Lite такое парсила через раз. Мы добавили лёгкий шаг нормализации на входе — маленькую вспомогательную модель, которая переводит вопрос в нормальный технический язык, — и попадание в справочник сразу подросло.

Что изменилось у инженеров

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

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

Что мы вынесли для себя

Как сделать ИИ-агента, который живёт в закрытом контуре и приносит пользу? Три вещи, которые для нас теперь стали правилом.

Не гнаться за размером модели. Небольшая российская модель с хорошей обвязкой обгоняет большую без неё почти на любой корпоративной задаче. И меньше ест ресурсов.

Строить всё вокруг MCP. Даже если сегодня инструмент один, завтра их будет пять, и вы будете рады, что не привязали агента к конкретной интеграции жёстко. Особенно с новой спецификацией — она снимает много старых проблем.

Заставлять агента говорить «не знаю». Локальный ИИ-агент, который признаётся в неведении, полезнее большой облачной модели, которая уверенно врёт. На производстве это разница между «инженер перепроверил» и «завод остановили».

А вопрос напоследок — для тех, кто ещё сомневается. Если у вас есть данные, которые вы бы не хотели показывать даже своему провайдеру связи, — может, пора перестать откладывать и посмотреть, что реально влезает в вашу собственную стойку? Ответ может приятно удивить.

Похожие статьи

• Курс по ИИ-агентам для оператора: чему мы учим команду заказчика после запуска
• Один большой промпт превратился в систему ИИ-агентов: история, где мы перестали чинить и начали делить
• Кодекс ИИ-агента в продакшене: правила, которые мы выписали после нескольких дорогих ошибок
• ИИ-агент для учётной системы «Гермес»: как мы построили платформу ИИ-агентов вокруг легаси-ERP