جواب کوتاه: اگر دو ایجنت برنامه‌نویسی را در یک پوشهٔ پروژه رها کنید، دیر یا زود روی فایل‌های هم می‌نویسند، شاخهٔ گیت را زیر پای هم عوض می‌کنند و تست‌های یکی وسط تغییرات نیمه‌کارهٔ دیگری اجرا می‌شود. راه‌حل سه بخش دارد: هر ایجنت در یک git worktree جدا و روی شاخهٔ خودش کار کند، همه از یک فایل دستورالعمل مشترک (AGENTS.md) پیروی کنند و کارها طوری تقسیم شوند که دو ایجنت هم‌زمان سراغ یک بخش از کد نروند. Orca این روال را در یک محیط جمع کرده که می‌تواند جای IDE را هم بگیرد، و تیم فنی سواپ‌ولت حدود شش ماه است با همین روش کار می‌کند.

این راهنما برای برنامه‌نویسی است که Claude Code، Codex یا Antigravity را دست‌کم یک بار امتحان کرده و حالا می‌خواهد چند تا را با هم به کار بگیرد. اگر هنوز با Claude Code آشنا نیستید، اول کلود کد چیست را بخوانید.

چرا دو ایجنت در یک پوشه به هم می‌خورند؟

ایجنت برنامه‌نویسی، برخلاف یک چت‌بات، مستقیم روی دیسک کار می‌کند: فایل را باز می‌کند، تغییر می‌دهد، دستور اجرا می‌کند و گاهی کامیت هم می‌زند. یک پوشهٔ گیت معمولی فقط یک نسخه از فایل‌ها، یک ناحیهٔ آماده‌سازی (index) و یک شاخهٔ فعال (HEAD) دارد. وقتی دو ایجنت هم‌زمان در همین پوشه کار کنند، هر دو به همین سه چیز دست می‌زنند. OpenAI هم در راهنمای بهترین روش‌های Codex اجرای هم‌زمان چند کار روی فایل‌های یکسان بدون worktree را جزو اشتباه‌های رایج آورده است.

جدول زیر تداخل‌هایی را که در عمل پیش می‌آید، با راه جلوگیری از هر کدام، کنار هم گذاشته است:

تداخل

چه می‌بینید؟

راه‌حل

ویرایش هم‌زمان یک فایل

تغییرات یک ایجنت با ذخیرهٔ دیگری پاک می‌شود

هر ایجنت در worktree خودش

عوض شدن شاخه

ایجنت اول ناگهان روی شاخهٔ دیگری کار می‌کند

هر شاخه فقط در یک worktree

تست روی کد نیمه‌کاره

نتیجهٔ تست به تغییرات ایجنت دیگر بستگی پیدا می‌کند

تست و بیلد در worktree همان ایجنت

فایل‌های .env و وابستگی‌ها

پروژه در worktree تازه بالا نمی‌آید

فایل .worktreeinclude و اسکریپت راه‌اندازی

پورت سرور توسعه

خطای EADDRINUSE

پورت جدا برای هر worktree

دیتابیس و سرویس‌های محلی

مایگریشن یک شاخه دیتابیس شاخهٔ دیگر را به هم می‌ریزد

دیتابیس یا کانتینر جدا برای هر worktree

دستورالعمل‌های ناهمخوان

هر ایجنت سبک و دستورهای خودش را دارد

یک AGENTS.md مشترک

تعارض موقع ادغام

آخر کار یک merge conflict بزرگ

تقسیم کار بر اساس ماژول و شاخه‌های کوتاه‌عمر

git worktree چیست و چطور کار می‌کند؟

git worktree قابلیتی در خود گیت است که به یک مخزن اجازه می‌دهد چند پوشهٔ کاری داشته باشد و در هر کدام شاخهٔ دیگری باز باشد. همهٔ این پوشه‌ها یک تاریخچهٔ مشترک دارند و کامیتی که در یکی می‌زنید، بلافاصله در بقیه هم هست. ولی فایل‌ها، index و HEAD هر پوشه مال خودش است. پس اگر هر ایجنت را در worktree خودش اجرا کنید، ایجنت‌ها نه فایل‌های هم را تغییر می‌دهند و نه شاخهٔ هم را عوض می‌کنند.

نمودار یک مخزن گیت مشترک با سه worktree جدا برای Claude Code، Codex و Antigravity؛ هر کدام شاخه و پورت خودش را دارد و کار با Pull Request در main ادغام می‌شود

ساختن worktree یک دستور است. از داخل پوشهٔ اصلی پروژه:

`git worktree add ../app-auth -b feat/auth`

این دستور پوشهٔ `../app-auth` را می‌سازد، شاخهٔ تازهٔ `feat/auth` را از روی شاخهٔ فعلی درست می‌کند و آن را در همان پوشه باز می‌کند. با `git worktree list` فهرست همهٔ worktreeها و شاخهٔ هر کدام را می‌بینید. وقتی کار تمام شد، `git worktree remove ../app-auth` پوشه را پاک می‌کند. اگر پوشه‌ای را دستی پاک کرده‌اید، `git worktree prune` اطلاعات جامانده‌اش را از مخزن برمی‌دارد.

دو نکته را از همین اول بدانید:

  • هر شاخه فقط در یک worktree. گیت اجازه نمی‌دهد شاخه‌ای را که در یک worktree باز است، در worktree دیگری هم باز کنید. همین محدودیت جلوی تداخل را می‌گیرد، ولی یعنی هر ایجنت شاخهٔ خودش را لازم دارد.
  • worktree تازه فایل‌های محلی را ندارد. هر چیزی که در `.gitignore` است، مثل `node_modules`، `.env` و پوشه‌های کش، در worktree تازه نیست و باید دوباره ساخته یا کپی شود. پایین‌تر می‌گوییم چطور.

Claude Code، Codex و Antigravity با worktree چطور کار می‌کنند؟

  • Claude Code خودش worktree می‌سازد. طبق راهنمای کارهای رایج Claude Code، دستور `claude --worktree feature-auth` یک جلسهٔ جدا روی worktree و شاخهٔ تازه باز می‌کند. همین دستور را با اسم دیگری در ترمینال دوم بزنید تا جلسهٔ موازی دوم را هم داشته باشید. فقط مخزن باید دست‌کم یک کامیت داشته باشد.
  • Codex در اپ دسکتاپ ChatGPT، زیر کادر پیام، گزینهٔ Worktree دارد. طبق راهنمای worktree در Codex، Codex برای هر گفت‌وگو یک worktree در مسیر `$CODEX_HOME/worktrees` می‌سازد که به‌طور پیش‌فرض روی هیچ شاخه‌ای نیست (detached HEAD). اگر نتیجه را پسندیدید، با دکمهٔ Create branch here آن را به شاخه تبدیل می‌کنید یا با Handoff گفت‌وگو و کد را به پوشهٔ اصلی پروژه می‌برید. اگر با Codex در ترمینال کار می‌کنید، worktree را خودتان با گیت بسازید و Codex را داخل همان پوشه اجرا کنید.
  • Antigravity، محیط برنامه‌نویسی ایجنت‌محور گوگل، اجازه می‌دهد چند گفت‌وگوی ایجنت را موازی اجرا کنید و همه را در Agent Manager ببینید. برای اینکه ایجنت‌های Antigravity با ابزارهای دیگر روی فایل‌های یکسان کار نکنند، هر worktree را به‌عنوان یک workspace جدا در Antigravity باز کنید. نسخهٔ خط فرمانش هم با دستور `agy` اجرا می‌شود.

یک دستورالعمل برای همهٔ ایجنت‌ها: AGENTS.md

وقتی سه ایجنت روی یک پروژه کار می‌کنند، باید چند چیز را یکسان بدانند: پروژه چطور بیلد می‌شود، تست با چه دستوری اجرا می‌شود، سبک کد چیست و به کدام بخش‌ها نباید دست زد. اگر هر ابزار فایل دستورالعمل خودش را داشته باشد، این فایل‌ها کم‌کم با هم فرق پیدا می‌کنند. AGENTS.md برای همین ساخته شده است: یک فایل Markdown ساده در ریشهٔ پروژه که ایجنت‌های شرکت‌های مختلف آن را می‌خوانند. این قالب حالا زیر نظر Agentic AI Foundation، بنیادی در Linux Foundation، اداره می‌شود.

هر سه ابزار این راهنما AGENTS.md را می‌شناسند:

ابزار

AGENTS.md را چطور می‌خواند؟

فایل‌های دیگرش

Codex

مستقیم؛ فایلی که به پوشهٔ کار نزدیک‌تر است اولویت دارد

AGENTS.override.md

Antigravity

مستقیم، در هر پوشه‌ای از پروژه

GEMINI.md و پوشهٔ .agents/rules

Claude Code

مستقیم وقتی CLAUDE.md نباشد (نسخهٔ 2.1.277 به بعد)، یا با import در CLAUDE.md

CLAUDE.md و پوشهٔ .claude/rules

ساده‌ترین چیدمان این است که همهٔ دستورالعمل‌ها را در AGENTS.md بنویسید و اگر CLAUDE.md هم دارید، فقط این یک خط را در آن بگذارید:

`@AGENTS.md`

طبق راهنمای حافظهٔ Claude Code، CLAUDE.md می‌تواند فایل‌های دیگر را با `@مسیر` وارد کند. این‌طور Claude همان دستورالعمل‌هایی را می‌خواند که Codex و Antigravity می‌خوانند و فقط یک فایل را به‌روز نگه می‌دارید. مخزن محتوای همین وبلاگ هم دقیقاً همین چیدمان را دارد.

در AGENTS.md چه بنویسیم؟

کوتاه و دقیق. OpenAI در راهنمای Codex نوشته یک AGENTS.md کوتاه و درست از یک فایل بلند پر از قاعدهٔ مبهم مفیدتر است و Anthropic هم پیشنهاد می‌کند CLAUDE.md زیر ۲۰۰ خط بماند. برای کار موازی این چند مورد از همه مهم‌ترند:

  • دستورهای نصب وابستگی‌ها، بیلد، تست و lint، دقیقاً همان‌طور که باید اجرا شوند.
  • اینکه سرور توسعه پورتش را از متغیر محیطی بخواند، نه از یک عدد ثابت.
  • قاعدهٔ شاخه و کامیت: هر کار روی شاخهٔ خودش، کامیت‌های کوچک و هیچ push مستقیمی روی main.
  • بخش‌هایی که ایجنت نباید بدون اجازه تغییر بدهد، مثل مایگریشن‌های دیتابیس یا تنظیمات CI.
  • اینکه پیش از اعلام «تمام شد»، تست‌های مرتبط را اجرا کند.

در monorepo برای هر پکیج یک AGENTS.md جدا بگذارید. ایجنت‌ها نزدیک‌ترین فایل به فایلی را که ویرایش می‌کنند می‌خوانند، پس هر بخش دستورالعمل خودش را دارد.

راه‌اندازی worktree تازه: .env، وابستگی‌ها، پورت و دیتابیس

worktree تازه یک کپی تمیز از مخزن است و هیچ فایل gitignoreشده‌ای در آن نیست. این خلأ را از سه راه پر کنید:

  1. کپی فایل‌های محلی با `.worktreeinclude`. فایلی به همین اسم در ریشهٔ مخزن بسازید و مسیر فایل‌هایی مثل `.env` و `.env.local` را در آن بنویسید. Codex و Orca موقع ساخت worktree این فایل‌ها را کپی می‌کنند و Claude Code هم از همین فایل پشتیبانی می‌کند.
  2. اسکریپت راه‌اندازی. نصب وابستگی‌ها و کارهای اولیه را به اسکریپتی بسپارید که با ساخت هر worktree اجرا شود. Codex اسم این را local environment گذاشته و Orca هم برای هر مخزن اسکریپت راه‌اندازی (setup) دارد که موقع ساخت worktree اجرا می‌شود.
  3. پوشه‌های سنگین مشترک. Orca می‌تواند پوشه‌های بزرگ و قابل بازسازی، مثل `node_modules` یا `.cache`، را به‌جای کپی از پوشهٔ اصلی لینک کند. این کار را فقط وقتی بکنید که وابستگی‌های شاخه‌ها یکی است؛ اگر یکی از ایجنت‌ها پکیجی اضافه یا ارتقا می‌دهد، worktree او پوشهٔ خودش را لازم دارد.

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

`PORT=3001 npm run dev`

برای دیتابیس محلی هم یا برای هر worktree یک دیتابیس جدا بسازید یا سرویس‌ها را با Docker Compose و اسم پروژهٔ جدا بالا بیاورید (`docker compose -p app-auth up`) تا کانتینرها و volumeهای هر شاخه از هم جدا بمانند. این‌طور مایگریشنی که یک ایجنت می‌نویسد، دیتابیس ایجنت دیگر را خراب نمی‌کند.

کار را چطور بین ایجنت‌ها تقسیم کنیم؟

worktree جلوی تداخل فایل‌ها را می‌گیرد، ولی اگر دو ایجنت روی یک ماژول کار کنند، تعارض فقط عقب می‌افتد و موقع ادغام سر می‌رسد. سه الگو در عمل خوب جواب می‌دهد.

کارهای مستقل، موازی

هر ایجنت یک کار جدا می‌گیرد؛ مثلاً Claude Code یک قابلیت تازه در بک‌اند می‌سازد، Codex یک باگ را رفع می‌کند و Antigravity صفحهٔ تازه‌ای در رابط کاربری درست می‌کند. شرطش این است که کارها فایل مشترک زیادی نداشته باشند. پیش از شروع، برای هر کار یک خط بنویسید که به کدام پوشه‌ها دست می‌زند.

یک کار، چند ایجنت

برای باگی که سخت پیدا می‌شود یا تصمیمی که چند راه دارد، یک پرامپت یکسان را به دو یا سه ایجنت بدهید، هر کدام در worktree خودش. بعد diffها را کنار هم بگذارید و بهترین را ادغام کنید. مستندات Orca همین را یکی از کاربردهای اصلی‌اش می‌داند. این الگو سهمیه را چند برابر مصرف می‌کند، پس آن را برای کارهایی نگه دارید که ارزشش را دارند.

نویسنده و بازبین

یک ایجنت کد را می‌نویسد و ایجنت دیگر، بهتر است از یک شرکت دیگر، diff را بازبینی می‌کند. نگاه یک مدل دیگر گاهی چیزهایی را پیدا می‌کند که مدل نویسنده از کنارشان گذشته است. تصمیم آخر هم با شماست.

چند قاعده هم ادغام را بی‌دردسر نگه می‌دارد:

  • شاخه‌ها را کوتاه‌عمر نگه دارید و هر کار را با یک Pull Request ادغام کنید.
  • بعد از هر ادغام در main، بقیهٔ worktreeها را روی main تازه rebase کنید تا تعارض‌ها کوچک بمانند.
  • تعداد ایجنت‌ها را با توان بازبینی خودتان تنظیم کنید. هر diff را بالاخره یک نفر باید بخواند، پس بیشتر از آنچه می‌توانید بازبینی کنید ایجنت اجرا نکنید. با دو یا سه ایجنت شروع کنید.
  • مصرف سهمیه را زیر نظر داشته باشید؛ چند ایجنت هم‌زمان سقف اشتراک را زودتر پر می‌کنند.

کار با چند پروژه هم‌زمان

اگر روی چند مخزن کار می‌کنید، مثلاً بک‌اند و فرانت‌اند جدا، این چند نکته نظم کار را حفظ می‌کند:

  • هر مخزن AGENTS.md خودش را داشته باشد. ترجیح‌های شخصی‌تان را، که در همهٔ پروژه‌ها یکی است، در فایل سراسری هر ابزار بگذارید؛ مثلاً `~/.claude/CLAUDE.md` برای Claude Code و `~/.gemini/AGENTS.md` برای Antigravity.
  • برای قابلیتی که به هر دو مخزن دست می‌زند، در هر مخزن یک worktree با اسم شاخهٔ یکسان بسازید تا ردگیری‌اش ساده بماند. Orca برای همین حالت «گروه پروژه» دارد که چند مخزن را زیر یک پروژه جمع می‌کند.
  • worktreeها را بیرون از پوشهٔ مخزن بسازید، مثلاً در یک پوشهٔ کناری، یا ساختنشان را به خود ابزار بسپارید تا پوشهٔ اصلی شلوغ نشود.
  • آخر هر کار worktree را پاک کنید و هر چند وقت یک بار خروجی `git worktree list` را نگاه کنید تا پوشهٔ فراموش‌شده‌ای نماند.

Orca چیست؟ محیطی برای چند ایجنت که جای IDE را می‌گیرد

همهٔ کارهای بالا را می‌شود با چند ترمینال و چند دستور گیت انجام داد. ولی وقتی کارها زیاد می‌شود، اینکه کدام ایجنت در کدام پوشه چه می‌کند، خودش کاری جدا می‌شود. Orca برای همین ساخته شده است: یک برنامهٔ دسکتاپ رایگان و متن‌باز (با مجوز MIT) برای macOS، ویندوز و لینوکس که شرکت Stably AI آن را ساخته و خودش «محیط توسعهٔ ایجنت» می‌نامد. در Orca هر کار worktree، ترمینال ایجنت و تب مرورگر مخصوص خودش را دارد.

Orca مدل هوش مصنوعی نیست و اشتراک جدایی هم نمی‌فروشد. ایجنت‌هایی را اجرا می‌کند که خودتان دارید: Claude Code، Codex، Antigravity، Gemini، Cursor، Grok، GitHub Copilot، OpenCode و ده‌ها ایجنت دیگر. به گفتهٔ مخزن Orca در گیت‌هاب، هر ایجنتی که در ترمینال اجرا شود، در Orca هم اجرا می‌شود.

چرا Orca می‌تواند جای IDE را بگیرد؟

Orca فقط یک ترمینال چندپنجره‌ای نیست. چیزهایی که هر روز در IDE لازم دارید، در خودش هست:

  • ویرایشگر کد: ویرایشگر VS Code با ذخیرهٔ خودکار. فایل یا عکس را هم می‌شود مستقیم روی پرامپت ایجنت کشید.
  • ترمینال: ترمینال‌های سریع با تقسیم پنجرهٔ نامحدود که تاریخچه‌شان بعد از بستن برنامه هم می‌ماند.
  • بازبینی diff: هر worktree را با شاخهٔ مبدأش مقایسه می‌کنید و با Annotate AI Diff روی هر خط نظر می‌گذارید تا همان نظر برای ایجنت فرستاده شود.
  • گیت و Pull Request: کامیت، push، ساخت PR و دنبال کردن نتیجهٔ CI همه داخل Orca انجام می‌شود. GitHub، GitLab، Linear و Jira هم به آن وصل می‌شوند و از هر issue می‌شود مستقیم یک worktree ساخت.
  • مرورگر داخلی: یک Chromium داخلی با Design Mode؛ روی هر جزء صفحه کلیک می‌کنید و HTML، CSS و تصویر همان بخش به پرامپت ایجنت می‌رود.
  • کار از راه دور: worktree را با SSH روی یک سرور قوی‌تر اجرا می‌کنید و با اپ موبایل Orca برای iOS و اندروید، از تمام شدن کار ایجنت باخبر می‌شوید و همان‌جا جوابش را می‌دهید.
  • مصرف اشتراک‌ها: مصرف و زمان پر شدن دوبارهٔ سهمیهٔ Claude و Codex را نشان می‌دهد.

مستندات worktree در Orca نشان می‌دهد که جلوگیری از تداخل در خود طراحی Orca است. هر workspace یک worktree و شاخهٔ واقعی گیت است و Orca فایل `.worktreeinclude` و تنظیمات `orca.yaml` را برای کپی یا اشتراک فایل‌های محلی می‌شناسد. حذف workspace پوشه و شاخه را با هم پاک می‌کند، ولی اگر شاخه کامیت ادغام‌نشده داشته باشد، Orca آن را نگه می‌دارد. هر وقت هم بخواهید، داخل همان پوشه با گیت معمولی کار می‌کنید.

خود Orca هم صریح گفته برای چه کسی ساخته شده است: برنامه‌نویسی که diff را می‌خواند و به کامیت‌هایش اهمیت می‌دهد. ابزاری برای ساختن نرم‌افزار بدون کدنویسی نیست.

مخزن Orca در اسفند ۱۴۰۴ ساخته شده و تا ۲۰ مهر ۱۴۰۵ بیش از ۹۰ هزار ستاره در گیت‌هاب گرفته است.

نصب Orca و ساختن اولین workspace

  1. Orca را از سایت Orca دانلود کنید. روی مک با Homebrew هم نصب می‌شود: `brew install --cask stablyai/orca/orca`
  2. پوشهٔ پروژه را به‌عنوان یک project به Orca اضافه کنید.
  3. یک workspace تازه بسازید: اسم کار را بنویسید، شاخهٔ مبدأ را انتخاب کنید (معمولاً `origin/main`) و ایجنت را از فهرست بردارید. Orca پشت صحنه worktree را می‌سازد و ایجنت را در اولین تب باز می‌کند.
  4. برای کار دوم، یک workspace دیگر با ایجنت دیگری بسازید. هر کدام در نوار کناری جدا دیده می‌شود.
  5. وقتی ایجنت کارش را تمام کرد، diff را مرور کنید و نظرهایتان را برایش بفرستید. آخر کار کامیت و PR بزنید و workspace را حذف کنید.

تجربهٔ تیم فنی سواپ‌ولت

تیم فنی سواپ‌ولت حدود شش ماه است که همین روال را در کار روزانه به کار می‌برد: هر کار در worktree خودش، چند ایجنت کنار هم و Orca به‌عنوان محیط اصلی کار. در این مدت بهره‌وری تیم بالا رفته و تیم فنی ما این روش را به هر برنامه‌نویسی که با ایجنت‌ها کار می‌کند پیشنهاد می‌کند.

اگر تازه شروع می‌کنید، لازم نیست همه‌چیز را یک‌جا عوض کنید. اول یک کار کوچک را در worktree جدا به یک ایجنت بدهید و هم‌زمان خودتان روی پوشهٔ اصلی کار کنید. وقتی این روال جا افتاد، ایجنت دوم و بعد Orca را اضافه کنید.

اشتراک ایجنت‌ها را از کجا تهیه کنیم؟

گیت و Orca رایگان‌اند و هزینهٔ اصلی، اشتراک خود ایجنت‌هاست:

  • Claude Code با اشتراک Claude Pro یا Max می‌آید. پلن‌ها و نصبش را در کلود کد چیست گفته‌ایم و اگر بین آن و Cursor مرددید، کرسر یا کلاد کد را ببینید.
  • Codex در همهٔ پلن‌های ChatGPT هست و پلن‌های پولی، مثل Plus، سهمیهٔ بیشتری برایش دارند.
  • Antigravity با حساب گوگل کار می‌کند و اشتراک Google AI Pro هم سهمیهٔ Antigravity را شامل می‌شود.

این اشتراک‌ها را در فروشگاه سواپ‌ولت بدون کارت خارجی و با موجودی تومانی یا تتری کیف پولتان می‌خرید: Claude، ChatGPT و Gemini. هر ابزار را با حساب شخصی خودتان وصل کنید تا کار و تاریخچه‌اش فقط دست خودتان باشد. برای مقایسهٔ همهٔ اشتراک‌ها هم راهنمای خرید اشتراک هوش مصنوعی را بخوانید.

پرسش‌های رایج

می‌شود Claude Code و Codex را هم‌زمان روی یک پروژه اجرا کرد؟

بله، به شرطی که هر کدام در worktree و شاخهٔ خودش کار کند. اگر هر دو در یک پوشه باشند، فایل‌ها و شاخهٔ گیت مشترک است و دیر یا زود کار هم را خراب می‌کنند.

git worktree با clone دوبارهٔ مخزن چه فرقی دارد؟

worktreeها یک مخزن گیت مشترک دارند؛ کامیت‌ها و شاخه‌های هر کدام بلافاصله در بقیه هم هست و تاریخچه دوباره دانلود نمی‌شود. با دو clone جدا باید بین آن‌ها push و pull کنید. تنها محدودیت worktree این است که یک شاخه را نمی‌شود هم‌زمان در دو worktree باز کرد.

AGENTS.md بنویسم یا CLAUDE.md؟

AGENTS.md. Codex و Antigravity مستقیم آن را می‌خوانند و Claude Code هم یا مستقیم می‌خواند یا با یک خط `@AGENTS.md` در CLAUDE.md. این‌طور فقط یک فایل را به‌روز نگه می‌دارید.

Orca رایگان است؟

بله. Orca رایگان و متن‌باز است و هزینه‌ای که می‌دهید فقط برای اشتراک خود ایجنت‌هاست، مثل Claude Pro یا ChatGPT Plus.

Orca جای VS Code یا Cursor را می‌گیرد؟

برای کار ایجنت‌محور بله؛ ویرایشگر VS Code، ترمینال، بازبینی diff، مرورگر و گیت را یک‌جا دارد. هر worktree هم یک پوشهٔ معمولی است و هر وقت بخواهید، می‌توانید آن را در IDE قبلی‌تان باز کنید.

چند ایجنت را هم‌زمان اجرا کنم؟

به اندازهٔ توان بازبینی خودتان. با دو یا سه ایجنت روی کارهای مستقل شروع کنید و وقتی دیدید diffها را به‌موقع می‌خوانید و ادغام می‌کنید، تعداد را بیشتر کنید.