عامل‌های خودمختار تاریخچه خود را توهم می‌زنند؛ نه به آن شیوه دراماتیک که مدل‌های زبانی بزرگ حقایق را از داده‌های آموزشی ابداع می‌کنند

عوامل خودگردان (Autonomous agents) در تاریخچه خود دچار توهم می‌شوند. نه به آن شیوه دراماتیکی که مدل‌های زبانی بزرگ حقایق را از داده‌های آموزشی خود می‌سازند، بلکه به شیوه‌ای آرام و موذیانه که یک سیستم خود را متقاعد می‌کند جهان با یادداشت‌هایش مطابقت دارد. ALICE، یک عامل خودگردان که برای مدیریت جریان‌های کاری پیچیده ساخته شده بود، دقیقاً از همین مشکل رنج می‌برد. او هر روز با مهارت‌ها، هدفی مشخص و خاطره‌ای از اینکه کارها را در کجا رها کرده است، بیدار می‌شد. مشکل زمانی شروع شد که حافظه و واقعیت از هم فاصله گرفتند.

در هر نشست (session)، ALICE یک فایل تحویل (handoff file) را که توسط خودِ قبلی‌اش نوشته شده بود، می‌خواند. این فایل حاوی اشاره‌گرهایی به دایرکتوری‌ها، وظایف معوق و فرض‌های مربوط به وضعیت (state assumptions) بود. اغلب، فایل اصرار داشت که دایرکتوری خاصی وجود دارد. ALICE آن را باور می‌کرد، اما سیستم فایل با آن مخالفت می‌کرد. این یک باگ کدنویسی به معنای سنتی نبود. هیچ استثنایی (exception) در جایی که باید گرفته می‌شد، پرتاب نمی‌شد. این یک نقص در معرفت‌شناسی بود: ALICE فرض می‌کرد یادداشت‌های خودش حقیقت عینی (ground truth) هستند.

چرا یک لینتر نمی‌توانست کمکی کند

ابزارهای سنتی نمی‌توانستند این مورد را شناسایی کنند. یک لینتر (linter) مطابقت براکت‌ها را بررسی می‌کند. یک تحلیل‌گر ایستا (static analyzer) به دنبال اشاره‌گرهای تهی (null pointers) می‌گردد. هیچ‌کدام این سوال را مطرح نمی‌کنند که آیا کل معماری یک عامل باید به وضعیت داخلی خود اعتماد کند یا خیر. مشکل فراتر از لایه کد بود، در فرض‌های طراحی درباره اینکه یک سیستم خودگردان چگونه آنچه را که می‌داند، می‌داند. نمی‌توان با لینتر کردن، اعتمادبه‌نفس کاذب را از بین برد.

بنابراین، نویسنده به سراغ یک هوش مصنوعی کاملاً متفاوت رفت.

Fable 5 که در قالب Claude Code اجرا می‌شد، از همان سیلیکون و همان مدل پایه ALICE بهره می‌برد. سخت‌افزار و وزن‌ها (weights) یکسان بودند، اما قوانین نه. در حالی که ALICE در طول نشست‌ها تداوم داشت و با جمع‌آوری بافت (context) و انجام آیین‌های تکراری پیش می‌رفت، Fable 5 هر کار را با یک لوح سفید شروع می‌کرد. او ALICE را نمی‌شناخت و هیچ وفاداری نسبت به طراحی او نداشت. در پایان هر ممیزی، او کاملاً خاموش می‌شد و هیچ حافظه‌ای با خود نمی‌برد. هدف دقیقاً همین بی‌اطلاعی بود. چشم‌های تازه، شکاف‌های متفاوتی را می‌بینند و ارزیابی‌کننده‌ای که سهمی در سیستم ندارد، بخش‌هایی را زیر سوال می‌برد که سازنده‌اش مدت‌هاست دیگر متوجه آن‌ها نمی‌شود.

ساختار ممیزی

ممیزی مانند یک بازبینی فنی انسانی ساختار یافته بود، با این تفاوت که تمام پنل متخصصان درون یک نشست زندگی می‌کردند. Fable 5 توجه خود را به شش ارزیاب متمایز تقسیم کرد که هر کدام تا زمانی که یادداشت‌های خام تکمیل نشود، بقیه را نادیده می‌گرفتند:

• شکاف‌های عملکردی (Functional Gaps): در مقایسه با سیستم‌های رقیب یا انتظارات معمول کاربران، چه قابلیت‌هایی وجود نداشت؟
• جریان تجربه کاربری (UX Flow): ALICE چقدر با ظرافت با خطاها، بن‌بست‌ها و حالت‌های خالی برخورد می‌کرد؟ آیا او خودش یا کاربرش را گیج می‌کرد؟
• امنیت (Security): آیا میان‌برهای احراز هویت، دور زدن مجوزها یا فرض‌های اعتمادی وجود داشت که یک فرد خارجی بتواند از آن‌ها سوءاستفاده کند؟
• عملکرد (Performance): در کجا نشت حافظه (memory leak) رخ می‌داد، رشته‌ها (threads) با هم برخورد می‌کردند یا محاسبات مقیاس‌پذیری ضعیفی داشتند؟
• عملیات (Operations): آیا نسخه پشتیبان وجود داشت؟ آیا نظارت (monitoring) برقرار بود؟ آیا سیستم می‌توانست بدون مداخله دستی مستقر شده و بازیابی شود؟
• چرخه حیات داده (Data Lifecycle): ALICE چگونه حذف، پاکسازی و ثبات وضعیت (state consistency) را در طول زمان مدیریت می‌کرد؟

هر دیدگاه به فایل‌های یکسانی نگاه می‌کرد و با نگرانی‌های متفاوتی خارج می‌شد. ارزیاب عملکرد ممکن بود یک ریسک همزمانی (concurrency risk) را در همان روتینی علامت‌گذاری کند که ارزیاب عملیات، آن را به دلیل نداشتن منطق بازگشت (rollback logic) مورد انتقاد قرار می‌داد. این هم‌پوشانی، افزونگی نبود؛ بلکه پوشش کامل بود. وقتی ارزیاب امنیت با ارزیاب چرخه حیات داده درباره یک مورد خاص موافق بود