LLM Engineers

هرمس ایجنت (Hermes Agent) یک Agent Harness از تیم Nous Research است که مدل‌های زبانی رو در یک پکیج عملیاتی از ابزارها، حافظه و کنترلرهای محیطی محصور می‌کنه. برخلاف دستیارهای معمولی که فقط به سوالات جواب میدن، هرمس به عنوان یک Runtime عمل می‌کنه که قابلیت‌هایی مثل کنترل ترمینال و مرورگر، اجرای Cron Job، مدیریت Subagents و اتصال به پیام‌رسان‌هایی مثل تلگرام و اسلک رو به صورت پیش‌فرض درون خودش داره. در واقع هرمس اون "چسب" یا Glueای هست که شما رو از سرهم‌بندی دستی LangGraph، داکر، سیستم‌های زمان‌بندی و دیتابیس‌های حافظه بی‌نیاز می‌کنه. تفاوت اصلی هرمس در مفهوم Harness Engineering نهفته است. هدف اینجا این نیست که مدل رو با پرامپت‌های طولانی‌تر باهوش‌تر کنیم، بلکه مهندسی کردن محیطی (Environment) است که مدل در آن فعالیت می‌کنه. هرمس این کار رو با لایه‌بندی دقیق انجام میده: لایه ابزارها (Web search, Terminal, Home Assistant)، لایه اجرا (Docker, SSH, Modal) و لایه حافظه (Persistent Memory). یکی از نقاط قوت فنی هرمس، سیستم Skillهاست؛ مهارت‌ها به صورت اسناد دانش (Markdown) در مسیر ~/.hermes/skills/ ذخیره میشن و فقط در صورت نیاز بارگذاری میشن تا مصرف توکن بیهوده بالا نره. این یعنی ایجنت با گذشت زمان و یادگیری از تسک‌های قبلی، پخته‌تر میشه و عملاً با شما رشد می‌کنه. یکی از جذاب‌ترین بخش‌های هرمس، Compounding Workflows یا جریان‌های کاریِ تجمیعی هست. هرمس از تجربه‌های قبلی اسکیل می‌سازه، اون‌ها رو در حین استفاده اصلاح می‌کنه و یک مدل ذهنی از کاربر و پروژه در سشن‌های مختلف ایجاد می‌کنه. این دقیقاً همون چیزیه که هرمس رو از ابزارهایی مثل Claude Code یا Cursor متمایز می‌کنه. هرمس بیشتر شبیه به یک Junior Operator است که همیشه روی سرور (VPS) شما بیداره، از طریق تلگرام در دسترسه، کارهای روتین رو با Cron انجام میده و تاریخچه تمام تعاملاتش رو برای استفاده در آینده ایندکس می‌کنه. کاربردهای واقعی هرمس فراتر از کدنویسی ساده‌ست. شما می‌تونید هرمس رو روی یک سرور خونگی یا VPS بالا بیارید و از طریق تلگرام بهش دستور بدید. مثلاً می‌تونید براش تعریف کنید که هر روز صبح اخبار خاصی رو مانیتور کنه، خلاصه‌سازی کنه و براتون بفرسته، یا اینکه مخازن گیت شما رو چک کنه و در صورت وجود آپدیت، یک گزارش تغییرات (Changelog) بنویسه. قدرت واقعی هرمس وقتی مشخص میشه که تسک‌های تکراری پروژه رو به Skill تبدیل کنید؛ کارهایی مثل "ایجاد PR برای ریفکتورینگ" یا "اجرای چک‌لیست ریلیز" که نیاز به دسترسی به ترمینال، گیت و مستندات دارن، با هرمس به تسک‌های خودکار تبدیل میشن. نکته فنی که نباید ازش غافل شد، امنیت و پایداری در تسک‌های طولانی‌مدت (Long-horizon) هست. اجرای ایجنت‌هایی که دسترسی به Shell دارن و همیشه آنلاین هستن، ریسک‌های امنیتی بزرگی مثل Sleeper Channels رو به همراه داره؛ جایی که ورودی‌های غیرقابل اعتماد می‌تونن به عنوان حافظه یا اسکیل در سیستم ذخیره بشن و بعداً کدهای مخرب اجرا کنن. همچنین، گزارش‌های جدید از شکست‌هایی مثل Channel Fracture در سیستم‌های چند ایجنتی هرمس خبر میدن که نشان‌دهنده چالش‌های جدی در پایداری تحویل پیام‌ها و تزریق حافظه در کارهای سنگین هست. هرمس هنوز یک ابزار تجربی محسوب میشه و نباید بدون ایزولاسیون کامل (Containerization) و لایه‌های تایید انسانی روی سیستم‌های حساس رها بشه. در نهایت، هرمس برای چه کسی مناسبه؟ اگر تسک‌های شما ماهیت تکرارپذیر دارن (مثل مانیتورینگ روزانه، نگهداری CI/CD، یا مدیریت دانش در ابزاری مثل Obsidian)، هرمس بهترین انتخابه. اما اگر فقط برای یک‌بار کدنویسی یا پرسیدن سوال به هوش مصنوعی نیاز دارید، ابزارهایی مثل Claude Code یا Cursor به دلیل سادگی و تمرکز بر IDE گزینه‌های منطقی‌تری هستن. هرمس زمانی ارزش خودش رو نشون میده که بخواهید یک "سیستم‌عامل برای هوش" بسازید که حافظه، اسکیل و زمان‌بندی رو به صورت یکپارچه مدیریت کنه. 📃 وب‌سایت رسمی هرمس ایجنت: https://hermes-agent.nousresearch.com 🛠 Join @LLMEngineers Community

مفهوم Harness Engineering کلید گمشده تولید نرم‌افزار با ایجنت‌ها در سال ۲۰۲۶ است. فرمول ساده‌ست: Agent = Model + Harness. هارنس یعنی هر چیزی که مدل نیست؛ از محدودیت‌ها و ابزارها گرفته تا لوپ‌های فیدبک و فایل‌های استیت. اگر مدل را CPU در نظر بگیریم، هارنس نقش Operating System را بازی می‌کند که منابع را مدیریت می‌کند، کارهای تکراری را Schedule می‌کند و اجازه نمی‌دهد مدل در Context Window خودش غرق شود. واقعیت این است که در پروژه‌های بزرگ، محیطی که مدل در آن کار می‌کند، بسیار مهم‌تر از خود مدل است. فایل‌های AGENT.md یا CLAUDE.md ابزارهای اصلی این معماری در مخازن کد هستند. این‌ها فایل‌های Markdown هستند که در ریشه پروژه قرار می‌گیرند تا ایجنت در شروع هر سشن بدونه کجاست، کانونشن‌های تیم چیست و معماری فعلی چه وضعیتی دارد. جالب اینجاست که برای رهگیری پیشرفت (Progress Tracking)، استفاده از فایل‌های JSON بسیار پایدارتر از Markdown عمل می‌کند؛ چون ایجنت‌ها در سشن‌های طولانی کمتر تمایل دارند ساختار JSON را تصادفی خراب کنند. این فایل‌ها در واقع RAM ایجنت هستند که بین ری‌استارت‌های مختلف سشن، ثابت می‌مانند. جدا کردن مرحله Planning از Execution یک اصل حیاتی در Harness Engineering است. ایجنتی که همزمان نقشه می‌کشد و کد می‌زند، خروجی غیرقابل اعتمادی دارد. در هارنس‌های سینیور، ابتدا یک Sprint Contract بسته می‌شود؛ یعنی یک ایجنت (Planner) پیشنهاد می‌دهد که چه تغییری می‌خواهد بدهد و ایجنت دوم (Evaluator) آن را نقد می‌کند. فقط بعد از توافق، مرحله پیاده‌سازی شروع می‌شود. این یعنی Context beats Instructions؛ نشان دادن نقشه راه و وضعیت فعلی فایل‌ها به ایجنت، صد برابر بهتر از نوشتن پرامپت‌های طولانی و انتزاعی جواب می‌دهد. پدیده Harness Decay واقعیتی است که باید به آن عادت کنیم. هر قطعه در هارنس، در واقع فرضیه‌ای است درباره اینکه مدل چه کاری را نمی‌تواند انجام دهد. با آپدیت شدن مدل‌ها (مثلاً از Opus 4.5 به 4.8)، بخش‌هایی از هارنس که قبلاً ضروری بودند تبدیل به Overhead می‌شوند چون مدل خودش هوشمندتر شده و می‌تواند آن مرحله را حذف کند. به نظر من، مهندسی که هارنس می‌سازد باید با ذهنیت Build to delete کار کند؛ یعنی هر قطعه را جوری طراحی کند که به محض قوی‌تر شدن مدل، بتوان آن را حذف کرد تا هزینه توکن بیهوده بالا نرود. هزینه اجرای یک لوپ کامل با هارنس مهندسی شده ممکن است ۲۰ برابر بیشتر از یک پرامپت ساده باشد، اما خروجی یک نرم‌افزار واقعی با UI تمیز و منطق درست است، نه یک دموی شکسته که فقط در اسکرین‌شات خوب به نظر می‌رسد. مهندس هوش مصنوعی واقعی در سال ۲۰۲۶ کسی نیست که پرامپت‌های زیباتری می‌نویسد، بلکه کسی است که بهترین Runtime را برای هوش طراحی می‌کند تا ایجنت بتواند در یک محیط ایزوله (Sandbox)، کد بزند، تست بگیرد و در صورت خطا، خودش را اصلاح کند. 📃 مستندات Anthropic درباره ارزیابی ایجنت‌ها: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents 📃 مقاله OpenAI درباره لوپ‌های ایجنتی Codex: https://openai.com/index/unrolling-the-codex-agent-loop/ 📃 چارچوب کاری Harness Engineering در arXiv: https://arxiv.org/abs/2605.13357 به نظر من، دوران کل‌کل سر اینکه کدام مدل بهتر است تمام شده. برنده کسی است که هارنس قوی‌تری بسازد. اگر دیتابیس یا مخزن کد شما شلخته باشد، حتی قوی‌ترین مدل دنیا هم خروجی آشغال تحویل می‌دهد. سرمایه‌گذاری روی خوانایی کد برای ایجنت (Harnessability)، ارزشمندترین کاری است که یک تیم فنی می‌تواند انجام دهد. 🛠 Join @LLMEngineers Community

معماری Agent Skills در واقع یک فرمت استاندارد و سبک برای بسته‌بندی دانش تخصصی و جریان‌های کاری (Workflows) است تا ایجنت‌های هوشمند بتوانند فراتر از چت کردن ساده، کارهای واقعی و تکرارپذیر انجام دهند. مشکل اصلی ایجنت‌ها این است که مثل ماهی قرمز حافظه کوتاه‌مدت دارند و کانتکست پروژه را بین جلسات مختلف فراموش می‌کنند. استاندارد Agent Skills که توسط Anthropic معرفی شده، این دانش را در قالب یک پوشه شامل دستورالعمل‌ها، اسکریپت‌ها و فایل‌های مرجع پکیج می‌کند تا ایجنت هر بار چرخ را از اول اختراع نکند. ساختار فنی یک Skill بسیار ساده و در عین حال قدرتمند است. یک پوشه حاوی فایل حیاتی SKILL.md که شامل Metadata (نام و توضیحات) و دستورالعمل‌های گام‌به‌گام است. در کنار آن، پوشه‌های اختیاری مثل scripts برای کدهای اجرایی پایتون یا بش، references برای مستندات فنی و assets برای تمپلیت‌ها قرار می‌گیرند. این یعنی شما دانش دامنه (Domain Expertise) خودتان را، مثلاً نحوه بازبینی کدهای امنیتی یا تحلیل داده‌های مالی، به صورت Version-controlled در کنار سورس‌کد پروژه نگه می‌دارید. مکانیزم Progressive Disclosure یا افشای تدریجی، برگ برنده این استاندارد برای مدیریت هزینه و کانتکست است. ایجنت در مرحله اول (Discovery) فقط نام و توضیحات اسکیل را می‌خواند تا بداند چه ابزارهایی در اختیار دارد. تنها زمانی که تسک کاربر با توضیحات یک اسکیل مطابقت داشته باشد، مرحله Activation رخ می‌دهد و کل محتوای دستورالعمل‌ها وارد Context Window مدل می‌شود. این روش باعث می‌شود ایجنت بتواند صدها مهارت مختلف داشته باشد بدون اینکه توکن‌های ارزشمند را با اطلاعات غیرضروری هدر دهد. تفاوت Skill با Plugin در این است که اسکیل فرمت نگارش و توسعه (Authoring) است، در حالی که پلاگین فرمت توزیع و بسته‌بندی (Shipping) محسوب می‌شود. وقتی شما چند اسکیل و کانکتور را برای بقیه هم‌تیمی‌ها بسته‌بندی می‌کنید، در واقع یک پلاگین ساخته‌اید. این تفکیک باعث می‌شود توسعه‌دهنده روی منطق کار (Logic) تمرکز کند و درگیر پیچیدگی‌های استقرار نشود. به نظر من، بزرگترین مزیت Agent Skills این است که ایجنت را از حالت "حدس زدن" (Confident Guessing) خارج می‌کند. وقتی ایجنت وارد یک سشن جدید می‌شود، هیچ ایده‌ای از کانونشن‌های تیم یا حوادث قبلی پروژه ندارد. با نوشتن یک اسکیل دقیق، شما "قوانین بازی" را یک‌بار می‌نویسید و ایجنت در هر اجرا موظف به رعایت آن‌هاست. این یعنی خروجی ایجنت دیگر وابسته به شانس یا پرامپت‌های تصادفی نیست، بلکه پیرو یک متدولوژی مهندسی‌شده است. 📃 مستندات Agent Skills: https://agentskills.io 🛠 Join @LLMEngineers Community

مفهوم Prompt Engineering دیگه داره به پایان عمرش می‌رسه و جای خودش رو به Loop Engineering میده. به جای اینکه دستی برای ایجنت پرامپت بنویسید، خروجی بگیرید و ارورها رو دوباره به خورد مدل بدید، یک سیستم طراحی می‌کنید که خودش کار رو پیدا کنه، انجام بده، با ابزارهای واقعی تست کنه و در صورت خطا خودش رو اصلاح کنه. این تغییر پارادایم، باتل‌نک توسعه رو از سرعت تایپ انسان به طراحی سیستم‌های خودکار و مستقل منتقل کرده. پیاده‌سازی لوپ‌ها روی کاغذ جذابه اما تو واقعیت به شدت پرهزینه است. یک لوپ ساده برای یک تسک برنامه‌نویسی می‌تونه به راحتی بین ۵۰ تا ۲۰۰ هزار توکن مصرف کنه. اگه محدودیت نذارید و از مدل‌های گرون‌قیمت استفاده کنید، تو چند روز کل بودجه API شما نابود میشه. دلیل اینکه این روزها پیاده‌سازی لوپ منطقی شده، ظهور مدل‌های ارزون‌قیمت با کانتکست بالا (مثل سری DeepSeek V4) هست که اجازه میدن ایجنت‌ها بدون نگرانی از هزینه، بارها خطا کنن و خودشون رو دیباگ کنن. معماری یک لوپ مهندسی‌شده و پایدار از ۶ بخش اصلی تشکیل میشه که باید دقیق کنار هم چیده بشن: بخش Automations: یک سیستم زمان‌بندی (کرون جاب یا هوک) که لوپ رو بیدار می‌کنه. به جای اجرای دستی، سیستم هر روز صبح ایشوها رو چک می‌کنه. مفهوم Worktrees: وقتی چند ایجنت موازی کار می‌کنن، نباید فایل‌های هم رو خراب کنن. استفاده از قابلیت worktree تو گیت باعث میشه هر ایجنت تو دایرکتوری ایزوله خودش کار کنه. فایل‌های Skills: ایجنت‌ها حافظه ندارن. باید فایل‌هایی مثل VISION.md یا SKILL.md تعریف بشه تا کانونشن‌های پروژه رو یک‌بار بخونن و هر بار از صفر شروع نکنن. پروتکل Connectors: استفاده از MCP برای اتصال ایجنت به دنیای واقعی. ایجنت باید بتونه تیکت جیرا رو آپدیت کنه یا تو اسلک پیام بده، نه اینکه فقط روی فایل سیستم بچرخه. معماری Sub-agents: مدلی که کد رو می‌نویسه، نباید خودش رو ارزیابی کنه. همیشه باید یک ایجنت برای تولید (Maker) و یک ایجنت ایزوله با دستورالعمل‌های سخت‌گیرانه‌تر برای تایید (Checker) داشته باشید. مدیریت State: یک فایل ساده STATE.md که لاگ کارهای انجام شده و ارورها رو نگه می‌داره تا لوپ در اجرای بعدی بدونه کجا متوقف شده و دوباره از صفر اختراع نکنه. بزرگترین اشتباه در ساخت لوپ، نبودن یک گیت اعتبارسنجی سفت و سخته. اگر معیار پایان کار، نظر خود ایجنت باشه، لوپ شما توهم می‌زنه و کار رو نصفه رها می‌کنه. یک لوپ واقعی به محض توقف، باید به صورت خودکار تست‌ها یا Linter رو اجرا کنه (مثلا با اجرای دستورات تست در پس‌زمینه). اگر خروجی خطا داشت، لاگ ارور به صورت خودکار به کانتکست برمی‌گرده و ایجنت مجبور به رفع اون میشه. برای جلوگیری از گیر کردن در لوپ بی‌نهایت، حتما باید یک Hard limit (مثلا حداکثر ۵ بار تلاش) براش تعریف بشه تا اگر نتونست حلش کنه، تسک رو به انسان بسپاره. بدهی درک کد (Comprehension debt) خطرناک‌ترین عارضه این سیستمه. وقتی لوپ‌ها با سرعت بالا کد می‌زنن و مرج می‌کنن، فاصله بین چیزی که تو ریپو هست و چیزی که شما از معماری می‌فهمید به شدت زیاد میشه. این سیستم قرار نیست شما رو از چرخه مهندسی حذف کنه. اگر لوپ روی کدهای حساسی مثل منطق Auth یا سیستم پرداخت رها بشه، فاجعه امنیتی و منطقی به بار میاد. بهترین نقطه شروع، اتوماتیک کردن رسیدگی به خطاهای CI، آپدیت Dependencyها و رفع باگ‌های مشخص و تکراریه. به نظر من، کسایی که هنوز دارن روی تکنیک‌های پرامپت‌نویسی وقت می‌ذارن، دارن روی مهارت اشتباهی سرمایه‌گذاری می‌کنن. طراحی لوپ‌های بسته (Closed Loops) که تسک‌های مشخص رو با ابزارهای تست خودکار هندل می‌کنن، چیزیه که تفاوت یک توسعه‌دهنده سینیور و یک کاربر ساده رو در آینده نزدیک مشخص می‌کنه. قبل از ساخت لوپ، مطمئن بشید که تسک شما حداقل هفته‌ای یک‌بار تکرار میشه و تست خودکار براش وجود داره، در غیر این صورت همون پرامپت زدن دستی کاملا منطقی‌تره. 🛠 Join @LLMEngineers Community

دوران تولید توکن به توکن (Autoregressive) با معرفی DiffusionGemma وارد فاز جدیدی شده که تمرکزش روی سرعت وحشتناک و پردازش موازیه. این مدل که بر پایه Gemma 4 ساخته شده، یک 26B MoE هست که در لحظه استنتاج فقط حدود ۴ میلیارد پارامتر فعال داره. برخلاف مدل‌های کلاسیک که خروجی رو دانه به دانه می‌سازن، این مدل از مکانیزم Diffusion برای تولید و اصلاح همزمان یک بلوک ۲۵۶ توکنی استفاده می‌کنه. این یعنی گلوگاه مدل از پهنای باند حافظه (Memory Bandwidth) به توان محاسباتی (Compute) منتقل شده و روی سخت‌افزارهای مدرن مثل RTX 5090 یا H100، سرعتی بین ۷۰۰ تا ۱۰۰۰ توکن بر ثانیه میده که عملاً با سرویس‌های ابری گرون‌قیمت مثل Groq رقابت می‌کنه. کاربرد عملی این مدل در حال حاضر بیشتر در تسک‌هایی مثل Fill-in-the-Middle (کامل کردن کد در وسط فایل)، اصلاح خطاهای OCR و Data Augmentation هست. به دلیل ماهیت Bidirectional یا دوطرفه بودن، مدل می‌تونه کل بلوک متن رو همزمان ببینه و برخلاف مدل‌های AR که وقتی توکنی رو نوشتن دیگه راه برگشت ندارن، اینجا مدل قابلیت Self-correction داره. یعنی اگه در مراحل اولیه تولید (Denoising) اشتباهی رخ بده، در گام‌های بعدی اصلاحش می‌کنه. برای تسک‌های غیرخطی مثل حل جدول یا معماهای منطقی که نیاز به دید کلی دارن، این معماری بسیار کارآمدتر از مدل‌های خطیه. معماری Uniform State Diffusion در این مدل به این صورته که ابتدا یک بوم (Canvas) از توکن‌های تصادفی ساخته می‌شه و طی چندین مرحله عملیات Denoising، توکن‌ها شفاف و قطعی می‌شن. برای متن‌های طولانی‌تر از ۲۵۶ توکن، مدل از روش Block Autoregressive استفاده می‌کنه؛ یعنی هر بلوک رو موازی می‌سازه، در KV Cache ذخیره می‌کنه و سراغ بلوک بعدی میره. این ترکیب باعث شده پایداری مدل‌های سنتی با سرعت مدل‌های نان-اتورگرسیو ترکیب بشه. تجربه کاربری و بنچمارک‌های اولیه نشون میده که DiffusionGemma در کنار سرعت بالا، افت کیفیت محسوسی نسبت به نسخه استاندارد Gemma 4 داره. در واقع شما سرعت رو با هوش معامله می‌کنید. برای تسک‌های پیچیده استدلالی یا نوشتن متون خلاقانه طولانی، مدل ممکنه دچار تناقض بشه یا منطق ضعیف‌تری نشون بده. اما برای خط لوله‌های (Pipelines) پردازش داده که نیاز به سرعت بالا دارن و هوش در حد Qwen 3.5 9B براشون کافیه، این مدل یک گزینه بی‌رقیبه. با کوانتایز کردن، مدل در ۱۸ گیگابایت VRAM جا می‌شه که یعنی روی کارت‌های گرافیک کانسومر مثل RTX 3090/4090 به راحتی قابل اجراست. به نظر من، DiffusionGemma شروع یک تغییر پارادایم در مدل‌های لوکال هست. اهمیت این مدل در اینه که از ظرفیت بلااستفاده Tensor Coreها در کارت‌های گرافیک استفاده می‌کنه. اگه پروژه شما نیاز به استخراج موجودیت (Entity Extraction)، خلاصه‌سازی سریع یا ویرایش در لحظه متن داره، حتماً سمت این مدل برید. اما برای چت‌بات‌های عمومی که نیاز به دقت بالا دارن، هنوز مدل‌های Autoregressive گزینه مطمئن‌تری هستن. پشتیبانی از این مدل در vLLM و SGLang اضافه شده و به راحتی با کتابخانه‌های Transformers هم قابل استفاده‌ست. 🤗 وزن‌های مدل در Hugging Face: https://huggingface.co/google/diffusiongemma-26B-A4B-it 🛠 Join @LLMEngineers Community

خانواده مدل‌های Nex-N2 بر پایه Qwen 3.5 توسعه داده شدن و هدف اصلی‌شون حل چالش‌های عملیاتی در سیستم‌های Agentic هست. این مدل‌ها به جای تمرکز روی چت جنرال، روی Code Implementation و Tool-use بهینه‌سازی شدن تا در لوپ‌های طولانی‌مدت (Long-horizon tasks) پایدار بمونن. مدل Nex-N2-Pro از معماری MoE با ۳۹۷ میلیارد پارامتر کلی و ۱۷ میلیارد پارامتر فعال استفاده می‌کنه که کانتکست Window آن ۲۶۲ هزار توکن است. مکانیزم فنی Adaptive Thinking در این مدل، طول زنجیره استدلال (Reasoning Chain) رو بر اساس سختی سوال تغییر می‌ده. این یعنی در تسک‌های ساده، توکن اضافی برای فکر کردن هدر نمیره و طبق ادعای تیم توسعه، حدود ۲۰ درصد مصرف توکن بدون کاهش دقت پایین اومده. در تسک‌های پیچیده مثل SWE-bench که نیاز به تغییر در سورس‌کد واقعی دارن، مدل از سیستم Coherent Thinking استفاده می‌کنه تا بین مرحله سرچ، کدنویسی و تست، پارادایم منطقی یکسانی رو حفظ کنه و دچار ناسازگاری نشه. تجربه‌های واقعی تسترها در کامیونیتی LocalLLaMA و X نشون می‌ده که مدل توی کدنویسی پایتون و ساخت اپلیکیشن‌های تک‌صفحه‌ای عملکردی مشابه GPT-4o و حتی در مواردی بهتر از آن داشته. با این حال، گزارش‌هایی مبنی بر گیر کردن در Repetition Loop در مواجهه با لینک‌های خراب یا ارورهای ۴۰۴ وجود داره. یعنی مدل وقتی با مانع محیطی غیرمنتظره برخورد می‌کنه، گاهی به جای تغییر استراتژی، روی تسک قبلی اصرار می‌کنه که نشان‌دهنده نیاز به Tuning بیشتر در بخش Error Handling هست. این مدل یک ابزار تخصصی برای برنامه‌نویس‌ها و توسعه‌دهنده‌های Agent هست و نباید به عنوان جایگزین مدل‌های جنرال برای نوشتن متن یا تحقیق‌های ساده استفاده بشه. تمرکز اصلی روی Actionable Output هست و اگر دنبال اتومیشن در ترمینال یا دیباگ خودکار کد هستید، ارزش تست کردن رو داره، مخصوصاً با توجه به لایسنس Apache 2.0 که اجازه استفاده تجاری رو می‌ده. 📃 مخزن گیت‌هاب و ابزارهای استقرار: https://github.com/nex-agi/Nex-N2 📃 مدل Nex-N2-Pro در Hugging Face: https://huggingface.co/nex-agi/Nex-N2-Pro 📃 دسترسی رایگان در OpenRouter: https://openrouter.ai/nex-agi/Nex-N2-Pro:free 🛠 Join @LLMEngineers Community

خلاصه وضعیت فریم‌ورک‌های ساخت Agent در میانه ۲۰۲۶ بر اساس پست‌های توییتر، لینکدین و ردیتی که مشاهده کردم، در حال حاضر هیچ استاندارد واحدی برای ساخت AI Agent وجود ندارد و انتخاب ابزار کاملاً به نوع پروژه (تولید، پروتوتایپ، پیچیدگی و ...) بستگی دارد. رتبه‌بندی فعلی محبوب‌ترین ابزارها: ۱. LangGraph (اکوسیستم LangChain) بهترین گزینه برای محیط‌های تولید (Production). مزایا: مدیریت حالت (Stateful)، ذخیره‌سازی نقاط چک‌پوینت (Checkpointing)، مشارکت انسان در حلقه (Human-in-the-Loop) و LangSmith برای نظارت. مناسب برای پروژه‌های پیچیده و نیازمند کنترل بالا. ۲. CrewAI بهترین گزینه برای سیستم‌های چندعاملی (Multi-Agent) و پروتوتایپ سریع. نقاط قوت: تعریف نقش و وظایف بسیار ساده و خوانا (مانند Researcher + Writer)، سرعت بالا و جامعه فعال. ۳. بهترین گزینه به نظر من: SDKهای بومی ارائه‌دهندگان (به‌ویژه OpenAI Agent SDK و Claude Agent SDK) در حال رشد سریع هستند. بسیاری از مهندسان ترجیح می‌دهند با لایه نازک و SDK خام کار کنند تا از انتزاعات اضافی دوری نمایند. ابزارهای قابل توجه دیگر: LlamaIndex: سلطان RAG و عامل‌های مبتنی بر داده. AutoGen/AG2، Pydantic AI، Semantic Kernel و ... روند غالب: ساخت Harness شخصی + تمرکز بر ارزیابی (Evaluation)، مشاهده‌پذیری (Observability) و حافظه (Memory). شما در حال حاضر از چه فریم‌ورکی برای ساخت Agent استفاده می‌کنید؟ نظر خود را بنویسید 👇

🚀 موج جدید مدل‌های هوش مصنوعی متن‌باز (فوریه تا آوریل ۲۰۲۶) در این دو ماه، شرکت‌های بزرگ جهان مدل‌های قدرتمند متن‌باز زیادی منتشر کردند. خلاصه لیست کامل: ✅ Gemma 4 (Google DeepMind - ۲ آوریل) سایزها: ۲.۳B تا ۳۱B | زمینه ۲۵۶K | چندوجهی | لایسنس Apache-2.0 قوی در استدلال عمومی و چندرسانه‌ای ✅ Qwen 3.6 Series (Alibaba - آوریل) مدل‌های متن‌باز: ۲۷B Dense و ۳۵B MoE MMLU-Pro تا ۸۶.۲٪ | سرعت بالا با int4 | پشتیبانی از تصویر ✅ DeepSeek V4 (DeepSeek AI - ۲۴ آوریل) V4-Pro: ۱.۶T (۴۹B فعال) | V4-Flash: ۲۸۴B (۱۳B فعال) زمینه ۱ میلیون توکن | بسیار قوی در کدنویسی و استدلال پیچیده | MIT ✅ Kimi K2.6 (Moonshot AI - ۲۰ آوریل) ۱T (۳۲B فعال) MoE | زمینه ۲۵۶K | عالی در استدلال و کدنویسی جامعه: «نزدیک‌ترین مدل متن‌باز به Claude 4.5» ✅ MiniMax M2.5 (۱۲ فوریه) ۲۲۹B (۱۰B فعال) MoE | سرعت بالا و هزینه خیلی کم بهترین عملکرد در عامل‌های هوشمند و SWE-Bench (۸۰.۲٪) ✅ GLM-5 / GLM-5.1 (Zhipu AI - فوریه و مارس) ۷۴۴B (۴۰B فعال) | زمینه ۲۰۰K | قوی در کدنویسی و کارهای agentic | MIT ✅ Nemotron-Cascade 2 (NVIDIA - ۱۹ مارس) ۳۰B (۳B فعال) MoE | زمینه ۱M | مدال طلا در IMO و IOI | LiveCodeBench ۸۷.۲٪ --- خلاصه عملکرد: - بهترین استدلال عمومی: Qwen 3.6-27B و Gemma 4-31B - بهترین کدنویسی: MiniMax M2.5 و Nemotron-Cascade 2 - قوی‌ترین مدل‌های بزرگ: DeepSeek V4-Pro و Kimi K2.6 - بهترین برای اجرا محلی و سرعت: Gemma و Qwen 3.6-MoE همه مدل‌ها وزن‌های باز روی Hugging Face دارند و اکثرشان تحت لایسنس Apache یا MIT هستند (استفاده تجاری آزاد).

✅ جما ۴ (Gemma 4) رسماً منتشر شد! 🚀 گوگل دیپ‌مایند بالاخره جما ۴ رو رونمایی کرد — قدرتمندترین مدل‌های متن‌باز تا امروز، با قابلیت‌های چندوجهی (تصویر + صدا + ویدیو) و اجرای محلی روی گوشی و دستگاه‌های کوچک. ### ویژگی‌های کلیدی: - ۴ سایز مختلف: از E2B (مناسب گوشی و راسپبری پای) تا ۳۱B Dense - لایسنس Apache 2.0 — کاملاً آزاد برای استفاده تجاری، بدون محدودیت! - حالت Thinking برای استدلال گام‌به‌گام - زمینه تا ۲۵۶K توکن - پشتیبانی از **۱۴۰+ زبان**، function calling و agentic workflows - مدل‌های کوچک (E2B/E4B) حتی صدا و ویدیو رو هم هندل می‌کنن ### عملکرد خیره‌کننده: - مدل ۳۱B در Arena AI رتبه ۳ جهانی (ELO ۱۴۵۲) - ریاضی AIME ۲۰۲۶: ۸۹.۲٪ (در مقابل ۲۰.۸٪ جما ۳) - کدینگ LiveCodeBench: ۸۰٪ - MMMU Pro (چندوجهی): ۷۶.۹٪ جما ۴ از جما ۳ در همه بنچمارک‌ها جهش عظیم داشته و حالا هوش واقعی روی دستگاه خودت در دسترسه — آفلاین، سریع و خصوصی.

۱. پادشاهی روی کارت گرافیک‌های گیمینگ (Qwen3.5-35B-A3B) این مدل به نظرم جذاب‌ترین بخش این ریلیز هست. معماری Mixture of Experts (MoE) اینجا شاهکار کرده. • نکته فنی: مدل سایز کلی 35B داره اما فقط حدود 3B پارامتر در لحظه (Active) فعال میشن. • کاربرد عملی: یعنی شما دانش یه مدل 35B رو دارید، اما سرعت Inference و تاخیر (Latency) در حد یه مدل 3B هست. • سخت‌افزار: این مدل راحت روی ۲۴ گیگ VRAM (مثل RTX 3090/4090) حتی با Quantization سبک بالا میاد. توی جدول MMLU-Pro نمره 84.5 گرفته که از GPT-5 mini (نسخه کلوزد) بالاتره. برای Agent هایی که روی لوکال ران می‌شن، این بهترین گزینست. ۲. مدل Dense برای کدنویسی (Qwen3.5-27B) چرا وقتی MoE هست، هنوز Dense می‌سازن؟ جواب تو پایداریه. • مدل 27B Dense توی بنچمارک SWE-bench Verified نمره 72.4 رو گرفته که از نسخه 35B MoE (با نمره 71.0) بالاتره. • تجربه من: برای تسک‌های Coding و Reasoning طولانی که Context Switching زیاد دارن، مدل‌های Dense هنوز Stableتر عمل می‌کنن و کمتر دچار Hallucination توی لاجیک‌های تو در تو میشن. اگه سیستم تک GPU دارید و کارتون فقط کده، این گزینه منطقی‌تریه. ۳. هیولای ورک‌استیشن (Qwen3.5-122B-A10B) این مدل عملاً Bridge بین مدل‌های لوکال و Frontier Models (مثل Claude Sonnet 4.5) هست. • با 122B پارامتر و 10B اکتیو، نیاز به ستاپ Multi-GPU داره (مثلاً دو تا A6000 یا ۴ تا 3090/4090). • توی GPQA Diamond نمره 86.6 رو زده که تنه به تنه مدل‌های اختصاصی میزنه. برای کارهای Multimodal سنگین و Vision Reasoning پیچیده، این مدل الان سقفِ Open-Weights محسوب میشه. ۴. مقایسه با رقبا (GPT-5 mini & Claude) طبق چارت‌ها، Qwen 3.5 توی اکثر بنچمارک‌ها (HMMT, MMMU) داره با فاصله کمی از Claude Sonnet 4.5 و GPT-oss-120b حرکت می‌کنه و گاهی جلو میزنه. • نکته ترسناک: فاصله بین مدل‌های Open و Closed (پولی) به حداقل رسیده. الان دیگه "دسترسی به مدل" مزیت نیست، "نحوه استفاده و Fine-tune" مزیت رقابتیه. جمع‌بندی فنی: به نظر من، دوران طلایی Local Agents شروع شده. وقتی می‌تونید روی لپ‌تاپ یا یه سرور خونگی مدلی ران کنید که Reasoning در سطح GPT-4o پارسال رو با سرعت ۱۰ برابر بهتون میده، یعنی معماری نرم‌افزارها باید عوض بشه. تمرکزتون رو بذارید روی Orchestration و Tool-use، چون خود مدل دیگه Bottleneck نیست. اگه سیستم خونگی قوی دارید، نسخه 35B-A3B رو حتما تست کنید؛ تعادل عجیبی بین سرعت و شعور داره. 🛠 Join @LLMEngineers Community

تحلیل معماری Qwen 3.5: خداحافظی با Brute-Force Scaling تیم Qwen با سری ۳.۵ نشون داد که دوران صرفاً اضافه کردن لایه و پارامتر تموم شده. زیر کاپوت این مدل‌ها تغییرات معماری سنگینی اتفاق افتاده که باعث شده مدل ۳۵ میلیاردی (با ۳ میلیارد پارامتر فعال) بتونه مدل ۲۳۵ میلیاردی نسل قبل رو توی جیبش بذاره. بیاید فنی بررسی کنیم. نوآوری در معماری: Hybrid Attention معماری این مدل‌ها دیگه Pure Transformer کلاسیک نیست. از ترکیب Gated DeltaNet و Gated Attention استفاده کردن. بلوک‌ها به صورت ترکیبی چیده شدن (مثلاً توی 35B، پترن به صورت ۳ تا DeltaNet و بعد ۱ دونه Attention تکرار میشه). اینکار باعث میشه سربار حافظه (KV Cache) توی Contextهای طولانی به شدت کاهش پیدا کنه و Throughput و درنتیجه سرعت پاسخگویی بره بالا، بدون اینکه دقت مدل توی Retrieval افت کنه. مکانیزم Mixture-of-Experts (MoE) در مدل‌های 35B و 122B از ۲۵۶ اکسپرت استفاده شده که برای هر توکن، ۸ اکسپرت روتینگ میشن + ۱ اکسپرت اشتراکی. این یعنی Sparsity بسیار بالا. توی مدل 122B عملاً دارید با هزینه محاسباتی یه مدل ۱۰ میلیاردی، خروجی یه مدل ۱۰۰+ میلیاردی می‌گیرید. برخلاف مدل‌های قبلی مثل Next-80B، اینجا Routing بسیار هوشمندتر شده و Expertها تخصصی‌تر عمل می‌کنن. قابلیت Multi-token Prediction (MTP) مدل آموزش دیده که چند توکن آینده رو پیش‌بینی کنه، نه فقط یکی. این تکنیک هم سرعت Inference رو بالا میبره و هم توانایی Reasoning رو تقویت می‌کنه چون مدل مجبور میشه "جلوتر" رو ببینه. پایپ‌لاین آموزشی: RL روی میلیون‌ها ایجنت برخلاف روش‌های سنتی SFT، اینجا تمرکز روی RL مقیاس‌‌پذیر بوده. مدل‌ها توی محیط‌های شبیه‌سازی شده با میلیون‌ها ایجنت تعامل کردن. این یعنی توانایی Tool Use، پلن‌چینی و Search توی این مدل‌ها "حفظیات" نیست، بلکه حاصل تعامل توی محیط‌های پیچیده است. به همین دلیله که توی بنچمارک‌هایی مثل BFCL و Tool-Use، مدل‌های Closed Source رو اذیت می‌کنن. ویژن و Multimodal از تکنیک Early-fusion استفاده شده. دیگه Vision Encoder جدا نیست که به مدل متنی چسبونده باشن؛ توکن‌های تصویری و ویدیویی از لایه‌های ابتدایی با متن ترکیب میشن. نتیجه‌ش میشه درک Native از ویدیو و تصاویر بدون از دست دادن جزئیات. نکات دیپلوی (Production Notes): برای پرفرمنس ماکزیمم، حتماً از SGLang یا vLLM استفاده کنید چون معماری Hybrid Attention و MTP رو کامل ساپورت می‌کنن. برای Thinking Mode، دمای (Temperature) رو روی ۱.۰ و top_p رو روی ۰.۹۵ بذارید. نسخه‌های GGUF (مثل IQ4_XS) روی سخت‌افزارهای محدود عملکرد پایداری دارن و Quality Degradation کمی نشون دادن. به نظر من این سری، تعریف جدیدی از Efficiency Frontier هست و نشون میده که بهینه‌سازی معماری و کیفیت دیتا، خیلی مهم‌تر از تعداد پارامتر خام هست. 📃 داکیومنت فنی و بنچمارک‌ها: https://qwenlm.github.io/blog/qwen3.5-medium/ 🛠 Join @LLMEngineers Community

معرفی سری Qwen 3.5 Medium اگه دنبال اجرای مدل‌های سطح بالا روی سیستم خودتون هستید و از حجم‌های عجیب‌وغریب خسته شدید، تیم Qwen دیروز سری جدید Medium رو ریلیز کرد که بازی رو عوض کرده. شعار این سری "هوش بیشتر، محاسبات کمتر" هست و تمرکز کاملاً رفته روی معماری بهینه، کیفیت دیتا و RL سنگین برای ایجنت‌ها. نکته جذاب ماجرا اینه که این مدل‌ها صرفاً متنی نیستن؛ به صورت Native قابلیت‌های Multimodal (تصویر و ویدیو) دارن و قابلیت Thinking Modeداخلشون تعبیه شده که می‌تونید روشن یا خاموشش کنید. مدل‌های اصلی این خانواده: مدل Qwen3.5-35B-A3B (MoE): ستاره‌ی این ریلیز. کلاً ۳۵ میلیارد پارامتر داره اما برای هر توکن فقط ۳ میلیاردش فعال میشه. به نظر من این مدل "Value King" جدید دنیای اپن‌سورسه. روی یه سیستم با ۲۴ گیگ رم (یا مک‌بوک) به راحتی اجرا میشه و طبق بنچمارک‌ها، مدل قبلی و غول‌پیکر Qwen3-235B رو شکست میده. خوراکِ کارهای لوکال و سیستم‌های با منابع محدوده. مدل Qwen3.5-122B-A10B (MoE): پل ارتباطی به مدل‌های Frontier. با ۱۲۲ میلیارد پارامتر (۱۰ میلیارد فعال)، فاصله‌ی کمی با مدل‌های بسته مثل GPT-5-mini داره، مخصوصاً توی سناریوهای پیچیده Agentic و Reasoning. اگر ستاپ Multi-GPU دارید، این گزینه برای پروداکشن عالیه. مدل Qwen3.5-27B (Dense): یه مدل کلاسیک و متراکم (Non-MoE). توی کارهای کدنویسی و Long-Context عملکرد عجیب و غریبی داره و گاهی حتی برادران MoE خودش رو هم میزنه. چون Dense هست، پایداری بیشتری توی Instruction Following داره. چرا این ریلیز مهمه؟ همه مدل‌ها لایسنس Apache 2.0 دارن، تا ۱ میلیون توکن Context رو ساپورت می‌کنن و توی بنچمارک‌های Coding و Agentic، مدل‌های Closed-source مثل GPT-5-mini و Claude-Sonnet-4.5 رو به چالش کشیدن (و جاهایی شکست دادن). جامعه کاربری خیلی سریع براشون GGUF ساخته و روی ابزارهایی مثل vLLM و Llama.cpp بالا میان. اگر توسعه‌دهنده هستید، الان وقتشه که کلاسترها رو بیخیال بشید و روی Edge Deviceها هوش واقعی رو تست کنید. 📃 لینک مدل‌ها در هاگینگ‌فیس: https://huggingface.co/collections/Qwen/qwen35-67bc603956d7827653603417 🛠 Join @LLMEngineers Community

بعد از لیدربورد کنکور، لازم بود یه بنچمارک جدی برای سنجش "روانیِ کلام" (Linguistic Fluency) داشته باشیم تا بفهمیم کدوم مدل مثل یه آدم حسابی فارسی حرف می‌زنه و کدوم یکی فقط کلمات رو پشت هم قطار می‌کنه. توی این لیدربورد که خودم طراحیش کردم، پارامترهایی مثل رعایت قواعد دستوری، لحن طبیعی (Naturalness) و اصطلاحات (Idiomatic) رو با داوری Gemini 2.5 Flash سنجیدم تا عمقِ فهم زبانی مدل‌ها مشخص بشه. معماری MoE در مدل Qwen3-30B-A3B باز هم صدرنشین شد. این مدل با امتیاز ۴۲.۱ نشون داد که توی "پیروی از دستورات" (Instruction Following) و "حفظ کانتکست" فوق‌العاده عمل می‌کنه. با اینکه توی بخش گرامر از مدل‌های گوگل ضعیف‌تره، ولی توی خروجی نهایی، پکیج کامل‌تری برای بیزنس و چت‌بات‌های فارسی ارائه میده. گوگل با Gemini 2.5 و خانواده Gemma 3 توی "گرامر" و "طبیعی بودن" (Naturalness) امتیازات بالایی گرفتن، اما توی "ایمنی" (Safety) و "پیروی از محدودیت‌های پرامپت" (Instruction Following) قافیه رو به Qwen و Saba باختن. این یه نکته سینیوریه: مدل‌های گوگل خیلی "کتابی" و تمیز حرف می‌زنن، اما وقتی بهشون دستور میدی که با یه لحن خاص یا محدودیت خاص بنویسن، انعطاف‌شون کمتر میشه. به نظر من، اگه اولویت شما "لحن طبیعی" و "حفظ کانتکست" در مکالمات فارسیه، Qwen3 بهترین خروجی رو بهتون میده. گوگل برای ویراستاری و چک کردن گرامر عالیه، اما برای یه دیالوگِ روون که کاربر حس نکنه داره با ربات حرف می‌زنه، هنوز مدل‌های MoE و تیون‌شده روی دیتای فارسی جلوترن. 🏆 لیدربورد روانی کلام فارسی (Persian Linguistic Fluency): https://huggingface.co/spaces/mshojaei77/Persian-linguistic-llm-leaderboard 🛠 Join @LLMEngineers Community