چرا عامل‌های برنامه‌نویسی خودگردان در محیط‌های واقعی ناکارآمد هستند؟

تصور کنید ساعتی پس از تعریف یک تسک ساده برای بازبینی سیستم احراز هویت، شاهد آن باشید که یک عامل هوش مصنوعی تمام کدها را نابود می‌کند. برای بسیاری از توسعه‌دهندگانی که از OpenClaw استفاده می‌کنند، گذار از دموهای صیقل‌خورده به واقعیتِ تلخِ مخازنی با تست‌های مستند نشده و پرچم‌های ویژگی (Feature Flags) قدیمی، یک شوک واقعی است.

در محیط‌های واقعی، یک تسک تمیز برای بازبینی احراز هویت می‌تواند تنها در ۶ دقیقه به‌دلیل آشفتگی مخزن (Repository) شکست بخورد. اکثر دموهای موجود، «مسیر خوش‌بینانه» را نشان می‌دهند؛ جایی که مدلی مثل Claude یا GPT-4 یک ویژگی را پیاده می‌کند، تست‌ها پاس می‌شوند و همه خوشحال می‌شوند. اما طبق گزارش‌های منتشر شده تا ۱۱ جولای ۲۰۲۶، شکاف میان این کلیپ‌های دست‌چین‌شده و واقعیت تولید، هنوز یک درهٔ عمیق است. مخازن کد واقعی، صفحات سفید نیستند، بلکه سایت‌های باستان‌شناسی از بدهی‌های فنی هستند. این چالش با آنچه پیش‌تر در بررسی دلایل شکست عامل‌های برنامه‌نویسی به دلیل عدم آمادگی مخازن تحلیل کردیم، کاملاً هم‌سو است.

یک مخزن با ساختار مونو-ریپو (Monorepo) — که در آن فایل‌های SDK با کدهای اپلیکیشن مخلوط شده و تست‌های ادغام پنهانی دارد — برای یک انسان، یک روز عادی کاری است. اما برای یک عامل (Agent) — شبیه به کارمندی که فقط دستورات مستقیم را می‌فهمد و هیچ شمّ محیطی ندارد — این وضعیت به معنای شکست فاجعه‌بار در پیش‌فرض‌های اولیه است. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد بیش از حد به منطق داخلی مدل بدون تطبیق با محیط واقعی، ریسک‌های عملیاتی را بالا می‌برد.

دیوار بازرسی مخزن

به نقل از تحلیل وب‌سایت dev.to، نقطه شکست واقعی نه در نوشتن کد، بلکه در بازرسی مخزن است. دموها معمولاً با تسک‌هایی شروع می‌شوند که در اولین کادر ذهنی مدل جای می‌گیرند؛ مثلاً اضافه کردن OAuth یا اصلاح یک تست ناپایدار. این روند تا زمانی کار می‌کند که واقعیتِ مخزن با منطق داخلی عامل در تضاد قرار نگیرد.

مخازن واقعی پر از تله‌هایی هستند که چرخه‌های سادهٔ عامل را می‌شکنند:

• فایل‌های تولیدشده‌ای که هرگز نباید دستی ویرایش شوند.
• محدودیت‌های ترتیب مهاجرت داده (Migration) که عامل قادر به دیدن آن‌ها نیست.
• منطق‌های کسب‌وکار تکراری و پرچم‌های ویژگی قدیمی از ماه‌ها پیش.
• سیستم‌های تست مستند نشده‌ای که رفتار کد را در محیط‌های CI تغییر می‌دهند.

دو حالت شکست عامل

وقتی یک عامل با این تضادها رو‌به‌رو می‌شود، معمولاً وارد یکی از دو حالت شکست می‌شود. حالت اول خطرناک‌ترین است: عامل به اجرای یک برنامهٔ مرده ادامه می‌دهد. در این حالت، کدها تمیز و منطقی به نظر می‌رسند، اما از نظر معماری کاملاً غلط‌اند چون محدودیت‌های واقعی مخزن را نادیده گرفته‌اند. این وضعیت دقیقاً همان «چرخه‌ی مرگ» یا Doom Loop است که چارچوب Agent Rigor با استفاده از سلسله‌مراتب دستوری تلاش می‌کند جلوی توهمات آن را بگیرد.

