Foreman перетворює агентів на основі великих мовних моделей (LLM) на нативні ресурси Kubernetes, дозволяючи командам запускати згенерований ШІ код у продакшені, зберігаючи при цьому суворий контроль над витратами та безпекою.

Як ця ідея вписується в сучасний робочий процес розробки

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

Відповіддю Foreman є вбудовування всього циклу написання коду всередину кластера Kubernetes. Foreman працює як ресурси Kubernetes.

Чотири основні об'єкти, завдяки яким це працює

  • Agent — визначає працівника. Він вказує назву LLM для виклику, перелічує інструменти, які модель може використовувати (наприклад, file-write або git-push), і встановлює бюджет, що обмежує кількість викликів моделі. Тут призначаються ролі: агент-кодер пише код, а агент-верифікатор його перевіряє.
  • Workload — створена користувачем одиниця роботи. Вона містить високорівневий намір (наприклад, «додати юніт-тести для модуля X»), посилання на цільовий репозиторій і список агентів, які мають виконати це завдання.
  • AgenticTask — конкретне завдання, яке створює Workload. У процесі виконання кожна AgenticTask фіксує оновлення статусу, що дозволяє операторам моніторити пайплайн у режимі реального часу.
  • FleetNode — вузол Kubernetes, який безпосередньо виконує завдання. Вбудований планувальник (scheduler) зіставляє очікувальні AgenticTasks із FleetNodes, які мають необхідну роль і ресурси.

Верифікація замість сліпої довіри

Foreman не припускає, що результат роботи моделі є правильним. Коли агент-кодер завершує свою роботу, він надсилає запит замість фінального результату. Верифікатор — зазвичай детермінований скрипт, а не інша LLM — пропускає код через лінтери, юніт-тести або повне збирання (build). Тільки якщо ці перевірки пройдено, Foreman записує нову гілку назад у репозиторій.

Якщо верифікатор не проходить перевірку, завдання позначається як відхилене, і зміни не вносяться. Такий поділ дозволяє моделі працювати творчо, тоді як «мережа безпеки» залишається під повним контролем людини.

Встановлення стека в кластері

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

Необхідно два набори облікових даних: облікові дані git для читання завдань (issues) і пушу гілок, а також облікові дані моделі для виклику або хостованого API, або локального сервісу виведення (inference service).

Регулятори витрат і безпеки, які ви дійсно можете налаштувати

Foreman дозволяє операторам обмежувати повноваження моделі, видаляючи інструменти з визначення агента. Видалення «bash» або «write_file» заважає моделі виконувати довільні команди оболонки або записувати дані за межі призначеного робочого простору.

Ліміт викликів обмежує кількість звернень до моделі на одне завдання, що дозволяє безпосередньо контролювати витрати. Налаштування вікна контексту — того, яку частину промпту бачить модель — додатково зменшує використання токенів. Коли модель працює локально на власному обладнанні (on-prem), дані не покидають організацію, що відповідає суворим політикам конфіденційності даних.

Де платформа демонструє переваги, а де все ще має труднощі

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

  • Виправлення задокументованого багу.
  • Додавання відсутніх тестів.
  • Оновлення документації для покращення чіткості або стилю.

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

Підсумок

Розглядаючи кодерів на базі LLM як повноцінні (first-class) ресурси Kubernetes і впроваджуючи детермінований етап верифікації, Foreman пропонує прагматичний шлях до генерації коду за допомогою ШІ у продакшені, забезпечуючи прозорість витрат і контроль безпеки. Це не універсальна панацея для всіх процесів розробки, але для повторюваних і тестованих завдань він забезпечує керований робочий процес, який природно вписується в існуючі cloud-native операції.