اگر امروز برای اجرای عامل‌های هوش مصنوعی با فهرست ابزارهای گسترده هزینه می‌پردازید، احتمالاً بخش بزرگی از بودجهٔ شما صرف تکرار توکن‌های توصیفی ابزارها در هر چرخه می‌شود. استفاده از Jev به‌عنوان مسیریاب ابزار می‌تواند هزینه‌های عملیاتی را در مقایسه با روش‌های استاندارد تا ۴.۵ برابر کاهش دهد. این رویکرد، تصمیم سادهٔ «کدام ابزار استفاده شود» را از وظیفهٔ پیچیدهٔ «پر کردن آرگومان‌ها و نوشتن گزارش نهایی» جدا می‌کند.
در حال حاضر، اکثر عامل‌ها با ارسال کل کاتالوگ ابزارهای خود — شامل هر نام، توصیف و فیلد ورودی — در هر نوبت به یک مدل زبانی بزرگ (LLM) عمل می‌کنند. این رویکرد «منوی کامل» برای مجموعه‌های کوچک ابزارها پاسخگو است، اما با رشد کاتالوگ‌ها به یک بدهی مالی و فنی تبدیل می‌شود. زمانی که منوی ابزارها از ۵۰ تا ۱۰۰ مورد فراتر می‌رود، توسعه‌دهندگان معمولاً شاهد جهشی در تأخیر (Latency)، افزایش هزینه‌های توکن و افت قابل اندازه‌گیری در دقت انتخاب ابزار هستند.
تفکیک سیستم ۱ در مقابل سیستم ۲
برای درک دلیل اثربخشی Jev، ضروری است بین انواع مدل‌ها تمایز قائل شویم. یک مدل «سیستم ۱» برای تصمیمات سریع، ارزان و محدود ساخته شده است. در مقابل، مدل «سیستم ۲» همان LLM سنگین‌تر و کندتری است که برای استدلال در کارهای باز طراحی شده است؛ نمونه‌هایی از این دست شامل «سه غول» (ChatGPT، Claude، Gemini) یا Grok هستند.
بسیاری از تیم‌ها سعی می‌کنند مشکل مسیریابی را با استفاده از یک ساختار چندعاملی حل کنند که در آن یک عامل تصمیم می‌گیرد کدام عامل متخصص یا ابزار در مرحله بعد اجرا شود. با این حال، اگر آن عامل مسیریاب همچنان یک LLM کامل سیستم ۲ باشد که در هر گام تمام طرح‌های (Schema) ابزارها را می‌بیند، هزینه صرفاً از یک فراخوانی به فراخوانی دیگر منتقل شده است و حذف نشده است. استفاده از یک مدل سیستم ۱ مانند Jev در این جایگاه، اجازه می‌دهد تا LLM گران‌قیمت فقط برای پر کردن آرگومان‌ها و نوشتن گزارش نهایی رزرو شود. این رویکرد یادآور مدل‌های تخصصی‌تر است که با جایگزینی توزیع احتمالات با تولید متن در منطق تصمیم‌گیری سعی در بهینه‌سازی ساختارهای تصمیم‌گیری دارند.
برای حل این مسئله، یک آزمایش عملی معماری «مغز دوگانه» را تست کرد. در این ساختار، به جای یک مدل غول‌پیکر که همه کارها را انجام دهد، سیستم از یک مدل سیستم ۱ برای تصمیمات سریع و ارزان و یک مدل سیستم ۲ برای استدلال‌های سنگین استفاده می‌کند. در این چیدمان، Jev (به عنوان مدل سیستم ۱) نقش مسیریاب را ایفا می‌کند، در حالی که مدل‌هایی مانند Moonshot Kimi K3 یا GPT-6 Astra اجرای واقعی وظایف را بر عهده می‌گیرند.
مکانیسم مسیریابی
این آزمایش سه وضعیت متمایز را در وظایفی شامل ۵۰، ۱۰۰ و ۲۰۰ ابزار مقایسه کرد:
- وضعیت الف (Kimi Full-Menu): مدل Moonshot Kimi K3 (از طریق OpenRouter) در هر گام تمام منوی ابزارها را می‌بیند و گزینه
tool_choiceروی حالت خودکار (auto) تنظیم شده است. این مدل می‌تواند در یک پاسخ چندین ابزار را فراخوانی کند یا برای نوشتن یادداشت حادثه متوقف شود. - وضعیت ب (Jev Router): مدل TypeSafe Jev 1.13 (از طریق API تصمیمات OpenRouter) وظیفه، حقایق جمع‌آوری شده تا آن لحظه و یک منوی انتخاب شامل تمام ابزارها به‌علاوه یک گزینه ویژه برای «پایان» (finish) را می‌بیند. Jev دقیقاً یک نام ابزار را برمی‌گرداند. سپس Kimi تنها طرح همان یک ابزار را برای پر کردن آرگومان‌ها می‌بیند. وقتی Jev گزینه «پایان» را انتخاب می‌کند، Kimi یادداشت نهایی را بدون نیاز به هیچ ابزاری می‌نویسد.
- وضعیت ج (Astra Full-Menu): مدل OpenAI GPT-6 Astra (مدل
openai/gpt-6-astraاز طریق OpenRouter) از همان حلقه منوی کامل مشابه وضعیت الف استفاده می‌کند. این حالت به عنوان معیار استاندارد سازمانی (Enterprise Baseline) در نظر گرفته شده است.
جزئیات و زمینه آزمایش
در این تست از تعاریف واقعی ابزارهای MCP (پروتکل زمینه مدل) استفاده شد که به صورت تو در تو طراحی شده بودند تا مجموعه‌های کوچک‌تر در دل مجموعه‌های بزرگ‌تر قرار گیرند. محیط آزمایش از نتایج ابزارهای جعلی اما سازگار برای GitHub، Kubernetes و Grafana استفاده کرد تا اطمینان حاصل شود که هر مسیریاب در دنیای یکسانی فعالیت می‌کند.
ترکیب کاتالوگ‌ها:
- ۵۰ ابزار: ابزارهای MCP مربوط به GitHub.
- ۱۰۰ ابزار: ۵۰ ابزار اولیه به‌علاوه ابزارهای MCP مربوط به Kubernetes.
- ۲۰۰ ابزار: ۱۰۰ ابزار قبلی به‌علاوه ابزارهای MCP مربوط به Grafana.
وظایف بررسی (Investigation Tasks):
هر اندازه کاتالوگ با یک وظیفه خاص در سبک SRE (مهندسی قابلیت اطمینان) تست شد:
- وظیفه ۵۰ ابزاری: بررسی تأخیر در پرداخت (checkout latency) پس از یک تغییر اخیر. عامل باید مشکل باز checkout را پیدا کند، کامیتی که timeout را تغییر داده شناسایی کند، محتوای فایل، PR باز، وضعیت CI و اسکن اسرار (secret scanning) را بررسی کند. در نهایت باید عبارت "suspect abc1234" را در مورد مشکل checkout کامنت کند و یک یادداشت حادثه بنویسد.
- وظیفه ۱۰۰ ابزاری: ادامه کار در فضای نام (namespace) پرداخت‌ها. عامل باید پادهای checkout را لیست کند، لاگ‌های پادهایی که Ready نیستند را بخواند، رویدادهای هشدار (warning events) را لیست کرده و Deployment را بررسی کند تا تصمیم بگیرد آیا علامت کلاستر با یک timeout کلاینت ۲۰۰ میلی‌ثانیه‌ای مطابقت دارد یا خیر، و سپس یادداشت حادثه را بنویسد.
- وظیفه ۲۰۰ ابزاری: اتمام کار با متریک‌ها. عامل باید Prometheus را برای p95 checkout، Loki را برای لاگ‌های deadline-exceeded کوئری کند و قوانین هشدار فعال (firing alert rule) و گروه OnCall را لیست کند تا تصمیم بگیرد آیا این یک مورد مثبت واقعی (true positive) است و آیا باید timeout را به حالت قبل برگرداند (roll back) یا خیر، و سپس یادداشت حادثه را بنویسد.
عملکرد در مقیاس بالا
در مقیاس ۵۰ ابزار، تفاوت هزینه بین Kimi و ترکیب Jev+Kimi ناچیز بود و هر دو تقریباً ۰.۰۸۶ دلار هزینه داشتند. Astra نیز وظیفه را حل کرد و با پاسخ طلایی (golden answer) مطابقت داشت، اما هزینه‌ای حدود ۰.۱۴۴ دلار داشت.
با رشد کاتالوگ به ۱۰۰ ابزار، هزینه ترکیب Jev+Kimi به ۰.۰۳۱ دلار کاهش یافت، در حالی که Kimi در حالت منوی کامل ۰.۰۷۸ دلار و Astra مبلغ ۰.۲۲۸ دلار هزینه داشتند. در این سناریو، هر سه پیکربندی با پاسخ طلایی مطابقت داشتند.
در نقطه ۲۰۰ ابزار، شکاف کارایی بیشتر شد. ترکیب Jev+Kimi هزینه ۰.۰۳۱ دلار را حفظ کرد که نشان‌دهنده کاهش ۴.۵ برابری هزینه در مقایسه با Kimi منوی کامل (۰.۱۳۹ دلار) و کاهش ۸ برابری در مقایسه با Astra منوی کامل (۰.۲۴۴ دلار) است. هزینه خودِ Jev برای این عملیات بسیار پایین و در حدود ۰.۰۰۴۰ دلار باقی ماند.
موازنه توکن‌ها و گام‌ها (Hops)
یک موازنه حیاتی، «تعداد گام‌ها» است. چون Jev مجبور است در هر دور فقط یک ابزار انتخاب کند، برای تکمیل یک وظیفه به نوبت‌های بیشتری نیاز دارد. برای مثال، در تست ۲۰۰ ابزاری، Jev به ۵ گام نیاز داشت در حالی که Astra تنها در ۲ گام کار را تمام کرد. این به این دلیل است که LLMهای منوی کامل می‌توانند چندین ابزار را در یک پاسخ دسته‌بندی (batch) کنند، در حالی که Jev در هر فراخوانی تنها یک گزینه برمی‌گرداند. گام‌های کمتر لزوماً به معنای مدل «هوشمندتر» نیست، بلکه اغلب نشان‌دهنده فراخوانی‌های موازی ابزار است. این چالش در کاهش تأخیر، مشابه آنچه در بهبود قابلیت اطمینان و کاهش Latency توسط Strands Decider 2B مشاهده شد، یکی از محورهای اصلی بهینه‌سازی عامل‌های هوشمند است.
با این حال، توکن‌های پرامپت برای LLM پرکننده (filler) به‌شدت سقوط کرد. در تست ۱۰۰ ابزاری، توکن‌های پرامپت Kimi از ۵۵,۰۳۲ در حالت منوی کامل به تنها ۵,۰۳۵ در حالت جفت‌شده با Jev رسید. در ۲۰۰ ابزار، توکن‌های پرامپت Kimi در حالت منوی کامل ۴۴,۲۱۵ بود، در حالی که با استفاده از Jev به ۴,۱۹۷ توکن کاهش یافت. دلیل این امر آن است که مدل گران‌قیمت دیگر مجبور نیست وزن کل کاتالوگ را در هر نوبت حمل کند.
دقت و نتایج
به‌رغم تعداد گام‌های بیشتر، کیفیت بررسی‌ها ثابت ماند. هر سه پیکربندی با موفقیت علت ریشه‌ای حادثه شبیه‌سازی شده را شناسایی کردند: p95 معادل ۴.۲ ثانیه، ۱۲۰۰ تطبیق در Loki، هشدارهای فعال و توصیه به بازگرداندن (roll back) timeout.
برخی امتیازهای «شکست طلایی» (golden fail) رخ داد، اما این موارد به عوامل خاصی نسبت داده شد:
- باگ‌های امتیازدهی: سیستم بررسی به دنبال زیررشته "1200" بود، اما مدل‌ها آن را به صورت "1,200" (با کاما) نوشتند.
- اثرات جانبی: در تست ۵۰ ابزاری، Jev در بررسی سخت‌گیرانه شکست خورد زیرا Kimi پس از انتخاب
add_issue_commentتوسط Jev، یک کامنت «یادداشت داخلی» دوم را ارسال کرد، هرچند کامنت مورد نیاز "suspect abc1234" وجود داشت.
مشاهدات و کارهای آینده
نویسنده اشاره کرد که OpenRouter می‌تواند یک مدل (slug) را به میزبان‌های مختلف با قیمت‌های متفاوت هدایت کند که ممکن است باعث نوسانات جزئی در هزینه شود. علاوه بر این، تلاشی برای ایجاد یک وضعیت «مسیریاب جاسازی» (embedding-router) متوقف شد، زیرا نزدیک‌ترین همسایه در اولین گام گزینه «پایان» را انتخاب کرد، چرا که متن وظیفه پیش از جمع‌آوری هرگونه حقیقتی، به نوشتن یادداشت حادثه اشاره کرده بود.
یک ادامه طبیعی برای این آزمایش، جفت کردن Jev با Astra به عنوان پرکننده آرگومان‌ها خواهد بود تا اطمینان حاصل شود که مدل سازمانی به جای منوی کامل، در هر گام تنها یک طرح ابزار را می‌بیند.
این تغییر در معماری، پرسش بنیادین توسعه‌دهندگان عامل‌ها را تغییر می‌دهد. هدف دیگر این نیست که آیا یک LLM «می‌تواند» ۲۰۰ ابزار را ببیند، بلکه این است که آیا «نیاز دارد» در هر نوبت آن‌ها را ببیند؟ با تبدیل مسیریابی به یک انتخاب محدود، توسعه‌دهندگان می‌توانند قدرت استدلال گران‌قیمت GPT-6 یا Claude را برای کارهایی نگه دارند که واقعاً به آن نیاز دارند.
برای کسانی که عامل‌هایی با کاتالوگ‌های MCP رو به رشد می‌سازند، این نتایج نشان‌دهنده حرکت به سمت مسیریابی ماژولار است. اثر ثانویه این موضوع، کاهش قابل توجه «مالیات توکن» پرداختی به ارائه‌دهندگانی مانند OpenAI است، جایی که قیمت‌گذاری هر توکن، طراحی‌های منوی کامل در مقیاس بالا به‌شدت گران می‌کند.
توسعه‌دهندگان می‌توانند کد کامل، کاتالوگ‌ها و نتایج خام JSON این آزمایش را در مخزن گیت‌هاب نویسنده (https://github.com/karthik-bommineni/tool-routing-experiment-with-jev) بررسی کنند تا مسیریابی مشابهی را در استک خود پیاده‌سازی نمایند.
گام بعدی شما
- اگر از مدل‌های گران‌قیمت برای انتخاب ابزار استفاده می‌کنید، معماری تفکیک‌شده (Router-Filler) را تست کنید.
- برای کاهش هزینه استنتاج، از مدل‌های کوچک‌تر (SLM) برای وظایف طبقه‌بندی و مسیریابی استفاده کنید.
- کدهای کامل و نتایج JSON این آزمایش را در مخزن گیت‌هاب نویسنده بررسی کنید تا مدل پیاده‌سازی مشابه را در استک خود به کار ببرید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو