تصور کنید یک دستیار هوشمند را برای رزرو ساعت ۲ بعدازظهر متقاعد کرده‌اید، اما در همان چند ثانیه‌ای که منتظر تایید نهایی هستید، شخص دیگری آن ساعت را رزرو می‌کند. اگر عامل هوش مصنوعی شما فاقد یک لایه اعتبارسنجی لحظه‌ای باشد، دستور را اجرا می‌کند و نتیجه چیزی جز یک خطای سیستمی یا تداخل در تقویم نخواهد بود. در واقع، در سه ثانیه‌ای که سیستم برای ارسال فراخوانی API زمان نیاز دارد، داده‌های دنیای واقعی تغییر می‌کنند و بدون یک مرز اعتبارسنجی، هوش مصنوعی برنامه را به هر حال اجرا می‌کند که منجر به درخواست ناموفق یا یک برنامه زمان‌بندی فاسد می‌شود.
این شکاف زمانی بین تایید کاربر و اجرای عملیات، همان چیزی است که به «مشکل برنامه منقضی‌شده» (Stale-Plan Problem) معروف است. StareBrain، لایه‌ای برای تایید دستورات تلفنی، اخیراً نشان داد که چگونه تغییر داده‌ها در چند ثانیه، منجر به شکست عملیات در سیستم‌های عامل‌محور (Agentic) می‌شود؛ جایی که «برنامه» ثابت است اما «دنیا» سیال و در حال تغییر است. این چالش‌ها در واقع تکرار همان نقص‌های ساختاری در گردش‌کارهای محاسباتی است که پیش‌تر منجر به خطاهای بحرانی در تراکنش‌های مالی شده بود.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و پایداری مدل‌های زبانی اشاره کردیم، اعتماد کورکورانه به خروجی مدل بدون بررسی وضعیت لحظه‌ای محیط، بزرگ‌ترین نقطه ضعف عامل‌هاست. در این سیستم‌ها، عامل (Agent) — شبیه به کارمندی که دستورات را یادداشت می‌کند اما قبل از اجرا دوباره چک نمی‌کند که آیا شرایط تغییر کرده یا نه — ممکن است بر اساس اطلاعاتی عمل کند که دیگر معتبر نیستند. این مشکل زمانی رخ می‌دهد که کاربر برنامه‌ای را تایید می‌کند، اما داده‌ها — مانند شماره تلفن یک مخاطب یا یک جایگاه خالی در تقویم — پیش از اجرای عملیات به‌روزرسانی می‌شوند. این رویکرد یادآور ضرورت انتقال چک‌لیست‌های اعتبارسنجی به بیرون از مدل است تا دقت عامل‌ها در مقیاس بالا تضمین شود.
توسعه‌دهنده این سیستم پیش از این، این مشکل را در رشته‌توییت‌های خود توصیف کرده بود، اما تا آن زمان موفق نشده بود آن را در یک محیط زنده و واقعی شکار کند. راهکار اولیه برای حل این مشکل، یک رویکرد ساده و موردی (Ad hoc) بود: بررسی مجدد فیلدهای خاص درست پیش از اجرا و درخواست تایید دوباره از کاربر در صورت تغییر هر مورد. اما این روش نیازمند بررسی‌های سفارشی برای هر نوع عملیات بود که منجر به تست‌های ناسازگار و ریسک بالای فراموش کردن این بررسی‌ها هنگام افزودن قابلیت‌های جدید می‌شد.
طبق گزارشی در وب‌سایت dev.to که در ۲۱ سپتامبر ۲۰۲۶ منتشر شد، برای حل این بحران، کتابخانه FreshCtx معرفی شد؛ ابزاری پایتونی که ردیابی وابستگی‌ها را در مرز اجرای دستورات استاندارد می‌کند. این کتابخانه به‌جای بررسی‌های پراکنده و دستی، از یک فراخوانی استاندارد به نام ctx.run() استفاده می‌کند. این مکانیزم تضمین می‌کند که تمام شواهدی که یک دستور بر اساس آن‌ها طراحی شده، درست پیش از فراخوانی مجدداً تایید شوند. این متدولوژی شباهت زیادی به رویکرد Timewitness در اعتبارسنجی اصلاح‌کدهای هوش مصنوعی دارد که از ایزوله‌سازی وضعیت برای جلوگیری از تاییدهای کاذب استفاده می‌کند.
توسعه‌دهنده پیش از ادغام این ابزار، ساختار کد و فایل README کتابخانه را به دقت بررسی کرد تا از ایجاد عادت‌های برنامه‌نویسی بر اساس اعتماد کورکورانه اجتناب کند. از آنجایی که بک‌اند سیستم از قبل بر پایه FastAPI و پایتون ساخته شده بود، هیچ تداخلی در زبان برنامه‌نویسی وجود نداشت.
او برای اطمینان از عملکرد، از یک محیط شبیه‌سازی‌شده (Filesystem Fixture) به‌جای APIهای زنده استفاده کرد تا منطق را کاملاً ایزوله کند. در این تست، دو مسیر با استفاده از یک وضعیت نسخه‌بندی شده (v7 برای در دسترس و v8 برای غیر در دسترس) مقایسه شدند:
- مسیر بدون حفاظ: سیستم بر اساس وضعیت v7 برنامه‌ریزی کرد. حتی پس از اینکه وضعیت به v8 (غیردر دسترس) تغییر یافت، دستور رزرو بدون توجه به تغییرات اجرا شد. این منجر به یک اثر رزرو بر اساس یک برنامه منقضی‌شده شد.
- مسیر محافظت‌شده: با استفاده از مرز FreshCtx، سیستم تغییر وضعیت به v8 را شناسایی کرد و بلافاصله یک بلوک
STALE_REASONINGفعال کرد. نتیجه این مسیر، صفر اثر رزرو (عدم اجرای دستور غلط) بود.
در مورد جزئیات ادغام و محدودیت‌ها، توسعه‌دهنده اشاره کرد که اگرچه FreshCtx آداپتورهای (Adapter) داخلی برای چندین سرویس دارد، اما هنوز شکاف‌هایی وجود دارد. این کتابخانه در حال حاضر از Postgres, Stripe, Git, HTTP, سیستم فایل (Filesystem) و MCP پشتیبانی می‌کند. با این حال، هیچ آداپتور آماده‌ای برای تقویم (Calendar) وجود ندارد و برای رزروهای واقعی تقویم، باید یک آداپتور سفارشی نوشته شود.
علاوه بر این، نگهدارنده کتابخانه تصریح کرد که ctx.run() یک تراکنش کاملاً اتمیک (Atomic) با APIهای خارجی نیست. در حالی که این ابزار شکاف را در مرزی که FreshCtx کنترل می‌کند می‌بندد، اما نمی‌تواند جلوی تایم‌اوت‌های APIهای راه دور یا تغییراتی را بگیرد که دقیقاً پس از ارسال درخواست رخ می‌دهند.
این تغییر رویکرد، قابلیت اطمینان هوش مصنوعی را از «اجرای امیدوارانه» به «اجرای تاییدشده» تغییر می‌دهد. برای توسعه‌دهندگانی که عامل‌های پیچیده می‌سازند، این یعنی حذف منطق‌های تکراری و سفارشی برای هر ابزار و جایگزینی آن با یک لایه اعتبارسنجی جهانی.
با تبدیل شکاف بین تایید و اجرا به یک ریسک درجه‌یک، می‌توان جلوی توهم (Hallucination) — شبیه به دوستی که با اطمینان خاطره‌ای را اشتباه تعریف می‌کند — در مورد موفقیت عملیات بر اساس داده‌های قدیمی را گرفت. این موضوع به‌ویژه در تراکنش‌های مالی یا زمان‌بندی‌های حساس که چند ثانیه تأخیر می‌تواند قصد کاربر را باطل کند، حیاتی است. باید منتظر توسعه آداپتورهای جامع‌تر شخص ثالث برای FreshCtx بود تا این الگوی اعتبارسنجی را بتوان در اکوسیستم‌های پیچیده‌تر SaaS سازمانی پیاده‌سازی کرد.
گام بعدی شما
- اگر در حال توسعه عامل‌های پایتونی هستید، کتابخانه FreshCtx را برای جایگزینی چک‌های دستی بررسی کنید.
- برای ابزارهای خاص (مانند تقویم یا CRMهای داخلی)، آداپتورهای سفارشی خود را بر اساس ساختار
ctx.run()طراحی کنید. - در طراحی UX، برای حالت‌های
STALE_REASONINGپیام‌های شفافی تعریف کنید تا کاربر بداند چرا دستور او در لحظه آخر لغو شده است.
اما داستان سخت‌افزاری این تحول و تأثیر تأخیرهای شبکه بر این اعتبارسنجی‌ها حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی بهینه‌سازی تأخیر در استنتاج مراجعه کنید.
گفتگو