‏چطوری مصرفِ توکنِ یه ایجنت رو ۹۴٪ کم کردم

نویسنده برای این‌که ایده‌ی «harnessِ تخصصی» رو ملموس کنه، یه مثالِ واقعی از کارِ روزمره‌ش می‌زنه: یه skill داره که تو آرشیوِ پست‌های وبلاگش می‌گرده، یه چیزِ ارزشِ بازنشر پیدا می‌کنه، چک می‌کنه که اخیراً بهش اشاره نکرده باشه، و یه پستِ کوتاهِ لینکدین می‌سازه که بهش لینک می‌ده. نسخه‌ی اولیه کاملاً با دستورهای زبانِ طبیعی تو قالبِ یه Agent Skill نوشته شده بوده و ایجنتش (فعلاً Codex) تو هر اجرا باید اون دستورها رو تفسیر می‌کرده، نقشه می‌ریخته، ابزار صدا می‌زده و وضعیتِ کارو دنبال می‌کرده.

به گفته‌ی نویسنده این برای ساختِ نسخه‌ی اول عالی بوده، چون زبانِ طبیعی بیانو آسون می‌کنه. ولی بعد از این‌که یه skill بارها اجرا می‌شه و مدام همون مسیرو می‌ره، بیشترِ رفتارش دیگه اکتشافی نیست. این skill همیشه تو همون جاها می‌گرده، همون فهرستِ محتوا رو می‌سازه، همون فیلترهای پست‌های اخیرو اعمال می‌کنه و همون state رو ذخیره می‌کنه. هیچ‌کدومِ این‌ها لازم نیست هر صبح از صفر استدلال بشه — خیلی‌هاشون اصلاً LLM نمی‌خوان. فقط دو مرحله واقعاً به مدل نیاز دارن: انتخابِ یه گزینه‌ی خوب از فهرست، و نوشتنِ پیش‌نویس.

برای همین نویسنده skill رو به یه «harnessِ تخصصی» کامپایل کرده. skillِ جدید تقریباً دیگه skill نیست؛ یه bootloaderِ نازکه که یه برنامه‌ی Python رو صدا می‌زنه. اون برنامه منابعِ معلومو می‌گیره، فهرستو می‌سازه، پست‌های اخیرو چک می‌کنه و کلِ گردش‌کارو مدیریت می‌کنه، و فقط برای انتخاب و تولید سراغِ LLM می‌ره. نتیجه ۹۴٪ توکنِ کمتر، ۸۷٪ تأخیرِ کمتر و عملاً همون کیفیتِ خروجی بوده. نکته اینه که این صرفه‌جویی از عوض‌کردنِ مدل با یه مدلِ ارزون‌تر نیومده؛ همون مدل سرِ جاشه و فقط فراخوانی‌هایی حذف شدن که کارشونو کدِ معمولی مستقیم‌تر انجام می‌ده.

نویسنده توضیح می‌ده منظورش از «کامپایل» چیه: از اجراهای روزانه‌ی قبلی traceهای واقعی داشته که نشون می‌داد ایجنت دقیقاً چی کار کرده — برنامه‌ریزی، فراخوانیِ ابزار، انشعاب‌ها و stateها. این traceها رو همراهِ skillِ اصلی به یه مدلِ قوی داده و ازش خواسته تشخیص بده کدوم قدم‌ها واقعاً به LLM نیاز دارن و کدوم‌ها اون‌قدر پایدار شدن که بشه کد نوشت، بعد harnessِ تخصصی رو بسازه. از نظرش قیاسِ کامپایلر همینه: از یه بازنماییِ منعطف و سطح‌بالا شروع می‌کنی، و بعد از این‌که گردش‌کار شکلِ واقعیشو نشون داد، بخش‌های پایدارو به یه بازنماییِ کارآمدتر پایین می‌بری.

الگویی که پیشنهاد می‌ده اینه: اول گردش‌کارو به‌شکل یه skillِ زبانِ طبیعی بیان کن، به‌قدرِ کافی اجراش کن تا trace جمع بشه و رفتار پالوده بشه، بخش‌های پایدار و قطعی‌شده رو پیدا کن، اون‌ها رو به کد کامپایل کن، و فراخوانیِ LLM رو فقط تو همون چند نقطه‌ای که قضاوتِ معنایی لازمه نگه دار. این کار یه هزینه‌ی یک‌باره داره ولی بعدش گردش‌کار می‌تونه صدها یا هزاران بار اجرا بشه — همون اقتصادِ آشنای بهینه‌سازی: یه بار خرج کن، رو استفاده‌ی مکرر سرشکن کن.

نویسنده یه نکته‌ی انگیزشی هم اضافه می‌کنه: انتظار نداره این تکنیک‌ها عمدتاً از شرکت‌های بزرگِ مدل بیان، چون کسب‌وکارشون فروشِ توکنه، ترجیحاً توکنِ زیاد از گرون‌ترین مدل‌ها. تکنیکی که کیفیتو حفظ کنه ولی مصرفِ توکنو ۹۴٪ کم کنه مستقیم برخلافِ این اقتصاده. از نظرش همین یه فرصتِ بزرگ برای کاربرها و سازنده‌های مستقله که ابزارهایی بسازن که گردش‌کارهای تکراری رو وارسی و بخش‌های قطعی‌شونو به کد منتقل کنن.

نکات کلیدی:

• بعد از این‌که یه گردش‌کار تثبیت شد، بیشترش دیگه به استدلالِ LLM نیاز نداره
• «کامپایل‌کردن» یعنی بخش‌های پایدارو به کدِ قطعی ببری و LLM رو فقط برای قضاوتِ معنایی نگه داری
• نتیجه‌ش ۹۴٪ توکنِ کمتر و ۸۷٪ تأخیرِ کمتر با تقریباً همون کیفیت بوده
• الگو: با زبانِ طبیعی کشف کن، با traceها بفهم، بعد چیزی که تثبیت شده رو کامپایل کن