تصور کنید یک برنامه‌نویس ارشد، وظیفه‌ای را به چندین دستیار می‌سپارد اما در نهایت متوجه می‌شود هر کدام در دنیای متفاوتی کد زده‌اند و هیچ‌کدام با هم هم‌راستا نیستند. این دقیقاً همان «خطای خاموش» یا حدس اشتباه اما با اطمینان است که سخت‌ترین بخش ساخت ابزارهای خودکار هوش مصنوعی را تشکیل می‌دهد. این چالش با آنچه در پروژه Loupe برای شناسایی باگ‌های نامرئی در کدهای AI بررسی شده، هم‌سویی دارد.
در ۱۴ ژوئیه ۲۰۲۶، سازنده ArDD — مجموعه‌ای از مهارت‌های Claude Code که طراحی شده تا پروژه‌ها را به‌اجبار از طریق برنامه‌ها و وظایف ساختاریافته پیش ببرد — توضیح داد که چرا صرفاً خواندن کد برای عیب‌یابی عامل‌ها کافی نیست. طبق این گزارش، پیشرفت واقعی نه از طریق تحلیل ایستا (Static Analysis)، بلکه با اجرای «تست‌های دود» (Smoke Tests) حاصل شد تا مشخص شود عامل‌ها در عمل چه کرده‌اند، در مقابل آنچه به آن‌ها گفته شده بود.
زمینه و ساختار ArDD
چارچوب ArDD برای جبران فقدان نظم و انضباط در مدل‌ها ساخته شد. به‌جای اینکه به یک عامل (Agent) — شبیه کارمندی که فقط دستورات کلی را می‌گیرد و بدون نقشه عمل می‌کند — اجازه داده شود به صورت «آزاد» (Freewheel) از یک پرامپت تک‌خطی مستقیماً به سراغ کد برود، این چارچوب پروژه را از یک خط لوله مشخص شامل مصنوعات (Artifacts)، برنامه‌ها و وظایف عبور می‌دهد. چرخه اصلی در اینجا یک توالی سخت‌گیرانه و دقیق است: برنامه $\to$ وظایف $\to$ اجرا.
برای جلوگیری از نظارت دائمی و خسته‌کننده بر یک عامل تک‌رشته‌ای (Single-threaded)، مرحله «اجرا» می‌تواند کار را به یک عامل فرعی بسپارد که در درخت کاری گیت (Git Worktree) مخصوص خود اجرا می‌شود. این معماری اجازه اجرای موازی را می‌دهد، اما ریسک‌های بزرگی در مورد «وضعیت‌های مشترک و تغییرپذیر» (Shared, Mutable State) ایجاد می‌کند. این نوع معماری‌های عامل‌محور در Claude Code، پیش از این با چالش‌های امنیتی جدی در زمینه دسترسی به کدهای محرمانه مواجه شده بودند که ضرورت نظارت دقیق بر دسترسی‌ها را بیش از پیش می‌کند.
بسیاری از توسعه‌دهندگان تصور می‌کنند یک سند طراحی دقیق یا مجموعه‌ای از دستورالعمل‌ها، شبکه ایمنی آن‌هاست. اما در جریان‌های کاری عامل‌محور، فاصله بین قصدِ پرامپت و وضعیت واقعی سیستم می‌تواند عمیق و نامرئی باشد. این وضعیت شبیه آشپزی است که دستور پخت را دقیق می‌خواند اما به‌اشتباه به‌جای شکر از نمک استفاده می‌کند؛ دستور پخت روی کاغذ بی‌نقص است، اما نتیجه نهایی یک فاجعه است.
جزئیات شکست‌های فنی
به نقل از گزارش dev.to، چارچوب ArDD با یک شکست بحرانی در نحوه مدیریت درخت‌های کاری گیت مواجه شد. طراحی اولیه به‌گونه‌ای بود که وضعیت‌های هماهنگی (Coordinating State)، مانند برنامه‌ها و لیست وظایف، پیش از سپردن کار به عامل فرعی، در شاخه اصلی (Main Branch) ثبت می‌شدند. این تصمیم بر اساس این تئوری بود که درخت کاریِ تفویض‌شده برای شروع به یک نقطه پایدار و تثبیت‌شده نیاز دارد تا از آن شاخه بزند.
با این حال، یک تست دود زنده نشان داد که این تئوری کاملاً غلط است. نویسنده یک برنامه و فایل وظایف موقت (Throwaway) را ثبت کرد، کار را تفویض نمود و متوجه شد که درخت کاری با وضعیت فعلی مطابقت ندارد. دلیل این اتفاق آن بود که ابزار مربوطه (Harness)، درخت‌های کاری را از شاخه ردیابی از راه دور (Remote Tracking Branch) می‌سازد، نه از HEAD محلی. این رفتار را نمی‌توان از طریق دستورات متنی (Prose) در مهارت‌های مدل کنترل کرد. علاوه بر این، بررسی‌ها در ردیاب مشکلات (Issue Tracker) نشان می‌دهد که این رفتار در نسخه‌های مختلف ابزار تغییر جهت داده است و همین موضوع، هرگونه فرض درباره همگام‌سازی را خطرناک می‌کند.
برای حل این مشکل، چندین حفاظ فنی و مکانیسمی پیاده‌سازی شد:
- worktree-align.sh: یک اسکریپت اجباری که عامل‌های فرعی در اولین قدم و به عنوان اولین اقدام خود اجرا می‌کنند. این اسکریپت تلاش می‌کند شاخه پیش‌فرض محلی را به صورت Fast-forward به شاخه جدید درخت کاری منتقل کند.
- بررسی‌های قطعی (Deterministic Checks): سیستم در صورتی که انتقال سریع (Fast-forward) ممکن نباشد، از ادامه مسیر امتناع می‌کند. سیستم هیچ تلاشی برای تطبیق دادن یک واگرایی پیچیده و به‌هم‌ریخته نمی‌کند و به سادگی اجرا را متوقف می‌کند.
- تله‌های شناسایی (Tripwires): توسعه‌دهنده متوجه یک باگ توضیح‌ناپذیر شد که در آن دستور
git worktree addتنظیمات گیتِ محیط اصلی را بهcore.bare = trueتغییر می‌داد. این اتفاق باعث می‌شود گیت معمولی در آن محیط از کار بیفتد. چون مکانیسم این خطا هرگز پیدا نشد، اکنون هماهنگ‌کننده (Coordinator) بعد از هر اجرای تفویض‌شده، این تغییر را چک می‌کند و در صورت بروز، «فریاد می‌زند» (هشدار شدید می‌دهد).
بازطراحی بنیادی و نتیجه
این تغییرات منجر به یک بازطراحی اساسی شد: اکنون وضعیت‌های هماهنگی بر روی خودِ «شاخه کاری» سوار می‌شوند (Ride the work branch). به‌جای به‌روزرسانی لیست وظایف در شاخه اصلی به پیش‌بینی کارهای آینده، وضعیت‌ها — از «آماده» $\to$ «در حال اجرا» $\to$ «تکمیل شده» — در همان شاخه‌ای زندگی می‌کنند که کد در آن تولید می‌شود. به همین ترتیب، تغییر وضعیت ثبت ویژگی‌ها از «وظیفه شده» به «پیاده‌سازی شده» (Tasked $\to$ Implemented) نیز روی شاخه کاری رخ می‌دهد. وضعیت تنها در لحظه ادغام (Merge) نهایی به شاخه اصلی منتقل می‌شود.
این چرخش تضمین می‌کند که یک اجرای شکست‌خورده، عملاً یک «عمل تهی» (No-op) باشد. اگر یک درخت کاری در میانه راه شکست بخورد، شاخه اصلی پاک می‌ماند چون هرگز وضعیت نیمه‌کاره را ندیده است. در این حالت، شاخه اصلی همچنان همان چیزی را می‌گوید که قبلاً می‌گفت و این موضوع همچنان صادق است. هیچ نیازی به تطبیق یا اصلاح نیست، زیرا وضعیت هماهنگی و کد به‌طور هم‌زمان و یکپارچه وارد شاخه اصلی می‌شوند.
برای کسانی که ابزارهای عامل‌های موازی می‌سازند، این یک درس حیاتی در مورد بدهی فنی (Technical Debt) هوش مصنوعی است. حالت شکست غالب در عامل‌ها، کراش‌های بلند و واضح نیست، بلکه خطاهای خاموش، نامرئی و با اطمینان است. تنها راه شکست این وضعیت، طراحی سیستم‌هایی است که وضعیت‌های مبهم را رد می‌کنند و هر شکست را از طریق تله‌های شناسایی، بلند و واضح می‌کنند. این دقیقاً همان رویکردی است که باید از یک مهندس تازه‌کار خواست: هرگز حدس نزن و ابهام را نپذیر.
اگر در حال ساخت Wrapperهای عامل‌محور هستید، باید بررسی کنید که «وضعیت‌های هماهنگی» شما در کجا قرار دارند. اطمینان حاصل کنید که یک عامل رها شده نمی‌تواند در شاخه اصلی شما به‌هم‌ریختگی و هرج‌ومرج ایجاد کند.
گام بعدی شما
- محل ذخیره «وضعیت‌های هماهنگی» خود را بازبینی کنید تا از تداخل‌ها جلوگیری شود.
- اطمینان حاصل کنید که یک عامل رها شده نمی‌تواند در شاخه اصلی شما به‌هم‌ریختگی ایجاد کند.
- برای هر عملیات حساس، یک اسکریپت ترازسازی (Alignment) مشابه worktree-align.sh تعریف کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو