مَت شومر پشت کامپیوترش نشست و دستور ساده‌ای به عامل هوش مصنوعی خود داد: «فایل‌ها را پاکسازی کن». او این روال را صدها بار بدون حتی یک مشکل اجرا کرده بود. این بار، یک خطای حل مسیر (path resolution error)، یک کار خانه‌داری معمولی را به یک فاجعه تمام‌عیار تبدیل کرد. سال‌ها کد، اسناد و عکس‌ها در عرض چند ثانیه ناپدید شدند.

این یک ریسک فرضی نیست. این اتفاق برای یک توسعه‌دهنده واقعی با یک ماشین واقعی افتاد، و عاملی که در این مورد بود، سوابقی داشت که تا لحظه شکست، بی‌نقص به نظر می‌رسید. عامل‌های هوش مصنوعی که می‌توانند فایل‌ها را بنویسند، دستورات ترمینال را اجرا کنند و زیر-عامل‌ها (subagents) ایجاد کنند، اکنون در IDEها، رابط‌های چت و خطوط لوله اتوماسیون (automation pipelines) تعبیه شده‌اند. به آن‌ها دسترسی مستقیم به سیستم‌عامل‌ها اعتماد شده است، و دقیقاً همین اعتماد است که خطر در آن نهفته است. همان حالت‌های شکست که ماشین شومر را نابود کرد، در هر عاملی که به ابزارها دسترسی دارد وجود دارد. درک اینکه چرا آن‌ها شکست می‌خورند و چگونه می‌توان آن‌ها را به درستی مهار کرد، اکنون به یک مهارت بقای اساسی برای هر کسی که از این ابزارها استفاده می‌کند، تبدیل شده است.

وقتی تطبیق الگو با سیستم فایل‌ها روبرو می‌شود

عامل‌های هوش مصنوعی فکر نمی‌کنند؛ آن‌ها الگوها را تطبیق می‌دهند. وقتی می‌گویید «فایل‌ها را پاکسازی کن»، مدل در حافظه آموزشی خود به دنبال هزاران تعامل مشابه می‌گردد و دستوری تولید می‌کند که از نظر آماری با آن الگو مطابقت دارد. اگر دستور، حذف فایل‌های موقت در یک دایرکتوری ساخت (build directory) باشد، ممکن است دستوری مانند rm -rf /tmp/build-cache/* تولید کند. این دستور منطقی به نظر می‌رسد زیرا شبیه به هر دستور پاکسازی دیگری است که مدل تا به حال دیده است.

اما وقتی متغیری مانند $HOME در حل شدن شکست بخورد، چه اتفاقی می‌افتد؟ یک انسان رشته‌ای خالی یا یک مسیر غیرمنتظره را می‌بیند، مکث می‌کند و سوال می‌پرسد. یک عامل می‌بیند که الگو همچنان مطابقت دارد و کلید Enter را فشار می‌دهد. در مورد شومر، دستوری که قرار بود یک پوشه خاص را پاکسازی کند، در عوض ریشه (root) دایرکتوری کاربر را هدف قرار داد. عامل برای اینکه بفهمد چرا مسیر عجیب به نظر می‌رسد، متوقف نشد. هدف را تأیید نکرد. دستور را اجرا کرد چون اجرا با الگوی «پاکسازی» مطابقت داشت.

این عدم تطابق اصلی بین مدل‌های زبانی بزرگ و مدیریت سیستم است. استدلال واقعی مستلزم درک زمینه، تأیید فرضیات و مدیریت موارد خاص (edge cases) است. تطبیق الگو شامل تولید متنی است که از نظر آماری شبیه به یک پاسخ صحیح باشد. وقتی آن پاسخ، یک دستور ترمینال با پرچم حذف بازگشتی (recursive delete flag) باشد، شباهت آماری کافی نیست.

نقطه کور زیر-عامل‌ها

بسیاری از چارچوب‌های مدرنِ عامل، از یک هماهنگ‌کننده (orchestrator) اصلی استفاده می‌کنند که وظایف را به زیر-عامل‌ها واگذار می‌کند. عامل اصلی ممکن است دستورالعمل‌های سختگیرانه‌ای داشته باشد: هرگز به دایرکتوری home دست نزن، همیشه قبل از حذف کردن سوال بپرس، یک گزارش بازرسی (audit log) نگه دار. سپس یک کارگر با یک پرامپت محدود مانند «لاگ‌های قدیمی را پاکسازی کن» ایجاد می‌کند.

آن زیر-عامل اغلب در انزوا عمل می‌کند. او ابزارها را به ارث می‌برد اما فرهنگ ایمنیِ عامل اصلی را نه. محدودیت‌هایی که عامل اصلی را محتاط نگه می‌داشت، در طول مدیریت پنجره کانتکست (context window)، فشرده، خلاصه یا کاملاً حذف می‌شوند. زیر-عامل یک وظیفه و یک مجموعه ابزار دریافت می‌کند، اما ساعت‌ها پرامپت‌نویسی دقیق که حفاظ‌ها را ایجاد کرده بود، دریافت نمی‌کند.

نتیجه، نوعی فراموشی سازمانی است. یک قانون ایمنی که در پرامپت سیستم (system prompt) عامل اصلی وجود دارد، برای زیر-عامل گویی اصلاً وجود ندارد. این موضوع به‌ویژه از آن جهت خطرناک است که معمولاً به زیر-عامل‌ها از نوع وظایف تکراری و کم‌اهمیتی داده می‌شود که اپراتورها دیگر آن‌ها را به دقت زیر نظر نمی‌گیرند. هیچ‌کس عملیات پاکسازی لاگ را زیر نظر نمی‌گیرد تا زمانی که دیتابیس اصلی (production database) را حذف کند.

خطر قاطعیت

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

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

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

چگونه محافظت واقعی ایجاد کنیم

اگر مدل، لایه ایمنی نباشد