معماری یک ایجنت حول کش پرامپت
خلاصهٔ کاملتر
تیم ویکتور تو این مقاله از یه واقعیت ساده شروع میکنه: APIهای مدل بیحالتن. هیچ نشستی سمت ارائهدهنده وجود نداره، پس هر فراخوانی باید کل پرامپت سیستمی، تعریف ابزارها و تمام تاریخچه رو با خودش ببره. برای چت آدمیزاد بیاهمیته، ولی برای ایجنت همهچیزه: هزینه بهشکل درجهدو رشد میکنه. مثال جاریشون یه ترد ۴۰ مرحلهایه که ۲.۱۷ میلیون توکن ورودی میفرسته، درحالیکه رونوشت نهایی فقط ۸۵ هزار توکنه.
کش پرامپت دقیقاً همین الگو رو هدف گرفته: ارائهدهنده حالت پردازششدهٔ پیشوند رو نگه میداره و اگه درخواست بعدی با همون بایتها شروع شه، از همونجا ادامه میده. روی Claude Opus 4.8، نوشتن در کش ۱.۲۵ برابر ورودی عادی و خوندن از کش یکدهم قیمته. همون ترد نمونه با کش از ۱۱.۳۵ دلار به ۲.۰۷ دلار میرسه، و به گفتهٔ نویسندهها سود پنهانترش تأخیره: توکنهای کششده مرحلهٔ prefill رو رد میکنن.
گیر کار دو تا شرط تیزه: تطابق باید بایتبهبایت باشه و عمر کش کوتاهه (حدود ۵ دقیقه که با هر بار استفاده تازه میشه). یه کاراکتر تغییر تو پرامپت سیستمی یا یه timestamp تزریقشده، همهچیز رو با قیمت کامل بازمحاسبه میکنه. ویکتور از این نتیجه گرفته که ترد باید یه لاگ فقطافزودنی باشه: هیچ پیامی ویرایش یا جابهجا نمیشه و تغییرات وسط ترد بهجای ویرایش پرامپت سیستمی، بهصورت پیام جدید اضافه میشن.
جالبترین تصمیم معماریشون سر ابزارهاست. ویکتور به بیش از ۳۲۰۰ ابزار وصله و جا دادن اسکیمای همهشون تو پرامپت نه ممکنه نه مفید؛ ولی بارگذاری پویای ابزارها هم پیشوند رو از موقعیت صفر خراب میکنه. راهحلشون اینه که مدل فقط چند ابزار بومی ثابت ببینه و بقیهٔ یکپارچهسازیها به شکل تابع معمولی تو یه SDK داخل سندباکس در دسترس باشن؛ یعنی مدل بهجای فراخوانی ابزار، کد مینویسه:
from sdk.tools.stripe_tools import list_subscriptions
subs = await list_subscriptions(status="active", limit=100)فشردهسازی تاریخچه هم داخل کش خودِ ترد انجام میشه: درخواست خلاصهسازی دقیقاً همون ترد زندهست با یک پیام دستور که تهاش اضافه شده، با همون تعریف ابزارها ولی tool_choice="none". نتیجهاش ضدشهودیه — فرستادن کل تاریخچه ارزونتر از فرستادن یه برش کوتاهه، چون برش کوتاه اصلاً به کش نمیخوره. خلاصهکردن ۶۰ هزار توکن بهشکل مستقل حدود ۰.۳۰ دلار درمییاد و داخل کش حدود ۰.۰۳ دلار.
زمانبندی فشردهسازی هم از چرخهٔ عمر کش پیروی میکنه. ترد فعال هرگز فشرده نمیشه، چون بازنویسی تاریخچه کل کش رو باطل میکنه؛ ولی ترد ساکت دقیقهٔ سوم از TTL پنجدقیقهای فشرده میشه تا خودِ خلاصهسازی هنوز سوار کش گرم باشه. آستانهها هم فرق دارن: حدود ۵۰ هزار توکن برای ترد فعال و ۱۶ هزار برای ترد ساکت. رفتار هر ارائهدهنده هم متفاوته — کش OpenAI خودکاره و جریمهٔ نوشتن نداره — پس جمعبندی نویسندهها اینه که کش یه جزء سیستمی با چرخهٔ عمر خودشه، نه بهینهسازی صورتحسابی که آخر کار روش میپاشن.
نکات کلیدی:
- یه ترد ۴۰ مرحلهای ۲.۱۷ میلیون توکن میفرسته برای رونوشتی که ۸۵ هزار توکنه
- خوندن از کش یکدهم قیمت ورودی عادیه و نوشتن در کش ۱.۲۵ برابر
- کش فقط با پیشوند بایتبهبایت ثابت کار میکنه، پس ترد باید فقطافزودنی باشه
- ابزارها بهجای اسکیما در پرامپت، به شکل تابع در یک SDK به مدل داده میشن
- ترد فعال رو فشرده نکنید؛ ترد ساکت رو درست قبل از سردشدن کش فشرده کنید




