آموزش Google Antigravity در ویندوز؛ نصب و اجرای اولین Agent امن
راهنمای عملی نصب Google Antigravity در ویندوز و ساخت یک جریان Agentic کنترل‌شده؛ از انتخاب Project و Worktree تا تنظیم Permission، بررسی Plan و Artifact و تحویل تغییرات قابل‌اعتماد.
عامل‌های کدنویسی فقط متن پیشنهاد نمی‌کنند؛ می‌توانند فایل بخوانند، تغییر ایجاد کنند، تست اجرا کنند و نتیجه را در مرورگر بررسی کنند. Google Antigravity این الگو را در یک محیط Agent-first جمع می‌کند: شما هدف و محدودیت را تعیین می‌کنید، Agent برنامه می‌سازد و کار می‌کند، و خروجی با Artifact قابل‌بررسی تحویل می‌شود.
همین قدرت، نیازمند کنترل است. نصب موفق فقط رسیدن به صفحه اصلی برنامه نیست؛ باید پروژه درست را باز کنید، محدوده دسترسی را کوچک نگه دارید و قبل از پذیرش تغییر، Diff و تست را ببینید. در این آموزش Antigravity را روی ویندوز آماده می‌کنیم و یک باگ ساده را با گردش‌کار امن برطرف می‌کنیم.
Google Antigravity چیست؟
Google Antigravity یک پلتفرم توسعه Agentic است که تجربه آشنای IDE را با Agent Manager ترکیب می‌کند. طبق معرفی رسمی Google، Agent می‌تواند در Editor، Terminal و Browser کار کند، برای وظایف چندمرحله‌ای Plan بسازد و نتیجه را به‌شکل Artifactهایی مانند فهرست کار، گزارش پیاده‌سازی، Screenshot یا Browser Recording ارائه دهد.
در Antigravity 2.0، برنامه دسکتاپ، IDE، CLI و SDK نقش‌های متفاوتی دارند. برای شروع روی ویندوز، رابط دسکتاپ و IDE مناسب‌اند؛ چون مسیر Project، Permission و بازبینی بصری را یکجا می‌بینید. CLI برای کاربرانی است که جریان Terminal یا اجرای Headless می‌خواهند.
| بخش | کار اصلی | مناسب برای | نقطه کنترل |
|---|---|---|---|
| Agent Manager | هدایت Agentها و Taskها | کارهای طولانی و موازی | Scope و وضعیت هر Task |
| Antigravity IDE | ویرایش و بازبینی کد | کار تعاملی روی Repository | Diff و تست |
| Browser integration | دیدن و آزمودن UI | رفع باگ فرانت‌اند | URL و Action مجاز |
| Artifacts | نمایش Plan و نتیجه | بازبینی سریع تصمیم‌ها | شواهد قابل‌تأیید |
| CLI | تعامل در Terminal | کار Headless و سبک | Permission فرمان‌ها |
پیش‌نیازهای نصب در ویندوز
- Windows به‌روز با دسترسی نصب نرم‌افزار برای حساب خودتان
- حساب Google شخصی یا حساب سازمانی پشتیبانی‌شده
- Git برای پروژه‌هایی که قرار است با Worktree ایزوله شوند
- حداقل یک Repository آزمایشی و بدون Secret واقعی
- مرورگر سازگار برای آزمون صفحات وب
- نسخه پشتیبان یا Commit تمیز پیش از شروع کار
برای تمرین اول از پروژه حساس یا محیط Production استفاده نکنید. یک Repository نمونه یا Branch مستقل بسازید تا بتوانید هر تغییر را بدون فشار زمانی بررسی و در صورت لزوم کنار بگذارید.
مرحله اول: دانلود از منبع رسمی
فقط از صفحه رسمی Google Antigravity وارد مسیر Download شوید. سیستم‌عامل Windows را انتخاب کنید و Installer متناسب با معماری دستگاه را بگیرید. فایل نصب را از لینک‌های بازنشرشده، کانال‌های ناشناس یا بسته‌های دستکاری‌شده دریافت نکنید.
پس از دریافت، Publisher و امضای دیجیتال فایل را در Properties ویندوز بررسی کنید. اگر نام Publisher معتبر نیست یا Windows هشدار غیرعادی نمایش می‌دهد، نصب را متوقف کنید و دوباره از صفحه رسمی شروع کنید. این بررسی ساده، ریسک نصب بسته جعلی را کاهش می‌دهد.
ورود با حساب شخصی یا سازمانی
در مسیر راه‌اندازی، نوع حساب را مطابق مالکیت Repository انتخاب کنید. پروژه شخصی را با حساب کاری و Repository سازمانی را با حساب شخصی مخلوط نکنید. اگر سازمان سیاست AI یا نگه‌داری داده دارد، پیش از اتصال کد خصوصی، مجوز و تنظیمات حساب را با مسئول امنیت هماهنگ کنید.
مرحله دوم: ساخت Project با محدوده روشن
در Antigravity 2.0، Project می‌تواند یک یا چند پوشه مرتبط را نگه دارد و Permissionهای مخصوص همان محدوده داشته باشد. برای اولین تجربه، فقط یک Repository را اضافه کنید. پوشه ریشه حساب کاربری، Documents کامل یا درایو را به Project ندهید.
| انتخاب | مزیت | ریسک | پیشنهاد |
|---|---|---|---|
| یک Repository | Scope روشن | کم | بهترین گزینه شروع |
| چند Repository مرتبط | Context کامل محصول | تغییر ناخواسته بین پروژه‌ها | پس از تسلط |
| پوشه عمومی توسعه | دسترسی آسان | Scope بیش از نیاز | اجتناب شود |
| دایرکتوری شخصی | تقریباً هیچ مزیت فنی | دسترسی به فایل‌های نامرتبط | هرگز برای Project |
مرحله سوم: Local یا New Worktree؟
Local Mode مستقیماً روی Checkout فعال کار می‌کند و برای اصلاح کوتاه و تعاملی مناسب است. New Worktree یک Git Worktree جدا برای Task ایجاد می‌کند؛ بنابراین تغییر Agent از پوشه اصلی و کار در حال انجام شما جدا می‌ماند.
برای Task پیچیده، Agent موازی یا تغییری که هنوز مطمئن نیستید، New Worktree انتخاب امن‌تری است. Local را زمانی انتخاب کنید که وضعیت Repository را می‌شناسید، تغییر کوچک است و می‌خواهید بلافاصله در همان Checkout بازبینی کنید.
| سناریو | Local | New Worktree |
|---|---|---|
| اصلاح یک متن یا تست کوچک | مناسب | اختیاری |
| تغییر چندفایلی | با احتیاط | پیشنهادی |
| چند Agent هم‌زمان | ریسک تداخل | مناسب |
| Working Tree دارای تغییر | ریسک هم‌پوشانی | ایزوله‌تر |
| نیاز به کنارگذاشتن آزمایش | دستی | ساده‌تر |
مرحله چهارم: Permission را با اصل حداقل دسترسی تنظیم کنید
موتور Permission در Antigravity سه رفتار Allow، Ask و Deny دارد. طبق مستندات Google، قانون محدودکننده‌تر اولویت دارد و عملیات حساس می‌تواند قبل از اجرا متوقف شود. برای شروع، خواندن و نوشتن داخل Project را محدود به Repository کنید و اجرای Terminal یا دسترسی وب را روی Ask نگه دارید.
- Allow: فقط عملیات تکراری و کم‌خطر که Scope آن دقیقاً مشخص است.
- Ask: نصب Dependency، فرمان‌های Terminal، دسترسی به URL و تغییر خارج از مسیر عادی.
- Deny: مسیرهای حاوی Secret، فایل‌های شخصی، ابزارهای انتشار و عملیات مخرب.
برای راحتی، الگوی گسترده مانند اجازه همه فرمان‌ها یا همه URLها نسازید. Permission باید براساس نیاز Task افزایش پیدا کند و پس از پایان کار دوباره بازبینی شود. وجود Approval مزاحمت نیست؛ مرزی برای جلوگیری از گسترش ناخواسته مأموریت است.
Secretها را از Context حذف کنید
فایل Environment واقعی، Connection String، Token انتشار و کلید خصوصی را وارد Prompt نکنید. یک فایل نمونه با نام متغیرها و مقدار ساختگی بسازید و Secret واقعی را در Secret Manager یا محیط امن نگه دارید. اگر Agent برای اجرای تست به Credential نیاز دارد، ابتدا بررسی کنید آیا Mock یا محیط Local بدون داده واقعی کافی است.
مرحله پنجم: اولین Task را درست تعریف کنید
یک Task خوب هدف، Scope، محدودیت، معیار پذیرش و روش تأیید دارد. برای نمونه، فرض کنید دکمه ذخیره در فرم پروفایل هنگام خطای شبکه بی‌پاسخ می‌ماند. درخواست زیر از «باگ را درست کن» بسیار ایمن‌تر است:
در صفحه ویرایش پروفایل فقط مسیر ذخیره فرم را بررسی کن. ابتدا علت را بازتولید و Plan کوتاه ارائه بده. هنگام خطای شبکه باید پیام قابل‌فهم نشان داده شود، دکمه از حالت Loading خارج شود و داده واردشده حفظ شود. فایل‌های Authentication، تنظیمات Deploy و Database را تغییر نده. پیش از افزودن Dependency یا اجرای فرمان تغییردهنده درخواست تأیید کن. تست موجود را به‌روزرسانی یا یک تست محدود اضافه کن و در پایان Diff، نتیجه تست و Screenshot حالت خطا را به‌عنوان Artifact تحویل بده.
این Prompt هم نتیجه مطلوب را روشن می‌کند و هم مرز کار را. ممنوعیت تغییر بخش‌های حساس را صریح بنویسید؛ Agent نباید از روی حدس بداند کدام فایل برای کسب‌وکار حیاتی است.
مرحله ششم: Plan را قبل از اجرا بازبینی کنید
Plan باید نشان دهد Agent چگونه باگ را بازتولید، علت را پیدا، تغییر را محدود و نتیجه را تأیید می‌کند. اگر Plan مستقیماً از مشاهده به بازنویسی بزرگ می‌پرد، آن را اصلاح کنید. برای یک باگ فرم، تغییر معماری Authentication یا جایگزینی کتابخانه UI معمولاً خارج از Scope است.
- آیا فایل‌های مورد انتظار با Task مرتبط‌اند؟
- آیا روش بازتولید قبل از Fix وجود دارد؟
- آیا تست شکست‌خورده یا شاهد فعلی ثبت می‌شود؟
- آیا تغییر کوچک و قابل‌بازگشت است؟
- آیا فرمان یا دسترسی جدید به Approval نیاز دارد؟
- آیا معیار پایان کار عینی است؟
مرحله هفتم: Artifact را به‌عنوان مدرک ببینید، نه تضمین
Artifact مرور کار را سریع می‌کند، اما جای Diff و اجرای مستقل تست را نمی‌گیرد. Screenshot می‌تواند ظاهر درست را نشان دهد ولی خطای Console، Accessibility یا رفتار Mobile را پنهان کند. Browser Recording نیز فقط همان مسیر ثبت‌شده را اثبات می‌کند.
| Artifact | چه چیزی ثابت می‌کند | چه چیزی را ثابت نمی‌کند |
|---|---|---|
| Plan | مسیر پیشنهادی | صحت پیاده‌سازی |
| Diff | فایل و خط تغییرکرده | نبود Regression |
| Test report | نتیجه تست‌های اجراشده | پوشش همه سناریوها |
| Screenshot | ظاهر یک State | رفتار و دسترس‌پذیری کامل |
| Browser recording | یک مسیر تعاملی | امنیت Backend |
پس از تحویل، خودتان Diff را بخوانید، تست‌های مرتبط را دوباره اجرا کنید و رفتار را در Browser مستقل ببینید. اگر Agent Dependency اضافه کرده است، دلیل، مجوز، نگه‌داری و آسیب‌پذیری آن را بررسی کنید.
مرحله هشتم: بازبینی امنیتی تغییر
عامل کدنویسی ممکن است برای رسیدن سریع به نتیجه، Validation را فقط در Client اضافه کند یا Error حساس را مستقیم نمایش دهد. بررسی کنید کنترل‌های امنیتی در لایه درست قرار گرفته‌اند و اطلاعات داخلی در Log، UI یا Response منتشر نمی‌شود.
- هیچ Secret یا Token داخل Source و Git ثبت نشده باشد.
- ورودی کاربر در Server نیز Validate شود.
- پیام خطا اطلاعات Stack، مسیر فایل یا Query را افشا نکند.
- مجوز دسترسی فقط در UI اعمال نشده باشد.
- Dependency جدید ضروری، معتبر و قفل‌شده باشد.
- تست، هم موفقیت و هم شکست را پوشش دهد.
- تغییر Migration یا تنظیم Production بدون درخواست صریح وجود نداشته باشد.
چه زمانی از چند Agent استفاده کنیم؟
قابلیت Teamwork و Agentهای موازی برای کارهای مستقل مفید است؛ مثلاً یک Agent تست را بررسی کند و دیگری مستندات را آماده کند. موازی‌سازی برای دو Agent که هم‌زمان یک فایل یا معماری مشترک را تغییر می‌دهند، بدون جداسازی Worktree می‌تواند Conflict و تصمیم متناقض ایجاد کند.
هر Agent باید مالک خروجی مشخص، Scope غیرهم‌پوشان و معیار پایان مستقل داشته باشد. یک Agent هماهنگ‌کننده یا بازبینی انسانی باید نتیجه‌ها را ترکیب کند. تعداد بیشتر Agentها خودبه‌خود کیفیت بالاتر ایجاد نمی‌کند.
Antigravity یا Gemini CLI؟
Google Antigravity برای کسی مناسب است که Agent Manager، IDE، Artifact و Browser یکپارچه می‌خواهد. Gemini CLI برای توسعه‌دهنده‌ای مناسب‌تر است که Terminal، Script، Headless mode یا Pipeline را ترجیح می‌دهد. برای اولین تجربه Agentic و بازبینی بصری، Antigravity مسیر قابل‌فهم‌تری ارائه می‌کند؛ برای Automation سبک، CLI ممکن است ساده‌تر باشد.
| نیاز | انتخاب مناسب | دلیل |
|---|---|---|
| مدیریت چند Task | Antigravity | Agent Manager |
| بازبینی UI | Antigravity | Browser و Artifact |
| اجرای Headless | CLI | سازگار با Terminal و Pipeline |
| شروع برای کاربر تازه‌کار | Antigravity | رابط بصری و Approval روشن |
| Automation تکراری | CLI با Guardrail | قابل اسکریپت‌کردن |
خطاهای رایج در اولین استفاده
بازکردن پوشه بیش از حد بزرگ
Scope را به Repository لازم محدود کنید. Context زیاد هم ریسک دسترسی را بالا می‌برد و هم تشخیص فایل مرتبط را سخت می‌کند.
فعال‌کردن Allow برای همه‌چیز
Terminal و Web را ابتدا روی Ask بگذارید. Allow عمومی سرعت ظاهری می‌دهد اما فرصت توقف در تصمیم حساس را حذف می‌کند.
درخواست مبهم و بدون معیار پذیرش
هدف، فایل‌های خارج از Scope، Stateهای مورد انتظار و تست نهایی را در Prompt مشخص کنید.
پذیرش Screenshot به‌جای تست
Screenshot فقط ظاهر را نشان می‌دهد. Diff، تست خودکار، Console و مسیر شکست را مستقل بررسی کنید.
کار مستقیم روی Branch اصلی
برای Task چندمرحله‌ای از Worktree یا Branch ایزوله استفاده کنید و Merge را پس از Review انجام دهید.
چک‌لیست قبل از پذیرش تغییر Agent
- هدف Task و Scope فایل‌ها رعایت شده است.
- هیچ تغییر نامرتبطی در Diff وجود ندارد.
- Testهای مرتبط به‌صورت مستقل اجرا شده‌اند.
- حالت خطا و Loading در Browser بررسی شده‌اند.
- هیچ Secret، داده شخصی یا تنظیم Production وارد Commit نشده است.
- Dependency جدید دلیل و مجوز قابل‌قبول دارد.
- Permission موقت پس از پایان Task بازبینی شده است.
- Artifactها با کد واقعی و نتیجه اجرا تطبیق دارند.
- Commit کوچک، روشن و قابل‌بازگشت است.
- Merge فقط پس از Review انسانی انجام می‌شود.
مسیرهای مکمل یادگیری
اگر محیط سبک Terminal را ترجیح می‌دهید، راهنمای GitHub Copilot CLI در ویندوز را ببینید. برای طراحی رابط پیش از توسعه، آموزش Google Stitch مسیر ایده تا Prototype را توضیح می‌دهد. اگر قصد ساخت MVP دارید، راهنمای Lovable با GitHub و کنترل امنیت مکمل مناسبی است.
جمع‌بندی
Google Antigravity زمانی مفید است که Agent را مجری محدود یک قرارداد روشن بدانید. Repository کوچک، Worktree ایزوله، Permission مبتنی بر Ask، Plan قابل‌بازبینی و Artifact همراه با تست، سرعت Agent را به خروجی قابل‌اعتماد نزدیک می‌کند.
برای اولین تجربه، یک باگ کم‌خطر را انتخاب کنید. قبل از اجرا Scope و معیار پذیرش را بنویسید، در طول کار Permissionها را آگاهانه تأیید کنید و در پایان Diff و تست را خودتان بررسی کنید. Agent می‌تواند کار را سریع کند؛ مسئولیت پذیرش تغییر همچنان با توسعه‌دهنده است.
امروز یک Repository آزمایشی را در Worktree جدا باز کن و یک Task کوچک با Scope، ممنوعیت‌ها و معیار پذیرش دقیق تعریف کن.