تصور کنید یک برنامه‌نویس ارشد هستید که باید هزاران خط کد قدیمی را از یک ابر (Cloud) به ابر دیگر منتقل کند، بدون اینکه حتی یک ثانیه سرویس قطع شود. این همان چالشی است که Antigravity CLI با جایگزینی دستی کدها با یک سیستم نظارت‌شده، آن را حل می‌کند. شعار محوری این چارچوب این است: «هیچ تغییر (Mutation) بدون تأیید صریح انسانی وارد محیط عملیاتی نمی‌شود».
طبق مستندات منتشرشده در ۳۰ ژوئن ۲۰۲۶، این ابزار با هدف حذف وابستگی به سرویس‌های AWS (Vendor Lock-in) در اپلیکیشن‌های پایتون طراحی شده است. به جای بازنویسی ساده کدها، این سامانه ارتشی از عامل‌های (Agent) زیرمجموعه را سازمان‌دهی می‌کند تا بارهای کاری را به Google Kubernetes Engine (GKE) منتقل کنند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل دسترسی در محیط‌های توزیع‌شده حیاتی است و این ابزار دقیقاً روی همین نقطه تمرکز کرده است.
بسیاری از تیم‌های فنی با کدهایی دست‌وپنجه نرم می‌کنند که پر از boto3 (SDK شرکت امازون) است؛ یعنی کدهایی که مثل یک قفل محکم، برنامه را به AWS می‌چسباند. ارثیه این کدها اغلب شامل اعتبارنامه‌های سخت‌کد شده (Hardcoded Credentials) و ذخیره‌سازی فایل‌های محلی است که در پادهای گذرا (Ephemeral Pods) کوبرنتیز شکست می‌خورند. برای بسیاری از تیم‌ها، ریسک بازنویسی دستی این کدها بسیار بالاست، اما از سوی دیگر، سپردن کامل یک مخزن کد عملیاتی به یک عامل خودکار نیز به همان اندازه خطرناک است. Antigravity CLI با تبدیل هوش مصنوعی به یک «مهندس تحت نظارت» به‌جای یک «اسکریپت کور»، این مشکل را حل کرده است.
موتور سازمان‌دهی: agy و عامل‌های زیرمجموعه
ابزار Antigravity CLI (یا agy) در واقع یک عامل مبتنی بر مدل‌های زبانی بزرگ (LLM) است که به سیستم فایل محلی و ترمینال دسترسی دارد. برخلاف یک چت‌بات استاندارد، این ابزار از «مهارت‌ها» (Skills) — که در فایل‌های SKILL.md تعریف شده‌اند — استفاده می‌کند تا تصمیم بگیرد از کدام ابزارها برای هر مرحله استفاده کند. هسته اصلی این مهاجرت، استفاده از عامل‌های زیرمجموعه است که در واقع عامل‌های فرزند با زمینه‌های (Context) کاملاً ایزوله هستند.
به نقل از مستندات فنی این پروژه، وقتی دستور /agnostic-cluster-refactor:spawn-refactor اجرا می‌شود، agy دو موجودیت متمایز را به صورت موازی خلق می‌کند:
- عامل بک‌اند (Backend Agent): تمرکز این عامل بر روی کدها است. این agent با اسکن کردن فایل
dependency-map.jsonتلاش می‌کند تا APIهای خاص AWS را شناسایی کرده و آن‌ها را با معادل‌های Google Cloud Storage (GCS) و Pub/Sub جایگزین کند. - عامل زیرساخت (Infra Agent): این عامل بر اساس اصل «حداقل دسترسی» عمل می‌کند و تنها بر تولید مانیفست‌های GKE مانند
serviceaccount.yamlوdeployment.yamlمتمرکز است.
برای جلوگیری از تداخلات احتمالی، هر عامل زیرمجموعه در یک Git Worktree ایزوله کار می‌کند. این استراتژی تضمین می‌کند که شاخه اصلی (Main Branch) کد تا زمانی که کاربر انسانی تغییرات را بررسی و تأیید نکند، دست‌نخورده و ایمن باقی می‌ماند.
دروازه امنیتی HITL
بر اساس گزارش فنی وب‌سایت dev.to، حیاتی‌ترین بخش این معماری، دروازه انسان-در-حلقه (Human-In-The-Loop یا HITL) است. این سیستم حفاظتی از طریق یک معماری دو لایه پیاده‌سازی شده است. لایه اول، فایلی به نام .agents/hooks.json است که یک هوک PreToolUse را ثبت می‌کند. این هوک هرگونه تلاش برای نوشتن در فایل‌ها خارج از دایرکتوری‌های ایمن (مانند examples/ یا terraform/) را رهگیری و متوقف می‌کند.
اگر عامل سعی کند فایلی محافظت‌شده را تغییر دهد، این هوک یک تصمیم force_ask را برمی‌گرداند که باعث توقف آنی عامل و درخواست تأییدیه از انسان می‌شود. لایه دوم در خود فایل SKILL.md تعریف شده است؛ جایی که مدل مجبور است یک مرحله تأییدیه متنی (Plain-text confirmation) را طی کند. این یعنی مدل باید ابتدا تمام تغییرات مورد نظر خود را فهرست کند و سپس منتظر دریافت پاسخ «YES» از کاربر بماند تا اجازه فعال‌سازی عامل‌های زیرمجموعه را پیدا کند.
حل مشکل «راه‌اندازی سرد» و تست‌های محلی
یک نقطه شکست ظریف اما رایج در مهاجرت‌های ابری، نحوه وارد کردن ماژول‌ها (Module-level import) است. وارد کردن google.cloud.storage در ابتدای یک فایل می‌تواند باعث کرش کردن برنامه در لحظه استارت‌آپ شود، اگر اعتبارنامه‌های GCP در دسترس نباشند. کد بازنویسی‌شده توسط این ابزار، این مشکل را با استفاده از «وارد کردن‌های شرطی» (Conditional Imports) در داخل بلوک‌های منطقی حل می‌کند تا برنامه حتی در محیط‌های شبیه‌ساز (Mock) نیز بدون خطا اجرا شود.
برای اعتبارسنجی استک GKE بدون صرف هزینه یا نیاز به توکن‌های واقعی گوگل، توسعه‌دهنده پرچم LOCAL_MOCK=true را تعریف کرده است. این قابلیت اجازه می‌دهد اپلیکیشن از یک ذخیره‌ساز در حافظه (In-memory store) برای تست استفاده کند. با توجه به اینکه Docker Desktop از یک runtime containerd مجزا نسبت به Docker daemon استفاده می‌کند، این سیستم از یک رجیستری محلی روی پورت ۵۰۰۱ به‌عنوان پل ارتباطی برای انتقال (Push/Pull) ایمیج‌ها به خوشه کوبرنتیز محلی استفاده می‌کند.
امنیت عملیاتی: هویت بار کاری
در مرحله نهایی استقرار در GKE، این چارچوب استفاده از کلیدهای JSON برای حساب‌های سرویس را به طور کامل رد می‌کند، زیرا این کلیدها ریسک امنیتی بالایی دارند. به‌جای آن، سیستم Workload Identity را پیاده‌سازی می‌کند که یک حساب سرویس کوبرنتیز (KSA) را از طریق یک انوتیشن IAM خاص به نام iam.gke.io/gcp-service-account به یک حساب سرویس گوگل (GSA) متصل می‌کند.
این رویکرد اجازه می‌دهد اپلیکیشن از اعتبارنامه‌های پیش‌فرض برنامه (Application Default Credentials یا ADC) استفاده کند. در این حالت، سرور متادیتای GKE درخواست را رهگیری کرده و یک توکن OAuth2 کوتاه‌مدت صادر می‌کند. این تغییر بنیادی باعث می‌شود دیگر نیازی به مونت کردن Secrets به عنوان Volume یا سخت‌کد کردن آن‌ها در Dockerfiles نباشد و ریسک نشت اعتبارنامه‌های طولانی‌مدت در لاگ‌های عملیاتی به طور کامل حذف شود.
تحلیل: از اسکریپت‌ها به گردش‌کارهای عاملی
این پیاده‌سازی نشان‌دهنده تغییری در نحوه مدیریت بدهی‌های فنی (Technical Debt) است. ما در حال حرکت از اسکریپت‌های ساده «جستجو و جایگزینی» (Find-and-Replace) به سمت گردش‌کارهای عاملی هستیم که زمینه معنایی (Semantic Context) کد را درک می‌کنند. با جداسازی منطق بک‌اند از مانیفست‌های زیرساختی از طریق عامل‌های زیرمجموعه، این سیستم در واقع رفتار یک تیم مهندسی واقعی (Engineering Pod) را شبیه‌سازی می‌کند.
برای متخصصان، ارزش واقعی در تولید کد نیست (که اکثر LLMها قادر به انجام آن هستند)، بلکه در معماری حفاظتی (Guardrail Architecture) است. ترکیب Git Worktrees و دروازه HITL، یک هوش مصنوعی غیرقابل پیش‌بینی را به ابزاری قابل تأیید تبدیل می‌کند. این الگو نشان می‌دهد که آینده برنامه‌نویسی با هوش مصنوعی، نه «خودمختار» (Autonomous) بلکه «نظارتی» (Supervisory) است، جایی که نقش اصلی انسان، حسابرسی شعاع تخریب (Blast Radius) اقدامات عوامل هوشمند است.
گام بعدی شما
- برای شروع، مخزن گیت‌هاب پروژه را بررسی کرده و اسکریپت‌های Terraform را برای محیط خود شخصی‌سازی کنید.
- پل ارتباطی Local-registry را در محیط Docker Desktop خود تست کنید تا از صحت انتقال ایمیج‌ها مطمئن شوید.
- معماری HITL را در پروژه‌های کوچک‌تر خود پیاده کنید تا ریسک استفاده از عامل‌های خودکار را کاهش دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو