اگر برای بهینه‌سازی هزینه‌های عامل‌های هوش مصنوعی خود از مدل‌های مختلف در یک زنجیره استفاده می‌کنید، احتمالاً همین حالا بخشی از زیرساخت شما بدون هیچ خطای آشکاری از کار افتاده است. در نخستین روزهای سپتامبر ۲۰۲۶، سه غول فناوری یعنی آنتروپیک (Anthropic)، گوگل (Google) و متا (Meta) به‌طور هم‌زمان به‌روزرسانی‌هایی را منتشر کردند که وضعیت استدلال مدل را به نسخه تولیدکننده گره می‌زند.
تا پیش از این، توسعه‌دهندگان تصور می‌کردند توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — در بخش استدلال، صرفاً رشته‌هایی از متن هستند. بر اساس این فرض، اگر یک مدل مسئله‌ای را گام‌به‌گام حل می‌کرد، می‌شد آن استدلال را ذخیره کرد و به مدل دیگری داد تا از ابتدا شروع نکند. شما می‌توانستید آن‌ها را لاگ کنید، در پایگاه داده ذخیره کنید، به یک فراخوانی API دیگر پاس دهید یا آن‌ها را به یک مدل کاملاً متفاوت بخورانید و انتظار داشتید هیچ چیز خراب نشود. اما طبق اعلام این سه شرکت، این فرض اکنون برای تمام سیستم‌های عملیاتی با نسخه‌های جدید مدل‌ها باطل شده است.
همان‌طور که در تحلیل قبلی ما درباره‌ی مدیریت بودجه در سیستم‌های عامل‌محور اشاره کردیم، این تغییر لایه‌ی جدیدی از بدهی فنی را ایجاد می‌کند. اکنون استدلال از یک اثر بدون وضعیت (Stateless) به یک منبع وابسته به وضعیت (Stateful) تبدیل شده است که باید در همان جایی بماند که متولد شده است. این یک تغییر بنیادین در نحوه شکست سیستم‌های عامل‌محور (Agentic) است و شناسایی آن با تست‌های سریع تقریباً غیرممکن است.
مفهوم استدلال در این بحران
برای درک علت این اختلال، باید تعریف دقیقی از استدلال داشته باشیم. یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در حالت‌های تفکر گسترده یا حالت‌های استدلالی، دو خروجی مجزا در یک درخواست واحد تولید می‌کند:
۱. پاسخ نهایی: بخشی که در نهایت به کاربر نهایی نمایش داده می‌شود.
۲. تخته‌سیاه داخلی (Internal Scratchpad): فضایی که مدل در آن پیش از متعهد شدن به پاسخ نهایی، مسئله را گام‌به‌گام بررسی و حل می‌کند. این بخش گاهی در پاسخ API قابل مشاهده است و گاهی پنهان می‌ماند.
به گزارش منابع فنی، طی دو سال گذشته، ارائه‌دهندگان به شکل‌های متفاوتی با این تخته‌سیاه برخورد کردند. برخی آن را پنهان کردند؛ برخی آن را به عنوان یک فیلد مجزا برای ثبت لاگ‌ها ارائه دادند؛ و برخی اجازه می‌دادند آن را به درخواست‌های آینده بازگردانید تا مدل مجبور نباشد کارهایی را که قبلاً انجام داده، دوباره تکرار کند. دقیقاً همین رفتار آخر — یعنی بازگرداندن محتوای استدلالی به درخواست‌های آتی — همان چیزی است که اکنون از کار افتاده است.
جزئیات تغییرات ارائه‌دهندگان
سه شرکت مختلف در یک بازه ۴۸ ساعته این مسیر را در پیش گرفتند. اگرچه هر کدام رویکرد متفاوتی داشتند، اما الگوی کلی یکسان است.
آنتروپیک صریح‌ترین رویکرد را داشت. در ۱ سپتامبر ۲۰۲۶، این شرکت مدل‌های Claude Fable 5.1 و یک نسخه محدودتر به نام Claude Mythos 5.1 را منتشر کرد. مدل Mythos 5.1 تنها از طریق برنامه‌های دسترسی مورد اعتماد (Trusted Access) در دسترس است و برای عموم عرضه نشده است. اما Fable 5.1 نسخه‌ای است که اکثر توسعه‌دهندگان از آن استفاده خواهند کرد و یک تغییر ساختاری خطرناک در راهنمای مهاجرت آن دفن شده است:
- قفل استدلال (Reasoning Lock): تفکر اکنون به‌طور یک‌طرفه به مدلی که آن را تولید کرده متصل است. شما نمی‌توانید توکن‌های استدلالی را از یک مدل بردارید و به مدل دیگری تحویل دهید.
- ابطال تاریخچه (History Invalidation): اگر شما یک نوبت (Turn) قدیمی در گفتگو را ویرایش کنید، هر توکن تفکری که بعد از آن نقطه تولید شده باشد، فوراً باطل می‌شود.
- تغییرات ابزارها: گزینه «انتخاب اجباری ابزار» (Forced tool choice) از لیست امکانات حذف شده است.
- قیمت‌گذاری: قیمت‌ها در سطح ۱۰ دلار به‌ازای هر میلیون توکن ورودی و ۵۰ دلار به‌ازای هر میلیون توکن خروجی باقی ماند، هرچند قیمت خواندن از حافظه پنهان (Cache read) کاهش یافت.
این قوانین برای هر حسابی که در تاریخ ۳۱ اوت ۲۰۲۶ یا پس از آن ایجاد شده باشد، اجرا می‌شوند و روند گسترش آن برای سایر حساب‌ها ادامه دارد.
گوگل در ۲ سپتامبر ۲۰۲۶ با معرفی Gemini 3.8 Flash به این روند پیوست؛ این سومین عرضه از سری Flash در حدود شش هفته اخیر است. هم‌زمان، مدل Gemini 3.8 Flash Cyber معرفی شد که تنها از طریق یک فرآیند تایید جدید به نام «برنامه Fairwind» (Fairwind Program) در دسترس است. اگرچه گوگل از عبارت صریح «قفل» مانند آنتروپیک استفاده نکرد، اما جهت حرکت یکسان است: قابلیت‌های بیشتر اکنون پشت وضعیت‌های (State) پیچیده‌تر و لایه‌های دسترسی سخت‌گیرانه‌تر قرار گرفته‌اند.
در همین تاریخ، متا مدل Muse Spark 1.3 را منتشر کرد. تغییرات این مدل ظریف‌تر است اما به همان مسیر اشاره دارد. این مدل اکنون در میانه انجام تسک، سوالات شفاف‌ساز می‌پرسد، پیش از انجام اقدامات حساس بازبینی می‌کند و پیش از متعهد شدن به اقدامات بازگشت‌ناپذیر، تایید می‌گیرد.
طبق اعلام متا، این رویکرد باعث شده فراخوانی ابزارها حدود ۲۰٪ و مصرف توکن‌ها حدود ۲۵٪ نسبت به نسخه قبلی کاهش یابد. با این حال، بنچ‌مارک‌های مستقل شرکت Artificial Analysis نشان داد که هزینه هر تسک تکمیل‌شده در واقع از حدود ۰.۴۰ دلار به حدود ۰.۵۵ دلار افزایش یافته است. دلیل این اتفاق آن است که مدل توکن‌های ورودی بیشتری را مصرف می‌کند تا بافت (Context) اضافی مربوط به سوالاتی که قبلاً پرسیده و پاسخ‌هایی که کاربر داده است را حفظ کند. این وضعیت (State) در داخل همان اجرای خاص (Run) زندگی می‌کند و در قالب یک فرمت قابل انتقال نیست.
نقاط شکست در معماری شما
چت‌بات‌های ساده یا خط‌لوله‌های تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — متوجه این تغییر نمی‌شوند. اگر شما یک پرامپت می‌فرستید، پاسخ می‌گیرید و گفتگو را به صورت تاریخچه متنی ساده ادامه می‌دهید، هیچ چیز خراب نمی‌شود زیرا توکن‌های استدلالی هرگز استخراج یا دوباره تزریق نمی‌شوند.
خطر اصلی برای «مسیریاب‌های چندمدلی» (Multi-model Routers) است. این یک الگوی رایج در سیستم‌های عامل‌محور است که در آن، اگر تسک ساده به نظر برسد، توسط یک مدل ارزان و سریع مدیریت می‌شود، اما اگر تسک پیچیده، پرهزینه یا نیازمند دقت بالا باشد، به یک مدل کندتر و گران‌تر ارتقا (Escalate) می‌یابد.
پیش از این، حرکت بهینه این بود که استدلال‌های ناقص مدل ارزان به مدل گران پاس داده شود تا مدل گران‌تر مجبور نباشد از صفر شروع کند. شما یک بار برای تفکر اولیه هزینه می‌کردید و از آن مجدداً استفاده می‌کردید. تحت قوانین جدید، این انتقال شکست می‌خورد. بسته به ارائه‌دهنده، یکی از سه نتیجه زیر رخ می‌دهد:
- شکست سخت (Hard Failure): درخواست به‌طور کامل با خطایی مبنی بر نامعتبر بودن یا عدم تطابق محتوای استدلالی رد می‌شود.
- کاهش بازدهی خاموش (Silent Efficiency Loss): API به‌طور خاموش استدلال‌هایی را که شما پاس داده‌اید نادیده می‌گیرد. مدل جدید «سرد» شروع به کار می‌کند و شما بهره‌وری و صرفه‌جویی در هزینه‌ای را که روی آن حساب کرده بودید، از دست می‌دهید.
- افت کیفیت (Quality Degradation): سیستم پاسخی تولید می‌کند که به نظر می‌رسد حاصل استدلال دقیق مدل قوی‌تر است، اما در واقعیت، آن مدل هرگز کاری را که شما تصور می‌کردید انجام نداده است.
هیچ‌یک از این نتایج معمولاً خطای بلندی (Loud Error) صادر نمی‌کنند. اپلیکیشن شما کرش نمی‌کند؛ فقط به‌طور خاموش بدتر می‌شود. مهندسی که هفته‌ها بعد در حال دیباگ کردن است، هیچ دلیل واضحی نخواهد داشت که شک کند بهینه‌سازی مسیریابی سال گذشته مقصر این اتفاق است.
تله ویرایش تاریخچه
بسیاری از چارچوب‌های عامل‌محور به قابلیت بازگشت و اصلاح نوبت‌های قبلی تکیه می‌کنند. این یک الگوی منطقی برای عامل‌هایی است که نیاز دارند به‌طور متناسب بازیابی شوند؛ برای مثال، اگر فراخوانی یک ابزار نتیجه بدی داد، یا سند بازیابی‌شده بی‌ربط بود، یا کاربر در میانه یک جلسه طولانی، حقیقتی را اصلاح کرد.
تحت قانون جدید آنتروپیک، ویرایش تاریخچه در هر نقطه، هر تکه از تفکراتی را که بعد از آن نقطه رخ داده است، باطل می‌کند. اگر چارچوب شما به‌طور خاموش از آن تفکرات بعدی برای جلوگیری از یک رفت‌وبرگشت اضافی یا برای منسجم نگه داشتن یک خلاصه استفاده می‌کرد، اکنون باید تمام آن کار را از ابتدا انجام دهد.
اگر چارچوب به‌طور صریح نداند که باید کار را دوباره انجام دهد، ممکن است استدلال‌های قدیمی و منقضی‌شده‌ای را ارائه دهد که به وضعیت گفتگویی متصل هستند که دیگر تغییر کرده است. این منجر به تولید پاسخ‌هایی می‌شود که با آخرین ورودی کاربر تضاد داخلی دارند. این ناهماهنگی‌ها شبیه به اشتباهات معمولی مدل (توهم یا Hallucination) به نظر می‌رسند تا باگ‌های زیرساختی، و همین موضوع تشخیص آن‌ها را سخت‌تر می‌کند.
چرا تست کردن این مشکل دشوار است؟
شکست‌های قفل استدلال فریبنده هستند زیرا در اسکریپت‌های تست تک‌مرحله‌ای (Single-turn) ظاهر نمی‌شوند. اگر یک سوال بپرسید و جواب را چک کنید، همه چیز درست به نظر می‌رسد. این شکست‌ها فقط در جریان‌های کاری طولانی، چند-نوبتی و چند-مدلی ظاهر می‌شوند؛ یعنی دقیقاً همان جریان‌هایی که اتوماسیون آن‌ها سخت‌ترین است و هنگام عجله برای عرضه محصول، راحت‌تر از همه نادیده گرفته می‌شوند.
سیستم‌هایی که بیشترین احتمال برخورد با این مشکل را دارند عبارت‌اند از:
- بات‌های پشتیبانی که وقتی یک جستجو اشتباه است، فراخوانی ابزارهای خود را اصلاح می‌کنند.
- عامل‌های کدنویسی که هنگام مواجهه با ابهام در یک کدبیس، از مدل سریع به مدل کند سوییچ می‌کنند.
- دستیارهای پژوهشی که به کاربران اجازه می‌دهند حقایق را در میانه جلسه اصلاح کنند و انتظار دارند عامل از همان نقطه اصلاح، استدلال را به جلو ببرد.
داستان هزینه‌های پنهان
استفاده مجدد از استدلال بین مدل‌های مختلف یک ترفند بهینه‌سازی واقعی بود. این کار به تیم‌ها اجازه می‌داد برای بخش بزرگی از تفکرات اکتشافی از مدل‌های ارزان استفاده کنند و قیمت‌های پرمیوم را فقط برای اینکه مدل گران‌قیمت خروجی نهایی را بررسی و صیقل دهد، پرداخت کنند.
قفل کردن استدلال به مدل، این ترفند را به‌طور هم‌زمان در کل صنعت حذف می‌کند. اگرچه این لزوماً یک توطئه نیست، اما زمان‌بندی آن با تمایل ارائه‌دهندگان به کسب درآمد پیش‌بینی‌پذیرتر از لایه‌های استدلال پرمیوم هم‌راستا است. آن‌ها دیگر نمی‌خواهند توسعه‌دهندگان با استفاده از مدل‌های ارزان برای انجام کارهای ذهنی سخت، مسیر پرداخت‌های لایه‌های گران‌قیمت را دور بزنند.
چک‌لیست عملی برای تیم‌های عملیاتی
اگر سیستم‌های عامل‌محور را مدیریت می‌کنید، باید این هفته این بازرسی‌ها را انجام دهید:
- بازرسی مرزهای مدل: در کد خود هر جایی را جستجو کنید که فیلد 'thinking' یا 'reasoning' را از یک پاسخ API استخراج کرده و در درخواست بعدی، به‌ویژه هنگام هدف قرار دادن یک نسخه مدل یا ارائه‌دهنده متفاوت، دوباره وارد می‌کنید.
- تست مسیرهای ارتقا: درخواستی شبیه به موارد واقعی تولید کنید که با یک مدل ارزان شروع شود، در میانه تسک باعث ارتقا شود و در نهایت به یک مدل گران‌قیمت برسد. بررسی کنید که آیا خروجی نهایی بازتاب‌دهنده استدلالی است که مدل گران‌قیمت خودش انجام داده است یا خیر.
- تایید ویرایش تاریخچه: اگر چارچوب شما از ویرایش یا بازپخش تاریخچه پشتیبانی می‌کند، دقیقاً بفهمید چه اتفاقی برای توکن‌های استدلالی بعد از نقطه ویرایش می‌افتد. تغییرات (Changelog) چارچوب خود را در ماه گذشته بررسی کنید تا ببینید آیا این مورد را وصله (Patch) کرده‌اند یا خیر.
- بررسی تاریخ حساب‌ها: آنتروپیک این قوانین را برای حساب‌های ایجاد شده در ۳۱ اوت ۲۰۲۶ یا پس از آن اجرا می‌کند. اگر حساب‌های متفاوتی برای محیط Staging و Production دارید، ممکن است باگ‌هایی در محیط عملیاتی ببینید که هرگز در محیط تست ظاهر نمی‌شوند.
- فرض همگرایی ارائه‌دهندگان: حتی اگر گوگل یا متا از عبارت «قفل استدلال» استفاده نکرده باشند، تغییرات اخیر آن‌ها به همین جهت است. فرض نکنید هیچ ارائه‌دهنده‌ای از این روند مستثنی است.
مدل‌های محدود شده و تغییرات بزرگ‌تر
الگوی دومی در همین بازه زمانی دیده می‌شود: ظهور مدل‌های محدود شده (Gated Models). مدل Mythos 5.1 آنتروپیک و Gemini 3.8 Flash Cyber گوگل هر دو نیازمند فرآیندهای درخواست هستند. هیچ‌کدام قیمت عمومی ندارند و با یک کارت اعتباری ساده قابل دسترسی نیستند.
مدل‌هایی که سخت‌گیرانه‌تر محدود شده‌اند، به‌طور مداوم مدل‌هایی هستند که محدودیت‌های ایمنی کمتری در مورد قابلیت‌های امنیت سایبری دارند. این استاندارد جدید برای عرضه‌های پیشرو (Frontier) است: یک نسخه به‌طور گسترده در دسترس با تمام حفاظ‌ها، و یک نسخه محدود برای دولت‌ها، زیرساخت‌های حیاتی و پلتفرم‌های اصلی فناوری.
این موضوع به داستان قفل استدلال متصل می‌شود زیرا نشان‌دهنده حرکتی به دور از نگاه به مدل‌ها به عنوان اجزای بدون وضعیت و قابل جایگزین است. استدلال در حال تبدیل شدن به یک منبع وابسته به وضعیت است که در داخل بافت (Context) یک مدل خاص زندگی می‌کند، نه یک بلوک JSON قابل انتقال که بتوان آن را بین سرویس‌ها جابجا کرد.
توصیه‌های من به تیمی که امروز پروژه را شروع می‌کند
اگر در حال شروع یک پروژه عامل‌محور جدید هستید، چند انتخاب در طراحی شما را از این مشکلات نجات می‌دهد:
۱. انتخاب مدل در مراحل اولیه: مسیریاب خود را طوری طراحی کنید که مدل را یک بار، در نزدیکی شروع تسک و بر اساس ارزیابی اولیه پیچیدگی، انتخاب کند. از ارتقای مدل در میانه تسک و تلاش برای انتقال وضعیت استدلال از آن مرز اجتناب کنید.
۲. تخصیص بیش از حد در ابتدا (Over-Provision): اگر تسکی پیچیده به نظر می‌رسد، بلافاصله آن را روی مدل قوی‌تر شروع کنید. هزینه تخصیص بیش از حد گاه‌به‌گاه، بسیار کمتر از هزینه دیباگ کردن شکست‌های خاموش استدلال در ساعت ۲ صبح است.
۳. فرض نقاط انشعاب (Fork Points): منطق ویرایش تاریخچه و تلاش مجدد (Retry) را با این فرض صریح بسازید که هر ویرایش، هر چیزی را که در پایین‌دست آن است باطل می‌کند. با ویرایش‌ها به عنوان یک نقطه انشعاب برخورد کنید که استدلال تازه را فعال می‌کند.
۴. مطالعه راهنمای مهاجرت: فقط به خط قیمت‌ها نگاه نکنید. مکانیسم‌هایی که در پایین صفحه دفن شده‌اند، همان چیزهایی هستند که در محیط عملیاتی به شما ضربه خواهند زد.
سخن پایانی
این دلیلی برای توقف ساخت ویژگی‌های عامل‌محور یا بی‌اعتمادی به مدل‌های مبتنی بر استدلال نیست. بلکه دلیلی است برای اینکه دیگر ارتقای مدل‌ها را به عنوان جایگزین‌های ساده (Drop-in replacements) نبینیم. اگر هر چیزی را مدیریت می‌کنید که بین مدل‌ها مسیریابی می‌کند، در میانه گفتگو ارتقا می‌یابد یا به کاربران اجازه ویرایش نوبت‌ها را می‌دهد، این موضوع شایسته یک بعدازظهر توجه متمرکز است.
بروید و هر جایی را که توکن‌های استدلالی شما در سیستم جابجا می‌شوند پیدا کنید و مطمئن شوید هیچ‌کدام سعی نمی‌کنند از مرزی عبور کنند که همین حالا بسته شده است. اگر الگوی تمیزی برای مدیریت این انتقال پیدا کرده‌اید، به اشتراک گذاشتن آن تنها راهی است که جامعه توسعه‌دهندگان از یادگیری این درس‌ها به روش سخت اجتناب کند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو