گلوگاه جدید عامل‌های هوش مصنوعی؛ چرا همگرایی مدل‌ها اعتماد را از بین برد؟

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

تا اواسط سال ۲۰۲۶، شکاف بین مدل‌های پیشرو به‌شدت کم شد. اکنون دوران انتخاب مدل به‌عنوان تصمیم اصلی معماری به پایان رسیده است. برای سال‌ها، صنعت با مدل‌های زبانی بزرگ (LLM) به عنوان خودِ محصول برخورد می‌کرد. دو سال پیش، انتخاب یک مدل احساس می‌شد که مهم‌ترین تصمیم در کل پشته‌ی تکنولوژی (Stack) است. تیم‌ها ارائه‌دهنده‌ای را انتخاب می‌کردند، درست همان‌طور که زمانی یک پایگاه‌داده را انتخاب می‌کردند و کل زیرساخت خود را بر اساس ویژگی‌های خاص و نقاط ضعف یک مدل واحد طراحی می‌کردند. این رویکرد زمانی جواب می‌داد که فاصله بین مدل پیشرو و دنبال‌کنندگان، یک جهش نسلی بود؛ فاصله‌ای چنان زیاد که شما مجبور بودید کل طراحی خود را بر اساس آن شکاف تنظیم کنید.

اما امروز وضعیت متفاوت است. طبق داده‌های LMArena و Artificial Analysis، خوشه‌ی مدل‌های برتر اکنون در فاصله‌ای بسیار اندک از یکدیگر قرار دارند و این تراکم مدام بیشتر می‌شود. هر آزمایشگاه بزرگی اکنون قابلیت‌های مدل استدلالی (Reasoning Model) و استفاده از ابزار (Tool Use) را به‌عنوان ویژگی‌های استاندارد ارائه می‌دهد.

علاوه بر این، قیمت APIها در سال‌های ۲۰۲۴ و ۲۰۲۵ تقریباً یک مرتبه بزرگی (Order of Magnitude) کاهش یافت و پس از آن نیز روند نزولی خود را ادامه داد. مدل‌های وزن‌های باز (Open Weights) اکنون به‌جای نسل‌ها، تنها با فاصله چند ماه از مدل‌های پیشرو عقب هستند. این روند سریع همگرایی را می‌توان در حوزه‌های تخصصی‌تر نیز مشاهده کرد، جایی که مدل‌های وزن‌باز در بازه زمانی کوتاهی توانستند به سطح توانمندی‌های سایبری مدل‌های پیشرو برسند. وقتی مدل‌ها جایگزین‌پذیر شوند، دیگر «وزن‌ها» محصول نیستند، بلکه «ارکستراسیون» (Orchestration) محصول اصلی است. اگر تسکی در یک مدل پیشرو شکست بخورد، احتمالاً در بقیه مدل‌ها هم به همان شکل شکست می‌خورد؛ زیرا مشکل هرگز در وزن‌های مدل نبوده است، بلکه در هر چیزی است که در اطراف مدل ساخته شده است. اگرچه هنوز برتری‌های واقعی در زمینه‌هایی مانند پنجره‌های بافتار طولانی (Long Context)، زبان‌های کمتر رایج و قابلیت اطمینان در فراخوانی ابزارها وجود دارد، اما مرکز توزیع مدل‌ها به یک نقطه همگرا شده است.

گلوگاه تأیید (The Verification Bottleneck)

متخصصانی که در حال ساخت حلقه‌های عاملی (Agent Loops) هستند، متوجه شده‌اند که تولید متن اکنون ارزان و تقریباً نامحدود شده است. اما گلوگاه واقعی «تأییدکننده» (Verifier) است؛ یعنی مکانیزمی که قضاوت کند آیا خروجی ارسال شود، مرحله‌ای تکرار شود یا عملیات به‌طور کامل متوقف گردد. در هر حلقه عاملی، ارزش تولیدی تنها به سرعتِ چیزی وابسته است که بتواند خروجی را قضاوت و تأیید کند.

این چرخش در دیدگاه رهبران صنعت مشهود است. اندرو ان‌جی (Andrew Ng) در یادداشت‌های خود درباره الگوهای طراحی عامل‌محور، «بازاندیشی» (Reflection) — یعنی تمرین بررسی کار توسط خودِ مدل — را در مرکز مهندسی عامل‌ها قرار داده است. به همین ترتیب، آندری کارپاتی (Andrej Karpathy) در سخنرانی خود در YC AI Startup School، مفهوم «نرم‌افزار ۳.۰» را به عنوان عملِ متصل کردن «تولید سریع» به «تأیید سریع» تعریف می‌کند.

در حالی که تیم‌های تک‌عاملی با نوشتن ارزیابی‌ها (Evals)، افزودن داوران (Judges) و محدود کردن طرح‌های خروجی (Output Schemas) سازگار شده‌اند، صنعت به سمت سامانه‌های چندعاملی (Multi-agent Systems) حرکت می‌کند. هدف نهایی دیگر یک عامل در یک حلقه نیست، بلکه مجموعه‌ای از عامل‌ها از تامین‌کنندگان مختلف است که با پروتکل‌های متفاوت صحبت می‌کنند و برای رسیدن به یک هدف واحد ترکیب شده‌اند. و اینجاست که داستان اعتماد متلاشی می‌شود.

جزئیات شکست‌های سیستماتیک

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

• انحراف برنامه (Plan Drift): برنامه‌ای که در مرحله اول منطقی است، اغلب تا مرحله چهارم منسوخ می‌شود. بستر تغییر می‌کند یا یک نتیجه میانی اشتباه خوانده می‌شود، اما عامل‌ها با اعتمادبه‌نفس به اجرای برنامه‌ای ادامه می‌دهند که دیگر هدفی را دنبال نمی‌کند. این اتفاق می‌افتد چون در میانه مسیر، هیچ چیزی برنامه را با واقعیت تطبیق نمی‌دهد.
• خطاهای مسیریابی (Routing Errors): در شبکه‌ای با ۳۰ قابلیت ثبت‌شده، عامل‌ها اغلب یک ابزار «محتمل» را به‌جای ابزار «درست» انتخاب می‌کنند. در حالی که این موضوع با سه ابزار تنها یک مشکل پرامپت است، در مقیاس بالا به یک مشکل بازیابی (Retrieval) تبدیل می‌شود. بسیاری از زیرساخت‌ها هنوز سعی می‌کنند این مشکل را با چپاندن همه چیز در پنجره بافتار (Context Window) و امید به بهترین نتیجه حل کنند.
• ابهام در هویت (Identity Ambiguity): در حال حاضر هویت یک «حس» (Vibe) است. به‌ندرت یک قرارداد قابل تأیید وجود دارد که مشخص کند یک عامل اجازه انجام چه کاری را دارد. اگرچه مجوزهای سطح پروتکل و توکن‌های محدودشده (Scoped Tokens) در حال ظهور هستند، اما اختیار معمولاً بر اساس پرامپت فرض می‌شود. اگر عاملی از محدوده مجاز خود فراتر رود، هیچ قراردادی برای ارجاع وجود ندارد—تنها یک ترنسکریپت است که می‌توان درباره آن بحث کرد.
• تبخیر خروجی (Output Evaporation): اکثر اجراها به متن ساده (Prose) ختم می‌شوند. یک حباب چت را نمی‌توان با اجرای قبلی مقایسه کرد (Diff)، با یک طرح (Schema) چک کرد یا در محیط عملیاتی مانیتور کرد. این بدترین فرمت قابل تأیید است که صنعت تا به حال در مقیاس بالا عرضه کرده است، اما همچنان به عنوان پیش‌فرض باقی مانده است.

شکاف شواهد (The Evidence Gap)

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

این ترنسکریپت، لاگی از پیام‌هاست (شاید با فراخوانی‌های ابزار در متن) که توسط همان سیستمی تولید شده که شما اکنون می‌خواهید آن را تأیید کنید. شما نمی‌توانید آن را به‌طور مستقل تأیید کنید، آن را برای تأیید به شخص ثالث نشان دهید یا اجرای دیشب را با اجرای هفته پیش مقایسه (Diff) کنید. از شما خواسته شده به «راوی» اعتماد کنید، در حالی که راوی همان «متهم» است.

در مهندسی بالغ، این وضعیت غیرقابل‌قبول است. حوزه‌های دیگر سال‌هاست پاسخ این مشکل را یافته‌اند:

• هوانوردی: به خاطرات خلبان اعتماد نمی‌کند؛ بلکه از یک ضبط‌کننده پرواز (جعبه سیاه) استفاده می‌کند که بازرسان بدون پرسش از شرکت هواپیمایی، آن را می‌خوانند.
• امور مالی: به ترمینال معامله‌گر اعتماد نمی‌کند؛ بلکه از سوابق تسویه (Clearing Records) استفاده می‌کند که هر دو طرف می‌توانند آن را تطبیق دهند.
• زنجیره تأمین نرم‌افزار: از اعتماد به ادعاهای ساخت (Build Claims) دست کشیده و شروع به درخواست اثبات منشأ (Provenance) کرده است.

در سال ۲۰۲۶، پیشرفته‌ترین مدرک برای یک عامل، اساساً اسکرین‌شاتی از یک پنجره چت است. در حالی که ابزارهای مشاهده‌پذیری (Observability) ردپاهایی (Traces)، بازه‌ها (Spans) و داشبوردهایی ارائه می‌دهند، این‌ها باز هم توسط سیستم مورد بررسی تولید و توسط فروشنده ذخیره شده‌اند. برای مشاهده آن‌ها، باید دوباره وارد همان سیستمی شوید که در حال بررسی آن هستید.

ساخت لایه اعتماد (Building a Trust Layer)

برای عبور از «اعتماد به راوی»، ساخت یک لایه اعتماد (Trust Layer) غیرقابل‌مذاکره است. این لایه ربطی به مدل بهتر ندارد، بلکه درباره ارکستراسیون، طراحی قرارداد و مهندسی تأیید است و باید چهار ویژگی داشته باشد:

۱. خروجی به‌عنوان قرارداد: نتایج باید در قالب‌های ساختاریافته و بررسی‌شده با Schema بازگردانده شوند. «آیا کار کرد؟» باید یک پرسش قابل بررسی (Checkable) باشد، نه یک تمرین درک مطلب. متن ساده باید استثنا باشد، نه رابط کاربری.
۲. هویت و محدوده به‌عنوان داده: هر بازیگر باید یک هویت قابل تأیید و یک محدوده اعلام‌شده از اقدامات مجاز داشته باشد. این محدوده باید در زمان ارکستراسیون چک شود، نه اینکه از روی پرامپت‌ها فرض شود.
۳. تأییدی که محدودیت‌های خود را می‌پذیرد: سیستم باید بین بررسی‌های ساختاری (آیا این خروجی خوش‌فرم و مطابق قرارداد است؟) و قضاوت معنایی (آیا این واقعاً درست است؟) تفاوت قائل شود. یک سیستم قابل اعتماد دقیقاً می‌گوید کدام بررسی را اعمال کرده است، به‌جای اینکه قضاوت‌هایی را القا کند که توانایی‌اش را ندارد.
۴. شواهد به‌جای گزارش: یک اجرای تمام‌شده باید چیزی صادر کند که شخص ثالث بتواند به‌طور مستقل بررسی کند. تست ساده است: تأیید نباید مستلزم فراخوانی سیستمی باشد که نتیجه را تولید کرده است. این شواهد امضا شده باید به یک هویت قابل تأیید متصل باشد.

این چرخش، هدف را از «مدل‌های بهتر» به «مهندسی تأیید» تغییر می‌دهد. چالش اصلی دیگر وزن‌های مدل نیست، بلکه شواهدی است که از اجرای مدل تولید می‌شود.

چه شواهدی واقعاً باعث می‌شود به اجرای عاملی که ندیده‌اید اعتماد کنید؟ نه اینکه کدام داشبورد شما را آرام می‌کند، بلکه شواهدی واقعی که بتوانید خودتان چک کنید و وقتی اجرای عملیات اهمیت دارد، به آن تکیه کنید. پاسخ احتمالاً در تلاقی مجوزهای سطح پروتکل و اثبات منشأ مستقل نهفته است.

گام بعدی شما

• خروجی‌های عامل‌های خود را از متن ساده به فرمت‌های ساختاریافته (مانند JSON با Schema سخت‌گیرانه) تغییر دهید.
• برای هر عامل، یک فایل «تعریف محدوده» (Scope Definition) خارج از پرامپت ایجاد کنید تا دسترسی‌ها در لایه ارکستراسیون چک شوند.
• به دنبال ابزارهای ثبت وقایع (Logging) مستقل از محیط اجرای مدل باشید تا شواهدی غیرقابل‌تغییر داشته باشید.

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