یک فایل دستورالعمل در جای اشتباه می‌تواند تفاوت بین عاملی باشد که یک قابلیت را با موفقیت عرضه می‌کند و عاملی که در حلقه‌ای بی‌پایان از خطاهای فراخوانی ابزار گیر می‌کند. این واقعیت، هسته اصلی یک راهنمای فنی از وب‌سایت dev.to در ۱ اکتبر ۲۰۲۶ بود که با جزئیات توضیح داد چگونه فایل‌های SKILL.md به عنوان پلی حیاتی بین محصولات توسعه‌دهنده و عامل‌های هوش مصنوعی عمل می‌کنند تا رفتار فعال مدل را فراتر از مستندات ایستا شکل دهند.
تصور کنید محصول شما شهری پیچیده است؛ مستندات استاندارد شبیه نقشه‌ای از کل شهر است، اما یک فایل مهارت (Skill file) مانند مسیریابی GPS است که عامل را دقیقاً به یک مقصد خاص می‌رساند. این رویکرد باعث می‌شود عامل (Agent) — شبیه دستیاری که به جای خواندن کل کتابخانه، فقط برگه تقلب مربوط به آن لحظه را می‌بیند — مجبور نباشد سرنخ‌های پراکنده را از میان یک کدبیس عظیم جمع کند. در عوض، مجموعه‌ای هدفمند از اسکریپت‌ها و منابع در اختیار او قرار می‌گیرد که تنها در زمان مرتبط بودن فعال می‌شوند. مهارت‌های عامل، لایه جدیدی بین عامل‌های کدنویس و محصولات توسعه‌دهنده ایجاد می‌کنند و به شکل‌دهی نحوه کشف، پیمایش و استفاده عامل از محصول شما کمک می‌کنند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل دقیق دسترسی به اطلاعات، کلید بهره‌وری در سیستم‌های عامل‌محور است. این تلاش برای ساختارمند کردن دستورالعمل‌ها در ادامه رویکردهایی است که استاندارد AGENTS.md برای یکسان‌سازی دستورالعمل‌های برنامه‌نویسی میان ابزارهای مختلف AI معرفی کرد.
مکانیزم کشف (Discovery Mechanism)
به نقل از گزارش dev.to، اولین چالش، قابلیت کشف است. فایل SKILL.md به‌طور خودکار پیدا نمی‌شود؛ مکان قرارگیری آن باید دقیقاً با محیط اجرای (Runtime) عاملی که استفاده می‌شود مطابقت داشته باشد. اگر این فایل صرفاً در جایی از مخزن (Repository) قرار گرفته باشد، به‌طور خودکار قابل کشف نخواهد بود.
- Claude Code مهارت‌های پروژه را در مسیر
.claude/skills/skill-name/SKILL.mdجست‌وجو می‌کند. - OpenAI Codex مهارت‌های مخزن را در مسیر
.agents/skillsیا از طریق پلاگین‌های بسته‌بندی شده شناسایی می‌کند.
هنگام تست یک مهارت، اولین گام این است که تأیید کنید فایل در مکانی نصب شده است که عامل برای کشف آن طراحی شده است. پس از کشف، عامل‌های OpenAI و Anthropic از مکانیزم «افشای تدریجی» (Progressive Disclosure) استفاده می‌کنند. آن‌ها کل مجموعه دستورالعمل‌ها را بلافاصله در پنجره زمینه (Context Window) — که مثل میز کاری است و فقط جای چند ورق کاغذ دارد — بارگذاری نمی‌کنند. در عوض، ابتدا متادیتای سبک، به‌ویژه «نام» و «شرح» را می‌خوانند تا تصمیم بگیرند آیا این مهارت برای وظیفه فعلی مرتبط است یا خیر و سپس محتوای کامل را بارگذاری می‌کنند. این موضوع باعث می‌شود شرح مهارت بسیار حیاتی باشد؛ هر دو ارائه‌دهنده توصیه می‌کنند از این متادیتا برای توضیح دقیق اینکه مهارت چه کاری انجام می‌دهد و عامل در چه زمانی باید آن را فعال کند، استفاده شود. برای حل چالش‌های گسترده‌تر در شناسایی ابزارها، راهکارهایی مانند ثبت خودکار ابزارهای MCP توسط GitTrends AI برای رفع بحران جست‌وجوی عامل‌ها ارائه شده است.
تست سطوح فعال‌سازی
برای تأیید اینکه یک مهارت واقعاً کار می‌کند، توسعه‌دهندگان باید فعال‌سازی را در سه سطح از جزئیات تست کنند. این کار تضمین می‌کند که عامل می‌تواند نیاز به مهارت را بدون اینکه صراحتاً به او گفته شود، استنباط کند؛ این دقیقاً مشابه نحوه تعامل واقعی توسعه‌دهندگان با عامل‌هاست که به جای ابزارهای خاص، اهداف خود را بیان می‌کنند.
۱. نام‌گذاری صریح (Explicit Naming): تست اینکه آیا عامل به یک دستور مستقیم پاسخ می‌دهد. مثال: «از مهارت Quantiles برای اجرای یک ارزیابی استفاده کن».
۲. شرح وظیفه (Task Description): تست اینکه آیا عامل می‌تواند مهارت را از روی یک وظیفه خاص شناسایی کند. مثال: «احراز هویت این برنامه را پیکربندی کن».
۳. استنتاج هدف (Goal Inference): تست اینکه آیا عامل می‌تواند مهارت را به یک هدف سطح بالای توسعه‌دهنده متصل کند. مثال: «این سرویس را متصل کن تا بتوانم ارزیابی عامل‌ها را شروع کنم».
شرکت OpenAI توصیه می‌کند که تمام این طیف، از درخواست‌های صریح و زمینه‌ای گرفته تا مواردی که مهارت اصلاً نباید فعال شود، مورد آزمایش قرار گیرد.
اندازه‌گیری اثرگذاری
افزودن یک مهارت همیشه نتایج را بهبود نمی‌بخشد؛ شواهد اولیه نشان می‌دهد که مهارت‌ها می‌توانند رفتار عامل را تغییر دهند، اما لزوماً همیشه به سمت بهتر شدن نیست. برای جداسازی اثر مهارت، توسعه‌دهندگان باید یک وظیفه یکسان را «با مهارت» و «بدون مهارت» مقایسه کنند، در حالی که مدل، مخزن، مستندات، ابزارها و محیط را ثابت نگه دارند. این کار باعث می‌شود مهارت به عنوان تنها متغیر آزمایشی باقی بماند. این متدولوژی در راستای تبدیل پرامپت‌های عامل‌های هوش مصنوعی به کدهای نسخه‌مند در مخازن skills است تا تغییرات به صورت سیستماتیک ردیابی شوند.
موفقیت از طریق ردپای اجرا (Execution Trace) سنجیده می‌شود. توسعه‌دهندگان باید به دنبال سیگنال‌های خاصی باشند تا تعیین کنند آیا جریان کاری کارآمدتر یا قابل‌اعتمادتر شده است یا خیر:
- موفقیت در وظیفه: آیا عامل به نتیجه تأیید شده رسید و آیا این موفقیت با وجود مهارت، سازگارتر و پایدارتر بود؟
- فراخوانی‌های ابزار (Tool Calls): آیا مهارت حجم کاری که عامل برای تکمیل وظیفه نیاز داشت را تغییر داد؟
- خطاهای ابزار: آیا مهارت به عامل کمک کرد تا از دستورات، آرگومان‌ها، APIها یا عملیات‌های نادرست اجتناب کند؟
- فراخوانی‌های تکراری: آیا مهارت باعث کاهش تلاش‌های مجدد غیرضروری یا حلقه‌ها شد، یا به عامل کمک کرد تا سریع‌تر بازیابی شود؟
- تأخیر (Latency): آیا مهارت مسیر رسیدن به هدف را کوتاه کرد یا سربار اضافی ایجاد نمود؟
- مصرف توکن: آیا مهارت باعث کاهش جست‌وجو و استدلال شد یا زمینه و پردازش بیشتری افزود؟
- مداخله انسانی: آیا عامل برای اتمام کار به شفاف‌سازی، تغییر مسیر یا کمک کمتری نیاز داشت؟
- فعال‌سازی مهارت: آیا عامل مهارت را بارگذاری کرد و در چه نقطه‌ای از وظیفه، این مهارت مفید واقع شد؟
کجا مهارت‌ها کمک می‌کنند و کجا آسیب می‌زنند
راهنمایی‌ها زمانی بیشترین اثر را دارند که یک مسیر ترجیحی یا پیش‌نیازهای غیربدیهی وجود داشته باشد؛ مواردی مانند توالی‌های خاص احراز هویت، تنظیمات اولیه، وضعیت (State)، وابستگی‌ها یا مجوزها. مهارت‌ها به‌ویژه برای تصمیمات خاص محصول مفید هستند، جایی که عامل باید بداند کدام API، دستور، پیکربندی یا جریان کاری برای یک موقعیت خاص مناسب است. همچنین زمانی که محدودیت‌های مهمی وجود دارد، مهارت‌ها بسیار مؤثرند؛ یعنی جایی که برخی رویکردها منطقی به نظر می‌رسند اما در واقع پشتیبانی نمی‌شوند، ناامن هستند، هزینه بالایی دارند یا مخرب‌اند.
علاوه بر این، مهارت‌ها زمانی کمک می‌کنند که موفقیت بدیهی نباشد (مثلاً یک پاسخ موفق API لزوماً به معنای تکمیل وظیفه نیست) یا زمانی که محصول دارای قراردادهای غیرمعمولی است که با آنچه یک عامل از محصولات مشابه استنباط می‌کند، تفاوت دارد. مقدار کمی راهنمایی که یک قانون یا اصل تصمیم‌گیری را ارائه دهد، می‌تواند در بسیاری از تغییرات یک وظیفه تعمیم یابد.
در مقابل، مهارت‌ها می‌توانند به چندین روش به عملکرد ضربه بزنند:
- هم‌پوشانی و تکرار (Redundancy): زمانی آسیب می‌زنند که اطلاعاتی را تکرار کنند که به‌راحتی قابل کشف است، مانند راهنمای CLI، طرحواره‌های (Schemas) API یا مستندات ساده.
- تجویز بیش از حد (Over-prescription): وقتی به جای ارائه یک اصل کلی، دقیقاً به عامل می‌گویید چگونه مشکل را حل کند، توانایی عامل در انطباق با وضعیت محیط کاهش می‌یابد.
- سخت‌گیرانه بودن (Rigidity): دستورالعمل‌ها می‌توانند انعطاف‌پذیری را کاهش دهند و باعث شوند عامل حتی زمانی که خطاها نشان می‌دهند باید مسیر را تغییر دهد، همچنان از مسیر مستند شده پیروی کند.
- ساختار ضعیف: مهارت‌هایی که «شبیه آموزش» (Tutorial-shaped) هستند، تنها یک مسیر واحد را کدگذاری می‌کنند که به موقعیت‌های ناآشنا منتقل نمی‌شود. همچنین مهارت‌های بزرگ و پر سر و صدا که در آن‌ها راهنمایی‌های مرتبط با مثال‌های بی‌ربط یا موارد خاص (Edge cases) رقابت می‌کنند، عملکرد را تخریب می‌کنند.
- کهنگی (Staleness): اگر دستورات، پارامترها یا مقادیر پیش‌فرض به‌طور مکرر تغییر کنند، راهنمایی‌ها قدیمی شده و با محصول فعلی در تضاد قرار می‌گیرند.
چرخه تکامل
به دلیل تغییر مداوم مدل‌های هوش مصنوعی و APIهای محصول، فایل‌های SKILL.md را نمی‌توان یک‌بار نوشت و رها کرد. راهنمایی‌هایی که امروز کمک می‌کنند، ممکن است با بهبود مدل‌ها غیرضروری شوند، در حالی که رفتارهای جدید عامل ممکن است مشکلاتی را آشکار کند که هرگز قبلاً دیده نشده‌اند. توسعه‌دهندگان باید مجموعه‌ای پایدار از وظایف ارزیابی را برای مهم‌ترین جریان‌های کاری خود نگه دارند تا از آن‌ها به عنوان تست‌های رگرسیون در هر بار به‌روزرسانی محصول، مستندات یا فایل مهارت استفاده کنند.
هرگاه شکست جدیدی در عملکرد عامل رخ دهد، باید آن را به یک وظیفه ارزیابی جدید تبدیل کرد. این کار یک حلقه بازخورد ایجاد می‌کند که در آن توسعه‌دهنده تصمیم می‌گیرد آیا اصلاحیه باید در فایل SKILL.md، مستندات کلی، پیام‌های خطای API یا در خودِ محصول اعمال شود. هدف این نیست که مهارت همه چیز را بهبود بخشد، بلکه هدف یافتن نقطه‌ای است که در آن مقدار کمی راهنمایی اضافی، تفاوتی معنادار ایجاد کند و در مقابل، تشخیص این است که کجا عامل بدون کمک و با تکیه بر استدلال خودش بهتر عمل می‌کند.
این تغییر در تجربه توسعه‌دهنده به این معناست که اکنون ساخت یک محصول مستلزم ساخت برای دو نوع کاربر است: برنامه‌نویس انسان و کدنویس عامل‌محور. هدف، یافتن نقطه دقیقی است که در آن مقدار کمی راهنمایی، تفاوت معناداری ایجاد کند بدون اینکه توانایی‌های استدلالی عامل را سلب کند.
گام بعدی شما
- ساختار پوشه‌بندی
.claude/skillsیا.agents/skillsرا در پروژه‌های خود پیاده کنید. - برای هر مهارت، یک شرح (Description) دقیق بنویسید تا مکانیزم افشای تدریجی مدل به‌درستی عمل کند.
- یک لیست از «شکست‌های رایج عامل» تهیه کنید و آن‌ها را به فایل‌های SKILL.md تبدیل کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو