در تاریخ ۲۱ خرداد ۱۴۰۵ (۱۱ ژوئن ۲۰۲۶)، شرکت اوپنایآی نتایج یک آزمایش مهندسی پنجماهه را منتشر کرد که تعریف سنتی ما از توسعهدهنده نرمافزار را به چالش میکشد. در گزارش Harness engineering: leveraging Codex in an agent-first world، اعضای تیم فنی این شرکت مستندات ساخت یک محصول داخلی واقعی با بیش از یک میلیون خط کد را ارائه کردند. ویژگی متمایز این پروژه یک چیز بود: مهندسان انسان حتی یک خط کد هم به صورت دستی ننوشتند.
به جای نوشتن منطق برنامه، تمرکز تیم روی طراحی، کنترل و تقویت محیطی بود که عاملهای Codex در آن فعالیت میکردند. این تغییر رویکرد، خبر از تولد یک تخصص مهندسی جدید میدهد: «مهندسی مهار» (Harness Engineering).
تعریف مهار
برای درک این تحول، ابتدا باید تعریف کنیم مهار چیست. یک مدل زبانی بزرگ (LLM) به خودی خود یک موتور احتمالاتی است. این مدلها بر اساس وزنهای آماری خود، احتمال کلمه بعدی را محاسبه میکنند؛ آنها فاقد وضعیت (state)، بافتار پویا یا توانایی اجرای مستقل هستند.
اما یک عامل (Agent) یک سیستم ترکیبی است. همانطور که ادی عثمانی در یادداشت Agent Harness Engineering بررسی کرده است، ساختار این سیستمها از یک فرمول ساده پیروی میکند:
عامل کدنویس = مدل هوش مصنوعی + مهار
«مهار» به تمام زیرساختهای قطعی و تعیینگری (deterministic) گفته میشود که مدل احتمالاتی را در بر میگیرند. این مهار شامل پرامپتهای سیستمی، فایلهای پیکربندی مانند AGENTS.md، محیطهای ایزوله برای اجرای کد (Sandbox)، ابزارهای تحلیل ایستای کد (Linter) و تستهای خودکار است.
این مهار چه کارکردی در کل سیستم دارد؟ بدون وجود یک مهار محکم، خروجی مدلهای زبانی در پروژههای بزرگ به سرعت دچار فرسایش بافتار، وابستگیهای نامعتبر و تجمع خطا میشود. مهار وجود دارد تا خروجیهای احتمالاتی مدل را به رفتارهای قطعی، تکرارپذیر و قابل تایید تبدیل کند.
مکانیزم چرخدنده یکطرفه در مدیریت خطا
یکی از اصول کلیدی در مهندسی مهار، اصل «چرخدنده یکطرفه» (Ratchet) است. در مهندسی مکانیک، چرخدنده جغجغهای ابزاری است که حرکت را فقط در یک جهت اجازه میدهد و مانع از برگشت آن میشود.
در مهندسی نرمافزار سنتی، وقتی عاملی خطایی مرتکب میشود—مثلاً تستی را غیرفعال میکند یا کدی با سینتکس اشتباه مینویسد—اولین واکنش انسان این است که خود دست به کار شده و کد را اصلاح کند. اما مهندسی مهار این مداخله دستی را رد میکند. اگر مهندس به صورت دستی کد را اصلاح کند، صرفاً نشانه بیماری را برطرف کرده اما محیط را برای خطاهای بعدی عامل باز گذاشته است.
در مقابل، مهندس مهار هر خطای عامل را به عنوان یک سیگنال سیستمی در نظر میگیرد. او محیط مهار را به گونهای اصلاح میکند که آن خطای خاص دیگر هرگز نتواند رخ دهد. این کار از چند طریق انجام میشود:
۱. محدودیتهای سطح پرامپت: اضافه کردن دستورالعملهای صریح به فایلهای راهنمای عامل (مانند ممنوعیت کامنت کردن تستها). ۲. ابزارهای تایید خودکار: تنظیم پیشنویسهای گیت (pre-commit hooks) برای رد کردن خودکار کدهایی که استانداردهای پروژه را نقض میکنند. ۳. عاملهای ناظر: تعریف عاملهای بازبین مستقل که وظیفه دارند کدهای تولید شده را قبل از ادغام، به طور دقیق تحلیل کنند.
وقتی هر خطا را با اصلاح محیط حل کنیم، دیوارهای حفاظتی سیستم به مرور زمان قویتر میشوند و نیاز به نظارت مستقیم انسان کاهش مییابد.
خوانایی سیستم و فشار معکوس
با افزایش سرعت تولید کد، گلوگاه اصلی سیستم از «نوشتن کد» به «تایید کد» تغییر مییابد. در آزمایش اوپنایآی Harness engineering: leveraging Codex in an agent-first world، تیمی کوچک متشکل از ۳ تا ۷ مهندس توانستند روزانه به طور میانگین ۳.۵ درخواست ادغام (PR) به ازای هر نفر ثبت کنند. مدیریت این حجم از تغییرات نیازمند آن است که برنامه برای خود عامل «خوانا» باشد.
«خوانایی» یعنی تبدیل خروجیهای خام به فرمتهایی که مدل بتواند آنها را تحلیل کند. برای مثال، مهندسان اوپنایآی پروتکل ابزار توسعه کروم (Chrome DevTools MCP) را مستقیماً به محیط اجرای عامل متصل کردند. این کار به Codex اجازه داد تا برای هر تغییر، یک نسخه بدون گرافیک (headless) از برنامه را اجرا کند، از وضعیت DOM عکس بگیرد و خطاهای کنسول را بخواند.
وقتی عامل تستی را اجرا میکند یا برنامه را بالا میآورد، خروجی این فرآیند یک حلقه بازخورد ایجاد میکند. اگر تستی خراب شود، این خطا همراه با جزییات به عنوان یک پرامپت جدید به عامل بازگردانده میشود. به این فرآیند «فشار معکوس» (back-pressure) میگویند. مهار به طور خودکار عامل را مجبور میکند تا زمانی که تمام تستها پاس نشدهاند، در محیط محلی خود به اصلاح کد ادامه دهد.
دستهبندی مهارها
برگت بوکلر در مقاله خود در سایت مارتین فاولر Harness engineering for coding agent users، سیستمهای مهار را به سه دسته اصلی تقسیم میکند:
- مهار قابلیت نگهداری (Maintainability harness): ابزارهایی که رعایت استانداردهای نگارش کد و پوشش تستهای اولیه را تضمین میکنند.
- مهار انطباق معماری (Architecture fitness harness): قوانینی که مانع از شکستن مرزهای ساختاری نرمافزار توسط عامل میشوند (مثلاً جلوگیری از دسترسی مستقیم لایه گرافیکی به پایگاه داده).
- مهار رفتار (Behaviour harness): محیطهای تست سناریوهای کاربر (End-to-End) که تضمین میکنند برنامه از نظر عملکردی درست کار میکند.
در عمل سیستمسازی، عدم وجود این مهارها باعث میشود عامل همواره سادهترین و غیراستانداردترین راه را برای حل مسائل انتخاب کند که نتیجه آن، کدهای درهمتنیدهای خواهد بود که تحت فشار ترافیک واقعی به سرعت فرو میریزند.
مهندسی محیط به جای مهندسی محصول
پیامد بلندمدت مهندسی مهار، تغییر بنیادی در نقش انسان است. ما دههها تلاش کردیم تا زبانهای برنامهنویسی و کامپایلرهایی بسازیم که کدها را برای انسانها خواناتر کنند. امروز این مسیر را معکوس کردهایم: ما محیطها و ساختارهایی طراحی میکنیم که فرآیند اجرای کد را برای ماشینها خوانا و قابل فهم کنند.
وقتی کار اصلی ما دیگر نوشتن کاراکترها در یک ویرایشگر متن نباشد، ارزش واقعی انسان در درک معماری سیستم، تعریف مرزهای حفاظتی و اعمال سلیقه مهندسی خلاصه میشود. مهندس نرمافزار در عصر عاملهای هوشمند، دیگر نویسنده کد نیست، بلکه معمار محدودیتهایی است که نوشتن کد را ایمن میسازند.
منابع
- Harness engineering: leveraging Codex in an agent-first world | OpenAI — Manual / ad-hoc · 2026-06-11
- Harness engineering for coding agent users — Manual / ad-hoc · 2026-06-11
- GitHub - walkinglabs/learn-harness-engineering: Harness engineering beginner tutorial, from 0 to 1 · GitHub — Manual / ad-hoc · 2026-06-11
- AddyOsmani.com - Agent Harness Engineering — Manual / ad-hoc · 2026-06-11