همه می‌خواهند تیمی از عوامل هوش مصنوعی (AI agents) بسازند. دموها وسوسه‌انگیز به نظر می‌رسند. یک عامل تحقیق می‌کند، دیگری کد می‌نویسد و سومی تست‌ها را اجرا می‌کند. اما بیشتر این سیستم‌ها یک راز کثیف دارند: آن‌ها شکننده هستند. آن‌ها در طول یک دمو‌ی پنج دقیقه‌ای عالی کار می‌کنند، اما در طول یک تحقیق واقعی از هم می‌پاشند. نقطه شکست به‌ندرت توانایی استدلال مدل زبانی یا تعداد عوامل در یک خوشه (swarm) است؛ بلکه فضای بین آن‌هاست. سیستم‌های چندعاملی در «سطح همکاری» (collaboration plane) شکست می‌خورند.

تله‌ی ناظر

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

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

وقتی هماهنگی شکست می‌خورد، چه چیزی از دست می‌رود؟

وقتی یک تحقیق عمیق می‌شود، شما به چیزی بسیار فراتر از پاسخ نهایی نیاز دارید. شما باید بدانید چه کسی، چه چیزی را در چه زمانی می‌دانسته است. باید ردیابی کنید که کدام یافته، جهت کار را تغییر داده است. باید درک کنید چرا یک عامل دو ساعت پیش برنامه‌ی خود را تغییر داده است. بدون یک سطح همکاری، هیچ‌کدام از این‌ها قابل مشاهده نیست. شما لاگ‌ها (logs) را دارید، اما لاگ‌ها فقط نویزهای زمانی هستند. آن‌ها ثبت می‌کنند که عامل C ناگهان به جای فراخوانی‌های API، شروع به تحلیل تراکنش‌های پایگاه داده کرده است، اما دلیل آن را توضیح نمی‌دهند. شما می‌توانید شاهد وقوع آن باشید و حدس بزنید.

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

سطح همکاری، حافظه نیست

سطح همکاری صرفاً یک ظرف حافظه برای حقایق نیست. حافظه، اطلاعات را ذخیره می‌کند؛ اما وضعیت همکاری (collaboration state)، کارهای در حال انجام را ذخیره می‌کند. یک پایگاه داده برداری (vector database) پر از اسناد، مطالب مرجع را در اختیار یک عامل قرار می‌دهد، اما به عامل نمی‌گوید که عامل X در حال حاضر در حال آزمایش فرضیه‌ای است که وظیفه‌ی فعلی عامل Y را بیهوده می‌کند. حافظه، یک بافت (context) ایستا است؛ اما وضعیت همکاری، نقشه‌ی زنده از عملیات است.

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

پنج ظرفِ وضعیت مشترک

یک سطح همکاری واقعی به پنج ظرف مشخص نیاز دارد.

ادعاها (Claims). این‌ها فرضیه‌های فعالی هستند که یک عامل در حال آزمایش آن‌هاست. در یک تحقیق کلاهبرداری، یک ادعا می‌تواند این باشد که «ناهنجاری با وظایف دسته‌ای (batch jobs) آخر هفته همبستگی دارد». هر عاملی باید بتواند ببیند کدام ادعاها باز هستند، کدام‌ها در حال آزمایش‌اند و چه کسی مالک آن‌هاست. بدون