Antigravity؛ محیط توسعه‌ای برای مدیریت گروهی از عامل‌ها

در بخش ابزارهای توسعه‌دهنده Google I/O ۲۰۲۶، Antigravity از یک محیط ساخت agent به محیطی برای سازمان‌دهی چند عامل نزدیک شد. توسعه‌دهنده می‌تواند عامل‌هایی با نقش، ابزار و هدف متفاوت تعریف کند، اجرای آن‌ها را مشاهده کند و خروجی را در یک workflow مشترک کنار هم بگذارد. این مدل برای تیم‌هایی ساخته شده که از یک coding assistant به سمت taskهای طولانی و هم‌زمان می‌روند.

#orchestration به‌عنوان محصول

یک عامل ممکن است کد بنویسد، عامل دیگری تست بگیرد و سومی مستندات را بررسی کند. اگر این کارها به‌درستی جدا شوند، زمان انتظار کاهش می‌یابد. اما عامل‌ها باید قرارداد خروجی، dependency و مالک داشته باشند. نموداری از چند agent بدون تعریف state و شرط پایان، فقط پیچیدگی را از prompt به داشبورد منتقل می‌کند.

Antigravity در کنار Gemini API و AI Studio معرفی شده و بر ساخت تجربه‌های agentic تأکید دارد. برای توسعه‌دهنده، این یعنی مدل تنها لایه طراحی نیست؛ runtime، ابزار، حافظه و مشاهده‌پذیری نیز در محیط توسعه دیده می‌شوند. agent باید بتواند نتیجه را در artifact قابل بررسی برگرداند، نه اینکه فقط پیامی مبهم درباره پایان کار بدهد.

#بررسی و کنترل

تیم باید اجرای عامل را مانند job توزیع‌شده ببیند. trace هر مرحله، prompt و ابزار صدا زده‌شده، هزینه و زمان باید ثبت شوند. اگر یک عامل داده نادرست داد، orchestration باید بتواند آن مسیر را دوباره اجرا یا کنار بگذارد. retry بی‌قیدوشرط در یک حلقه چندعاملی هزینه و خطا را چند برابر می‌کند.

permission نیز باید در سطح عامل تعریف شود. عامل تست به secret production نیاز ندارد؛ عامل مستندات نباید بتواند کد را تغییر دهد. approval می‌تواند در مرزهای مشخص مانند merge، deploy یا ارسال داده فعال شود. این جداسازی، امکان استفاده از عامل‌های بیشتر را بدون گسترش بی‌حساب اختیار فراهم می‌کند.

#وضعیت توسعه

ابزارهای معرفی‌شده در I/O ممکن است پیش‌نمایش یا rollout محدود داشته باشند. تیمی که به Antigravity وابستگی می‌سازد باید status دسترسی، مدل‌های پشتیبانی‌شده و مسیر export یا جایگزین را بررسی کند. یک prototype موفق الزاماً به معنی API پایدار production نیست.

Antigravity ارزش خود را وقتی نشان می‌دهد که عامل‌ها قابل هدایت و قابل توضیح باشند. توسعه‌دهنده نباید فقط تعداد taskهای موازی را بسنجد؛ کیفیت نتیجه، زمان review و هزینه اصلاح معیارهای سالم‌تری برای تصمیم است.

معماری چندعامل همچنین به تعریف artifact مشترک نیاز دارد. اگر عامل کدنویس فقط پیامی متنی تحویل دهد و عامل تست نتواند نسخه فایل، خروجی تست و فرض‌های او را ببیند، موازی‌سازی ظاهری است. ثبت ورودی، تغییرات و وضعیت هر زیرعامل، امکان بازسازی یک اجرای ناموفق را فراهم می‌کند. در محیط تولید، همین قابلیت برای ممیزی و پاسخ به خطا ضروری است.