حالت دوم صادقانه‌تر اما کم‌بازده‌تر است: عامل متوقف می‌شود. مدل با یک ابهام رو‌به‌رو می‌شود — مثلاً اینکه کدام مسیر احراز هویت واقعی است — و عملاً منتظر «نظارت بزرگسالان» می‌ماند. این اتفاق، عامل «خودگردان» را دوباره به یک چت‌بات تبدیل می‌کند که منتظر پرامپت بعدی انسان است.

معماری بقا

خودگردانی تک‌عاملی عمدتاً «سوخت دموها» است. سپردن برنامه‌ریزی، حافظه، بازرسی و بازیابی به یک مدل واحد، ایده‌ای زیباست که به محض kثیف شدن کدبیس می‌شکند. الگوی باورپذیرتر، ساختار «مغز دوقلو» است.

در این مدل، OpenClaw به‌عنوان هماهنگ‌کننده عمل می‌کند و Codex وظیفه پیاده‌سازی عینی را بر عهده می‌گیرد. این کار باعث جداسازی جهت‌گیری بلندمدت از تسک محدودِ نوشتن کد می‌شود.

برای بقا در این محیط‌ها، عامل‌ها به یک فایل وضعیت زنده، مانند GOALS.md نیاز دارند. این یک یادداشت مبهم نیست، بلکه سندی است که موارد زیر را ردیابی می‌کند:
۱. حقایق تأییدشده (مثلاً کدام پوشه‌ها تولیدشده هستند).
۲. پیش‌فرض‌های باطل شده درباره معماری.
۳. فایل‌هایی که واقعاً بازرسی شده‌اند و تست‌های اجرا شده.
۴. موانع عینی که نیاز به تصمیم انسانی دارند.

هزینه اقتصادی دقت

این چرخهٔ «بازرسی $
ightarrow$ به‌روزرسانی اهداف $
ightarrow$ پیاده‌سازی $
ightarrow$ تأیید $
ightarrow$ بازطراحی»، یک مشکل قیمت‌گذاری ایجاد می‌کند. در APIهایی که هزینه بر اساس توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — محاسبه می‌شود، هر چرخهٔ بازیابی و بازرسی اضافی، مبلغ صورت‌حساب را بالا می‌برد.

وقتی محاسبات بر اساس توکن قیمت‌گذاری می‌شوند، تیم‌ها ترغیب می‌شوند تا تعداد چرخه‌ها را کم کنند. این دقیقاً opposite آن چیزی است که مهندسی خوب می‌طلبد. دقت نیازمند این است که عامل متوقف شود، دوباره بخواند و مکرراً مسیر خود را تغییر دهد.

به همین دلیل است که مدل‌های هزینهٔ ثابت، مانند Standard Compute، طراحی سیستم را تغییر می‌دهند. با حذف اضطراب هزینهٔ توکنی، توسعه‌دهندگان می‌توانند به عامل‌ها اجازه دهند تا هر چند بار که لازم است بازرسی و بازطراحی کنند تا کد در یک محیط آشفته واقعاً کار کند.

گام بعدی شما

• اگر از ابزارهای کدنویسی خودگردان استفاده می‌کنید، به‌جای تست‌های ساده، یک تسک بازبینی در یک مخزن قدیمی و پیچیده را امتحان کنید.
• بررسی کنید آیا ابزار شما قابلیت ردیابی وضعیت (State Tracking) در یک فایل خارجی دارد یا خیر.
• مدل‌های هزینهٔ ثابت را برای پروژه‌های بزرگ جایگزین مدل‌های توکنی کنید تا دقت فدای هزینه نشود.

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