اگر در حال حاضر برای مدیریت پیچیدگیهای پروژههای خود تعداد عاملهای هوش مصنوعی را افزایش میدهید، احتمالاً در مسیر شکست هستید. طبق اعلام اندرو انجی (Andrew Ng)، کلید موفقیت در مقیاس صنعتی، نه در تعداد عاملها، بلکه در نحوه صحبت کردن آنها با یکدیگر است.
او در راهنمای ۱۲ صفحهای که در ۸ اوت ۲۰۲۶ منتشر کرد، مفهوم مهندسی گراف (Graph Engineering) را معرفی کرد. این مفهوم — شبیه به طراحی نقشه یک شهر که تعیین میکند ترافیک از کدام خیابانها عبور کند تا گرههای ترافیکی ایجاد نشود — ساختار توپولوژیکی است که عاملها (Agents) — همان دستیارهای هوشمند کوچک که هر کدام وظیفه خاصی دارند — را به هم متصل میکند. این رویکرد تکاملیافتهای از تلاشهای اوست که پیشتر در پروژه OpenWorker، خروجیهای نهایی را جایگزین محیطهای چت ساده کرد تا کارآمدی عملیاتی افزایش یابد.
همانطور که در تحلیل قبلی ما دربارهی شکست سامانههای چندعاملی در مقیاس واقعی اشاره کردیم، ارسال هر پیام به تمام عاملها (Broadcasting) باعث فشار شدید به پنجرهٔ زمینه (Context Window) — یعنی میز کاری مدل که فضای محدودی برای نگه داشتن اطلاعات دارد — و افزایش سرسامآور هزینههای توکن (Token) میشود.
به نقل از این راهنما، مهندسی گراف بر سه رکن اصلی استوار است:
- نقش گرهها (Node Roles): تعریف دقیق وظایف تخصصی برای هر عامل.
- انواع یالها (Edge Types): تعیین ماهیت و نوع اتصال بین دو عامل.
- جریان اطلاعات (Information Flow): ساختاردهی به نحوه اشتراکگذاری وضعیت برای کاهش تکرار.
اندرو انجی تأکید میکند که شکل این گراف (ستارهای، مشبک یا سلسلهمراتبی) مستقیماً بر میزان تأخیر، انتشار خطا و قابلیت عیبیابی سیستم اثر میگذارد. به باور او، معماری ارتباطات است که نتیجه نهایی را تعیین میکند، نه تعداد مدلهای بهکاررفته.
برای مدیران کسبوکار و مهندسان، این یعنی طراحی گراف باید با همان دقتی انجام شود که انتخاب مدل یا مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — انجام میشود. در واقع این نگاه ساختاریافته، مکمل نقشه راه جامع ۲۰۲۶ برای ساخت و فروش عاملهای B2B است که بر پیادهسازی تجاری این سیستمها تمرکز دارد. طبق این مستند، تقسیمبندی وضعیت (State Partitioning) بین عاملها تنها راه عبور از گلوگاههای فنی در تبدیل نمونههای آزمایشگاهی به محصولات تجاری است.
اگرچه در پست اولیه دادههای بنچمارک یا نمونهکد ارائه نشده، اما عمق این راهنما نشاندهنده چرخش به سمت قواعد کیفی برای مدیریت ارکستراتورهای متمرکز در برابر تفویض اختیار همتا-به-همتا است. این تغییر پارادایم یادآور دیدگاه رایان لوپوپولو است که مهندسی هارنس را به عنوان جایگزینی برای رویکردهای سنتی پرامپت پیشنهاد داد تا پایداری سیستمهای عاملمحور تضمین شود.
گام بعدی شما
- ساختار ارتباطی عاملهای خود را از حالت پخش همگانی (Broadcast) به مدلهای سلسلهمراتبی تغییر دهید.
- برای هر عامل یک نقش گره (Node Role) صریح تعریف کنید تا تداخل وظایف کاهش یابد.
- منتظر انتشار پست وبلاگی یا ویدیوهای تکمیلی اندرو انجی در دو هفته آینده باشید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو