Почему мы этим занимаемся
В свои продукты мы внедрили различных агентов и ассистентов, которые помогают работать с документами и чатами. У нас много агентских систем, которые мы разрабатываем сами и используем в работе. Сейчас у нас SDLC в сочетании с агентами: разработчики взаимодействуют с агентами в процессе работы.
Как сейчас предпочитает работать обычный пользователь? Ему уже недостаточно просто искать в Google — он хочет получить готовый ответ на свой запрос, не занимаясь поиском самостоятельно.
Текущая ситуация в компании
Как это выглядит у нас сейчас? Мы не ограничиваем сотрудников, они используют различных агентов, и всё это выглядит несистемно. Многие, кто переходит от классической разработки (написание кода вручную) к работе с агентами, сталкиваются с тем же — процесс кажется хаотичным, потому что нет единого подхода и паттерна.
Новый проект
С марта я занимаюсь разработкой нового проекта. Это решение, которое работает в браузере: слева окно ассистента, справа окно предпросмотра — результат вашей работы.
Как сейчас действуют маркетологи и другие специалисты, когда им нужно быстро создать сайт — не типовой, как на Tilda, а что-то, чего на Tilda сделать не получится?
В процессе разработки я понял, что действительно могу создать целый проект, практически ничего не настраивая вручную, буквально с телефона. Агент, если корректно формулировать запросы, самостоятельно создаёт результат. Он необходим для того, чтобы закрыть последний этап до публикации.
В классическом случае агент создаёт качественный сайт, но встаёт вопрос: как разместить его в облаке, как опубликовать в интернете? Вы, специалисты, знаете, как это сделать. Но мы говорим о пользователях, которые просто хотят получить результат. Раньше нужно было обращаться к разработчикам, искать подрядчика. С такими системами вы формулируете задачу, получаете результат, нажимаете кнопку — и всё публикуется. Вам не нужно думать о том, как поднять сервер, привязать домен и так далее.
Знакомство с PDLC
Изучив это направление глубже, я захотел разобраться подробнее. Мне понравилась сама идея.
Расскажу, что это такое. Это следующий шаг после SDLC. Можно сказать, что PDLC построен поверх SDLC. Расшифровывается как Product Development Life Cycle. Когда вы мыслите уже не программным обеспечением (SDLC — это Software Development Life Cycle), а продуктом. Вам не нужно думать о коде.
Количество строк кода — результат работы разработчика — вместе с AI растёт нелинейно, очень быстро. Компании это радует, и они планируют внедрять такой подход. Была проделана большая работа: написан обширный документ с описанием фреймворка. На момент подготовки презентации документ уже обновился — я работал по прежней версии, а перед выступлением увидел новую.
Почему стоит заниматься этим сейчас
Технологическое отставание неизбежно возникнет, если компания не внедряет AI вообще или делает это несистемно. Как я показал: все работают с агентами, но единой системы нет. На первый взгляд неплохо, но в итоге это приведёт к значительному отставанию. Если мы сейчас не займёмся этим — будем сильно отставать.
Разумеется, подход рассчитан на масштаб крупной корпорации, мы меньше. Но это не отменяет действия этих принципов для нас.
Как меняется работа
Петля намерений
Сразу отмечу: это не про сокращение штата. Возможно, останавливается его рост, что тоже положительно.
Петля намерений — это область творчества человека. Для чего человек подходит лучше всего? Придумывать. Рутинную работу всегда можно делегировать.
У нас есть разработчик. Теперь он не просто разработчик — неважно, какой у него стек. Он может быть продакт-менеджером, тестировщиком, кем угодно. Он формирует намерение. Ему приходит задача что-то сделать — и это намерение становится заданием для агента.
Продуктовый инженер теперь не пишет код. Он пишет спецификацию. Многие, например бэкенд-разработчики, и так работают со спецификациями — у них всё проходит через список задач. Для них мало что меняется. Пишем спецификацию, отдаём на согласование двум людям. Они делают это с помощью агента, но всё равно проверяют результат самостоятельно. Если спецификация недостаточно качественная — возвращаем на доработку, затем передаём дальше. На этом работа человека завершается.
Петля реализации
Далее начинается вторая петля — петля реализации. Здесь работают автоматика и агенты. Это закрытая система, набор сервисов, который принимает на вход намерение и реализует его. Человек в этот процесс не вмешивается — только собирает метрики.
Здесь появляется термин IDP (это тоже описано в документе). Что делает IDP? Он принимает намерения, проводит их валидацию по корпоративным правилам. Потому что человек может сформулировать что-то некорректное, двое других это одобрят, а в спецификации будет написано, например: «при публикации разрушить весь продакшн».
IDP — Внутренняя платформа для разработчиков. Здесь происходит автоматическая проверка — тоже может выполняться агентом, реализовать можно по-разному. Это гарантирует безопасность спецификации. Затем начинает работать кодинговый агент, включается наш SDLC-процесс, где есть Reviewer — но у нас ревьюер тоже агент. Здесь возникает цикл, который повторяется, пока намерение не будет выполнено.
Если в ходе выполнения у группы агентов возникает вопрос, мы возвращаем его человеку — значит, в спецификации есть проблема. По идее, этого быть не должно, потому что на стадии проверки мы должны были всё урегулировать. Но такую возможность необходимо предусмотреть.
Понятие Harness
Всё это составляет большой Harness. Кто знает значение этого термина? Полагаю, в этом году это будет одно из ключевых слов. Harness — это то, что окружает вашу LLM-модель. У кодингового агента это инструменты для записи файлов, загрузки данных из сети и подобного. Harness должен быть достаточно большим, чтобы LLM-модель как можно меньше выполняла задач самостоятельно.
Задача LLM-модели — быть оркестратором. Harness должен быть больше самой модели. Что это означает? Сейчас важна экономика токенов: чем меньше токенов мы потратили, тем лучше. Нужно создать достаточно много инструментов и автоматизаций для LLM, чтобы она просто указывала Harness: «Вызови это, сделай то, выполни ещё что-то». Чем больше инструментов, тем выше степень автоматизации и тем меньше расход токенов.
Компактные команды
Когда появляется продуктовый инженер, встаёт вопрос: что делать с командой дальше? Возьмём обычную Scrum-команду. В документе Сбера это 10–15 человек, в компаниях поменьше — до 10 человек. Стандартная Scrum-команда — 7 плюс-минус 3 человека.
Мы видим, что люди никуда не исчезают — они распределяются на небольшие команды, готовые самостоятельно реализовывать продуктовые фичи. Агенты работают, а люди составляют спецификации.
Внедрение: с чего начать
Чтобы реализовать всё описанное, сначала нужно создать IDP. Он должен закрывать всё, что не делает человек. Сначала мы пишем сами, а затем работает IDP.
Работа со знаниями организации
Чтобы приступить к его созданию, нужно разобраться со знаниями в организации. Это самое важное и самое сложное. Это необходимо сделать, если у вас есть SDLC и вы хотите добавить туда агентов.
Вам нужен . Сейчас он есть у многих, но зачастую в компании не один MCP-сервер, а несколько: база знаний, Git и прочее. Вы подключаете их все к своей среде разработки, к Cursor, и этих серверов становится слишком много — это создаёт проблему. Большое количество точек входа в знания — проблема для организации.
Знание организации — это всё: метрики с продакшна (например, из Prometheus), Git-коммиты, продуктовые метрики, даже переписка в мессенджерах. Их нужно объединить в единый MCP-сервер, чтобы любой сотрудник мог его подключить. В будущем мы будем подключать это к агенту.
Нам нужен единый узел авторизации для предоставления доступа ко всем остальным сервисам. Здесь для примера указаны: Git, база знаний, мессенджеры, Grafana, Kubernetes. Всё это нужно объединить в единый MCP-сервер, чтобы управлять доступом к информации и предоставлять его сотрудникам избирательно.
Проблема с большим количеством инструментов
Проблема в следующем: мы подключаем к кодинговому агенту множество инструментов, все доступные в MCP. Все знают, что такое MCP?
Все эти инструменты суммируются и заполняют контекст модели. Каждый инструмент описывает определённые действия. Например, «получить документы из базы знаний» — и у него есть обязательное описание: «этот инструмент нужен для получения документов из базы знаний». LLM видит это и выполняет. Но так мы заполним весь контекст огромным количеством инструментов и потратим слишком много токенов, а нам необходимо их экономить.
Поэтому нужен единый MCP-сервер, который агрегирует инструменты и передаёт в LLM информацию об их наличии, предлагая запросить нужное. То есть теперь LLM формирует намерения для MCP-сервера — что именно она хочет сделать.
Например, LLM хочет выполнить git push, git commit. Она обращается к MCP-серверу (Gateway) с запросом: «Мне нужна работа с Git». MCP Gateway подбирает нужные инструменты, возвращает их, и мы тратим значительно меньше токенов. Так мы экономим и при этом предоставляем достаточно информации.
Готовое решение
Что делает Context Forge? Он всё агрегирует, обеспечивает единую авторизацию для ваших агентов или для вас лично. И распределяет это по отдельным виртуальным MCP-серверам, которые можно подключить — один или несколько.
Единственный недостаток этого решения — оно не умеет сжимать контекст. При создании виртуального сервера оно просто предоставляет доступ, а количество токенов остаётся прежним. Но можно написать к нему плагин для сжатия текста.
Как происходит сжатие? Есть множество методов. Я пока остановился на самом очевидном и простом: Gateway содержит Discovery-сервис, который предоставляет LLM всего три инструмента — поиск утилиты, её получение и вызов. И вместо передачи тысячи эндпоинтов LLM знает, что может найти нужный инструмент в MCP и сэкономить токены.
Всё это мы внедряем прямо сейчас на базе MCP Forge, и оно уже в целом работает.
Кодинговый агент и изоляция
Далее должен появиться кодинговый агент. Он должен работать в изолированной среде. Это не то, что разработчики запускают на своём компьютере. Это запускается на серверах, в облаках, чтобы разработчик отправил спецификацию, закрыл ноутбук и отправился отдыхать (образно говоря — конечно, сразу так сделать никто не позволит).
Оркестратор должен уметь запускать небольшие виртуальные машины или контейнеры, в которых работает кодинговый агент. В этих контейнерах он может выполнять любые действия. Как известно, агент может случайно повредить операционную систему. Оркестратор нужен, чтобы не повредить ваш компьютер и не причинить ущерба инфраструктуре. Если один из контейнеров выйдет из строя (агент сам себе что-то повредит) — оркестратор его удалит, заново поднимет и оповестит о том, что контейнер был перезапущен и требуется вмешательство. Но в целом это должно работать автоматически.
Теперь IDP выглядит так: есть система авторизации, MCP и Task-оркестратор. В целом уже можно ставить задачу, и система будет её выполнять.
Выбор кодингового агента
Следующий шаг — выбрать кодингового агента. Мы находимся в непростых условиях, и я не могу позволить компании, которую собираюсь полностью перевести на агентскую разработку, остаться ни с чем, если вдруг зарубежные сервисы станут недоступны.
Мы не будем использовать ни Cursor, ни Claude, ни другие подобные решения. Мы возьмём — это опенсорсный кодинговый агент, он отлично работает. Я много его проверял и тестировал в своём проекте. К нему будем подключать LLM. Мы создадим контейнер с необходимыми утилитами и клиентом, который будет принимать и выполнять задачи. Это будет наш кодинговый агент.В принципе, неважно, какого агента вы используете, потому что чем лучше его Harness, тем менее важна модель под капотом.
Встраивание в SDLC-процесс
Далее мы всё это оркестрируем. В IDP есть оркестратор — алгоритмическая утилита, а не LLM, которая принимает задачи, запускает контейнер и передаёт агенту. Агент выполняет работу, подключается агент-ревьюер, всё проверяется и возвращается в оркестратор. Он алгоритмически принимает решение о перезапуске процесса, если ревьюер выявил проблемы. Эти проблемы передаются кодинговому агенту, и он их исправляет. Это одна линия цикла (синяя).
Когда мы считаем, что агент выполнил задачу, оркестратор передаёт её дальше — запускается Eval, и мы тестируем результат. Мы стараемся минимально использовать LLM на этих этапах, чтобы экономить токены. Почти всё можно реализовать на веб-хуках и автоматизациях — здесь LLM не нужна. Если возникает вопрос — возвращаемся к человеку. Если вопросов нет — считаем намерение выполненным, возвращаемся к человеку, и он обязательно проверяет результат. Потому что именно человек несёт ответственность за итоговый результат — так же, как раньше, когда работал вручную.
Выбор модели: токен-роутер
Далее — следующая задача. Мы выбрали OpenCode. Какую модель использовать? Откуда её взять?
В непростых условиях мы должны сохранять гибкость. Поэтому нужно использовать роутер запросов. Мы уже реализовали у себя токен-роутер. Есть готовые решения, например LiteLLM. Мы взяли за основу другое решение и доработали его.
Суть в следующем: вы подключаете всё, что связано с AI, к единому токен-роутеру. Указываете доступные модели — например, модель кодинг-агента, модель ревьюера — это доступ ко всем облачным сервисам. На роутере вы настраиваете, что кодинговый агент по возможности обращается, например, к Anthropic. Но если он недоступен, мы переключаемся на российские шлюзы (all-MLM, iProxy и подобные). Если и они недоступны — переключаемся на более дорогие Яндекс и Cloud.ru с развёрнутыми DeepSeek, Qwen и подобными. Если у вас есть локальный GPU (у нас там работают Whisper и другие модели) — можно переключаться на них.
Здесь происходит расчёт стоимости токенов, количества запросов, распределение по проектам — какой проект потребляет больше токенов. Это становится дополнительным знанием и учётом расхода токенов. Даже если мы остановили рост штата, затраты на AI начнут расти в структуре расходов на разработку. Поэтому всё это нужно учитывать. Сюда входит вся ваша AI-система, и роутер ведёт полный учёт.
Слой безопасности
Далее должен быть слой безопасности — это обязательный этап. Здесь мы используем готовые сканеры и решения: SonarQube, Trivy и подобные. В каждой компании может быть своё решение, его несложно найти. Вы стремитесь максимально просканировать всю автоматизированную работу и проверить её на безопасность.
Итоговая схема
Это примерная схема того, что получается. У нас есть авторизация и оркестратор, который управляет всем процессом. Всё это алгоритмы без AI. Сюда поступают все запросы. Слой агентов — я показал этот цикл реализации намерений. Eval — алгоритмический, слой безопасности тоже. Средства на LLM расходуются только здесь (в слое агентов). Возможно, ещё в оркестраторе, когда пользователю задаются вопросы.
Из этого мы уже реализовали вот эту и вот эту части. SDLC у нас есть, Eval есть. Осталось внедрить всё это в продуктовую разработку и уйти от разрозненных агентов.