هدف این کانال فقط معرفی مدل‌های جدید LLM یا ابزارهای مرتبط با آن‌ها نیست.

تلاش من این است که صرفاً کپی‌کننده نباشم؛ یعنی هر چیزی را که ترند شد یا احتمالاً کلیک می‌خورد، بدون فکر اینجا بازنشر نکنم.

ممکن است درباره یک مدل LLM مطلب منتشر کنم، یک ابزار کاربردی را معرفی کنم، یا حتی سراغ کتاب، فیلم یا داستانی بروم که به نوعی با این موضوعات مرتبط است.

هدف اصلی این کانال این است که با هم درک بهتری از هوش مصنوعی و مدل‌های زبانی پیدا کنیم؛ فناوری‌ای که هنوز در ابتدای مسیر خود قرار دارد و قرار است بخش مهمی از آینده ما را شکل دهد.

امیدوارم بتوانیم با شناخت بهتر این فضا، سریع‌تر و آگاهانه‌تر خودمان را با آن تطبیق دهیم.

———

اگر شما هم بیشتر از هیجان خبرها، به فهمیدن پشت ماجرا علاقه دارید، خوش آمدید 🚀👍✌️

بیشتر افراد می‌گویند: «من از Cursor AI استفاده می‌کنم» یا «دارم یک AI Agent می‌سازم.»

اما این‌ها لایه‌های متفاوتی از یک فناوری هستند:


🤖 ایجنت‌ها (Agents) ← جریان‌های کاری ساخته‌شده از پرامپت‌ها، ابزارها، مجوزها و مدل‌ها

🛠 هارنس‌ها (Harnesses) ← Cursor، Copilot، Claude Code، OpenCode

🌐 ارائه‌دهندگان (Providers) ← OpenAI، Anthropic، Google، OpenRouter، Bedrock

🧠 مدل‌ها (Models) ← GPT، Claude، Gemini، DeepSeek



در تصویر بالا:

🔴 فلش قرمز = وابستگی به یک ارائه‌دهنده خاص
🟢 فلش سبز = امکان انتخاب ارائه‌دهنده یا مدل


درک تفاوت این لایه‌ها باعث می‌شود ارزیابی، طراحی و مقایسه سیستم‌های هوش مصنوعی بسیار شفاف‌تر و دقیق‌تر شود.

به هر چیزی «AI Agent» نگیم، اول مشخص کنیم دقیقاً درباره کدام لایه صحبت می‌کنیم.

🧠 بیشتر LLMهایی که امروز با آن‌ها کار می‌کنیم یک ویژگی مشترک دارند: تلاش برای «کامل بودن».

💬 حتی اگر یک سؤال کوتاه بپرسید، معمولاً سعی می‌کنند پاسخی جامع، مفصل و پوشش‌دهنده تمام جوانب ارائه دهند. برای یک Bash Script ساده هم اغلب کدی دریافت می‌کنید که از چیزی که واقعاً نیاز دارید طولانی‌تر و پیچیده‌تر است.

⚖️ این رفتار همیشه بد نیست، اما گاهی برای تحلیل، دیباگ یا تصمیم‌گیری سریع فقط به یک پاسخ کوتاه و مستقیم نیاز داریم.

✍️ در چنین مواقعی می‌توانید از این پرامپت استفاده کنید یا آن را در فایل‌های AGENTS.md و CLAUDE.md قرار دهید:

When reporting information to me, be extremely concise and sacrifice grammar for the sake of concision

🚀 این دستور مدل را ترغیب می‌کند به جای کامل‌ترین پاسخ ممکن، روی کوتاه‌ترین پاسخ مفید تمرکز کند.

📚 Credit: Matt Pocock

⚔️ در اکوسیستم LLMها هم مثل بسیاری از حوزه‌های نرم‌افزار، به نظر می‌رسد دو جبهه وجود دارد: Open Source و Closed Source.

🚨 جالب است که بخش قابل توجهی از هشدارها درباره خطرات AI، رگولیشن و محدود کردن دسترسی عمومی، از سمت شرکت‌هایی مطرح می‌شود که مدل‌هایشان را به‌صورت بسته توسعه می‌دهند.

📜 این داستان هم جدید نیست. سال ۲۰۱۹، OpenAI انتشار کامل GPT-2 را به دلیل «خطرات بالقوه سوءاستفاده» به تعویق انداخت. امروز هم روایت‌های مشابهی را در قالب AGI، سناریوهای آخرالزمانی و ماجراهایی مثل Mythos و Fable می‌بینیم.

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

