¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
LLM Engineers
Ir al canal en Telegram
A highly technical blog tailored for LLM engineers. Contact me: linkedin.com/in/mshojaei77
Mostrar más2 004
Suscriptores
+5224 horas
+1127 días
+10530 días
Carga de datos en curso...
Canales Similares
Sin datos
¿Algún problema? Por favor, actualice la página o contacte a nuestro gerente de soporte.
Nube de Etiquetas
Menciones Entrantes y Salientes
---
---
---
---
---
---
Atraer Suscriptores
junio '26
junio '26
+117
en 1 canales
mayo '26
+17
en 0 canales
Get PRO
abril '26
+37
en 1 canales
Get PRO
marzo '26
+7
en 0 canales
Get PRO
febrero '26
+30
en 0 canales
Get PRO
enero '26
+21
en 0 canales
Get PRO
diciembre '25
+259
en 0 canales
Get PRO
noviembre '25
+83
en 1 canales
Get PRO
octubre '25
+51
en 0 canales
Get PRO
septiembre '25
+1 437
en 1 canales
Get PRO
agosto '250
en 6 canales
Get PRO
julio '25
+116
en 3 canales
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 12 junio | +1 | |||
| 11 junio | +52 | |||
| 10 junio | +3 | |||
| 09 junio | +2 | |||
| 08 junio | +5 | |||
| 07 junio | +48 | |||
| 06 junio | +1 | |||
| 05 junio | +2 | |||
| 04 junio | +1 | |||
| 03 junio | +1 | |||
| 02 junio | 0 | |||
| 01 junio | +1 |
Publicaciones del Canal
هرمس ایجنت (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| 2 | مفهوم 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 | 460 |
| 3 | معماری 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 | 558 |
| 4 | مفهوم 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 | 711 |
| 5 | دوران تولید توکن به توکن (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 | 748 |
| 6 | خانواده مدلهای 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 | 746 |
| 7 | خلاصه وضعیت فریمورکهای ساخت 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 استفاده میکنید؟ نظر خود را بنویسید 👇 | 2 070 |
| 8 |  Sin texto... | 0 |
| 9 |  Sin texto... | 0 |
| 10 |  Sin texto... | 0 |
| 11 |  Sin texto... | 0 |
| 12 | 🚀 موج جدید مدلهای هوش مصنوعی متنباز (فوریه تا آوریل ۲۰۲۶)
در این دو ماه، شرکتهای بزرگ جهان مدلهای قدرتمند متنباز زیادی منتشر کردند. خلاصه لیست کامل:
✅ 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 هستند (استفاده تجاری آزاد). | 0 |
| 13 | ✅ جما ۴ (Gemma 4) رسماً منتشر شد! 🚀
گوگل دیپمایند بالاخره جما ۴ رو رونمایی کرد — قدرتمندترین مدلهای متنباز تا امروز، با قابلیتهای چندوجهی (تصویر + صدا + ویدیو) و اجرای محلی روی گوشی و دستگاههای کوچک.
### ویژگیهای کلیدی:
- ۴ سایز مختلف: از E2B (مناسب گوشی و راسپبری پای) تا ۳۱B Dense
- لایسنس Apache 2.0 — کاملاً آزاد برای استفاده تجاری، بدون محدودیت!
- حالت Thinking برای استدلال گامبهگام
- زمینه تا ۲۵۶K توکن
- پشتیبانی از **۱۴۰+ زبان**، function calling و agentic workflows
- مدلهای کوچک (E2B/E4B) حتی صدا و ویدیو رو هم هندل میکنن
### عملکرد خیرهکننده:
- مدل ۳۱B در Arena AI رتبه ۳ جهانی (ELO ۱۴۵۲)
- ریاضی AIME ۲۰۲۶: ۸۹.۲٪ (در مقابل ۲۰.۸٪ جما ۳)
- کدینگ LiveCodeBench: ۸۰٪
- MMMU Pro (چندوجهی): ۷۶.۹٪
جما ۴ از جما ۳ در همه بنچمارکها جهش عظیم داشته و حالا هوش واقعی روی دستگاه خودت در دسترسه — آفلاین، سریع و خصوصی. | 0 |
