هر بار که یک عامل هوش مصنوعی گزارش میدهد «تستها با موفقیت پاس شدند»، باید فرض کنید این ادعا تا زمان اثبات، 거짓 است. این هشدار جدی در راهنمای فنی منتشر شده در ۱۸ سپتامبر ۲۰۲۶ در وبسایت dev.to مطرح شد؛ گزارشی که ادعا میکند توسعهدهندگان بهطور معمول درباره وضعیت میزبانیهای پیشنویس (Scratch Hosts) — محیطهای موقتی که عاملهای هوش مصنوعی در آن کد اجرا میکنند — خودشان را فریب میدهند.
بسیاری از برنامهنویسان تصور میکنند شروع یک جلسه چت جدید، شبیه به روشن کردن یک کامپیوتر کاملاً نو و استریل است. این یک تصور خطرناک و اشتباه است. در جریانهای کاری واقعی توسعه نرمافزار، یک جلسه (Session) صرفاً یک دستگیره یا شناسه برای گفتگو است، در حالی که سیستم فایل (Filesystem) از بلوکهای ماندگاری روی دیسک تشکیل شده است. این دو ساعت (زمانسنج) با هم ریست نمیشوند؛ به این معنا که عامل شما اغلب «ارواح» و بقایای وظایف قبلی را به ارث میبرد.
تصور کنید وارد آشپزخانهای میشوید که تازه یک مراسم پذیرایی بزرگ در آن برگزار شده است. حتی اگر یک سرآشپز جدید (عامل هوش مصنوعی) بیاورید، میزها هنوز چسبناک هستند و سطل زباله پر است. اگر سرآشپز بگوید غذا عالی شده، شما نمیدانید این نتیجه مهارت اوست یا چون از مواد باقیمانده از مهمانی قبلی استفاده کرده است.
زمینه شکست عاملها (The Context of Agent Failure)
عاملها به روشهایی خستهکننده و محلی شکست میخورند. آنها معمولاً به دلیل یک خطای منطقی پیچیده در مدل زبانی بزرگ (LLM) شکست نمیخورند، بلکه دلیل آن چیزهایی مثل حافظههای پنهان (Cache) قدیمی، فایلهای .env منقضی شده یا یک فایل قفل (Lockfile) است که از یک شاخه (Branch) متفاوت کپی شده است. وقتی یک توسعهدهنده عبارت «تستها پاس شدند» را در یک رشته گفتگو میبیند، بهندرت از خود میپرسد که آن تستها دقیقاً چه ساختار فایلی (File Tree) را مشاهده کردهاند. این مسئله در واقع ادامه بحثی است که پیشتر درباره توهمات مربوط به لاگهای عاملها و عدم اعتبار آنها به عنوان مدرک اجرا بررسی کردیم.
به همین دلیل، یک میزبان یکبارمصرف (Throwaway Host) لزوماً یک اتاق استریل نیست. برای تبدیل این موضوع از سطح «شنیدهها و باورهای عامیانه» به «مهندسی»، توسعهدهندگان باید هر ادعای موفقیت (Green Claim) را تا زمان بررسی هش (Hash) دیسک، مشکوک بدانند. هدف این است که وضعیت دیسک در لحظه شروع (T0) ثابت شود تا نتیجه نهایی در لحظه پایان (T1) واقعاً قابل توضیح و تحلیل باشد.
پنج توهم محیطهای عامل (The Five Myths of Agent Environments)
بر اساس گزارش dev.to، پنج باور غلط اصلی وجود دارد که منجر به خروجیهای غیرقابل اعتماد هوش مصنوعی میشود:
- توهم جلسه پاک (The Clean Session Myth): این باور که یک جلسه جدید برابر است با یک دیسک خالی. در واقعیت، دایرکتوریها، حافظههای پنهان بستهها (Package Caches) و فایلهای Swap ویرایشگر در طول چتهای مختلف باقی میمانند. عامل از نقطه صفر ریاضی شروع نمیکند، بلکه از هر چیزی که آخرین مستأجر محیط بر جای گذاشته است شروع میکند.
- توهم وضعیت گیت (The Git Status Myth): فرض بر این است که اگر دستور
git statusخروجی پاکی دارد، پس میزبان هم پاک است. گیت فقط فایلهای ردیابیشده (Tracked) را دنبال میکند. گیت متوجهnode_modules،.env.local، پوشهbuild/یا.pytest_cacheنمیشود. یک عامل میتواند یک فایل باینری خارج از مخزن یا یک شنونده (Listener) روی پورت ۳۰۰۰ باقی بگذارد، بدون اینکهgit statusهرگز هشداری بدهد. - توهم تطابق محلی (The Local Match Myth): این فرض که اجرای دستور
installباعث میشود میزبان دقیقاً با لپتاپ محلی شما مطابقت داشته باشد. میزبانهای پیشنویس و لپتاپها هر دو دچار «رانش» (Drift) میشوند. وابستگیهای اختیاری بر اساس سیستمعامل و CPU تغییر میکنند. بدون نسخههای تثبیتشده (Pinned) زمان اجرا و هشهای فایل قفل، داشتن یک نام پوشه مشابه به معنای داشتن یک درخت فایل مشابه نیست. این چالشها شباهت زیادی به برخی باورهای غلط درباره استکهای رایگان هوش مصنوعی دارد که در نهایت منجر به شکست در استقرار محیطهای عملیاتی میشوند. - توهم پاکسازی با توقف (The Stop-Wipe Myth): این ایده که متوقف کردن حلقه اجرای عامل، تمام اثرات جانبی را از بین میبرد. کشتن یک پردازش والد (Parent Process) لزوماً تمام پردازشهای فرزند را نمیکشد. سرورهای پسزمینه، File Watcherها و کانتینرها اغلب زنده میمانند، پورتها را اشغال میکنند و جلسه بعدی را آلوده میکنند.
- توهم همگامسازی درخت (The Tree Sync Myth): باور به اینکه پوش کردن یک شاخه به این معنا است که عامل دقیقاً همان کامیت را میبیند. عاملها اغلب فقط چند فایل را با دستور
catمیخوانند اما بهندرت ثابت میکنند که کامیت خاصی را مشاهده کردهاند. آنها ممکن است در حال خواندن یک درخت کاری کثیف (Dirty Worktree) یا پچهای ثبتنشده از جلسه قبلی باشند.
پیادهسازی موجودی قابل بازپخش (Implementing a Replayable Inventory)
برای مقابله با این شکستها، این راهنما رویکرد «ساندویچی» را برای اجرای عامل پیشنهاد میدهد. بهجای تکیه بر «بررسی حس» (Vibe Check)، توسعهدهندگان باید یک اسکریپت موجودی فضای کاری (Workspace Inventory Script) را قبل و بعد از هر حلقه اجرای عامل اجرا کنند.
این فرآیند شامل ثبت یک عکس (Snapshot) از میزبان در T0 (قبل از پرامپت) و T1 (بعد از اتمام کار) است. با مقایسه (Diff) این دو اسنپشات، شما میتوانید دقیقاً ببینید چه چیزی روی دیسک تغییر کرده است، بهجای اینکه به خلاصه اقدامات عامل اعتماد کنید.
جزئیات فنی برای سیستم موجودی
برای ساخت یک سیستم موجودی واقعی، مکانیزمها و دستورات زیر توصیه شده است:
- بررسیهای زمان اجرا و محیط (Runtime and Environment Checks):
- ثبت نسخهها با استفاده از دستورات
command -v node && node -vوcommand -v python3 && python3 --version. - لیست کردن نام متغیرهای محیطی (بدون نمایش مقادیر برای محافظت از اسرار/Secrets) با استفاده از
env | awk -F= '{print $1}' | sort.
- ثبت نسخهها با استفاده از دستورات
- تأیید وضعیت گیت (Git State Verification):
- ثبت کامیت دقیق با دستور
git rev-parse HEAD. - استفاده از
git status --porcelain=v1برای داشتن وضعیتی که توسط ماشین قابل خواندن باشد. - شناسایی فایلهای ردیابینشده با دستور
git ls-files -o --exclude-standard | head.
- ثبت کامیت دقیق با دستور
- مانیتورینگ وضعیت سیستم (System State Monitoring):
- حسابرسی پردازشهای فعال:
ps -u "$(id -u)" -o pid,ppid,etime,cmd | head. - بررسی پورتهای باز:
ss -lnt.
- حسابرسی پردازشهای فعال:
- یکپارچگی فایلها (File Integrity):
- تولید هش برای فایلهای قفل:
test -f package-lock.json && sha256sum package-lock.json. - ایجاد یک مانیفست از درخت فایلها با استفاده از
findوsha256sum؛ بهطور خاص نادیده گرفتنnode_modulesو.venvبرای جلوگیری از نویز و تمرکز بر تغییرات سورس کد.
- تولید هش برای فایلهای قفل:
جدول تصمیمگیری اعتماد (The Trust Decision Table)
این گزارش یک چارچوب سختگیرانه برای تصمیمگیری درباره قابل اعتماد بودن یک نتیجه ارائه میدهد. اگر یک چت میگوید «انجام شد»، این هیچ چیز را ثابت نمیکند. اگر تستها پاس شدند، این نتیجه تنها زمانی قابل اعتماد است که کامیت HEAD، محیط اجرا و فایل قفل تثبیت (Pin) شده باشند.
| سیگنال موجود | آنچه در واقعیت ثابت میکند | آیا اعتماد کنیم؟ |
|---|---|---|
| چت گفت «انجام شد» | مدل کلمات تولید کرده است | خیر |
| وضعیت گیت پاک است | فایلهای ردیابیشده با HEAD مطابقت دارند | نه به تنهایی |
| تستها چاپ کردند «پاس شد» | یک Runner چیزی را اجرا کرده است | نه تا زمانی که HEAD، محیط و فایل قفل تثبیت شوند |
| موجودی قبل/بعد مطابقت دارد | تغییرات دیسک محدود و مشخص است | بله، برای این میزبان و این اجرا |
| موجودی موجود نیست | شما یک داستان مشاهده کردید | خیر |
| پورتها هنوز در حال شنود هستند | اثرات جانبی باقی ماندهاند | خیر |
| هش فایل قفل تغییر کرده است | قرارداد وابستگیها جابجا شده است | فقط بعد از خواندن Diff فایل قفل |
تحلیل: هزینه بیلدهای «فولکلور» (The Cost of 'Folklore' Builds)
این تغییر دیدگاه، استفاده از عاملهای هوش مصنوعی را از «داستانسرایی» به «مهندسی» تبدیل میکند. وقتی توسعهدهندگان به خلاصههای چت تکیه میکنند، در حال تمرین فولکلور هستند، نه ساخت نرمافزار. اثر ثانویه این موضوع، انباشت پنهان بدهی فنی (Technical Debt) است؛ جایی که عاملها مشکلاتی را با استفاده از ویژگیهای خاص محیطی (Environment-specific quirks) حل میکنند که هرگز در محیط عملیاتی (Production) کار نخواهند کرد.
برای یک توسعهدهنده کاربردی، این یعنی «افزایش بهرهوری» توسط عاملها اغلب توهمی است که توسط یک دیسک کثیف ایجاد شده است. با اجبار به ثبت موجودی T0، شما مقدار کمی زمان برای تنظیمات هزینه میکنید تا در عوض، یقین پیدا کنید که کد شما واقعاً کار میکند.
برنامه آزمایشی یکساعته پیشنهادی
برای اثبات ناپایداری میزبانهای پیشنویس، این راهنما یک آزمایش کنترلشده روی یک ماشین یکبارمصرف را پیشنهاد میکند:
۱. اسنپشات T0: اجرای اسکریپت موجودی. ثبت دستی کامیت HEAD، نسخههای زمان اجرا و هشهای فایل قفل.
۲. اجرا: درخواست یک تغییر بسیار کوچک و بازگشتپذیر (یک فایل، یک تست) از عامل.
۳. اسنپشات T1: اجرای مجدد اسکریپت موجودی و مقایسه (Diff) نتایج. دور زدن و علامتگذاری هر مسیری که تغییر کرده اما شما صراحتاً درخواست تغییر آن را نداده بودید.
۴. توقف و تأیید: متوقف کردن عامل و ثبت مجدد اسنپشات برای تأیید اینکه پردازشهای فرزند و پورتها واقعاً بسته شدهاند.
۵. بازپخش (Replay): اجرای همان پرامپت برای بار دوم. مقایسه دو فایل «بعد از اجرا» برای اثبات اینکه پرامپت یکسان، لزوماً منجر به پچ (Patch) یکسانی نمیشود.
محدودیتها و هشدارها
این رویکرد جایگزینی برای یک خط لوله کامل CI/CD یا یک بیلد گواهیشده (Attested Build) نیست. اسکریپت موجودی برای جلوگیری از کرش کردن، درختهای طولانی را کوتاه (Truncate) میکند، به این معنی که مخازن بسیار بزرگ ممکن است برخی فایلها را پنهان کنند. علاوه بر این، لیست کردن نام متغیرهای محیطی بدون مقادیر، یک مصالحه ضروری برای جلوگیری از نشت اسرار (Secrets) به لاگهاست، هرچند ممکن است برخی باگهای پیکربندی را پنهان کند.
کسانی که در حال حاضر از بیلدرهای هرمنوتیک (Hermetic Builders) یا ماشینهای مجازی یکبارمصرف (Ephemeral VMs) با قابلیت پاکسازی اثباتشده استفاده میکنند، میتوانند از این روش صرفنظر کنند. همچنین این روش برای کسانی که اعتبارنامههای محیط عملیاتی (Production Credentials) را روی میزبانهای پیشنویس قرار میدهند نیست — موضوعی که راهنما صراحتاً نسبت به آن هشدار میدهد.
گام بعدی شما
این موضوع را با اجرای یک diff بین دو پرامپت کاملاً یکسان روی یک میزبان تست کنید؛ احتمالاً متوجه خواهید شد که پرامپت «یکسان»، تغییرات دیسک متفاوتی ایجاد میکند. میتوانید با پیادهسازی یک بررسی ساده sha256sum روی فایل قفل پروژه قبل و بعد از هر جلسه با عامل شروع کنید. از خود بپرسید: آیا میزبان پیشنویس من واقعاً خالی شروع شد؟ آیا مدل کامیتی را که من پوش کردم دید؟ اگر نمیتوانید پاسخ T0 را بدهید، نمیتوانید T1 را توضیح دهید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو