تصور کنید یک عامل هوش مصنوعی به شما گزارش میدهد که تمام تستهای نرمافزاری با موفقیت پاس شدهاند، اما در واقع هیچ کدی روی ماشین اجرا نشده است. این شکاف خطرناک میان «گزارش موفقیت» و «اجرای واقعی»، بزرگترین نقطه ضعف فعلی در اعتماد ما به لاگهای عاملهای هوش مصنوعی است. این پرسش که «آیا آن بیلد واقعاً روی یک ماشین اجرا شد یا مدل فقط یک بیلد را توصیف کرد؟» یک نقص بنیادی را در نحوه اعتماد ما به لاگهای عاملهای AI آشکار میکند. این تضاد میان گزارشات متنی و واقعیتهای سیستمی را در تحلیل پیشین خود درباره تفاوت لاگهای چت با وضعیت واقعی دیسک بررسی کرده بودیم.
به نقل از گزارشهای فنی اخیر، وقتی یک عامل ادعا میکند که یک مجموعه تست را اجرا کرده، اغلب صرفاً در حال پیشبینی توکنهای (Tokens) — شبیه تکههای کوچکی از متن که مدل تکهتکه میخورد — مربوط به یک نتیجه موفق است، نه اینکه کد خروج (Exit Code) واقعی یک پردازش را از هسته سیستمعامل گزارش کند. این اشتباه زمانی رخ میدهد که توسعهدهندگان یک دستور را کپی میکنند و سپس با خروجی استاندارد (stdout) مانند یک میزبان واقعی برخورد میکنند. این جهش ذهنی همان باگ اصلی است و به این معناست که لاگهای شما احتمالاً در حال دروغ گفتن به شما هستند.
این موضوع در حالی اهمیت مییابد که استقرار عاملهای خودمختار در محیطهای عملیاتی افزایش یافته است. ریشه این مشکل در فروپاشی سه لایه عملیاتی متمایز است: لایه مدل (پیشبینی توکن)، لایه ابزار (ارسال تابع) و لایه میزبان (اجرای واقعی پردازش). برای درک عمیقتر این تفکیک، ساختار سهلایه عاملهای هوش مصنوعی و دلیل ناکافی بودن مدل به تنهایی را مطالعه کنید.
درک سه لایه عملیاتی
برای جلوگیری از شکستهای سیستمی، باید این سه تعریف را بهطور دقیق تفکیک کرد و شاید بهتر باشد آنها را روی یک یادداشت چسبان در مقابل چشم داشته باشید:
- لایه مدل (Model Plane): مسئول مدیریت متن و پیشبینی توکنها است. این لایه شامل تولید خروجیهای جعلی برای دستورات است.
- لایه ابزار (Tool Plane): بهعنوان یک واسطه (Broker) عمل میکند که فراخوانی تابع (Function Calling) را میپذیرد.
- لایه میزبان (Host Plane): تنها لایهای که در آن هسته سیستمعامل واقعاً یک پردازش را آغاز میکند. تنها این لایه است که دارای نام میزبان (Hostname) است.
بسیاری از توسعهدهندگان تاریخچه چت را منبع حقیقت میدانند. اما در واقعیت، یک گزارش «سبز» در پنجره چت ممکن است در لایه مدل متوقف شده باشد، جایی که هوش مصنوعی صرفاً یک بیلد موفق را توصیف کرده بدون اینکه هرگز کامپایلر را فعال کند. یک JSON ابزار نیز ممکن است در لایه ابزار متوقف شود. MonkeyCode پیشنهاد میکند مدل ذهنی را تغییر دهیم: مدل صرفاً یک «پیشنهاددهنده» است و میزبان تنها «اجراکننده». هرگز این دو هویت را در یک گزارش ادغام نکنید. بعد از هر اجرای عامل، این سؤال سخت و بیپرده را بپرسید: «کدام میزبان این argv را اجرا کرد؟» اگر پاسخ ندارید، شما یک اجرا ندارید، بلکه یک داستان با علائم نگارشی دارید.
چهار افسانه در اجرای عاملها
بر اساس مستندات این چارچوب، چهار باور غلط یا افسانه اصلی وجود دارد که منجر به شکست در استقرار میشود:
افسانه اول: مدل همان ماشین است.
بسیاری تصور میکنند نقطه اتصال API دستورات بش (Bash) را اجرا میکند. برخی حتی ادعا میکنند که API همان باکس CI است. این نگاه این حقیقت را نادیده میگیرد که یک نقطه اتصال مدل، توکنها را پیشبینی میکند؛ او کامپایلر شما را اسپان (Spawn) نمیکند. موفقیت در توکن به معنای موفقیت در پردازش نیست. یک پاسخ HTTP 200 به معنای یک فراخوانی سیستمی wait(2) نیست.
برای جمعآوری شواهد، شناسه مدل در کلاینت را با نام میزبان در یک فایل رسید مقایسه کنید. اگر این رشتهها یکسان بودند، مشکلی جدی وجود دارد. یک مدل زبانی یک میزبان یونیکس نیست. اگر لاگی دستور printf 'client_host=%s\n' "$(hostname)" را نشان میدهد، این دستور فقط نام باکس کلاینت را میگوید، نه نام اجراکننده (Runner).
افسانه دوم: سرورهای رایگان مشابه لپتاپ شما هستند.
توسعهدهندگان اغلب یک باکس ریموت رایگان را بالا میآورند و تصور میکنند متغیرهای PATH، نسخه Node یا فایلهای .env.local با ماشین محلیشان یکی است. اما تصاویر ریموت پاک (Clean) شروع میشوند. فایلهای ~/.zshrc شما، SSH agent و توکنهای خصوصی npm با «حس خوب» یا به صورت خودکار منتقل نمیشوند. این چالشها نشان میدهد که چرا استفاده از سرورهای رایگان برای شناسایی محدودیتهای AI بر پاسخهای Mock ترجیح دارد.
یک باینری گمشده اغلب شبیه به شکست عامل به نظر میرسد، اما معمولاً فقط یک PATH خالی است. برای تأیید این موضوع، یک اسکریپت env_delta.sh را روی میزبان اجرا — نه در پنجره چت — کنید تا بررسی شود آیا node، python3، make و HOME واقعاً شناسایی (Resolve) میشوند یا خیر.
افسانه سوم: فراخوانی ابزار به معنای تکمیل است.
یک پاسخ JSON موفق از ابزار، لزوماً به معنای خروج پردازش با وضعیت صفر (Status Zero) نیست. واسطهها (Brokers) ممکن است خروجی استاندارد را بهصورت ناقص برگردانند، تایماوتها ممکن است شبیه به پاسخ به نظر برسند و Wrapperها میتوانند SIGPIPE را ببلعند. عبارت «Tool ok» یک وضعیت POSIX نیست. برخی عاملها صرفاً یک دستور را روایت میکنند بدون اینکه هرگز آن را فراخوانی کنند.
افسانه چهارم: توهم مسیر.
مسیری (pwd) که در یک ترنسکریپت چاپ میشود اغلب یک مسیر منطقی است. عاملها وارد ورکتریها (Worktrees) میشوند و فراموش میکنند بازگردند. لینکهای نمادین (Symlinks) دروغ میگویند و کانتینرها مسیر / را بازنویسی میکنند. مسیر منطقی میتواند با مسیر فیزیکی متفاوت باشد، به این معنی که استقرار مسیر منطقی باعث ارسال درخت (Tree) اشتباه میشود.
پیادهسازی سامانه «رسید»
برای عبور از «داستانهای دارای علائم نگارشی»، این راهنما پیشنهاد میکند یک سامانه رسید (Receipt) سختگیرانه پیاده شود. بهجای اعتماد به لاگهای چت، توسعهدهندگان باید از یک اسکریپت پوششی — مانند run_receipt.sh پیشنهادی — استفاده کنند که دادهها را مستقیماً روی میزبان اجرا ذخیره کند.
جزئیات مکانیزم رسید شامل موارد زیر است و اسکریپت run_receipt.sh باید منطق زیر را اجرا کند:
- شناسه منحصربهفرد: تولید یک
receipt_idبا استفاده از تاریخ UTC و شناسه پردازش (مثلاً$(date -u +%Y%m%dT%H%M%SZ)-$). - یکپارچگی دستور: محاسبه هش SHA-256 از
argvدقیق با استفاده ازsha256sumیاshasum -a 256. - متادیتای میزبان: ثبت
hostname،whoami،pwdوuname -srm. - کنترل نسخه: ثبت نسخه فعلی گیت با دستور
git rev-parse HEAD. - حقیقت محض: ثبت وضعیت خروج واقعی (
$?) بلافاصله پس از اجرای دستور.
با الزام به وجود یک فایل فیزیکی در پوشه /tmp بهعنوان مدرک اجرا، تیمها دیگر بر اساس توصیفات چتبات، درخواستهای ادغام (PR) را تایید نمیکنند. اگر فایل رسید گم شده باشد، یعنی لایه ابزار هرگز به لایه میزبان نرسیده است. من اسکرینشاتهای چت را بهعنوان مدرک نمیپذیرم؛ من فایلی را میخواهم که میزبان نوشته باشد.
اعتبارسنجی محیط
عدم تطابق محیط یکی از دلایل اصلی «شکست عامل» است که در واقع فقط یک PATH گمشده است. این گزارش پیشنهاد میکند اسکریپت env_delta.sh روی میزبان اجرا شود تا تأیید شود باینریهایی مانند Node یا Python واقعاً Resolve میشوند.
برای اطمینان از یکپارچگی دایرکتوری، توصیه میشود مسیر فیزیکی با استفاده از pwd -P تثبیت شود و یک فایل شناختهشده (مانند README.md) هش شود. این ثابت میکند که عامل واقعاً در مخزن درست بوده و نه در یک بازنویسی موقت کانتینر. همچنین از دستور git status --porcelain | wc -l برای بررسی dirty_lines استفاده کنید. اگر تعداد صفر نباشد، میزبان ویرایشهای ثبتنشدهای دارد که چت هرگز به شما نخواهد گفت.
جدول تصمیمگیری برای ادغام
برای حذف مهندسی بر اساس «حس» (Vibe Coding)، نویسنده یک فیلتر سختگیرانه برای ادعاهای عامل پیشنهاد میکند:
| ادعا در ترنسکریپت | نیاز قبل از باور کردن | شکست در صورت نبود |
|---|---|---|
| «دستور را اجرا کردم» | نام میزبان + هش argv + وضعیت خروج | نبود فایل رسید |
| «تستها پاس شدند» | خروج ۰ از اجراکننده تست | فقط متن مدل |
| «در شاخه main هستیم» | git rev-parse HEAD روی آن میزبان |
نام شاخه در چت |
| «سکرتها در دسترس بودند» | نامهای صریح کلیدها (هرگز مقادیر نه) | فرض بر وجود .env |
| «مشابه محیط محلی است» | uname به علاوه نسخههای ابزار | PATH ریموت خالی |
هنگام تأیید سکرتها، نامها را دامپ کنید، نه مقادیر را. از بررسیهایی مانند if test -n "${DATABASE_URL:-}"; then echo DATABASE_URL=set; fi استفاده کنید تا ثابت شود نام وجود دارد بدون اینکه مقدار سکرت چاپ شود.
تمرین یکساعته برای تیمها
ابتدا پرامپتها را تنظیم نکنید. تفکیک میزبان را با این تمرین تمرین کنید:
۱. یک شل ریموت پاک باز کنید و یک مخزن کوچک را کلون کنید.
۲. اسکریپت run_receipt.sh را در مخزن قرار دهید.
۳. از عامل بخواهید دستورات ./run_receipt.sh true و سپس ./run_receipt.sh false را اجرا کند.
۴. خودتان هر دو رسید را cat کنید. از عامل نخواهید که آنها را خلاصه کند.
۵. تأیید کنید که نام میزبانها مطابقت دارد و خروجیها به ترتیب ۰ و ۱ هستند.
اگر عامل از اجرای اسکریپت پوششی اجتناب کرد یا یک مسیر رسید جعلی ساخت که در /tmp وجود ندارد، شما نقص واقعی خود را یافتهاید. عادت استفاده از Wrapper را قبل از اصلاح مدل درست کنید.
محدودیتها و دامنه
این سامانه رسید یک ابزار آموزشی است، نه یک لاگ حسابرسی رمزنگاریشده. یک پردازش میتواند نام میزبان را جعل کند، یک کانتینر میتواند uname را جعل کند و کاربران root میتوانند /tmp را ویرایش کنند. این سیستم خروجیهای شبکه (Network Egress) را ردیابی نمیکند و مشکل اختلاف ساعت را حل نمیکند (اگرچه date -u کمک میکند). این رویکرد مبتنی بر POSIX برای میزبانهای ویندوزی به اسکریپتهای متفاوتی نیاز دارد.
اگر در حال حاضر CI هرمنتیک (Hermetic) دارید یا فایلهای Workflow را بررسی میکنید، این موارد را نادیده بگیرید. این جایگزینی برای ایزولاسیون چند-مستاجری یا یک تیم سندباکس واقعی نیست. اگر عامل شما اصلاً نمیتواند شل را اجرا کند، لایه مدل نمیتواند یک هسته (Kernel) رشد دهد.
این تغییر در عمل، فرض بنیادی جریانهای کاری عاملمحور را تغییر میدهد. این صنعت را از «مشاهده» رفتار AI به سمت «حسابرسی» وضعیت سیستم میبرد. برای توسعهدهنده، این یعنی تفاوت بین یک استقرار پایدار و یک شکست فاجعهبار ناشی از یک پیام موفقیت توهمآمیز. از درخواست خلاصه نتایج از عامل دست بردارید و خودتان فایلهای /tmp را بخوانید.
گام بعدی شما
- اسکریپتهای اجرای خود را با یک لایه ثبت رسید (Receipt) در
/tmpتجهیز کنید تا از اجرای واقعی دستورات مطمئن شوید. - هرگز خروجی چتبات را بهعنوان مدرک برای ادغام کد (Merge) نپذیرید و مستقیماً وضعیت خروج (Exit Status) را چک کنید.
- با اجرای
env_delta.shروی میزبان، تفاوت متغیرهای محیطی ماشین محلی و ابری را شناسایی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو