چرا عامل‌های هوش مصنوعی شکست می‌خورند و معماری سه‌لایه چه کمکی می‌کند؟

اگر امروز یک عامل هوش مصنوعی برای کسب‌وکار خود طراحی کرده‌اید، احتمالاً با این واقعیت تلخ روبه‌رو هستید که استراتژی فعلی شما شکست می‌خورد؛ زیرا مدل شما با هر جلسه (Session) جدید، مانند ذهنی کاملاً پاک شروع می‌کند که هیچ حافظه بلندمدتی ندارد. این عامل هیچ خاطره‌ای از اتفاقات دیروز ندارد، اصلاحاتی که هفته پیش به آن گوشزد کردید را فراموش کرده و هیچ ایده‌ای ندارد که شرکت شما پیش از این چه تصمیماتی گرفته است. این چالش حافظه، ریشه در ساختار مدل‌های زبانی دارد که در تحلیل‌های پیشین ما درباره‌ی ابزارهایی مانند Ditto برای استخراج ترجیحات از لاگ‌ها مورد بررسی قرار گرفت.

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

در نتیجه، توسعه‌دهندگان بین دو نوع شکست گیر می‌کنند: یا باید بلوک‌های عظیم و سنگینی از دستورالعمل‌ها را در هر پرامپت بچسبانند (Paste) که این کار یک «مالیات» دائمی بر روی تأخیر (Latency) و هزینه ایجاد می‌کند، یا اجازه دهند عامل در اثر تضاد قوانین بین تیم‌ها، دچار بی‌ثباتی و انحراف شود. اگر شما یک پرامپت خوب بنویسید و آن را در هر پروژه کپی کنید، این روش از دو جهت شکست می‌خورد: اول، در همان هفته اول از هم می‌پاشد زیرا داشتن شش نسخه از یک قانون، در عمل به معنای داشتن شش قانون متفاوت است (به دلیل عدم همزمانی)، و دوم، هر خطی که کپی شده است، در هر جلسه به‌طور ابدی هزینه مالی خواهد داشت. برای مدیریت بهینه‌تر این هزینه‌ها و کاهش مصرف توکن‌ها، استفاده از مسیریاب‌های قطعی (Deterministic Router) جایگزینی کارآمد برای پرامپت‌های حجیم است.

به نقل از گزارشی در وب‌سایت dev.to مورخ ۲۶ ژوئیه ۲۰۲۶، یک الگوی معماری جدید پیشنهاد شده است که در آن عامل‌ها باید هوش سازمانی را دقیقاً مشابه انسان‌ها — یعنی از طریق نمودار سازمانی (Org Chart) و دسترسی‌های محدود شده — به ارث ببرند. این رویکرد، مسئله را از «مهندسی پرامپت» به «معماری سیستم» تغییر می‌دهد.

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

مدل میراث سه‌لایه

• لایه ۱: قانون اساسی (The Constitution): این یک سند ریشه‌ای است که سقف آن تقریباً ۴۰ خط است. این لایه مرزهای غیرقابل‌مذاکره، هویت و ایمنی را تعریف می‌کند؛ مواردی مانند اینکه چه چیزی به عنوان «سند و مدرک» پذیرفته می‌شود، تعریف دقیق کلمه «انجام شده» (Done) چیست و مرزهای ایمنی قانونی (به جای مرزهای استایلی و ظاهری) کدامند. هر جلسه به‌طور خودکار این لایه را بارگذاری می‌کند. چون این سند توسط هر جلسه از هر پروژه برای همیشه خوانده می‌شود، کوتاهی شدید آن یک الزام طراحی است. قانونی که رشد کند، مانند صورت‌حسابی است که هر بار کسی کار را شروع می‌کند، ارسال می‌شود. اگر قانونی نباشد که هر پروژه پیش از دانستن ماهیت کارش به آن نیاز داشته باشد، جایگاهش در لایه اول نیست.
• لایه ۲: قانون اساسی پروژه (Project Constitution): این لایه حاوی حقایقی است که فقط مختص به یک پروژه واحد است و هیچ چیز اضافه‌ای ندارد. این لایه قوانین لایه ۱ را به‌طور رایگان به ارث می‌برد، به این معنی که هرگز قوانین جهانی را دوباره تکرار نمی‌کند تا پنجره متنی (Context Window) سبک بماند.
• لایه ۳: پایگاه دانش (Knowledge Base): این لایه شامل چندین صد سند است که هرگز در هنگام شروع (Startup) بارگذاری نمی‌شوند. این اسناد تقریباً رایگان هستند، مگر زمانی که به‌طور خاص به آن‌ها نیاز باشد.

