تصور کنید می‌خواهید در یک بازی شطرنج حساس شرکت کنید، اما هم‌زمان باید کتابچه قوانین بازی را بنویسید و تمام حرکات خود را هم بازرسی کنید. برای اکثر کاربران، این یعنی رسیدن به سقف توانایی‌های یک عامل (Agent) واحد؛ نقطه‌ای که در آن پنجره زمینه (Context Window) — مانند میز کاری که فقط جای چند ورق کاغذ دارد و کل کتابخانه در آن جا نمی‌شود — بیش از حد شلوغ شده و استدلال مدل تیره و تار می‌شود.
طبق یک به‌روزرسانی فنی در ۵ جولای ۲۰۲۶ در وب‌سایت dev.to، پلتفرم Halo برای شکستن این محدودیت، معماری خود را از یک «مغز» واحد به پنج عامل متخصص تغییر می‌دهد. تا پیش از این، Halo تمام مراحل شناسایی، بهره‌برداری و اصلاح خطا را در یک حلقه واحد مدیریت می‌کرد. هرچند این روش برای ادغام ۲۴ ابزار و مدیریت حافظه شکست‌ها (failure cache) که برای هر پروژه به‌طور مجزا تعریف می‌شد، کارساز بود، اما در نهایت به یک گلوگاه رسید.
یک مشکل حیاتی در این ساختار، «مسموم‌سازی» داده‌ها بود. به نقل از تیم توسعه، چون سیستم از یک مدل و یک پنجره متنی واحد برای همه کارها استفاده می‌کرد، یک اشتباه کوچک در مرحله شناسایی اولیه — مثلاً یک فرض غلط درباره شبکه — به‌سادگی تمام مراحل بعدی را مسموم می‌کرد. این اتفاق به این دلیل رخ می‌داد که عامل نمی‌توانست ذهنیتی که برای برنامه‌ریزی نیاز دارد را از ذهنیتی که برای حمله لازم است تفکیک کند و هر دو برای تصاحب فضای محدود حافظه با هم می‌جنگیدند.
همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های عامل‌محور اشاره کردیم، جداسازی لایه‌های تصمیم‌گیری از لایه‌های اجرا، کلید پایداری در سیستم‌های پیچیده است. برای حل این چالش، Halo اکنون یک لایه ارکستراسیون (Orchestration) چندعاملی را پیاده می‌کند تا اطمینان حاصل شود که شکست در یک حمله، به‌جای تبدیل شدن به یک دیوار متنی گیج‌کننده که برنامه‌ریز مجبور به باز کردن گره‌های آن باشد، به‌عنوان یک سیگنال دقیق برای عیب‌یاب ارسال شود.
زمینه این تغییر
یک تست نفوذ (Pentest) تک‌وظیفه نیست، بلکه ترکیبی از ۵ یا ۶ نوع تفکر متفاوت است که به هم دوخته شده‌اند. این مراحل شامل موارد زیر است: تعیین هدف نهایی، تصمیم‌گیری برای ترتیب عملیات، اجرای عملیات حمله، شناسایی نقاط ضعف و در نهایت اصلاح مسیر زمانی که یک متد خاص با شکست مواجه می‌شود.
با تقسیم این مسئولیت‌ها، هر عامل وظیفه‌ای کوچک‌تر و متمرکزتر دریافت می‌کند. این کار مانع از آن می‌شود که پنجره زمینه توسط دغدغه‌هایی که متعلق به فاز دیگری از پروژه هستند، آلوده شود. این تغییر، سیستم را از «یک عامل که ۵ شغل دارد» به «پنج عامل که هر کدام یک شغل دارند» تبدیل می‌کند.
معماری پنج‌عاملی Halo
Halo برای توزیع بار شناختی، پنج نقش مشخص را تعریف کرده است تا فشار روی مدل کاهش یابد:
- برنامه‌ریز (The Planner): استراتژی‌های سطح بالا را مدیریت می‌کند. این عامل به جای دستورات تک‌به‌تک، بر اساس استراتژی فکر می‌کند و تعیین می‌کند چه پیش‌شرط‌هایی باید پیش از هر اقدام محقق شوند و شکل کلی پروژه را طراحی می‌کند.
- هماهنگ‌کننده (The Orchestrator): مانند یک دیسپچر عمل می‌کند. این عامل بین برنامه‌ریز و سایر عامل‌ها قرار می‌گیرد، تصمیم می‌گیرد چه کسی باید در مرحله بعد وارد عمل شود و برش‌های درست اطلاعات را به متخصص مربوطه ارسال می‌کند.
- کاشف آسیب‌پذیری (Vulnerability Discovery): خروجی‌های اسکن، نتایج شمارش (enumeration) و داده‌های شناسایی را تفسیر می‌کند. وظیفه این بخش تبدیل این داده‌ها به یک لیست اولویت‌بندی شده از نقاط ضعف است، به‌جای آنکه تفسیر داده‌ها را تنها به‌عنوان یک اثر جانبی از حمله ببیند.
- مهاجم (The Attacker): روش‌های خاص را روی اهداف تعریف‌شده اجرا می‌کند. این عامل فقط به هدف، روش و ابزارهای لازم نیاز دارد و اصلاً نیازی نیست از نقشه کلی و جامع عملیات باخبر باشد.
- عیب‌یاب (The Debugger): خطاهای ابزاری یا حملات ناموفق را رصد می‌کند. تحلیل می‌کند که چرا یک مورد «عجیب» به نظر رسیده و این درک را به حافظه شکست‌های موجود برمی‌گرداند تا اشتباهات سه پروژه بعد تکرار نشوند.
این تحول، مهم‌ترین تغییر معماری این پلتفرم پس از پیاده‌سازی سرور MCP است. با محدود کردن دامنه هر عامل، تداخل‌های «فضای ذهنی» حذف شده و شکست‌ها به‌طور موثرتری ایزوله می‌شوند.
برای پژوهشگران امنیت و توسعه‌دهندگان، این به معنای سیستمی است که می‌تواند مدت‌زمان بیشتری فعال بماند و در صورت شکست، واکنش منعطف‌تری نشان دهد. در حال حاضر، اولویت طراحی تیم بر روی یک رویکرد «ابتدا طرح» (sketch-first) است. تیم روی مرزهای بین این نقش‌ها روی کاغذ تمرکز کرده است تا پیش از نوشتن هرگونه کد ارکستراسیون، جزئیات را نهایی کند و از بازنویسی‌های گران‌قیمت معماری در آینده جلوگیری نماید.
این گذار، تغییر از ابزاری است که صرفاً یک حلقه را با لیستی طولانی‌تر تکرار می‌کند، به سیستمی که در واقع در طول زمان بهبود می‌یابد. تیم برنامه دارد در مسیر تبدیل این طرح‌های اولیه به محصول نهایی، شفافیت کامل را حفظ کند.
منتظر جزئیات فنی آینده درباره فرمت‌های پیام‌رسانی (message-passing) و وضعیت مشترک (shared state) باشید، زیرا همین موارد تعیین می‌کنند که این پنج عامل در زمان واقعی چگونه با یکدیگر ارتباط برقرار می‌کنند.
گام بعدی شما
- اگر از ابزارهای اتوماسیون تست نفوذ استفاده می‌کنید، بررسی کنید که آیا سیستم شما لایه‌ی تفکیک بین «برنامه‌ریز» و «اجراکننده» دارد یا خیر.
- روی مفاهیم Message-passing در سامانه‌های چندعاملی مطالعه کنید تا متوجه شوید این ۵ عامل چگونه با هم ارتباط برقرار می‌کنند.
- مدل‌های استدلالی کوچک‌تر را برای نقش‌های تخصصی (مثل عیب‌یاب) امتحان کنید تا هزینه استنتاج را کاهش دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ اثر این معماری بر مصرف GPU را در تحلیل‌های آینده بررسی خواهیم کرد.
گفتگو