تصور کنید می‌خواهید یک قابلیت جدید به نرم‌افزاری ۲۰ ساله اضافه کنید که هیچ‌کس دیگر کد آن را نمی‌فهمد. به جای ریسک بازنویسی کل سیستم یا اتکای کورکورانه به اتوماسیون‌های شکننده، حالا راه سومی وجود دارد. طبق گزارشی که در ۱۶ اکتبر ۲۰۲۶ در dev.to منتشر شد، چارچوب طراحی جدیدی به نام مهندسی هارنس (Harness Engineering) معرفی شده است. این سیستم به عامل‌هایی مانند Claude Code یا Codex اجازه می‌دهد تا منطق عملیاتی اپلیکیشن‌ها را در زمان اجرا کشف کنند و به جای بازنویسی سورس‌کد، آن‌ها را گسترش دهند.
بسیاری از تلاش‌های مدرنیزاسیون با هوش مصنوعی بر درک کد برای بازنویسی آن تمرکز دارند. در همین راستا، راهکارهای IBM برای تبدیل خودکار کدهای میراثی به معماری‌های مدرن بر کاهش ریسک مهاجرت داده‌ها در سیستم‌های قدیمی تأکید دارد. اما در پلتفرم‌های کم‌کد (Low-code) و سیستم‌های سازمانی، منطق واقعی کسب‌وکار اغلب در تنظیمات رابط کاربری (GUI)، متادیتاها و رویه‌های عملیاتی پنهان است. اتوماسیون ساده‌ی رابط کاربری در اینجا شکست می‌خورد؛ چون کلیک کردن روی یک دکمه با درک اینکه آیا یک قانون تجاری واقعاً اجرا شده است، تفاوت دارد.
برای درک بهتر، اضافه کردن یک گردش‌کار تأیید را به یک ابزار شرکتی تصور کنید. یک توسعه‌دهنده انسانی فقط دکمه نمی‌زند؛ او دسترسی‌ها را بررسی می‌کند، چک می‌کند که آیا تغییرات در سیستم ثبت شده‌اند و مطمئن می‌شود که زنجیره‌ی کارهای وابسته خراب نشده است. یک عامل هوش مصنوعی باید دقیقاً همین کارها را انجام دهد. او باید بفهمد کدام عملیات‌ها در دسترس هستند، چه زمانی معتبرند، چه وضعیت‌هایی از اپلیکیشن و چه دسترسی‌هایی مورد نیاز است و یک تغییر چگونه بر توابع موجود اثر می‌گذارد. مهندسی هارنس این سطح از دانش عملیاتی را در اختیار عامل قرار می‌دهد. هدف تنها اتوماسیون یک گردش‌کار موجود نیست، بلکه توانمند کردن عامل‌ها برای مدیریت، پیکربندی و گسترش اپلیکیشن‌ها از طریق رابط‌های پشتیبانی‌شده است.
معماری پنج‌مرحله‌ای
این چارچوب برای تضمین قابلیت اطمینان، کار عامل را به پنج مرحله متصل تقسیم می‌کند:
- تعریف هدف: تعیین نتیجه‌ی تجاری و معیارهای پذیرش شفاف (Acceptance Criteria).
- مهندسی معکوس: کشف رفتار، وضعیت‌ها و محدودیت‌های اپلیکیشن از طریق مشاهده.
- ساخت هارنس: تبدیل دانش کشف‌شده به قابلیت‌های اجرایی.
- اجرای عامل: برنامه‌ریزی عملیات، مشاهده نتیجه و بازیابی از خطاها.
- ارزیابی هدف: تأیید اینکه آیا نیاز تجاری واقعاً برآورده شده است یا خیر.
این معماری چهار رشته مهندسی مجزا را ادغام می‌کند. مهندسی معکوس وظیفه کشف و اعتبارسنجی رفتار را بر عهده دارد. مهندسی هارنس این دانش را در کنترل‌های قابل استفاده مجدد سازماندهی می‌کند. تحقیق در عملیات (Operations Research) از انتخاب اقدام بهینه تحت محدودیت‌های هزینه، ریسک و عملیاتی پشتیبانی می‌کند. مهندسی زمان اجرا (Runtime Engineering) مسئول اجرای مطمئن، ردیابی وضعیت، تأیید و بازیابی است. این‌ها سیستم‌های جداگانه نیستند، بلکه مسئولیت‌های متفاوتی در یک فرآیند واحد هستند.
مدل عملیاتی اجرایی (EOM)
در قلب این معماری، مدل عملیاتی اجرایی (Executable Operational Model یا EOM) قرار دارد. برخلاف مهندسی معکوس سنتی که مستندات ایستا یا مشخصات بازیابی‌شده تولید می‌کند، EOM یک دارایی زنده است که عامل در حین اجرا از آن استفاده می‌کند. این مدل فقط نمی‌گوید «چگونه» کاری را انجام دهد، بلکه بستر و شرایط پیرامون آن را هم تعریف می‌کند.
برای اپلیکیشن‌های کم‌کد، عامل این مدل را از طریق مشاهده رابط کاربری، ضبط عملیات، مقایسه ورودی/خروجی، تحلیل تغییر وضعیت‌ها و بازرسی متادیتاها یا کدهای تولیدشده می‌سازد. برای مثال، هنگام بررسی یک طراح گردش‌کار، عامل ممکن است کشف کند که یک گردش‌کار باید ابتدا «باز» (Unlock) شود تا قابل تغییر باشد، یا اینکه ذخیره کردن تغییرات لزوماً به معنای فعال شدن خودکار آن‌ها نیست. همچنین ممکن است بفهمد که برخی تغییرات پیکربندی بر گردش‌کارهای وابسته اثر می‌گذارد یا خطاهای اعتبارسنجی تنها پس از یک عملیات خاص نمایان می‌شوند.
یک ورودی EOM برای به‌روزرسانی گردش‌کار شامل این عناصر دقیق است:
- وضعیت (State): حالت فعلی یا استنباط‌شده‌ی اپلیکیشن.
- اقدام (Action): عملیاتی که از طریق یک رابط پشتیبانی‌شده در دسترس است.
- پیش‌نیازها (Preconditions): الزاماتی مانند 'design_is_unlocked' یا 'user_has_permission'.
- اثرات (Effects): تغییرات مورد انتظار در نتیجه‌ی عملیات.
- ناورداها (Invariants): شرایطی که باید ثابت بمانند (مثلاً گردش‌کارهای نامرتبط نباید تغییر کنند و رکوردهای موجود باید حفظ شوند).
- تأیید (Verification): روشی که عامل با آن اثر را تأیید می‌کند (مثلاً باز کردن مجدد تنظیمات برای مقایسه مقادیر یا اجرای تست‌های گردش‌کار).
- بازیابی (Recovery): گام‌هایی برای بازگشت در صورت شکست عملیات یا نتیجه نامشخص (مثلاً بازرسی وضعیت واقعی یا بازگرداندن پیکربندی قبلی در صورت ایمن بودن).
- اطمینان (Confidence): مشخص می‌کند که این دانش مشاهده شده، فرضی یا تأیید شده است.
در عمل، EOM نیازی نیست که یک موتور مدل‌سازی رسمی و واحد باشد. این مدل می‌تواند بین مهارت‌ها (Skills)، فایل‌های پیکربندی، ابزارها، مدل‌های وضعیت و تعاریف تست توزیع شود. تحول حیاتی در اینجا، تبدیل رفتار کشف‌شده به قابلیت‌های عملیاتی اجرایی است.
محیط اجرای هارنس
هارنس در واقع پل ارتباطی عامل هوش مصنوعی با اپلیکیشن است. برای ابزارهایی مثل Claude Code یا Codex، این محیط شامل دستورالعمل‌های اپلیکیشن، مهارت‌ها (Skills)، ابزارهای GUI، دستورات CLI، ادغام‌های MCP، ابزارهای بازرسی وضعیت، ارزیاب‌ها و رویه‌های بازیابی است.
اجزای کلیدی هارنس عبارتند از:
- دستورالعمل‌ها و مهارت‌ها: ارائه دانش عملیاتی قابل استفاده مجدد.
- ابزارها: باز کردن رابط‌های پشتیبانی‌شده‌ی اپلیکیشن.
- مدل‌های وضعیت و سیاست‌ها: تعیین اینکه کدام اقدام در هر لحظه معتبر است.
- ارزیاب‌ها: بررسی اینکه آیا نتایج مورد نظر حاصل شده است.
یک تصمیم طراحی حیاتی در هارنس، تفکیک بین «مشاهده» و «تغییر» است. در حالی که کد تولیدشده یا متادیتا برای درک ساختار و وابستگی‌ها مفید است، هارنس ترجیح می‌دهد تغییرات را از طریق رابط‌های طراحی رسمی پلتفرم انجام دهد. تغییر مستقیم در کدهای تولیدشده ممکن است مکانیزم‌های پیکربندی داخلی پلتفرم کم‌کد را دور بزند. بنابراین، هارنس به جای اینکه صرفاً مجموعه‌ای از دستورات در دسترس یک LLM باشد، به یک محیط مهندسی مختص به آن اپلیکیشن تبدیل می‌شود.
برنامه‌ریزی و تحقیق در عملیات
عامل پس از داشتن EOM باید استراتژی خود را انتخاب کند. همیشه چندین راه برای رسیدن به هدف وجود دارد. برای مثال، تغییر قوانین تأیید ممکن است از طریق یک رویه شناخته‌شده در GUI، یک توالی کوتاه‌تر اما کمتر تست‌شده، یا یک رابط مدیریتی پشتیبانی‌شده انجام شود. کوتاه‌ترین مسیر همیشه بهترین نیست.
این چارچوب از مفاهیم تحقیق در عملیات برای انتخاب اقدام تحت محدودیت‌ها استفاده می‌کند. عامل ریسک تغییرات ناخواسته را در برابر هزینه زمان اجرا می‌سنجد. برنامه‌ریزی شامل این موارد است:
- زمان اجرای مورد انتظار و هزینه ابزار.
- وابستگی‌های بین عملیات‌ها.
- قابلیت اطمینان رویه‌های مشاهده‌شده قبلی.
- ریسک تغییرات ناخواسته.
- دسترسی‌های مورد نیاز و مرزهای تأیید.
- عدم قطعیت درباره وضعیت فعلی اپلیکیشن.
برنامه‌ریزی شامل یک موازنه حیاتی بین «عمل کردن» و «تحقیق کردن» است. اگر عامل مطمئن نیست که ذخیره کردن یک گردش‌کار آن را فعال می‌کند، باید تصمیم بگیرد که آیا هزینه تست این رفتار در یک محیط Sandbox کمتر از ریسک بروز خطا در محیط عملیاتی (Production) است یا خیر. این موضوع به مفاهیمی مانند «ارزش اطلاعات»، «اکتشاف در برابر بهره‌برداری» (Exploration vs Exploitation) و «برنامه‌ریزی تحت مشاهده ناقص» متصل می‌شود.
اگرچه همیشه به یک بهینه‌ساز ریاضی یا حل‌کننده POMDP نیاز نیست، اما سیستم از گراف‌های وابستگی، بررسی سیاست‌ها، امتیازدهی اکتشافی (Heuristic) و برنامه‌ریزی مجدد مبتنی بر ریسک استفاده می‌کند. این کار باعث جداسازی استدلال LLM از محدودیت‌های سختگیرانه‌ای می‌شود که توسط سیاست‌های هارنس اعمال می‌گردند. LLM اهداف را تفسیر کرده و درباره موقعیت‌های ناآشنا استدلال می‌کند، در حالی که EOM دانش مختص به اپلیکیشن را فراهم می‌سازد.
مهندسی زمان اجرا و قابلیت اطمینان
رابط‌های گرافیکی (GUI) به‌شدت ناهمگام (Asynchronous) و وابسته به وضعیت (Stateful) هستند و کنترل آن‌ها برای هوش مصنوعی سخت است. این چارچوب یک لایه زمان اجرا معرفی می‌کند تا شکاف بین «تکمیل شدن یک اقدام» و «تحقق هدف تجاری» را پر کند. برای مثال، اگر کلیک روی دکمه «ذخیره» با تأخیر (Timeout) مواجه شود، عامل در وضعیت عدم قطعیت قرار می‌گیرد: آیا تغییر شکست خورد، موفق شد یا به صورت ناقص اعمال شد؟ تکرار کورکورانه عملیات ممکن است خطرناک باشد.
قابلیت اطمینان از طریق سه مکانیزم اصلی حفظ می‌شود:
۱. تطبیق اثرات (Effect Reconciliation): زمان اجرا، اقدام مورد نظر، وضعیت اپلیکیشن قبل از اجرا، نتیجه مشاهده‌شده و تأیید بعدی را ثبت می‌کند. اگر عملیاتی نتیجه نامشخص تولید کند، زمان اجرا ابتدا وضعیت واقعی اپلیکیشن را بازرسی می‌کند و سپس اقدام به تکرار می‌نماید. برای مثال، پس از یک Timeout، ممکن است پیکربندی را مجدداً باز کند تا مقادیر ذخیره شده را با تغییرات مورد نظر مقایسه کند. اصل بر این است که قبل از تکرار یک عملیات نامشخص، وضعیت واقعی مشاهده شود.
۲. عملیات جبرانی (Compensating Operations): چون GUIها به‌ندرت از تراکنش‌های اتمیک دیتابیس یا Rollbackهای مطمئن پشتیبانی می‌کنند، زمان اجرا از رابط‌های رسمی برای بازگرداندن پیکربندی‌های قبلی استفاده می‌کند. این گام‌های بازیابی نیز باید تأیید شوند، زیرا جبران کردن با بازگشت تراکنش دیتابیس یکسان نیست.
۳. مرزهای تأیید (Approval Boundaries): سیستم مرزهای سختگیرانه‌ای تعریف می‌کند که در آن عامل باید متوقف شده و برای اقدامات تخریبی یا برگشت‌ناپذیر، اجازه انسانی بگیرد. بازرسی‌های Read-only و اکتشاف در Sandbox ممکن است به نظارت کمی نیاز داشته باشند، اما تغییرات پیکربندی در محیط Production نیازمند تأیید صریح انسانی است. زمان اجرا باید این مرزها را اعمال کند، نه اینکه به حافظه LLM برای به یاد آوردن آن‌ها تکیه کند.
کاربرد عملی: مدیریت سفارشات
برای درک بهتر، اضافه کردن یک گردش‌کار تأیید جدید به یک اپلیکیشن مدیریت سفارش را در نظر بگیرید. هدف این است که کاربران مجاز بتوانند سفارشات را برای تأیید ارسال کنند، قوانین مسیریابی را اعمال کنند و تاریخچه را بدون خراب کردن پردازش‌های موجود حفظ نمایند.
گام‌های پیاده‌سازی:
- گام ۱ (تعریف): معیارهای پذیرش صریح برای گردش‌کار جدید تعیین می‌شود. این‌ها به معیار ارزیابی برای ارزیاب (Evaluator) تبدیل می‌شوند.
- گام ۲ (کشف): عامل فرم‌ها، اشیاء داده‌ای و طراح گردش‌کار را بازرسی می‌کند. از طریق عملیات‌های کنترل‌شده، وابستگی‌های مرتبط را شناسایی کرده و کشف می‌کند که گردش‌کارها باید قبل از ویرایش باز (Unlock) و پس از ذخیره، به‌طور جداگانه فعال شوند. این یافته‌ها با وضعیت اعتبارسنجی آن‌ها ثبت می‌شوند.
- گام ۳ (به‌روزرسانی): این یافته‌ها در EOM ثبت می‌شوند. هارنس با پیش‌نیازهای ویرایش، تغییرات پیکربندی مورد انتظار، گام‌های اعتبارسنجی و گزینه‌های بازیابی به‌روز می‌شود. همچنین ابزارهایی برای بازرسی وضعیت فعلی گردش‌کار فراهم می‌گردد.
- گام ۴ (اجرا): عامل توالی اقدامات را بر اساس وابستگی‌ها و رویه‌های شناخته‌شده انتخاب می‌کند. او از طراح کم‌کد برای به‌روزرسانی گردش‌کار استفاده می‌کند و زمان اجرا پس از هر تغییر مهم، وضعیت را چک می‌کند. در صورت شکست عملیات، عامل ابتدا وضعیت واقعی را تطبیق داده و سپس تلاش مجدد می‌کند.
- گام ۵ (ارزیابی): ارزیاب بررسی می‌کند که آیا مسیریابی درست کار می‌کند، دسترسی‌ها اعمال شده‌اند، تاریخچه تأییدات حفظ شده و تست‌های پردازش سفارشات موجود همچنان پاس می‌شوند یا خیر. در صورت شکست تست، عامل تفاوت بین رفتار مورد انتظار و مشاهده‌شده را بررسی می‌کند.
مصنوعات مهندسی در هر گام:
- تعریف هدف: معیارهای پذیرش تجاری.
- مهندسی معکوس: مشاهدات، دانش وضعیت و وابستگی‌ها.
- ساخت هارنس: مدل عملیاتی، مهارت‌ها، سیاست‌ها و ارزیاب‌ها.
- اجرا: تاریخچه اقدامات، شواهد وضعیت و رکوردهای بازیابی.
- ارزیابی: نتایج تست و کاندیداهای بهبود تأیید شده.
این فرآیند، مهندسی معکوس را به یک حلقه مداوم تبدیل می‌کند. هر شکست یا وضعیت غیرمنتظره، اطلاعات جدیدی را فاش می‌کند که EOM را بهبود می‌بخشد. به مرور زمان، هارنس به یک دارایی مهندسی قابل استفاده مجدد تبدیل می‌شود که مانع از آن می‌شود که عامل در هر جلسه جدید مجبور به کشف مجدد منطق اپلیکیشن باشد.
بهبود مستمر هارنس
مهندسی معکوس با ساخت اولیه به پایان نمی‌رسد. هر اجرا می‌تواند یک وابستگی گم‌شده یا یک رویه مطمئن‌تر را آشکار کند. با این حال، این یادگیری باید کنترل‌شده باشد. یک رفتار مشاهده‌شده نباید به‌طور خودکار به یک قانون تجاری تبدیل شود و یک راهکار موقت (Workaround) موفق نباید بلافاصله جایگزین یک رویه تأیید شده گردد. تغییرات در دانش عملیاتی نیازمند شواهد، اعتبارسنجی، نسخه‌بندی و بازبینی است، به‌ویژه زمانی که هارنس تغییرات در اپلیکیشن ایجاد می‌کند. هارنس صرفاً از مهندسی معکوس ساخته نمی‌شود، بلکه به مکانیزمی تبدیل می‌شود که از طریق آن مهندسی معکوس ادامه می‌یابد.
محدودیت‌ها و موازنه ها
این رویکرد روی سه نوع کار تمرکز دارد: عملیات (استفاده از توابع موجود)، پیکربندی (تغییر تنظیمات) و گسترش (ساخت قابلیت جدید از طریق رابط‌های طراحی). این روش نمی‌تواند قابلیتی را ایجاد کند که خودِ پلتفرم زیرساختی از آن پشتیبانی نمی‌کند.
چندین محدودیت همچنان باقی است:
- مشاهده GUI تنها نمای ناقصی از رفتار سیستم ارائه می‌دهد.
- تغییر در رابط کاربری می‌تواند رویه‌های کشف‌شده قبلی را باطل کند.
- برخی عملیات‌ها را دشوار است به‌صورت «تکرارپذیر بدون اثر» (Idempotent) طراحی کرد.
- صحیح بودن تجاری ممکن است همچنان به متخصصان دامنه یا سیستم‌های تست مستقل نیاز داشته باشد.
همچنین یک هزینه مهندسی اولیه برای کشف رفتار، تعریف دانش عملیاتی، ساخت ابزارها و پیاده‌سازی ارزیاب‌ها وجود دارد. برای کمی‌سازی ارزش، این چارچوب پیشنهاد می‌کند سه پیکربندی با هم مقایسه شوند: یک عامل GUI با کاربرد general-purpose، یک عامل GUI با مهارت‌های تعریف‌شده دستی، و یک عامل که از دانش عملیاتی کشف‌شده، برنامه‌ریزی محدود و یک هارنس متمرکز بر قابلیت اطمینان استفاده می‌کند. معیارهای کلیدی شامل نرخ تکمیل هدف، پوشش معیارهای پذیرش، موفقیت در بازیابی، تخلفات رگرسیون، هزینه اجرا و تلاشی است که برای تطبیق عامل پس از تغییر UI اپلیکیشن لازم است.
این تغییر دیدگاه نشان می‌دهد که مدرنیزاسیون لزوماً به معنای بازنویسی نیست. با مهندسی محیط پیرامون اپلیکیشن، می‌توانیم سیستم‌های قدیمی را از طریق بهبود درک، توسعه و عملیات عامل‌های هوش مصنوعی تکامل دهیم.
گام بعدی شما
- اگر با سیستم‌های Legacy یا پلتفرم‌های Low-code سر و کار دارید، ابتدا نقشه‌های وابستگی (Dependency Graphs) عملیات‌های کلیدی خود را ترسیم کنید.
- برای پیاده‌سازی عامل‌های خود، به جای اتکای صرف به LLM، یک لایه «تأیید وضعیت» (State Verification) بین اقدام عامل و نتیجه نهایی قرار دهید. در این مسیر، شناخت گام‌های پاک‌سازی کدهای بی‌کیفیت تولیدشده توسط AI می‌تواند به ارتقای کیفیت خروجی‌های سیستم شما کمک کند.
- بررسی کنید که کدام بخش‌های اپلیکیشن شما قابلیت «مشاهده بدون تغییر» را دارند تا بتوانید مدل‌های EOM اولیه را بسازید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو