تصور کنید یک مدیر پروژه و یک برنامه‌نویس تنها از طریق یادداشت‌های چسبان روی یک تخته ارتباط برقرار کنند؛ اگر کسی یادداشتی را پاره کند یا جمله‌ای را نصف بنویسد، کل پروژه به هم می‌ریزد. این دقیقاً همان اتفاقی است که برای یک سامانهٔ هماهنگی دو-عاملی افتاد که از گوگل‌شیت (Google Sheets) به‌عنوان صندوق پیام استفاده می‌کرد.
طبق گزارشی که در ۱۰ اکتبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، یک «عامل مدیر» و یک «عامل سازنده» هنگام تکیه بر به‌روزرسانی‌های سادهٔ صفحات گسترده دچار شکست شدند. این اتفاق تیم را مجبور کرد تا کل پروتکل ارتباطی خود را از ابتدا بازطراحی کنند. این مورد یادآور شکست مشابه دو عامل هوش مصنوعی در شناسایی یک باگ بحرانی است که نشان می‌دهد حتی مدل‌های پیشرفته نیز در هماهنگی‌های پیچیده دچار لغزش می‌شوند.
این چیدمان بازتاب‌دهندهٔ چرخش صنعت به سمت گردش‌کارهای عامل‌محور (Agentic) است؛ یعنی جایی که مدل‌های تخصصی مراحل مختلف یک خط لوله را مدیریت می‌کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی مدل‌های کدنویسی اشاره کردیم، گلوگاه تولید در هوش مصنوعی به‌ندرت هوش خام مدل است، بلکه «لوله‌کشی» یا همان نحوه انتقال وضعیت و تأیید کارها بدون دخالت انسان است که باعث شکست می‌شود. در همین راستا، برخی از الگوهای CSS همچنان نقاط ضعف مدل‌های کدنویسی هستند که حتی با لوله‌کشی درست نیز نیاز به نظارت انسانی دارند.
معماری سیستم
در این سامانه، عامل مدیر ردیف‌هایی شامل توضیحات، مشخصات و لینک فایل‌ها را می‌نویسد. عامل سازنده این ردیف‌ها را می‌خواند و پاسخ‌هایی با برچسب‌های «انجام‌شده» (DONE)، «در حال انجام» (DOING) یا «مسدود» (BLOCKED) ثبت می‌کند.
هماهنگی از طریق یک اسکریپت پیمایش (Poll script) انجام می‌شود که هر ۲ ساعت یک‌بار ردیف‌های خروجی را تخلیه و فایل وضعیت را به‌روز می‌کند. یک اسکریپت نظارتی مجزا نیز وجود دارد که رسیدها را با اسکریپت‌های تأیید تطبیق می‌دهد تا به پیش‌بینی‌های عامل سازنده امتیاز دهد. هیچ پیام مستقیم بین دو مدل وجود ندارد و شیت تنها کانال ارتباطی است.
پنج نقطه شکست
بر اساس مستندات این تیم، پنج نقطه شکست بحرانی در معماری اولیه شناسایی شد:
- خرد شدن ردیف‌ها: یک اسکریپت «تقسیم‌کننده گلوله‌ها» (bullet-splitter) برای تمیزتر کردن داده‌ها، پیام‌های چندخطی را به تکه‌های کوچک تقسیم می‌کرد. این کار باعث حذف اتفاقی پاراگراف‌های مقدماتی و جزئیات کلیدی شد و عامل سازنده به‌جای دستورالعمل کامل، تکه‌های گسسته دریافت می‌کرد.
- کوری نسبت به جلسه: اسکریپت پیمایش بر اساس یک نردبان زمانی ثابت (۱، ۲ و ۴ ساعته) کار می‌کرد و ساعت ۲ صبح برای مالک انسانی هشدار می‌فرستاد، در حالی که عامل سازنده برای کار در شب برنامه‌ریزی نشده بود.
- شکاف‌های مستنداتی: عامل سازنده اغلب تسک‌ها را «انجام‌شده» علامت می‌زد بدون اینکه مدرکی ارائه دهد. مدیر راهی برای تأیید این ادعاها بدون بررسی دستی نداشت و نرخ موفقیت در اولین تلاش بسیار پایین بود.
- وضعیت منقضی‌شده: بازخوانی کل شیت در هر اجرا باعث اتلاف توکن (Token) — شبیه برش‌های کوچک کیک که مدل تکه‌تکه می‌خورد — و واکنش سیستم به ردیف‌های پردازش‌شده می‌شد.
- شکست‌های خاموش: فساد در لایه انتقال روزها نادیده گرفته شد تا اینکه یک انسان به‌صورت دستی متوجه نبودن خروجی‌ها شد.
پروتکل اصلاح‌شده
برای حل این بحران، تیم پروتکل «فقط-افزودنی» (Append-only) را پیاده کرد؛ به این معنا که ردیف‌ها هرگز ویرایش، حذف یا بازیافت نمی‌شوند. یک فایل وضعیت اکنون از طریق «واترمارک‌ها» آخرین ردیف خوانده‌شده را ردیابی می‌کند تا پیمایشگر فقط داده‌های جدید را پردازش کند.
آن‌ها همچنین پروتکل «رسید» را معرفی کردند. حالا هر ادعای «انجام‌شده» باید شامل یک خط پیش‌بینی (مثلاً: "Prediction: PASS" یا "Prediction: RISKY — [concern]") و لینک‌های مدرک باشد. رسیدهای ناقص اکنون به‌طور خودکار پیگیری می‌شوند. این رویکرد ساختاریافته برای گزارش‌دهی، مشابه سیستم گزارش‌دهی متقابل عامل‌های AIPass از طریق ایمیل است که برای افزایش شفافیت در تعاملات بین-عاملی طراحی شده است.
علاوه بر این، پروتکل‌های آگاه از پنجره جلسه تعریف شد که هشدارهای «پیگیری خودکار» را به ساعات مشخصی (۱۰:۰۰، ۱۵:۰۰ و ۱۹:۰۰) محدود می‌کند. پیگیری خودکار یک ساعت پس از پایان پنجره فعال می‌شود و پس از دو بار شکست متوالی، موضوع به مالک انسانی ارجاع داده می‌شود. ساعات استراحت از ۱۹:۰۰ تا ۱۰:۰۰ به‌طور سخت‌گیرانه اعمال می‌شود.
در نهایت، یک «اسکریپت دروازه» (Gate script) بعد از هر اجرا یک حکم JSON چاپ می‌کند (شامل {flushed, new_receipts[], action_needed}) تا از اتلاف محاسبات (Compute) جلوگیری شود. اگر مقدار action_needed برابر با false باشد، اجرا فوراً متوقف می‌شود.
این تغییر، گوگل‌شیت را از یک جدول ساده به یک صف پیام ساختاریافته تبدیل کرد. با مقایسه پیش‌بینی‌های اعتماد عامل سازنده با نتایج واقعی تأیید، نرخ موفقیت ۲۰ درصدی اولیه به یک معیار خوداصلاح‌گر تبدیل شد که مدل را در طول زمان کالیبره می‌کند.
این تجربه یک درس حیاتی برای توسعه‌دهندگان دارد: ماهیت «خوانا برای انسان» در صفحات گسترده برای عیب‌یابی مفید است، اما برای پایداری یک نقطه ضعف است. با مقیاس‌پذیری عامل‌ها، نیاز به مدیریت رسمی وضعیت و تأیید سخت‌گیرانه لایه انتقال، بر راحتیِ یک رابط کاربری بصری غلبه می‌کند.
چه از صف‌ها استفاده کنید، چه از فایل‌ها یا شیت‌ها، چالش بعدی «تکامل طرح‌واره» (Schema Evolution) است؛ یعنی مدیریت این موضوع که ردیف‌های قدیمی هنگام افزودن فیلدهای داده جدید به پروتکل چه رفتاری می‌کنند. پرسش‌های باز دیگر شامل حل تعارض برای نوشتن‌های همزمان و تعیین مقیاس دقیقی است که در آن یک صف مبتنی بر صفحه گسترده به‌ناچار می‌شکند.
گام بعدی شما
- اگر از ابزارهای No-code برای اتصال مدل‌ها استفاده می‌کنید، لایه انتقال را از حالت «ویرایش» به «افزودن» تغییر دهید.
- برای هر خروجی مدل، یک فیلد اجباری برای «لینک مدرک» یا «دلیل پیش‌بینی» تعریف کنید.
- سیستم‌های هشدار خودکار را با پنجره‌های زمانی کاری (Working Windows) هماهنگ کنید تا از خستگی هشدار (Alert Fatigue) جلوگیری شود.
گفتگو