کنترل‌پلین برای ایجنت‌ها: Omnigent روی Kubernetes

مهندس‌های infrastructure سال‌هاست دارن سرویس‌ها رو orchestrate می‌کنن. Load balancer جلوی application server. Sidecar برای telemetry. Policy enforcement روی ingress. این pattern اونقدر آشناست که دیگه تقریباً کسل‌کننده‌ست.

حالا همین سوال داره به لایه‌ی agent‌ها می‌رسه.

Databricks اخیراً Omnigent رو open source کرد و بهش می‌گه “meta-harness”: یه لایه که agent harness‌های مختلف، از جمله Claude Code، Codex و هر پیاده‌سازی سفارشی دیگه‌ای رو پشت یه API مشترک جمع می‌کنه. Session‌ها، policy‌ها و skill‌ها همراهت می‌مونن، فارغ از اینکه زیرشون چه مدل یا harness‌ای داره کار می‌کنه. یه abstraction روی واقعیت مدیریت همزمان چند agent tool و copy کردن دستی context بین‌شونه.

این ایده برای کسی که قبلاً یه AI agent رو self-host کرده جدید نیست. وقتی داشتم یه research agent رو روی EKS راه می‌انداختم، همین سوال‌ها مطرح شد: state کجا زندگی می‌کنه؟ چه کسی مرزهای شبکه رو کنترل می‌کنه؟ چطور agent رو به دنیای بیرون expose کنی بدون اینکه کل ماشین رو باز بذاری؟ Omnigent این سوال‌ها رو توی یه محصول منسجم formalize کرده.

Meta-Harness اصلاً چیه؟

سه تا بخش هستن که قبل از فکر کردن به deployment باید بشناسی.

Runner یه agent زیرین رو توی یه sandbox session می‌پوشونه. درخواست‌های شبکه رو intercept می‌کنه، policy اعمال می‌کنه و دسترسی agent به دنیای بیرون رو مدیریت می‌کنه. کار اصلی security اینجاست.

Server مدیریت session‌ها، policy‌ها و sharing رو به عهده داره. این همونیه که بهت اجازه می‌ده یه قانون مثل “قبل از هر git push بعد از دانلود یه package، تایید انسانی لازمه” رو بدون دست زدن به خود agent تعریف کنی. Policy‌ها اینجا stateful و context-aware هستن، نه فقط یه لیست ساده‌ی allow/deny.

Database جایی‌ه که session state، audit log‌ها و تنظیمات policy ذخیره می‌شن. باید از pod‌های runner یا process‌های منفرد جان سالم به در ببره.

اگه قبلاً یه سرویس web stateful روی Kubernetes deploy کردی، این مشکل رو توی یه حوزه‌ی دیگه قبلاً حل کردی. topology همونه.

شکل مسئله روی Kubernetes

اجرای Omnigent روی یه cluster مسئله‌ی infrastructure تازه‌ای نیست. همون شکلی داره که احتمالاً قبلاً deploy کردی: یه server component که باید horizontally scalable باشه و بنابراین باید stateless باشه؛ یه runner component که یه subprocess رو می‌پوشونه و ذاتاً single-session‌ه؛ و یه database مشترک که هر دو بهش دسترسی دارن.

manifest‌های deployment، تعریف‌های Service، قوانین Ingress، اینا بخش جالب نیستن. سوالی که واقعاً به فکر کردن نیاز داره اینه: مرز network interception کجاست؟ Runner باید بین agent و ترافیک outbound قرار بگیره تا بتونه policy اعمال کنه. اینکه کجای topology فعلی cluster‌ات می‌شینه و چطور با network policy‌ها و کنترل‌های egress موجودت تعامل می‌کنه، سوالیه که قبل از نوشتن هر YAML باید روش فکر کنی.

کانفیگ database اولین جدایی راهه:

# تک‌نمونه برای تست محلی یا demo
DATABASE_URL=sqlite:////data/artifacts/chat.db

# پروداکشن: هر Postgres مدیریت‌شده‌ای کار می‌کنه
DATABASE_URL=postgresql://user:pass@postgres-host:5432/omnigent

SQLite برای یه setup تک‌نمونه‌ی محلی کار می‌کنه، ولی داده‌ها رو روی disk محلی pod ذخیره می‌کنه. روی Kubernetes یعنی داده‌ها با pod می‌میرن اگه persistent storage به صورت صریح mount نشده باشه. SQLite رو فقط انتخاب کن اگه دقیقاً می‌دونی داری از چی صرف نظر می‌کنی.

Postgres انتخاب درسته به محض اینکه persistence برات مهمه یا بخوای بیشتر از یه replica از server داشته باشی. هر Postgres مدیریت‌شده‌ای، چه داخل cluster چه خارجی، کار می‌کنه. محدودیت اصلی قابل دسترس بودن از pod CIDR‌ته. migration اولیه روی یه Postgres تازه حدود یه دقیقه طول می‌کشه؛ به startup probe‌ات وقت کافی بده وگرنه اولین deployment‌ات روی یه healthcheck شکست می‌خوره که باید پاسش می‌داد.

بقیه‌ی سوال‌های Kubernetes همون‌هایی هستن که برای هر سرویس stateful جواب می‌دی: secret‌ها کجا زندگی می‌کنن؟ Runner چطور credential‌های agent‌هایی که می‌پوشوندشون رو می‌گیره؟ چه کسی می‌تونه از خارج cluster به server دسترسی داشته باشه؟

شروع سریع بدون سربار عملیاتی

اگه می‌خوای بفهمی Omnigent چطور رفتار می‌کنه قبل از اینکه یه تصمیم infrastructure بگیری، یه HuggingFace Docker Space سریع‌ترین مسیر به UI‌ه. در چند دقیقه می‌تونی بالاش بیاری. نکته‌ی مهم اینه: HuggingFace Spaces به صورت پیش‌فرض از ephemeral disk storage استفاده می‌کنن. اگه SQLite تنظیم کنی، session history و policy‌هات با restart بعدی container از بین می‌رن. برای کشف کردن خوبه، نه برای چیزی که می‌خوای نگهش داری.

برای تیم‌هایی که از قبل روی Databricks کار می‌کنن، Omnigent مدیریت‌شده روی Databricks طرف دیگه‌ی طیفه. Meta-Harness رو بدون اینکه خودت عملیاتش کنی می‌گیری، با مدل security و governance خود Databricks که از قبل تنظیم شده. اگه agent‌ها و داده‌های سازمانت از قبل توی اون اکوسیستم هستن، اینجا نقطه‌ی شروع واضحه.

فضای جالب اینجاست: self-hosted روی infrastructure‌ای که خودت کنترلش داری، با policy‌هایی که روی risk model واقعی تیمت تنظیم شدن، نه default‌های vendor.

بخشی که واقعاً اهمیت داره

سوال deployment جواب قابل حلی داره. سوال policy سخت‌تر و جالب‌تره.

سیستم policy Omnigent stateful‌ه. یه قانون می‌تونه بگه: بعد از اینکه این agent یه package دانلود کرد، قبل از اینکه بتونه به یه remote repository push کنه، تایید دستی لازمه. این یه لیست ساده‌ی allow/deny نیست؛ یه state machine‌ه که روی اقدامات agent لایه می‌شه. Policy‌هات threat model سازمانت برای رفتار agent رو کدگذاری می‌کنن.

مال تو چطور می‌تونه باشه؟ محدودیت هزینه که agent رو قبل از یه API call گرون متوقف کنه. Approval gate قبل از اینکه هر write‌ای به یه محیط مشترک بزنه. Audit trail هایی که از model switch‌ها رد می‌شن تا موقع یه incident بدونی کدوم مدل کدوم تصمیم رو گرفته.

Kubernetes operator‌ها سال‌هاست سیستم‌های stateful رو به صورت declarative مدیریت می‌کنن. همون غریزه اینجا هم اعمال می‌شه: تعریف کن رفتار صحیح agent چه شکلیه، بعد بذار سیستم اعمالش کنه به جای اینکه هر session رو دستی نظارت کنی.

لایه‌ی agent داره treatment infrastructure‌ای رو که همیشه بهش نیاز داشته دریافت می‌کنه. تنها سوال اینه که آیا خودت تعریف می‌کنی این برای تیمت چه شکلی به نظر برسه، یا می‌ذاری یکی دیگه این تصمیم رو بگیره.

هنوز فرصت نکردم Omnigent رو توی یه cluster واقعی خودم اجرا کنم؛ پروژه‌های دیگه وقتم رو گرفتن. ولی از قبل توی TODO listمه و به محض اینکه وقت کردم یه deployment واقعی امتحان کنم، یه پست follow-up می‌ذارم.