سیستم هارنس: کاهش ۷۵ درصدی هزینه‌های مدل‌های زبانی گران‌قیمت

اگر امروز برای استفاده از مدل‌های پیشرو هزینه پرداخت می‌کنید، احتمالاً بخش زیادی از بودجه‌ی شما صرف تکرار عملیات‌های ساده می‌شود. اسکات فرایکسل، توسعه‌دهنده‌ای که در ۲۶ اوت ۲۰۲۶ یافته‌های خود را منتشر کرد، نشان داد که چگونه می‌توان با تغییر نگاه به هوش مصنوعی از یک «ابزار چت» به یک «جزء سیستمی»، هزینه‌های استنتاج را تا ۷۵٪ کاهش داد.

او این رویکرد را «هارنس» (Harness) می‌نامد؛ محیطی ساختاریافته که تعامل عامل‌های هوش مصنوعی با کد و ابزارها را مدیریت می‌کند. این سیستم به یک توسعه‌دهنده اجازه می‌دهد تا ثبات و خروجی یک تیم مهندسی بزرگ را به‌تنهایی به دست آورد. این رویکرد با مفاهیم مشابهی در معماری DeepSeek Harness همسو است که بر مدیریت قابلیت‌های قابل تعویض در عامل‌های AI تمرکز دارد.

فرایکسل این پیشرفت را بخشی از یک روند تاریخی می‌بیند. او به یاد می‌آورد که یک توسعه‌دهنده «پیر و باسابقه» (graybeard) مشاهده کرده بود که قانون مور برای نرم‌افزارها نیز صادق است. او اشاره می‌کند که نارضایتی‌های روزمره در گذشته — مانند شکایت‌ها از J2EE، کندی Netbeans، طراحی‌های مبتنی بر جدول (table-based layouts) و نیاز به بارگذاری مجدد کامل صفحات — در واقع موتور محرک بهینه‌سازی بوده‌اند. در ۱۸ ماه گذشته، ما شاهد جهشی بی‌وقفه بوده‌ایم: تکمیل خودکار کدها (tab completions) به کدنویسی عامل‌محور تکامل یافت و اکنون این روند به مدیریت عامل‌ها از طریق یک هارنس رسیده است.

برای اکثر برنامه‌نویسان، هوش مصنوعی مجموعه‌ای از چت‌های پراکنده در مرورگر یا یک IDE است. این وضعیت باعث ایجاد وابستگی به «سس جادویی» (magic sauce) می‌شود؛ جایی که کاربر احساس می‌کند به شخصیت یا رابط کاربری یک مدل خاص زنجیر شده است. فرایکسل استدلال می‌کند که بهره‌وری واقعی زمانی رخ می‌دهد که مدل‌ها را به کالاهایی معمولی (commoditizing) تبدیل کنیم و در عوض، تمرکز خود را روی لایه‌ی ارکستراسیون یا همان مدیریت هماهنگ بگذاریم.

تصور کنید محیط هوش مصنوعی شما شبیه به یک سالن تولید در کارخانه است — به جای اینکه یک نابغه داشته باشید که همه کار انجام دهد (و اغلب گیج شود)، مجموعه‌ای از ایستگاه‌های تخصصی دارید. در اینجا «هارنس» نقش نوار نقاله و مدیری را دارد که تضمین می‌کند هر قطعه از کار، به‌درستی از یک ایستگاه به ایستگاه بعدی منتقل شود.

معماری هارنس

سیستم فرایکسل بر یک تجربه یکپارچه در سه رابط کاربری ترمینالی (TUI) شامل Cursor، Claude و Pi استوار است. این ابزارها یک فایل مرکزی به نام AGENTS.md و مجموعه‌ای از «مهارت‌های» تعریف‌شده را به اشتراک می‌گذارند. این یعنی فارغ از اینکه او از کدام رابط استفاده کند، هوش مصنوعی همیشه به یک زمینه و دستورالعمل یکسان دسترسی دارد. این ساختار اضطراب مربوط به جابجایی بین ابزارها را از بین می‌برد؛ برای مثال، او در پایان ماه می‌تواند بدون مشکل از Cursor به Codex منتقل شود.

او برای بهینه‌سازی هزینه و عملکرد، از استراتژی مدل‌های لایه‌ای (tiered model strategy) استفاده می‌کند:

• وظایف ساده و نگهداری: توسط مدل deepseek-v4-flash-0731 انجام می‌شود که مدل بسیار کارآمدی است و حجم اصلی کار را مدیریت می‌کند.
• ویژگی‌های پیچیده و بازنویسی: برای مدل‌های پیشرو (Frontier) مانند Fable (از طریق API آنتروپیک) رزرو شده است؛ یعنی جایی که استدلال سطح بالا برای ویژگی‌هایی با اجزای متحرک زیاد لازم است.

قابلیت‌ها و محیط ایزوله

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

• پشتیبانی از محیط: استفاده از سندباکس (Sandboxing) — شبیه به یک محیط آزمایشگاهی ایزوله که هر اتفاقی در آن بیفتد به سیستم اصلی آسیب نمی‌زند — در کنار یک رابط وب، File System Access API، Docker و فایل‌های اجرایی Deno.
• قابلیت حسابرسی: برای اینکه فرآیند شفاف بماند، رابط‌های کاربری (TUIs) اکیداً دستور گرفته‌اند که تمام خروجی‌های تولید شده را فقط در پوشه‌ی artifacts/ ذخیره کنند.
• یکپارچگی با Git: از آنج که Cursor از .gitignore برای نادیده گرفتن فایل‌ها استفاده می‌کند، فرایکسل از یک ریشه‌ی بدون گیت (git-less root) و یک مهارت خاص استفاده می‌کند که هارنس را با مخزن (repo) موجود در دایرکتوری کاری همگام‌سازی می‌کند.

گردش کار: برنامه‌ریز، مجری و منتقد

برای جلوگیری از اینکه هوش مصنوعی اهداف خود را فراموش کند یا با آن‌ها دچار تداخل شود، فرایکسل از سیستم تفکیک نقش‌ها بر اساس تکنیک «پیش‌گام» (Prewalk) اثر کان بولوک استفاده می‌کند. در این روش، یک مدل پیشرو برای مرحله برنامه‌ریزی و اولین وظیفه به کار می‌رود و پس از اینکه الگو (pattern) تثبیت شد، کار به مدل‌های دیگر سپرده می‌شود. او این روش را با تفکیک نقش‌های برنامه‌ریز/مجری/منتقد ترکیب کرد، زیرا یک پرامپت واحد که همزمان برنامه‌ریزی، اجرا و نقد کند، اغلب در اهداف خود گیج می‌شود.

او بار شناختی را به چهار مرحله مجزا تقسیم کرده است:

۱. برنامه‌ریز (Planner): از یک مدل پیشرو برای ایجاد یک برنامه رسمی استفاده می‌کند که در قالب یک لیست وظایف به صورت گراف جهت‌دار بدون دور (DAG) بیان می‌شود.
۲. مجری (Worker): گره‌های این گراف (DAG) را یکی‌یکی اجرا می‌کند و فقط روی پیاده‌سازی تمرکز دارد، بدون اینکه نگران معماری کلی باشد.
۳. منتقد (Critic): کد پیاده شده را بررسی می‌کند تا آن را ساده‌تر کرده و منطق آن را به چالش بکشد. این مرحله اغلب باعث ایجاد یک حلقه بازگشت به مرحله‌ی مجری برای اصلاحات می‌شود.
۴. ترویج‌کننده (Promoter): مرحله نهایی برای اطمینان از اینکه کار تکمیل شده به‌درستی برای سایر انسان‌ها مستند و اطلاع‌رسانی شده است. فرایکسل این مرحله را برای غلبه بر عادت شخصی‌اش (که سریعاً کار را تحویل دهد و بدون اطلاع‌رسانی به سراغ پروژه بعدی برود) اضافه کرد. او اشاره می‌کند که ترویج کار موضوعی ظریف است و به‌راحتی ممکن است خراب شود (borked)، بنابراین از مدل Fable برای این مرحله استفاده می‌کند تا به ارتباطات وزن بیشتری ببخشد.

به نقل از گزارش منتشر شده در scott-fryxell.github.io این دسته‌بندی دقیق و تحویل مرحله‌به‌مرحله، استفاده او از مدل گران‌قیمت Fable را حتی در دوره‌های توسعه شدید، ۷۵٪ کاهش داده است. او این وضعیت را «اشباع هوش مصنوعی» (AI soak) می‌نامد که به او اجازه می‌دهد پروژه‌های شخصی و مشتریانش را تنها با دو اشتراک ۲۰ دلاری مدیریت کند.

گسترش هارنس به محصولات

این سیستم فقط برای کدنویسی نیست و می‌تواند محصولات نرم‌افزاری واقعی را به حرکت درآورد. اپلیکیشن دوربین او که عکس‌ها را به گرافیک برداری تبدیل می‌کند، از طریق ابزاری به نام poster-driver به هارنس متصل است. این برنامه تصاویر را به لایه‌های مقدار و اشکال ساده می‌کند و جزئیات را حذف می‌کند تا کاربر بتواند دوباره در Procreate یا چاپ‌ها روی آن‌ها طراحی کند.

با اجرای برنامه در حالت Headless Chrome، مدل زبانی بزرگ (LLM) می‌تواند اپلیکیشن را به همان راحتی که یک صفحه وب را بارگذاری می‌کند، اسکریپت‌نویسی کند. این امر به هوش مصنوعی اجازه می‌دهد تا با یک دستور ساده npm، انیمیشن‌ها یا پوسترها را از فایل‌های ویدئویی تولید کند:

npm run make:animation artifacts/my-movie.mp4

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

اکتشافات خلاقانه

فراتر از اپلیکیشن دوربین، فرایکسل در حال بررسی محیط‌های سه‌بعدی پیچیده‌تر است. او در حال حاضر روی یک محیط در Blender کار می‌کند که محله‌ی او را به‌صورت سه‌بعدی بازسازی کرده و پوسترها را روی آن قرار می‌دهد. این سیستم به او اجازه می‌دهد صحنه‌ها و استوری‌بوردهایی خلق کند که بسیار فراتر از امکانات وب است. او استدلال می‌کند که افراد خلاق همچنان می‌توانند از ابزارهای غیر-AI به روشی «هوش مصنوعی‌وار» استفاده کنند تا لذت‌بخش‌ترین بخش‌های فرآیند خلاقیت حفظ شود.

محیط جدید توسعه‌دهنده

فرایکسل فضای کاری اصلی خود را از ویرایشگر به ترمینال منتقل کرده و از Ghostty و nvim استفاده می‌کند. او از هارنس به عنوان یک «جیگ» (Jig) — شبیه به قالبی که در نجاری برای تکرار دقیق یک برش استفاده می‌شود — بهره می‌برد تا مدل زبانی پیکربندی nvim او را در لحظه ویرایش کند. این کار به هوش مصنوعی اجازه می‌دهد تا به او در تسلط بر حرکات پیچیده Vim کمک کند، در حالی که او روی منطق پروژه‌هایش متمرکز می‌ماند.

ساختار دایرکتوری او برای حسابرسی دقیق طراحی شده است و تمام مصنوعات تولید شده توسط AI را در یک پوشه اختصاصی /artifacts نگه می‌دارد. ساختار به شرح زیر است:

• brayness/ (ریشه)
  • AGENTS.md و AGENTS.local.md
  • bin/, prompts/, plans/
  • skills/, extensions/, artifacts/
  • work/ (شامل realness/, blog/, brayness/, nvim/)

مهارت‌های نقشه‌برداری شده و قوس برنامه‌ریزی

او طیف گسترده‌ای از مهارت‌های نقشه‌برداری شده (mapped skills) را برای پشتیبانی از قوس برنامه‌ریزی خود توسعه داده است. این مهارت‌ها عبارتند از:

• سیستم و ابزارها: nvim-buffers, flexible-visual-system, project-tooling, brayness-sync, agent-browser.
• توسعه و طراحی: vuetify-to-semantic, rust-best-practices, realness-design, typography, user-interface, vue-inspect.
• برنامه‌ریزی و بررسی: planner, planning, memory, previous-work, critic, test-coverage, simplify, promoter.
• وظایف تخصصی: vault, interview-prep, logo-finder, hyperframes, readable, zoom-to-ableton, motion-systems.

او اشاره می‌کند که یاد گرفته است جزئیات و دقت بیش از حد در این مهارت‌ها را کاهش دهد تا از «توضیحات بدیهی برای ماشین‌ها» (mansplaining to clankers) و مصرف توکن‌های غیرضروری جلوگیری کند.

این چرخش راهبردی با محدودیت‌های دولتی اخیر بر روی مدل Fable شتاب گرفت؛ موضوعی که به گفته او نشان‌دهنده «امتیازات پدرانه» (daddy privilege) در صنعت بود. این اتفاق بسیاری از توسعه‌دهندگان را سوق داد تا دسترسی‌های خود را متنوع کنند و با مدل‌های چینی مانند DeepSeek از طریق رابط Pi تجربه کنند. Pi از ابزاری که او صرفاً با آن بازی می‌کرد، به مهم‌ترین بخش تجهیزاتش تبدیل شد و به او اجازه داد تا «با قدرت (bash) از هر مشکلی عبور کند». در همین راستا، ظهور مدل‌های قدرتمند چینی مانند GLM-5.2 به عنوان جایگزین‌های عملی برای توسعه‌دهندگان، این روند متنوع‌سازی را تقویت کرده است.

برای توسعه‌دهنده مدرن، این بدان معناست که «مزیت رقابتی» دیگر دانستن بهترین پرامپت نیست، بلکه ساخت یک زیرساخت شخصی — یک جیگ — است که اجازه می‌دهد مدل‌های مختلف بدون اتلاف توکن روی استدلال‌های تکراری، در هماهنگی کامل با یکدیگر کار کنند. این دیدگاه با رویکردی که در DeepSeek Harness برای تبدیل معماری عامل‌ها به مجموعه‌ای از پلاگین‌ها دنبال شده، کاملاً همسو است.

گام بعدی شما

• تفکیک نقش‌های Planner و Worker را در گردش کارهای خود پیاده کنید تا از گیج شدن مدل در پروژه‌های بزرگ جلوگیری کنید.
• برای وظایف تکراری از مدل‌های Flash (مانند DeepSeek) و برای معماری کلی از مدل‌های Frontier استفاده کنید.
• یک فایل متمرکز مانند AGENTS.md برای تعریف نقش‌ها و مهارت‌ها بسازید تا بین ابزارهای مختلف (Cursor, Claude, etc) تداوم زمینه حفظ شود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.