«هارنس پیش از اشتراک»؛ اولویت‌بندی ساختار عملیاتی بر ارتقای مدل

اگر امروز برای دسترسی به آخرین مدل‌های گران‌قیمت هزینه می‌کنید، احتمالاً بودجه‌ی خود را دور می‌ریزید. حقیقت این است که ارتقای مدل تنها زمانی معنا پیدا می‌کند که سیستم فعلی شما بتواند وظایف را تعریف کند، سطح دسترسی‌ها را محدود سازد، وضعیت (State) را حفظ کند، نتایج را به‌دقت بررسی نماید، در صورت شکست متوقف شود و در نهایت یک رسید یا گزارش دقیق باقی بگذارد. در حالی که یک مدل قدرتمندتر ممکن است کیفیت یک اجرای واحد را بهبود ببخشد، اما این «هارنس عامل» (Agent Harness) است که باعث می‌شود اجراهای مکرر، قابل بازرسی و قابل اعتماد باشند. برای کسانی که در حال ساخت وظایف مبتنی بر هوش مصنوعی هستند، ارتقا به یک اشتراک گران‌تر اغلب یک اشتباه است اگر گردش‌کار زیربنایی هنوز تعریف نشده باشد. اگر این بخش‌های ساختاری غایب هستند، اولین سرمایه‌گذاری باید روی یک هارنس بهتر، یک قالب دقیق‌تر یا یک فرآیند عملیاتی بهین‌تر حول مدل فعلی باشد.

این تغییر در طرز تفکر درست زمانی رخ می‌دهد که صنعت از رابط‌های ساده‌ی چت به سمت گردش‌کارهای پیچیده و عامل‌محور (Agentic Workflows) حرکت می‌کند. چشم‌انداز فعلی مملو از مدل‌های قدرتمندی است که شکست می‌خورند؛ نه به دلیل فقدان قدرت استدلال، بلکه به دلیل فقدان مرزها. این چالش‌ها نشان می‌دهند که حتی پیشرفته‌ترین مدل‌ها بدون ساختار حمایتی، در رعایت محدودیت‌های سخت‌گیرانه ناتوان‌اند؛ موضوعی که در بررسی اثرگذاری چارچوب‌های قطعی بر کنترل محدودیت‌های مدل‌های پیشرو به تفصیل تحلیل شده است. برای اجتناب از هزینه‌های بیهوده، سازندگان باید بین «مغز» (مدل) و «اسکلت» (هارنس) تمایز قائل شوند. یک مدل هوش مصنوعی صرفاً پاسخ بعدی را تولید می‌کند. در مقابل، یک هارنس عامل تصمیم می‌گیرد که مدل چه زمینه‌ای (Context) دریافت کند، از کدام ابزارها می‌تواند استفاده کند، چه وضعیت‌هایی باید برای مراحل بعد باقی بمانند، در کجا تأیید انسانی الزامی است، خروجی چگونه تست می‌شود و پس از وقوع شکست چه اتفاقی می‌افتد.

زمینه فنی و شواهد

طبق یک راهنمای منتشر شده در dev.to در تاریخ ۲۸ ژوئیه ۲۰۲۶، یک هارنس از مجموعه‌ای از پرامپت‌ها، ابزارها، سیاست‌های تعیین زمینه و مسیرهای بازیابی تشکیل شده است که مدل را احاطه می‌کنند. این تعریف با نوشتاری از ادی عثمانی (Addy Osmani) در آوریل ۲۰۲۶ همسو است که در آن، هارنس به عنوان لایه‌ی ارکستراسیون و مشاهده (Observation Layer) توصیف شده است؛ لایه‌ای شامل قلاب‌ها (Hooks) و محیط‌های ایزوله (Sandboxes) که تعیین می‌کند آیا یک سیستم واقعاً برای استفاده ایمن است یا خیر.

یک پویش اکتشافی توسط Builderlog در تاریخ ۲۹ ژوئیه ۲۰۲۶ این رویکرد را تأیید می‌کند. این بررسی که از بحث‌های ردیت شروع شد و با شواهد گیت‌هاب (GitHub)، هکر نیوز (Hacker News) و یوتیوب تقویت گردید، نشان داد که کلاستر «اولویت هارنس بر مدل» شامل ۱۷ مورد شواهدی در چهار نوع منبع مختلف و ۳۴,۲۶۹ تعامل بومی ثبت شده بود. یک پست کلیدی در تاریخ ۲۲ ژوئیه ۲۰۲۶ که استدلال می‌کرد هارنس بسیار مهم‌تر از مدل است، تا لحظه‌ی بازیابی داده‌ها ۴۲ کامنت داشت. اگرچه این اعداد یک نظرسنجی جامع بازار نیستند و صرفاً جهت‌نما هستند، اما نشان‌دهنده‌ی یک استدلال فنی پایدار و مستمر در جامعه‌ی توسعه‌دهندگان است.

هزینه پیچیدگی

شواهد اخیر برجسته می‌کنند که نتایج بهتر معمولاً از سخت‌گیری ساختاری حاصل می‌شوند، نه از قدرت خام مدل. گزارشی از شرکت Anthropic در مارس ۲۰۲۶، جزئیات هارنسی را شرح داد که از نقش‌های «برنامه‌ریز»، «تولیدکننده» و «ارزیاب» با تحویل‌های ساختاریافته، تأییدیه مبتنی بر مرورگر و قراردادهای بازه زمانی (Sprint Contracts) صریح استفاده می‌کرد. چنین رویکردهایی در عمل موفقیت‌آمیز بوده‌اند، به‌طوری‌که پیاده‌سازی گردش‌های کاری ساختارمند توانسته است نرخ موفقیت عامل‌ها را از ۶۰٪ به ۹۴٪ برساند. در حالی که این ساختار نتایج کاربردی به‌مراتب بیشتری نسبت به اجرای تک‌مدلی تولید کرد، اما در یک آزمایش واحد، بیش از ۲۰ برابر گران‌تر بود.

به همین ترتیب، مقاله‌ی ژوئیه ۲۰۲۶ پروژه‌ی Harness Handbook استدلال می‌کند که رفتار واقعی یک سیستم در میان پرامپت‌ها، بسته‌بندی ابزارها (Tool Wrappers)، مجوزها، وضعیت، اجرای سندباکس و مسیرهای جایگزین توزیع شده است. صرفاً نام یک مدل نمی‌تواند تضمین کند که آیا سیستم پیش از حذف یک فایل اجازه می‌گیرد یا اینکه چگونه پس از یک استثنای فنی (Technical Exception) خود را بازیابی می‌کند.

قانون خرید برای مبتدیان

برای یک فرد مبتدی، ترتیب پیش‌فرض عملیات باید به این صورت باشد: یک وظیفه تکراری با یک محصول نهایی قابل مشاهده انتخاب کنید، کوچک‌ترین هارنس ایمنی که می‌تواند آن را اجرا کند بسازید، وظیفه را سه بار تکرار کرده و شکست‌ها را ثبت کنید و تنها زمانی مدل را ارتقا دهید که محدودیت‌های یکسان مدل در هر سه اجرا مانع از پیشرفت شود. این یک «قانون خرید» است و نه یک بنچ‌مارک؛ این قانون ادعا نمی‌کند که محصول خاصی لزوماً در زمان یا هزینه صرفه‌جویی می‌کند، بلکه متدی برای تصمیم‌گیری است.

برای تعیین گلوگاه، کاربران می‌توانند از یک کارت امتیازی ۱۴ امتیازی استفاده کنند. به هر دسته‌بندی ۰، ۱ یا ۲ امتیاز اختصاص دهید:

• وظیفه (Task): (۰) «کمک در امور کسب‌وکار»؛ (۱) وظیفه‌ای نام‌دار اما با پایان مبهم؛ (۲) یک ماشه (Trigger) و یک محصول نهایی صریح.
• زمینه (Context): (۰) چت‌های مخلوط یا یادداشت‌های قدیمی؛ (۱) بخشی از مطالب تأییدشده جدا شده‌اند؛ (۲) منابع دقیق، نسخه‌ها و موارد حذفی ثبت شده‌اند.
• اتحادیه/دسترسی (Authority): (۰) عامل می‌تواند ارسال کند، پرداخت کند یا حذف نماید؛ (۱) تأییدیه‌ها وجود دارند اما دامنه آن‌ها گسترده است؛ (۲) هر اقدام دارای امتیاز بالا دارای یک گیت (Gate) دقیق است.
• وضعیت (State): (۰) پیشرفت تنها در فضای چت زنده است؛ (۱) فایل‌ها وجود دارند اما ادامه‌ی کار غیررسمی است؛ (۲) وضعیت، گام بعدی، مالک و نسخه پس از ری‌استارت باقی می‌مانند.
• تأییدیه (Verification): (۰) عامل تولیدکننده می‌گوید نتیجه خوب به نظر می‌رسد؛ (۱) انسان به صورت غیررسمی بررسی می‌کند؛ (۲) چک‌های پذیرش یا یک ارزیاب مستقل می‌توانند نتیجه را رد کنند.
• بازیابی (Recovery): (۰) تکرار تا زمان موفقیت؛ (۱) جایگزین دستی وجود دارد؛ (۲) حد تکرار، شرط توقف، بازگشت به حالت قبل (Rollback) و مالک ارجاع صریح هستند.
• رسید (Receipt): (۰) هیچ رکورد پایداری نیست؛ (۱) لاگ وجود دارد اما زمینه تصمیم‌گیری حذف شده است؛ (۲) مرجع ورودی، اقدام، نتیجه، بازبین، هزینه و استثنائات ثبت شده‌اند.

مجموع امتیازات را محافظه‌کارانه تفسیر کنید: ۰ تا ۵ امتیاز یعنی شما هنوز نباید مدل دیگری بخرید؛ ابتدا فرآیند دستی را تعریف کنید. ۶ تا ۱۰ امتیاز پیشنهاد می‌کند که هارنس را مورد به مورد بر اساس چک‌های شکست‌خورده بهبود بخشید. ۱۱ تا ۱۴ امتیاز به این معناست که باید سه آزمایش مقایسه‌ای انجام دهید و سپس به ارتقای مدل فکر کنید.

چه زمانی واقعاً ارتقا کنیم؟

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

مثال‌هایی از گلوگاه‌های واقعی مدل عبارتند از: مدلی که مکرراً روابط در یک سند طولانی تأیید شده را تشخیص نمی‌دهد، شکست در یک وظیفه کدنویسی پس از دریافت زمینه صحیح مخزن (Repository) و تست‌ها، یا تولید آثار بصری غیرقابل استفاده در برابر یک روباریک (Rubric) نمره‌دهی concrete. جمله‌ی «پاسخ ضعیف به نظر می‌رسید» کافی نیست؛ شما باید نام دقیق چک پذیرش شکست‌خورده را ذکر کنید.

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

هارنس حداقلی قابل پذیرش (MVH)

یک هارنس اولیه نیازی به ده عامل مختلف ندارد. این سیستم به هفت قطعه قابل رؤیت نیاز دارد:
۱. یک قرارداد وظیفه
۲. یک پوشه منابع تأییدشده
۳. یک مجری (Executor)
۴. یک گیت تأیید انسانی
۵. یک چک‌لیست پذیرش
۶. یک قانون تکرار و توقف
۷. یک رسید تکمیل

افزودن یک ارکستراتور تنها زمانی ضروری است که گردش‌کار دارای شاخه‌های واقعی یا چندین مالک باشد. عامل‌های موازی نیز تنها زمانی باید اضافه شوند که کارهای مستقل قابل ادغام و بررسی باشند. پیچیدگی هزینه‌ای است که اغلب بر مزایای آن می‌چربد. در واقع، اهمیت این نظارت انسانی در نقاط حساس ساختار، تا حد زیادی مؤثر است؛ همان‌طور که تحلیل گردش‌کار درlead-generation نشان داد نظارت انسانی نرخ شکست را در مراحل حساس کاهش می‌دهد.

پیاده‌سازی و محدودیت‌ها

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

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

به کاربران هشدار داده می‌شود که در طول این مرحله تست، دسترسی زنده به حساب‌ها (Live Account Authority) را اعطا نکنند. از داده‌های عمومی، تخیلی، سانسور شده یا صراحتاً تأیید شده استفاده کنید. برای شروع، یک قرارداد تست بنویسید که شامل موارد زیر باشد: ماشه، منابع تأیید شده، محصول نهایی، چک‌های پذیرش، اقدامات خارجی (که باید هیچ باشد)، بازبین انسانی، حداکثر تلاش‌ها، حداکثر هزینه، شرط توقف، جایگزین دستی و مکان رسید. وظیفه را سه بار با مدل فعلی اجرا کنید. ثبت کنید کدام شکست‌ها تکرار شدند و آیا شکست به دلیل دانش، دستورالعمل‌ها یا محیط بود. هر بار تنها یک متغیر را تغییر دهید؛ اگر مدل و پرامپت‌ها را با هم تغییر دهید، نمی‌توانید تشخیص دهید چه چیزی باعث رفع خطا شده است.

گام بعدی شما

• برای یکی از کارهای تکراری هفته‌تان، یک «قرارداد وظیفه» شامل ورودی، خروجی و شرط پذیرش بنویسید.
• امتیازدهی ۱۴ امتیازی بالا را روی گردش‌کار فعلی خود اجرا کنید تا نقطه شکست را بیابید.
• پیش از خرید اشتراک مدل جدید، سه اجرای مشابه با مدل فعلی انجام داده و دلیل شکست‌ها را دسته‌بندی کنید.

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