تصور کنید برنامهنویسی هستید که میخواهد یک باگ ورود به سیستم را در پروژهای زنده رفع کند؛ مدلهای زبانی فعلی میتوانند کد اصلاحشده را پیشنهاد دهند، اما چون «بدنی» ندارند، نمیتوانند فایلی را بخوانند یا تستی را اجرا کنند. دیپسیک (DeepSeek) برای پر کردن این شکاف، «مغز» (مدل) را از «هارنس» (Harness) یا همان محیط زماناجرا جدا کرده است. این تمایز دقیق در یک تحلیل فنی که در ۲۰ اوت ۲۰۲۶ منتشر شد، به تفصیل شرح داده شده است.
طبق گزارش وبسایت dev.to، هدف از این رویکرد عبور از تعاملات سادهی «متن-به-متن» و رسیدن به چرخهای از مشاهده، تفکر و اقدام است. اکثر کاربران با هوش مصنوعی به عنوان یک رابط گفتگو میشناسند که در آن یک پرامپت منجر به یک پاسخ میشود. اما این الگو در کاربردهای واقعی شکست میخورد؛ زیرا تعامل با محیط را ندارد. در حالی که یک مدل میتواند درباره یک مسئله استدلال کند، اما بدون یک سیستم خارجی برای اجرای دستورات و بازگرداندن بازخورد، نمیتواند به طور مستقل تأیید کند که آیا راهکارش کار میکند یا خیر.
به همین دلیل، صنعت به سمت فرمول «عامل = مدل + هارنس» حرکت میکند. اگر مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — مغز سیستم باشد، هارنس نقش سیستم عصبی، اندامهای حسی و عملگرهای حرکتی را ایفا میکند. بدون این لایه، دستور «اجرای pytest» برای مدل تنها یک رشته متنی است، نه یک فرمان عملیاتی. همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، جداسازی لایهی استدلال از لایهی اجرا، کلید دستیابی به پایداری در سیستمهای پیچیده است.
به گزارش وبسایت dev.to، هارنس مدیریت چرخهی حیاتی «زمینه $
ightarrow$ مدل $
ightarrow$ اقدام $
ightarrow$ محیط $
ightarrow$ مشاهده $
ightarrow$ بهروزرسانی زمینه» را بر عهده دارد. این سیستم کارهای سنگینی را انجام میدهد که مدل به تنهایی قادر به انجام آنها نیست:
- مدیریت ابزار: هارنس فراخوانیهای واقعی API، عملیات روی فایلها یا جستوجوهای وب را که مدل درخواست کرده است اجرا میکند و خطاهای حاصل از آنها را مدیریت مینماید.
- مدیریت زمینه: این لایه تصمیم میگیرد که کدام اقدامات پیشین و نتایج ابزارها برای گنجاندن در پنجره متنی (Context Window) — شبیه میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — حفظ، فشرده یا حذف شوند تا با ظرفیت مدل سازگار باشند.
- مدیریت نشست: حفظ وضعیت (State) یک وظیفه، به گونهای که یک عامل بداند پس از یک وقفه یا اختلال، از کجا باید ادامه دهد.
- کنترل اجرا: تعیین زمانهایی که کاربر باید تأییدیه ارائه دهد و زمانهایی که عامل باید متوقف شود یا یک اقدام شکستخورده را مجدداً امتحان کند.
با افزایش ابزارهای در دسترس عاملها، محیط زماناجرا معمولاً به یک ساختار یکپارچه (Monolith)، متورم و غیرقابل نگهداری تبدیل میشود. DeepSeek Harness با اتخاذ فلسفه «همه چیز یک پلاگین است»، با این مشکل مقابله میکند. این طراحی تضمین میکند که قابلیتهای جدید را بتوان بدون نیاز به تغییر در موتور اصلی زماناجرا اضافه کرد.
این معماری ماژولار باعث میشود هارنس سبک بماند و در عین حال از جریانهای کاری پیچیده پشتیبانی کند. این ساختار اجازه میدهد تا یک مدل واحد، بسته به اینکه هارنس چگونه پیکربندی شده باشد، رفتارهای کاملاً متفاوتی از خود نشان دهد؛ این موضوع ثابت میکند که محیط اجرا به اندازه پارامترهای مدل اهمیت دارد.
این چرخش، فرض بنیادی توسعه هوش مصنوعی را تغییر میدهد. گلوگاه عملکرد عاملها دیگر فقط قدرت استدلال مدل نیست، بلکه کارایی هارنس در مدیریت وضعیت و بازخوردهای ابزار است. توسعهدهندگانی که صرفاً بر مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — تمرکز میکنند، به دلیل نبود یک لایهی اجرای قدرتمند با محدودیت مواجه خواهند شد.
برای یک توسعهدهنده عملیاتی، این به معنای تغییر تمرکز از «چگونه مدل را هدایت کنیم» به «چگونه محیط را بسازیم» است. ارزش واقعی در حال انتقال از وزنهای مدل به سمت منطق ارکستراسیون سیستم است.
برای مشاهده این سیستم در عمل، باید APIهای خاص پلاگین در DeepSeek Harness را بررسی کنید تا درک کنید چگونه میتوان قابلیتهای حسی آن را برای سیستمهای فایل محلی خود گسترش داد.
گام بعدی شما
- بررسی APIهای پلاگین در DeepSeek Harness برای درک نحوه گسترش حسگرهای مدل روی سیستمهای فایل محلی.
- بازنگری در معماری عاملهای فعلی خود و جایگزینی منطقهای سختافزاری با ساختار پلاگینمحور.
- مطالعه مستندات مربوط به مدیریت وضعیت (State Management) در محیطهای زماناجرا برای کاهش توهمات مدل در وظایف طولانی.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو