مهندسی شاسی؛ جایگزینی زیرساخت‌های سخت‌گیرانه با مهندسی پرامپت در عامل‌های هوش

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

به گزارش وب‌سایت dev.to، یک توسعه‌دهنده در ۲۲ اوت ۲۰۲۶ متوجه شد که شکست در یکپارچه‌سازی Next.js و Express نه به دلیل ضعف مدل زبانی، بلکه به دلیل نبود کامل زیرساخت‌های کنترلی بود. این مورد نشان می‌دهد که تکیه بیش از حد به مهندسی پرامپت (Prompt Engineering) — که شبیه هنر سؤال درست پرسیدن از یک مشاور باتجربه است — یک تله است.

همان‌طور که در تحلیل قبلی ما درباره‌ی حاکمیت هوش مصنوعی اشاره کردیم، «کیستیِ» مدل اهمیت کمتری نسبت به «چگونگیِ» محدود کردن آن دارد. برای اکثر برنامه‌نویسان، واکنش غریزی بازنویسی پرامپت است، اما گلوگاه واقعی، نبود یک شاسی برای هدایت مدل است.

برای حل این مشکل، مفهوم «مهندسی شاسی» (Harness Engineering) پیشنهاد شده است. این رویکرد به جای ارسال انبوه کدها به مدل، از یک سیستم ساختاریافته استفاده می‌کند که شامل موارد زیر است:

• مدیریت زمینه: استفاده از بازیابی هدفمند برای نمایش تنها فایل‌های ضروری در هر لحظه به عامل (Agent). این رویکرد یادآور راهکارهای پیشرفته‌ای است که در سیستم Arka Sentinel برای جایگزینی موتور حافظه محلی با بردار معنایی به کار گرفته شد تا امنیت و دقت داده‌ها حفظ شود.
• ابزارهای استاندارد: یکپارچه‌سازی سرورهای پروتکل زمینه مدل (MCP) برای ایجاد مسیرهای اجرای امن و محدود.
• وضعیت پایدار: پیاده‌سازی نقاط بازرسی (Checkpoints) تا گردش‌های کاری طولانی در صورت شکست، از همان نقطه ادامه یابند و از ابتدا شروع نشوند.
• تأیید سخت‌گیرانه: اجبار عامل به اجرای تست‌ها و بررسی خروجی‌های CLI پیش از تأیید نهایی تسک.

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

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

گام بعدی شما

• نقاطی از گردش کار خود را که در آن مدل بدون تست خارجی «خود-تأیید» می‌کند، شناسایی و حذف کنید.
• برای کاهش توهم (Hallucination) — شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — از یکپارچه‌سازی ابزارهای مبتنی بر MCP استفاده کنید.
• سیستم نقاط بازرسی را برای تسک‌های طولانی‌تر از ۱۰ دقیقه پیاده‌سازی کنید.

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