اگر امروز برای اجرای عاملهای هوش مصنوعی هزینه پرداخت میکنید، احتمالاً بخش بزرگی از بودجه شما صرف خواندن تکراریِ دستورالعملهای ابزارها میشود. یک تغییر ساده در طراحی بستر متنی میتواند صورتحساب توکنهای شما را تا ۴.۲ برابر کاهش دهد.
به نقل از مطالعهای که در ۱۵ سپتامبر ۲۰۲۶ منتشر شد و از کتاب Context Engineering: Turn LLMs From Liars Into Experts اقتباس شده است، تغییر به طراحی بومی پروتکل زمینه مدل (Model Context Protocol یا MCP) توانست تعداد توکنهای ورودی را در یک تسک اتوماسیون مرورگر از ۱۱۴,۰۰۰ به ۲۷,۰۰۰ برساند. این رویکرد در واقع بخشی از گذار صنعت به سمت فرمتهای استاندارد برای یکپارچهسازی ابزارهاست تا جایگزینی برای رابطهای اختصاصی و پیچیده باشد. نکته کلیدی این است که این کاهش چشمگیر بدون تغییر در مدل زبانی یا مرورگر رخ داده است.
بسیاری از توسعهدهندگان با MCP مانند یک سامانه تکلایه برخورد میکنند که فقط روی استفاده از ابزار (Tool Use) متمرکز است. این همان لایهای است که همه ابتدا میسازند: توابعی مثل get_weather()، send_email() یا query_database(). آنها این توابع را ایجاد کرده و تمام مستندات لازم را در بخش توضیحات ابزار میریزند. این رویکرد یک «مالیات توکنی» ایجاد میکند؛ به این معنا که مدل در هر نوبت گفتگو، هزینه خواندن توضیحات ابزار را میپردازد، صرفنظر از اینکه آیا واقعاً از آن ابزار استفاده میکند یا خیر.
این وضعیت شبیه این است که یک توسعهدهنده برای یک ربات دفترچه راهنما بنویسد. در روش قدیمی، ربات مجبور است برای هر قدمی که برمیدارد، کل دفترچه ۱۰۰ صفحهای را از ابتدا بخواند. در طراحی بومی MCP، ربات فقط در زمانی که نیاز دارد، به صفحه خاصی که به آن نیاز دارد نگاه میکند. نتیجه تکخطی این مطالعه موردی کاملاً روشن است: صورتحساب توکنهای شما، هزینه توضیحات ابزارهاست، نه خودِ ابزارها.
چارچوب سه لایه
برای رسیدن به این صرفهجویی، این چارچوب بستر متنی را به سه لایه مجزا بر اساس نیازهای عامل تقسیم میکند. نادیده گرفتن هر یک از این سه لایه یا منجر به کاهش قدرت بیان مدل میشود یا باعث میشود توکنهای بیشتری پرداخت کنید:
- منابع (Resources): منابع اطلاعاتی فقط-خواندنی که مدل میتواند در صورت نیاز فراخوانی کند (مانند
file://یاdb://یاapi://). از این لایه برای زمینههای ایستا یا دادههایی که به کندی تغییر میکنند استفاده کنید. این لایه ارزان است چون دادهها فقط زمانی که به آنها ارجاع داده شود، فراخوانی میشوند. - ابزارها (Tools): عملیاتهای قابل اجرا که اثرات جانبی دارند، مانند
create_fileیاsend_email. از این لایه برای اقداماتی که عامل در دنیای واقعی انجام میدهد استفاده کنید. این لایه هزینه متوسطی دارد زیرا تعریف ابزار در هر فراخوانی در بستر متنی باقی میماند. - پرامپتها (Prompts): قالبهای پارامتریک و قابل استفاده مجدد که کلاینت میتواند آنها را فراخوانی کند. از این لایه برای جریانهای تکراری مانند بررسی کد (Code Review)، دستهبندی تیکتها یا پاسخ به حوادث (Incident Response) استفاده کنید. این لایه ارزان است چون در سمت سرور قرار دارد و کلاینت آنها را فقط هنگام درخواست دریافت میکند.
چرا مصرف توکن از ۱۱۴ هزار به ۲۷ هزار رسید؟
طبق گزارش این مطالعه، در ساختار پرهزینه (۱۱۴ هزار توکن)، از طراحی سبک CLI (رابط خط فرمان) استفاده شده بود. در این حالت، تمام مستندات کامل خط فرمان، استراتژیهای مدیریت خطا و مثالهای کاربردی برای ۳۰ ابزار اولیه (Primitives) مختلف مستقیماً در بستر متنی ریخته شده بود.
در این طراحی، بستر متنی به صورت زیر ساخته میشد:
generate_cli_documentation(): ۳۰ ابزار اولیه با مستندات کاملgenerate_cli_examples(): مثالهای کاربردی برای هر یکgenerate_error_handling_docs(): تمام کدهای خطا و استراتژیهای تلاش مجدد (Retry)- تسک واقعی: حدود ۸ هزار توکن
این منجر به این شد که در هر بار اجرا، تقریباً ۱۰۶ هزار توکن از مستندات ابزارها روی تسک اصلی قرار بگیرد.
در ساختار بهینه (۲۷ هزار توکن)، این مدل با یک لایه انتزاعی سطح بالا جایگزین شد. سرور بهجای ارائه ابزارهای سطح پایین، مجموعهای کوچک از ابزارهای مبتنی بر «قصد» (Intent) را ارائه داد، مانند:
playwright_navigate(url)playwright_click(selector)playwright_type(selector, text)playwright_screenshot()playwright_extract_text(selector)
در این مدل، سرور مستندات سطح CLI، سیاستهای تلاش مجدد و نگاشت خطاها را بهصورت داخلی نگه میدارد. سه مکانیزم خاص این بهرهوری را ایجاد کردند:
۱. سطح انتزاع: سبک CLI جزئیات سطح پایین است، اما MCP یک انتزاع سطح بالا است. کلاینت «قصد» خود را میفرستد و سرور نحوه اجرای فنی را پیدا میکند.
۲. جداسازی بستر متنی: جزئیات پیادهسازی در سرور MCP میماند و کلاینت فقط آنچه را میبیند که برای تصمیمگیری درباره اقدام بعدی لازم است.
۳. تفکیک پویا: MCP جزئیات را زمانی باز میکند که ابزار واقعاً اجرا شود. در سبک CLI، باید همه چیز از ابتدا توصیف شود تا در صورت نیاز در دسترس باشد.
منطق تصمیمگیری برای جایگذاری بستر متنی
برای اینکه بدانید هر تکه از بستر متنی به کدام لایه تعلق دارد، از این قاعده ساده استفاده کنید. بپرسید: آیا عامل نیاز دارد کاری انجام دهد، چیزی بخواند یا چیزی را تکرار کند؟
- انجام کاری $\rightarrow$ ابزار. این شامل اثرات جانبی، تغییرات در دادهها و فراخوانیهای خارجی است.
- خواندن چیزی $\rightarrow$ منبع. این شامل دادههای فقط-خواندنی است که از طریق URI قابل دسترسی هستند و در صورت نیاز فراخوانی میشوند.
- تکرار چیزی $\rightarrow$ پرامپت. این شامل قالبهایی است که کلاینت میتواند با نام آنها را فراخوانی کند.
اگر متوجه شدید مستندات کامل یک API را در فیلد توضیحات ابزار قرار دادهاید، متوقف شوید؛ آن داده یک «منبع» (Resource) است. اگر هر بار یک دستورالعمل ۶ مرحلهای را در پرامپت سیستمی تکرار میکنید، متوقف شوید؛ آن یک «پرامپت» (Prompt) است.
وضعیت پشتیبانی کلاینتها در اواخر ۲۰۲۶
پیادهسازی این لایهها در کلاینتهای بزرگ هوش مصنوعی تا سپتامبر ۲۰۲۶ متفاوت است. مشخصات MCP سه لایه دارد، اما کلاینتها آنها را بهطور یکسان پیادهسازی نکردهاند:
- Claude Desktop: بهطور کامل از منابع، ابزارها و پرامپتها پشتیبانی میکند. پرامپتها در منوی اسلش (slash-menu) داخل چت ظاهر میشوند.
- Cursor: پشتیبانی قوی از ابزارها دارد. پشتیبانی از منابع در طول سال ۲۰۲۶ بهبود یافته اما همچنان ناهماهنگ است. پشتیبانی از پرامپتها در بهروزرسانی اخیر اضافه شد و بهصورت سرتاسری در پیکربندی
mcp.jsonکار میکند. - ChatGPT: از سال ۲۰۲۵ شروع به عرضه MCP کرد (بتا Developer Mode در سپتامبر ۲۰۲۵ عرضه شد). عرضه برای نسخههای Enterprise و Business تا سال ۲۰۲۶ ادامه یافت. پشتیبانی از ابزارها مستحکم است، در حالی که منابع و پرامپتها هنوز در حال عرضه هستند.
- کلاینتهای SDK سفارشی: استفاده از SDKهای پایتون یا تایپاسکریپت به شما اجازه میدهد هر آنچه مینویسید را پیادهسازی کنید. افزودن منابع و پرامپتها بسیار ساده است و شدیداً توصیه میشود.
بازبینی مشخصات MCP در ۲۸ ژوئیه ۲۰۲۶ با معرفی متد server/discover این چشمانداز را بهبود بخشید. اکنون شناسایی قابلیتها از طریق این متد انجام میشود، بنابراین یک کلاینت استاندارد میتواند بهجای حدس زدن، بپرسد که سرور چه خدماتی ارائه میدهد.
شکستهای رایج در طراحی
یک اشتباه متداول این است که همه چیز در لایه ابزارها قرار گیرد چون این لایه آشناترین بخش است. این یک تجربه رایج برای توسعهدهندگان است. نشانههای این شکست عبارتند از:
- توضیحات ابزاری که هر کدام بیش از ۵۰۰ کلمه هستند.
- وجود بیش از ۳۰ ابزار در سطح دسترسی.
- پرامپتهای سیستمی حاوی دستوراتی مثل «هنگام استفاده از ابزار X، به یاد داشته باش ابتدا Y را چک کنی».
- هزینه توکنی شرمآور در هر نوبت گفتگو.
راه حل این است که ابزارهای سطح پایین مرتبط را در یک «ابزار قصد-محور» ادغام کنید، مطالب مرجع را به منابع (Resources) منتقل کنید و دستورالعملهای تکراری را به پرامپتها (Prompts) ببرید. در این حالت، سرور MCP ارکستراسیون را بر عهده میگیرد و عامل دیگر هزینه آن را با توکن پرداخت نمیکند. این بهینهسازیهای ساختاری در کنار ابزارهای زیرساختی مانند گیتوی Bifrost که هزینههای استنتاج را تا ۹۲.۲٪ کاهش داده است، میتواند بهرهوری عاملها را به شدت افزایش دهد. اصل طراحی ساده است: توضیحات ابزار، بخشی از بستر متنی است و بستر متنی قیمت دارد.
گام بعدی شما
اگر در حال حاضر یک سرور MCP را اجرا میکنید، این سه اقدام عملی را برای بهینهسازی هزینه توکنهای خود انجام دهید:
۱. حسابرسی توکنها: تعداد توکنهایی که تعاریف ابزارهای شما در یک اجرای معمولی مصرف میکنند را بشمارید. اگر بیش از ۲۰٪ بودجه کل ورودی شماست، جای فشردهسازی وجود دارد.
۲. انتقال مطالب مرجع: یک مورد را شناسایی کنید که در حال حاضر در پرامپت سیستمی یا توضیحات ابزار است اما در واقع یک مطلب مرجع است. آن را به یک Resource منتقل کنید.
۳. استخراج جریانهای تکراری: یک جریان چندمرحلهای را که اغلب فراخوانی میکنید شناسایی کنید. آن را به یک Prompt تبدیل کنید تا بهجای بازسازی در کلاینت در هر بار اجرا، روی سرور ذخیره شود.
هیچکدام از این تغییرات نیازی به بازنویسی عامل شما ندارد؛ اینها صرفاً تغییرات پیکربندی در سمت سرور MCP هستند. کلاینت در اولین اتصال بعدی از این مزایا بهرهمند خواهد شد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو