«جلوگیری از تأیید بدون بررسی»؛ هدف اصلی در طراحی Airframe

احتمالاً بدون اینکه متوجه شوید، خروجی‌های عامل هوش مصنوعی خود را کورکورانه تایید می‌کنید. وقتی یک عامل برای دهمین بار تغییرات مشابهی را در کد پیشنهاد می‌دهد، ناظر انسانی معمولاً خواندن را متوقف کرده و فقط کلید 'y' را می‌زند؛ در این لحظه نظارت فعال به یک تجربهٔ مسافری تبدیل می‌شود که هیچ کنترلی بر مسیر ندارد. این دیگر نظارت نیست، بلکه یک مهر تایید کورکورانه است. پرسش بنیادین این است: آیا من در حال هدایت این پرواز هستم یا صرفاً یک مسافرم؟

این زوال شناختی، مسئله‌ای است که Hyuga در ۳۰ اوت ۲۰۲۶ با انتشار ابزار Airframe به آن پاسخ داد. طبق مستندات این پروژه، اکثر توسعه‌دهندگان در حال حاضر عامل‌ها را بدون یک پنل ابزار (Instrument Panel) مدیریت می‌کنند؛ آن‌ها فقط یک دیالوگ تایید را در هر لحظه می‌بینند و نسبت به اثر کلی جلسه، میزان ورود به مناطق خطرناک یا خطاهای قبلی عامل کاملاً کور هستند.

Airframe بر این اساس طراحی شده که یک خلبان برای پرواز سریع و ایمن، به ابزارهای اندازه‌گیری نیاز دارد. این ابزار یک پنل وضعیت ارائه می‌دهد که «سورتي» (Sortie) — یا همان یک چرخه کامل از کار — را ردیابی می‌کند. یک خلبان دنیای بیرون را مستقیماً نمی‌بیند، بلکه ابزارهایی برای سنجش سوخت، میزان آسیب و مهمات باقی‌مانده را می‌بیند. به همین ترتیب، Airframe انسان را از حالت تاییدهای کند و مداوم به حالت نظارت آگاهانه منتقل می‌کند؛ جایی که کاربر تنها زمانی دخالت می‌کند که عقربه‌های خاصی سیگنال ریسک بدهند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، حذف لایه‌های نظارتی انسانی در سیستم‌های خودکار، ریسک خطاهای زنجیره‌ای را به‌شدت افزایش می‌دهد.

پنل ابزار

با اجرای دستور airframe status کاربر به نمایی کلی از عملیات جاری دست می‌یابد. در این سیستم، سکوت به معنای وضعیت درست است و کاربر هر زمان که بخواهد وضعیت را چک می‌کند. این پنل چندین معیار کلیدی را ردیابی می‌کند:

• سورتي (Sortie): یک شناسه منحصربه‌فرد برای هر اجرا (مثلاً 2026-08-30T07-07-43-412Z-18aa80). هر آنچه در اجرای قبلی ناتمام مانده، به اجرای بعدی منتقل می‌شود. این رویکرد برای جلوگیری از اتلاف منابع در پنجره‌های متنی است، مشابه آنچه در بررسی بازدهی عامل‌های کدنویسی و جلوگیری از پوسیدگی زمینه تحلیل کردیم.
• محدودکننده (Limiter): شمارش میزان پیشروی در مسیرهای بازگشت‌ناپذیر.
• هم‌رزم‌ها (Wingmen): تعداد زیر-عامل‌هایی (Subagents) که در طول جلسه فعال شده‌اند.
• سوخت (Fuel): معیاری برای تعداد گام‌های باقی‌مانده بر اساس بودجه تعیین‌شده.
• اجزای نصب‌شده: مجموعه‌ای از ابزارهای فعال شامل airframe (بدنه/ظرف)، redline (محدودکننده)، habit (یادگیری از اصلاحات دستی)، carbon (نگهدارنده پیش‌نویس) و groundtruth (دروازه تکمیل).

مکانیزم محدودکننده

هستهٔ اصلی این ابزار، «محدودکننده» است؛ عقربه‌ای که اندازه‌گیری می‌کند یک سورتي چقدر در زمینه‌های بازگشت‌ناپذیر پیش رفته است. برخلاف «حفاظ‌ها» (Guardrails) — شبیه به نرده‌های ایمنی در لبهٔ پرتگاه که برای ایجاد اصطکاک و کند کردن فرآیند هستند — محدودکننده طراحی شده تا کاربر بتواند با اطمینان «گاز بدهد» و سرعت را بالا ببرد. بدون ابزار، تنها راه ایمن، حرکت بسیار کند و تایید تک‌تک مراحل است تا هرگز چشم از مسیر برداشته نشود. اما با محدودکننده، وضعیت «ایمن برای اجرا» و «زمان مهار کردن» بر اساس عددی روی پنل تفکیک می‌شوند:

• محدودکننده ۰: یعنی هیچ اتفاق خطرناکی نیفتاده و کاربر می‌تواند عامل را رها کند.
• مقدار صعودی: سیگنالی است که نشان می‌دهد ماشین در حال فشار آوردن به حوزه‌های حساس است و خلبان باید دقت کند.

به نقل از Hyuga، یک شکست بحرانی در طراحی ابزارها، مسئلهٔ «نویز» است. در زمان انتشار این مخزن، مقدار محدودکننده به ۲۰ رسید در حالی که آستانه روی ۳ بود؛ یعنی بیش از شش برابر حد مجاز. بررسی‌ها نشان داد تمام این هشدارها مربوط به دستورات جست‌وجو (Search) بود. برای مثال، اجرای grep -n "npm publish" .github/workflows/release.yml یا grep -rn "rm -rf" packages/ همان امتیازی را داشت که اجرای واقعی آن دستورات تخریبی.

محدودکننده در واقع یک عبارت منظم (Regex) را روی کل دستور به عنوان یک بلوک متنی تطبیق می‌داد. این موضوع ثابت کرد ابزار خراب بدتر از نبود ابزار است، چون کاربر را عادت می‌دهد هشدار بیستم را نادیده بگیرد — همان هشدار تک و حیاتی که واقعاً اهمیت دارد. این باگ با تفکیک آرگومان‌های متنی grep از اقدامات واقعی اصلاح شد، هرچند ابزارهایی مانند sed ،xargs و node -e همچنان امتیاز منفی می‌گیرند چون آرگومان‌های آن‌ها در واقع دستورات اجرایی هستند.

حالت‌های عملیاتی و ایمنی

Airframe برای جلوگیری از اثر «مچ‌گیری» (Wrist-grabbing) ناشی از محدودیت‌های نامتناسب، دو گردش‌کار متضاد را تعریف کرده است که با دستورات airframe mode strike یا airframe mode cruise تغییر می‌کنند:

۱. حالت ضربتی (Strike Mode): برای پیاده‌سازی، رفع باگ و ارسال کد (Shipping). در این حالت از یک «دروازه تکمیل» استفاده می‌شود تا تایید کند آیا ردیف‌ها واقعاً در پایگاه‌داده نشسته‌اند یا یک فایل حقیقتاً نوشته شده است. در این حالت، شما می‌خواهید اگر نتیجه حاصل نشد، دروازه جلوی شما را بگیرد. این سخت‌گیری در عملیات حساس، یادآور رویکرد عامل Sonjomon در اولویت دادن به خویشتن‌داری برای جلوگیری از اصلاحات خودسرانه در محیط‌های عملیاتی است.
۲. حالت کروز (Cruise Mode): برای پیش‌نویس، طراحی و تصمیم‌گیری درباره اینکه چه چیزی ساخته شود. در این حالت دروازه تکمیل ساکت است؛ چون ایده‌ای که هنوز شکل نگرفته نباید به عنوان شکست گزارش شود. هرچه ایده بهتر باشد، زودتر بسته می‌شود.

برای جلوگیری از دست رفتن داده‌ها در فاز پیش‌نویس، ابزاری به نام Carbon را معرفی کرده‌اند. وقتی عامل می‌خواهد فایلی را که هنوز در Git ردیابی نمی‌شود بازنویسی کند، Carbon نسخه قبلی را ذخیره می‌کند. برای مثال، فایلی مانند 2026-08-30T07-32-32-255Z-0bef6e1d.md نگهداری می‌شود. فایل‌هایی که گیت قبلاً ردیابی کرده است کپی نمی‌شوند، زیرا git show می‌تواند آن‌ها را بازیابی کند. این مشکل رایجی را حل می‌کند که در آن عامل پیش‌نویسی را پاک می‌کند و چون فایل هرگز Commit نشده بود، Diff گیت خالی می‌ماند.

اعتبارسنجی و خودمختاری

دروازه تکمیل یا groundtruth به جای اعتماد به ادعای مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — وضعیت واقعی سیستم را دوباره بازخوانی می‌کند. این پاسخی است به مشکل «صفر خطا در برابر صفر اجرا». Hyuga تجربه کرده بود که سه فایل CI و انتشار را در پوشه‌های پکیج ادغام کند؛ اما چون گیت‌هاب فقط پوشه .github/ در ریشه را می‌خواند، فایل‌ها هرگز اجرا نشدند. رابط کاربری «صفر خطا» را نشان می‌داد که دقیقاً شبیه به موفقیت بود.

Groundtruth این مشکل را با اجرای یک دستور خام به عنوان مدرک حل می‌کند. مثلاً:
groundtruth verify --probe "psql -tAc 'select count(*) from t where batch=123'" --count 45
اگر عامل ادعا کند ۴۵ ردیف اضافه شده اما پروب مقدار صفر را برگرداند، فرآیند متوقف می‌شود. در اینجا هیچ API یا مدل زبانی دخیل نیست و فقط خروجی خام سیستم ملاک است. این نوع اعتبارسنجی سخت‌گیرانه، شباهت زیادی به استفاده از فایل‌های تله برای سنجش واقعی امنیت سیستم‌فایل دارد تا ادعاهای مدل با واقعیت زیرساختی تطبیق یابد.

در مورد خودمختاری، وقتی امتیاز از آستانه می‌گذرد، ماشین به‌طور خودکار متوقف نمی‌شود، بلکه به خلبان توصیه می‌کند: «این سورتي مقدار ۲۰ را در برابر حد ۳ هزینه کرده است... قبل از ادامه، بلند بگویید که از لبه عبور کرده‌اید». تصمیم نهایی با انسان است چون تضمینی نیست که ماشین همیشه درست‌تر از شخص باشد.

تنها استثنا متغیر AIRFRAME_AUTONOMY است. وقتی این متغیر روی دلیل اجرای بدون نظارت (مثلاً یک حلقه یا تایمر) تنظیم شود، ماشین کاملاً متوقف خواهد شد. وقتی کسی روی صندلی نیست، «توصیه کردن» معنایی ندارد و ماشین باید متوقف شود.

کاربردهای عملی

این سیستم به‌طور خاص برای سه سناریوی پرریسک طراحی شده است:

• خستگی پایان روز: اواخر یک روز طولانی، قضاوت انسانی تضعیف می‌شود. محدودکننده عددی را نشان می‌دهد که پایین نمی‌رود و مجموع ریسک روز را مرئی نگه می‌دارد. کاربران می‌توانند مسیرهای تولید (Production) را نام‌گذاری کنند (مثلاً { "production": ["/var/www/", "/srv/client-sites/"] }) تا ریسک‌های خاص ردیابی شوند.
• حلقه‌های بدون نظارت: جایی که ترمز سخت برای تایمرها یا اسکریپت‌های خودکار از طریق AIRFRAME_AUTONOMY ضروری است.
• نویسندگی متون: هنگام نوشتن مقالات، پروپوزال‌ها یا یادداشت‌های طراحی، Carbon از حذف پیش‌نویس‌های ردیابی‌نشده جلوگیری می‌کند.

این ابزار برای کارهای کوتاه و یک‌باره، آزمایش‌های محلی بازگشت‌پذیر یا قضاوت‌های صرفاً ذهنی (مثلاً «آیا این طراحی زیباست؟») مناسب نیست، چون برای این موارد هیچ «پروب» فنی برای چک کردن دروازه وجود ندارد. همچنین نمی‌تواند بازنویسی‌های انجام شده توسط sed -i یا فرمت‌کننده‌هایی که قلاب‌ها (Hooks) را دور می‌زنند، شناسایی کند.

آیندهٔ کابین خلبان

این تغییر رویکرد نشان می‌دهد که گلوگاه آیندهٔ عامل‌های هوش مصنوعی، کیفیت مدل نیست، بلکه مقیاس‌پذیری «انسان در حلقه» (Human-in-the-loop) است. به‌زودی عامل‌ها هنگام خواب ما اجرا می‌شوند، چندین عامل به‌طور همزمان کار می‌کنند و هر اجرا ساعت‌ها طول می‌کشد.

وقتی کاربر بیدار می‌شود و با خروجی هشت عامل مواجه می‌شود، نیاز اصلی این است که بتواند بازسازی کند چه اتفاقی افتاده است. آیا یک عامل به‌طور بی‌صدا یک اصلاح دستی دیروز را بازگردانده است؟ به همین دلیل ردیف wingmen وجود دارد تا بدانیم دقیقاً چند زیر-عامل فعال شده‌اند. اینکه «هوش مصنوعی کار را انجام می‌دهد» به معنای فرمانده بودن شماست یا صرفاً حمل شدن، توسط کابین خلبان تصمیم گرفته می‌شود، نه توسط مدل.

باید توجه داشت که Airframe عامل را «درست» نمی‌کند؛ بلکه یک عقربه است، نه یک حفاظ. مقدار محدودکننده از یک دفتر کل (Ledger) جمع می‌شود که خود عامل می‌تواند در آن بنویسد، و نگهدارنده پیش‌نویس نام‌ها را تطبیق می‌دهد، نه محتوا را. این ابزار برای عاملی ساخته شده که حساب کارهایش را گم کرده است، نه عاملی که قصد دارد به‌طور مخفیانه کاربر را دور بزند.

اگر جلسات طولانی با عامل‌ها دارید، می‌توانید این ابزار را از طریق npx @hyuga/airframe install نصب کنید. این ابزار به Node 18+ نیاز دارد و هیچ وابستگی، دیمون یا نیاز به LLM ندارد. این پروژه تحت لایسنس MIT در github.com/hyuga611/airframe منتشر شده است. اگر روی صندلی نشسته‌اید، به ابزارها نگاه کنید.

گام بعدی شما

• اگر از عامل‌های کدنویسی (مانند Claude Code یا Devin) استفاده می‌کنید، یک سیستم ردیابی برای دستورات بازگشت‌ناپذیر (مانند rm یا npm publish) تعریف کنید.
• برای کارهای حساس، به جای تایید سریع، یک «دروازه تکمیل» ساده (یک اسکریپت Bash برای چک کردن خروجی واقعی) پیاده‌سازی کنید.
• در پروژه‌های بدون Git، از نسخه‌بندی دستی یا ابزارهایی شبیه Carbon برای جلوگیری از بازنویسی پیش‌نویس‌ها استفاده کنید.

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