معماری غیرمتمرکز عامل‌های هوش مصنوعی هزینه استنتاج را ۴۰٪ کاهش داد

تصور کنید یک باشگاه ورزشی را اداره می‌کنید، اما به جای کارکنان انسانی، ۹ متخصص دیجیتال تمام امور را مدیریت می‌کنند. این دیگر یک دمو یا آزمایش آزمایشگاهی نیست؛ بلکه یک استقرار واقعی است که ۹۹٪ عملیات روزانه یک باشگاه در شهر دونگ‌گوان چین را بر عهده دارد. به نقل از گزارش منتشر شده در ۶ جولای ۲۰۲۶ در وب‌سایت dev.to، این سامانه با سخت‌افزاری بسیار ابتدایی شامل تنها ۲ هسته پردازشی (CPU) و ۳.۶ گیگابایت رم اجرا می‌شود.

نکته کلیدی اینجاست که برخلاف اکثر نمایش‌های تبلیغاتی، این سیستم از یک «مدیریت مرکزی» استفاده نمی‌کند. توسعه‌دهندگان در هفته اول متوجه شدند که وقتی یک ارکستراتور مرکزی دچار شکست می‌شود، تمام عامل‌ها عملاً کور شده و توانایی عمل از دست می‌دهند؛ زیرا این ساختار یک تک‌نقطه شکست (Single Point of Failure) ایجاد می‌کند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن و پایداری سیستم‌های توزیع‌شده اشاره کردیم، حذف این نقطه بحرانی حیاتی است. این چالش در واقع ریشه در همان مشکلاتی دارد که در تحلیل ما درباره‌ی ناکارآمدی مدل‌های قدرتمند در رفع شکست‌های ساختاری عامل‌ها بررسی شد، جایی که مدل بهتر لزوماً به معنای سیستم پایدارتر نیست. برای حل این مشکل، آن‌ها یک سیستم «قانون‌مدار» یا «قانون اساسی» ایجاد کردند که در آن عامل‌ها (Agents) — شبیه به کارمندانی که هر کدام دستورالعمل دقیقی در دست دارند و بدون نیاز به رئیس، با هم هماهنگ می‌شوند — از طریق یک گذرگاه مشترک (Agent-Bus) با مدل انتشار/اشتراک (pub/sub) با یکدیگر ارتباط برقرار می‌کنند.

زمینه: اکوسیستم عامل‌ها

این سیستم از ۹ عامل تخصصی تشکیل شده است که هر یک نقش متمایزی در اکوسیستم باشگاه ایفا می‌کنند. این نقش‌ها عبارتند از:

• Baron: مدیریت و تولید محتوای برند
• Stella: حسابرسی و کنترل کیفیت
• Zeus: استراتژی‌های سرمایه‌ای
• Luna: عملیات مربوط به جامعه و کاربران
• Tristan: مدیریت زیرساخت
• Ethan: یکپارچگی و صحت داده‌ها
• Shuyu: فرماندهی کلی عملیات
• Melody: مربیگری متابولیک
• Momo: عملیات فروشگاه و فروش

الگوهای معماری

بر اساس مستندات فنی، این سیستم برای حفظ پایداری در طول ۳.۵ ماه عملیات تولیدی، از ۵ الگوی کلیدی استفاده می‌کند:

• حذف ارکستراتور مرکزی: عامل‌ها با استفاده از cron خودشان را زمان‌بندی می‌کنند و از طریق یک گذرگاه (Bus) مشترک ارتباط می‌گیرند. هر عامل از دو فایل حیاتی پیروی می‌کند: SOUL.md که حکم قانون اساسی و دستورالعمل‌های اخلاقی-عملیاتی او را دارد و SKILL.md که فهرست ابزارهای در دسترس اوست. در این معماری، گذرگاه تنها وابستگی مشترک است.
• امتیازدهی اطمینان پیش از اجرا: عامل‌ها به جای واکنش به هر فعال‌ساز (Trigger)، یک پیش‌بررسی وزن‌دار انجام می‌دهند. آن‌ها چهار معیار را در بازه ۰ تا ۱ تحلیل می‌کنند: امتیاز تطابق قصد (Intent match)، امتیاز فوریت (Urgency)، امتیاز اثرگذاری (Impact) و بررسی تکراری نبودن (Duplication check). تنها تسک‌هایی که امتیاز ترکیبی وزن‌دار آن‌ها از آستانه قابل تنظیمی مانند ۰.۷ بالاتر باشد، اجرا می‌شوند.
• لایه حسابرسی: عاملی به نام Stella به عنوان یک ناظر خارجی عمل می‌کند. استلا هیچ تسکی را اجرا نمی‌کند؛ بلکه به طور مستقل تمامی خروجی‌ها را از نظر صحت واقعی، انطباق با محدوده (Scope) و یکپارچگی روایت بررسی می‌کند. اگر استلا موردی را علامت‌گذاری کند، خروجی بدون هیچ استثنایی متوقف و نگه داشته می‌شود.
• حافظه مشترک، اراده مستقل: عامل‌ها اطلاعات را از فایل‌های دانش دائمی مشترک و جریان رویدادهای Agent-Bus می‌خوانند. با این حال، هر عامل فایل‌های حافظه و تاریخچه شخصی خود را دارد. هیچ عاملی نمی‌تواند محدوده عمل (Scope) عامل دیگر را تغییر دهد تا از وقوع شکست‌های زنجیره‌ای جلوگیری شود.
• پل انسانی: برای عملیاتی که نیاز به اعتماد و امضای رسمی دارند، نقاط بازرسی (Checkpoints) صریحی تعریف شده است. این موارد شامل راه‌اندازی حساب‌های خارجی، اسناد قانونی که نیاز به امضای مؤسس دارند و تصمیمات استراتژیکی است که معیارهای تعریف‌شده‌ای ندارند.

جزئیات فنی

این مکانیسم امتیازدهی اطمینان به تنهایی منجر به کاهش ۶۰ درصدی اقدامات غیرضروری شد و هزینه مصرف توکن‌ها را تا ۴۰٪ کاهش داد. این رویکرد بهینه‌سازی هزینه‌ها شباهت زیادی به معماری مسیریاب‌های قطعی برای کاهش هزینه‌های عملیاتی دارد که در آن با دقت در مسیریابی درخواست‌ها، مصرف توکن‌ها به شدت کاهش می‌یابد. پشته فنی این پروژه برای بهره‌وری حداکثری روی یک نمونه سبک (Light Instance) در Tencent Cloud طراحی شده است:

• زمان اجرا (Runtime): استفاده از Node.js از طریق فریم‌ورک OpenClaw.
• ارتباطات: مدل pub/sub در گذرگاه عامل‌ها که از رویدادهای مبتنی بر فایل (file-based events) استفاده می‌کند.
• حافظه: ترکیب سیستم فایل با مکمل‌های ویکی که قابل کامپایل هستند.
• مسیریابی مدل: استفاده از DeepSeek V4؛ به طوری که برای اکثر عملیات‌ها از «حالت سریع» (flash mode) و برای استراتژی‌های پیچیده از «حالت کامل» (full mode) استفاده می‌شود.
• حاکمیت: فایل‌های SOUL.md مجزا برای هر عامل در کنار دانش دائمی مشترک.

برای متخصصان و توسعه‌دهندگان، این تغییر نشان می‌دهد که صنعت در حال حرکت از «مهندسی پرامپت» (Prompt Engineering) — که هنر سؤال درست پرسیدن است — به سمت «حاکمیت پایدار» (Persistent Governance) است. در حالی که پرامپت‌ها دائماً تغییر می‌کنند، قانون‌نامه‌ها (Constitutions) باقی می‌مانند؛ به طوری که فایل‌های SOUL.md این باشگاه در ۳.۵ ماه عملیاتی تنها ۴ بار تغییر یافتند. هر یک از این تغییرات یک تصمیم حاکمیتی آگاهانه بود، نه یک اصلاح ساده در پرامپت.

توسعه‌دهندگان تأکید می‌کنند که قابلیت حسابرسی (Auditability) بسیار ارزشمندتر از صرفاً زمان فعال بودن (Uptime) است. از نظر آن‌ها، Uptime ۹۹.۹ درصدی بی‌معناست اگر نتوانید ثابت کنید چرا یک عامل تصمیم خاصی گرفته است. با ثبت (Log) همه چیز در ابتدا و فیلتر کردن در مراحل بعدی، آن‌ها ذخیره‌سازی را ارزان و دیباگ کردن بدون داشتن بستر (Context) را گران فرض کرده‌اند.

در نگاه به آینده، هدف این پروژه مقیاس‌پذیری از یک فروشگاه به ۱۰ فروشگاه از طریق استقرار چند-باشگاهی است. آن‌ها همچنین در حال توسعه پشتیبانی از عامل‌های خارجی هستند تا عامل‌های شخص ثالث بتوانند به گذرگاه (Bus) متصل شوند و یک مشخصات رسمی برای پروتکل PoPB (اثبات رفتار فیزیکی) تدوین می‌کنند.

توسعه‌دهندگان اکنون می‌توانند کد کامل این پروژه را از طریق مخزن گیت‌هاب ZWISERFIT بررسی کنند تا این الگوها را برای اتوماسیون کسب‌وکارهای فیزیکی تحلیل نمایند.

گام بعدی شما

• بررسی مخزن ZWISERFIT برای درک نحوه پیاده‌سازی فایل‌های SOUL.md
• تست مکانیسم امتیازدهی (Confidence Scoring) برای کاهش هزینه‌های API در پروژه‌های خود
• مطالعه معماری pub/sub برای جایگزینی ارکستراتورهای متمرکز در سیستم‌های چندعاملی

اما اثر این معماری بر مصرف سخت‌افزارها حتی شگفت‌انگیزتر است؛ به تحلیل ما درباره‌ی تراشه‌های LPU و بهینه‌سازی استنتاج مراجعه کنید.