پیوند حافظه به اقدام

طبق گزارش dev.to، اکثر توسعه‌دهنده‌ها این سیستم را وارونه می‌سازند؛ آن‌ها زمینه‌های (Contexts) عظیم را در لایه‌های بالا قرار می‌دهند و سپس تعجب می‌کنند که چرا هر جلسه کند و گران است. راز موفقیت لایه ۳ در استفاده از یک موتور جستجو یا تپه‌ای از اسناد که هیچ‌کس نمی‌خواند (که در واقع حافظه نیستند) نیست، بلکه وجود یک «جدول محرک» (Trigger Table) در لایه ۲ است.

سازوکارهای لایه سوم

• نگاشت اقدامات (Mapping Actions): سیستم از یک جدول کوتاه استفاده می‌کند که یک اقدام خاص را به مطالعه‌ی متنی مورد نیاز مرتبط می‌کند.
• ارسال به‌موقع (Just-in-Time Delivery): عامل به‌دنبال دانش نمی‌گردد. در عوض، دانش دقیقاً در لحظه‌ی انجام اقدام تحویل داده می‌شود.
• مثال‌ها: به عامل صراحتاً گفته می‌شود: «قبل از اینکه کدهای مربوط به صورت‌حساب (Billing) را لمس کنی، این سند را بخوان» یا «قبل از اینکه هر چیزی که مشتری می‌بیند را تغییر دهی، آن مورد را مطالعه کن».

این تمایز دقیقاً همان تفاوت بین نیمی از سیستم است که کار کرد و نیمی که شکست خورد و نابود شد.

ادغام حلقه‌های بازخورد انسانی

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

۱. تصاعد (Escalation): این زمانی است که عامل می‌گوید: «من به تصمیمی نیاز دارم که اختیار اتخاذ آن با من نیست». این مورد در تغییرات محیط عملیاتی (Production)، تعهدات هزینه‌ای یا هر اقدامی که غیرقابل بازگشت باشد، کاربرد دارد.
۲. کالیبراسیون (Calibration): این زمانی است که یک انسان می‌گوید: «آن مورد اشتباه بود و شکلِ این اشتباه به این صورت است».

کالیبراسیون ارزشمندترین حلقه بازخورد است و متأسفانه در اکثر پیاده‌سازی‌ها کاملاً نادیده گرفته می‌شود. اصلاحی که فقط در یک پنجره چت می‌ماند، اصلاحی است که شما سه هفته دیگر دوباره برای آن هزینه خواهید کرد (چون عامل دوباره همان اشتباه را می‌کند). با استفاده از گفتگوهای رشته‌ای (Threaded Conversations)، این اصلاحات یک خانه دائمی در کنار همان موردی که اصلاح شده پیدا می‌کنند و مواد خام لازم را برای بازگرداندن آن اصلاح به لایه‌ی ۲ فراهم می‌کنند.

لایه‌ی امنیت و حریم خصوصی

با تعریف عامل به‌عنوان یک «اصیل» (Principal) در دایرکتوری فعلی شرکت، مشکل هویت و دسترسی‌ها به‌طور کامل حل می‌شود. عامل عضو گروه‌ها می‌شود، حقوق آن گروه‌ها را به ارث می‌برد و دسترسی‌هایش دقیقاً به همان روشی لغو می‌شود که دسترسی یک کارمند departing (خارج شده از سازمان) لغو می‌گردد. این کار از وقوع حوادث امنیتی جلوگیری می‌کند که در اثر ایجاد یک مدل دسترسی دوم (که با گذشت زمان از مدل واقعی فاصله می‌گیرد) رخ می‌دهد.

این معماری به سؤال حیاتی تیم‌های ریسک پاسخ می‌دهد: «عامل به چه چیزهایی دسترسی دارد و چه کسی این تصمیم را گرفته است؟» وقتی پاسخ این باشد که «همان گروه‌هایی که بر انسان‌های انجام‌دهنده این کار نظارت دارند»، ماهیت گفتگو تغییر می‌کند.

طراحی حریم خصوصی و کیفیت داده

برای اینکه لایه‌های بالاتر مرتبط باقی بمانند، اطلاعات باید رو به بالا جریان یابد، اما این کار ریسک ایجاد یک سیستم نظارتی (Surveillance System) را به along دارد. نظارت، کیفیت داده‌های جمع‌آوری‌شده را تخریب می‌کند؛ زیرا مردم لایه‌های شخصی خود را به‌صورت «نمایشی» (Performative) پر می‌کنند تا خوب به نظر برسند. ورودی‌های نمایشی باعث ایجاد الگوهای غلط می‌شوند و این الگوها منجر به تصمیمات غلط اما با اطمینان بالا در سطح مدیریت ارشد می‌شوند.

برای جلوگیری از این اتفاق، سیستم از یک تضمین حریم خصوصی ساختاری استفاده می‌کند:

• الگوهای ناشناس: هویت‌ها در لایه تیم حذف می‌شوند و فقط الگوها رو به بالا حرکت می‌کنند. برای مثال، گزارش اینکه «۴ نفر این استاندارد را در این ماه نامفهوم دانستند» مجاز است، اما گزارش اینکه «سارا ۴ بار این مورد را نامفهوم دانست» ممنوع است.
• عدم امکان جستجوی معکوس: این یک ویژگی ساختاری در سطوح دسترسی و تجمیع داده‌هاست، نه یک «وعده سیاستی» یا قانون اداری.
• آستانه‌ها (Thresholds): یک اتفاق واحد، یک «الگو» نیست. هیچ موردی تا زمانی که چندین سیگنال از یک نوع ظاهر نشود، تصاعد نمی‌یابد؛ این کار مانع از آن می‌شود که یک «بعدازظهر بد» به عنوان یک روند سازمانی گزارش شود.

قانون محرک‌ها: چرا نیت‌ها شکست می‌خورند؟

بحرانی‌ترین یافته آزمایش‌های سال ۲۰۲۶، شکست «اعمال یادآوری‌شده» (Remembered Acts) بود. نویسنده سعی کرد یک گزارش مشترک پیاده‌سازی کند که در آن هر جلسه پروژه با نوشتن یک خط درباره تغییرات به پایان برسد تا یک خلاصه بین-پروژه‌ای ایجاد شود.

بیست و دو روز بعد، داده‌ها شکست کامل را نشان دادند:

• تنها ۱۰ ورودی ایجاد شده بود.
• ۸ مورد از آن‌ها در سه روز اول رخ داده بود و تنها یک مورد، یازده روز پیش ثبت شده بود.
• تمام ۱۰ مورد متعلق به تنها یک پروژه از بین پنج پروژه بود.
• پروژه‌ای که مشتری واقعی داشت، حتی یک خط هم ننوشته بود.

آن خلاصه مشترک نه تنها قدیمی بود، بلکه غلط بود؛ به گونه‌ای که با اطمینان کامل پروژه‌ای را به عنوان یک «پوشه پوچ» (Shell Folder) توصیف می‌کرد که هشت روز پیش بازنشسته شده بود. علاوه بر این، «آشفتگی طرح‌واره» (Schema Drift) رخ داد: برچسب‌های زمانی (Timestamps) در ردیف اول به صورت عدد صحیح (Integer) بودند و در ردیف آخر به صورت رشته‌های فرمت‌شده (Formatted Strings)، که باعث کرش کردن اسکریپت تحلیل داده شد. این نوع شکست در گزارش‌دهی را در تحلیل ما درباره‌ی دلایل متوقف شدن عامل‌های کدنویس در مقیاس واقعی با جزئیات بیشتری بررسی کرده‌ایم.

قانون حافظه

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

قانون: هر چیزی که وابسته به «به یاد آوردن» باشد، اتفاق نخواهد افتاد. آن را به یک «عمل» گره بزنید، وگرنه وجود ندارد. هر جلسه در مدل‌های زبانی، ذهنی تازه است که هیچ حافظه‌ای از اینکه «توافق کرده است عادتی را تکرار کند» ندارد. شما نمی‌توانید حافظه سازمانی را از دل نیت‌های خوب که بین افرادی با گسست حافظه (Amnesiacs) توزیع شده است، بسازید.

علاوه بر این، سیستم‌های کششی (Pull-based) به شکلی فریبنده شکست می‌خورند. فایل وجود دارد و نمودار زیبا به نظر می‌رسد، اما تا زمانی که ردیف‌ها را نشمارید، نمی‌فهمید که خالی است. دو نتیجه کاربردی از این تجربه حاصل شد:
۱. بخش خواندن نیاز به فشار (Push) دارد: خلاصه‌ای که به دست کسی داده نشود، خوانده نمی‌شود. باید در شروع جلسه به‌صورت خودکار و بدون درخواست (Unprompted) نمایش داده شود.
۲. بررسی تازگی (Freshness Checks): داشبوردی که به‌طور خاموش یازده روز است قدیمی شده، بدتر از نبودِ داشبورد است. باید تاریخ تولید داشته باشد و هرگاه قدیمی شد، اعتراض کند.

چک‌لیست پیاده‌سازی

برای کسانی که امروز در حال ساخت این سیستم هستند، نویسنده این توالی دقیق را توصیه می‌کند:

۱. لایه ۱ را بنویسید و آن را به ۴۰ خط محدود کنید. اگر طولانی‌تر است، در واقع یک قانون لایه ۲ است که در لباس لایه ۱ ظاهر شده.
۲. قبل از ایجاد اسناد، جدول محرک‌ها را بسازید. مکانیسم تحویل (Delivery Mechanism) محصول اصلی است؛ اسناد فقط موجود انبار هستند.
۳. مرز حریم خصوصی را قبل از اولین سیگنال تعیین کنید. شما نمی‌توانید ناشناس بودن را بعداً به سیستمی که مردم از पहले به آن بی‌اعتماد شده‌اند، اضافه کنید.
۴. عامل را در دایرکتوری (Directory) شرکت قرار دهید. از گروه‌های موجود استفاده کنید، نه تنظیمات سفارشی (Bespoke)، تا لغو دسترسی‌ها (Deprovisioning) از روز اول درست کار کند.
۵. اتصال تصاعد (Escalation) را فوراً به ابزار چت خود متصل کنید. اجازه ندهید اولین باری که یک عامل به انسان نیاز دارد، اولین تست برای بررسی سالم بودن کانال ارتباطی باشد.
۶. کالیبراسیون را برای ثبت ارزان (سریع) کنید. اگر اصلاح عامل بیش از یک پاسخ (Reply) زمان ببرد، هرگز انجام نخواهد شد.
۷. جریان رو به بالا را تنها پس از انجام مراحل بالا فعال کنید. آن را به چیزی گره بزنید که در پایان زمان کاری به‌طور طبیعی اتفاق می‌افتد.

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

در نهایت، معماری بخش آسان کار است. بخش سخت این است که مطمئن شوید سیستم سه هفته بعد هنوز در حال اجراست، که این موضوع کاملاً به این بستگی دارد که چه چیزی باعث تحریک عملیات نوشتن (Write) می‌شود.

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