ابزارهایی مثل OpenClaw، Hermes یا Manus گاهی میان روی آنتن همه یوتیبرها و گاهی میرن. یکی میگه وای، خیلی خطر داره. یکی میگه همه زندگی من رو به باد داد. یکی هم ویدئو میذاره و میگه من دیگه همهچیز رو واگذار کردم به یکی از اینا و خودم نشستم تخمه میشکنم و فیلم نگاه میکنم.
اما اگر این جنگولکبازیهای یوتیوبرها رو بذاریم کنار و بخواهیم یکی رو انتخاب کنیم، باید قبل یه سؤال مهم از خودمون بپرسیم:
آیا ما واقعاً به یک autonomous agent نیاز داریم؟
اگر استفاده ما از AI بیشتر شامل سؤال پرسیدن، نوشتن متن، تولید کد یا انجام چند کار موردیه، برای این کارها همان هارنسهای فعلی کافی هستند. در واقع این autonomous agent زمانی معنی پیدا میکنه که برای کارهایی استفاده بشه که:
🔁 مرتب تکرار بشه،
🧩 چند مرحله مشخص داشته باشه،
🛠 بین چند ابزار یا سرویس محدود جابهجا بشه،
⏳ و لازم باشه بدون حضور دائم ما ادامه پیدا کنه.
مثلاً هر روز اطلاعاتی را از چند منبع جمع کند، تغییرات را بررسی کند، نتیجه را دستهبندی کند و در نهایت یک گزارش قابل استفاده تحویل بده.
اینجا ارزش Agent فقط در این نیست که «هوشمند» است.
ارزش اصلی اینه که بخشی از هماهنگی، پیگیری و رفت و برگشت بین مراحل مختلف رو از دوش ما برمیداره.
⚠️ اما اشتباه رایج اینه که اول یک ابزار نصب کنیم و بعد دنبال کاری بگردیم که بهش بسپاریم. انگار یکی رو استخدام کنیم و بدونیم که خیلی کارا بلده، ولی فعلاً نه میتونیم کارمون رو کامل و دقیق بهش توضیح بدیم و مهمتر اینکه هنوز بهش اعتماد نداریم که پسورد و دسترسی به همهچیز رو بهش بدیم.
به نظرم مسیر درست دقیقاً برعکسه.
اول باید ببینیم چه کاری رو مرتب انجام میدیم که تکراری، وقتگیر و نسبتاً قابل پیشبینیه.
بعد باید بتونیم چهار سؤال رو دربارهاش جواب بدیم:
هدف نهایی این کار دقیقاً چیه؟
برای انجامش چه مجموعه ابزار و دسترسیهایی لازمه؟
از کجا میفهمیم درست انجام شده؟
اگر اشتباه انجام شد، چقدر راحت میتونیم برگردیم و اصلاحش کنیم؟
اگر جواب این سؤالها روشن نیست، احتمالاً هنوز اون کار گزینه خوبی برای خودکار شدن نیست؛ چه با اسکریپت، چه با autonomous agent.
🧪 حتی بعد از انتخاب کار هم بهتره از روز اول سراغ اجرای اون با autonomous agent نریم.
اول همون workflow رو چند بار با هارنسهای فعلی و مدلهای مختلف و با نظارت خودمون اجرا کنیم؛ خروجیها رو ببینیم، جاهایی که گیر میکنه پیدا کنیم و بفهمیم آیا نتیجه واقعاً قابل پیشبینیه یا نه.
وقتی دیدیم Agent در یک محدوده مشخص بارها نتیجه قابل قبول میده، تازه میشه بخشی از کار رو به trigger، schedule یا اجرای مستقل سپرد.
اگر بعد از خودکار کردن یک workflow مجبور باشیم دائماً دنبالش راه بیفتیم، خطاهاش رو اصلاح کنیم و ببینیم این بار چه تصمیم عجیبی گرفته، چیزی را خودکار نکردیم؛ فقط شکل کار رو عوض کردیم.
برای همین بهتره از این سؤال شروع نکنیم:
«کدوم Autonomous Agent رو نصب کنم؟»
سؤال بهتر اینه:
«کدوم بخش از کار من بهاندازه کافی تکراری، شفاف و قابلاندازهگیریه که بشه واگذارش کرد؟»
اگر جوابی برای این سؤال نداریم، احتمالاً هنوز به یک Autonomous Agent نیاز نداریم.
اما اگر این جنگولکبازیهای یوتیوبرها رو بذاریم کنار و بخواهیم یکی رو انتخاب کنیم، باید قبل یه سؤال مهم از خودمون بپرسیم:
آیا ما واقعاً به یک autonomous agent نیاز داریم؟
اگر استفاده ما از AI بیشتر شامل سؤال پرسیدن، نوشتن متن، تولید کد یا انجام چند کار موردیه، برای این کارها همان هارنسهای فعلی کافی هستند. در واقع این autonomous agent زمانی معنی پیدا میکنه که برای کارهایی استفاده بشه که:
🔁 مرتب تکرار بشه،
🧩 چند مرحله مشخص داشته باشه،
🛠 بین چند ابزار یا سرویس محدود جابهجا بشه،
⏳ و لازم باشه بدون حضور دائم ما ادامه پیدا کنه.
مثلاً هر روز اطلاعاتی را از چند منبع جمع کند، تغییرات را بررسی کند، نتیجه را دستهبندی کند و در نهایت یک گزارش قابل استفاده تحویل بده.
اینجا ارزش Agent فقط در این نیست که «هوشمند» است.
ارزش اصلی اینه که بخشی از هماهنگی، پیگیری و رفت و برگشت بین مراحل مختلف رو از دوش ما برمیداره.
⚠️ اما اشتباه رایج اینه که اول یک ابزار نصب کنیم و بعد دنبال کاری بگردیم که بهش بسپاریم. انگار یکی رو استخدام کنیم و بدونیم که خیلی کارا بلده، ولی فعلاً نه میتونیم کارمون رو کامل و دقیق بهش توضیح بدیم و مهمتر اینکه هنوز بهش اعتماد نداریم که پسورد و دسترسی به همهچیز رو بهش بدیم.
به نظرم مسیر درست دقیقاً برعکسه.
اول باید ببینیم چه کاری رو مرتب انجام میدیم که تکراری، وقتگیر و نسبتاً قابل پیشبینیه.
بعد باید بتونیم چهار سؤال رو دربارهاش جواب بدیم:
هدف نهایی این کار دقیقاً چیه؟
برای انجامش چه مجموعه ابزار و دسترسیهایی لازمه؟
از کجا میفهمیم درست انجام شده؟
اگر اشتباه انجام شد، چقدر راحت میتونیم برگردیم و اصلاحش کنیم؟
اگر جواب این سؤالها روشن نیست، احتمالاً هنوز اون کار گزینه خوبی برای خودکار شدن نیست؛ چه با اسکریپت، چه با autonomous agent.
🧪 حتی بعد از انتخاب کار هم بهتره از روز اول سراغ اجرای اون با autonomous agent نریم.
اول همون workflow رو چند بار با هارنسهای فعلی و مدلهای مختلف و با نظارت خودمون اجرا کنیم؛ خروجیها رو ببینیم، جاهایی که گیر میکنه پیدا کنیم و بفهمیم آیا نتیجه واقعاً قابل پیشبینیه یا نه.
وقتی دیدیم Agent در یک محدوده مشخص بارها نتیجه قابل قبول میده، تازه میشه بخشی از کار رو به trigger، schedule یا اجرای مستقل سپرد.
اگر بعد از خودکار کردن یک workflow مجبور باشیم دائماً دنبالش راه بیفتیم، خطاهاش رو اصلاح کنیم و ببینیم این بار چه تصمیم عجیبی گرفته، چیزی را خودکار نکردیم؛ فقط شکل کار رو عوض کردیم.
برای همین بهتره از این سؤال شروع نکنیم:
«کدوم Autonomous Agent رو نصب کنم؟»
سؤال بهتر اینه:
«کدوم بخش از کار من بهاندازه کافی تکراری، شفاف و قابلاندازهگیریه که بشه واگذارش کرد؟»
اگر جوابی برای این سؤال نداریم، احتمالاً هنوز به یک Autonomous Agent نیاز نداریم.
👍8❤5💯2🥰1
اوایل جام جهانی بود که یه پست در Medium دیدم که نویسندهاش با استفاده از Claude برنده جام جهانی ۲۰۲۶ رو پیشبینی کرده بود. البته کلمه «پیشبینی» اینجا خیلی درست نیست و بهتره بگم احتمال برنده شدن تیمها رو محاسبه کرده بود.
البته نویسنده فقط از Claude نپرسیده «چه تیمی قهرمان میشه؟» و Claude هم از روی حس یا اطلاعات داخل مدل اسم اسپانیا رو بیرون نکشیده.
کلاد به نویسنده کمک کرده اطلاعات بیش از ۴۹ هزار مسابقه ملی رو جمعآوری و پردازش کنه، برای تیمها سیستم امتیازدهی Elo بسازه، احتمال گلها رو با یک مدل آماری محاسبه کنه و ادامه تورنمنت رو ۵۰ هزار بار شبیهسازی کنه.
نتیجه این شبیهسازیها این بوده که اسپانیا بیشتر از بقیه تیمها قهرمان شده؛ تقریباً یک بار از هر ۳.۴ تورنمنت.
اما بخش مهم ماجرا برای من اسپانیا یا حتی فوتبال نیست.
تا چند سال پیش انجام چنین پروژهای به ترکیبی از برنامهنویسی، آمار، جمعآوری و تمیز کردن داده و احتمالاً چند روز یا چند هفته زمان نیاز داشت.
حالا یک نفر تونسته بخش بزرگی از این کار رو با کمک LLM در مدت کوتاهی انجام بده.
وقتی داشتم به این مقاله فکر میکردم یاد فیلم Limitless افتادم. توی فیلم شخصیت اصلی داستان یعنی Eddie Morra با مصرف قرصی به نام NZT به توانایی ذهنی عجیبی میرسه.
میتونه حجم زیادی از اطلاعات رو به خاطر بیاره، ارتباط بین اتفاقها رو سریعتر پیدا کنه و چند حرکت جلوتر از بقیه تصمیم بگیره. اواخر فیلم تقریباً به نقطهای میرسه که انگار میتونه آینده رو پیشبینی کنه.
البته Eddie آینده رو به شکل جادویی نمیبینه. چیزی که فیلم نشون میده، ذهنیه که میتونه تعداد زیادی متغیر، الگو و پیامد احتمالی رو با سرعت خیلی بالا کنار هم بذاره.
در واقع اگر بتونیم درست از LLM استفاده کنیم، میتونه شبیه قرص NZT در فیلم Limitless عمل کنه.
نه به این معنی که ناگهان همهچیز رو بفهمیم و آینده رو ببینیم، بلکه به ما کمک میکنه حجم بیشتری از اطلاعات رو پردازش کنیم، بین اونها ارتباط پیدا کنیم، چند مدل بسازیم و هزاران آینده احتمالی رو قبل از تصمیم گرفتن آزمایش کنیم.
🔮 اما اینجا باید مراقب یک اشتباه مهم باشیم.
راحتتر شدن ساختن مدل پیشبینی، به معنی دقیقتر شدن پیشبینی نیست.
مدلی که در مقاله ساخته شده بود، در تست سه جام جهانی قبلی حدود ۵۵ درصد نتایج رو درست پیشبینی کرده بود.
اجرای ۵۰ هزار شبیهسازی هم مدل رو دقیقتر نمیکنه.
فقط نشون میده اگر دادهها، فرضها و فرمولهای ما درست باشن، هر کدوم از آیندههای ممکن با چه احتمالی اتفاق میافتن.
اگر فرض اولیه اشتباه باشه، میتونیم همون اشتباه رو ۵۰ هزار بار با سرعت و ظاهر علمی بیشتری تکرار کنیم 😁
ارزش LLM این نیست که مثل فالگیر جواب نهایی رو به ما بگه.
ارزشش اینه که ساختن و آزمایش کردن مدلهایی رو که قبلاً فقط از عهده تیمهای تخصصی برمیاومد، برای افراد بیشتری ممکن میکنه.
این توانایی فقط به مدلهای آماری هم محدود نیست.
الان دیگه برای اینکه به مشتری نشون بدیم محصول چه شکلی خواهد بود، لازم نیست فقط موکاپ Figma رو بهش نشون بدیم. میتونیم خیلی سریع چند MVP درست کنیم که تا حدودی هم کار میکنن.
از پیشبینی فروش و تقاضا گرفته تا بررسی ریسک پروژه، نگهداری تجهیزات یا تحلیل سناریوهای مختلف، حالا ساختن یک مدل اولیه خیلی ارزانتر و سریعتر شده.
البته انسان هنوز باید تصمیم بگیره چه دادهای معتبره، چه فرضی وارد مدل بشه، نتیجه با چه روشی ارزیابی بشه و آیا مدل واقعاً از یک روش ساده بهتره یا نه.
شاید LLMها هنوز ما رو به Eddie Morra تبدیل نکرده باشن.
اما دارن توانایی ساختن ابزارهایی رو در اختیارمون میذارن که میتونن قبل از تصمیمگیری، هزاران مسیر احتمالی رو بررسی کنن.
آینده لزوماً قابلپیشبینیتر نشده؛ توانایی ما برای ساختن، آزمایش کردن و مقایسه آیندههای احتمالی بیشتر شده.
شاید نزدیکترین چیز به قدرت Eddie Morra این نباشه که آینده رو ببینیم؛ بلکه این باشه که قبل از انتخاب یک مسیر، بتونیم هزاران مسیر ممکن رو بررسی کنیم.
البته نویسنده فقط از Claude نپرسیده «چه تیمی قهرمان میشه؟» و Claude هم از روی حس یا اطلاعات داخل مدل اسم اسپانیا رو بیرون نکشیده.
کلاد به نویسنده کمک کرده اطلاعات بیش از ۴۹ هزار مسابقه ملی رو جمعآوری و پردازش کنه، برای تیمها سیستم امتیازدهی Elo بسازه، احتمال گلها رو با یک مدل آماری محاسبه کنه و ادامه تورنمنت رو ۵۰ هزار بار شبیهسازی کنه.
نتیجه این شبیهسازیها این بوده که اسپانیا بیشتر از بقیه تیمها قهرمان شده؛ تقریباً یک بار از هر ۳.۴ تورنمنت.
اما بخش مهم ماجرا برای من اسپانیا یا حتی فوتبال نیست.
تا چند سال پیش انجام چنین پروژهای به ترکیبی از برنامهنویسی، آمار، جمعآوری و تمیز کردن داده و احتمالاً چند روز یا چند هفته زمان نیاز داشت.
حالا یک نفر تونسته بخش بزرگی از این کار رو با کمک LLM در مدت کوتاهی انجام بده.
وقتی داشتم به این مقاله فکر میکردم یاد فیلم Limitless افتادم. توی فیلم شخصیت اصلی داستان یعنی Eddie Morra با مصرف قرصی به نام NZT به توانایی ذهنی عجیبی میرسه.
میتونه حجم زیادی از اطلاعات رو به خاطر بیاره، ارتباط بین اتفاقها رو سریعتر پیدا کنه و چند حرکت جلوتر از بقیه تصمیم بگیره. اواخر فیلم تقریباً به نقطهای میرسه که انگار میتونه آینده رو پیشبینی کنه.
البته Eddie آینده رو به شکل جادویی نمیبینه. چیزی که فیلم نشون میده، ذهنیه که میتونه تعداد زیادی متغیر، الگو و پیامد احتمالی رو با سرعت خیلی بالا کنار هم بذاره.
در واقع اگر بتونیم درست از LLM استفاده کنیم، میتونه شبیه قرص NZT در فیلم Limitless عمل کنه.
نه به این معنی که ناگهان همهچیز رو بفهمیم و آینده رو ببینیم، بلکه به ما کمک میکنه حجم بیشتری از اطلاعات رو پردازش کنیم، بین اونها ارتباط پیدا کنیم، چند مدل بسازیم و هزاران آینده احتمالی رو قبل از تصمیم گرفتن آزمایش کنیم.
🔮 اما اینجا باید مراقب یک اشتباه مهم باشیم.
راحتتر شدن ساختن مدل پیشبینی، به معنی دقیقتر شدن پیشبینی نیست.
مدلی که در مقاله ساخته شده بود، در تست سه جام جهانی قبلی حدود ۵۵ درصد نتایج رو درست پیشبینی کرده بود.
اجرای ۵۰ هزار شبیهسازی هم مدل رو دقیقتر نمیکنه.
فقط نشون میده اگر دادهها، فرضها و فرمولهای ما درست باشن، هر کدوم از آیندههای ممکن با چه احتمالی اتفاق میافتن.
اگر فرض اولیه اشتباه باشه، میتونیم همون اشتباه رو ۵۰ هزار بار با سرعت و ظاهر علمی بیشتری تکرار کنیم 😁
ارزش LLM این نیست که مثل فالگیر جواب نهایی رو به ما بگه.
ارزشش اینه که ساختن و آزمایش کردن مدلهایی رو که قبلاً فقط از عهده تیمهای تخصصی برمیاومد، برای افراد بیشتری ممکن میکنه.
این توانایی فقط به مدلهای آماری هم محدود نیست.
الان دیگه برای اینکه به مشتری نشون بدیم محصول چه شکلی خواهد بود، لازم نیست فقط موکاپ Figma رو بهش نشون بدیم. میتونیم خیلی سریع چند MVP درست کنیم که تا حدودی هم کار میکنن.
از پیشبینی فروش و تقاضا گرفته تا بررسی ریسک پروژه، نگهداری تجهیزات یا تحلیل سناریوهای مختلف، حالا ساختن یک مدل اولیه خیلی ارزانتر و سریعتر شده.
البته انسان هنوز باید تصمیم بگیره چه دادهای معتبره، چه فرضی وارد مدل بشه، نتیجه با چه روشی ارزیابی بشه و آیا مدل واقعاً از یک روش ساده بهتره یا نه.
شاید LLMها هنوز ما رو به Eddie Morra تبدیل نکرده باشن.
اما دارن توانایی ساختن ابزارهایی رو در اختیارمون میذارن که میتونن قبل از تصمیمگیری، هزاران مسیر احتمالی رو بررسی کنن.
آینده لزوماً قابلپیشبینیتر نشده؛ توانایی ما برای ساختن، آزمایش کردن و مقایسه آیندههای احتمالی بیشتر شده.
شاید نزدیکترین چیز به قدرت Eddie Morra این نباشه که آینده رو ببینیم؛ بلکه این باشه که قبل از انتخاب یک مسیر، بتونیم هزاران مسیر ممکن رو بررسی کنیم.
👍8❤3👌2🥰1
فرض کنید یک Skill برای بررسی PRها ساختید و بعد از چند بار استفاده، به نتیجه خوبی رسیدید.
فایلش رو برای بقیه اعضای تیم میفرستید. یکی کپی میکنه داخل
دو هفته بعد چند نسخه مختلف از همون Skill داریم و دیگه دقیقاً معلوم نیست نسخه اصلی کدومه.
اینجا Skill دیگه فقط یک prompt شخصی نیست؛ تبدیل شده به یک dependency تیمی.
یعنی دیگه فقط یک یا چند فایل Markdown معمولی نیست؛ بخشی از پروسه توسعه نرمافزاره و باید دقیقاً مثل کد باهاش برخورد کنیم.
برای اشتراکگذاری تیمی هم بهتره یک repository مشخص، review و نسخه ثابت داشته باشه. نه اینکه هر کس یک کپی متفاوت روی سیستم خودش نگه داره و همه هم فکر کنن آخرین نسخه دست اونهاست.
باید دقت کنیم که ما معمولاً به
اگر Skill مخرب یا آلوده شده باشه، میتونه Agent رو هدایت کنه که فایل بخونه، اطلاعات رو به یک سرویس خارجی بفرسته یا از toolهایی استفاده کنه که قبلاً بهش اجازه دادهایم.
اگر Skill همراه خودش script داشته باشه، خطر دیگه فقط prompt injection نیست؛ ممکنه به اجرای کد و یک حمله واقعی در زنجیره تأمین نرمافزار تبدیل بشه.
حتی لازم نیست Skill اصلی مخرب باشه. ممکنه dependency که توی Skill بهش اشاره شده آلوده بشه یا یک آپدیت بدون review رفتار Skill رو عوض کنه.
آآآما ماجرا وقتی ترسناکتر میشه که میریم سراغ Skillهای پابلیک. عمده محتوای Skillها متنهای Markdown هستن که بشر (انواع گونههای دولوپر) همیشه از نوشتن و خوندنشون فرار میکرده.
ولی Agent خطبهخط و کلمهبهکلمه میخونه و بهش عمل میکنه.
دقیقاً مثل پکیجهای نرمافزاری که توی کد استفاده میکنیم، اینها هم ممکنه هک بشن و متن یا کد مخرب داخلشون قرار بگیره.
اینجاست که SBOM هم میتونه کمک کنه بفهمیم چه Skill، script و dependencyهایی وارد سیستم شدن. البته SBOM فقط فهرست اجزاست و بهتنهایی تضمین نمیکنه که اونها امن هستن.
خلاصه اوضاعی شده که ایجنت دیگه صاحابش رو هم نمیشناسه 😁
فایلش رو برای بقیه اعضای تیم میفرستید. یکی کپی میکنه داخل
.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 فقط فهرست اجزاست و بهتنهایی تضمین نمیکنه که اونها امن هستن.
خلاصه اوضاعی شده که ایجنت دیگه صاحابش رو هم نمیشناسه 😁
👍10🔥4🥰4❤3
وقتی میگیم باید از 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های قابلکنترل متصل بشن و به جزئی مهندسیشده از خود سیستم تبدیل بشن.
این کارها مفیدن، اما هنوز استفاده موردی از 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های قابلکنترل متصل بشن و به جزئی مهندسیشده از خود سیستم تبدیل بشن.
❤23👍10🥰2👏2⚡1
داستانها و فیلمها زیاد در مورد هوش مصنوعی که از کنترل خارج شده دیدیم و خوندیم. از ادیسه ۲۰۰۱ یا ترمینتور و یا حتی ماتریکس. اما به نظر من یکی از جالبترین و ترسناکترین اینها Ex Machina بوده.
توی ماجرای اخیری که بین openAI و HuggingFace افتاد، به نظرم Ex Machina خیلی نزدیکتره به همشون، اگر فیلم رو ندید تقریبا براتون اسپول شده تا الان ولی نمیخوام بیشتر از این اسپول کنم.
در مورد این ماجرا بروس اشنایر اخیرا از چیزی صحبت میکنه به اسم «ضریب جن»، نسرین (همسرم) هم در وبسایتش در این مورد پستی نوشته با عنوان «ضریب غول چراغ جادو» 🙂
پست بروس اشنایر
پست نسرین
فیلم
بعد از دیدن فیلم هم این ویدئو رو پیشنهاد میکنم ببنید
توی ماجرای اخیری که بین openAI و HuggingFace افتاد، به نظرم Ex Machina خیلی نزدیکتره به همشون، اگر فیلم رو ندید تقریبا براتون اسپول شده تا الان ولی نمیخوام بیشتر از این اسپول کنم.
در مورد این ماجرا بروس اشنایر اخیرا از چیزی صحبت میکنه به اسم «ضریب جن»، نسرین (همسرم) هم در وبسایتش در این مورد پستی نوشته با عنوان «ضریب غول چراغ جادو» 🙂
پست بروس اشنایر
پست نسرین
فیلم
بعد از دیدن فیلم هم این ویدئو رو پیشنهاد میکنم ببنید
❤16🥰3👌3👎1🤔1
Please open Telegram to view this post
VIEW IN TELEGRAM
👍28❤9🔥7🥰2
Please open Telegram to view this post
VIEW IN TELEGRAM
❤24👍4💯3🥰2🔥1
این روزها هر بحثی درباره AI خیلی زود میرسه به این سؤال که:
قراره کارهامون رو بگیره یا نه؟
مطلب زیر از دیدگاهی به نام « تخریب خلاق » به این موضوع نگاه میکنه، اینکه تکنولوژی چطور بعضی کارها رو از بین میبره، فرصتهای جدید میسازه و این بار چرا سرعت این تغییر میتونه همه چیز رو متفاوت کنه.
🔗 لینک مطلب
قراره کارهامون رو بگیره یا نه؟
مطلب زیر از دیدگاهی به نام « تخریب خلاق » به این موضوع نگاه میکنه، اینکه تکنولوژی چطور بعضی کارها رو از بین میبره، فرصتهای جدید میسازه و این بار چرا سرعت این تغییر میتونه همه چیز رو متفاوت کنه.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13🥰2👍1
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👍8🔥4🥰2
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤5🔥2🥰1
قبلا درباره nono و این موضوع نوشتم که محدودیت دسترسی AI agent باید بیرون از prompt و در سطح سیستمعامل اعمال بشه.
اما ساختن profile مناسب برای
برای سادهتر کردن این کار nono-wizard رو ساختم. ابزار coding agent، مسیر پروژه و سطح دسترسی موردنظرتون رو میپرسه و در انتها profile و command آماده اجرای
کل ابزار یک صفحه static هست و بدون نصب یا build داخل مرورگر اجرا میشه:
saderi.github.io/nono-wizard
اما ساختن profile مناسب برای
nono، مخصوصا برای کسی که تازه میخواد ازش استفاده کنه، میتونه کمی گیجکننده باشه. باید مشخص کنید agent به کدوم فایلها دسترسی داشته باشه، کجا اجازه نوشتن داشته باشه، به چه سرویسهایی در اینترنت وصل بشه و با چه تنظیماتی اجرا بشه.برای سادهتر کردن این کار nono-wizard رو ساختم. ابزار coding agent، مسیر پروژه و سطح دسترسی موردنظرتون رو میپرسه و در انتها profile و command آماده اجرای
nono رو تولید میکنه.کل ابزار یک صفحه static هست و بدون نصب یا build داخل مرورگر اجرا میشه:
saderi.github.io/nono-wizard
❤7👍7🥰3👌3