فرض کنید یک Skill برای بررسی PRها ساختید و بعد از چند بار استفاده، به نتیجه خوبی رسیدید.

فایلش رو برای بقیه اعضای تیم می‌فرستید. یکی کپی می‌کنه داخل .agents/skills`، یکی می‌ذاره داخل .claude/skills` و یکی هم چند خطش رو تغییر می‌ده تا روی سیستم خودش بهتر کار کنه.

دو هفته بعد چند نسخه مختلف از همون Skill داریم و دیگه دقیقاً معلوم نیست نسخه اصلی کدومه.

اینجا Skill دیگه فقط یک prompt شخصی نیست؛ تبدیل شده به یک dependency تیمی.

یعنی دیگه فقط یک یا چند فایل Markdown معمولی نیست؛ بخشی از پروسه توسعه نرم‌افزاره و باید دقیقاً مثل کد باهاش برخورد کنیم.

برای اشتراک‌گذاری تیمی هم بهتره یک repository مشخص، review و نسخه ثابت داشته باشه. نه اینکه هر کس یک کپی متفاوت روی سیستم خودش نگه داره و همه هم فکر کنن آخرین نسخه دست اون‌هاست.

باید دقت کنیم که ما معمولاً به SKILL.md مثل یک فایل Markdown نگاه می‌کنیم، ولی Agent محتوای اون رو به‌عنوان دستورالعمل قابل اعتماد وارد context خودش می‌کنه.

اگر Skill مخرب یا آلوده شده باشه، می‌تونه Agent رو هدایت کنه که فایل بخونه، اطلاعات رو به یک سرویس خارجی بفرسته یا از toolهایی استفاده کنه که قبلاً بهش اجازه داده‌ایم.

اگر Skill همراه خودش script داشته باشه، خطر دیگه فقط prompt injection نیست؛ ممکنه به اجرای کد و یک حمله واقعی در زنجیره تأمین نرم‌افزار تبدیل بشه.

حتی لازم نیست Skill اصلی مخرب باشه. ممکنه dependency که توی Skill بهش اشاره شده آلوده بشه یا یک آپدیت بدون review رفتار Skill رو عوض کنه.

آآآما ماجرا وقتی ترسناک‌تر میشه که می‌ریم سراغ Skillهای پابلیک. عمده محتوای Skillها متن‌های Markdown هستن که بشر (انواع گونه‌های دولوپر) همیشه از نوشتن و خوندنشون فرار می‌کرده.

ولی Agent خط‌به‌خط و کلمه‌به‌کلمه می‌خونه و بهش عمل می‌کنه.

دقیقاً مثل پکیج‌های نرم‌افزاری که توی کد استفاده می‌کنیم، این‌ها هم ممکنه هک بشن و متن یا کد مخرب داخلشون قرار بگیره.

اینجاست که SBOM هم می‌تونه کمک کنه بفهمیم چه Skill، script و dependencyهایی وارد سیستم شدن. البته SBOM فقط فهرست اجزاست و به‌تنهایی تضمین نمی‌کنه که اون‌ها امن هستن.

خلاصه اوضاعی شده که ایجنت دیگه صاحابش رو هم نمی‌شناسه 😁

وقتی می‌گیم باید از LLM استفاده کنیم، منظور فقط این نیست که ازش بخوایم فایل‌های YAML کوبرنتیز رو برامون بنویسه یا لاگ یک پاد مشکل‌دار رو براش کپی کنیم و بپرسیم ایراد کجاست.

این کارها مفیدن، اما هنوز استفاده موردی از LLM در یک محیط چت هستن. ما اطلاعات رو جمع می‌کنیم، context رو در اختیار مدل می‌ذاریم و بعد خروجی رو به سیستم برمی‌گردونیم. یعنی تمام ارتباط بین LLM و سیستم همچنان به‌صورت دستی و از طریق ما انجام می‌شه.

یک نمونه خوب از چیزی که باید به سمتش حرکت کنیم، JARVIS در فیلم Iron Man هست.

بعد از اولین آزمایش پرواز، تونی مشکلات لباس در ارتفاع بالا رو توضیح می‌ده و پیشنهاد می‌کنه از آلیاژ طلا و تیتانیوم استفاده بشه. JARVIS طرح جدید رو render می‌کنه، اما نتیجه کاملاً طلاییه. تونی ازش می‌خواد کمی قرمز هم اضافه کنه. نسخه جدید نمایش داده می‌شه و بعد از تأیید تونی، آزمایشگاه ساخت و مونتاژ لباس رو شروع می‌کنه؛ در حالی که خود تونی از اونجا می‌ره. 🤖