❓سؤال اینجاست:

آیا نگرانی‌های ایمنی واقعاً دغدغه اصلی هستند، یا «ایمنی» گاهی به ابزاری برای حفظ مزیت رقابتی تبدیل می‌شود؟

🔓 به‌خصوص وقتی مدل‌های متن‌باز این امکان را می‌دهند که افراد و سازمان‌ها بدون وابستگی به ارائه‌دهندگان بزرگ، مدل‌ها را روی زیرساخت خود اجرا کنند.

⚠️ در ادامه پست قبلی، چند روز پیش استاد اعظم «بروس اشنایر» مقاله‌ای منتشر کرده که امروز فرصت کردم بخوانمش.

مطالعه‌اش را به شدید توصیه می‌کنم.

https://www.schneier.com/blog/archives/2026/06/anthropics-fable-and-the-state-of-ai.html

دنیای فیلم‌ها و داستان‌های علمی‌تخیلی معمولاً نگاه تاریکی به هوش مصنوعی دارد، از Skynet گرفته تا انواع سناریوهای آخرالزمانی

اما یک استثنای بزرگ وجود دارد: ایزاک آسیموف.

آسیموف نه‌فقط خالق «سه قانون رباتیک» بود، بلکه ده‌ها داستان و رمان درباره رابطه انسان و ربات نوشت، داستان‌هایی که برخلاف جریان غالب، صرفاً بر پایه ترس از هوش مصنوعی ساخته نشده‌اند.

البته آسیموف هم مثل خیلی از نویسنده‌های علمی‌تخیلی، برای پیش بردن داستان معمولاً به ربات‌ها ظاهر و رفتار انسان‌گونه می‌داد. اما اگر پوسته داستان را کنار بزنیم، با سؤال‌ها و چالش‌هایی روبه‌رو می‌شوید که شباهت عجیبی به بحث‌های امروز AI دارند.

یکی از داستان‌های مجموعه «روبات کامل» به نام Galley Slave دقیقاً از همین جنس است. داستانی که موقع خواندنش گاهی حس می‌کنید آسیموف چند دهه قبل نشسته و درباره روزگار ما نوشته است.

ترجمه فارسی «روبات کامل» توسط کتابسرای تندیس در سه جلد منتشر شده و این داستان با نام «جان کَن» در جلد دوم قرار دارد.

اگر هم حوصله خواندن ندارید، نریشن انگلیسی داستان را می‌توانید از لینک زیر گوش کنید:

https://www.youtube.com/watch?v=C8e_0c8nbFA

🛠 بین ده‌ها «Code Harness» مختلف، تا الان فرصت کار با این‌ها رو داشتم:

* GitHub Copilot
* OpenCode
* Pi
* Kiro CLI
* Claude Code

🚀 شروع کار من هم مثل خیلی‌ها با GitHub Copilot بود، اما کم‌کم به سمت ابزارهای ترمینال‌محور و مستقل‌تر رفتم.

⚙️ فعلاً OpenCode هارنس پیش‌فرض منه، ولی کم‌کم دارم به مهاجرت به Pi فکر می‌کنم. از نظر تجربه کار در ترمینال و فلسفه طراحی، Pi به چیزی که از ابزارهای لینوکسی انتظار دارم نزدیک‌تره. حسی که دارم اینه که OpenCode بیشتر با ذهنیت کاربران macOS طراحی شده.

🔓 هم OpenCode و هم Pi متن‌باز هستند؛ بنابراین می‌توانید دقیقاً ببینید هارنس چطور کار می‌کنه، System Prompt هارنس چیه و چه ابزارهایی در اختیار مدل قرار میده. اگر هم خواستید، به‌راحتی می‌توانید رفتارش را تغییر بدید.

🔒 از طرف دیگر، به نظر می‌رسه اکوسیستم Anthropic روزبه‌روز بسته‌تر میشه. Claude Code عملاً شما را به مدل‌های خودش محدود کرده و به نظر می‌رسه تمرکز شرکت بیشتر روی هدایت کاربران به سمت اکوسیستم خودش باشه. حتی بعضی وقت‌ها این حس رو دارم که تمام تلاششون اینه که هزینه استفاده از مدل‌ها برای افراد خارج از اکوسیستم Claude Code بالاتر باشه.

⚠️ همان‌طور که در مقاله اخیر بروس اشنایر هم مطرح شده بود، ممکنه بشه با یک هارنس خوب از یک مدل بیشتر از چیزی که روی کاغذ نشون میده کار کشید.

🐧 فعلاً هنوز اول راه هستیم. یک زمانی که توی لینوکس تازه‌کار بودیم هر هفته توزیع عوض می‌کردیم؛ این روزها هم هر هفته یک هارنس جدید را امتحان می‌کنیم.

🔒 یکم بیشتر توضیح بدم که چرا «حس» می‌کنم اکوسیستم Anthropic روزبه‌روز بسته‌تر میشه.

قبلاً Anthropic اجازه می‌داد از اشتراک Claude در هارنس‌های دیگر هم استفاده کنید. اما بعد از موفقیت ابزارهای دیگه، این امکان حذف شد و عملاً برای استفاده خارج از اکوسیستم Claude باید سراغ API می‌رفتید؛ روشی که معمولاً هزینه بسیار بیشتری نسبت به اشتراک عادی دارد.

بعدها حتی بسیاری از اپلیکیشن‌هایی که روی اشتراک Claude حساب کرده بودند هم مجبور شدند به API مهاجرت کنند. برای بعضی استارتاپ‌ها این فقط یک تغییر فنی نبود، بلکه مستقیماً روی هزینه‌ها و مدل کسب‌وکارشان اثر گذاشت.

نکته دیگر این است که Claude Code متن‌باز نیست. وقتی بخشی از سورس آن به اشتباه منتشر شد، مشخص شد بخش‌هایی از پیاده‌سازی فاصله زیادی با تصویری دارد که معمولاً از آن ارائه می‌شود. از آنجایی که سورس بسته است، عملاً امکان بررسی مستقل رفتار هارنس هم وجود ندارد.

یک نکته دیگه که به‌شدت رو اعصابه اینه که تقریباً اکثر هارنس‌ها روی فایل AGENTS.md به یک توافق نانوشته رسیده‌اند، اما Claude Code مسیر خودش را رفته و از CLAUDE.md استفاده می‌کند.

ممکن است بگن که Codex هم متن‌باز نیست، که درسته. اما تفاوتش برای من اینجاست که اگر از Codex استفاده نکنم (که نمی‌کنم)، همچنان می‌توانم با همان هزینه معمول به مدل‌های OpenAI دسترسی داشته باشم. در اکوسیستم Anthropic این انتخاب روزبه‌روز محدودتر به نظر می‌رسد.

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

🌐 تقریباً هر زمان که بخوام با یک مدل درباره موضوعات فنی صحبت کنم، سراغ انگلیسی میرم. اوایل این کار رو برای گرفتن جواب بهتر انجام می‌دادم و البته توضیح دادن موضوعات فنی به انگلیسی هم راحت‌تر بود. بعد کم‌کم تبدیل به عادت شد و رفتم ببینم این عادت درست هست یا نه که به چند چیز جالب رسیدم.

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

از اون مهم‌تر، تقریباً توی همه هارنس‌ها System Prompt و پرامپت‌های داخلی به زبان انگلیسی نوشته شده. یعنی شما از همون لحظه اول دارید با سیستمی کار می‌کنید که تقریباً همه اجزاش حول زبان انگلیسی ساخته شده‌اند.

یه نکته دیگه هم اینه که مدل‌ها کلمات رو «درک» نمی‌کنن. متن تبدیل به توکن میشه و تمام پردازش پشت صحنه روی همین توکن‌ها انجام میشه. طبیعتاً هر زبانی که توی داده‌های آموزشی، فرایند آموزش و ارزیابی مدل حضور پررنگ‌تری داشته باشه، معمولاً خروجی بهتری هم میده.

از اون طرف، بخش بزرگی از Safety Training، Preference Tuning و حتی Benchmark Testing مدل‌ها هم به زبان انگلیسی انجام میشه. برای همین خیلی عجیب نیست که مدل‌ها توی خیلی از کارهای فنی روی انگلیسی عملکرد بهتری داشته باشن.

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

📝 در ادامه پست قبلی، یه نکته رو هم بگم:

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

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

معمولاً پرامپت‌های طولانی رو اول به اون Agent میدم، بعد خروجی اصلاح‌شده رو به Agent اصلی میدم که قراره کار فنی انجام بده. اینطوری احتمال اینکه به خاطر انگلیسی افتضاح من موضوع رو اشتباه متوجه بشه کمتر میشه.

فایل AGENTS.md که برای این Agent استفاده می‌کنم رو هم اینجا می‌ذارم.

🤖 یکی از بحث‌هایی که با آمدن AI Agentها جدی‌تر شده اینه که اگر یک ایجنت خرابکاری کرد، مقصر کیه؟

مدل؟ ابزار؟ هارنس؟ یا کسی که اون ایجنت رو راه انداخته؟

⚠️ اسپویلر آلرت: مسئولیت نهایی همچنان با آدمه 😁😈.

فرقی نمی‌کنه کد رو خودت نوشته باشی یا Claude، GPT، Copilot یا هر Agent دیگه‌ای تولیدش کرده باشه. در نهایت تو بودی که مدل رو انتخاب کردی، بهش ابزار دادی، دسترسی تعریف کردی، پرامپت نوشتی و اجازه دادی وارد محیط واقعی بشه.

📄 اینجا باید دقت کنیم که نوشتن Rules توی فایل AGENTS.md به‌تنهایی کافی نیست. اگر بخوام همین موضوع رو بدون AI Agent توضیح بدم، میشه این:

شما به دولوپر می‌گید که چیزی رو مستقیم توی main پوش نکنه و حتماً برای تغییرات PR باز کنه. روز بعد دولوپر یه کد رو مستقیم توی main پوش می‌کنه، پایپلاین اجرا میشه و پروداکشن به فنا میره.

🔐 اینجا مقصر اصلی شما هستید، نه دولوپر؛ چون دسترسی push به main رو محدود نکردید.

با AI قضیه حساس‌تر هم میشه. چون یک Agent می‌تونه در چند ثانیه کاری رو انجام بده که قبلاً شاید یک انسان برای انجام دادنش چند دقیقه یا چند ساعت وقت لازم داشت. اگر به چنین چیزی دسترسی production بدیم و همه چیز بریزه به هم، نمی‌تونیم بگیم «AI این کار رو کرد».

🧠این AI Agent فقط یه ابزار جدیده؛ تصمیم و مسئولیت هنوز با آدمه.

📝 قبلاً درباره این نوشتم که نوشتن rules توی AGENTS.md به‌تنهایی کافی نیست.

👨‍💻 از نظر من coding agentها شبیه برنامه‌نویس جونیوری هستن که کتاب و ویدئو زیاد دیدن و شدیداً علاقه دارن با کارشون شما رو تحت تأثیر قرار بدن. برای همین گاهی از خطوطی که براشون کشیدید خارج میشن تا بگن: «ببین من چقدر بلدم!»

⚠️ برای همین اینکه بهشون بگیم «این فایل رو تغییر نده»، «به production دست نزن» یا «secretها رو نخون»، تا وقتی از نظر فنی جلویش را نگرفتیم، بیشتر شبیه توصیه است تا محدودیت واقعی.

🖥 وقتی به یک AI Agent دسترسی shell می‌دیم، عملاً بهش اجازه می‌دیم فایل بخونه و تغییر بده، command اجرا کنه، package نصب کنه، network request بزنه و حتی به secretها نزدیک بشه. برای همین کنترل کردن چنین چیزی فقط با prompt یا denylist کافی نیست.

📦 برای کنترل این ریسک، می‌تونیم از sandbox استفاده کنیم. راه‌های زیادی برای این کار وجود داره و یکی از نمونه‌هاش nono هست.

https://github.com/nolabs-ai/nono

🔒 ابزار nono یک sandbox برای اجرای Agentهاست که به جای اعتماد به خود مدل یا هارنس، دسترسی‌ها را در سطح سیستم‌عامل محدود می‌کند. یعنی می‌تونید مشخص کنید Agent به کدام مسیرها دسترسی داشته باشه، کجا نتونه بنویسه، چه network accessی داشته باشه و چه چیزهایی براش از اساس غیرممکن باشه.

🔐 این دقیقاً همان تفاوت بین نصیحت کردن یک دولوپر و بستن دسترسی push به main است.

🧪 البته sandbox هم مثل هارنس‌ها یک جواب واحد نداره؛ باید تست کنیم و ببینیم کدوم روش برای کدوم کار مناسب‌تره.

🚧 ممکنه چیزی که روی سیستم خودمون خوب جواب میده، برای pipeline گیت یا محیط CI/CD انتخاب مناسبی نباشه.