تصور کنید یک پروتوتایپ در فیگما دارید که شامل بخش‌های ثبت‌نام (Onboarding)، پرداخت (Checkout) و پروفایل است؛ در حالت عادی، توسعه این بخش‌ها فرآیندی تکه‌تکه و زمان‌بر است که نیازمند مدیریت دستی شاخه‌های مختلف کد است. ابزار ivar این گره را می‌گشاید و اجازه می‌دهد سه یا چند عامل (Agent) — شبیه به کارمندانی که هر کدام مسئول یک اتاق از خانه هستند و بدون تداخل با هم کار می‌کنند — به‌طور هم‌زمان روی این بخش‌های مجزا در یک مخزن کد (Repository) واحد کار کنند و در نهایت نتایج کار خود را در قالب یک درخواست ادغام (Pull Request) واحد ترکیب کنند.
مدیریت مشارکت‌های موازی هوش مصنوعی معمولاً به تداخلات شدید در ادغام کد (Merge Conflicts) یا خرابی نسخه‌های نهایی (Broken Builds) منجر می‌شود، زیرا عامل‌ها ممکن است فایل‌های یکدیگر را بازنویسی کنند. در حال حاضر، اکثر توسعه‌دهندگان به مدیریت دستی git worktree یا ارسال پرامپت‌های متوالی (Sequential Prompting) متکی هستند که این امر سرعت انتقال از طراحی به کد را کاهش می‌دهد. طبق گزارشی که در ۳۰ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، ivar این جداسازی را خودکار می‌کند و برای هر عامل یک محیط کاری مجزا (Worktree) و اسکریپت راه‌اندازی اختصاصی فراهم می‌کند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، ایزوله‌سازی محیط‌های اجرا برای جلوگیری از رفتارهای پیش‌بینی‌نشده در سامانه‌های عامل‌محور حیاتی است. این رویکرد در مدیریت ساختار فایل‌ها شباهت‌هایی به استراتژی meclaw در جایگزینی حلقه‌های تکرار با توپولوژی فایل دارد تا نظم عملیاتی در محیط‌های پیچیده حفظ شود.
گردش کار موازی
برای پیاده‌سازی این ساختار، توسعه‌دهنده ابتدا یک «تالار» (Hall) را مقداردهی اولیه کرده و با استفاده از دستورات ivar init و سپس ivar repo add app [email protected]:acme/app.git مخزن خود را به سیستم معرفی می‌کند. این سیستم از یک ساختار سلسله‌مراتبی برای حفظ نظم و ترتیب استفاده می‌کند:
- ویژگی اصلی (Main Feature): یک شاخه والد (مثلاً
figma-proto) از طریق دستورivar feature create figma-protoایجاد می‌شود. سپس با دستورivar feature promote figma-proto appارتقا می‌یابد تا به عنوان پایه و اساس (Base) برای سایر بخش‌ها قرار گیرد. - ویژگی‌های فرعی (Subfeatures): شاخه‌های فرزند (مانند
onboardingیاcheckoutیاprofile) از شاخه والد جدا می‌شوند. ترتیب در اینجا حیاتی است؛ اگر یک شاخه فرزند پیش از والد ارتقا یابد، ivar هشدار می‌دهد که پایه وجود ندارد و در این صورت، شاخه فرزند را مستقیماً از شاخه اصلی (Main) جدا می‌کند. این نوع سازمان‌دهی عامل‌های تخصصی برای وظایف مجزا، یادآور روش زنجیره‌سازی عامل‌های PHP در NanoAgent است که برای کاهش توهمات مدل از تفکیک وظایف بهره می‌برد. - ایزولاسیون: هر ویژگی فرعی محیط کاری (Worktree) مخصوص به خود را دریافت می‌کند. این امر تضمین می‌کند که عامل‌ها هرگز با ایندکس (Index)، وضعیت HEAD یا فایل‌های یکدیگر تداخل نداشته باشند.
اجرای فنی
هر جلسه کاری با دستور ivar session start در یک ترمینال مجزا آغاز می‌شود. برای مثال، توسعه‌دهنده سه ترمینال باز می‌کند تا به‌طور دستی دستورات ivar session start onboarding ، ivar session start checkout و ivar session start profile را به ترتیب اجرا کند. توجه داشته باشید که هیچ دستور واحدی برای شروع هم‌زمان هر سه جلسه وجود ندارد و آن‌ها باید به‌صورت دستی باز شوند.
برای اطمینان از اینکه محیط کاری کاملاً عملیاتی است، توسعه‌دهندگان دستورات مربوط به وابستگی‌ها را در یک اسکریپت راه‌اندازی در مسیر .ivar/setups/app.sh قرار می‌دهند. این اسکریپت معمولاً شامل موارد زیر است:
set -eبرای اطمینان از اینکه اسکریپت در صورت بروز هرگونه خطا، بلافاصله متوقف شود.make depsبرای نصب تمامی وابستگی‌های مورد نیاز پروژه.make codegenبرای تولید کدهای لازم (Code Generation).
این اسکریپت هر بار که یک شاخه (Branch) جدید جدا می‌شود، اجرا می‌گردد تا از شروع به کار عامل‌ها با یک بیلد خراب جلوگیری شود. علاوه بر این، سرور پروتکل زمینهٔ مدل (MCP) مربوط به فیگما، تنها یک‌بار در فایل ivar.json تعریف شده و در هر جلسه کاری متجسم (Materialize) می‌شود؛ این قابلیت به هر عامل اجازه می‌دهد تا فریم‌های پروتوتایپ فیگما را به‌طور مستقیم بخواند.
نظارت و یکپارچه‌سازی
توسعه‌دهندگان می‌توانند وضعیت کل درخت ویژگی‌ها را از هر ترمینالی با دستور ivar feature status figma-proto --recursive بررسی کنند. این نما نشان می‌دهد کدام فرزندان فعال هستند و کدام‌ها یکپارچه شده‌اند. برای مثال، اگر بخش‌های ثبت‌نام و پرداخت به پایان رسیده باشند، وضعیت آن‌ها به صورت «integrated» نمایش داده می‌شود، در حالی که ویژگی اصلی همچنان توسط بخش پروفایل که فعال است، «مسدود» (blocked by) شده است.
یکپارچه‌سازی از طریق یک «دروازه برنامه‌ریزی» (Plan Gate) رخ می‌دهد. توسعه‌دهنده باید ابتدا یک برنامه ایجاد و آن را تأیید کند (مثلاً با دستور ivar plan create onboarding plan و سپس ivar plan approve onboarding plan) تا در نهایت تغییرات فرزند از طریق دستور ivar feature integrate onboarding به شاخه والد بازگردانده شود.
تحویل نهایی
پس از اینکه تمام قطعات (Slices) در شاخه والد ادغام شدند، ویژگی اصلی حامل تمام مشارکت‌ها خواهد بود. توسعه‌دهنده پیش‌نمایشی از تحویل نهایی را با دستور ivar feature deliver figma-proto --preview بررسی می‌کند. این دستور شاخه، ریموت و پایه را می‌خواند تا یک اثر انگشت (Fingerprint) منحصربه‌فرد چاپ کند، بدون اینکه داده‌ای را بنویسد.
زمانی که پیش‌نمایش صحیح بود، توسعه‌دهنده آن را با دستور ivar feature deliver figma-proto --fingerprint <fp> اعمال می‌کند. این عمل باعث می‌شود شاخه به سرور منتقل شده و یک Pull Request واحد در برابر شاخه اصلی (Main) باز شود. لازم به ذکر است که برای ایجاد PR، داشتن یک ریموت گیت‌هاب الزامی است؛ ریموت‌های محلی تنها باعث Push شدن شاخه می‌شوند.
این سازوکار نقش توسعه‌دهنده را از یک کدنویس به یک ارکستراتور یا هماهنگ‌کننده تغییر می‌دهد. انسان به‌جای مدیریت تک‌تک پرامپت‌ها، بر تأیید «برنامه» و تأیید اثر انگشت نهایی تمرکز می‌کند. این روش اصطکاک ناشی از جابجایی مداوم بین شاخه‌های مختلف (Context-switching) هنگام هماهنگی چندین عامل هوش مصنوعی را از بین می‌برد. در واقع، این سطح از کنترل بر عامل‌های نرم‌افزاری، گامی در جهت تبدیل مدل‌های زبانی به عامل‌های عملیاتی مشابه پلتفرم OtoDock است که در آن مدل‌ها از محیط‌های ایزوله برای اجرای دستورات واقعی استفاده می‌کنند.
نویسنده اشاره می‌کند برای تیم‌هایی که گردش کار موازی ندارند، استفاده از git worktreeهای استاندارد و یک فایل .mcp.json ساده برای سرور فیگما ممکن است کافی باشد. با این حال، زمانی که عامل‌ها به سرورهای MCP یکسان و اسکریپت‌های راه‌اندازی مشابه در محیط‌های ایزوله نیاز دارند، استفاده از ivar ضروری می‌شود.
گام بعدی شما
- بررسی مستندات ivar برای راه‌اندازی اولین «تالار» (Hall) چندعاملی خود.
- تعریف اسکریپت‌های setup دقیق برای جلوگیری از توقف عامل‌ها در مراحل ابتدایی.
- آزمایش مدل‌های مختلف استدلالی برای مدیریت ویژگی‌های پیچیده‌تر در شاخه‌های فرعی.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو