تصور کنید یک سیستم را که در آن مصاحبهگران هوش مصنوعی میتوانند در یک لحظه، نقش و تخصص خود را تغییر دهند. این کار از طریق بارگذاری متدولوژیهای تخصصی از طریق فایلهای قابل انتقال انجام میشود. این رویکرد معماری که Skillviewer نامیده شده است، دانش رویهای (Procedural Knowledge) را از مدل هسته جدا میکند. این ساختار به عاملها اجازه میدهد بدون تکیه بر پرامپتهای عظیم و ایستا، عملیات خود را مدیریت کنند.
بسیاری از عاملهای هوش مصنوعی بهدلیل نبودِ زمینهی کنترلشده و نسخهبندیشده برای کارهای پیچیده، در پایداری خروجی شکست میخورند. اگرچه تولید بازیابیافزا (RAG) — شبیه دانشآموزی که قبل از جواب دادن، اول کتاب درسی را باز میکند و از آن نقل میآورد — راهکاری رایج است، اما بیشتر بر حقایق «توصیفی» (Declarative Facts) تمرکز دارد؛ یعنی بر «چیستی» موضوع. در حالی که برای یک فرآیند مصاحبه طبیعی و ساختاریافته، به دانش «رویهای» یا همان «چگونگی» انجام کار نیاز است. توسعهدهنده Skillviewer، RAG را بهعنوان یک جایگزین در نظر گرفت، اما در نهایت برای بررسی دقت فنی و کارایی در این هدف خاص، اولویت را به ساخت یک نمونه اولیه بر پایه فایلهای SKILL داد.
به نقل از گزارشی در dev.to که در ۷ سپتامبر ۲۰۲۶ منتشر شد، انگیزه اصلی سازنده Skillviewer، بازسازی تجربه باکیفیت مصاحبهگر AI در پلتفرم Wellfound بود. راهکار نهایی، ایجاد فایل SKILL بود؛ سندی فنی و ساختاریافته که بهطور خاص برای این طراحی شده است تا عاملهای هوش مصنوعی بتوانند وظایف را بهصورت پیشبینیپذیر اجرا کنند.
سازوکار فایلهای SKILL
فایلهای SKILL بر دانش رویهای تمرکز دارند. دانش رویهای به عادتها، مهارتها و تکنیکهایی اشاره دارد که از طریق کاربرد عملی به دست میآیند، نه از طریق یادگیری کتابی یا تئوریک. برای مثال، همانطور که یک تیم جدید از مهندسان باید عملاً از سیستمعامل یک شرکت استفاده کنند تا یاد بگیرند چگونه در آن پیمایش کنند، یک عامل هوش مصنوعی نیز برای برگزاری یک مصاحبه حرفهای به راهنمای رویهای نیاز دارد. این موضوع کاملاً با دانش توصیفی متفاوت است؛ دانشی که مربوط به بخش «چگونه» یک وظیفه است و معمولاً از طریق سخنرانیهای کلاسی آموخته میشود.
این فایلها از طریق یک فرآیند سه مرحلهای از «افشای تدریجی» (Progressive Disclosure) عمل میکنند:
- کشف (Discovery): در لحظه شروع، سیستم فقط نام و توصیف فایل را میخواند. این کار باعث میشود سیستم بداند چه زمانی باید یک SKILL خاص را بارگذاری کند بدون اینکه حافظه را اشغال کند.
- فعالسازی (Activation): هنگامی که یک وظیفه با توصیف مهارت مطابقت داشت، عامل کل فایل SKILL.md را در پنجره متنی (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — بارگذاری میکند.
- اجرا (Execution): عامل دستورالعملها را دنبال کرده و در صورت نیاز، کدهای پیوستشده یا فایلهای مرجع ذکر شده در سند را اجرا میکند.
برای تضمین پیشبینیپذیری، فایلهای SKILL مرزهای پاکی را تعریف میکنند. آنها نهتنها توضیح میدهند که چه زمانی از یک مهارت استفاده شود، بلکه مشخص میکنند چه زمانی باید از آن اجتناب کرد. این فایلها شامل حفاظها (Guardrails) و محدودیتهای منفی هستند تا خطاهای ظریفی که معمولاً نیاز به بازبینی انسانی دارند، کاهش یابند. این رویکرد اجازه میدهد تا دانشهای تخصصی، مانند خط لولههای تحلیل داده یا قالببندی ارائهها، بهعنوان دستورالعملها و منابع قابل استفاده مجدد ثبت شوند.
جزئیات فنی قالب SKILL.md
برای درک بهتر کاربرد قالب SKILL.md، بررسی اهداف عملیاتی و مزایای آن نسبت به پرامپتنویسی استاندارد ضروری است:
- جریانهای کاری تکرارپذیر: این قالب وظایف پیچیده و چندمرحلهای را به رویههای ثابت و تکرارپذیر تبدیل میکند.
- تخصص دامنه: دانش تخصصی (مثلاً خط لولههای خاص تحلیل داده) را بهعنوان منابعی که میتوان دوباره از آنها استفاده کرد، ثبت میکند.
- گسترش منابع: برخلاف یک دستورالعمل استاندارد که فقط متنی است، SKILL اجازه میدهد دستورات در یک دایرکتوری یا بسته (Package) پخش شوند و به منابع خارجی ارجاع دهند.
- کنترل نسخه: چون اینها فایل هستند، میتوانند نسخهبندی شوند. این موضوع برای ارزیابی عملکرد عامل در طول زمان حیاتی است.
- پتانسیل بازارچه: این معماری اجازه میدهد یک بازارچه مبتنی بر SKILL ایجاد شود؛ جایی که کاربران بتوانند مهارتهای خاصی را برای تمرین برای یک نقش شغلی خاص در یک شرکت خاص دانلود کنند.
مهندسی لایه صوتی
ساخت یک رابط صوتی بلادرنگ چالشهای فنی قابل توجهی داشت. توسعهدهنده در ابتدا Google Live API و استریم دوطرفه ADK را بررسی کرد. ایده اولیه این بود که فایل SKILL در عامل بارگذاری شود و ارتباط از طریق ADK و لایه انتقال استریم که بهصورت پیشفرض ارائه میشد، برقرار گردد. با این حال، یک تضاد نسخهای ظاهر شد: محدودیتهای مسابقه (Hackathon) نیاز به استفاده از Gemini 3.5+ داشت، در حالی که Live API به Gemini 3.1 وابسته بود. برای جلوگیری از استفاده از «هکها» برای دور زدن این محدودیتها، توسعهدهنده به دنبال یک طراحی سیستم سختگیرانهتر و اصولیتر رفت.
برای حل این مشکل، پلتفرمهای ارتباطی بلادرنگ مانند LiveKit، Pipecat (Daily) و Voximplant مورد تحقیق قرار گرفتند. هدف یافتن ابزاری بود که بتواند مجموعهای از نیازهای Plug-and-play را برآورده کند:
- تشخیص فعالیت صوتی (VAD) و انتقال دادههای صوتی.
- تشخیص نوبت گفتگو و مدیریت قطع کردن صحبت توسط کاربر (Barge-in).
- توقف فوری تبدیل متن به گفتار (TTS) در لحظهای که کاربر صحبتش را شروع میکند.
- مدیریت وضعیت گفتگو (Conversation State Management).
- استریم دوطرفه برای هر دو بخش STT (تبدیل گفتار به متن) و TTS.
- ابزارهای سنجش تأخیر (Latency Instrumentation) و قابلیت یکپارچگی با هر مدل زبانی یا عامل دلخواه.
تکامل طراحی سیستم
طراحی سیستم در سه فاز متمایز تغییر کرد تا به پیادهسازی نهایی برسد:
طراحی اول: استریم دوطرفه ADK
این فاز بر استفاده از ADK و استریم لایه انتقال متمرکز بود. دستاورد اصلی این تلاش، شناسایی ویژگیهای ضروری برای یک تجربه صوتی باکیفیت بود: ترنسکریپتهای صوتی بلادرنگ و توانایی کاربر برای «قطع کردن» (Barge-in) هوش مصنوعی.
طراحی دوم: آداپتور سفارشی LiveKit
تحقیق در مورد رویکرد پیادهسازی Live API نشان داد که دو مسیر اصلی یکپارچگی وجود دارد: سرور-به-سرور یا کلاینت-به-سرور که هر دو بر اتصالات Websocket متکی هستند. توسعهدهنده تلاش کرد از LiveKit بهعنوان لایه ارتباطی استفاده کرده و آن را به ADK متصل کند. این کار نیازمند یک معماری پیچیده شامل یک «آداپتور سفارشی LiveKit ↔ ADK LLM» بود تا جریان داده بین میکروفون کاربر، لایه VAD/STT و مدل Gemini مدیریت شود.
طراحی سوم: پل Pipecat ADK
آداپتور سفارشی LiveKit در نهایت رد شد زیرا پیادهسازی آن از نظر فنی بسیار دشوار بود و به مقدار زیادی «کد چسب» (Glue Code) سفارشی نیاز داشت. توسعهدهنده به Pipecat روی آورد که یک خط لوله صوتی بلادرنگ آماده ارائه میداد. با بهرهگیری از پروژه متنباز pipecat-adk، توسعهدهنده دسترسی فوری به مدیریت قطع گفتگو، مدیریت زمینه (Context)، مدیریت وضعیت و چرخه حیات فراخوانی توابع (Function Call Lifecycles) پیدا کرد، بدون اینکه نیاز باشد یکپارچگی را از صفر بنویسد.
در معماری نهایی، جریان بهاین صورت است: کاندیدا از طریق مرورگر (WebRTC) صحبت میکند، Pipecat بخش STT را مدیریت میکند، پل ADK رویدادها را به عامل مصاحبهگر میفرستد و Gemini 3.5+ از طریق Vertex AI استدلال را انجام میدهد. پاسخ سپس از طریق TTS به کاربر بازمیگردد. این طراحی تضمین میکند که لایه هوش (ADK) و لایه ارتباطات (Pipecat) متمایز اما همگام باقی بمانند.
نویسندگی عاملمحور و ایمنی
از آنجا که نوشتن دستی فایلهای SKILL و فایلهای مرجع برای کاربر نهایی خستهکننده است، Skillviewer شامل یک «سازنده عاملمحور» (Agentic Builder) است. این قابلیت به کاربران اجازه میدهد معیارهای مورد نظر برای مصاحبه را به زبان ساده در یک صفحه پرامپت AI توصیف کنند. در پشت صحنه، سیستم بهطور خودکار فایل SKILL را میسازد. کاربران سپس میتوانند طرح را در یک بوم (Canvas) مشاهده کنند تا آن را تأیید، ویرایش یا تغییر دهند، که این امر رابط کاربری را بصری و آسان میکند.
برای جلوگیری از سوءاستفاده از پلتفرم، سیستم چندین حفاظ سختگیرانه را پیادهسازی کرده است:
- محدودیت دامنه مصاحبه: گفتگو را صرفاً به موضوعات مرتبط با مصاحبه محدود میکند.
- سلسلهمراتب دستورات: جلوگیری از تزریق پرامپت (Prompt Injection) یا تزریق دستورات برای دور زدن قوانین مصاحبه.
- محتوای حساس: جلوگیری از تولید سؤالات نامناسب یا تبعیضآمیز.
- حفاظت از اطلاعات داخلی: مسدود کردن مدل زبانی از افشای پرامپت سیستمی، روباریکهای ارزیابی، ابزارها یا پیکربندیها.
- ایمنی خروجی: جلوگیری از پاسخهای نامناسب یا ناایمن.
- مدیریت رفتارهای توهینآمیز کاندیدا: اطمینان از اینکه عامل در برابر تعاملات توهینآمیز یا نامناسب کاندیدا، واکنش متقابل مشابه نشان نمیدهد.
- مجوز ابزار/اکشن: جلوگیری از انجام اقدامات غیرمجاز در اپلیکیشن توسط مدل زبانی.
تحلیل: تغییر از پرامپت به مهارت
این تغییر از پرامپتنویسی یکپارچه (Monolithic Prompting) به فایلهای SKILL ماژولار، نشاندهنده حرکتی به سمت «مهندسی نرمافزار عاملمحور» است. با تبدیل تخصص به یک دارایی نسخهبندیشده، توسعهدهندگان میتوانند بازارچهای از مهارتها ایجاد کنند. در چنین بازارچهای، هر کسی میتواند با بارگذاری فایل SKILL مربوطه، برای یک نقش خاص در یک شرکت خاص تمرین کند.
برای یک توسعهدهنده عملی، این بدان معناست که عاملهای AI بیشتر شبیه به نرمافزارهای سنتی میشوند: ماژولار، قابل تست و قابل استفاده مجدد. مزایای این رویکرد عبارتند از:
- قابلیت استفاده مجدد: یک مهارت یکسان میتواند در چندین جلسه مصاحبه مختلف استفاده شود.
- افشای تدریجی: در صورت ادغام یک کتابخانه مهارت در آینده، ابتدا میتوان متادیتاها را نمایش داد.
- یکپارچگی منابع: دستورالعملها دیگر فقط متن نیستند، بلکه میتوانند در یک دایرکتوری یا بسته پخش شوند.
- نسخهبندی: برای ارزیابی عملکرد عامل در طول زمان ضروری است.
این روش جنبه «شانسی» پرامپتنویسی را کاهش داده و آن را با یک سیستم سختگیرانه از راهنماییهای عملیاتی جایگزین میکند. اگرچه پروژه در زمان گزارش ۵۰٪ کامل شده بود، اما هدف اصلی یعنی ایجاد یک لایه ارتباطی دوطرفه و لایه هوش با موفقیت محقق شد.
برای مشاهده ارتباط دوطرفه و بارگذاری مهارتها در عمل، میتوانید ویدیو کامل ارائه و دمو را در Devpost تماشا کنید.
گفتگو