Foreman عامل‌های مدل زبانی بزرگ (LLM) را به منابع بومی Kubernetes تبدیل می‌کند و به تیم‌ها اجازه می‌دهد کد تولیدشده توسط هوش مصنوعی را در محیط عملیاتی اجرا کنند، در حالی که هزینه‌ها و امنیت را تحت کنترل دقیق نگه می‌دارند.

چگونگی انطباق این ایده با جریان کاری توسعه امروزی

سازمان‌ها در حال آزمایش با LLMهایی هستند که می‌توانند کد بنویسند، اما بیشتر پیاده‌سازی‌ها با مدل به عنوان یک جعبه سیاه قابل اعتماد برخورد می‌کنند. یک سیگنال واحد «انجام شد» (done) از سوی مدل می‌تواند تغییرات آزمایش‌نشده را مستقیماً به یک مخزن (repository) ارسال کند که این امر نگرانی‌های امنیتی و قابلیت اطمینان را افزایش می‌دهد. در عین حال، اجرای سرویس‌های هوش مصنوعی در ابر می‌تواند به سرعت هزینه‌بر شود، به‌ویژه زمانی که یک مدل مشابه به طور مکرر از خط لوله‌های CI فراخوانی می‌شود.

پاسخ Foreman این است که کل حلقه کدنویسی را درون یک کلاستر Kubernetes قرار دهد. Foreman به عنوان منابع Kubernetes اجرا می‌شود.

چهار شیء اصلی که این فرآیند را ممکن می‌سازند

  • Agent – یک کارگر را تعریف می‌کند. نام LLM مورد نظر برای فراخوانی را مشخص می‌کند، ابزارهایی که مدل می‌تواند فراخوانی کند (مانند file-write یا git-push) را فهرست می‌کند و بودجه‌ای را تعیین می‌کند که سقف فراخوانی‌های مدل را مشخص می‌سازد. نقش‌ها در اینجا متصل می‌شوند؛ یک عامل کدنویس (coder agent) کد می‌نویسد و یک عامل تأییدکننده (verifier agent) آن را بررسی می‌کند.
  • Workload – واحد کار تعریف‌شده توسط کاربر است. این شیء شامل هدف سطح بالا (مثلاً «افزودن تست‌های واحد برای ماژول X»)، ارجاعی به مخزن هدف و فهرستی از عامل‌هایی است که باید کار را انجام دهند.
  • AgenticTask – وظیفه مشخصی است که توسط یک Workload ایجاد می‌شود. با پیشرفت کار، هر AgenticTask به‌روزرسانی‌های وضعیت را ثبت می‌کند و به اپراتورها اجازه می‌دهد خط لوله را به صورت لحظه‌ای (real-time) نظارت کنند.
  • FleetNode – یک نود Kubernetes است که وظایف را در واقع اجرا می‌کند. زمان‌بند (scheduler) داخلی، AgenticTaskهای در انتظار را با FleetNodeهایی که نقش و منابع مورد نیاز را دارند، مطابقت می‌دهد.

جایگزینی اعتماد کورکورانه با تأییدیه

Foreman فرض نمی‌کند که خروجی مدل صحیح است. وقتی یک عامل کدنویس کار خود را تمام می‌کند، به جای یک نتیجه نهایی، یک درخواست ارسال می‌کند. یک تأییدکننده (verifier) — که معمولاً یک اسکریپت قطعی (deterministic) است و نه یک LLM دیگر — کد را از طریق لینترها (linters)، تست‌های واحد یا بیلد‌های کامل بررسی می‌کند. تنها در صورتی که این بررسی‌ها با موفقیت انجام شوند، Foreman شاخه (branch) جدید را در مخزن می‌نویسد.

اگر تأییدکننده با شکست مواجه شود، وظیفه با برچسب رد شده (rejected) مشخص می‌شود و تغییرات هرگز اعمال نمی‌شوند. این جداسازی اجازه می‌دهد مدل خلاقانه عمل کند در حالی که شبکه ایمنی کاملاً تحت کنترل انسان باقی می‌ماند.

نصب پشته (stack) روی یک کلاستر

  1. چارت اصلی LLMKube را با استفاده از Helm مستقر کنید.
  2. چارت Foreman را نیز از طریق Helm مستقر کنید.
  3. حالت عامل (agent mode) را به "native" تغییر دهید تا حلقه واقعی درخواست-پاسخ فعال شود.
  4. نقش‌ها (coder، verifier) را به FleetNodeهایی که میزبان کار خواهند بود، اختصاص دهید.

دو مجموعه اعتبار (credential) مورد نیاز است: اعتبار git برای خواندن مسائل (issues) و ارسال شاخه‌ها (pushing branches)، و اعتبار مدل برای فراخوانی یک API میزبانی‌شده یا یک سرویس استنتاج (inference service) خود-میزبانی‌شده.

تنظیمات هزینه و امنیت که واقعاً می‌توانید کنترل کنید

Foreman به اپراتورها اجازه می‌دهد با حذف ابزارها از تعریف عامل، اختیارات مدل را محدود کنند. حذف bash یا write_file مانع از اجرای دستورات دلخواه شل (shell) یا نوشتن خارج از فضای کاری تعیین‌شده توسط مدل می‌شود.

محدودیت تعداد دفعات (turn limit)، تعداد فراخوانی‌های مدل در هر وظیفه را محدود کرده و مستقیماً هزینه‌ها را کنترل می‌کند. تنظیم پنجره بافت (context window) — یعنی میزان پرامپتی که مدل می‌بیند — مصرف توکن را بیشتر کاهش می‌دهد. وقتی مدل به صورت محلی روی سخت‌افزار داخلی (on-prem) اجرا می‌شود، هیچ داده‌ای از سازمان خارج نمی‌شود که این امر سیاست‌های سخت‌گیرانه حریم خصوصی داده‌ها را برآورده می‌کند.

نقاط قوت پلتفرم و نقاط ضعف آن

Foreman در کارهای مکانیکی و با محدوده مشخص عالی عمل می‌کند:

  • رفع یک باگ مستند شده.
  • افزودن موارد تست (test cases) مفقود شده.
  • به‌روزرسانی مستندات برای وضوح یا سبک نگارش.

این وظایف دارای معیارهای موفقیت مشخصی هستند که یک تأییدکننده می‌تواند به طور خودکار آن‌ها را بررسی کند. این سیستم هنوز در بازطراحی‌های معماری سطح بالا یا کارهای ویژگی (feature) مبهم که در آن‌ها «درستی» به قضاوت انسانی بستگی دارد، با چالش روبرو است.

جمع‌بندی

Foreman با در نظر گرفتن کدنویس‌های مبتنی بر LLM به عنوان منابع درجه‌اول (first-class) Kubernetes و اعمال یک مرحله تأیید قطعی، مسیری عمل‌گرایانه برای تولید کد هوش مصنوعی در محیط عملیاتی ارائه می‌دهد که هزینه‌ها را قابل مشاهده و امنیت را تحت کنترل نگه می‌دارد. این ابزار یک راه حل جادویی برای تمام کارهای توسعه نیست، اما برای وظایف تکرارپذیر و قابل تست، یک جریان کاری قابل حسابرسی فراهم می‌کند که به طور طبیعی با عملیات‌های موجود در فضای cloud-native سازگار است.