حافظه مشترک و الگوی تخته‌سیاه در سیستم‌های چندایجنتی

در طراحی سیستم‌های چندایجنتی (Multi-Agent Systems)، نگه‌داری و به‌اشتراک‌گذاری وضعیت میان ایجنت‌ها چالش‌برانگیزترین بخش معماری است. اگر هر ایجنت تمام پیام‌های پیشین را بخواند، پنجره‌ی زمینه‌اش (Context Window) خیلی سریع پر می‌شود و هزینه‌ی توکن سرسام‌آوری روی دست سیستم می‌گذارد؛ از طرف دیگر، اگر داده‌ها تفکیک نشوند، یک خطای ساده یا توهم کوچک در یکی از ایجنت‌ها به تمام گره‌های بعدی سرایت می‌کند و گزارش نهایی را کاملاً به انحراف می‌کشد.

این پدیده «مسموم‌سازی حافظه» نام دارد؛ باگی پنهان که با کرش کردن برنامه خودش را نشان نمی‌دهد، بلکه رفته‌رفته کیفیت پاسخ‌ها را پایین می‌آورد و ریشه‌یابی آن در زنجیره‌های پیچیده‌ی استدلال ساعت‌ها زمان می‌برد. در این درس، دو الگوی بنیادین حافظه مشترک یعنی «استخر پیام» (Message Pool) و «تخته‌سیاه همراه با اشتراک» (Blackboard with Subscription) را بررسی می‌کنیم و با استفاده از کتابخانه‌ی استاندارد پایتون، سازوکار مقابله با توهمات و ممیزی حافظه را پیاده می‌سازیم.

در سیستم‌های چندایجنتی سال 2026 دو رویکرد هم‌زمان وجود دارند: استخر پیام (Message pool؛ همه پیام‌های یکدیگر را می‌بینند، مانند AutoGen GroupChat یا MetaGPT) و تخته‌سیاه با اشتراک (Blackboard with subscription؛ ایجنت‌ها مشترک رویدادهای مرتبط می‌شوند، مانند Context-Aware MCP یا فریم‌ورک Matrix). این دو، تنها بخش‌های دارای وضعیت (Stateful) در یک سیستم چندایجنتی هستند؛ یعنی دقیقاً همان جایی که باگ‌های جذاب و چالش‌برانگیز شکل می‌گیرند. حالت شکست مرجع در اینجا مسموم‌سازی حافظه (Memory poisoning) است: یک ایجنت واقعیتی ساختگی را بر اثر توهم ثبت می‌کند، سایر ایجنت‌ها آن را واقعیتی اثبات‌شده فرض می‌کنند، و دقت سیستم به‌مرور افت می‌کند؛ افتی تدریجی که اشکال‌زدایی‌اش بسیار دشوارتر از یک کرش ناگهانی است. در این درس، هر دو ساختار را صرفاً با کتابخانه‌ی استاندارد پایتون پیاده‌سازی می‌کنیم، یک حمله‌ی مسموم‌سازی درون آن تزریق می‌کنیم، و سه راهکار کاهش ریسک را نشان می‌دهیم که در محیط عملیاتی واقعاً جواب می‌دهند.

صورت مسئله

سیستم‌های چندایجنتی به فضایی نیاز دارند تا ایجنت‌ها بتوانند فکت‌ها را با یکدیگر به اشتراک بگذارند. یک راهکار دم‌دستی این است که «همه‌چیز را از طریق پیام پاس دهیم»؛ اما این کار یعنی بازآفرینی همان وضعیت مشترک با کپی‌کاری‌های اضافی. گزینه‌ی دیگر این است که «یک لاگ سراسری در اختیار همه بگذاریم»؛ ولی لاگ‌های سراسری بی‌رویه رشد می‌کنند و خیلی راحت مسموم می‌شوند. راهکار سوم «تصویر کردن یک نما برای هر ایجنت» است؛ مقیاس‌پذیر، اما با ساختار و اسکیمای سنگین.

وقتی یکی از ایجنت‌ها دچار توهم می‌شود و همان توهم را در وضعیت مشترک می‌نویسد، تک‌تک ایجنت‌های بعدی که آن وضعیت را می‌خوانند، توهم را به عنوان فکتی قطعی می‌پذیرند. تا وقتی که انسان متوجه ماجرا شود، زنجیره‌ی استدلال پنج لایه عمیق‌تر شده و ریشه‌ی اصلی خطا به سومین پیام ثبت‌شده در سیستم برمی‌گردد. دیباگ کردن افت تدریجی دقت در سیستم‌های چندایجنتی، به‌مراتب سخت‌تر از دیباگ کردن یک کرش ناگهانی است.

این همان مسموم‌سازی حافظه است؛ دومین دسته‌ی پرتکرار خطاها در تاکسونومی MAST (مقاله‌ی Cemri و همکاران، arXiv:2503.13657). این نقص ساختاری است: هر معماری حافظه‌ی مشترکی که فاقد ثبت منشأ و سندیت (Provenance) و همچنین یک مدل اعتبارسنج (Verifier) غیرقابل‌نوشتن باشد، در نهایت به این سرنوشت دچار خواهد شد.

مفهوم

دو توپولوژی اصلی

استخر پیام کامل. همه‌ی ایجنت‌ها تک‌تک پیام‌ها را می‌خوانند. AutoGen GroupChat و MetaGPT از همین الگو استفاده می‌کنند. ساده، شفاف و کاملاً قابل‌بررسی است، اما به بیش از حدود 10 ایجنت مقیاس نمی‌پذیرد؛ چون کانتکست (Context) هر ایجنت با کارهای ایجنت‌های دیگر پر می‌شود.

agent-A ──write──▶ ┌────────────────┐ ◀──read── agent-D
                   │ message pool   │
agent-B ──write──▶ │                │ ◀──read── agent-E
                   │ (global log)   │
agent-C ──write──▶ └────────────────┘ ◀──read── agent-F

تخته‌سیاه با اشتراک. ایجنت‌ها موضوعات مورد علاقه‌ی خود را اعلام می‌کنند؛ بستر زیرین فقط پیام‌های مرتبط را هدایت می‌کند. CA-MCP (مقاله‌ی arXiv:2601.11595) و فریم‌ورک غیرمتمرکز Matrix (مقاله‌ی arXiv:2511.21686) از این الگو بهره می‌برند. مقیاس‌پذیری بالاتری دارد، اما برای این‌که اشتراک‌ها معنادار باشند، نیازمند طراحی اولیه‌ی اسکیما است.

                   ┌─ topic: prices ──┐
agent-A ──pub────▶ │                  │ ──▶ agent-D (subscribed)
                   ├─ topic: orders ──┤
agent-B ──pub────▶ │                  │ ──▶ agent-E (subscribed)
                   ├─ topic: alerts ──┤
agent-C ──pub────▶ │                  │ ──▶ agent-F (subscribed)
                   └──────────────────┘

برتری هر رویکرد در کجاست؟

• استخر پیام کامل زمانی برنده است که تعداد ایجنت‌ها کم باشد (کمتر از 10 ایجنت)، نقش‌های ناهمگنی داشته باشند و افق گفت‌وگو کوتاه باشد. وقتی همه همه‌چیز را می‌بینند، استدلال درباره‌ی این‌که چه کسی چه حرفی زد بسیار ساده است.
• تخته‌سیاه زمانی برنده است که ایجنت‌ها پرتعداد باشند، از نظر نقش یکسان اما در نمونه‌های زیاد اجرا شوند (ازدحام‌ها)، و گفت‌وگو طولانی‌مدت باشد. مسیریابی دقیق از اتلاف هزینه‌ی توکن و آلودگی کانتکست جلوگیری می‌کند.

سیستم‌های محیط عملیاتی اغلب این دو را ترکیب می‌کنند: یک استخر پیام کامل و کوچک در لایه‌ی بالا (لایه‌ی برنامه‌ریزی)، و تخته‌سیاه‌ها در لایه‌ی پایین‌تر (لایه‌ی ورکرها).

سناریوی مسموم‌سازی حافظه

سه ایجنت روی یک وظیفه‌ی پژوهشی کار می‌کنند. ایجنت A وظیفه‌ی بازیابی اطلاعات را دارد، ایجنت B خلاصه‌ساز است، و ایجنت C تحلیل‌گر.

1. ایجنت A صفحه‌ای را دریافت می‌کند و پیامی در وضعیت مشترک می‌نویسد: «این پژوهش از بهبود دقت 42 درصدی خبر می‌دهد.»
2. اما در صفحه‌ی دریافتی نوشته شده بود «4.2 درصد بهبود». ایجنت A در تشخیص ممیز دچار توهم شده است.
3. ایجنت B با خواندن وضعیت مشترک می‌نویسد: «بهبود بزرگ 42 درصدی در دقت گزارش شده است (منبع: A).»
4. ایجنت C با خواندن وضعیت مشترک می‌نویسد: «استفاده از آن توصیه می‌شود؛ رشد 42 درصدی تحول‌آفرین است.»
5. گزارش نهایی به رقم 42 درصدی استناد می‌کند که اساساً وجود خارجی نداشته است.

هیچ ایجنتی کرش نکرد. هیچ تستی خطا نداد. سیستم «کار کرد». با این حال، توهم از طریق وضعیت مشترک از کانتکست یک ایجنت به زنجیره‌ی استدلال تمام ایجنت‌های بعدی سرایت کرد.

چرا این نقص ساختاری است؟

اگر وضعیت مشترک وجود نداشت، توهم ایجنت A در همان کانتکست خودش باقی می‌ماند. ایجنت‌های بعدی یا دوباره اطلاعات را دریافت می‌کردند یا آن را از نو استخراج می‌کردند و شاید متوجه خطا می‌شدند. اما با یک وضعیت مشترک ناپخته و ساده‌انگارانه، کانتکست ایجنت A تبدیل به کانتکست همه‌ی ایجنت‌ها می‌شود و آن توهم به عنوان یک حقیقت مسلّم جا می‌افتد.

مسئله، خود وضعیت مشترک نیست؛ مسئله، وضعیت مشترک بدون منشأ و سندیت و بدون یک مدل اعتبارسنج مستقل است. سه راهکار برای مهار این مسئله وجود دارد:

1. ثبت منشأ و سندیت در هر عملیات نوشتن. هر رکورد در وضعیت مشترک ثبت می‌کند که چه کسی آن را نوشته، در چه زمانی، با چه پرامپتی، و (در صورت وجود) به چه منبعی استناد کرده است. ایجنت‌های بعدی اطلاعات را با تردیدی متناسب با منشأ و سندیت آن می‌خوانند.
2. نسخه‌بندی عملیات‌های نوشتن و برخورد الحاقی (Append-only) با آن‌ها. تصحیح یک خطا به‌صورت یک رکورد جدید ثبت می‌شود که جایگزین رکورد قبلی خواهد شد، نه به‌روزرسانی درجا. به این ترتیب، زنجیره‌ی حسابرسی حفظ می‌شود.
3. نگه‌داشتن حداقل یک ایجنت بدون دسترسی نوشتن در وضعیت مشترک. یک ایجنت اعتبارسنج فقط-خواندنی از رکوردها نمونه‌برداری می‌کند، منابع را مجدداً دریافت و بررسی می‌کند، و مغایرت‌ها را مشخص می‌سازد. این ایجنت هم استخر را می‌خواند، پس ممکن است با یک داده‌ی نادرست فریب بخورد؛ اما هر داده را با منبع اصلی تطبیق می‌دهد و چون اجازه‌ی نوشتن ندارد، احکامش هرگز فکت مسمومی را دوباره به وضعیت مشترک برنمی‌گرداند.

پیشینه‌ی معماری تخته‌سیاه (Hayes-Roth، سال 1985)

الگوی تخته‌سیاه چهار دهه قبل از ایجنت‌های LLM متولد شد. هیز-راث در سال 1985 در مقاله‌ی «A Blackboard Architecture for Control»، منابع دانشی متخصصی را توصیف کرد که یک تخته‌سیاه سراسری را زیر نظر دارند، راه‌حل‌های جزئی ارائه می‌دهند و سایر منابع دانشی را فعال می‌کنند. تخته‌سیاه سال 2026 (CA-MCP، Matrix) دقیقاً همان الگو است؛ منتها ایجنت‌های LLM نقش منابع دانش را بازی می‌کنند و داده‌های ساخت‌یافته‌ی JSON همان راه‌حل‌های جزئی هستند. در ادبیات قدیمی، راه‌حل‌های مدونی برای تداخل در نوشتن، کنترل فرصت‌طلبانه و سازگاری داده‌ها وجود دارد که سیستم‌های مدرن امروزه دوباره در حال کشف آن‌ها هستند.

تصویر کردن در برابر نمای کامل

یک تخته‌سیاه خالص به تمام مشترکان، تصویر یکسانی ارائه می‌دهد (در دامنه‌ی یک موضوع). طراحی تهاجمی‌تر، تصویر کردن اختصاصی برای هر ایجنت است: هر ایجنت نمایی متناسب با نقش خودش دریافت می‌کند. تابع‌های کاهنده‌ی (Reducer) وضعیت در LangGraph پیاده‌سازی مرجع این الگو در سال 2026 هستند؛ تابع کاهنده، وضعیت سراسری را در برشی متناسب با نقش ایجنت خلاصه می‌کند.

تصویر کردن اختصاصی برای هر ایجنت مقیاس‌پذیری بالاتری دارد اما نیازمند اسکیما است. بدون اسکیما، ناچارید این تصویر کردن داده را به‌شکل دم‌دستی در پرامپت تک‌تک ایجنت‌ها بازسازی کنید.

الگوهای مدیریت تداخل در نوشتن

نوشتن هم‌زمان چند ایجنت صرفاً مسئله‌ی LLM نیست، بلکه یک چالش هم‌روندی (Concurrency) است. سه الگو در اینجا کارایی دارند:

• نویسنده‌ی متوالی (تک‌تولیدکننده). تمام درخواست‌های نوشتن از طریق یک ایجنت هماهنگ‌کننده عبور می‌کنند و ترتیبی می‌شوند. ساده است، ولی می‌تواند گلوگاه شود.
• هم‌روندی خوش‌بینانه با نسخه‌بندی. هر رکورد نسخه‌ای دارد؛ نویسنده‌ها در صورت عدم تطابق نسخه با شکست مواجه می‌شوند و دوباره تلاش می‌کنند. همان تکنیک کلاسیک پایگاه‌های داده.
• افرازبندی موضوعی. ایجنت‌های مختلف مالک موضوعات متفاوتی هستند. به این ترتیب تداخلی بین موضوعات پیش نمی‌آید. این روش نیازمند مرزبندی‌های حساب‌شده است.

بیشتر فریم‌ورک‌های سال 2026 به‌صورت پیش‌فرض از الگوی نویسنده‌ی متوالی استفاده می‌کنند؛ زیرا فراخوانی‌های LLM آن‌قدر کند هستند که تداخل به‌ندرت رخ می‌دهد و گلوگاه شدن آن مشکلی ایجاد نمی‌کند.

مدل اعتبارسنج غیرقابل‌نوشتن

مهم‌ترین راهکار مهار این مشکل، بهره‌گیری از مدل اعتبارسنج فقط-خواندنی است. اصول پیاده‌سازی آن عبارت‌اند از:

• مدل اعتبارسنج وضعیت مشترکی با تیم دارد (تخته‌سیاه یا استخر را می‌خواند).
• مدل اعتبارسنج هیچ دسترسی نوشتنی به وضعیت مشترک ندارد و فقط به یک کانال اعتبارسنجی جداگانه متصل است.
• مدل اعتبارسنج به‌طور مستقل منابع استنادشده در پیام‌ها را دوباره واکشی می‌کند و عدم تطابق‌ها را پرچم می‌زند.
• خروجی‌های اعتبارسنج به یک انسان یا یک ایجنت تصمیم‌گیرنده‌ی مجزا هدایت می‌شوند و هرگز به استخر اصلی برنمی‌گردند.

بدون این جداسازی، خروجی‌های اعتبارسنج خود به پیام‌هایی جدید در استخر بدل می‌شوند؛ این یعنی استخر مسموم، اعتبارسنج را مسموم می‌کند و اعتبارسنج نیز ارزیابی‌هایش را با خطا آلوده خواهد کرد.

پیاده‌سازی

فایل code/main.py هر دو توپولوژی را صرفاً با کتابخانه‌ی استاندارد پایتون پیاده‌سازی می‌کند و یک حمله‌ی مسموم‌سازی ساده به‌همراه سه راهکار کاهش ریسک را نشان می‌دهد.

• MessagePool — لاگ الحاقی و ایمن در برابر چندریسمانی (Thread-safe) همراه با خواندن تمام داده‌ها.
• Blackboard — سیستم انتشار/اشتراک موضوع‌محور با امکان اشتراک مجزا به ازای هر ایجنت.
• ProvenanceEntry — به ازای هر نوشتن، مشخصات (writer، timestamp، prompt_hash، source_uri) را ذخیره می‌کند.
• PoisoningScenario — یک سناریوی پژوهشی سه ایجنتی را اجرا می‌کند که در آن ایجنت A در تشخیص ممیز دچار توهم می‌شود و در نهایت گزارش پایانی را چاپ می‌کند.
• Verifier — ایجنت فقط-خواندنی که منابع را دوباره واکشی می‌کند و مغایرت‌ها را پرچم می‌زند. همین سناریو را در حضور مدل اعتبارسنج اجرا می‌کند.

اجرا:

python3 code/main.py

خروجی مورد انتظار:

• اجرای 1 (بدون اعتبارسنج): عدد ساختگی 42 درصد تا گزارش نهایی نفوذ می‌کند.
• اجرای 2 (با اعتبارسنج): اعتبارسنج تناقض را پرچم می‌زند، استخر برچسب «flagged» می‌خورد و گزارش نهایی شامل یک اصلاحیه خواهد بود.

کاربرد در عمل

فایل outputs/skill-memory-auditor.md یک مهارت است که طراحی حافظه‌ی مشترک را در هر سیستم چندایجنتی از نظر ثبت منشأ و سندیت، نسخه‌بندی و جداسازی اعتبارسنج ممیزی می‌کند. پیش از بردن معماری‌های چندایجنتی به محیط عملیاتی، این بررسی را روی آن‌ها اجرا کنید.

تحویل به پروداکشن

برای هر معماری حافظه‌ی مشترک:

• منشأ و سندیت را در هر بار نوشتن ثبت کنید: (writer, timestamp, prompt_hash, tool_calls_cited, source_uri).
• لاگ را فقط الحاقی بسازید. اصلاحیه‌ها ورودی‌های جدیدی هستند که به ورودی منسوخ‌شده ارجاع می‌دهند.
• حداقل یک ایجنت اعتبارسنج فقط-خواندنی با دسترسی مستقل به منابع مستقر کنید.
• خروجی اعتبارسنج را به کانالی مجزا بفرستید، نه دوباره به استخر مشترک.
• نسبت عملیات‌های نوشتنی که جایگزین موارد قبلی شده‌اند را لاگ کنید؛ بالا رفتن این نسبت نشانه‌ی زودهنگام شکل‌گیری الگوهای توهم است.

تمرین‌ها

1. اسکریپت code/main.py را اجرا کنید. مطمئن شوید در اجرای اول توهم گسترش می‌یابد و در اجرای دوم مهار می‌شود.
2. یک توهم دوم اضافه کنید: ایجنت B حجم یک مجموعه‌داده را از خودش بسازد. اعتبارسنج باید بتواند بدون این‌که به‌طور دستی برای هر کدام تنظیم شده باشد، هر دو خطا را بگیرد.
3. استخر پیام کامل را به یک تخته‌سیاه با پارتیشن‌های موضوعی (prices، summaries، analyses) تبدیل کنید. افرازبندی موضوعی مانع کدام سناریوهای مسموم‌سازی می‌شود و جلوی کدام سناریوها کمکی نمی‌کند؟
4. مقاله‌ی هیز-راث (1985، "A Blackboard Architecture for Control") را بخوانید. دو الگوی کنترلی از مقاله را که در این درس بررسی نشدند و سیستم‌های سال 2026 می‌توانند از آن‌ها بهره ببرند شناسایی کنید.
5. مقاله‌ی CA-MCP (arXiv:2601.11595) را بخوانید. مخزن کانتکست مشترک (Shared Context Store) آن را به کلاس‌های MessagePool یا Blackboard در code/main.py نگاشت کنید. CA-MCP چه ساختارهای پایه‌ای دیگری به آن می‌افزاید؟

اصطلاحات کلیدی

مطالعه‌ی بیشتر

• Cemri et al. — Why Do Multi-Agent LLM Systems Fail? — تاکسونومی MAST؛ مسموم‌سازی حافظه یکی از زیرمجموعه‌های خطای هماهنگی است
• CA-MCP — Context-Aware Multi-Server MCP — مخزن کانتکست مشترک برای سرورهای MCP هماهنگ
• Matrix — decentralized multi-agent framework — تخته‌سیاه مبتنی بر صف پیام بدون هماهنگ‌کننده‌ی مرکزی
• LangGraph state and reducers — الگوی تصویر کردن اختصاصی برای هر ایجنت در محیط عملیاتی
• Anthropic — How we built our multi-agent research system — نکات منشأ و سندیت و اعتبارسنجی در یک پیاده‌سازی عملیاتی واقعی