تصور کنید مدیر لجستیکی هستید که میخواهد در کمتر از دو دقیقه بفهمد کدام محمولات در فصل گذشته بیش از ۴۸ ساعت تأخیر داشتهاند، این تأخیرها چه ارتباطی با وضعیت آبوهوا داشتند، چه ضربهای به سودآوری مشتریان درجهیک زده است و الگوهای تراکم در بنادر چه بودهاند. در سامانههای سنتی، چنین درخواستی پیچیده یا باعث کرش کردن یک سیستم یکپارچه (monolithic) میشد یا پس از ۴۰ دقیقه پردازش، با خطای Time-out مواجه میشد. در یک دستیار LLM ساده، چنین درخواستی یا به دلیل دادههای ناقص منجر به توهم (hallucination) میشد یا به دلیل محدودیتهای پنجره بافت (context limits) از پاسخ دادن امتناع میکرد.
امروز این فرآیند در کمتر از ۹۰ ثانیه به پایان میرسد. این جهش در عملکرد مدیون تغییر رویکرد از مدلهای سادهٔ «درخواست-پاسخ» به معماری «برنامهریزی-اجرا-ترکیب» (plan-execute-synthesize) است. به جای اینکه یک مدل سعی کند همه کارها را انجام دهد، تیمی از عاملهای متخصص، دادهها را در محیطهای توزیعشده سازماندهی و هماهنگ میکنند.
این گذار در حالی رخ میدهد که بازار هوش مصنوعی عاملمحور طبق گزارش Svitla Systems، از ۷.۶ میلیارد دلار در سال ۲۰۲۵ به ۱۰.۸ میلیارد دلار در سال ۲۰۲۶ خواهد رسید. گارتنر تخمین میزند که تا پایان سال ۲۰۲۶، ۴۰٪ از اپلیکیشنهای سازمانی عاملهای وظیفهمحور را در خود ادغام کنند. در حال حاضر اکثر سازمانها بین دو گزینه شکستخورده گیر کردهاند: سامانههای سنتی مانند Apache Spark، Presto و BigQuery که قدرت پردازش مقیاسپذیری دارند اما نمیتوانند درباره زبان طبیعی مبهم استدلال کنند، و دستیارهای LLM که استدلال خوبی دارند اما نمیتوانند روی پتابایتها داده مقیاس بگیرند یا وضعیت (state) را در خطلولههای پردازشی چندساعته حفظ کنند. سامانههای توزیعشدهٔ عاملمحور با عمل کردن به عنوان یک لایه استدلالی و ارکستراسیون بر روی زیرساختهای محاسباتی توزیعشده، این شکاف را پر میکنند و از پروتکل زمینهٔ مدل (MCP) برای اتصال هر عامل به سیستمهای دادهای مورد نیازش استفاده میکنند.
معماری چهارلایه
به نقل از یک راهنمای جامع مهندسی منتشرشده در dev.to در تاریخ ۱۶ ژوئیه ۲۰۲۶، الگوی برنده شامل چهار لایه مجزا است:
- لایه درک پرسوجو: این لایه یک درخواست خام به زبان طبیعی، SQL یا ترکیبی را به یک نقشه اجرایی ساختاریافته تبدیل میکند. وظایف این لایه شامل طبقهبندی قصد (تجمیعی، مقایسهای، علّی، اکتشافی یا چندگام)، استخراج زیر-پرسوجوها و نگاشت وابستگیها است. خروجی این لایه یک دستور SQL ساده نیست، بلکه یک گراف جهتدار بدون دور (DAG) از زیر-وظایف با ورودیها، خروجیها و اهداف مسیریابی تعریفشده است.
- لایه ارکستراسیون: این لایه به عنوان کنترلکننده ترافیک عمل میکند. از پروتکل A2A برای هماهنگی بین عاملها استفاده کرده و شیء وضعیت جهانی پرسوجو (global query state object) را مدیریت میکند. این لایه با اجرای موازی زیر-وظایف مستقل و توالیبندی وظایف وابسته، تضمین میکند که پیشنیازها پیش از اجرا برطرف شدهاند.
- لایه اجرا: در این مرحله، عاملهای متخصص کار واقعی را انجام میدهند. اینها شامل عاملهای SQL برای پایگاههای داده رابطهای، عاملهای پیمایش گراف برای گرافهای دانش، عاملهای جستجوی برداری برای ذخیرهگاههای Embedding و عاملهای API برای سرویسهای خارجی هستند. تمام اینها از طریق پروتکل زمینهٔ مدل (MCP) متصل شدهاند که به عاملها اجازه میدهد بدون توجه به نوع پایگاه داده، ابزارهای استاندارد را فراخوانی کنند. این رویکرد بهینه در مدیریت دادههای برداری، با بهرهگیری از شتابدهندههای گرافیکی در نسخههای جدید PostgreSQL میتواند بازدهی کل سیستم را بهطور چشمگیری افزایش دهد.
- لایه ترکیب: این مرحله نهایی، نتایج تمام زیر-وظایف تکمیلشده را دریافت میکند. این یک فرآیند پیچیده برای حل تضاد بین منابع، مدیریت نتایج ناقص و حفظ سازگاری واقعبینانه است. خروجی این لایه یک «زنجیره اثبات» (provenance chain) است که هر ادعا در پاسخ نهایی را به زیر-وظیفه و سیستم دادهای خاص خود متصل میکند.
این معماری توسط چارچوب Academy (مقاله arXiv:2505.05428، بهروزرسانیشده در ژانویه ۲۰۲۶) تأیید شده است که این ساختار را برای محاسبات علمی و محیطهای HPC جهت مدیریت پروتکلهای دسترسی متنوع و الگوهای اجرای ناهمگام پیاده کرده است.
حل مسئلهٔ تجزیهٔ پرسوجو
تجزیهٔ پرسوجو (Query Decomposition) اهرم اصلی این پشته است. استخراج سادهٔ کلمات کلیدی اغلب در استدلالهای «چندگام» (multi-hop) شکست میخورد؛ یعنی جایی که پاسخ سؤال اول (مثلاً «کدام محمولات تأخیر داشتند؟») ورودی سؤال دوم (مثلاً «آبوهوای آن مکانهای خاص چطور بود؟») را تعیین میکند.
پژوهشهای DocETL (منتشرشده در VLDB ۲۰۲۵) نشان میدهد که treating کردن تجزیه به عنوان «بازنویسی پرسوجو» و «تولید نقشه»، دقت را در وظایف پیچیده مستنداتی بین ۲۵٪ تا ۸۰٪ افزایش میدهد. این فرآیند یک توالی سختگیرانه پنجمرحلهای را دنبال میکند:
۱. طبقهبندی قصد: تعیین اینکه پرسوجو تجمیعی، مقایسهای، علّی، اکتشافی یا چندگام است. کلاسِ انتخاب شده، استراتژی را تعیین میکند؛ برای مثال، پرسوجوهای تجمیعی به وظایف جمعآوری موازی تقسیم میشوند که به یک مرحله نهایی واحد میرسند.
۲. استخراج زیر-پرسوجوها: شکستن درخواست به سؤالات اتمیک. برای مثال، درخواستی برای محمولات تأخیری، بررسی آبوهوا، مواجهه مالی و الگوهای تراکم، به چهار سؤال اتمیک با وابستگیهای حیاتی تقسیم میشود.
۳. نگاشت وابستگی: ساخت DAG برای جلوگیری از گلوگاههای سریالسازی. گرافی که به اشتباه پرسوجوهای قابل اجرا به صورت موازی را به صورت متوالی (Serial) تعریف کند، رایجترین گلوگاه عملکرد در این سیستمهاست.
۴. مسیریابی منبع داده: تطبیق زیر-پرسوجو با بهینهترین موتور. دادههای ساختیافته به SQL، دادههای بدون ساختار به عاملهای برداری/مستند، روابط به عاملهای گراف و دادههای خارجی به عاملهای API ارسال میشوند.
۵. تخمین هزینه: پیشبینی هزینه محاسباتی. با پیروی از رویکرد FrugalGPT در مسیریابی به سمت ارزانترین مدلِ قادر، میتوان تا ۹۸٪ کاهش هزینه بدون افت دقت به دست آورد.
برای بهینهسازی بیشتر، الگوی «آبشار وظایف» (Task Cascade) توصیفشده در ACM Management of Data ۲۰۲۶، جستجوهای ساده را ابتدا از یک طبقهبندیکننده سریع عبور میدهد. اگر پرسوجو با یک جستجوی ساده قابل پاسخ باشد، کل مسیر گرانقیمت تجزیه و اجرای موازی را دور میزند. این رویکرد با تبدیل وظایف به آبشاری از عملیات ارزانتر و ارجاع رکوردهای نامطمئن به یک مدل «اوراکل» گرانقیمت، هزینههای سرتاسری را در هشت وظیفه پردازش مستندات (با دقت هدف ۹۰٪) به طور متوسط ۳۶٪ کاهش میدهد.
مدیریت حالت و اجرا در محیط توزیعشده
مدیریت حالت (State) در میان این عاملها یک چالش عظیم سیستمهای توزیعشده است. سیستم یک شیء وضعیت جهانی را نگه میدارد که قابل سریالسازی و نسخهبندی است. این شیء، نقشه اصلی، وضعیت هر زیر-وظیفه، نتایج وظایف تکمیلشده، حالتهای میانی ترکیب، مصرف منابع accumulated و زنجیره اثبات را ردیابی میکند.
با استفاده از پروتکل A2A، هر زیر-وظیفه از یک ماشین وضعیت عبور میکند:
- Submitted (ارسالشده): اعزام به عامل.
- Working (در حال پردازش): عامل در حال پردازش است. برای مجموعه دادههای بزرگ، عاملها بهروزرسانیهای پیشرفت میانی را استریم میکنند تا اگر وابستگیهای پاییندستی پیشتر برطرف شده بودند، امکان پایان زودهنگام فراهم شود.
- Input-required (نیازمند ورودی): عامل به دلیل ابهام یا خطاهای منبع، نیاز به شفافسازی دارد و ارکستراتور باید درباره استراتژی جایگزین تصمیم بگیرد.
- Completed (تکمیلشده): نتیجه در وضعیت جهانی نوشته میشود.
- Failed (شکستخورده): بروز خطا. این حالت باعث میشود ارکستراتور بین تلاش مجدد، مسیریابی به منبع جایگزین یا علامتگذاری پرسوجو به عنوان «پاسخدادنی جزئی» تصمیم بگیرد.
نقاط بازرسی (Checkpointing) برای پرسوجوهای طولانیمدت ضروری است تا در برابر شکستهای گذرا مانند قطعی شبکه یا محدودیتهای نرخ API (Rate Limits) مقاوم باشند. ارکستراتور شیء وضعیت را در ذخیرهگاههای بادوام ذخیره میکند: Apache Cassandra برای محیطهایی با نرخ نوشتن بالا یا PostgreSQL برای نیازهای حساس به سازگاری.
در محیطهای محاسباتی با عملکرد بالا (HPC)، چارچوب Academy از معناشناسی «ارسال از طریق ارجاع» (pass-by-reference) از طریق اشیاء پروکسی استفاده میکند. به جای سریالسازی و انتقال مجموعهدادههای عظیم بین عاملها (که باعث مسدود شدن صفهای پیام میشود)، عاملها ارجاعات سبک را منتقل میکنند که از طریق مکانیسمهای انتقال خارج از باند (out-of-band) به دادههای واقعی دسترسی پیدا میکنند. این امر برای مدیریت حجم دادههایی که در حالت عادی غیرممکن هستند، حیاتی است. برای دستیابی به سرعتهای عملیاتی بالاتر، معماریهایی مانند ناهمگام Stormchaser توانستهاند تأخیر عاملها را به شدت کاهش دهند تا پاسخدهی به سطح میلیثانیه برسد.
دسترسی فدرسیون دادهها از طریق MCP
دادهها در سازمانها به ندرت در یک مکان هستند. الگوی فدراسیون MCP هر منبع داده (PostgreSQL, Snowflake, MongoDB و غیره) را در یک سرور MCP میپیچد. عامل اجرا یک ابزار استاندارد را فراخوانی میکند و سرور MCP آن درخواست را به پروتکل بومی سیستم ترجمه میکند. برای مثال، سرور MCP مربوط به PostgreSQL یک کوئری SQL تولید میکند، در حالی که سرور Elasticsearch یک کوئری مخصوص خود را میسازد، اما عامل تنها یک رابط یکپارچه میبیند.
برای جلوگیری از هزینه مسیریابی اشتباه، پژوهش arXiv:2502.19280 با عنوان «جستجوی فدرال کارآمد برای RAG با استفاده از مسیریابی سبک» (بهروزرسانی آوریل ۲۰۲۶) توصیه میکند از مدلهای مسیریابی اختصاصی استفاده شود. این مدلهای کوچک و سریع روی ترافیک عملیاتی آموزش دیدهاند تا منبع داده بهینه را پیشبینی کنند و از نظر هزینه-بهرهوری، بسیار بهتر از قوانین استاتیک یا مسیریابی LLMهای سنگین عمل میکنند.
از آنجا که منابع مختلف از قراردادهای شمای متفاوتی استفاده میکنند (مثلاً ستونهای رابطهای در مقابل مستندات تودرتو)، سیستم از الگوی Schema-on-Read استفاده میکند. هر سرور MCP دادهها را با شمای طبیعی خود برمیگرداند و عامل ترکیب (synthesis agent) اینها را با استفاده از یک «رجیستری شمای متمرکز» که نام فیلدهای منبع را به شناسههای مفهومی یکپارچه متصل میکند، تطبیق میدهد.
ترکیب نتایج و مدیریت خطا
ترکیب نتایج (Synthesis) اغلب سختتر از اجرای آنهاست. چون عاملها دادهها را در زمانهای مختلف میخوانند، ناهماهنگیهای زمانی رخ میدهد. مهندسان اکنون از «سازگاری با محدوده زمانی» (timestamp-bounded consistency) استفاده میکنند که در آن هر زیر-وظیفه برچسب زمانی خواندن را ثبت میکند. عامل ترکیب نتایج را علامتگذاری میکند اگر این پنجره از یک آستانه خاص فراتر رود: ۱۰۰ میلیثانیه برای دادههای مالی بلادرنگ یا ۲۴ ساعت برای تحلیلهای دستهای (batch).
ترکیب نتایج از طریق ترکیب پیشرونده (Progressive Synthesis) بهینه میشود. سیستم منتظر تکمیل کل DAG نمیماند، بلکه به محض اتمام اولین زیر-وظایف، شروع به ساخت یک پاسخ موقتی میکند. این پاسخ با رسیدن نتایج بعدی بهروز و اصلاح میشود. در صورت بروز تضاد، عامل یک سلسلهمراتب سختگیرانه را دنبال میکند:
- منبع معتبر (Authoritative Source): بر منابع غیرمعتبر پیروز میشود (طبق تعریف در رجیستری شما).
- تازگی (Recency): دادههای جدیدتر بر دادههای قدیمیتر اولویت دارند.
- جزئیات (Granularity): دادههای دقیقتر و جزئیتر بر دادههای تجمیعی پیروز میشوند.
علاوه بر این، سیستم از «الگوی نتایج جزئی» (Partial Results Pattern) استفاده میکند. اگر یک زیر-وظیفه شکست بخورد، سیستم یک ارزیابی اثرگذاری شکست انجام میدهد تا بفهمد آیا آن وظیفه در «مسیر بحرانی» بود یا صرفاً «غنیسازی اختیاری». اگر اختیاری بود، سیستم یک پاسخ کاهشیافته (مثلاً تحلیل ریزش مشتری بدون انتساب بازاریابی) را همراه با متادیتای پوشش و افشای منابع در دسترس نبود را ارائه میدهد. با این حال، باید توجه داشت که حتی با این ساختارهای پیشرفته، برخی بنچمارکهای سختگیرانه مانند Stripe نشان دادهاند که عاملها همچنان در مراحل حساس اعتبارسنجی نهایی ممکن است با چالشهای جدی مواجه شوند.
برای بازیابی، ارکستراتور یک سیاست تلاش مجدد (retry) لایهبندی شده را اجرا میکند: تلاش مجدد فوری برای خطاهای گذار شبکه، عقبنشینی نمایی (exponential backoff) برای خطاهای محدودیت نرخ، بازگشت به منابع جایگزین برای عدم دسترسی به منابع، و ارجاع فوری به مدیر سیستم برای خطاهای مجوز دسترسی.
موازنه هزینه و تأخیر
اقتصاد توکنها یک محدودیت اصلی است. یک پرسوجوی پیچیده در ۱۰ منبع میتواند ۳۰,۰۰۰ تا ۱۰۰,۰۰۰ توکن مصرف کند که هزینهای بین ۰.۰۳ تا ۰.۱۵ دلار برای هر کوئری دارد. برای مقابله با این موضوع، FrugalGPT (چن و همکاران، ۲۰۲۴) نشان داد که مسیریابی زیر-وظایف ساده به مدلهای ارزانتر میتواند بدون از دست دادن دقت، تا ۹۸٪ کاهش هزینه ایجاد کند.
تأخیر (Latency) توسط کندترین زیر-وظیفه در مسیر بحرانی تعیین میشود. موثرترین بهینهسازیها عبارتند از:
- کش کردن زیر-وظایف: استفاده از TTL برای زیر-پرسوجوهای پرتکرار (مثلاً «دریافت محمولات تأخیری Q1 ۲۰۲۶») برای حذف محاسبات تکراری.
- کش معنایی (Semantic Caching): شناسایی پرسوجوهای معادلاً از نظر معنایی برای اجتناب از اجرای مجدد، که پژوهشها نشان میدهد میتواند بهبود سرعت تا ۱۵ برابر ایجاد کند.
- موازنه (Parallelization): حذف سریالسازیهای غیرضروری در گراف وابستگی برای کوتاه کردن مسیر بحرانی.
پیادهسازی در محیط عملیاتی و چارچوب تصمیمگیری
استقرارهای موفق در محیط عملیاتی معمولاً از سه الگوی تکرارشونده پیروی میکنند:
۱. لایه پرسوجوی Mesh داده: استفاده از یک سرور MCP برای هر محصول دادهای دامنه (domain data product). این به تیمهای دامنه اجازه میدهد کنترل ذخیرهگاهها و شمای خود را حفظ کنند، در حالی که عامل تجزیه، زیر-پرسوجوها را در مرزهای دامنه مسیریابی میکند تا بینشهای بین-دامنهای ایجاد کند.
۲. عاملهای تحلیل سری زمانی: تجزیه پرسوجوهای IoT به زیر-پرسوجوهای موازی در بازههای زمانی. این روش از عاملهای متخصص برای تشخیص ناهنجاری، تحلیل همبستگی و تطبیق الگوهای تاریخی برای ارائه ارزیابی یکپارچه از دادههای حسگر استفاده میکند.
۳. گردشهای علمی فدرسیون: هماهنگسازی عاملها در سیستمهای HPC مانند Aurora و Polaris با استفاده از ارسال پیام. چارچوب Academy توانایی درخواست کار، فعالسازی رویدادهای دورهای و مقیاسبندی پویا منابع بر اساس حجم کاری را نشان میدهد.
چه زمانی از این معماری استفاده کنیم؟
- وقتی پرسوجوها بیش از ۳ منبع ناهمگن را بدون یک رابط مشترک درگیر میکنند.
- زمانی که استدلال واقعاً چندگام (multi-hop) مورد نیاز است.
- وقتی زمان اجرا در سیستمهای موجود از تأخیر قابل قبول فراتر میرود.
- وقتی مجموعه داده ترکیبی از مودالیتههای ساختیافته و بدون ساختار است.
- وقتی حجم پرسوجوها به قدری زیاد است که سرمایهگذاری روی ارکستراسیون را توجیه کند.
چه زمانی از آن اجتناب کنیم؟
- اگر پرسوجوها تکراری هستند و میتوانند توسط یک Job بهینه در SQL یا Spark مدیریت شوند.
- اگر دادهها تنها در یک یا دو سیستم بهخوبی ساختاریافته قرار دارند.
- اگر تیم شما عمق دانش لازم در سیستمهای توزیعشده برای دیباگ هماهنگیهای چند-عاملی را ندارد.
اگر برای استقرار برنامهریزی میکنید، ابتدا سرورهای MCP خود را بسازید و سپس به سراغ ساخت ارکستراتور بروید. ساختن «مغز» پیش از «دستها» معمولاً منجر به این کشف میشود که دسترسی به دادهها گلوگاه واقعی است، نه هوش سیستم. سپس عامل تجزیه را اضافه کرده و کیفیت آن را مستقل از کیفیت اجرا، با ترافیک واقعی بسنجید. در نهایت، اجرای موازی و ترکیب نتایج را اضافه کنید.
هر انتقال وضعیت وظیفه A2A و هر فراخوانی MCP را با استفاده از OpenTelemetry و LangSmith ابزاربندی (Instrument) کنید. برای متریکهای سیستم از Prometheus و Grafana استفاده کنید. دیباگ کردن یک سیستم عاملمحور توزیعشده بدون Trace (ردیابی) اساساً غیرممکن است.
گام بعدی شما
- بررسی پروتکل MCP برای استانداردسازی دسترسی عاملها به دیتابیسهای مختلف.
- پیادهسازی یک طبقهبندیکننده ساده (Classifier) برای تفکیک پرسوجوهای «سریع» از «پیچیده» جهت کاهش هزینه.
- استفاده از ابزارهای Trace برای تحلیل مسیر بحرانی در گراف وابستگی وظایف.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو