مفهوم Agent Harness یا Harness Engineering یکی از اون اصطلاحاتیه که این روزها زیاد شنیده می‌شه، اما چون هم خیلی کلیه و هم خیلی تخصصی، خیلیا هنوز دقیقاً نمی‌دونن چیه. در ساده‌ترین تعریف، خیلیا فکر می‌کنن Harness فقط همون محیط (Environment) اجرای ایجنت هست، اما داستان خیلی عمیق‌تر از این حرف‌هاست.

برای درک بهتر، باید مسیر تکامل تعامل با مدل‌ها رو ببینیم:

۱. سال ۲۰۲۳ و Prompt Engineering:
اوایل که ChatGPT اومد، با Context Window محدود (۴۰۹۶ توکن) درگیر بودیم. تمام تلاشمون این بود که با نوشتن پرامپت‌های بهتر، خروجی دقیق‌تری بگیریم. اما برای کارهای پیچیده اصلاً کافی نبود.

۲. سال ۲۰۲۴ و Context Engineering:
اینجا ابزارهایی مثل RAG، Tool Calling و پروتکل‌هایی مثل MCP وارد شدن. هدف این بود که کانتکست مدل رو بهتر مدیریت کنیم تا ایجنت بتونه به دیتابیس یا فایل‌های خاص دسترسی داشته باشه. اما یک مشکل بزرگ وجود داشت: وقتی تسک‌ها طولانی می‌شد (مثلاً ۱۰-۱۲ ساعت کار مداوم)، کانتکست پر می‌شد و ایجنت مجبور بود اطلاعات رو خلاصه‌سازی (Summarize) کنه. این کار باعث می‌شد جزئیات فنی گم بشه، ایجنت گیج بشه و تسک‌ها رو نصفه رها کنه.

۳. ظهور Harness Engineering:
اینجاست که مفهوم Harness وارد عمل می‌شه. Harness در واقع یک لایه‌ی Orchestration بالای سر کانتکست هست. به جای اینکه ایجنت رو توی کانتکست خودش غرق کنیم، اون رو وارد یک Loop (حلقه) منظم می‌کنیم.

ساختار کار در Harness معمولاً به این شکله:
* ابتدا یک فایل نیازمندی‌های دقیق (PRD) تولید می‌شه.
* این فایل به تسک‌های ریز در قالب JSON شکسته می‌شه.
* ایجنت در هر تکرار (Iteration) از حلقه، فقط روی یک تسک مشخص تمرکز می‌کنه.
* در شروع هر مرحله، ایجنت یک کانتکست کاملاً تازه و تمیز (Fresh Context) دریافت می‌کنه، اما با قوانین (Rules) سخت‌گیرانه‌ای که از قبل براش تعریف شده.

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

نمونه‌های عملی این رویکرد رو می‌شه توی دموی اخیر Anthropic دید. حتی Cursor با معرفی Cloud Agents و قابلیت تعریف Automation برای آپدیت خودکار کدبیس، عملاً داره به سمت Harness Engineering حرکت می‌کنه. در این حالت، شما حتی لازم نیست IDE باز باشه؛ ایجنت توی کلاود طبق تسک‌های تعریف شده کار می‌کنه، کد می‌زنه، تست می‌کنه و در نهایت Pull Request رو براتون می‌فرسته.

در واقع قدرت واقعی ایجنت‌های آینده نه فقط توی مدل قوی‌تر، بلکه توی Harness یا همون زیرساخت مدیریتی هست که ایجنت رو هدایت می‌کنه تا تسک‌های طولانی رو بدون افت کیفیت به پایان برسونه.

🛠 Join @LLMEngineers Community

نشستم ۲۲ تا ابزار کدزنی AI رو با هم مقایسه کردم... بحث سر Harness یا همون بستر اجرای مدله. یعنی اون سیستم مدیریت کانتکست و ابزارهایی که دور مدل کشیده شده.

خلاصه چندتا دسته‌بندی اصلی:
— اگه دنبال سرعت و تجربه تمیز توی ادیتوری: Cursor هنوز بی‌رقیبه.
— اگه گیک ترمینالی: Claude Code جادو می‌کنه.
— اگه کنترل کامل و دنیای متن‌باز رو می‌خوای: Cline و opencode رو حتماً تست کن.
— اگه می‌خوای تسک رو بسپری به ایجنت و بری سراغ کارای دیگه: Devin و Codex و Jules گزینه‌های اصلی‌ان.

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

لینک مقاله:
https://medium.com/@mshojaei77/i-compared-22-ai-coding-harnesses-most-developers-are-comparing-the-wrong-thing-4efb26650fcd

🛠 Join @LLMEngineers Community

بینا ۰.۱ ✨ 👀

پروژه Bina OCR رو کلاً یک هفته‌ست که استارت زدیم و امروز اولین بنچمارک واقعی رو ازش گرفتیم... نتیجه حتی برای خودمون هم غیرمنتظره بود. مدل Bina 0.1 توی تست‌های OCR فارسی جلوتر از مدل‌های بزرگی مثل Gemini 3.5 Flash قرار گرفت. البته این تازه اول مسیره و هنوز کلی باگ و کار زمین‌مونده داریم.

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

این پروژه با همکاری رضا سیار جلو رفته که قبلاً هم سیستم شنوا (ASR فارسی) رو توسعه داده بود. از اون دست به کیبوردهایی که کمتر حرف می‌زنن و بیشتر کد می‌زنن. (اسپویلر: پروژه بعدی هم قراره tts فارسی باشه)

واقعیت فنی اینه که ساختن یه مدل خوب، بیشتر از اینکه درگیر بازی با معماری و مدل‌های عجیب‌وغریب باشه، لنگِ داده‌ست. برای اینکه نسخه‌های بعدی Bina OCR بتونن کارهای سخت‌تر رو انجام بدن به چندتا چیز نیاز مبرم داریم: داده‌های متنوع‌تر، اسناد واقعی‌تر، دستخط‌های نامرتب و البته قدرت پردازش (compute) برای آموزش و تست.

اگر حوزه اپن‌سورس و ابزارهای پایه برای فارسی براتون دغدغه‌ست، می‌تونید توی توسعه این زیرساخت کمک کنید. فرقی نداره با به اشتراک گذاشتن داده‌های متنی و تصویری، کمک فنی به توسعه، معرفی پروژه یا حتی حمایت مالی برای هزینه‌های سنگین labeling و اجاره GPU. هدف اینه که کامیونیتی اوپن سورس فارسی پیشرفت کنه

نسخه اولیه مدل :
https://huggingface.co/Reza2kn/Bina-0.1
کامیونیتی تلگرام پروژه :
https://t.me/bina_ocr


🛠 Join @LLMEngineers Community

براساس این بنچمارک ما که دارای ۶,۶۶۹ خط متن تایپی و ۶,۶۶۹ صفحه متن دست نویس هست: بینا ۰.۱ در حال حاضر بهترین مدل تشخیص متن فارسی تایپی و دست نویسه! 🔥🔥

پروژه OpenBench v1 برای ارزیابی و بنچمارک دقیق ایجنت‌های کدنویسی منتشر شد... ابزاری متن‌باز که روی مقایسه و سنجش harnessها تمرکز داره.

اکثر تیم‌ها تمام تمرکز رو روی انتخاب مدل گذاشتن - اما یک ایجنت کدنویسی حاصل ترکیب مدل و harness است؛ یعنی همون ابزارهای جانبی، پرامپت‌ها، دسترسی‌ها و سیستم مدیریت اجرای اطراف مدل. وقتی مدل یکسان باشه (مثلاً gpt-5.6)، تغییر دادن harness از cursor به codex، claude یا devin می‌تونه درصد موفقیت و هزینه‌ها رو کلاً تغییر بده.

معیارهای سنجش توی این فریم‌ورک روی سه محور اصلی میچرخه: درصد درستی (correctness)، میزان مصرف token (ورودی، خروجی و cache) و تاخیر زمانی (latency)... ارزیابی‌ها هم داخل کانتینرهای ایزوله Docker اجرا میشن و صحت کد با اسکریپت‌های checker مستقل ارزیابی میشه، نه ادعای خود ایجنت.

https://github.com/minghinmatthewlam/openbench

🛠 Join @LLMEngineers Community

Explain what happens when your input exceeds the context window?

Find out what you can’t do…

امروز داشتم پیپر SkillOpt رو می‌خوندم که مایکروسافت منتشر کرده. یه ایده کاربردی برای وقت‌هایی که به وزن‌های مدل دسترسی نداریم یا تغییر دادنشون گرونه.

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

ایده اصلی این پیپر اینه که فایل متنی SKILL.md رو مثل یه متغیر قابل آموزش توی شبکه‌های عصبی در نظر بگیریم. مدل اصلی کاملا ثابت می‌مونه و یه مدل دیگه به عنوان بهینه‌ساز، فقط روی همون متن کار می‌کنه.

سازوکارش دقیقا از مفاهیم یادگیری عمیق الگو برداشته، ولی روی فضای متن:
- اول مدل روی یه دسته از تسک ها کار میکنه تا خروجی‌های درست و غلط جمع بشن.
- مدل بهینه‌ساز، الگوهای تکراریِ شکست و موفقیت رو تحلیل می‌کنه.
- به جای اینکه کل متن رو از نو بنویسه، فقط بخش‌های خاصی رو اضافه یا جایگزین می‌کنه. این سقف تعداد تغییرات مجاز، اینجا دقیقا کارکرد نرخ یادگیری رو داره تا متن یهو به هم نریزه.
- تغییرات روی یه دیتاسِت جداگانه تست می‌شن. فقط اگه امتیاز واقعا بهتر بشه، تغییر روی فایل نهایی اعمال می‌شه.
- اگه تغییری امتیاز رو کم کنه، میره تو یه حافظه موقت تا مدل دوباره همون اشتباه رو برای ویرایش‌های بعدی تکرار نکنه.

نتایج تست‌ها روی شش تا بنچمارک مختلف (از پرسش‌وپاسخ تا کار با فایل‌های اکسل) و هفت تا مدل (از نسخه‌های جی‌پی‌تی ۵.۵ تا qwen) نشون میده که این روش به شدت خوب کار می‌کنه.
- روی جی‌پی‌تی ۵.۵، میانگین دقت رو حدود ۲۳.۵ درصد نسبت به حالت بدون دستورالعمل بالا برده.
- خروجی نهایی بعد از همه این کارها، فقط یه فایل متنی کوچیک بین ۳۰۰ تا ۲۰۰۰ توکنه.
- دستورالعملی که برای یه مدل قوی بهینه شده، به طرز عجیبی روی مدل‌های کوچیک‌تر هم جواب می‌ده و قابل انتقاله.

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

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

🛠 Join @LLMEngineers Community

مدل جدید کیمی K3 کلاً قضیه مدل‌های متن‌باز رو وارد یه مرحله جدید کرده... یه مدل غول‌پیکر با ۲.۸ تریلیون پارامتر کل که موقع جواب دادن به هر کلمه، ۱۰۴ میلیارد پارامترش فعال می‌شن و تا ۱ میلیون توکن متن یا تصویر رو هم‌زمان پردازش می‌کنه.

سازنده‌هاش تونستن بازدهی آموزش مدل رو نسبت به نسل قبل ۲.۵ برابر بهتر کنن. خلاصه تغییرات مهمش ایناست:

- ترکیب هوشمندانه توجه (Hybrid Attention):
برای اینکه موقع خواندن متن‌های خیلی طولانی حافظه کارت گرافیک پر نشه، ۳ لایه از یک مکانیزم سبک و سریع خطی با نام Kimi Delta Attention استفاده کردن و بعد ۱ لایه توجه کامل با نام Gated MLA گذاشتن. این ترکیب باعث می‌شه مدل متن‌های طولانی رو بدون کند شدن بفهمه.

- برداشت هوشمند از لایه‌های قبلی (Attention Residuals):
توی مدل‌های قدیمی، هر لایه فقط اطلاعات لایه قبلی خودش رو می‌گرفت. اینجا هر لایه می‌تونه برگرده و بر اساس نیاز از اطلاعات لایه‌های خیلی عقب‌تر هم استفاده کنه تا مفاهیم پیچیده رو فراموش نکنه.

- تقسیم کار بین ۸۹۶ کارشناس کوچک (MoE):
به جای یک شبکه یک‌دست، مدل از ۸۹۶ کارشناس تخصصی کوچک تشکیل شده که برای هر کلمه فقط ۱۶ تاشون انتخاب می‌شن. با یک روش ریاضی جدید به اسم Quantile Balancing کاری کردن که بار پردازشی کاملاً مساوی تقسیم بشه و هیچ کارشناسی بی‌کار نمونه.

- پردازش تصویر بومی بدون مدل کمکی (MoonViT-V2):
بخش فهم تصویر مدل از همون روز اول همراه با متن آموزش دیده؛ برعکس مدل‌های دیگه که یک مدل تصویربردار آماده رو به متن وصل می‌کردن. این کار پایداری مدل رو موقع یادگیری خیلی بالاتر برده.

چرا این مدل مهمه؟
- توی تست‌های کدنویسی و هوش خودکار (مثل چرخیدن توی وب و انجام کارهای چندمرحله‌ای) پا‌به‌پای قوی‌ترین مدل‌های تجاری مثل Claude Fable 5 و GPT-5.6 Sol می‌اد.
- نمره ۹۳.۵٪ توی آزمون دانش و استدلال GPQA Diamond گرفته.
- هزینه‌ی اجرایی هر درخواستش حدود یک‌سوم مدل‌های تجاری مشابه هست.

نقطه ضعفش کجاست؟
توی استدلال‌های خیلی پیچیده در سطح تحقیقات علمی (مثل بنچمارک CritPt با نمره ۲۳.۴٪) هنوز عقب‌تر از مدل‌های تجاری قوی می‌افته که نشون می‌ده مدل‌های متن‌باز توی استدلال عمیق هنوز جای کار دارن.
https://github.com/MoonshotAI/Kimi-K3/blob/main/k3_tech_report.pdf

🛠 Join @LLMEngineers Community

یه مجموعه اسکیل رو به صورت ازمایشی ساختم تا فرآیند Spec-Driven Development رو توی ابزارهای کدنویسی پیاده کنیم... ایده اصلی اینه که جلوی گیج شدن coding agentها و گم شدن تصمیمات معماری رو بگیریم.

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

توی روش SDD همه‌چیز بر پایه فایل‌های متنی جلو می‌ره تا یک قرارداد پایدار بین آدم و agent وجود داشته باشه... به جای حرف زدن خالی، مراحل به خروجی‌های مشخص تبدیل می‌شه.

چند تا skill براش تعریف کردم:

- اسکیل sdd-harness: مشخص می‌کنه که هر task چقدر سخت‌گیری و سندسازی لازم داره تا تعادل بین سرعت و دقت حفظ بشه.

- اسکیل sdd-feature: کار رو به چهار بخش spec.md (چی می‌خوایم)، design.md (چطور پیاده بشه)، tasks.md (لیست کارها) و verification.md (مدارک اثبات) تقسیم می‌کنه.

- اسکیل sdd-review: یک مرحله ارزیابی مستقل قبل از merge یا release که کورکورانه به خروجی agent اعتماد نمی‌کنه.

نکته مهم: هنوز خودم این workflowها و skillها رو توی پروژه‌های واقعی و سنگین تست نکردم... همه‌چیز فعلاً در حد آزمایش و Experimental هست و ممکنه نیاز به اصلاح داشته باشه.

این ابزارها فعلاً روی محیط‌هایی مثل Claude Code، OpenAI Codex، Hermes Agent و GitHub Copilot قابل استفاده‌ست:

https://github.com/mshojaei77/sdd-agent-skills

🛠 Join @LLMEngineers Community

سلام دوستان عزیز 👋
بعد از تجربه‌ی خوبی که با Bina OCR و شنوا (ASR فارسی) داشتیم (هنوز تموم نشده)، پروژه‌ی بعدی‌مون شروع شده: ساخت یه مدل TTS فارسی متن‌باز 🎙️
یکی از بزرگ‌ترین چالش‌های TTS فارسی اینه که خط فارسی حرکت‌گذاری نمی‌شه، پس مدل باید حدس بزنه کلمه چطور تلفظ می‌شه. مثلاً «برگزاری» رو می‌شه چند جور خوند، و بدون داده‌ی درست، مدل گاهی اشتباه تلفظ می‌کنه.
برای حل این مشکل یه مینی‌گیم ساختیم که توش شما تلفظ درست کلمات رو مشخص می‌کنید. چند ثانیه وقت می‌گیره ولی داده‌ای که جمع می‌شه مستقیم می‌ره تو آموزش مدل TTS 🙏
اگه دوست دارید کمک کنید یه پروژه‌ی متن‌باز فارسی جلو بره:
👉 https://persianasr.com/Gooya-2/

هرچی مشارکت بیشتر بشه، مدل باکیفیت‌تر
می‌شه. ممنون از همراهیتون ❤️

🛠 Join @LLMEngineers Community

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

AI/ML Research Scientist
تمرکزش روی خلق ایده‌ها، معماری‌های جدید و نوشتن مقاله‌های علمیه. موفقیتش با نوآوری و آزمایش‌های تئوری سنجیده می‌شه و معمولاً مدرک دکترا یا رزومه پژوهشی خیلی قوی می‌خواد.

AI/ML Research Engineer
کارش اینه که اون ایده‌های تئوری و مقاله‌ها رو به کدهای واقعی تبدیل کنه تا بشه روشون آزمایش انجام داد. زیرساخت‌های لازم برای آموزش مدل و جمع‌آوری دیتا رو می‌سازه و بیشتر از دانشمند تحقیق، دست به کد هست.

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

Machine Learning Engineer
مسئولیتش اینه که مدل رو به یه نرم‌افزار پایدار و قابل استفاده برای کاربر تبدیل کنه. از مدیریت مسیرهای انتقال داده (Data Pipelines) گرفته تا مانیتورینگ و نگهداری مدل توی محیط واقعی؛ در واقع یه مهندس نرم‌افزاره که تخصصش یادگیری ماشینه.

Data Scientist
بیشتر دنبال استخراج تحلیل و آمار از داده‌هاست تا به مدیران کمک کنه تصمیم‌های بیزنسی بهتری بگیرن. برخلاف مهندس ماشین‌لرنینگ، لزوماً قرار نیست کدش وارد چرخه تولید محصول بشه.

ML/AI Platform Engineer
ابزارهای داخلی می‌سازه تا بقیه مهندس‌های همون شرکت بتونن راحت‌تر کارهای ماشین‌لرنینگی رو انجام بدن؛ مثلاً سیستم‌های خودکار برای تست مدل یا ثبت نسخه‌های مختلف مدل (Model Registry).

ML/AI Infrastructure Engineer
تمرکزش روی لایه‌های زیرساختی و سخت‌افزاریه. مدیریت سرورها، پردازش‌های موازی سنگین، خوشه‌بندی پردازنده‌ها و کلاً هر چیزی که به پایداری و مقیاس‌پذیری سیستم محاسباتی ربط داره.

ML Framework Engineer
روی هسته اصلی کتابخانه‌ها و ابزارهای پایه کار می‌کنه. مثلاً بهینه‌سازی کدهای سطح پایین برای کتابخانه‌هایی مثل PyTorch یا کار روی کامپایلرهایی که مدل رو برای اجرا روی سخت‌افزار آماده می‌کنن.

AI Hardware Engineer
کارش طراحی و بهینه‌سازی تراشه‌ها و قطعات سخت‌افزاریه که مخصوص پردازش‌های سنگین هوش مصنوعی ساخته می‌شن؛ مثل کار روی پردازنده‌های گرافیکی یا تراشه‌های مخصوص پردازش عصبی.

ML/AI Solutions Architect
قبل از پیاده‌سازی، نیاز مشتری رو بررسی می‌کنه و طراحی می‌کنه که چطور ابزارهای هوش مصنوعی باید توی سیستم‌های بزرگ مشتری جا بگیرن و با بقیه بخش‌ها کار کنن.

AI/ML Solutions Engineer
بیشتر نقش اجرایی و پشتیبانی داره. به مشتری‌ها کمک می‌کنه تا محصول رو عملاً راه بندازن، کدها رو یکپارچه کنن و اگه موقع نصب یا استفاده مشکلی پیش اومد حلش کنن.

Developer Advocate
رابط بین شرکت و جامعه برنامه‌نویس‌هاست. آموزش می‌سازه، توی کنفرانس‌ها صحبت می‌کنه و بازخوردهای توسعه‌دهنده‌ها رو به تیم محصول برمی‌گردونه تا ابزارها بهتر بشن.

خلاصه اینکه اگه دنبال اسمی هستی که به کارت بیاد، به جای عنوان، به این نگاه کن که چقدر قراره مدل بسازی، چقدر قراره زیرساخت کد بزنی و آیا اصلاً با مشتری در تماسی یا نه...

منبع: کتاب Machine Learning Interviews اثر Chip Huyen

🛠 Join @LLMEngineers Community