تصور کنید یک عامل هوشمند برای انجام یک وظیفه‌ی ساده، در یک حلقه‌ی بی‌پایان گیر کند و پیش از آنکه متوجه شوید، هزاران دلار از حساب شما برداشت کند. این کابوس مالی دیگر یک احتمال نیست، بلکه ریسک واقعی اجرای عامل‌های هوشمند است. قیمت‌گذاری ناشناخته‌ی یک مدل، صرفاً یک خطای پیکربندی جزئی نیست؛ بلکه برای عامل‌های خودمختار، یک شکست بحرانی در زمان اجرا (Runtime Failure) محسوب می‌شود.
در تاریخ ۲۲ ژوئن ۲۰۲۶، توسعه‌دهنده‌ای به نام سالم اسیلی (Salim Assili) با جزئیات توضیح داد که چرا محیط‌های اجرای عامل‌های هوش مصنوعی باید به‌گونه‌ای طراحی شوند که «بسته شکست بخورند» (Fail Closed). این به معنای آن است که سیستم باید از اجرای هرگونه فراخوانی ارائه‌دهنده (Provider Call) خودداری کند، اگر هزینه آن فراخوانی را نتوان به‌طور دقیق تخمین زد.
زمینه: چرا عامل‌ها ریسک را چند برابر می‌کنند؟
برخلاف برنامه‌های ساده‌ی LLM که یک درخواست ارسال می‌کنند و هزینه‌ها را بعداً بررسی می‌کنند، عامل‌ها در حلقه‌ها (Loops) عمل می‌کنند. یک عامل (Agent) — شبیه به کارمندی که برای رسیدن به نتیجه، چندین بار به منابع مختلف مراجعه می‌کند و اگر جواب نگرفت دوباره تلاش می‌کند — ممکن است ده‌ها مرحله را طی کند. او می‌تواند یک مدل را فراخوانی کند، درخواست‌ها را تکرار کند، از ابزارها استفاده کند، محتوای بیشتری (Context) اضافه کند و طی ده‌ها گام، مدل‌ها را تغییر دهد. خطرناک این است که این سیستم‌ها ممکن است به‌کندی شکست بخورند، بدون آنکه هرگز به‌طور کامل کرش کنند.
این موضوع در واقع تکامل همان بحرانی است که در تحلیل‌های ما درباره‌ی حلقه‌های تکرار بدون محدودیت بررسی کردیم؛ جایی که عدم کنترل بر تکرارها، اعتماد به عامل‌های هوشمند را تخریب می‌کند.
این یعنی یک اشتباه تایپی ساده در نام مدل، تغییر در نام مستعار ارائه‌دهنده (Provider Alias)، یا یک مدل جایگزین (Fallback) بدون قیمت مشخص، می‌تواند ریسک‌های هزینه‌ای را به‌صورت نمایی افزایش دهد. اگر پیکربندی محیط توسعه با محیط عملیاتی (Production) متفاوت باشد یا مدل جدیدی بدون متادیتای قیمت‌گذاری اضافه شود، ممکن است محیط اجرا پیش از آنکه کسی متوجه شود، ۱۰، ۲۰ یا ۵۰ فراخوانی انجام دهد. چون شکست‌های هزینه‌ای اغلب اشتباهات خسته‌کننده‌ی زمان اجرا هستند و نه کرش‌های دراماتیک، برای مدت طولانی‌تر باقی می‌مانند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، این خطاهای زمان اجرا اغلب شناسایی نمی‌شوند تا زمانی که صورت‌حساب برسد. در واقع، این مسئله با چالش‌های مدیریت توکن در گفتگوهای طولانی مشابه است، زیرا همان‌طور که پیش‌تر بررسی کردیم، حجم زیاد داده در چت‌های طولانی می‌تواند هزینه‌های استنتاج را به شکلی غیرمنتظره افزایش دهد.
جزئیات: مکانیسم «شکست بسته» (Fail Closed)
برای حل این مشکل، اسیلی ابزاری به نام AI CostGuard را معرفی کرد؛ یک لایه‌ی ایمنی محلی (Local-first) مبتنی بر TypeScript/Node.js که به جای تکیه بر داشبوردهای پس از اجرا، مانند یک «کلید قطع اضطراری» (Kill Switch) پیش از فراخوانی عمل می‌کند. این ابزار تضمین می‌کند که وقتی سیستم نمی‌تواند تصمیمی ایمن درباره‌ی فراخوانی بعدی ارائه‌دهنده بگیرد، از ادامه مسیر خودداری کند.
این گارد زمان‌اجرایی، درخواست را پیش از آنکه فراخوانی API ارائه‌دهنده اجرا شود، رهگیری می‌کند تا چهار پرسش حیاتی را پاسخ دهد:
- از کدام مدل استفاده می‌شود؟
- هزینه‌ی تخمینی ورودی و خروجی چقدر است؟
- چه مقدار بودجه برای این اجرای خاص باقی مانده است؟
- آیا این فراخوانی مجاز است؟
از نظر فنی در TypeScript، این فرآیند توسط گاردی مدیریت می‌شود که پارامترهای runId (شناسه‌ی اجرا)، model (مدل)، inputTokens (توکن‌های ورودی)، maxOutputTokens (حداکثر توکن‌های خروجی) و budget (بودجه) را ارزیابی می‌کند. اگر تصمیم نهایی «نامجاز» باشد، سیستم پیش از آنکه دستور provider.call مورد انتظار (awaited) قرار گیرد، یک خطای ساختاریافته صادر می‌کند.
چارچوب AI CostGuard
به نقل از مستندات گیت‌هاب این پروژه، AI CostGuard یک دفتر حسابداری صورت‌حساب، یک دیواره‌ی آتش سازمانی یا یک مرز امنیتی سخت‌افزاری نیست. در عوض، این یک لایه‌ی ایمنی است که بر چندین حالت شکست (Failure Modes) خاص تمرکز دارد:
- قیمت‌گذاری ناشناخته مدل: مسدود کردن فراخوانی‌هایی که کاتالوگ قیمت‌گذاری فاقد رشته‌ی مدل (Model String) مربوطه است تا از حدس‌های خاموش سیستم جلوگیری شود.
- تشخیص طوفان تکرار (Retry Storm): شناسایی تلاش‌های سریع و متوالی که منجر به جهش ناگهانی هزینه‌ها می‌شود.
- تشخیص حلقه‌ی پرامپت: شناسایی زمانی که یک عامل در یک چرخه‌ی تکراری و بی‌مفهوم گیر کرده است.
- حفاظت از حداکثر گام‌ها: اعمال یک محدودیت سخت روی تعداد تکرارهای مجاز در هر اجرا.
- گاردهای بودجه: استفاده از میان‌افزارها (Middleware) و رپرهای (Wrappers) نرم‌افزاری برای اجرای سخت‌گیرانه‌ی سقف هزینه‌کرد.
با پیاده‌سازی یک قاعده‌ی ساده — if (!pricingCatalog.has(model)) { throw new UnknownModelPricingError(model); } — توسعه‌دهندگان می‌توانند از حدس‌های خاموش جلوگیری کنند. در این حالت، اجرای زمان‌اجرا پیش از وقوع هزینه متوقف می‌شود و توسعه‌دهنده را مجبور می‌کند تا نام مستعار مدل را اصلاح کند، متادیتای قیمت را به‌روزرسانی نماید یا پیکربندی را تغییر دهد.
این رویکرد، پارادایم را از «مانیتورینگ» (Monitoring) به «گاردینگ» (Guarding) تغییر می‌دهد. در حالی که داشبوردهای صورت‌حساب و لاگ‌ها پس از اجرا به این سوال پاسخ می‌دهند که «چه اتفاقی افتاد؟»، یک گارد زمان‌اجرایی به این سوال پاسخ می‌دهد: «آیا این فراخوانی بعدی باید رخ دهد؟». وقتی یک فراخوانی ارائه‌دهنده اجرا می‌شود، هزینه ایجاد شده است؛ اما یک گارد پیش از فراخوانی، مانع از تداوم آن اشتباه می‌شود.
برای کیف پول توسعه‌دهندگان، این یعنی تفاوت بین یک بودجه‌ی کنترل‌شده‌ی ۵ دلاری و یک صورت‌حساب تصادفی ۵ هزار دلاری که بر اثر یک حلقه‌ی بازگشتی مدل (Model Fallback Loop) ایجاد شده است. این متد، استدلال‌های پیچیده را با «قوانین خسته‌کننده» جایگزین می‌کند — یعنی دانستن مدل، قیمت و بودجه — تا پیش‌بینی‌پذیری در جریان‌های کاری عاملی (Agentic Workflows) تضمین شود.
توسعه‌دهندگان اکنون می‌توانند این لایه‌ی ایمنی را از طریق بسته‌ی npm با نام @salimassili/ai-costguard ادغام کنند تا خطاهای ساختاریافته‌ای را برای ابهامات هزینه‌ای پیاده‌سازی نمایند.
گام بعدی شما
- اگر از Agentic Workflows استفاده می‌کنید، لایه‌ی کنترل هزینه را پیش از استقرار در محیط Production پیاده‌سازی کنید.
- متادیتای قیمت‌گذاری تمام مدل‌های جایگزین (Fallback) را در کاتالوگ سیستم خود به‌روزرسانی کنید.
- سقف گام‌های مجاز (Max-Steps) را برای هر Task به‌صورت مجزا تعریف کنید.
اما مدیریت هزینه‌ها تنها بخشی از چالش است؛ اثر این پیچیدگی‌ها بر معماری تراشه‌های جدید را در گزارش بعدی بررسی خواهیم کرد.
گفتگو