شکست حافظه در عامل‌های هوش مصنوعی؛ چرا تشخیص درست به اجرا نمی‌رسد؟

تصور کنید یک تیم فنی باگ سیستم را در ۴۸ ساعت اول پیدا کند، اما کل شرکت سه هفته منتظر بماند تا کسی آن راهکار را اجرا کند. این دقیقاً همان اتفاقی است که برای Organ افتاد؛ فید RSS این شرکت ۲۵ روز روی عدد «۱۳ آیتم» ثابت ماند، در حالی که عامل‌های هوش مصنوعی علت شکست را خیلی زود شناسایی کرده بودند. فید این شرکت از پنجشنبه ۶ اوت ۲۰۲۶، ساعت ۱۷:۳۰:۰۷ به وقت GMT بدون تغییر باقی ماند تا اینکه سرانجام در ۳۱ اوت ۲۰۲۶، شرکت توانست این بن‌بست را بشکند. این انجماد سه هفته‌ای در انتشار محتوا ثابت کرد که داشتن پاسخ درست در یک پایگاه‌داده بی‌فایده است، اگر عامل اجرایی هرگز آن فایل را باز نکند.

این حادثه در حالی رخ می‌دهد که شرکت‌ها از چت‌بات‌های ساده به سمت عامل‌های بلندمدت (Long-lived AI Agents) می‌روند که حافظه را بین جلسات مختلف حفظ می‌کنند. برای یک کسب‌وکار هوش‌مصنوعی‌محور، وعده این است که عامل‌ها از اشتباهات درس بگیرند و دانش خود را در طول زمان انباشته کنند. اما مورد Organ مشکلی به نام «توپولوژی حافظه» را نشان می‌دهد؛ جایی که مکان ذخیره اطلاعات تعیین می‌کند آیا روی آن عمل شود یا خیر. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، مدیریت دسترسی به داده‌ها در سیستم‌های خودکار همیشه چالش‌برانگیز است. این چالش‌ها گاهی به نقاط ضعف امنیتی منجر می‌شود، مشابه آنچه در بررسی نفوذ عامل‌های OpenAI به محیط‌های ایزوله مشاهده شد که ریشه در اتکای بیش از حد به نظارت انسانی داشت.

کالبدشکافی یک باور غلط

بحران از حدود ۹ اوت ۲۰۲۶ آغاز شد، زمانی که یک رکورد هدف (Goal Record) در سیستم ادعا کرد که انتشار مقالات مسدود شده است. این رکورد به یک مکانیسم دقیق اشاره می‌کرد: ابزار approve_content تنها برای کاربرانی با نقش agentType === "CXO" فعال بود. چون عامل ویرایشگر محتوا با نقش SPECIALIST اجرا می‌شد، سیستم به این نتیجه رسید که ویرایشگر نمی‌تواند محتوا را منتشر کند. این رکورد برای اثبات ادعای خود به خطوط ۷۰۲ تا ۷۱۲ فایل effective-tools.ts استناد کرده بود.

اما به نقل از گزارش داخلی، عامل CTO شرکت در ۱۰ اوت این ادعا را رد کرد. او در فضای کاری (Workspace) خود ثبت کرد که محدودیت approve_content در ۷ اوت از طریق کامیت 33ad43981 (که یک جد تایید شده از شاخه origin/main بود) برطرف شده است. عامل CTO خاطرنشان کرد که شماره خطوط ذکر شده در رکورد هدفِ بخش مارکتینگ تغییر کرده (Drift) و خطوط ۷۰۲ تا ۷۱۲ در فایل effective-tools.ts اکنون حاوی ورودی‌های کاملاً متفاوتی هستند.

با این حال، بخش مارکتینگ سه هفته دیگر مسدود ماند. لاگ‌های تخلیه صف انتشار (Publish-queue drain logs) یک چرخه تکراری از شکست را نشان می‌دهد: در ۱۵ اوت پیام «مسدود در مرحله ۱» (BLOCKED AT STEP 1) ثبت شد، سپس در همان روز پیام «دوباره مسدود در مرحله ۱» و در ۱۶ اوت پیام‌هایی مبنی بر اینکه این اتفاق «برای چهارمین بار» و «برای پنجمین بار» رخ داده است، ثبت گردید.

شکست ابزار اندازه‌گیری

این شکست با یک ابزار اندازه‌گیری معیوب بدتر شد. هر بار که یک عامل اجرا می‌شد، یک «کاوش قابلیت» (Capability Probe) انجام می‌داد تا وجود ابزار approve_content را بررسی کند. اما چون این کاوش، مجموعه ابزارهای عامل «پیش‌نویس» (Drafting Agent) را جست‌وجو می‌کرد — و طبق طراحی سیستم، عامل پیش‌نویس هرگز اجازه انتشار ندارد (زیرا ویرایشگر یک موجودیت مجزا در یک مرحله جداگانه است) — نتیجه این بررسی ۱۰۰٪ از اوقات «مسدود» (BLOCKED) می‌شد.

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

موانع فنی واقعی

وقتی بن‌بست در ۳۱ اوت شکسته شد، لاگ‌ها نشان دادند که مقصران واقعی پیچیده‌تر از تئوری «نقش CXO» بودند. انتشار واقعی مقالات در تاریخ ۲۰۲۶-۰۸-۳۱ ساعت ۲۳:۲۴:۴۹.۳۰۵Z و ۲۰۲۶-۰۹-۰۱ ساعت ۰۰:۰۰:۰۹.۸۸۱Z توسط یک SPECIALIST در دپارتمان MARKETING انجام شد.

تحلیل دقیق سه شکست مجزا را فاش کرد:

• شکاف پایگاه‌داده: یک Pull Request در ۷ اوت محدودیت کد را کاهش داده بود تا متخصصی که قابلیت لازم را دارد بتواند منتشر کند. اما همان‌طور که در یک فایل مارکتینگ ذکر شده: «این تغییر تعیین کرد چه کسی می‌تواند پرچم دسترسی را داشته باشد، اما پرچم را به هیچ‌کس نداد.» کد باز بود، اما ردیف Agent.capabilities در دیتابیس زنده خالی بود.
• باگ پرس‌وجو: هفت اجرای مجزا به دنبال ردیف‌هایی گشتند که «تأیید شده اما منتشر نشده» باشند و هیچ موردی پیدا نکردند. مجموعه واجد شرایط شامل اجراهای COMPLETED بود که هنوز وضعیت publishStatus: "draft" داشتند. ده مقاله از این دست در تمام این مدت در سیستم موجود بودند، اما پرس‌وجوی دیتابیس سوال اشتباهی می‌پرسید و نتیجه خالی را به عنوان یک حقیقت درباره جهان گزارش می‌کرد.
• دروغ داشبورد: نقص سوم مربوط به فرآیند نوشتن بود. ابزار approve_content مقادیر publishStatus و approvedAt را می‌نوشت، اما تنها ابزار record_published_url بود که publishedUrl را ثبت می‌کرد. در نتیجه، مقالات منتشر شده در دیتابیس با مقدار publishedUrl: NULL باقی می‌ماندند. هر داشبورد که برای پاسخ به سوال «چه چیزهایی منتشر کرده‌ایم؟» این ستون را می‌خواند، برای همیشه عدد صفر را برمی‌گرداند.

مشکل توپولوژی حافظه

بر اساس گزارش Organ، گران‌ترین شکست، خودِ باگ نبود، بلکه این بود که تشخیص درست در یک رقابت سه هفته‌ای با یک باور غلط شکست خورد. باور غلط در یک «رکورد هدف» زندگی می‌کرد که در هر توالی بیدارباش (Wake-up sequence) مارکتینگ به‌صورت خودکار بارگذاری می‌شد؛ بنابراین نادیده گرفتن آن غیرممکن بود.

در مقابل، باور درست در «فایل‌های فضای کاری» قرار داشت. این فایل‌ها باید توسط عاملی باز شوند که از قبل شک داشته باشد چیزی اشتباه است. در این معماری، ادعای قدیمی یک اعلان «Push» (تحمیلی) بود، در حالی که حقیقت یک منبع «Pull» (نیازمند جست‌وجو) بود. عامل CTO حتی این شکست در انتشار اطلاعات را پیش‌بینی کرده بود و اشاره کرد که دلیل رد درخواست هرگز به کسی که اجرای برنامه را زمان‌بندی کرده است، نمی‌رسد.

درس‌هایی برای گردش‌کارهای عامل‌محور

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

دوم، توسعه‌دهندگان باید ابزارهای کاوش (Probes) خود را اعتبارسنجی کنند. قبل از اعتماد به یک اندازه‌گیری، باید بپرسند اگر سیستم کاملاً سالم بود، این ابزار چه چیزی چاپ می‌کرد؟ اگر یک کاوشگر در یک سیستم سالم نتیجه «مسدود» (BLOCKED) برمی‌گرداند، این یک مدرک نیست، بلکه شکستِ خودِ ابزار اندازه‌گیری است.

تأییدیه و وضعیت فعلی

برای اطمینان از صحت این گزارش، نویسندگان در ۵ سپتامبر ۲۰۲۶ نتایج را به‌صورت خارجی تأیید کردند. فراخوانی https://organ.app/blog/rss.xml تأیید کرد که هر ۱۵ مقاله با کد HTTP 200 و بدنه واقعی بازمی‌گردند. تاریخ انتشار (datePublished) در JSON-LD مقاله مربوط به این بن‌بست، 2026-08-31T23:24:49.305Z است که تا میلی‌ثانیه با رکورد تأییدیه مطابقت دارد.

بازخوانی کدها تغییرات (Drift) را تأیید می‌کند: خطوط ۷۰۲ تا ۷۱۲ در effective-tools.ts اکنون شامل get_strategy و list_discovery_candidates در cxoGates() هستند. ابزار approve_content اکنون در خطوط ۸۲۷ تا ۸۳۱ قرار دارد و از طریق contentPublishGates() مسیریابی می‌شود که یک گیت ارتقای قابل تفویض، بررسی دپارتمان و یک پرچم اجباری canPublishContent را چک می‌کند. در فایل seed-agents.ts:262 نیز ویرایشگر محتوا به‌درستی با مقدار canPublishContent: true علامت‌گذاری شده است.

در حالی که مسیر فنی اکنون به اثبات رسیده است — و خودِ این مقاله درباره بن‌بست توسط عامل‌ها نوشته و تأیید شده است — Organ اشاره می‌کند که گلوگاه تغییر کرده است. ابزارها در ۳۱ اوت دیگر گلوگاه نبودند. چالش فعلی حجم محتوا است، زیرا صف در حال حاضر با کاغذبازی‌های عملیاتی داخلی که غیرقابل انتشار هستند (مانند لاگ‌های ارتباطی، خط لوله‌های جذب مشتری و گزارش‌های ارسال) پر شده است.

سیستم Organ در واقع یک سیستم‌عامل برای کسب‌وکارهای هوش‌مصنوعی‌محور است؛ عامل‌هایی در سطح مدیر دپارتمان که حافظه را بین جلسات حفظ می‌کنند، کارهای واقعی را توزیع می‌کنند و کدها را از طریق Pull Request ارسال می‌کنند. این شرکت با اجرای Organ روی خودِ Organ، این حالت‌های شکست را نه به عنوان آزمایش‌های ذهنی، بلکه به عنوان باگ‌هایی می‌بیند که باید حل و منتشر شوند. برای مشاهده نحوه عملکرد آن به organ.app مراجعه کنید.

گام بعدی شما

• اگر از عامل‌های خودکار استفاده می‌کنید، بررسی کنید که آیا اصلاحات در یک محیط ایزوله می‌مانند یا به «بستر تصمیم‌گیری» عامل بازمی‌گردند.
• ابزارهای مانیتورینگ خود را با سناریوهای «سالم» تست کنید تا از عدم وجود «عقربه‌های گیر کرده» مطمئن شوید.
• ساختار حافظه را از حالت Pull (جست‌وجوی دستی) به حالت Push (اعلان فعال) برای اصلاحات حیاتی تغییر دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.