چند سال پیش وقتی مفهوم Prompt Engineering بهوجود اومد، تصور خیلیها محدود و معطوف به یه چیزی شبیه هنر جملهنویسی بود. اینکه چجوری به مدل بگیم چه میخواهیم، چجوری نقش مدل رو براش توضیح بدیم، چجوری ساختار خروجی مورد نظرمون رو تبیین کنیم، و چجوری با مثال زدن، رفتار مدل رو کمی قابل پیشبینی کنیم.
اما هر چی agentها جدیتر شدن، مسئله هم عوض شد.
کمکم داستان ما با AI از سطح پرامپت فراتر رفت. ایجنتها فقط قرار نیست جواب بدن بلکه میتونن ابزارها رو فراخوانی کنن، با فایلها کار کنن، کد بنویسن، تست کنن، خطاها رو تحلیل کنن، مسیرشون رو در طول کار اصلاح کنن، و نهایتاً کارهای قابل اتکا رو به انجام برسونن. توی چنین فضایی، چیزی که رفتار ایجنت رو جهتدهی میکنه فقط مدل نیست. یک لایهی مهمتر و کاربردیتر هم داریم، یعنی skill.
در واقع Skill یعنی مجموعهای از دستورالعملها، قواعد، تجربهها، قراردادها و روشهای انجام کار که ایجنت موقع حل مسئله ازشون استفاده میکنه. مثلا اینکه برای یک benchmark خاص چجوری شواهد رو جمعآوری کنه، توی اِکسل چجوری فرمولنویسی کنه و بعدش خروجی فرمولها رو صحتسنجی کنه، یا توی کدنویسی چجوری قبل از تغییر فایلها ساختار پروژه رو درک کنه، یا توی یک workflow سازمانی چجوری از تکرار خطاهای قبلی جلوگیری کنه. همهی اینها مهارتهای مختلفی هستن که ما توسعه و در دسترس ایجنت قرار میدیم.
تا امروز، اکثر این skillها دستی نوشته میشدن (این شامل skillهایی که انسان از AI درخواست میکنه تا بنویسه هم میشه؛ چون در عمل باز یک فرایند دستی است با ابزاری به نام AI). یک انسان میشینه، چند تجربه رو تبدیل به rule میکنه، و یک فایل Markdown تولید میکنه، و امیدوار میشه که دفعه بعدی ایجنت عملکرد بهتری داشته باشه. این از پرامپت خام کمی بهتره، ولی هنوز یک فرآیند مهندسیشده نیست.
همینجاست که مسئلهای که باعث پیدایش SkillOpt شد شکل گرفته. یعنی اگه skill اینقدر روی رفتار ایجنت اثرگذاره، چرا مثل یک artifact قابل آموزش، قابل ارزیابی و قابل بهبود باهاش برخورد نکنیم؟
ایده اصلی: مدل رو تغییر نده، بهش روشِ کار رو آموزش بده
SkillOpt ماحصل یک کار تحقیقاتی علمی بین محققهای Microsoft و محققینی از سه دانشگاه چینی (دانشگاه ژیایو تُنگ، دانشگاه تُنگجی و دانشگاه فودان) است. و ابزاری تولید شده از دل این پروژه تحقیقاتی تحت عنوان SkillOpt و بهصورت کدباز عرضه شده. ایده اصلیش ساده ولی مهم و کارا است: به جای اینکه وزنهای مدل رو fine-tune کنیم، skill document را train میکنیم. نکته مهمی که توی مقاله اومده اینه که روی ۵۲ از ۵۲ سلول ارزیابی، SkillOpt بهترین یا مساوی با بهترین بوده نتیجه رو گرفته.علاوه بر این +۲۳.۵ امتیاز بهصورت میانگین روی GPT-5.5 یه رقم چشمگیره که تونسته به دست بیاره.
این دیدگاه، مدل اصلی یا همون target model رو ثابت نگه میداره؛ یعنی وزنهایش تغییر نمیکنن، اما یک فایل skill (فایل Markdown)، به عنوان external state برای مدل در نظر گرفته میشه. این فایل همون چیزیه که ایجنت قبل یا حین انجام کار ازش برای تصمیمگیری، صحتسنجی، شناسایی و کاربری ابزارها و نهایتا شکلدهی به خروجی استفاده میکنه.
پس به جای اینکه بگیم: «مدل بلد نیست، پس باید fine-tuneش کنیم»
میگیم: «شاید مدلِ پایه کافی باشه، اما procedure و دستورالعملی که بهش دادیم خام، ناقص یا بیکیفیته.»
این تفاوت کوچیک نیست. چون توی fine-tuning، شما وارد فضای weightها (وزندهی) میشید. هزینهها، داده، زیرساخت، ریسک overfitting، governance و deployment پیچیدهتر میشن. اما توی SkillOpt خروجی نهایی فقط یک فایل best_skill.md است. یعنی یک artifact ساده، قابل خوندن، قابل مرور و بازبینی، قابل نسخهدهی، قابل کنترل، و قابل توزیع.
این دقیقا همون جاییه که موضوع برای تیمهای نرمافزاری و platform engineering مهم میشه. ما سالهاست code رو review میکنیم، test مینویسیم، CI داریم، lint داریم، release gate داریم. اما حالا بخش مهمی از خروجی مهندسی ما توسط agentها و skillها و promptها تولید میشن. اگر این skillها بیکیفیت باشن، خروجی ایجنت هم بیکیفیت میشه. حتی اگر مدلِ پشتش قوی باشه.
SkillOpt چه مسئلهای رو حل میکنه؟
مسئله این نیست که کسی نمیتونه یک skill بنویسه (چه خودش چه AI به واسطه یک پرامپت انسانی). بلکه مسئله اینه که skill خوب نوشتن، با حدس و تجربه شخصی، قابل scale نیست.
فرض کنید یک agent روی ۱۰۰ تا تسک مشابه اجرا میشه. بعضیها رو درست حل میکنه، بعضیها رو غلط. ما میتونیم بنشینیم و manually failureها رو بخونیم و skill رو بهتر کنیم. اما این کار چند تا مشکل داره:
اول اینکه subjective است، یعنی هر کسی ممکنه از failureها برداشت متفاوتی داشته باشه.
دوم اینکه قابل تکرار نیست. معلوم نیست تغییر بعدی، واقعا کارایی و عملکرد رو بهتر کنه یا فقط به نظر ما بهتر بیاد!
سوم اینکه ممکنه skill را overfit کنیم. یعنی برای چند نمونه خاص، بهتر بشه ولی روی نمونههای جدید خرابتر عمل کنه.
چهارم اینکه skillها به مرور فربه و شلوغ میشن. وقتی با هر بار failure یک rule جدید اضافه کنیم، بدون اینکه کسی بپرسه آیا این rule هنوز لازمه یا نه، دقیقا توی مسیر فربهسازی skill پیش میریم.
SkillOpt تلاش میکنه همین فرآیند رو منظم کنه. یعنی skill editing رو از یک فعالیت دستی و احساسی به یک loop شبیه training تبدیل کنه.
SkillOpt چجوری کار میکنه؟
SkillOpt یک حلقه optimization داره که از نظر ذهنی خیلی شبیه training توی شبکه عصبی است، اما به جای weight-space در text-space اتفاق میافته!
۱. اجرای ایجنت با skill فعلی
اول target model با skill فعلی روی تعدادی درخواست اجرا میشه. خروجی این اجراها فقط جواب نهایی نیست. مسیر حل مسئله هم ذخیره میشه: پیامها، tool callها، feedback verifier، metadata task، و score نهایی.
توی ادبیات SkillOpt به اینها trajectory گفته میشه. یعنی SkillOpt فقط نمیبینه که جواب درست بوده یا غلط. میبینه ایجنت چجوری به اون جواب رسیده.
این نکته مهمیه، چون خیلی وقتها failure فقط توی جواب نهایی معلوم نمیشه، بلکه ممکنه ایجنت مسیر اشتباهی رفته باشه که به پاسخ غلط رسیده باشه، verification رو جدی نگرفته باشه، context رو ناقص خونده باشه، یا یک rule خوب رو وسط کار رها کرده باشه.
۲. تحلیل موفقیتها و شکستها
بعد از مرحله اولیه؛ یک optimizer model وارد میشه. این مدل از target model مجزا است. کارش هم انجام درخواست نیست بلکه تحلیل trajectoryها رو انجام میده.
توی این مرحله optimizer model شروع به بررسی failureها و successها در قالب minibatchها میکنه. یعنی مثل training، همهچیز رو یکجا قورت نمیده. دسته به دسته نگاه میکنه و دنبال الگو میگرده:
- کجاها agent اشتباه کرده؟
- چه چیزی توی skill فعلی کم بوده؟
- کدوم rule خوب کار کرده و باید حفظ بشه؟
- چه دستورالعملی مبهم بوده؟
- کدوم بخش skill باعث رفتار بد شده؟
- چه چیزی باید اضافه، حذف یا جایگزین بشه؟
اینجا SkillOpt از add/delete/replace edits استفاده میکنه. یعنی skill رو کورکورانه rewrite نمیکنه، بلکه تغییرات ساختیافته پیشنهاد میده.
۳. محدود کردن مقدار تغییر
توی شبکه عصبی learning rate داریم، و اگه learning rate زیاد باشه، مدل ممکنه از مسیر خوب خارج بشه. اگر خیلی کم باشه، یادگیری کند یا بیاثر میشه. حالا SkillOpt هم یه چیزی مشابه learning rate توی فضای متنی داره: اسمش هم edit budget است.
یعنی optimizer نمیتونه هر بار کل skill رو از نو بنویسه. تغییرات باید محدود باشن و این باعث میشه skill به شکل تدریجی بهتر بشه و رفتارهای درست قبلی با یک rewrite بزرگ نابود نشن!
این نکته برای skillها حیاتیه چون توی فایلهای دستورالعملی، یک جملهی اضافه یا حذفشده، میتونه رفتار ایجنت رو به شدت تغییر بده. اگه روی این فرایند کنترل نداشته باشیم، عملا self-improvement تبدیل میشه به self-randomization!
۴. validation gate
مهمترین بخش SkillOpt این بخش است؛ جایی که هر candidate skill که توسط optimizer ساخته میشه، فقط وقتی پذیرفته میشه که روی held-out validation split بهتر عمل کنه. یعنی فقط چون optimizer گفته «با این تغییر بهتر شد» پذیرفته نمیشه. باید در عمل روی دادهای که برای انتخاب نگه داشته شده، بهتر بشه.
اگر بهتر نشد، ویرایش رد میشه و حتی توی rejected-edit buffer ذخیره میشه تا optimizer دوباره همون مسیر غلط رو تکرار نکنه.
این شبیه همون چیزیه که در مهندسی بالغ داریم: تغییر بدون تست و آزمون و صحتسنجی نباید وارد مسیر اصلی کار بشه. توی دنیای ایجنتها هم همین اصل باید جدی گرفته بشه؛ یعنی ایجنت خودش skill رو تغییر بده، چیز جذابیه، اما بدون gate کنترلی، همین امر جذاب به یه چیز خطرناک تبدیل میشه. ممکنه چیزی رو که ظاهرا منطقیه به skill اضافه کنه و رفتار کلی رو خراب کنه.
SkillOpt میگه self-improvement بدون صحتسنجی، بیشتر شبیه توهم پیشرفت است تا پیشرفت واقعی.
خروجی نهایی چیه؟
خروجی قابل توزیع (deploy) توسط SkillOpt یک فایل skill است. نه یک مدل جدید. نه یک سرویس inference جدید. نه یک chain طولانیتر از callهای اضافه. معمولا یک best_skill.md که میتونه از چندصد تا چند هزار توکن باشه. این خیلی مهمه، چون توی production، افزایش کیفیت ایجنت اغلب با یک trade-off همراهه؛ یعنی callهای بیشتر، تاخیر بیشتر، هزینه بیشتر، پیچیدگی بیشتر. اما توی SkillOpt، optimization در زمان training انجام میشه. در زمان inference، ایجنت فقط skill بهتر رو مصرف میکنه. و این یعنی deployment ساده میمونه.
از نظر مهندسی، این یک مزیت بزرگه. شما میتونین skill رو مثل code artifact ببینین:
- توی Git نگهش دارید.
- بتونید Review ش کنید.
- بهش Version تخصیص بدید.
- از نسخههای مختلف، Diff بگیرید.
- تونید در صورت نیاز، Roll back کنید.
- برای domainهای مختلف skill جداگانه داشته باشید.
- برای benchmark یا workflow خاص train کنید.
- بتونید روی validation splitها gate بگذارید.
- و در نهایت با همان دیسیپلینی که برای کدهاتون دارید مدیریتشون کنید.
چرا این موضوع برای تیمهای نرمافزاری مهمه؟
به نظرم ارزش SkillOpt فقط در خود ابزار نیست. ارزش اصلیاش در تغییریه که در نگاه ما ایجاد میکنه. از جنس همون تغییری که در فرایند تبدیل شدن از کدنویس به مهندس نرمافزار تجربه میکنیم. ما مدتهاست که AI رو از سمت model نگاه کردیم: کدوم مدل قویتره؟ کدوم مدل context بیشتری داره؟ کدوم مدل کدنویسی بهتری داره؟ کدوم مدل از ابزارها بهتر استفاده میکنه؟
این سوالها هنوز مهمن، اما کافی نیستن؛ وقتی وارد فضای agentic workflows میشیم، کیفیت کار، فقط تابعی از مدل مورد استفادهمون نیست. تابع procedure هم هست. یعنی اینکه ایجنت چجوری مسئله رو به بخشهای کوچیک میشکنه، چطوری شواهد جمع میکنه، چطورخطاها رو شناسایی و صحتسنجی میکنه، چجوری از context استفاده میکنه، چجوری ابزارها رو صدا میزنه، چجوری از تکرار اشتباهاتش جلوگیری میکنه، و چجوری خروجی نهایی رو قابل اعتماد میکنه. اینها دقیقا چیزهاییه که در skill document آورده میشن.
برای تیمهای فنی، این یعنی skillها باید از حالت فایلهای تزئینی و promptهای پراکنده خارج بشن. باید وارد یک lifecycle مهندسی بشن. همونطوری که کدهای بدون review خطرناکن، skillهای بدون review هم خطرناک هستن. همونطوری که کدهای بدون test قابل اعتماد نیستن، skillهای بدون benchmark هم قابل اعتماد نخواهند بود. همونطور که dependency بدون versioning دردسر درست میکنه، skill بدون versioning هم دردسر درست میکنه. همونطور که architecture decision بدون مستندات بعدا تیم رو زمینگیر میکنه، skill decision بدون منطق و استدلال هم بعدا ایجنت رو غیرقابل پیشبینی میکنه. SkillOpt این پیام رو خیلی شفاف اعلام میکنه: skill یک متن ساده نیست. skill بخشی از سیستم اجرایی ایجنته.
تفاوت SkillOpt با prompt tuning معمولی چیه؟
ممکنه با خودتون بگید: «خب این هم همون prompt optimization است دیگه.» تا حدی بله، اما تفاوت مهمی وجود داره. Prompt optimization معمولا روی بهتر کردن یک prompt برای یک task یا خانواده کوچکی از taskها تمرکز داره. اما SkillOpt عملا skill رو مثل یک artifact به صورت procedural میبینه. یعنی چیزی که قراره در طول زمان رشد کنه و بهتر شه، روی چندین درخواست ارزیابی بشه، failureهای قبلی رو جذب کنه، ruleهای درست رو نگه داره، و در نهایت به شکل یک asset قابل استفاده مجدد دربیاره.
از طرف دیگه، SkillOpt فقط پیشنهاد یک متن بهتر رو نمیده. بلکه یک optimization loop داره:
۱. اجرا
۲. ثبت trajectory
۳. تحلیل batchها
۴. پیشنهاد ویرایش
۵. اعمال محدودیت تغییر
۶. صحتسنجی
۷. قبول یا رد
۸. ذخیره ویرایشهای شکستخورده
۹. تکرار epochها
۱۰. خروجی گرفتن از best skill
این دیگه صرفا prompt نویسی نیست. این یک فرایند مهندسی شده روی یک training pipeline است، ولی روی متن. تفاوت اصلیتر هم اینه که SkillOpt یه validation gate داره که هیچکدوم از روشهای prompt optimization رایج ندارن، و این اط نظر ساختاری متفاوتش میکنه، نه فقط در دامنهی فعالیتش.
نسبت SkillOpt با Hermes Agent
نکته جالب اینه که SkillOpt تنها نمونهای نیست که به این نتیجه رسیده. Hermes Agent هم از مسیر دیگهای به اهمیت skillها رسیده. مثلا توی Hermes، عملا skillها فایلهای قابل لود شدن هستن که ایجنت موقع نیاز ازشون استفاده میکنه. ایده progressive disclosure هم برای اینه که همه چیز از ابتدا وارد context نشه و مصرف توکنها کنترل بشه. از طرفی Hermes مکانیزمهایی مثل skill management و Curator داره تا skillهای agent-created همینطوری روی هم تلنبار نشن، duplicate نشن، stale نشن، و در صورت نیاز patch یا archive بشن.
یعنی دو تا مسیر متفاوت داریم که پیامشون مشترکه:
دانش کاربردی ایجنت باید جایی بیرون از وزنهای مدل مدیریت بشه.
SkillOpt این رو بیشتر از زاویه optimization و benchmark-driven training میبینه. ولی Hermes این رو بیشتر از زاویه agent lifecycle، memory، skill management و self-improvement عملیاتی میبینه.
هر دو هم به یه نقطه میرسن: فایل skill، که یک دارایی سطح پایین و یا کماهمیت نیست. بلکه یکی از مهمترین اهرمها توی agent engineering است.
چرا اینها برای انترپرایزها مهمتر هم میشن؟
توی فضای شخصی، اگه یک skill بد بنویسیم، نهایتا یک یا چند خروجی بد میگیریم و نهایتا دوباره تلاش میکنیم. اما وقتی توی یک سازمان و خصوصا یک انترپرایز باشیم، یک skill بد میتونه باعث تصمیم اشتباه، کدهای بد، مستندات غلط، incident، leakage، یا حتی رفتارهای غیرقابل پیشبینی توی workflowهای مهم بشه.
تصور کنین یک تیم نرمافزاری از agent برای code review، migration، incident analysis، data quality check، یا تولید تست استفاده میکنه. اگه skill مربوط به این کارها ضعیف باشه، ایجنت ممکنه با مطمئنانه خروجی غلط بسازه!! اینجا دیگه نمیشه گفت «مدل خوبه، پس کافیه»، بلکه باید بپرسیم:
skill از کجا اومده؟
چه کسی اون رو نوشته؟
روی چه دادهای تست شده؟
چند بار تغییر کرده؟
آخرین تغییر چرا انجام شده؟
آیا روی validation بهتر شده یا فقط متنش قشنگتر شده؟
آیا نسخه production با نسخه آزمایشی فرق داره؟
آیا skill برای domain ما train شده یا عمومی است؟
آیا skillهای deprecated هنوز استفاده میشن؟
آیا skillها owner دارن؟
آیا مکانیزم rollback داریم؟
اینها سوالهای platform engineering هستن، نه prompt engineering. حتی به بیان بهتر، AI platform engineering.
skill optimization هم بدون governance خطرناکه!
البته نباید از اون طرف پشتبوم بیفتیم. اینکه skill قابل آموزشه به این معنا نیست که باید کورکورانه به self-editing اعتماد کنیم. اتفاقا هرچی skill مهمتر بشه، governance ش هم مهمتر میشه. اگه ایجنت اجازه داشته باشه skillها رو بدون مرز تغییر بده، چند خطر جدی داریم:
ممکنه skillهای مهم رو overfit کنه.
ممکنه ruleهای درست قبلی رو حذف کنه.
ممکنه skill رو بزرگ، مبهم و متناقض کنه.
ممکنه تغییراتش با policy سازمان ناسازگار باشه.
ممکنه تحت تاثیر prompt injection، skill رو آلوده کنه.
ممکنه skillهای مشترک بین تیمها رو خراب کنه.
ممکنه skillهای تولیدی و آزمایشی قاطی بشن.
بنابراین درس اصلی این نیست که «بگذاریم ایجنت خودش همه چیز رو بهتر کنه.» بلکه skill باید مثل کدها مدیریت بشه، اما با ابزارهای مخصوص خودش. یعنی review، validation، versioning، ownership، audit trail، benchmark، promotion flow، rollback، و policy enforcement.
SkillOpt یک قدم مهم در بخش validation-driven optimization است. ولی توی انترپرایز، این فقط یک بخش از پازله؛ بخش دیگرش، governance و lifecycle management روی اسکیلهاست.
مثال:
فرض کنید یه agent برای بررسی Pull Request داریم. skill اولیه میگه:
«کد رو review کن، bugها رو پیدا کن، و پیشنهاد بده.»
این skill خیلی عمومی و مبهمه. ایجنت ممکنه خوب کار کنه، اما خروجیاش قابل پیشبینی و با کیفیت قابل اتکا نیست.
بعد از چند rollout، میبینیم ایجنت توی PRهای backend چند خطای تکراری داره:
مثلا به migrationها دقت نمیکنه یا breaking change روی API contract رو تشخیص نمیده یا…یه مهندس باتجربه بعد از دیدن این failureها ممکنه skill رو بهتر کنه و بنویسه:
قبل از review، affected components رو تشخیص بده.
اگر API تغییر کرده، backward compatibility رو بررسی کن.
اگر database query اضافه شده، index و cardinality رو در نظر بگیر.
و…
ولی SkillOpt تلاش میکنه همین کار رو به طور سیستماتیک انجام بده. یعنی از trajectoryهای واقعی بفهمه چه ruleهایی کمه، تغییرات پیشنهادی اش رو اعلام کنه، و اونها را محدود کنه، و فقط اگر روی مرحله صحتسنجی بهتر شدن قبول کنه.
این برای من نقطه جذاب ماجراست. skill خوب شبیه یادداشتهای یک مهندس باتجربه بعد از چند ساعت کار عمیق با سیستمه. SkillOpt تلاش میکنه این تجربه رو از دل اجرای واقعی استخراج کنه.
جمعبندی
به نظرم SkillOpt یک نشونه مهم از بلوغ اکوسیستم agentهاست.
ما از مرحله «یک prompt خوب بنویس» عبور کردیم.
حتی از مرحله «چند tool به مدل بده» هم عبور کردیم.
حتی اسکیلسازی هم امر بدیهی و سادهایه.
حالا وارد مرحلهای شدهایم که باید رفتار ایجنت رو مهندسی کنیم.
توی این مرحله، skillها نقش جدیتری از قبل دارن. چون skill همون جاییه که دستورالعمل، تجربه، خطمشی، قراردادها و روش انجام کار در اون ذخیره میشه.
SkillOpt میگه این فایلهای Markdown رو ساده نبینین. اینها میتونن trainable parameter یک frozen agent باشن. نه به معنی ریاضی دقیق weight training، اما به معنی یک artifact قابل بهینهسازی، قابل ارزیابی و قابل توزیع.
پیام عملیاش این میشه که:
اگه از AI agent در توسعه نرمافزار، مستندسازی، code review، migration، QA، incident response یا workflowهای سازمانی استفاده میکنیم، باید skillها رو جدیتر بگیریم.
نه به عنوان promptهای پراکنده.
نه به عنوان فایلهای کمکی کنار پروژه.
بلکه به عنوان بخشی از سیستم مهندسی.
Skill خوب میتونه خروجی یک مدل معمولی رو بسیار بهتر کنه.
Skill بد میتونه خروجی یک مدل قوی رو خراب کنه.
و skill بدون validation، governance و lifecycle، دیر یا زود تبدیل میشه به همون بدهی فنی قدیمی، فقط این بار در لباس AI.
شاید تا چند وقت پیش مهمترین سوال این بود که «کدوم مدل رو استفاده کنیم؟» اما برای ایجنتهای جدی، سوال مهمتر این است:
«این مدل با چه skillهایی کار میکنه، این skillها چطور ساخته شدن، چطور بهتر شدن، و چه کسی کیفیتشون رو تضمین میکنه؟»
GitHub: https://github.com/microsoft/SkillOpt
Paper: https://arxiv.org/abs/2605.23904
Donwload