Foreman превращает агентов на базе больших языковых моделей (LLM) в нативные ресурсы Kubernetes, позволяя командам запускать сгенерированный ИИ код в продакшене, сохраняя при этом строгий контроль над затратами и безопасностью.

Как эта идея вписывается в современный рабочий процесс разработки

Предприятия экспериментируют с LLM, способными писать код, но в большинстве реализаций модель рассматривается как «черный ящик», которому доверяют безоговорочно. Один сигнал «готово» от модели может привести к тому, что непроверенные изменения попадут прямиком в репозиторий, что вызывает опасения по поводу безопасности и надежности. В то же время запуск ИИ-сервисов в облаке может быстро стать дорогостоящим, особенно когда одна и та же модель вызывается многократно из CI-конвейеров.

Решение Foreman заключается в том, чтобы встроить весь цикл написания кода внутрь кластера Kubernetes. Foreman работает как ресурсы Kubernetes.

Четыре основных объекта, которые обеспечивают работу системы

  • Agent — определяет исполнителя. Он указывает, какую LLM нужно вызывать, перечисляет инструменты, которые может использовать модель (например, file-write или git-push), и устанавливает бюджет, ограничивающий количество вызовов модели. Здесь назначаются роли: агент-кодер (coder) пишет код, а агент-верификатор (verifier) его проверяет.
  • Workload — единица работы, созданная пользователем. Она содержит высокоуровневое намерение (например, «добавить юнит-тесты для модуля X»), ссылку на целевой репозиторий и список агентов, которые должны выполнить задачу.
  • AgenticTask — конкретная задача, которую порождает Workload. По мере выполнения задачи каждый AgenticTask записывает обновления статуса, позволяя операторам отслеживать конвейер в режиме реального времени.
  • FleetNode — узел Kubernetes, который непосредственно выполняет задачи. Встроенный планировщик сопоставляет ожидающие AgenticTask с FleetNode, имеющими необходимую роль и ресурсы.

Верификация вместо слепого доверия

Foreman не предполагает, что результат работы модели будет верным. Когда агент-кодер завершает свою работу, он отправляет запрос вместо окончательного результата. Верификатор — обычно детерминированный скрипт, а не другая LLM — прогоняет код через линтеры, юнит-тесты или полную сборку. Только если эти проверки пройдены, Foreman записывает новую ветку обратно в репозиторий.

Если верификатор не проходит проверку, задача помечается как отклоненная, и изменения не попадают в репозиторий. Такое разделение позволяет модели проявлять творческий подход, в то время как «сеть безопасности» остается полностью под контролем человека.

Установка стека в кластере

  1. Разверните основной чарт LLMKube с помощью Helm.
  2. Разверните чарт Foreman также через Helm.
  3. Переключите режим агента на «native», чтобы активировать реальный цикл «запрос-ответ».
  4. Назначьте роли (coder, verifier) узлам FleetNodes, которые будут выполнять работу.

Требуются два набора учетных данных: учетные данные git для чтения задач (issues) и отправки веток, а также учетные данные модели для вызова либо хостинг-API, либо собственного сервиса инференса.

Рычаги управления стоимостью и безопасностью, которые вы действительно можете использовать

Foreman позволяет операторам ограничивать полномочия модели, удаляя инструменты из определения агента. Удаление «bash» или «write_file» запрещает модели выполнять произвольные shell-команды или записывать файлы за пределами назначенного рабочего пространства.

Лимит итераций ограничивает количество вызовов модели на одну задачу, напрямую контролируя расходы. Настройка контекстного окна — объема промпта, который видит модель — позволяет дополнительно сократить использование токенов. Когда модель запускается локально на собственном оборудовании, данные не покидают организацию, что соответствует строгим политикам конфиденциальности данных.

В чем платформа сильна, а где она все еще спотыкается

Foreman отлично справляется с механическими, четко определенными задачами:

  • Исправление задокументированного бага.
  • Добавление недостающих тест-кейсов.
  • Обновление документации для ясности или соблюдения стиля.

У этих задач есть четкие критерии успеха, которые верификатор может проверить автоматически. Система все еще испытывает трудности с высокоуровневым архитектурным редизайном или неоднозначными задачами по разработке функций, где «правильность» зависит от человеческого суждения.

Итог

Относясь к кодерам на базе LLM как к первоклассным ресурсам Kubernetes и внедряя этап детерминированной верификации, Foreman предлагает прагматичный путь к генерации кода с помощью ИИ в продакшене, обеспечивая прозрачность расходов и контроль безопасности. Это не «серебряная пуля» для всех задач разработки, но для повторяемых и тестируемых задач он предоставляет проверяемый рабочий процесс, который естественным образом вписывается в существующие cloud-native операции.