اریک پروونشر، مهندس کدکس در اپن‌ای‌آی، در سری پست‌های خود در پلتفرم ایکس (X) هشداری صریح به توسعه‌دهندگان صادر کرد: اجرای ده‌ها یا صدها زیرعامل موازی برای حل یک تسک، نه تنها کیفیت خروجی را تضمین نمی‌کند، بلکه هزینه توکن را به‌صورت نمادین بالا می‌برد. او این پدیده را «مالیات هماهنگی» (Coordination Tax) می‌نامد و توضیح می‌دهد که عامل‌ها به یکدیگر اعتماد ندارند و در حلقه‌ی بی‌پایان تأیید و بررسی مجدد کار یکدیگر گیر می‌افتند.

یک فایل پایتون، ۱٬۳۹۳ عامل و ۲۰ هزار دلار

نقطه عطف این بحث، پروژه‌ای بود که در آن یک توسعه‌دهنده برای بازنویسی (ریفکتورینگ) یک فایل پایتون از ۱٬۳۹۳ عامل فابل (Fable) استفاده کرده و در ازای آن ۲۰ هزار دلار هزینه توکن پرداخته بود. واکنش پروونشر موجز و درس‌آموز بود: «یک عامل تکی آстра (Astra) می‌توانست همین کار را با کسری از این هزینه انجام دهد.» او تأکید می‌کند که اگرچه ترورهای عامل ممکن است زمان دیواری (wall-clock) را کوتاه کنند، اما سربار توکن یک «تله» است که بسیاری در آن می‌افتد.

چرا ترورها فشرده توکن می‌سوزانند؟

  • عدم اعتماد متقابل: زیرعامل‌ها کار یکدیگر را دوباره بررسی می‌کنند (double-checking) و این تکرار مستقیماً هزینه توکن را چندبرابر می‌کند.
  • پرامپت‌های سیستمی تکراری: هر زیرعامل پرامپت سیستمی اختصاصی خود را دارد و در مقیاس بزرگ، این پرامپت‌ها مصرف توکن قابل‌توجهی ایجاد می‌کنند.
  • فراخوانی‌های ابزار تکراری: بدون اشتراک‌گذاری زمینه (context) مناسب، زیرعامل‌ها ابزارهای یکسان را بارها و بارها فراخوانی می‌کنند.
  • پرس‌وجوی مداوم وضعیت (Polling): معماری‌های رایج منتظر می‌مانند تا زیرعامل‌ها گزارش دهند، به جای اینکه از مدل رویدادمحور (event-driven) استفاده کنند.

راهکار پیشنهادی: تفویض غیرمستقیم و برنامه‌ریزی بر اساس رویداد

پروونشر پیشنهاد می‌دهد که به جای مدیریت میکرو موازی، وظایف به رشته‌های اجرای جداگانه (separate threads) واگذار شوند که تنها در اتمام کار، عامل اصلی را مطلع می‌کنند. این الگو، بار نظارت را از روی عامل اصلی برمی‌دارد و از دورۀ پرس‌وجوی بی‌پایان جلوگیری می‌کند. او همچنین اذعان می‌کند که اپن‌ای‌آی همچنان باید راهکارهای بهتری برای مدیریت زمینه اشتراکی و کاهش تکرار در سطوح پایین‌تر ارائه دهد.

نمودار مقایسه هزینه توکن در معماری عامل تکی در برابر ترور عامل

تأثیر بر معماری سیستم‌های عامل‌محور (Agentic Systems)

این انتقادات در زمانی بیان شده که مدل‌های استدلال‌گر (reasoning models) مانند o3 و o4-mini اپن‌ای‌آی قابلیت استفاده از ابزار (tool use) را به‌طور بومی داشته و توسعه‌دهندگان به سرعت در حال ساخت لایه‌های ارکستراسیون پیچیده بر روی آن‌ها هستند. درک «مالیات هماهنگی» برای هر کسی که در حال طراحی سیستم‌های عامل‌محور در مقیاس تولید است، ضروری شده است. تمرکز باید از «چند عامل چطور اجرا کنیم؟» به «چطور با کمترین عامل و بیشترین اشتراک‌گذاری زمینه نتیجه بگیریم؟» تغییر یابد.

معماری پیشنهادی تفویض وظایف به رشته‌های موازی با اطلاع‌رسانی رویدادمحور

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