چرا گزارش‌های چت عامل‌های هوش مصنوعی با واقعیت دیسک متفاوت است؟

تصور کنید کدی را به یک عامل هوش مصنوعی می‌سپارید و او با اطمینان می‌گوید «تست‌ها پاس شدند»، اما وقتی ترمینال را باز می‌کنید، هیچ فایلی تغییر نکرده است. این شکاف خطرناک بین «روایت مدل» و «واقعیت دیسک»، بسیاری از توسعه‌دهندگان را به تله‌ای می‌کشاند که در آن تیک سبز رابط کاربری، جایگزین کد واقعی شده است. برخی این پدیده را «دور افتخار» (The victory lap) می‌نامند؛ وضعیتی که در آن مدل یک فراخوانی ابزار (Tool Call) را چاپ می‌کند و کاربر تصور می‌کند کد ارسال شده است، در حالی که git status همچنان پاک است و هیچ تغییری در واقعیت رخ نداده است.

به گزارش یک راهنمای فنی که در تاریخ ۴ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این تمایل به اعتماد به متن چت‌ها بیش از فایل‌سیستم، شکافی خطرناک بین پیشرفت ادراکی و پیشرفت واقعی ایجاد می‌کند. در نهایت، یک تیک سبز در رابط کاربری یک عامل هوش مصنوعی به این معنا نیست که کد شما واقعاً روی دیسک نوشته شده است.

این بحران اعتبارسنجی درست زمانی رخ می‌دهد که گردش‌های کاری عامل‌محور (Agentic) از چت‌های ساده به مدیریت خودکار مخازن کد منتقل می‌شوند. بسیاری از برنامه‌نویسان خروجی عامل را به عنوان دفتر کل حقیقت می‌بینند، در حالی که مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در واقع یک «راوی» است، نه یک کامپایلر. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی توهمات مدل‌های زبانی اشاره کردیم، مدل‌ها تمایل دارند موفقیت را روایت کنند، حتی اگر عملیاتی نشده باشد. این وضعیت شبیه خلبانی است که به نمایشگر شبیه‌ساز اعتماد می‌کند در حالی که هواپیما هنوز روی باند فرودگاه است. این شکاف با رابط‌های کاربری (UI) عامل‌ها عمیق‌تر می‌شود که فایل‌های JSON را طوری رندر می‌کنند که گویی یک کامیت گیت هستند و بدین ترتیب کاربران را آموزش می‌دهند که بررسی فایل‌سیستم را کاملاً کنار بگذارند.

پنج باور غلط در گردش‌های کاری عامل‌محور

طبق گزارش dev.to، پنج تصور رایج و تکرار شونده وجود دارد که منجر به شکست در محیط عملیاتی می‌شود. هر یک از این باورها توسط یک رفتار خاص در رابط کاربری تقویت می‌شود و برای اصلاح آن، نیاز به یک مدل ذهنی جدید است:

• توهم نوشتن JSON (The JSON Write Myth): کاربران تصور می‌کنند فراخوانی ابزار write_file لزوماً فایلی ایجاد کرده است.

  • چرا گسترش می‌یابد: رابط‌های کاربری عامل‌ها روی این فراخوانی یک تیک سبز نمایش می‌دهند. این تیک فقط به این معناست که مدل یک JSON با ساختار درست تولید کرده است؛ به این معنا نیست که اجراکننده (Runner) واقعاً عملیات نوشتن را روی دیسک اعمال کرده است.
  • روش بررسی: دستور test -f PATH && echo "exists" || echo "missing" را اجرا کنید و سپس از stat -c '%y %s %n' PATH و git status --porcelain -- PATH استفاده کنید. اگر مسیر گم شده باشد یا وضعیت گیت خالی باشد، متن چت دروغ گفته است.
  • مدل ذهنی اصلاح‌شده: با هر فراخوانی ابزار تنها به عنوان یک «پیشنهاد» برخورد کنید. JSON به تنهایی هرگز یک اثر جانبی (Side Effect) ایجاد نمی‌کند؛ تنها اجراکننده است که می‌نویسد و دیسک تنها مدرک است.

• توهم پایداری (The Persistence Myth): این باور رایج که سرورهای ابری رایگان، درخت کاری (Working Tree) را حفظ می‌کنند.

  • چرا گسترش می‌یابد: حافظه عضلانی ما از کار با SSH القا می‌کند که دیسک‌های ابری پایدار هستند. اما یک سرور رایگان اغلب فقط یک Runner موقت است.
  • روش بررسی: قبل از ترک Runner، دستورات pwd ،git rev-parse --show-toplevel ،git status --porcelain ،git log -1 --oneline و ls -la را اجرا کنید. یک لیست خالی در porcelain به همراه مسیر گم شده، نشان‌دهنده «فراموشی» سرور است.
  • مدل ذهنی اصلاح‌شده: فضای ذخیره‌سازی موقت (Scratch storage) یک فضای کاری واقعی نیست. تاریخچه چت، بک‌آپ درخت کد شما نیست؛ یا با گیت ذخیره کنید یا انتظار نداشته باشید فایل‌ها بعداً موجود باشند.

• توهم «اتمام کار» (The 'Done' Myth): وقتی عامل روایت می‌کند که تست‌ها پاس شدند، اغلب فقط در حال داستان‌سرایی است.

  • چرا گسترش می‌یابد: مدل‌ها عاشق روایت موفقیت به زبان ساده هستند چون روایت ارزان است، در حالی که اجرای واقعی pytest هزینه (زمانی و پردازشی) دارد.
  • روش بررسی: دستور تست را به صورت دستی بازپخش کنید (مثلاً python -m pytest -q) و کد خروجی را چاپ کنید: echo "exit:$?". سپس git diff --stat را اجرا کنید.
  • مدل ذهنی اصلاح‌شده: موفقیت یعنی یک کد خروجی (Exit Code) که قابل بازپخش باشد. جمله‌ای که حاوی کلمه «پاس شد» است، همچنان فقط یک جمله است.

• توهم قابلیت جابه‌جایی ابزارها (The Tool Portability Myth): توسعه‌دهندگان تصور می‌کنند با تعویض مدل (مثلاً از یک ارائه‌دهنده به ارائه‌دهنده دیگر)، عملکرد ابزارها حفظ می‌شود.

  • چرا گسترش می‌یابد: طرح‌های (Schemas) سبک OpenAI قابل جابه‌جایی به نظر می‌رسند. در حالی که نام‌ها مطابقت دارند، فیلدهای مورد نیاز اغلب متفاوت‌اند؛ یک مدل ممکن است مسیر را حذف کند در حالی که مدل دیگر یک فلگ (Flag) خیالی اختراع کند.
  • روش بررسی: لاگ‌های JSONL را نگه دارید و دو مدل را روی یک پرامپت با اسکریپتی مانند schema_diff.py مقایسه کنید تا کلیدهای arguments را بسنجید. آن را به صورت python schema_diff.py model_a.jsonl model_b.jsonl اجرا کنید.
  • مدل ذهنی اصلاح‌شده: طرح ابزارها متعلق به «قرارداد استقرار» (Deployment Contract) است. شناسه مدل و طرح را با هم پین (Pin) کنید و این قرارداد را در هر جابه‌جایی قبل از ادغام (Merge) بررسی کنید.

• توهم همگرایی (The Convergence Myth): این باور که تکرارهای رایگان (Free Retries) در نهایت منجر به وضعیت درست مخزن می‌شود.

  • چرا گسترش می‌یابد: تکرارها رایگان به نظر می‌رسند، بنابراین امیدواری ارزان است. اما حلقه‌ها باعث تقویت موفقیت‌های ساختگی می‌شوند و در واقع جستجو نمی‌کنند؛ مدل صرفاً داستان درخت کاری را بازنویسی می‌کند.
  • روش بررسی: حلقه را محدود کنید (مثلاً N=3) و هر چند دور یک‌بار با استفاده از git status --porcelain و git diff --stat ممیزی کنید. اگر وضعیت porcelain نوسان داشت اما تغییر واقعی در diff نبود، متوقف شوید.
  • مدل ذهنی اصلاح‌شده: تکرارها فقط زمانی کمک می‌کنند که یک «راهنمای حقیقت» (Oracle) وجود داشته باشد. وضعیت گیت و تست‌ها Oracle هستند؛ چت نیست. یک حلقه رایگان بدون Oracle فقط یک «فن‌فیکشن» (Fan Fiction) است.

پیاده‌سازی ممیزی مفروضات

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

گام اول: ثبت پیشنهادها، نه حس‌ها
هر فراخوانی ابزار را قبل از هرگونه اجرا در یک فایل JSONL بنویسید. این کار یک سابقه از «قصد» (Intent) ایجاد می‌کند. این رویکرد ثبت دقیق تصمیمات پیش‌تر نشان داده است که چگونه لاگ‌های ساختاریافته می‌توانند خطاهای منطقی پنهان در خط لوله‌های هوش مصنوعی را افشا کنند. یک اسکریپت پیشنهادی مانند log_call.py باید برچسب زمانی، نام ابزار و آرگومان‌ها (مثلاً write_file برای README.md) را ثبت کند و این اسکریپت را قبل از اجرای هر ابزار در Runner قلاب (Hook) کنید. اگر نتوانید پیشنهاد را ثبت کنید، نمی‌توانید بعداً آن را ممیزی کنید.

گام دوم: تطبیق با گیت
مسیرهای ادعا شده را از ریشه مخزن با گیت تطبیق دهید. با استفاده از اسکریپتی مانند reconcile.py توسعه‌دهندگان می‌توانند مسیرها را از فراخوانی‌های write_file ،edit_file یا apply_patch در لاگ JSONL استخراج کرده و آن‌ها را با git status --porcelain مقایسه کنند. استفاده از قلاب‌های بومی گیت در ابزارهایی مانند oh-my-agent نیز راهکاری برای حل چالش‌های انتساب کد و مدیریت دقیق تغییرات توسط عامل‌هاست. این کار چهار لیست حیاتی تولید می‌کند:

1. مسیرهای ادعا شده (Claimed paths)
2. مسیرهای تغییر یافته/کثیف (Dirty paths)
3. مسیرهای ادعا شده که روی دیسک گم شده‌اند
4. مسیرهایی که ادعا شده تغییر کرده‌اند اما با وجود حضور روی دیسک، Dirty نیستند

گام سوم: جدول تصمیم‌گیری
اعتماد را با یک جدول تصمیم‌گیری جایگزین کنید. هرگاه چت و جدول در تضاد بودند، جدول برنده است:

نقش زیرساخت‌های رایگان

این راهنما اشاره می‌کند که ابزارهایی مانند MonkeyCode که دسترسی رایگان به مدل و سرور می‌دهند، باید به عنوان محیط‌های آزمایشی (Scratch Harnesses) دیده شوند، نه محیط‌های کاری پایدار. (افشا: این مقاله به عنوان بخشی از فعالیت‌های ترویجی محصول MonkeyCode تهیه شده است).

در این گردش کار، از مدل رایگان برای تولید JSON ابزار جهت بازرسی استفاده می‌شود و از سرور رایگان برای اجرای reconcile.py در محیط ایزوله. برای سنجش واقعی امنیت این محیط‌ها، می‌توان از ابزارهای ممیزی سیستم‌فایل مانند Tripwire استفاده کرد تا نفوذهای احتمالی عامل به خارج از محیط ایزوله شناسایی شود. هیچ‌کدام فضای کاری پایداری نیستند (ارجاع به توهم دوم). اگر این گزینه‌ها کافی نبودند، نویسنده توصیه می‌کند به صورت محلی (Local) اجرا کنید، زیرا این گردش کار به برند خاصی وابسته نیست.

تحلیل: تغییر از «حس‌ها» به «راهنماهای حقیقت»

این تغییر دیدگاه، توسعه با هوش مصنوعی را از مهندسی «مبتنی بر حس» (Vibes-based) به یک مدل «محور اعتبارسنجی» منتقل می‌کند. برای یک توسعه‌دهنده عمل‌گرا، این بدان معناست که رابط کاربری چت دیگر رابط اصلی برای تشخیص موفقیت نیست؛ بلکه ترمینال و دفتر کل گیت هستند. اثر مرتبه دوم این تغییر، افزایش ضروری «اصطکاک» در کدنویسی با AI است — یعنی مجبور کردن انسان به بازپخش دستی دستورات برای اطمینان از اینکه عامل در حال نوشتن فن‌فیکشن درباره کدبیس نیست.

البته این ممیزی محدودیت‌هایی دارد. این روش باگ‌های عمیق معنایی (Semantic) را نمی‌گیرد، زیرا یک فایل می‌تواند روی دیسک وجود داشته باشد اما همچنان غلط باشد. وضعیت گیت نمی‌تواند یک الگوریتم بد را تشخیص دهد، diffهای طرح ابزار نمی‌توانند ثابت کنند که یک ابزار امن است و حلقه‌های کوتاه ممکن است تست‌های ناپایدار (Flaky) در CI را نادیده بگیرند. در نتیجه، این چک‌لیست نباید به عنوان بازبینی امنیتی، ممیزی لایسنس یا مانیتورینگ محیط عملیاتی استفاده شود.

در نهایت، عامل یک «موتور پیشنهاد» است. اجراکننده (Runner) بازیگر اصلی است و دیسک تنها مدرک است. با پین کردن شناسه‌های مدل و طرح‌ها به عنوان یک قرارداد استقرار، تیم‌ها می‌توانند جلوی شکست‌های خاموش ناشی از تعویض مدل را بگیرند. این رویکرد برای کسانی که از قبل مدل‌ها را پین کرده و CI را بازپخش می‌کنند، یا کسانی که فقط به چت بدون مخزن نیاز دارند، ضروری نیست.

برای شروع ایمن‌سازی گردش کار خود، سعی کنید از امروز بعد از هر نوبتِ پاسخِ عامل، دستور git status --porcelain را اجرا کنید تا ببینید آیا دیسک واقعاً تکان خورده است یا خیر. به یاد داشته باشید: متن چت یک داستان است، اما گیت یک دفتر کل است.

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