تکنیک «نانس»؛ راهکار جلوگیری از خطاهای مسیر در عامل‌های کدنویس

تصور کنید ساعتی از زمان خود را صرف بررسی کدهای زیبایی می‌کنید که هرگز در پروژه شما اعمال نشده‌اند. این کابوس هر توسعه‌دهنده‌ای است که از عامل‌های هوش مصنوعی (AI Agents) — سیستم‌هایی که مثل دستیارهای برنامه‌نویس، می‌توانند به‌طور مستقل فایل‌ها را بخوانند و تغییر دهند — برای بازنویسی کدها استفاده می‌کند. این وضعیت زمانی رخ می‌دهد که شما فکر می‌کنید مدل در حال ویرایش کد شماست، اما در واقعیت، او در حال تغییر دادن یک نسخه خیالی از پروژه در یک فضای ایزوله است.

به نقل از راهنمای کاربردی منتشر شده در dev.to در ۱۲ سپتامبر ۲۰۲۶، بسیاری از برنامه‌نویسان با یک خطای خاص در «دقیقه دوازدهم» هر جلسه مواجه می‌شوند. در این لحظه، عامل ادعا می‌کند تغییرات را با موفقیت اعمال کرده و در چت هم کدها درست به نظر می‌رسند، اما در محیط ویرایشگر (IDE)، هیچ تغییری رخ نداده است. این اتفاق زمانی می‌افتد که عامل در یک کانتینر یا یک کپی سایه‌ای (Shadow Copy) از فایل‌ها فعالیت می‌کند که با دید توسعه‌دهنده متفاوت است. در واقع، مدل در یک محیط Bind-mount یا کانتینری است که با نمای محلی توسعه‌دهنده تفاوت دارد.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی چالش‌های استقرار مدل‌های عامل‌محور اشاره کردیم، تفاوت میان «ادراک مدل» و «واقعیت دیسک» یکی از بزرگ‌ترین نقاط ضعف فعلی است. این وضعیت شبیه این است که لوله‌کشی را برای تعمیر نشتی حمام استخدام کنید، اما او بدون اینکه مطمئن شود در آپارتمان شماست، شروع به کاشی‌کاری در واحد همسایه کند. شما هرگز اجازه نمی‌دهید لوله‌کش قبل از تأیید حضورش در واحد شما، کاشی‌ها را بشکند. در AI coding، «نانس» (Nonce) نقش آن تأییدیه حضور را ایفا می‌کند؛ یک پژواک فیزیکی برای اثبات اینکه عامل در قایق درستی ایستاده است.

مکانیزم نانس

اساس این روش، یک «تأییدیه رفت‌وبرگشت» (Round-trip verification) است. به‌جای اینکه از مدل بخواهید ساختار پروژه را توصیف کند یا گشتی در مخزن بزند — که نویسنده آن را «حرف‌های ارزان» (Cheap talk) می‌نامد چون با واقعیت دیسک برخورد نمی‌کند و هیچ تداخلی با دیسک ندارد — توسعه‌دهنده مدل را مجبور می‌کند یک کار فیزیکی، خسته‌کننده و کسالت‌بار انجام دهد. این رویکرد در واقع پاسخی به این واقعیت است که لاگ‌های ابزارهای هوش مصنوعی اغلب ادعاهایی توخالی هستند و لزوماً مدرکی بر اجرای واقعی کد روی دیسک محسوب نمی‌شوند:

• نوشتن: عامل یک فایل کوچک (نانس) حاوی یک رشته تصادفی را با استفاده از ابزار نوشتن (Write tool) خودش ایجاد می‌کند.
• خواندن: عامل همان فایل را با استفاده از ابزار خواندن (Read tool) خودش دوباره باز می‌کند.
• تأیید: توسعه‌دهنده خروجی را بررسی می‌کند تا مطمئن شود رشته‌ها دقیقاً مطابقت دارند و مسیر فایل کاملاً درست است.

اگر این حلقه قطع شود، جلسه «در لابی» (In the lobby) باقی مانده و باید فوراً ری‌استارت شود. نویسنده اسکریپتی به نام prove_path.sh ارائه داده که این فرآیند را خودکار می‌کند؛ این اسکریپت یک رشته تصادفی تولید کرده، آن را در .agent-nonce می‌نویسد و سپس صحت خواندن آن را بررسی می‌کند. برای تضمین اجرای سخت‌گیرانه، این اسکریپت از دستور set -euo pipefail استفاده می‌کند و ریشه مسیر را از طریق pwd دریافت می‌کند تا هیچ خطایی نادیده گرفته نشود.

مراحل دقیق اعتبارسنجی

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

• اجرای اسکریپت Probe دقیقاً از طریق همان کانال ابزاری که عامل قرار است بعداً برای اعمال پچ‌ها (Patches) از آن استفاده کند.
• درخواست از عامل برای چاپ هم‌زمان و در یک نوبت دستورات pwd ،ls -la .agent-nonce و git rev-parse --show-toplevel.
• مقایسه این سه پاسخ با وضعیت فعلی و واقعی ویرایشگر محلی.

اگر این پاسخ‌ها متفاوت باشند، مشکل جلسه مربوط به «هویت» (Identity) است، نه «هوش» (Intelligence). به باور نویسنده، اگر عاملی نمی‌تواند یک کار خسته‌کننده و ساده را درست انجام دهد، نباید اجازه داشته باشد کارهای هوشمندانه و پیچیده مثل بازنویسی ماژول احراز هویت (Auth module) را در حالی که هنوز در مسیر /tmp گم شده است، انجام دهد.

مدیریت عدم تطابق محیطی

این شکست‌ها در محیط‌های SSH پیچیده یا سرورهای رایگان بسیار رایج هستند. طبق گزارش این منبع، ابزارهایی مثل MonkeyCode دسترسی رایگان به مدل‌ها و سرورها می‌دهند که باعث می‌شود توسعه‌دهندگان وسوسه شوند و از این مرحله اعتبارسنجی بگذرند. (توضیح: مقاله اصلی به عنوان بخشی از تبلیغات محصول MonkeyCode تهیه شده است، هرچند نویسنده سهمیه خاص یا تداوم سخت‌افزاری مشخصی را برای این محصول تعریف نکرده است). این ابزار پیش‌تر یک پروتکل سه-مرحله‌ای را برای توقف باگ‌های پنهان در کدهای تولید شده توسط هوش مصنوعی معرفی کرده بود که با فلسفه نانس همسو است.

دلایل رایج این «شکست‌های خاموش» عبارت‌اند از:

• اتصال Language Server به پوشه‌های محلی در حالی که شل (Shell) به یک سرور راه دور متصل است.
• استفاده کانتینرها از یک کپی قدیمی و سطحی (Shallow copy) از یک کلون قدیمی به عنوان دایرکتوری کاری.
• نوشتن عامل در پوشه‌ای هم‌نام با هدف اما در یک مسیر موازی (Sibling folder).
• وجود سه ساعت متضاد: ساعت ویرایشگر لپ‌تاپ، ساعت جلسه SSH/مرورگر، و دید مدل که فقط نتایج ابزارها را می‌بیند.

برای تیم‌های Node.js، یک نسخه پیشرفته‌تر و سخت‌گیرانه‌تر به نام prove_path.mjs پیشنهاد شده است. این نسخه از realpathSync و git rev-parse --show-toplevel استفاده می‌کند تا مطمئن شود دایرکتوری کاری شل دقیقاً با ریشه واقعی Git مطابقت دارد. توسعه‌دهنده تشویق می‌شود که این اسکریپت را اجرا کرده و خروجی JSON حاصل را در چت قرار دهد تا مدل مجبور شود به همان شیئی نگاه کند که انسان می‌بیند.

تأییدیه گام دوم

برای شناسایی باگ‌های سخت‌تر و گریزان‌تر، یک «پرش دوم» (Second Hop) تعریف شده است. پس از تأیید نانس اولیه، توسعه‌دهنده از عامل می‌خواهد یک تغییر بسیار کوچک اعمال کند: اضافه کردن خط دوم به فایل نانس با متن patched-by-agent.

این مرحله عامل‌هایی را شناسایی می‌کند که می‌توانند یک‌بار از طریق یک Stub بنویسند اما در ویرایش‌های بعدی به‌طور خاموش سیستم‌فایل (Filesystem) را تغییر می‌دهند. این کار از ایجاد «داستان‌های شکست» (Novella of failure) جلوگیری می‌کند؛ جایی که مدل فایل src/index.ts را از یک درخت کش‌شده (Cached tree) لیست می‌کند اما پچ را در پوشه‌ای موازی می‌نویسد. اگر عامل نتواند این محدودیت کوچک را رعایت کند، نباید برای بازنویسی یک ماژول حساس احراز هویت مورد اعتماد قرار گیرد.

یکپارچه‌سازی و بهداشت کد

برای اینکه این تست Probe تبدیل به یک مزاحمت نشود، توصیه می‌شود فایل .agent-nonce پیش از شروع جلسه به فایل .gitignore اضافه شود. این کار تضمین می‌کند که فایل تأییدیه هرگز به‌طور تصادفی وارد یک کامیت، یک Pull Request یا یک «شرمندگی به شکل سکرت» (Secret-shaped embarrassment) نشود.

رعایت این قانون نادیده گرفتن (Ignore) بخشی از خودِ ریتوال است و نه یک فکر بعدی. اگر عامل نتواند محدودیت .gitignore را رعایت کند، این یک درس ارزان‌قیمت درباره محدودیت‌های مدل است، پیش از آنکه یک ریلیز خراب و فاجعه‌بار اتفاق بیفتد.

تحلیل: تغییر معیار پذیرش

این رویکرد تعریف «پذیرش موفق» (Successful onboarding) یک عامل AI را تغییر می‌دهد. اکثر محصولات، اولین تابع تولید شده را جشن می‌گیرند، اما این متدولوژی استدلال می‌کند که «هویت» باید مقدم بر «هوش» باشد. صفحات خوش‌آمدگویی مدل‌ها اغلب شبیه لابی هتل‌ها درباره منظره اقیانوس حرف می‌زنند، اما واقعیت‌های تلخ Bind Mountها و کلون‌های حذف شده که در دقیقه دوازدهم ظاهر می‌شوند را نادیده می‌گیرند.

برای یک توسعه‌دهنده عملی، این یعنی ۱۵ دقیقه اول هر جلسه باید به عنوان یک «دروازه عبور» (Gate) دیده شود، نه یک گرم‌کردن ساده یا کمدی. مواجهه با یک پیام «FAIL» صریح در چت، بسیار ارزان‌تر از این است که یک ساعت وقت بگذارید و متدی زیبا را بررسی کنید که در دایرکتوری‌ای قرار گرفته که امشب تصادفی حذفش خواهید کرد.

محدودیت‌ها و دامنه کاربرد

باید توجه داشت که این چرخه نانس یک چراغ‌قوه است، نه یک جدول رده‌بندی (Leaderboard). این تست موارد زیر را ثابت نمی‌کند:

• صحت کد تولید شده.
• امنیت سرور راه دور.
• پایداری لایه‌های رایگان (Free tier).
• تأخیر (Latency) یا رتبه مدل.

یک جلسه می‌تواند تست نانس را پاس کند اما همچنان نسخه Node اشتباه داشته باشد، فایل‌های Secret آن ناقص باشد یا ساعت سیستمش به‌هم ریخته باشد که باعث فاسد شدن URLهای امضا شده (Signed URLs) شود. این یک معماری ایزولاسیون تولیدی (Production isolation) نیست؛ اگر نمی‌توانید سرور را به‌راحتی دور بریزید، نباید با یک سرور رایگان مثل یک ایستگاه کاری دائمی رفتار کنید.

چه کسانی این ریتوال را نادیده بگیرند؟

برخی کاربران ممکن است نیازی به این فرآیند نداشته باشند:

• توسعه‌دهندگانی که در Imageهای توسعه راه دور قفل‌شده کار می‌کنند که در آن‌ها Mount تغییرناپذیر است و ویرایشگر از اساس به آن متصل است.
• کسانی که با داده‌های حساس و رگوله‌شده کار می‌کنند و نمی‌توانند فایل‌های نانس کنار رکوردهای مشتریان بسازند یا ترنسکریپت‌ها را در مدل‌های میزبانی‌شده قرار دهند.
• کاربران IDEهای مدیریت‌شده که نقشه‌های فضای کاری (Workspace Maps) آن‌ها توسط فروشنده کنترل می‌شود.

برای بقیه که در «میانه آشفته» (Messy middle) هستند — جایی که یک سرور رایگان، یک ویرایشگر محلی و یک مدل، فقط در نام پروژه مشترک‌اند و هیچ چیز دیگری را به اشتراک نمی‌گذارند — این ریتوال ضروری است. اگر عامل شکست خورد، توصیه می‌شود جلسه را فوراً متوقف کنید، Mount یا Clone را اصلاح کنید و با یک پرامپت سرد (Cold Prompt) دوباره شروع کنید، به‌جای اینکه با مدل درباره لحنش بحث کنید.

گام بعدی شما

• اسکریپت prove_path.sh را در ریشه پروژه‌های خود قرار دهید و هر بار پیش از شروع بازنویسی‌های گسترده، آن را اجرا کنید.
• فایل .agent-nonce را به .gitignore اضافه کنید تا از ورود فایل‌های تست به مخزن کد جلوگیری شود.
• در صورت مشاهده تضاد بین خروجی pwd مدل و ویرایشگر، جلسه را بدون بحث با مدل، ری‌استارت کنید.

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