تصور کنید یک عامل هوش مصنوعی را برای تحقیق در یک موضوع پیچیده فعال کنید و صبح روز بعد با صورت‌حسابی مواجه شوید که بودجهٔ یک ماههٔ شما را تنها در چند ساعت بلعیده است. این کابوس مالی، دقیقاً همان نقطه‌ای است که مهندسی زمان-اجرا (Runtime Engineering) با چالش جدی روبه‌رو می‌شود.
طبق گزارش ۸ جولای ۲۰۲۶ در وب‌سایت dev.to، شرکت آنتروپیک (Anthropic) قابلیت‌های کلود کوورک (Claude Cowork) را فراتر از اپلیکیشن‌های دسک‌تاپ گسترش داده است. این تحول به عامل‌ها اجازه می‌دهد فارغ از فعال بودن جلسه کاربر، به کارهای خود ادامه دهند. این قابلیت دسترسی گسترده‌تر به عامل‌ها را فراهم کرده است، به‌طوری‌که اکنون کنترل از راه دور کلود کوورک از طریق موبایل نیز امکان‌پذیر شده است. اما یک مشکل حیاتی وجود دارد: عامل‌ها به‌طور ذاتی نمی‌دانند چه زمانی باید متوقف شوند. اکنون کاربران می‌توانند از طریق مرورگر وب یا اپلیکیشن گوشی هوشمند کلود با نسخه‌های محدود تعامل کنند، اما چون کارهای Cowork حتی پس از خروج کاربر از سیستم هم ادامه می‌یابد، ریسک هزینه‌های خارج از کنترل API به تهدید اصلی این سیستم‌های خودمختار تبدیل شده است.
در اینجا شکافی میان رویکرد «واکنشی» و «پیش‌کننده» شکل می‌گیرد. یک چت‌بات معمولی واکنشی است؛ یعنی منتظر پیام کاربر می‌ماند، پاسخ می‌دهد و سپس تعامل متوقف می‌شود. اما یک عامل (Agent) — شبیه به کارمندی که اختیار دارد برای رسیدن به هدف، هر ابزار یا منبعی را بدون اجازهٔ لحظه‌ای به لحظهٔ شما به کار بگیرد — پیش‌کننده است. او می‌تواند مدل را فراخوانی کند، ابزارها را اجرا کند، نتایج را بررسی نماید، کانتکست (زمینه) جدید اضافه کند و عملیات را به‌طور نامحدود تکرار کند. بدون نظارت انسانی، چنین عاملی می‌تواند در یک شب هزاران بار مدل را فراخوانی کرده و بودجه یک ماه را در عرض چند ساعت نابود کند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد مطلق به لایهٔ پرامپت برای کنترل رفتار مدل‌ها خطرناک است. بسیاری از توسعه‌دهندگان از یک «حلقه ساده» (Naive Loop) برای عامل‌ها استفاده می‌کنند؛ جایی که یک بلوک کد ساده مانند while (!task.done) منتظر پاسخ ارائه‌دهنده می‌ماند و گام بعدی عامل را اجرا می‌کند. این روش نوشتن آن آسان است اما برای گردش‌کارهای بدون نظارت، کاملاً ناایمن است. چنین حلقه‌هایی فاقد محدودیت حداکثری گام‌ها، بررسی‌های بودجه یا سیستم تشخیص «طوفان تکرار» (Retry-storm) هستند. در این حالت، اگر عامل در یک حلقه منطقی گیر کند، مدام به فراخوانی ارائه‌دهنده ادامه می‌دهد تا زمانی که یک نیروی خارجی آن را متوقف کند؛ نیروهایی مانند خطای ارائه‌دهنده، رسیدن به سقف محدودیت حساب یا یک صورت‌حسابی نجومی. هیچ‌کدام از این‌ها کنترل‌های بهینه برای زمان-اجرا نیستند. شناسایی این نقاط شکست در محیط‌های عملیاتی، تداعی‌کننده رویکردهایی است که در Strands Evals با استفاده از مهندسی آشوب برای سخت‌سازتر کردن عامل‌ها به کار می‌رود.
توسعه یک گردش‌کار بدون نظارت، به چیزی فراتر از یک داشبورد مدیریتی نیاز دارد؛ این امر مستلزم یک «نگهبان» (Guard) است که پیش از هر فراخوانی ارائه‌دهنده اجرا شود. توسعه‌دهندهٔ AI CostGuard، که یک لایهٔ ایمنی محلی (Local-first) مبتنی بر TypeScript/Node.js است، مجموعه‌ای مشخص از بررسی‌های پیش از فراخوانی را پیشنهاد می‌کند. این تغییر معماری، مسئولیت ایمنی را از «پرامپت مدل زبانی بزرگ» به «محیط اجرا» (Runtime Environment) منتقل می‌کند.
بر اساس مستندات این ابزار، با قرار دادن یک لایه تصمیم‌گیرنده پیش از رسیدن درخواست به ارائه‌دهنده، توسعه‌دهندگان می‌توانند محدودیت‌های سخت‌گیرانه‌ای را از طریق مکانیسم‌های زیر اعمال کنند:
- قیمت‌گذاری مدل: محیط اجرا باید هزینه مدل را در یک کاتالوگ قیمت‌ها تأیید کند. اگر قیمت نامعلوم باشد، تماس مسدود می‌شود. این کار از «حدس زدن» بودجه در زمان استفاده از نام‌های مستعار مدل (Alias)، سیستم‌های جایگزین (Fallback) یا بازنویسی گیت‌وی جلوگیری می‌کند.
- بودجه در سطح تسک: برخلاف داشبوردهای ماهانه که گزارش‌های «دیر» می‌دهند، بودجه‌های سطح تسک، دقیقاً تماس بعدی را پیش از ایجاد هزینه متوقف می‌کنند. اگر
estimatedNextCallCost > budgetRemainingباشد، فرآیند متوقف می‌شود. - محدودیت گام‌ها: سیاست‌های صریح برای حداکثر تعداد گام‌ها تضمین می‌کند که هر اجرای ناقص که در بازه زمانی معقول به پایان نمی‌رسد، به‌صورت پاکیزه با دلیل
max_steps_exceededمتوقف شود. - تشخیص طوفان تکرار: سیستم بررسی می‌کند که آیا خطاهای اخیر مشابه هستند یا خیر. هدف این است که از تبدیل شدن شکست‌های مکرر به حجم اصلی عملیاتی جلوگیری شود.
- تشخیص حلقهٔ پرامپت: لایه حفاظتی شناسایی می‌کند که آیا عامل مدام سؤالات تقریباً یکسانی را می‌پرسد یا خیر. این مکانیسم الگوهایی را می‌گیرد که در آن عامل فعال به نظر می‌رسد اما در واقع مسیرهای جدیدی را اکتشاف نمی‌کند.
- ردیابی پیشرفت: اگر حرکت معناداری صورت نگیرد، اجرا متوقف می‌شود. محیط اجرا سیگنال‌هایی مانند کاهش خطاها، تغییر در فایل‌ها، بهبود تست‌ها یا تکمیل موارد چک‌لیست را ردیابی می‌کند. اگر پس از چندین گام پیشرفتی حاصل نشود، دستور توقف
no_progressصادر می‌شود.
برای توسعه‌دهندگان، این به معنای آن است که محیط اجرا به اولین خط دفاعی تبدیل می‌شود. تکیه بر خطاهای ارائه‌دهنده یا محدودیت‌های حساب کاربری برای متوقف کردن یک عامل سرکش، استراتژی ناپایداری است. استفاده از یک «دلیل توقف» ساختاریافته (مانند similar_prompt_loop یا budget_exceeded) اجازه می‌دهد عیب‌یابی بهتر صورت گیرد و مقیاس‌پذیری گردش‌کارهای عامل‌محور ایمن‌تر شود.
ابزار AI CostGuard به‌طور خاص برای مقابله با این ریسک‌های نامرئی، از جمله اجرای خارج از کنترل و تخطی از بودجه، طراحی شده است تا تصمیم بگیرد آیا تماس بعدی با ارائه‌دهنده باید اجرا شود یا خیر. برای پیاده‌سازی این حفاظ‌ها، مهندسان باید به سمت پیاده‌سازی لایه‌های ایمنی محلی بروند که به‌طور مستقیم با استک‌های Node.js یا TypeScript آن‌ها یکپارچه شود. چالش بعدی، ایجاد تعادل بین این شرایط توقف سخت‌گیرانه و انعطاف‌پذیری مورد نیاز برای وظایف استدلالی پیچیده و بلندمدت خواهد بود.
گام بعدی شما
- اگر از مدل‌های عامل‌محور در محیط Production استفاده می‌کنید، لایه‌های حفاظتی را از داخل پرامپت به محیط Node.js منتقل کنید.
- برای هر تسک مجزا، یک بودجه (Budget) سخت تعریف کنید تا از اتلاف اعتبار API جلوگیری شود.
- مکانیسم تشخیص «عدم پیشرفت» (No Progress) را برای شناسایی حلقه‌های منطقی در استدلال‌های پیچیده پیاده کنید.
این تنها آغاز مدیریت هزینه‌های استنتاج است؛ اما چالش بعدی، ایجاد تعادل بین این محدودیت‌های سخت و انعطاف‌پذیری مورد نیاز برای استدلال‌های بلندمدت خواهد بود که در گزارش‌های آتی بررسی خواهیم کرد.
گفتگو