مدیریت سلسله‌مراتبی در برابر پنجره متنی واحد؛ هزینه‌ای بدون بازده

اجبار یک عامل هوش مصنوعی به تشکیل کمیته برای نوشتن یک مقاله کوتاه، دستورالعملی برای اتلاف منابع اقتصادی است. یک ارزیابی فنی فاش کرد که هماهنگی چندعاملی (Multi-Agent Orchestration) می‌تواند هزینه‌های توکن را تا ۴.۳۸ برابر افزایش دهد، بدون آنکه هیچ بهبودی در صحت خروجی ایجاد کند.

این یافته، روند رایج صنعت در ساخت سلسله‌مراتب پیچیده «عامل‌محور» برای هر وظیفه را به چالش می‌کشد. در حالی که هدف این معماری‌ها اغلب جداسازی زمینه (Context) و جلوگیری از نویز است، هزینه واقعی مدیریت این جداسازی — یا همان «مالیات فورک» (Fork Tax) — اغلب از مزایای انتزاعی آن پیشی می‌گیرد.

زمینه: پروتکل Subsession

این ارزیابی بر پایه پروتکل Subsession بنا شده است؛ لایه‌ای روی محیط‌های اجرای عامل (Agent Runtimes) که برای تحمیل جلسات فرزند با نقش‌های مشخص (Role-typed)، دستورالعمل‌های نسخه‌بندی شده (Versioned Briefs) و ژورنال‌های نقاط بازرسی فقط-افزودنی (Append-only Checkpoint Journals) طراحی شده است. این رویکرد در ابتدا با هدف جلوگیری از متورم شدن پنجره متنی از طریق محدود کردن حافظه عامل‌ها معرفی شده بود. معماری این سیستم بر یک اصل ثابت (Invariant) بنیادین استوار است: زمینهٔ جلسه مادر تنها به اندازه گزارش نهایی رشد می‌کند ($O(\text{report})$)، و هرگز به اندازه تمام متن گفتگوهای فرزند ($O(\text{child transcript})$) افزایش نمی‌یابد.

در این مدل، اپراتور انسانی کل درخت سازمانی را می‌بیند، اما جلسه مادر فقط گزارش‌های ساختاریافته را دریافت می‌کند. در حالی که گیت‌های مکانیکی و قراردادهای گزارش‌دهی برای تحمیل این جداسازی وجود دارند، سؤال این بود که آیا این سربار ساختاری در حجم کاری واقعی به‌صرفه است یا خیر. برای پاسخ به این سؤال، تیم پژوهشی یک دستورالعمل ارزیابی رسمی (RUBRIC.md) را پیش‌ثبت کرد و مجموعه داده‌های حاصل را به یک حسابرسی تأیید خصمانه مستقل (results/VERIFICATION.md) ارسال نمود.

آزمایش: اجرای خطی در برابر هماهنگ‌شده

برای کمی‌سازی این هزینه، پژوهشگران دو بازوی اجرایی متمایز را با استفاده از مدل bai-/glm-5.3-flash مقایسه کردند:

• بازوی خطی (نقش: Worker): یک جلسه تک‌عامل و خودمختار. در اینجا ابزارهای Subsession به‌طور ساختاری حذف شده‌اند (canSpawn: false). عامل پرامپت وظیفه را دریافت کرده و تمام مراحل ناوبری کد، ویرایش، اجرای اسکریپت و تأیید را مستقیماً در جلسه خود انجام می‌دهد.
• بازوی هماهنگ‌شده (نقش: Coordinator): یک جلسه ناظر که اجازه ایجاد فرزندان را دارد (canSpawn: true با سقف عمق depthCap: 2). طبق اصلاحات پیش‌ثبت شده در پروتکل، ناظر موظف است کار را به حداقل دو جلسه فرزند (Worker Subsessions) واگذار کرده و گزارش‌های بازگشتی آن‌ها را پیش از ارائه پاسخ نهایی ترکیب و سنتز کند.

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

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

• مدل یکسان: تمام جلسات در هر دو بازو به پیش‌فرض استقرار (bai-/glm-5.3-flash) ارجاع داده شدند.
• داده‌های قطعی (Deterministic Fixtures): تمام فایل‌های مخزن (۸۰ فایل TypeScript)، فایل‌های CSV مالی (۳۶۰ ردیف در واحد سنت‌های صحیح)، لاگ‌های سرور (۳۰۰۰ خط) و یادداشت‌های جلسات (۳۴۷ کیلوبایت در ۲۰۰ بخش) از یک بذر تصادفی PRNG (مدل Mulberry32) تولید شدند.
• امتیازدهی مکانیکی: خروجی‌ها توسط اسکریپت checks/check.mjs و با تطبیق دقیق (Deep-equality) در برابر داده‌های مرجع JSON منجمد ارزیابی شدند.
• اجرای متناوب: اجراها در توالی A/B/B/A انجام شد تا سوگیری‌های مربوط به محدودیت‌های زمانی API (Throttling) در ساعات مختلف روز حذف شود.

کمی‌سازی مالیات فورک

پژوهشگران ۲۰ وظیفه را در چهار کلاس مهندسی نرم‌افزار بررسی کردند (۵ وظیفه برای هر کلاس). طبق گزارش این مطالعه، در تمام ۱۹ جفتِ تکمیل‌شده، روش هماهنگ‌شده به‌طور مطلق گران‌تر از روش خطی بود.

شاخص‌های عملکرد بر اساس کلاس وظایف:

• خوانش گسترده (T01–T05): توکن‌های خطی (میانه) ۷۶,۳۹۳ در برابر توکن‌های هماهنگ‌شده ۳۰۴,۸۲۴ (۳.۹۹ برابر). زمان واقعی (Wall-clock time) از ۲۰۴ ثانیه به ۴۹۱ ثانیه (۲.۴۱ برابر) افزایش یافت.
• نوشتار تک‌مرحله‌ای (T06–T10): توکن‌های خطی (میانه) ۴۹,۲۶۹ در برابر هماهنگ‌شده ۲۱۵,۶۳۱ (۴.۳۸ برابر). زمان واقعی از ۹۶ ثانیه به ۷۴۵ ثانیه (۷.۷۶ برابر) رسید.
• تبدیل اسناد طولانی (T11–T15): توکن‌های خطی (میانه) ۱۷۰,۶۳۱ در برابر هماهنگ‌شده ۵۹۲,۴۵۲ (۳.۴۷ برابر). زمان واقعی از ۴۳۹ ثانیه به ۱,۲۲۴ ثانیه (۲.۷۹ برابر) افزایش یافت.
• ابزارهای چندمرحله‌ای (T16–T20): توکن‌های خطی (میانه) ۱۰۴,۳۲۱ در برابر هماهنگ‌شده ۳۹۰,۱۲۹ (۳.۷۴ برابر). زمان واقعی از ۱۸۵ ثانیه به ۷۵۹ ثانیه (۴.۱۰ برابر) رسید.

خلاصه صحت و تأخیر

• برابری صحت: هر دو بازو عملکرد یکسانی داشتند و ۱۰۰٪ وظایف T01 تا T19 را پاس کردند. هر دو در وظیفه T20 به‌دلیل یک نقص در گردآوری داده‌های مرجع شکست خوردند؛ جایی که پرامپت ترتیب لغت‌نامه‌ای (Lexicographic) را می‌خواست اما تولیدکننده داده‌ها ابتدا دایرکتوری‌ها را مرتب کرده بود.
• تورم توکن: اجراهای هماهنگ‌شده بین ۳.۴۷ تا ۴.۳۸ برابر توکن‌های صورت‌حسابی بیشتری نسبت به اجراهای خطی مصرف کردند.
• جهش تأخیر: زمان واقعی اجرا ۲.۴۱ تا ۷.۷۶ برابر افزایش یافت. در وظایف «نوشتار تک‌مرحله‌ای»، اعزام کارکنان، انتظار برای دست‌دادن‌های ابزاری (Tool Handshakes) و ادغام گزارش‌ها ۷۴۵ ثانیه زمان برد، در حالی که عامل خطی همین کار را در ۹۶ ثانیه انجام داد.

پارادوکس هماهنگی

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

• جلسه مادر (حلقه ناظر): ۵۵٪ از کل هزینه.
• جلسات فرزند (انجام وظیفه): ۴۵٪ از کل هزینه.

در یک اجرای معمولی، حجم میانه گزارش‌های ارسالی به مادر تنها ۳,۵۲۹ بایت بود، اما جلسه مادر به‌طور میانگین ۲۱۳,۲۱۹ توکن را صرف مدیریت این گزارش‌ها کرد. این یعنی ناظر حدود ۶۰ برابر بیشتر از حجم داده‌های دریافتی، توکن مصرف کرده است تا حلقه هماهنگی را پیش ببرد.

در ۱۷ مورد از ۱۹ مورد، تنها سربار ناظر از کل توکن‌های مصرف‌شده توسط یک عامل خطی برای انجام کامل وظیفه از ابتدا تا انتها بیشتر بود. اصل $O(\text{report})$ به‌طور مکانیکی روی دیسک برقرار بود، اما از نظر اقتصادی بی‌معنی بود. هزینه شناختی تدوین دستورالعمل‌های ساختاریافته، تعیین مسیرهای فایل (Globs)، انتظار برای نوبت، نظارت بر وضعیت و رفع تناقضات، هزینه خودِ وظیفه را به حاشیه راند.

شکست فرضیه نقطه تلاقی

پژوهشگران ابتدا فرض کردند یک «نقطه تلاقی» (فرضیه ۳) وجود دارد که در آن، با بزرگ‌تر شدن وظایف، صرفه‌جویی حاصل از جداسازی زمینه بر سربار پروتکل غلبه کند. اما داده‌ها این فرض را کاملاً رد کردند:

• صفر درصد موفقیت: در هیچ‌یک از ۱۹ جفت (۰٪)، روش هماهنگ‌شده توکن کمتری مصرف نکرد.
• صرفه‌جویی حداقلی: تنها در ۲ مورد از ۱۹ جفت، جلسه مادر به‌تنهایی توکن کمتری نسبت به کلِ اجرای خطی مصرف کرد (وظیفه T13 با ضریب ۰.۹۹ و وظیفه T17 با ضریب ۰.۸۶).
• سد ناپذیری (H4): در ۰٪ اجراها، توکن‌های مادر کمتر از ۰.۵ برابر توکن‌های خطی بود.

حتی در بزرگ‌ترین سند — یک سند جلسه اجرایی ۳۴۷ کیلوبایتی با ۲۰۰ بخش — عامل خطی تحلیل را در ۱۷۰,۶۳۱ توکن به پایان رساند، در حالی که بازوی هماهنگ‌شده ۵۹۲,۴۵۲ توکن سوزاند (۳.۴۷ برابر). از آنجا که پنجره‌های متنی مدل‌های مدرن (۱۲۸ هزار توکن به بالا) می‌توانند چنین اسنادی را در یک پاس هضم کنند، تقسیم کار باعث تلاش‌های تکراری شد. هر دو کارکن مجبور بودند بخش‌های خود را بخوانند، یافته‌ها را سریال‌سازی کنند و به ناظر بفرستند، و سپس ناظر باید تمام یافته‌ها را خوانده و دوباره آن‌ها را تأیید می‌کرد.

ریسک‌های عملیاتی و بن‌بست‌ها

علاوه بر هزینه، این مطالعه ریسک‌های شدید پایداری را در معماری‌های Subsession برجسته کرد. یک تلاش برای سنجش تاب‌آوری وضعیت (فرضیه ۵) از طریق بازگشت از نقطه بازرسی (اجرای R38-T19-orch) به یک «فاجعه عملیاتی» منجر شد. وظیفه در توکن ۱۸,۵۴۹ (گام ۲، ۷۸ ثانیه) متوقف و با یک پرامپت بازیابی منجمد مجدداً اجرا شد: «شما در میانه وظیفه متوقف شدید؛ از نقطه بازرسی خود بازیابی کنید و کار را به پایان برسانید؛ به‌طور عادی گزارش دهید.»

بخش بازیابی ۱۲۹,۹۴۵ توکن اضافی مصرف کرد و مجموع را به ۱۴۸,۴۹۴ رساند. ناظر سعی کرد ۵ فرزند ایجاد کند؛ دو مورد به‌دلیل توهم نام‌های نقش ثبت‌نشده (log-analyst-a و log-analyst-b) رد شدند. دو کارکن معتبر ایجاد شدند اما بدون ارسال گزارش متوقف و بسته شدند.

نکته حیاتی این بود که محیط اجرای ناظر هیچ مکانیزم تایم‌اوت یا تشخیص فرزندان مرده برای گزارش‌های نامتقارن نداشت. ناظر پیام نهایی را ارسال کرد که اعلام می‌کرد پس از رسیدن گزارش‌ها، خروجی را ادغام می‌کند، و سپس به‌طور نامحدود متوقف شد. جلسه برای ۵۳,۰۴۶ ثانیه (حدود ۱۴.۷ ساعت) در حالت بن‌بست (Deadlock) باقی ماند تا به‌صورت دستی متوقف شود. این ثابت می‌کند که بدون نظارت فعال بر وضعیت سکون (Quiescence Monitoring)، بازگشت از نقطه بازرسی به‌جای صرفه‌جویی در توکن، بن‌بست‌های نامحدود ایجاد می‌کند. این نوع شکست‌های سیستمی بخشی از مسیرهای شکست رایجی هستند که مانع از استقرار تجاری عامل‌های هوش مصنوعی می‌شوند.

نقاط اصطکاک مکانیکی

این محک چهار حالت شکست خاص در ساختارهای چندعاملی را شناسایی کرد:

• توهم نقش (UNKNOWN_ROLE): ناظران به‌جای نقش تعریف‌شده worker ،نقش‌های خیالی مثل doc-summarizer-a ،summarizer یا log-analyst اختراع می‌کردند. هر ایجاد نامعتبر، یک نوبت کامل LLM و یک رفت‌وبرگشت ابزاری مصرف می‌کرد تا در نهایت به نقش‌های معتبر بازگردد.
• قحطی بودجه: در اجرای R15، ناظر چنان توکنی در حلقه برنامه‌ریزی مصرف کرد که تمام ۶ فرزند ایجاد شده در توکن صفر کشته شدند. این امر مستلزم «اصلاح پروتکل شماره ۴» بود تا بودجه مشترک درخت از ۱۵۰,۰۰۰ به ۱,۰۰۰,۰۰۰ توکن افزایش یابد تا سقف بودجه به‌طور نامتقارن روی بازوی هماهنگ‌شده اثر نگذارد.
• شرایط رقابتی (Race Conditions): در حداقل ۸ اجرا، قلاب‌های تأیید خودکار با عملیات نوشتن فایل در جلسات فرزند در رقابت بودند و به‌طور غلط گزارش دادند که خروجی‌ها «مفقود» یا «مورد اختلاف» هستند. ناظران مجبور شدند نوبت‌های اضافی را صرف خواندن مستقیم دیسک کنند تا این هشدارهای غلط را رد کنند.
• تأیید تکراری: کارکنان اغلب در شمارش‌ها توهم می‌زدند. در وظیفه T04، یک کارکن ادعا کرد ۵۳ ایمپورت وجود دارد در حالی که ۵۲ مورد بود؛ در T13، کارکنان ادعای ۱۰۳ مورد کردند در حالی که ۱۰۰ مورد بود. ناظر این موارد را تنها با اجرای مجدد استخراج داده‌ها از روی فایل‌های خام شناسایی کرد، که باعث تکرار تلاش کارکن و افزایش هزینه کل شد.

دیدگاه منتقدانه

یک تأییدکننده خصمانه این محک را حسابرسی کرد (results/VERIFICATION.md) تا مطمئن شود نتایج حاصل از طراحی آزمایش نیستند. یک نقد معتبر این است که این محک، یک سلسله‌مراتب پیچیده شرکتی را بر مسائلی تحمیل کرده که به‌راحتی در یک نوبت مدل جا می‌شدند. با تحمیل واگذاری به $\ge 2$ فرزند در حجم‌های کاری زیر ۱۰۰ هزار توکن، آزمایش بیشتر سربار اداری را سنجیده است تا توانایی غلبه بر وظایفی که از محدودیت‌های زمینه فراتر می‌روند.

با این حال، این موضوع یک نکته عملیاتی و قابل اجرا را تأیید می‌کند: تحمیل توزیع کار (Fan-out) در وظایفی که در پنجره متنی فعال جا می‌شوند، ضریب هزینه ۳.۵ تا ۴.۴ برابری با صفر درصد بهبود صحت ایجاد می‌کند. در اجرای آزمایشی R02b، یک ناظر توانمند تشخیص داد که وظیفه کوچک است و تصمیم گرفت آن را به‌صورت خطی انجام دهد؛ اما پروتکل او را مجبور به واگذاری کرد. غریزه اولیه ناظر درست بود.

پیامدهای معماری

اگرچه پروتکل Subsession از نشت متن فرزندان به زمینه ناظر جلوگیری می‌کند، اما مشکل اقتصادی را حل نمی‌کند. هماهنگی دارای «جرم» است. عمل نوشتن دستورالعمل‌ها، تعیین مسیرهای فایل، بازرسی خروجی‌ها و مدیریت مجوزها منابع بیشتری نسبت به خودِ کار مصرف می‌کند.

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

هماهنگی باید صرفاً برای «دیوارهای ساختاری» رزرو شود — مانند زمانی که اشباع زمینه باعث افت استدلال می‌شود، یا زمانی که الزامات امنیتی و ایزولاسیون ابزارها، یک مرز اجرای مجزا را تحمیل می‌کند. تا زمانی که یک عامل به یک دیوار سخت در زمینه یا مجوزها برخورد نکند، ارزان‌ترین نمودار سازمانی، نبودِ هرگونه نمودار سازمانی است.

بازتولید محک

تمام داده‌ها، اسکریپت‌ها و تله‌متری در مخزن عمومی تحت پوشه bench/ به‌صورت متن‌باز در دسترس هستند. برای بازتولید این نتایج:

1. تأیید داده‌ها: دستورات node generate.mjs --verify و node selftest.mjs را اجرا کنید (نتیجه مورد انتظار: ۲۰/۲۰ PASS).
2. محاسبه شاخص‌ها: دستورات node compile.mjs ،node analyze.mjs و node stats.mjs را برای استخراج اعداد از results/results.csv اجرا کنید.

هر عدد در این مقاله مستقیماً از تله‌متری ثبت‌شده در bench/runs/ استخراج شده است.

گام بعدی شما

• در طراحی عامل‌های خود، ابتدا بررسی کنید آیا حجم داده‌های ورودی از ۸۰٪ ظرفیت پنجره متنی مدل شما فراتر می‌رود یا خیر؛ اگر نه، از معماری‌های چندعاملی پرهیز کنید.
• برای کاهش «مالیات فورک»، گزارش‌های ارسالی از فرزند به مادر را به شدت فشرده و ساختاریافته کنید تا توکن‌های مدیریت ناظر کاهش یابد.
• در سیستم‌های چندعاملی، حتماً مکانیزم Timeout و تشخیص Deadlock برای جلسات فرزند پیاده‌سازی کنید تا از بن‌بست‌های چندساعته جلوگیری شود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.