افزایش ۲۲.۶ درصدی هزینه‌های عامل‌های هوش مصنوعی بدون فعال شدن هشدارها

اگر امروز بودجه استنتاج عامل‌های خود را مدیریت می‌کنید، احتمالاً بخشی از پول شما در حفره‌ای نامرئی می‌ریزد. رشد روزانه تنها ۰.۳۵ درصدی هزینه‌ها برای ابزارهای نظارتی استاندارد عملاً نامرئی است. در حالی که یک داشبورد مدیریتی معمولی تنها زمانی هشدار می‌دهد که هزینه امروز ۲۰ درصد بیشتر از هفته گذشته باشد، یک رشد کند در «کف ورودی» (Input Floor) — شامل پرامپت‌های سیستمی، طرح‌های ابزار (Tool Schemas)، فایل‌های CLAUDE.md و سرورهای MCP — می‌تواند طی ۶۰ روز هزینه‌های شما را ۲۲.۶ درصد افزایش دهد، بدون آنکه حتی یک هشدار فعال شود.

این پدیده که «رانش هزینه عامل» (AI agent cost drift) نامیده می‌شود، یک نقطه کور خطرناک در بودجه‌های عملیاتی ایجاد می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی نامرئی بودن برخی داده‌های FAQ برندها برای هوش مصنوعی اشاره کردیم، این رانش نشان‌دهنده نوع متفاوتی از نامرئی بودن است: یک نشت مالی که دقیقاً با سازوکاری پیش می‌رود که خودِ مانیتورهای نظارتی را دور می‌زند. این موضوع در مدیریت پروژه‌های پیچیده حیاتی است، چرا که هرگونه عدم تطابق در مستندات می‌تواند منجر به افزایش توکن‌ها شود؛ راهکاری که در تحلیل بهینه‌سازی توکن‌ها با اولویت‌دهی به مستندات فنی برای کاهش رانش پروژه بررسی شده است.

به نقل از یک تحلیل فنی که در ۱۵ جولای ۲۰۲۶ در dev.to منتشر شد، ریشه این مشکل در ریاضیات است. خطوط مبنای متحرک (Rolling Baselines) — مانند میانگین‌های متحرک (Rolling Means)، میانه‌های متحرک (Rolling Medians) یا میانگین‌های متحرک نمایی (EWMA) در سطح یک ناوگان (Fleet) — تشخیص‌دهنده «سرعت» هستند، نه «سطح». چون خط مبنا هم‌روند با سیگنال بالا می‌رود، هر رشدی که یکنواخت باشد و کندتر از پنجره تطبیق (Adaptation Window) پیش برود، برای همیشه نامرئی می‌ماند. نویسنده این وضعیت را شبیه به «پدیده قورباغه در آب جوش» برای بودجه‌های هوش مصنوعی توصیف می‌کند.

ریاضیات نامرئی بودن

یک پنجره متحرک، وضعیت امروز را با مبنایی مقایسه می‌کند که از w روز گذشته ساخته شده و تقریباً در مرکز w/2 روز قبل قرار دارد. تحت رشد روزانه یکنواخت g، نسبت سطح امروز به سطح مبنا تقریباً برابر با (1+g)^(w/2) است. هشدار زمانی فعال می‌شود که این نسبت از آستانه T فراتر رود. با حل معادله برای g، فرمول «باند کور» (Blind Band) به دست می‌آید: g* = T^(2/w) - 1.

هر رشدی کندتر از g* برای همیشه نامرئی است. نسبتی که تشخیص‌دهنده محاسبه می‌کند دیگر افزایش نمی‌یابد، زیرا خط مبنا با همان سرعت سیگنال بالا می‌رود. برای پیکربندی‌های رایج، این ریاضیات «باندهای کور» زیر را پیش‌بینی می‌کند:

• پنجره ۷ روزه، آستانه ۱.۱۵: رشد‌های کمتر از ۴.۰۷٪ در روز نامرئی هستند (که در ۳۰ روز به ۳.۳۱ برابر تبدیل می‌شود).
• پنجره ۷ روزه، آستانه ۱.۲۰: رشد‌های کمتر از ۵.۳۵٪ در روز نامرئی هستند (که در ۳۰ روز به ۴.۷۷ برابر تبدیل می‌شود).
• پنجره ۱۴ روزه، آستانه ۱.۲۰: رشد‌های کمتر از ۲.۶۴٪ در روز نامرئی هستند (که در ۳۰ روز به ۲.۱۸ برابر تبدیل می‌شود).
• پنجره ۲۸ روزه، آستانه ۱.۲۰: رشد‌های کمتر از ۱.۳۱٪ در روز نامرئی هستند (که در ۳۰ روز به ۱.۴۸ برابر تبدیل می‌شود).
• پنجره ۲۸ روزه، آستانه ۱.۱۰: رشد‌های کمتر از ۰.۶۸٪ در روز نامرئی هستند (که در ۳۰ روز به ۱.۲۳ برابر تبدیل می‌شود).

آزمایش در شش دنیای مصنوعی

برای اثبات این نظریه، پژوهشگر شش «دنیای» مصنوعی را با استفاده از Python 3.13.5 (تنها با کتابخانه‌های استاندارد، به‌صورت آفلاین، بدون شبکه و بدون کلید API) ساخت و چهار نوع تشخیص‌دهنده متحرک را طی ۶۰ روز آزمایش کرد. برای حذف نویز ترافیکی، در هر دنیا تعداد دفعات اجرا به ۴۰ بار در روز محدود شد (که یک امتیاز مثبت برای داشبوردها بود). نتایج این آزمایش‌ها در دو اجرای جداگانه، بایت به بایت یکسان بودند (شاخص sha256 1772e695cb75f79d9e3f162ed4c49477a329703610cdf5ddff54cec2cc4da62a).

کف ورودی در لحظه ثبت (Pin Time) برابر با ۶۱,۰۶۰ بایت بود که از اجزای زیر تشکیل شده بود:

• JSON ابزارها: ۲۶,۰۰۰ بایت (محلی)
• پرامپت سیستمی (System Prompt): ۱۲,۰۰۰ بایت (محلی)
• دستورالعمل‌ها (CLAUDE.md): ۹,۰۰۰ بایت (محلی)
• ساختار پشتیبان (Harness Scaffold): ۶,۰۰۰ بایت (تأمین‌کننده)
• سرورهای MCP (الف و ب): هر کدام ۴,۰۰۰ بایت (محلی)
• زمان اجرا (Session ID 36B/Timestamp 24B): ۶۰ بایت (تغییرپذیر)

مقدار «کار» در هر اجرا به صورت یک توزیع لگ‌نرمال (میانه ۱۸,۰۰۰ بایت، سیگما ۰.۸) تولید شد که در یک فاکتور ترکیب شغلی روزانه (لگ‌نرمال، سیگما ۰.۱۵) ضرب می‌شد. این بدان معنا بود که یک اجرای معمولی ۸۶,۰۳۳ بایت بود و کف ورودی ۷۱.۰ درصد از کل درخواست را تشکیل می‌داد.

سپس شش مسیر مختلف شبیه‌سازی شد:

• کنترل (Control): هیچ تغییری نکرد. تمام تشخیص‌دهنده‌ها پاس شدند.
• رانش سریع (Creep): هر روز یک بخش سیاستی منحصربه‌فرد (۳۸۰ تا ۶۲۰ بایت) به CLAUDE.md اضافه شد؛ در روز ۱۴ یک سرور MCP سوم و در روز ۳۳ سرور چهارم اضافه شد و در روز ۴۰، ۱۲ طرح ابزار (Tool Schemas) اضافه گردید. نرخ رشد: ۱.۰۴۴٪+ در روز (رسیدن به ۱۱۲,۷۰۰ بایت). تشخیص‌دهنده‌ها تنها در روز ۴۰ و هنگام «پله‌ی» نصب طرح ابزارها هشدار دادند.
• رانش کند (Slowcreep): یک بخش سیاستی هر سه روز یک‌بار و یک سرور MCP در روز ۳۳ اضافه شد. نرخ رشد: ۰.۳۴۷٪+ در روز (رسیدن به ۷۴,۸۸۵ بایت، افزایش ۲۲.۶ درصدی). هر چهار تشخیص‌دهنده متحرک طی ۶۰ روز هیچ هشداری ندادند.
• ساختار (Harness): هیچ تغییری در فایل‌های محلی داده نشد. تأمین‌کننده (Vendor) ساختار پشتیبان را در روزهای ۱۲، ۳۱ و ۴۸ ارتقا داد.
• جهش (Spike): یک سند معماری ۴۰ کیلوبایتی در روز ۳۰ به CLAUDE.md اضافه شد. تمام هشدارها بلافاصله فعال شدند.
• حجم کاری (Workload): کف ثابت ماند، اما مقدار کار در هر اجرا (میانه ۱۸,۰۰۰ بایت) در روز ۳۰ دو برابر شد.

راهکار «لنگر یخ‌زده»

برای حل این مشکل، نویسنده ابزاری به نام drift_anchor_gate.py معرفی کرد. این ابزار خط مبنای متحرک را با یک «لنگر یخ‌زده» (Frozen Anchor) جایگزین می‌کند. این روش یک درخواست شاهد (Canary Request) قطعی را در روز صفر تثبیت می‌کند و هر اجرای بعدی را با این نقطه ثابت مقایسه می‌کند.

در دنیای «رانش کند»، در حالی که داشبوردهای متحرک دو ماه سکوت کردند، لنگر یخ‌زده در روز نهم با تلورانس ۲٪، رانش را شناسایی و مسدود کرد. نکته کلیدی این است که لنگر، فایل‌هایی را که توسعه‌دهنده به یاد می‌آورد لیست کند اندازه‌گیری نمی‌کند، بلکه «درخواست رندر شده» (Rendered Request) را می‌سنجد. همان‌طور که نویسنده اشاره می‌کند: «آنچه شما برایش پول می‌دهید، مخزن کد شما نیست، بلکه درخواست نهایی رندر شده است». این دقت در نظارت بر درخواست‌ها، به‌ویژه در سیستم‌های مقیاس‌پذیر حائز اهمیت است؛ مشابه آنچه در بررسی سازوکار دسته‌های عامل هوشمند برای اتوماسیون برای مدیریت جریان‌های کاری ۲۴ ساعته مشاهده می‌شود.

مالیات پنهان تامین‌کنندگان

یکی از تکان‌دهنده‌ترین یافته‌ها مربوط به دنیای «ساختار» بود. در این سناریو، هر فایل محلی بایت به بایت با روز صفر یکسان بود. اجرای diff -rq بین یک اسنپ‌شات روز صفر و روز ۵۹ هیچ تفاوتی نشان نداد و git diff کاملاً خالی بود. هش‌های SHA256 برای پرامپت‌های سیستمی و تنظیمات MCP یکسان ماندند (مثلاً CLAUDE.md روی مقدار 063d5a8a... باقی ماند).

با این حال، تأمین‌کننده هوش مصنوعی به طور بی‌صدا، ساختار پشتیبان (Saffold)—یعنی پیش‌درآمد پروتکل و پوشش‌های امنیتی—را سه بار طی ۶۰ روز افزایش داد:

• روز ۱۲: ۲,۶۰۰+ بایت
• روز ۳۱: ۳,۱۰۰+ بایت
• روز ۴۸: ۳,۴۰۰+ بایت

تا روز ۵۹، درخواست رندر شده ۱۴.۹ درصد بایت‌های بیشتری در کف داشت. تشخیص‌دهنده‌های متحرک تا روز ۵۸ سکوت کردند (۴۶ روز تأخیر و آن هم فقط پس از سومین افزایش)، در حالی که لنگر یخ‌زده اولین افزایش را در روز ۱۲ شکار کرد. این ثابت می‌کند هزینه‌ها حتی زمانی که کد توسعه‌دهنده ایستا است، افزایش می‌یابد.

نقاط قوت داشبوردها

نویسنده تصریح می‌کند که لنگر جایگزینی برای داشبوردهای متحرک نیست، بلکه مکمل آن‌هاست. لنگر در برابر «رشد حجم کاری» (Workload Growth) کور است؛ یعنی زمانی که محصول شما واقعاً کار بیشتری انجام می‌دهد، مانند بازگرداندن قطعات (Chunks) بیشتر در یک خط لوله RAG یا زمانی که کاربران ورودی‌های بزرگ‌تری را وارد می‌کنند.

در دنیای «حجم کاری»، داشبورد درست در روز ۳۰ هشدار داد (زمانی که حجم کار دو برابر شد)، در حالی که لنگر آن را تایید کرد چون کف ورودی رانش نیافته بود. اگر شما «جهش» و «حجم کاری» را در لاگ‌های استفاده در کنار هم ببینید، غیرقابل تشخیص هستند؛ هر دو شبیه به یک پرش هزینه به نظر می‌رساند. لنگر آن‌ها را از هم تفکیک می‌کند: با مسدود کردن چسباندن سند ۴۰ کیلوبایتی (رانش) و تایید افزایش فعالیت کاربر (حجم کاری).

جزئیات حیاتی پیاده‌سازی

برای اطمینان از اینکه گیت (Gate) در صورت بروز خطا «باز» نماند (fail open)، ابزار یک قرارداد خروجی سخت‌گیرانه را اجرا می‌کند. هرگونه فقدان اثر (Artifact) به جای کاهش هزینه، به عنوان یک «شکست ساختاری» تلقی می‌شود. این تصمیم به دلیل یک باگ قبلی بود که در آن یک خط مبنای صفر-بایتی باعث تقسیمی شد که نتیجه‌اش ۰.۰ گردید و منجر به یک PASS اشتباه برای ۲.۲۵ میلیون توکن شد.

• خروجی ۰ (PASS): رانش در محدوده تلورانس است، شاهد یخ‌زده است و هر فیلد اعلام شده موجود و غیرخالی است.
• خروجی ۱ (BLOCK): رانش از حد مجاز فراتر رفته است.
• خروجی ۲ (STRUCTURAL): ورودی غیرقابل استفاده است. این موارد را شامل می‌شود:
  • فیلدهای حذف شده: فیلدی (مثل tools_json) گم شده است. یک بررسی ساده بایت-محور این را به عنوان رانش ۴۲.۶٪- می‌بیند و PASS می‌دهد، اما لنگر خروجی ۲ می‌دهد.
  • فیلدهای صفر-بایتی: فیلدی (مثل mcp_b) حضور دارد اما رندر شده آن صفر بایت است.
  • فیلدهای ناشناخته: فیلدهای جدیدی (مثل mcp_c) ظاهر شده‌اند که در ثبت اولیه نبودند.
  • تغییر تسک: مقدار task_sha256 شاهد تغییر کرده است (یعنی شاهدی که خودش رانش کرده، دیگر شاهد نیست).
  • رانش متغیر: فیلدی که «تغییرپذیر» (volatile) علامت شده (مانند session_id) تغییر طول داده است (مثلاً از ۳۶ بایت به ۹۶ بایت).
  • مجموع غلط: مجموع فیلدهای فردی با مقدار کل rendered_bytes مطابقت ندارد.

اثر سهم کف ورودی

نامرئی بودن این رانش به «سهم کف» (Floor Share) بستگی دارد—یعنی چه مقدار از کل درخواست شما از پرامپت‌های ایستا در مقابل داده‌های دینامیک کاربر تشکیل شده است. پژوهشگر آزمایشی را اجرا کرد که در آن تشخیص‌دهنده w=7 در هر سطح کاری بر اساس آستانه «صفر-هشدار-اشتباه» خود کالیبره شد:

• سهم کف ۹۵.۸٪ (میانه کار ۲,۰۰۰ بایت): آستانه T=1.05. رانش را می‌بیند و از روز ۳۳ چهار هشدار می‌دهد.
• سهم کف ۸۹.۸٪ (میانه کار ۵,۰۰۰ بایت): آستانه T=1.05. رانش را می‌بیند و از روز ۱۲ شش هشدار می‌دهد.
• سهم کف ۸۱.۸٪ (میانه کار ۱۰,۰۰۰ بایت): آستانه T=1.15. باند کور ۴.۰۷٪ در روز است. صفر هشدار در رانش کند.
• سهم کف ۷۱.۷٪ (میانه کار ۱۸,۰۰۰ بایت): آستانه T=1.15. باند کور ۴.۰۷٪ در روز است. صفر هشدار در رانش کند.
• سهم کف ۵۹.۲٪ (میانه کار ۳۰,۰۰۰ بایت): آستانه T=2.00. باند کور ۲۱.۹۰٪ در روز است. صفر هشدار در رانش کند.
• سهم کف ۴۱.۷٪ (میانه کار ۶۰,۰۰۰ بایت): آستانه T=2.00. باند کور ۲۱.۹۰٪ در روز است. صفر هشدار در رانش کند.

در سهم کف ۹۰ درصد و بالاتر، داشبورد می‌تواند رانش را شناسایی کند. اما برای اکثر عامل‌ها، هرچه حجم کاری نویزی‌تر باشد، آستانه باید بالاتر رود تا سکوت کند، و این یعنی درِ ورود برای رانش‌های خاموش بازتر می‌شود. یک بررسی ثانویه روی نویز روزانه (سیگما از ۰.۰۵ تا ۰.۲۵) نشان داد که تنها در سطح بسیار آرام (سیگما ۰.۰۵)، داشبورد توانست یک هشدار در رانش کند در روز ۳۶ بگیرد—یعنی ۲۷ روز بعد از اینکه لنگر آن را مسدود کرده بود.

ملاحظاتی درباره کشینگ و تثبیت

یک اعتراض این است که کشینگ (Caching) این موضوع را بی‌اهمیت می‌کند. در حالی که یک پیشوند (Prefix) پایدار قابل کش است و خواندن آن ارزان‌تر از نوشتن است، کشینگ تنها «سطح» هزینه را تغییر می‌دهد، نه «نسبت» رانش. کف همچنان رشد می‌کند و هزینه رانش در هر فراخوانی پرداخت می‌شود. علاوه بر این، ویرایش یک فایل دستورالعمل، پیشوند کش را باطل می‌کند، به این معنی که هر به‌روزرسانی «رانش کند» باعث می‌شود یک نوشتن کامل کش (Cache Write) اتفاق بیفتد و هزینه را تشدید کند. به زبان ساده، رانش کند یک اتفاق «ارزان» است که مکرراً کش شما را دور می‌ریزد.

در مورد نگهداری لنگر، نویسنده سیاست «ثبت مجدد» (Re-pinning) سخت‌گیرانه‌ای را پیشنهاد می‌کند. وقتی یک تغییر مشروع رخ می‌دهد (مثلاً سرور MCP جدید)، ثبت مجدد باید بازتاب‌دهنده رانش تجمعی از زمان ثبت اولیه در روز صفر باشد. این کار تضمین می‌کند توسعه‌دهنده‌ای که تغییری را تایید می‌کند، ببیند که کف ورودی اکنون مثلاً «۴۷٪ بالاتر از جایی است که در مارس بود»، نه اینکه فقط «۴٪ بالاتر از هفته پیش است». این امر از تبدیل شدن فرآیند ثبت مجدد به یک خط مبنای متحرک دیگر جلوگیری می‌کند.

برای اجرای این روش در یک روز دوشنبه، نویسنده توصیه می‌کند درخواست رندر شده برای یک تسک قطعی و یخ‌زده را استخراج کرده و تعداد بایت‌ها و هش‌ها را به عنوان لنگر ذخیره کنید. یک مرحله در CI اضافه کنید که آن تسک را مجدداً رندر کرده و با تلورانسی نزدیک به ۲٪ (برای تغییرات جزئی در رشته‌های نسخه) مقایسه کند و اگر رانش رخ داد، بیلد را متوقف کند. این روش در ترکیب با یک داشبورد استاندارد برای جهش‌ها و حجم کاری، شکافی را می‌پوشاند که اجازه می‌دهد رانش هزینه در معرض دید همگان پنهان بماند.

گام بعدی شما

• یک درخواست شاهد (Canary) برای عامل خود تعریف کنید و تعداد بایت‌های رندر شده آن را ذخیره کنید.
• یک تست ساده در خط لوله CI/CD اضافه کنید تا تغییرات غیرمنتظره در حجم پرامپت‌های سیستمی را شناسایی کند.
• تفکیک دقیق هزینه‌های مربوط به «کف ورودی» و «حجم پردازشی» را در داشبورد خود پیاده کنید.

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