اگر سیستمهای چند-عاملی را پیاده میکنید، باید خبر بد را بشنوید. یک درخواست سادهی کاربر ممکن است بدون آنکه بدانید، صدها فراخوانی مخفی API ایجاد کند.
این پدیده زمانی رخ میدهد که عاملهای هوش مصنوعی (AI Agents) — مثل کارمندانی متخصص در یک شرکت که هر کدام وظیفه خاصی دارند — برای تأیید یا بازیابی دادهها، مدام از یکدیگر درخواست میگیرند. در نتیجه، فشار روی زیرساختها به صورت تصاعدی رشد میکند. این فشار شدید به منابع، دقیقاً همان نقطهای است که در بررسی بنبست عاملهای هوش مصنوعی در دنیای واقعی به هزینههای گزاف بدون بازدهی در مقیاس عملیاتی اشاره کردیم.
همانطور که در تحلیل قبلی ما دربارهی چالشهای استقرار مدلهای بازمتن اشاره کردیم، مدیریت منابع در مقیاس واقعی سختترین بخش بازی است. تصور کنید در یک دفتر اداری، هر کارمند قبل از پایان دادن به یک وظیفه، از پنج همکار دیگر «تأییدیه» بخواهد. در ابتدا منطقی به نظر میرسد، اما حجم ارتباطات به سرعت کل سازمان را فلج میکند. طبق گزارش فنی منتشر شده در dev.to در ۱۰ ژوئن ۲۰۲۶، سیستمهای هوش مصنوعی دقیقاً همین مشکل را با سرعت ماشین تکرار میکنند.
توسعهدهندگان دریافتند که عاملهای «هوشمندتر»، لزوماً کار را کمتر نمیکنند. استدلال بیشتر یعنی مراحل برنامهریزی بیشتر، که در نهایت به فراخوانیهای بیشتر برای استنتاج (Inference) — یعنی همان لحظهی تولید جواب توسط مدل — منجر میشود. بر اساس مستندات این گزارش، سه الگوی شکست بحرانی شناسایی شده است: این الگوها با ناپایداریهای زیرساختی در عاملهای AI که پیشتر کالبدشکافی کردیم، همسویی دارند و ریشه در نحوه مدیریت توکنها دارند.
- چرخههای بازخوردی: عاملها در حلقههای تکرار شونده، مدام از هم اطلاعات میخواهند.
- مارپیچهای تأیید: مراحل تکراری که خروجی را بهبود نمیبخشند اما منابع را میبلعند.
- تقویت تصاعدی: تبدیل یک درخواست ورودی به ۱۰، سپس ۵۰ و در نهایت صدها فراخوانی داخلی.
این تحول یعنی باید به گردشهای کاری عاملها به چشم سیستمهای توزیعشده (Distributed Systems) نگاه کنید. تیمهای فنی با اعمال محدودیت نرخ درخواست (Rate Limit) روی تکرارها، فقط هزینهها را پایین نیاوردند. در کنار این محدودیتها، پیادهسازی روشهایی مانند «صف اقدامات» برای جلوگیری از هدررفت توکنها میتواند پایداری عملیاتی را بهطور چشمگیر افزایش دهد. آنها از این محدودیتها به عنوان ابزاری برای تشخیص خطا استفاده کردند. هر جا گردش کاری به سقف محدودیت میرسید، یک نقطه ناکارآمد یا یک حلقه برنامهریزی اضافی در معماری فاش میشد.
گام بعدی شما
- نسبت ارتباطات بین-عاملی (Agent-to-Agent ratio) را در سیستم خود حسابرسی کنید.
- پایش کنید که آیا فشار روی زیرساخت شما با تعداد کاربران رشد میکند یا با رفتار داخلی عاملها.
- محدودیتهای نرخ داخلی را به عنوان ابزار دیباگ برای شناسایی وظایف تکراری به کار بگیرید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو