Как собрать управляемый агентный стек

Гость выпуска — Михаил, директор департамента внутренней платформы разработки в cloud.ru; там её называют не IDP, а PDP, платформой для разработки продукта, и в такой формулировке фокус чуть смещается. Сама платформа отчасти агрегирует собственные сервисы компании. Александр замечает, что у облачного провайдера продукты инженерны по природе, поэтому разница между классическим IDP и их PDP невелика. Дальше Михаил объясняет, почему вопрос «пилить своё или брать чужое» ложный: он возникает сразу на двух уровнях. У компании это уровень экосистемы — цена ошибки, персональные данные, секреты и личная ответственность руководителя за правила безопасности, которые выстраивались годами. У разработчика вопрос локальный: этот инструмент задачу решает, а тот нет, и завтра Claude Code могут отнять. Ответ, считает Михаил, не в выборе стороны, а в разделении труда: простую суммаризацию или письма незачем отдавать самой дорогой модели.

Александр раскладывает стек на пять частей. Обвязка, или харнес, крутит агентский цикл и подаёт контекст; модель без обвязки остаётся в режиме request-response; инструменты дают руки — без них агент умный, но ничего не узнает и не сделает; идентичность Михаил просил упомянуть ещё в анонсе, чтобы люди и агенты не смешивались; границы удерживают агента в рамках. Прежние расспросы экспертов Александр сравнивает с ощупыванием слона: каждый описывает свою часть, а картинка не складывается. Каждую ось можно закрыть самому или взять готовой: обвязку написать, взять открытую или Codex, который, по его словам, кажется, открыт; модель — закрытую провайдерскую, открытых весов у себя или у регионального провайдера; инструменты — MCP от облачной CRM или свои адаптеры к он-премному «монстру двадцатилетней давности». Отсюда и ложные дихотомии: open source — не локальный инференс, локальная модель — не гарантия безопасности, внутренний MCP, сделанный «как бог послал», открывает агенту всё, а внешний API при нормальном контракте не означает утечки.

Отдельная линия — почему обвязка важнее выбора модели. Михаил объясняет: Claude Code видит только репозиторий, не знает правил разработки, связей между микросервисами и бизнес-ограничений, а недостающее додумывает сам. Пример из практики: увидев автотесты, агент начинает подстраиваться под них — попросишь 80% покрытия, ровно их и сгенерирует; когда тестирование выносят за границу его видимости и прогоняют после, результат становится лучше. Александр называет это переобучением на инструкции. Но и ставка на свой харнес рискованна: за рубежом, по словам Александра, команды держат платформу тонкой и обвязку не изобретают, потому что через квартал-полгода выходит новая модель и харнес из ускорителя превращается в ограничитель. Михаил соглашается: обвязка, написанная ради оптимизации, обесценивается вместе с релизом. Сложность уезжает к провайдеру: в день записи Александр отправил задачу в режим глубокого исследования, стая субагентов копала два часа, пятичасовая квота сгорела, а отчёта он так и не получил.

Практический центр тяжести — два шлюза. Модельный, LLM gateway, стоит между обвязкой и моделями и в продвинутом варианте сам решает по типу задачи, куда её отправить, как авторежим в Cursor; на нём же ловят утечку секретов и персональных данных. Инструментальный отвечает за второй путь: в какие тулы и MCP агенту разрешено ходить и живёт ли он в песочнице. У Михаила это уже инженерная задача: поставили стандартный forward-прокси, который анализирует весь трафик и маскирует секреты и персональные данные. Разбираясь, как Claude Code работает под капотом, они увидели, что он залезает в игнорируемые файлы и через время вспоминает пароль непонятно откуда. Просто не передавать данные нельзя — теряется ценность обработки, поэтому их маскируют и демаскируют, и всё упирается в скорость. Полнота фильтра неидеальна: работают с пилотной группой, вручную просматривают трафик и правят регулярки, вышли, по прикидке Михаила, примерно на 99%, а анализ через LLM всегда долгий, поэтому подбирают лёгкие модели, которые хорошо находят. Александр добавляет, что проектирование такого шлюза стало одной из задач в его будущей книге по system design.

Восемь конфигураций Александр раскладывает от самой жёсткой к самой мягкой. Первая — автономный air-gapped стек без интернета, весь контур ваш. Вторая — своя обвязка и корпоративный модельный шлюз, но топовая модель по внешнему API: наружу отдан один блок. Третья — готовый открытый клиент поверх своей серверной модели или локальной на домашней железяке; так Александр иногда крутит агентские прототипы дома. Четвёртая — вендорский кодинг-агент вроде Claude Code плюс собственный инструментальный шлюз с MCP во внутреннюю платформу; так, по его наблюдениям, идут многие зарубежные компании, подписав контракт. Пятая — полный SaaS для стартапа или петпроекта. Шестая — мультимодельный роутер с классификатором, который сам решает, что уходит локально, что к региональному провайдеру, а что к внешней топовой модели. Седьмая — планирование сильной внешней моделью и исполнение по плану моделью попроще внутри: наружу уходит метаинформация, а не приватные данные, и выходит дешевле. Восьмая — личный стек с MCP к почте и диску, которым, признаёт Михаил, на масштабе начинают решать рабочие задачи, и это тяжело даже детектировать.

Последние минуты — про модель угроз. Михаил напоминает, что она у каждого своя и строится от поверхности атаки и ценности данных: у SPA исходники и так уезжают в бандлы, а ради уникального алгоритма, на котором держится продукт, можно решить работать вообще без агентов; он вспоминает и спор с безопасниками про слабые сертификаты на машинах CDN, раздававших публичные данные. Александр проходит по красным стрелкам схемы: недоверенный репозиторий, который вы просите агента проанализировать; секреты между обвязкой и моделью; инъекция в письме, после которой агент вместо сводки пересылает почту наружу; слишком широкие права, когда инструмент видит не «Михаила, которому разрешили прочитать табличку для дашборда», а Михаила целиком, способного дропнуть таблицу. Михаил отвечает, что новые MCP у них сначала проходят allowlist и одобрение безопасников, а Александр добавляет двенадцать границ из лонгрида: песочница ОС, запрет внешнего трафика, минимальные привилегии, on-behalf-of. Внедрять всё сразу из-за FOMO он не советует, а в финале зовёт Михаила вернуться и разобрать отдельно одну из подтем — например, LLM gateway.