سی‌جی آویلا از آنتروپیک: عامل‌های هوش مصنوعیِ تنها تنبل می‌شوند، دروغ می‌گویند و هدف را گم می‌کنند
کن تامپسون تقریباً به‌تنهایی و در حدود یک ماه یونیکس را ساخت؛ کاری که مستلزم نگه‌داشتن تمام طرح سیستم در ذهن یک نفر بود. فرد بروکس نیز شاهد بود که سربار هماهنگی‌ها چگونه پروژه سیستم‌عامل OS/360 شرکت IBM را به دردسر انداخت؛ تجربه‌ای که او را به نگارش کتاب ماه انسان افسانه‌ای سوق داد. درس‌های دهه‌های ۱۹۶۰ و ۱۹۷۰، از جمله انسجام مفهومی، تشکیل تیم‌های کوچک و تخصصی و ایجاد اعتماد لایه‌به‌لایه به‌جای تکیه بر ساختارهای ستاره‌ای، اکنون به الگویی برای آنتروپیک تبدیل شده‌اند تا به‌جای اداره یک عامل هوش مصنوعی، هزار عامل را مدیریت کند.
این محور اصلی استدلال سی‌جی آویلا و هریسون استال، دو عضو کادر فنی آنتروپیک، در گفت‌وگو با پادکست AI Engineer است. به گفته آن‌ها، عامل‌های منفرد به سقفی مشخص می‌رسند و راه‌حل، ساخت مدل بزرگ‌تر نیست؛ بلکه باید هماهنگی میان عامل‌ها را بهبود داد. قابلیت Flows در سرویس Claude Managed Agents که جمعه پیش از این گفت‌وگو منتشر شد، به کلود امکان می‌دهد ساختار چندعاملی خود را طراحی و اجرا کند. آویلا شخصاً فرایندی متشکل از ۱۰۰۰ عامل را برای ساخت یک سیستم‌عامل سازگار با یونیکس به راه انداخت. این فرایند حتی پس از ۸۵ ساعت همچنان در حال اجرا بود و مخزن گیت‌هاب آن حدود ۱۰۰۰ کامیت داشت؛ اما پروژه هنوز تمام نشده بود.
چرا یک عامل کافی نیست؟
آویلا سه دلیل مشخص برای ناکارآمدشدن عامل‌های منفرد برمی‌شمارد که هرکدام در Flows با یک الگوی طراحی متناظر پاسخ داده شده‌اند.
تنبلی عامل‌محور. فرض کنید به یک عامل دستور دهید: «اختلالی در سامانه داریم؛ این ۵۰ سرویس را بررسی کن و به محیط عملیاتی دست نزن.» عامل ۳۵ سرویس را بررسی می‌کند، می‌بیند همه سالم‌اند و خودش را قانع می‌کند که احتمالاً بقیه سرویس‌ها هم مشکلی ندارند. در نتیجه، بررسی را پیش از تکمیل متوقف می‌کند. Flows با اختصاص یک زمینه کاری مستقل به هر سرویس، این مشکل را برطرف می‌کند؛ به این ترتیب می‌توان اطمینان داشت که تک‌تک سرویس‌ها واقعاً بررسی شده‌اند.
سوگیری به نفع کار خود. مثال آویلا در این زمینه ساده و روشن است: «اگر از یک عامل بخواهید شعری بنویسد و بعد از خودش بپرسید آیا شعر خوبی است، جواب می‌دهد بله.» همین اتفاق در تولید کد نیز رخ می‌دهد. تولیدکننده و ارزیاب باید دو عامل جداگانه باشند و در زمینه‌های کاری مستقلی فعالیت کنند که ارزیابی‌های قبلی بر آن‌ها اثر نگذاشته باشد.
انحراف از هدف. در مثال اختلال سرویس‌ها، دستور «به محیط عملیاتی دست نزن» در پایان پیام می‌آید. با پرشدن پنجره زمینه و فشرده‌سازی مکرر اطلاعات آن، این محدودیت ممکن است از یاد برود. Flows هدف مشخص را در تمام مراحل، به‌صورت یکسان، در اختیار هر عامل فرعی قرار می‌دهد.
نمونه تاریخی این مسئله نیز روشن است. لینوس توروالدز، خالق لینوکس، در سال ۱۹۹۸ به نقطه‌ای رسید که به مشارکت‌کنندگان گفت قصد دارد به تعطیلات برود. روز بعد، لری مک‌ووی در پیامی تشخیصی ارائه کرد که آویلا آن را عیناً نقل می‌کند: «مشکل این است که لینوس مقیاس‌پذیر نیست.» توروالدز تا سال ۲۰۰۲ از ساختاری ستاره‌ای، که در آن ۳۶ نفر مستقیماً به او گزارش می‌دادند، به شبکه‌ای لایه‌بندی‌شده از نگه‌دارندگان مورد اعتماد پروژه روی آورده بود. از نظر آویلا، توسعه‌دهندگانی که امروز مسئول هماهنگی تعداد زیادی عامل هستند، با همان گلوگاه روبه‌رو خواهند شد.
هزینه Flows بیشتر است و همین نکته اهمیت دارد
استال ارزش این رویکرد را با توجه به محدودیت‌های یک عامل منفرد توضیح می‌دهد: یک عامل معمولاً حدود یک ساعت کار می‌کند و پس از آن عملکردش افت می‌کند. ساختاری متشکل از یک هماهنگ‌کننده و مجموعه‌ای از عامل‌ها می‌تواند مدت بیشتری دوام بیاورد. گردش‌کارهای پویا امکان ایجاد «مجموعه‌های تو‌در‌توی دلخواه از عامل‌ها را فراهم می‌کنند که همگی به‌صورت موازی فعالیت می‌کنند». او به تصویری طنزآمیز از کاربران اشاره می‌کند که برای زنده نگه‌داشتن Claude Code، لپ‌تاپ‌هایشان را نیمه‌باز نگه می‌دارند و مرتب دکمه تأیید را می‌فشارند؛ وضعیتی که به گفته او، برای حل مسائل در مقیاس جامعه «محدودیتی بسیار بزرگ» ایجاد می‌کند.
روشن‌ترین نمونه برای مقایسه هزینه و فایده، آزمایشی است که آویلا درباره اجرای یک وظیفه اسکن فهرست پیگیری در دو حالت ارائه می‌کند: یک بار با عامل منفرد و بار دیگر با Flows. اجرای مبتنی بر Flows هزینه بسیار بیشتری دارد، اما در شناسایی تمام جزئیات نیز بسیار مؤثرتر است.
| معیار | عامل منفرد | هماهنگ‌کننده و مجموعه عامل‌ها | Flows؛ گردش‌کارهای پویا |
|---|---|---|---|
| مدت اجرا پیش از افت عملکرد | حدود یک ساعت | بیشتر | مدت نامحدود از نظر طراحی، با چندین مرحله |
| چه کسی عامل‌های فرعی را تعریف می‌کند؟ | مصداق ندارد | توسعه‌دهنده هر عامل را تعریف می‌کند | عامل اصلی ساختار عامل‌های فرعی خود را تعیین می‌کند |
| جداسازی زمینه کاری | وجود ندارد | به‌ازای هر رشته گفت‌وگو | به‌ازای هر رشته نشست، با جداسازی فیزیکی |
| هزینه | کمترین | متوسط | بیشترین |
| مناسب‌ترین کاربرد | کارهای سریع، در حدود ۳۰ ثانیه | وظایف مشخص و واگذارشده | کارهای بلندپروازانه، پیچیده و قابل راستی‌آزمایی |
آویلا درباره محدودیت‌های این سیستم صریح است. در هر فرایند Flows حداکثر ۱۰۰۰ عامل می‌توانند حضور داشته باشند. عامل اصلی می‌تواند چندین فرایند را اجرا کند یا پس از پایان یک فرایند، فرایند دیگری را آغاز کند. بااین‌حال، Flows برای کاری که یک عامل منفرد می‌تواند ظرف ۳۰ ثانیه انجام دهد، گزینه مناسبی نیست.
بودجه هر نشست پیش از آغاز فرایند تعیین می‌شود. اگر اجرای Flows به سقف بودجه برسد، رویدادی با عنوان «بودجه به پایان رسید» ثبت می‌شود. کاربر می‌تواند در میانه نشست بودجه را افزایش دهد تا فرایند از همان نقطه ادامه پیدا کند، بی‌آنکه کارهای تکمیل‌شده کنار گذاشته شوند. استال می‌گوید مدل عمداً از میزان بودجه خود هنگام اجرا مطلع نمی‌شود، زیرا «اگر بودجه را به آن بگویید، کلود ممکن است کمی مضطرب شود».
جداسازی مغز از دست‌ها
استال در نیمه دوم سخنرانی خود بر ایمنی تمرکز می‌کند. اصل معماری محوری این است: «ایده این است که مغز، یعنی حلقه‌ای که واقعاً استنتاج را اجرا می‌کند، کاملاً از چیزی که ما دست‌های کلود می‌نامیم جدا باشد؛ دست‌ها همان بخشی هستند که عامل از طریق آن می‌تواند در دنیای واقعی اقدام کند.»
یکی از مشخص‌ترین سازوکارهای فنی این معماری به مدیریت اطلاعات محرمانه مربوط می‌شود. هر محفظه اجرایی که به یک راز یا اعتبارنامه نیاز دارد، نسخه‌ای جعلی دریافت می‌کند که در صورت استفاده معتبر نیست. اعتبارنامه واقعی فقط در لایه پروکسی خروجی و هنگام ارسال درخواست جایگزین نسخه جعلی می‌شود. به گفته استال، نه می‌توان با طراحی یک پیام دستوری از کلود خواست اعتبارنامه واقعی را استخراج کند و نه می‌توان از طریق دسترسی به محیط ایزوله به آن دست یافت. سامانه‌های نگه‌داری امن، اطلاعات محرمانه را به‌صورت متغیرهای محیطی ذخیره می‌کنند و برای هر مورد دو فیلد پیکربندی دارند: محل تزریق، یعنی بخشی از درخواست خروجی که راز باید در آن قرار گیرد، مانند توکن حامل یا بدنه درخواست؛ و میزبان‌های مجاز، یعنی دامنه‌هایی که جایگزینی اعتبارنامه فقط برای آن‌ها انجام می‌شود. به این ترتیب، برای مثال، کلید Twilio به دامنه‌ای دلخواه ارسال نخواهد شد.
استال چارچوب خود برای توسعه‌دهندگان را با سه فعل توضیح می‌دهد: تعریف، یعنی مشخص‌کردن ماهیت عامل، مجوزها، شخصیت، مهارت‌ها و ابزارهای آن؛ محصورسازی، یعنی تعیین محدودیت‌های فیزیکی و سیاست‌های محیط اجرا، از جمله محدودکردن دامنه‌های مجاز و اجازه‌دادن به جست‌وجوی وب بدون امکان دریافت مستقیم محتوای صفحات؛ و تشخیص، یعنی استفاده از جریان رویدادهای پایدار که امکان متوقف‌کردن هر نشست منحرف‌شده از مسیر موردنظر را فراهم می‌کند.
او یک توصیه ساده و فوری نیز دارد: سیاست مجوزها را از حالت «همیشه سؤال بپرس» به حالت خودکار یا Auto Mode تغییر دهید. به گفته او، وقتی انسان‌ها بارها با درخواست تأیید روبه‌رو می‌شوند، حدود ۹۷ درصد مواقع موافقت می‌کنند؛ بنابراین، تأیید دستی به نمایشی از کنترل تبدیل می‌شود. استال استدلال می‌کند که کلود «بسیار صبورتر» است و می‌تواند واقعاً تشخیص دهد که فراخوانی یک ابزار ایمن است یا ممکن است به اقدامی مخرب منجر شود.
این الگو در محیط عملیاتی چگونه اجرا می‌شود؟
دو گردش‌کار مشخص، کاربرد این معماری را نشان می‌دهند. نخست، Bug Hunter درخواست‌های ادغام کد یا پول‌ریکوئست‌ها را بررسی می‌کند. در این فرایند، کد به بخش‌های کوچک‌تر تقسیم می‌شود و هر بخش به زمینه کاری مستقلی سپرده می‌شود تا عامل مربوطه مشکلات احتمالی را شناسایی کند. در مرحله دوم، یک عامل بازبین درباره هر مورد گزارش‌شده موافقت یا مخالفت می‌کند. در مرحله سوم، مواردی که احتمال واقعی‌بودن آن‌ها وجود دارد انتخاب می‌شوند و به مرحله اثبات می‌روند؛ در این مرحله، مخزن کد دریافت می‌شود و تلاش می‌کنند با بازتولید شرایط، وجود باگ را تأیید کنند. نتایج در قالب نظرهای درون‌خطی در درخواست ادغام نمایش داده می‌شوند و هر مورد اولویت شدت مشخصی دارد.
گردش‌کار دوم، Explainer Studio، ویدئوهای پویانمایی‌ای را تولید می‌کند که آنتروپیک از حساب ClaudeDevs خود منتشر می‌کند. این فرایند با مرحله پژوهش آغاز می‌شود که شامل برنامه‌ریزی، شناسایی منابع و بررسی صحت اطلاعات است. سپس یک خلاصه محتوایی تهیه و به مرحله تولید سپرده می‌شود؛ در این مرحله، صحنه‌های جداگانه ساخته و متحرک‌سازی می‌شوند. مراحل دیگری نیز به تولید جلوه‌های صوتی، گویندگی و نگارش متن اختصاص دارند. آویلا می‌گوید ساخت و متحرک‌سازی ویدئویی که چهار سال پیش حدود ۲۰ ساعت زمان می‌برد، اکنون با یک دستور کوتاه برای یک فرایند Flows امکان‌پذیر است.
مسئله‌ای که هنوز حل نشده است
این گفت‌وگو فرمول مشخصی برای تعیین زمان مناسب استفاده از Flows ارائه نمی‌کند و تنها بر مناسب‌بودن آن برای «کارهای بلندپروازانه و پیچیده» تأکید دارد. افزایش توانایی‌ها با افزایش هزینه همراه است. مدل عمداً از بودجه خود اطلاع ندارد. همچنین، به دلایل ایمنی، ساختارهای تو‌در‌تو به یک لایه محدود شده‌اند و آنتروپیک هنوز از ایجاد ساختارهای عظیم و پیچیده با انشعاب‌های نامحدود پشتیبانی نمی‌کند. آزمایش اصلی، یعنی ساخت یک سیستم‌عامل با ۱۰۰۰ عامل، نیز در پایان نشست همچنان ادامه داشت.
این همان تنش حل‌نشده‌ای است که در مرکز راهبرد آنتروپیک قرار دارد. درس‌های مهندسی نرم‌افزار در دهه‌های ۱۹۶۰ و ۱۹۷۰، از جمله انسجام مفهومی، تشکیل تیم‌های کوچک و تخصصی و ایجاد اعتماد لایه‌به‌لایه، مستقیماً در هماهنگی عامل‌ها کاربرد دارند. اما آن تجربه‌ها هشداری نیز در خود داشتند: افزودن نیروی انسانی بیشتر به پروژه‌ای که از برنامه عقب افتاده است، می‌تواند تأخیر آن را بیشتر کند. آزمایش آویلا با ۱۰۰۰ عامل برای ساخت سیستم‌عامل، نخستین داده مهم برای بررسی این پرسش است که آیا همین هشدار درباره عامل‌های هوش مصنوعی نیز صدق می‌کند یا نه. آنتروپیک پاسخ خود را در قالب رابط برنامه‌نویسی کاربردی و قابلیت‌های نرم‌افزاری ارائه می‌کند، نه صرفاً در محیط خط فرمان. اینکه این رویکرد واقعاً مقیاس‌پذیر خواهد شد یا به ساختاری بیش‌ازحد پیچیده و پراکنده می‌انجامد، پرسشی است که سال آینده به آن پاسخ خواهد داد.