نکته مهم این صحنه رنگ لباس نیست. JARVIS فقط یک chatbot نیست که درباره طراحی لباس پیشنهاد بده. به نتایج آزمایش، مدل طراحی، نرم‌افزار render و تجهیزات ساخت دسترسی داره. تونی هدف و اصلاحات رو مشخص می‌کنه، نتیجه رو می‌بینه و بعد اجرای کار رو به سیستمی می‌سپاره که می‌تونه بدون حضور دائم اون ادامه بده.

دیدگاه ما به استفاده از LLM هم باید به همین سمت حرکت کنه: از ابزاری که فقط به سؤال‌های موردی جواب می‌ده، به بخشی از سیستم که context و ابزار لازم برای انجام یک workflow واقعی رو در اختیار داره.

مثلاً می‌تونیم سرویسی داخل یا کنار کلاستر داشته باشیم که به metrics، logs، traces، events و تاریخچه deploymentها دسترسی داشته باشه. وقتی مشکلی پیش میاد، این اطلاعات رو کنار هم بذاره، تغییرات اخیر رو بررسی کنه، علت احتمالی رو پیدا کنه و نتیجه رو به ما گزارش بده.

اگر دسترسی محدود و مشخصی هم بهش داده باشیم، می‌تونه بعضی اقدامات از پیش تعریف‌شده مثل restart کردن یک سرویس، rollback کردن یک deployment یا تغییر تعداد replicaها رو انجام بده. البته چنین اقدام‌هایی باید قابل ثبت، قابل بررسی و در صورت نیاز قابل برگشت باشن.

اینجا دیگه LLM فقط ابزاری برای جواب دادن به یک سؤال نیست؛ بخشی از حلقه عملیاتی سیستمه. وضعیت رو می‌بینه، اطلاعات رو از چند منبع کنار هم می‌ذاره و در محدوده‌ای که ما تعیین کردیم واکنش نشون می‌ده.

پروژه‌هایی مثل openchoreo.dev نمونه‌ای از همین مسیر هستن. OpenChoreo یک پلتفرم متن‌باز برای کوبرنتیزه که اطلاعاتی مثل لاگ‌ها، متریک‌ها و وضعیت سرویس‌ها رو در اختیار agentها می‌ذاره تا بتونن علت مشکلات رو بررسی کنن، راه‌حل پیشنهاد بدن و در محدوده دسترسی مشخص، بعضی مشکلات رو برطرف کنن.

هدفم از اشاره به OpenChoreo این نیست که همه باید همین ابزار رو نصب کنن. نکته اینه که LLMها رو فقط در حد coding agent یا یک پنجره چت نبینیم. ارزش اصلی اون‌ها زمانی بیشتر می‌شه که به context واقعی، ابزارهای مشخص و workflowهای قابل‌کنترل متصل بشن و به جزئی مهندسی‌شده از خود سیستم تبدیل بشن.

داستان‌ها و فیلم‌ها زیاد در مورد هوش مصنوعی که از کنترل خارج شده دیدیم و خوندیم. از ادیسه ۲۰۰۱ یا ترمینتور و یا حتی ماتریکس. اما به نظر من یکی از جالبترین و ترسناکترین اینها Ex Machina بوده.

توی ماجرای اخیری که بین openAI و HuggingFace افتاد، به نظرم Ex Machina خیلی نزدیکتره به همشون، اگر فیلم رو ندید تقریبا براتون اسپول شده تا الان ولی نمیخوام بیشتر از این اسپول کنم.

در مورد این ماجرا بروس اشنایر اخیرا از چیزی صحبت می‌کنه به اسم «ضریب جن»، نسرین (همسرم) هم در وبسایتش در این مورد پستی نوشته با عنوان «ضریب غول چراغ جادو» 🙂


پست بروس اشنایر
پست نسرین
فیلم
بعد از دیدن فیلم هم این ویدئو رو پیشنهاد میکنم ببنید

قبلا درباره nono و این موضوع نوشتم که محدودیت دسترسی AI agent باید بیرون از prompt و در سطح سیستم‌عامل اعمال بشه.

اما ساختن profile مناسب برای nono، مخصوصا برای کسی که تازه می‌خواد ازش استفاده کنه، می‌تونه کمی گیج‌کننده باشه. باید مشخص کنید agent به کدوم فایل‌ها دسترسی داشته باشه، کجا اجازه نوشتن داشته باشه، به چه سرویس‌هایی در اینترنت وصل بشه و با چه تنظیماتی اجرا بشه.

برای ساده‌تر کردن این کار nono-wizard رو ساختم. ابزار coding agent، مسیر پروژه و سطح دسترسی موردنظرتون رو می‌پرسه و در انتها profile و command آماده اجرای nono رو تولید می‌کنه.

کل ابزار یک صفحه static هست و بدون نصب یا build داخل مرورگر اجرا می‌شه:

saderi.github.io/nono-wizard