آموزش Antigravity CLI (آنتی‌گرویتی): نصب، مجوزها و کار روزانه با agy

راهنمای عملی ابزار خط فرمان Antigravity گوگل به زبان ساده: نصب روی مک، لینوکس و ویندوز، فایل AGENTS.md، مجوزها و محیط ایزوله، دستورهای روزانه، MCP و اجرای خودکار.

آموزش Antigravity CLI (آنتی‌گرویتی): نصب، مجوزها و کار روزانه با agy
نویسنده
تیم ژرف
انتشار
۱۵ مرداد ۱۴۰۵
به‌روزرسانی
۶ مهر ۱۴۰۵
زمان مطالعه
۱۸ دقیقه

Antigravity CLI نسخه خط فرمان پلتفرم ایجنت‌های گوگل است و با فرمان agy اجرا می‌شود. آن را داخل پوشه پروژه باز می‌کنید و کارتان را به زبان عادی می‌گویید. ایجنت کد را می‌خواند، برای کارهای چندمرحله‌ای برنامه می‌ریزد، چند فایل را با هم ویرایش می‌کند، فرمان اجرا می‌کند و پیش از نوشتن روی دیسک، تغییر را برای تأیید نشانتان می‌دهد. گوگل این نسخه را برای کسانی ساخته که بیشتر وقتشان در ترمینال می‌گذرد، از راه دور روی سرور کار می‌کنند یا می‌خواهند ایجنت را داخل اسکریپت و خط لوله ساخت به کار بگیرند.

این راهنما قدم‌به‌قدم جلو می‌رود: پیش‌نیازها، نصب، اولین جلسه، فایل قواعد پروژه، مجوزها و محیط ایزوله، دستورهای روزانه، اتصال ابزارهای بیرونی و اجرای خودکار. همه فرمان‌ها، پرچم‌ها و نام فایل‌ها در ۶ مهر ۱۴۰۵ (۲۸ سپتامبر ۲۰۲۶) با مستندات رسمی Antigravity CLI تطبیق داده شده‌اند. در آن روز آخرین نسخه ثبت‌شده در تغییرنامه رسمی نسخه 1.2.9 بود که ۱ مهر منتشر شده است. گوگل نسخه‌های تازه را تدریجی منتشر می‌کند و ممکن است چند روز طول بکشد تا به همه برسند؛ اگر فرمانی رفتار دیگری داشت، صفحه مستندات پیوندشده را ببینید.

تصویر رسمی گوگل برای معرفی Antigravity CLIتصویر رسمی گوگل برای معرفی Antigravity CLI

Antigravity CLI چیست و به چه کاری می‌آید؟

Antigravity نام خانواده‌ای از ابزارهای گوگل است: یک برنامه دسکتاپ با نمای تصویری به نام Antigravity 2.0، افزونه برای چند ویرایشگر کد، یک کتابخانه پایتون برای ساختن ایجنت، و همین نسخه خط فرمان. طبق صفحه معرفی، نسخه ترمینال و نسخه دسکتاپ روی یک هسته ایجنت مشترک کار می‌کنند. یعنی توان استدلال، ابزارها و درکشان از کد یکی است. تنظیمات اصلی و قانون‌های مجوز هم میان این دو همگام می‌شود؛ اگر قانونی را در یکی تغییر دهید، در دیگری هم تغییر می‌کند.

فرق در شیوه کار است. نسخه ترمینال سبک است، کاملاً با صفحه‌کلید کار می‌کند، روی اتصال راه دور و داخل tmux هم مشکلی ندارد و یک حالت بدون رابط کاربری دارد که خروجی‌اش را برنامه‌های دیگر می‌خوانند. اگر گفت‌وگویی در ترمینال پیچیده شد و به نمای تصویری نیاز داشت، می‌توانید آن را به نسخه دسکتاپ ببرید. اگر پیش‌تر از Gemini CLI استفاده می‌کردید، در اولین اجرا می‌توانید افزونه‌ها، مهارت‌ها و تنظیمات قبلی‌تان را یک بار وارد کنید.

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

پیش از نصب: سیستم‌عامل، حساب گوگل و پلن

  • سیستم‌عامل: طبق راهنمای نصب و ورود، این ابزار روی مک، لینوکس و ویندوز به‌صورت بومی اجرا می‌شود. سامانه تازه مجوزها و محیط ایزوله فعلاً روی مک و لینوکس فعال است و ویندوز هنوز از سامانه قبلی استفاده می‌کند.
  • حساب کاربری: یک حساب شخصی گوگل. صفحه پرسش‌های متداول می‌گوید اگر ورود با حساب سازمانی مشکل داشت، با یک نشانی جیمیل امتحان کنید. استفاده از آن برای افراد زیر ۱۸ سال مجاز نیست.
  • پلن: طبق صفحه پلن‌ها و اعتبارها، همه پلن‌ها، حتی بدون اشتراک پولی، یک سهمیه پایه و دسترسی به نسخه خط فرمان دارند. مشترکان پلن‌های Pro و Ultra سهمیه بیشتری می‌گیرند که هر پنج ساعت تازه می‌شود، و تیم‌ها از راه Gemini Enterprise و با شرایط گوگل کلاد به آن دسترسی پیدا می‌کنند. اینکه در هر پلن کدام مدل‌ها قابل انتخاب‌اند، در صفحه مدل‌ها آمده است.

نصب Antigravity CLI روی مک، لینوکس و ویندوز

در مک و لینوکس این فرمان را در ترمینال اجرا کنید. نصب‌کننده فایل اجرایی را در مسیر ~/.local/bin/agy می‌گذارد:

curl -fsSL https://antigravity.google/cli/install.sh | bash

در ویندوز، اگر از PowerShell استفاده می‌کنید:

irm https://antigravity.google/cli/install.ps1 | iex

و اگر در خط فرمان کلاسیک ویندوز هستید:

curl -fsSL https://antigravity.google/cli/install.cmd -o install.cmd && install.cmd && del install.cmd

در ویندوز فایل اجرایی در پوشه C:\Users\<username>\AppData\Local\agy\bin قرار می‌گیرد. روی رایانه کاری یا سروری که داده حساس دارد، پیش از اجرای هر اسکریپت نصبی که از اینترنت می‌آید، یک بار محتوایش را بخوانید.

بعد از نصب، پنجره ترمینال تازه‌ای باز کنید و نصب را بررسی کنید:

agy --help

اگر به‌جای راهنمای فرمان‌ها پیام agy: command not found دیدید، پوشه ~/.local/bin هنوز در مسیر جست‌وجوی شل نیست. صفحه رفع اشکال نشان می‌دهد این مسیر را چطور به فایل ~/.zshrc یا ~/.bashrc اضافه کنید.

به‌روزرسانی را لازم نیست دستی انجام دهید. نسخه خط فرمان یک به‌روزرسان داخلی دارد که در پس‌زمینه نسخه تازه را می‌گیرد، و اجرای دوباره همان اسکریپت نصب هم نسخه موجود را ارتقا می‌دهد. اگر روی سرور ساخت می‌خواهید نسخه ثابت بماند، متغیر AGY_CLI_DISABLE_AUTO_UPDATE=true را در پروفایل شل تنظیم کنید. اگر به‌روزرسانی گیر کرد، طبق همان صفحه رفع اشکال، فایل قفل ~/.gemini/antigravity-cli/updater/update.lock را پاک کنید.

اولین جلسه: ورود، اعتماد به پوشه و چند سؤال بی‌خطر

به پوشه پروژه بروید، مطمئن شوید تغییر ذخیره‌نشده‌ای ندارید و ابزار را اجرا کنید:

cd path/to/your-project
git status
agy

بار اول نوبت ورود است. ابزار ابتدا در انبار امن رمزهای سیستم‌عامل (مثل Keychain در مک) دنبال جلسه ذخیره‌شده می‌گردد و اگر پیدا نکرد، مرورگر را برای ورود به حساب گوگل باز می‌کند. اگر از راه SSH به سرور وصل هستید، مرورگری در کار نیست؛ ابزار یک نشانی چاپ می‌کند که باید آن را در مرورگر رایانه خودتان باز کنید، وارد شوید و کدی را که نمایش داده می‌شود در ترمینال سرور بچسبانید. برای خروج و پاک کردن توکن‌های ذخیره‌شده، داخل جلسه /logout را بزنید.

بعد از ورود، سه سؤال کوتاه می‌پرسد: رنگ‌بندی، نحوه نمایش و اعتماد به پوشه. در نحوه نمایش، حالت تمام‌صفحه برای ترمینال‌های محلی راحت‌تر است و حالت درون‌خطی که خروجی را در تاریخچه عادی ترمینال نگه می‌دارد، برای اتصال راه دور و tmux بهتر است. سؤال سوم مهم‌ترین است: وقتی به پوشه اعتماد کنید، ایجنت همه فایل‌هایش را فهرست می‌کند و می‌تواند درخواست اجرای ابزار بدهد. فقط پوشه همان پروژه‌ای را تأیید کنید که می‌خواهید روی آن کار شود؛ نه پوشه خانه کاربر و نه پوشه والد چند پروژه.

تصویر رسمی از تنظیمات اولین اجرا و نمایش تغییرات در Antigravity CLIتصویر رسمی از تنظیمات اولین اجرا و نمایش تغییرات در Antigravity CLI

در جلسه اول فقط سؤال بپرسید و هنوز چیزی را تغییر ندهید. چند نمونه مناسب:

  • «این پروژه چه کار می‌کند؟ پوشه‌های اصلی و فایلی را که برنامه از آن شروع می‌شود نشان بده.»
  • «فرمان اجرای تست‌ها را پیدا کن و فقط توضیح بده؛ چیزی اجرا نکن.»
  • «کدام فایل‌ها با ورود کاربر و نگهداری نشست سروکار دارند؟ فقط فهرست کن.»

چند میان‌بر هم از همین ابتدا به کار می‌آید: با نوشتن @ مسیر فایل‌ها پیشنهاد داده می‌شود و می‌توانید فایل مشخصی را به درخواست ضمیمه کنید. اگر پیامی را با ! شروع کنید، خودتان مستقیم یک فرمان شل اجرا می‌کنید. کلید Esc کار در حال اجرا را فوراً متوقف می‌کند. برای عوض کردن مدل، داخل جلسه /model را بزنید؛ بیرون از جلسه هم فرمان agy models فهرست شناسه مدل‌های در دسترس حسابتان را نشان می‌دهد.

فایل AGENTS.md: قواعدی که ایجنت همیشه می‌خواند

هر جلسه تازه چیزی از جلسه قبل به یاد ندارد. برای اینکه قواعد ثابت پروژه را هر بار تکرار نکنید، طبق راهنمای قواعد یک فایل AGENTS.md یا GEMINI.md در ریشه پروژه بسازید. این فایل سربرگ خاصی لازم ندارد و محتوایش همیشه در کار ایجنت لحاظ می‌شود. یک نمونه:

# Rules for this repository
- Install: pnpm install
- Run one test file: pnpm vitest run path/to/file.test.ts
- API handlers live in src/api/; keep them thin and move logic to src/services/
- Do not touch infra/ or any .env file
- Every change ends with: pnpm lint && pnpm test

چند نکته درباره جای این فایل‌ها و رفتارشان:

  • قواعد مخصوص یک پوشه: اگر یک AGENTS.md در زیرپوشه‌ای بگذارید، هر وقت ایجنت فایلی از آن پوشه را بخواند یا ویرایش کند، آن قواعد هم اضافه می‌شود و در تعارض، قاعده دقیق‌تر برنده است.
  • قواعد سراسری: فایل ~/.gemini/AGENTS.md یا ~/.gemini/GEMINI.md روی همه پروژه‌های شما اعمال می‌شود.
  • قواعد جداگانه: هر فایل داخل پوشه .agents/rules/ باید سربرگ YAML با کلید trigger داشته باشد. مقدارهای مجاز always_on، model_decision، glob و manual هستند و گوگل هشدار می‌دهد قاعده‌ای که این کلید را نداشته باشد یا مقدارش غلط باشد، بی‌صدا نادیده گرفته می‌شود.
  • اندازه: از نسخه 1.2.7 قواعد بودجه جداگانه‌ای معادل ۲۰ هزار توکن دارند. فایل‌ها را کوتاه نگه دارید تا چیزی از آن‌ها جا نیفتد.

یک قاعده جداگانه که فقط هنگام کار با فایل‌های مهاجرت پایگاه داده فعال می‌شود، این شکلی است:

---
trigger: glob
globs: "*.sql"
description: "Rules for database migration files"
---
# Migration rules
- Never drop or rename a column in a single migration
- Add new columns as nullable first

گوگل تفاوت قاعده و مهارت را این‌طور توضیح می‌دهد: قاعده برای محدودیت‌ها و اصول ثابت است، مثل «به پوشه زیرساخت دست نزن»، و مهارت برای روندهای چندمرحله‌ای، مثل «مراحل انتشار نسخه». یک نکته را هم در نظر بگیرید: قاعده راهنمای مدل است، نه قفل. اگر کاری باید قطعاً ممنوع باشد، جلویش را با قانون‌های مجوز بگیرید که در بخش بعد آمده است. رمز عبور و کلید دسترسی را هرگز در این فایل‌ها ننویسید.

مجوزها، حالت‌های اجرا و محیط ایزوله

کنترل دسترسی در این ابزار سه لایه جدا دارد و بهتر است هر سه را بشناسید.

لایه اول: سطح کلی مجوز ابزارها. کلید toolPermission در فایل تنظیمات تعیین می‌کند ایجنت پیش از کدام کارها بپرسد. طبق مرجع خط فرمان چهار مقدار دارد:

مقداررفتارمناسب برای
request-review (پیش‌فرض)پیش از نوشتن فایل، اجرای فرمان و دسترسی به وب می‌پرسدشروع کار و بیشتر پروژه‌ها
proceed-in-sandboxفرمان‌های داخل محیط ایزوله را خودکار اجرا می‌کند و برای بقیه می‌پرسدکار روزانه روی مک و لینوکس با محیط ایزوله روشن
strictپیش از هر ابزاری که فقط خواندنی نباشد می‌پرسدپروژه‌های حساس
always-proceedهیچ‌وقت نمی‌پرسدفقط محیط آزمایشی دورریختنی

کلید جداگانه artifactReviewPolicy هم مشخص می‌کند پیش از نوشتن کد، خروجی‌ها برای بازبینی نشان داده شوند یا نه. مقدار پیش‌فرضش asks-for-review است و بهتر است همین بماند.

لایه دوم: حالت اجرا. طبق صفحه حالت‌های اجرا، در حالت default ایجنت پیش از هر ویرایش فایل می‌ایستد و تغییر را رنگی نشان می‌دهد. کلید y تغییر را می‌پذیرد، n آن را رد می‌کند و f نمای کامل تغییرات را باز می‌کند. در حالت accept-edits ویرایش فایل‌ها بدون پرسش انجام می‌شود، و در حالت plan ایجنت فقط با ابزارهای خواندنی بررسی می‌کند و پیش از نوشتن هر کدی، برنامه‌اش را برای تأیید ارائه می‌دهد. با Shift+Tab به ترتیب میان default، accept-edits و plan جابه‌جا می‌شوید و برای شروع مستقیم در یک حالت، از پرچم --mode استفاده کنید؛ مثلاً agy --mode=plan. حالت اجرا فقط به ویرایش فایل مربوط است و اجرای فرمان‌های شل همچنان تابع قانون‌های مجوز می‌ماند.

لایه سوم: قانون‌های دقیق. در فایل ~/.gemini/antigravity-cli/settings.json سه فهرست allow، ask و deny تعریف می‌کنید و هر قانون به شکل action(target) نوشته می‌شود. مستندات مجوزها ترتیب اولویت را صریح گفته است: اول رد، بعد پرسش، بعد اجازه. این نمونه محیط ایزوله را روشن می‌کند، فرمان‌های git و اسکریپت‌های ساخت و تست را آزاد می‌گذارد، برای git push حتماً می‌پرسد و حذف گسترده، sudo و نوشتن داخل پوشه .git را می‌بندد:

{
    "toolPermission": "proceed-in-sandbox",
    "enableTerminalSandbox": true,
    "permissions": {
        "allow": ["command(git)", "command(regex:npm run (build|lint|test))", "write_file(src/)"],
        "ask": ["command(git push)"],
        "deny": ["command(rm -rf)", "command(sudo)", "write_file(.git/)"]
    }
}

چون پرسش بر اجازه مقدم است، git status بی‌سؤال اجرا می‌شود ولی git push با وجود قانون command(git) همچنان تأیید می‌خواهد. کارهای دیگر هم تعریف‌شده‌اند: read_file و write_file برای مسیرها، read_url برای دامنه‌های وب، mcp برای ابزارهای سرورهای MCP و unsandboxed برای فرمان‌هایی که باید بیرون از محیط ایزوله اجرا شوند. خواندن و نوشتن داخل پوشه پروژه به‌طور پیش‌فرض آزاد است و هر چیزی بیرون از آن اجازه می‌خواهد. برای مدیریت این قانون‌ها داخل جلسه، دستور /permissions را بزنید.

محیط ایزوله. با "enableTerminalSandbox": true یا پرچم agy --sandbox، طبق صفحه محیط ایزوله فرمان‌های ایجنت در لینوکس داخل فضای نام‌های هسته و در مک با sandbox-exec اجرا می‌شوند. در این حالت فرمان‌ها فقط در پوشه پروژه، پوشه‌های موقت و حافظه‌های نهان ساخت می‌نویسند، فایل‌های حساسی مثل ~/.ssh و .env در دسترس نیستند و دسترسی شبکه فقط برای دامنه‌هایی باز است که با read_url اجازه داده‌اید. مقدار پیش‌فرض این کلید در نسخه خط فرمان false است، پس خودتان روشنش کنید. کلید allowNonWorkspaceAccess را هم که دسترسی به بیرون از پوشه پروژه را می‌دهد، خاموش نگه دارید.

تصویر رسمی پنل تنظیمات Antigravity CLIتصویر رسمی پنل تنظیمات Antigravity CLI

پرچم --dangerously-skip-permissions همه درخواست‌ها را خودکار تأیید می‌کند. روی رایانه اصلی‌تان یا هر جایی که کلید و داده واقعی هست از آن استفاده نکنید. برای بحث مفصل‌تر درباره این موضوع، مقاله امنیت مجوز ابزارهای هوش مصنوعی را ببینید.

دستورهای روزمره داخل جلسه

هر پیامی که با / شروع شود یک دستور است. فهرست کامل در مرجع خط فرمان آمده و این‌ها پرکاربردترین‌ها هستند:

دستورکاربرد
/helpفهرست دستورها و کلیدهای میان‌بر
/config یا /settingsپنل تنظیمات
/permissionsمدیریت قانون‌های مجوز
/modelانتخاب مدل، که برای جلسه‌های بعد هم می‌ماند
/diffنمایشگر تغییرات فایل‌ها، نوبت‌ها و کامیت‌ها
/rewind یا /undoبرگشتن به یک پیام قبلی در گفت‌وگو
/forkساختن نسخه موازی از گفت‌وگو برای امتحان راه دیگر
/resumeادامه یک گفت‌وگوی قبلی
/contextدیدن اینکه حافظه کاری مدل با چه چیزهایی پر شده است
/usageدیدن مصرف سهمیه مدل
/mcpمدیریت سرورهای MCP
/skillsدیدن مهارت‌های بارگذاری‌شده
/agentsدیدن ایجنت‌های سفارشی و ساب‌ایجنت‌های در حال کار
/clearشروع گفت‌وگوی تازه

چند کلید هم مدام به کار می‌آید: Shift+Tab برای عوض کردن حالت اجرا، Esc برای متوقف کردن کار جاری، Ctrl+R برای باز کردن پنل بازبینی خروجی‌ها و Ctrl+G برای نوشتن درخواست‌های طولانی در ویرایشگر متن خودتان. وقتی ابزار را می‌بندید، فرمان دقیق ادامه همان جلسه را چاپ می‌کند.

چطور از Antigravity کار بخواهید

این ایجنت وقتی بهترین نتیجه را می‌دهد که درخواستتان به چهار سؤال جواب بدهد: چه چیزی خراب است، کدام بخش کد اجازه تغییر دارد، چه چیزی باید دست‌نخورده بماند و کدام آزمون درستی اصلاح را نشان می‌دهد. این دو را مقایسه کنید:

  • درخواست مبهم: «فرم ثبت‌نام را درست کن.»
  • درخواست روشن: «وقتی کاربر دو بار پشت سر هم روی دکمه ثبت‌نام می‌زند، دو حساب ساخته می‌شود. اول با یک تست همین مشکل را بازتولید کن، بعد کوچک‌ترین اصلاح ممکن را فقط در پوشه src/signup انجام بده. به ساختار جدول کاربران دست نزن. در پایان تست‌های همان پوشه را اجرا کن و بگو چه ریسکی باقی مانده است.»

راهنمای بهترین روش‌ها تأکید می‌کند که مؤثرترین کار این است که ایجنت راهی برای سنجیدن کار خودش داشته باشد، یعنی تست یا فرمان ساخت. برای تغییرهای بزرگ‌تر این ترتیب جواب می‌دهد:

  1. با Shift+Tab به حالت plan بروید، یا درخواست را با /plan شروع کنید، و بخواهید اول بررسی کند و برنامه اجرا بنویسد.
  2. برنامه را بخوانید. اگر فایل اشتباهی در آن هست یا تستی جا افتاده، همان‌جا اصلاحش کنید.
  3. به حالت default برگردید تا هر ویرایش فایل را پیش از ذخیره ببینید و با y یا n جواب دهید.
  4. بخواهید تست‌های مرتبط را اجرا کند و خروجی را خودتان نگاه کنید.
  5. کل تغییرات را با /diff یا git diff مرور کنید، نه فقط خلاصه‌ای را که ایجنت نوشته است.
  6. اگر مسیر اشتباه بود، با /rewind برگردید؛ اگر مطمئن نیستید کدام راه بهتر است، با /fork نسخه موازی بسازید و راه دوم را آنجا امتحان کنید.
  7. کامیت را خودتان انجام دهید.

گزارش پایانی ایجنت فقط توصیف کار است، نه اثبات آن. اثبات، خروجی تست و تغییرات واقعی فایل‌هاست. در کدهای ورود کاربر، پرداخت، داده شخصی و ساختار پایگاه داده، بازبینی انسانی را کنار نگذارید.

MCP، مهارت‌ها و ساب‌ایجنت‌ها

MCP استانداردی است که ایجنت را به ابزارهای بیرونی مثل پایگاه داده، سامانه مدیریت کار یا مستندات داخلی وصل می‌کند. طبق مستندات MCP در Antigravity، ساده‌ترین راه، مدیر تعاملی است که با /mcp باز می‌شود. تعریف سرورها در دو فایل نگه داشته می‌شود: ~/.gemini/config/mcp_config.json برای همه پروژه‌ها و .agents/mcp_config.json برای همان پروژه. ساختار فایل این است:

{
  "mcpServers": {
    "sqlite-explorer": {
      "command": "node",
      "args": ["/usr/local/bin/sqlite-mcp-server.js"],
      "env": { "SQLITE_DB_PATH": "/var/data/app.db" }
    },
    "my-remote-server": {
      "serverUrl": "https://api.example.com/mcp/",
      "headers": { "Authorization": "Bearer YOUR_API_TOKEN" },
      "disabledTools": ["delete_records"]
    }
  }
}

سرورهایی که روی سیستم خودتان اجرا می‌شوند با command و args تعریف می‌شوند و سرورهای راه دور با serverUrl. مستندات تصریح می‌کند کلیدهای قدیمی url و httpUrl پذیرفته نمی‌شوند. با disabledTools ابزارهایی را که نمی‌خواهید مدل ببیند پنهان می‌کنید و ابزارهای MCP به‌طور پیش‌فرض پیش از اجرا اجازه می‌خواهند؛ اگر به سروری اعتماد کامل دارید، با قانونی مثل mcp(linter/*) آن را آزاد کنید. هر سروری که محتوای بیرونی مثل صفحه وب یا تیکت را به جلسه می‌آورد، می‌تواند دستورهای مخرب هم با خودش بیاورد. معماری امن این اتصال‌ها را در راهنمای معماری یکپارچه‌سازی MCP شرح داده‌ایم.

مهارت‌ها پوشه‌هایی هستند که یک فایل SKILL.md دارند و روندی تکرارشونده را توضیح می‌دهند؛ مثلاً مراحل بازبینی کد یا انتشار نسخه. سربرگ این فایل یک description لازم دارد که ایجنت با خواندنش تصمیم می‌گیرد مهارت به کار فعلی مربوط است یا نه. مهارت‌های پروژه در .agents/skills/ و مهارت‌های شخصی شما در ~/.gemini/antigravity-cli/skills/ قرار می‌گیرند و /skills فهرست مهارت‌های بارگذاری‌شده را نشان می‌دهد.

ساب‌ایجنت‌ها ایجنت‌های فرعی هستند که ایجنت اصلی برای بخش‌های مستقل یک کار در پس‌زمینه راه می‌اندازد؛ مثلاً یکی مسیر کد را بررسی می‌کند و دیگری تست‌ها را. پنل /agents کار آن‌ها را نشان می‌دهد و کلید Alt+J شما را به ساب‌ایجنتی می‌برد که منتظر تأیید است. دو ساب‌ایجنت را هم‌زمان روی ویرایش فایل‌های یکسان نگذارید.

تصویر رسمی گوگل از سه ساب‌ایجنت که برای یک کار راه افتاده‌اندتصویر رسمی گوگل از سه ساب‌ایجنت که برای یک کار راه افتاده‌اند

اجرای خودکار با agy -p

وقتی کاری را چند بار در حالت تعاملی با موفقیت انجام دادید، می‌توانید آن را در اسکریپت یا خط لوله CI اجرا کنید. طبق صفحه حالت بدون رابط، پرچم -p یک درخواست را اجرا می‌کند، جواب را چاپ می‌کند و خارج می‌شود. جواب به خروجی استاندارد می‌رود و خطاها و پیام‌های وضعیت به خروجی خطا، تا خروجی تمیز بماند:

# Plain text answer with higher reasoning effort
agy -p "Outline a plan to add caching to this service." --effort high

# One JSON object for scripts; read the answer field with jq
agy -p "Name three popular version control systems, comma-separated." --output-format json | jq -r '.response'

# Continue the most recent conversation
agy -p "Now explain your previous answer in more detail" --continue

پرچم‌های مفید دیگر: --output-format که text، json یا stream-json می‌گیرد، --json-schema برای اینکه جواب در قالب مشخصی برگردد، --model با شناسه‌ای که agy models نشان می‌دهد، --conversation برای ادامه یک گفت‌وگوی مشخص با شناسه‌اش، --print-timeout برای سقف زمان اجرا و --sandbox برای روشن کردن محیط ایزوله. اگر مدل را با --model مشخص کنید و آن مدل وجود نداشته باشد، اجرا با خطا تمام می‌شود و بی‌صدا مدل دیگری انتخاب نمی‌شود.

در این حالت کسی نیست که به درخواست مجوز جواب دهد. ابزاری که تأیید لازم داشته باشد رد می‌شود، اجرا ادامه پیدا می‌کند و پیامی در خروجی خطا چاپ می‌شود. پس فرمان‌های لازم را از پیش در فهرست allow بگذارید، نه اینکه با --dangerously-skip-permissions همه‌چیز را باز کنید. اجرای بدون رابط از اطلاعات ورود ذخیره‌شده استفاده می‌کند؛ پس یک بار به‌صورت تعاملی وارد شوید. برای سرورهای ساخت، راهنمای نصب راه دیگری هم گذاشته است: مقدار "modelProvider": "gemini" را در فایل تنظیمات بگذارید و کلید Gemini API را در متغیر GEMINI_API_KEY قرار دهید تا درخواست‌ها بدون حساب کاربری مستقیم به Gemini API بروند. خروجی موفق هم فقط یعنی اجرا تمام شده، نه اینکه کد درست است؛ تغییرات را پیش از ادغام بازبینی کنید.

راه‌اندازی ایجنت برنامه‌نویسی برای تیم

وقتی ایجنت از رایانه یک نفر به کل تیم می‌رسد، تصمیم‌های زیادی باید از پیش گرفته شود. پیش از راه‌اندازی، این فهرست را کامل کنید:

  • مدل و سرویس: کدام مدل و سرویس از نظر هزینه، کیفیت و محل نگهداری داده برای سازمان شما مناسب است؛
  • فایل قواعد مشترک: یک AGENTS.md کوتاه در مخزن git با فرمان‌های ساخت و تست و کارهای ممنوع؛
  • مجوزهای تیمی: چون فایل تنظیمات این ابزار در پوشه خانه هر نفر است، یک settings.json استاندارد با محیط ایزوله روشن و قانون‌های رد مشترک آماده کنید و به همه بدهید؛
  • قاعده بازبینی: هیچ تغییری بدون بازبینی انسانی ادغام نشود، به‌خصوص در کدهای مالی و امنیتی؛
  • سقف هزینه: سقف مصرف ماهانه به تومان برای هر نفر و گزارش ماهانه مصرف؛
  • سنجش نتیجه: چند کار واقعی و تکراری تیم را انتخاب کنید و زمان و کیفیت انجامشان را پیش و پس از راه‌اندازی اندازه بگیرید.

اگر قصد دارید چنین ایجنتی را در تیم برنامه‌نویسی سازمانتان به کار بگیرید، با ابزار و مدلی متناسب با کارتان و با قاعده‌های روشن برای مجوز و بازبینی، با ما صحبت کنید: تماس تلفنی با ۰۹۰۱ ۵۵۵ ۵۶۵۱ یا پیام در واتس‌اپ. جزئیات این خدمت را در صفحه آموزش هوش مصنوعی و ایجنت برنامه‌نویسی برای تیم‌ها هم می‌توانید ببینید.

یادداشت منابع (بازبینی‌شده در ۶ مهر ۱۴۰۵ / ۲۰۲۶-۰۹-۲۸)

همه فرمان‌ها، پرچم‌ها و تنظیمات این راهنما در تاریخ بالا با این صفحه‌های رسمی تطبیق داده شد:

#Google Antigravity#Antigravity CLI#آموزش Antigravity#ایجنت برنامه‌نویسی#Gemini#MCP#برنامه‌نویسی با هوش مصنوعی

مطالب مرتبط

این ابزار را در تیم خودتان راه بیندازید

اگر می‌خواهید ایجنت‌های هوش مصنوعی و اتوماسیون این راهنما را در تیم نرم‌افزار یا فرایندهای سازمانتان به کار بگیرید، از یک آزمایش کوچک شروع کنید که بتوانید نتیجه‌اش را بسنجید.