معماری لایه‌ی دروازه؛ راهکار جلوگیری از تخلیهٔ سریع بودجه در عامل‌های هوش مصنوعی

یک حلقهٔ تکرارشوندهٔ بدون نظارت در یک عامل خودگردان می‌تواند در کمتر از یک ساعت، ۱۰ هزار دلار از اعتباری یک کلید API شرکتی را ببلعد. طبق بررسی‌های فنی منتشرشده در ۳ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، مکانیزم‌های کنترل هزینه در چارچوب‌هایی مثل CrewAI، LangChain و حلقه‌های فراخوانی ابزار OpenAI از نظر معماری دارای نقص هستند.

اکثر تیم‌های توسعه از نظارت واکنشی استفاده می‌کنند؛ برای مثال در LangChain از تابع get_openai_callback() بهره می‌برند. این روش توکن (Token) — یعنی تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — را پس از تکمیل درخواست شبکه رصد می‌کند. یعنی زمانی که سیستم هشدار بودجه صادر می‌کند، بدهی به ارائه‌دهندهٔ مدل زبانی بزرگ (LLM) — شبیه کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — پیش‌تر ثبت شده است. این دقیقاً مثل این است که بخواهید یک خرید تک‌پایه و افراطی را با نگاه کردن به صورت‌حساب بانکی، آن هم بعد از تایید تراکنش، متوقف کنید.

همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، جداسازی لایه‌های دسترسی حیاتی است. برای جلوگیری از «منع سرویس مالی» (FDoS)، مهندسان باید مرز محدودیت‌ها را به بیرون از حلقهٔ اجرای عامل منتقل کنند. این ضرورت مدیریتی را پیش‌تر در بررسی ابزار Runcap برای کنترل هزینه‌های استنتاج نیز تحلیل کرده بودیم که بر اهمیت توقف سخت عملیات تأکید داشت. بر اساس مستندات dev.to، این کار مستلزم ایجاد یک محیط مالی مجزا است که در آن دروازهٔ پرداخت، پیش از ارسال هر درخواست، موجودی را بررسی کند.

معماری لایه‌ی دروازه (Gateway)

این رویکرد قطعی بر اساس محورهای زیر عمل می‌کند:

• دروازهٔ هزینه پیش از فراخوانی: بررسی مجوزها و موجودی کیف پول پیش از ارسال درخواست. این استراتژی مشابه رویکردی است که پلتفرم Bifrost برای کاهش هزینه‌ها از طریق مدیریت نقطه انتهایی به کار گرفت.
• توقف اجرای عملیات: اگر سقف بودجه ۵ دلار باشد، هر درخواستی که موجودی را به ۵.۰۱ دلار برساند، در سطح دروازه به‌صورت فیزیکی مسدود می‌شود.
• ردپای بازرسی: استفاده از لاگ‌های زنجیره‌ای با هش SHA-256 برای اطمینان از عدم دست‌کاری داده‌های هزینه.

به گزارش ZDNET و به نقل از دیوید گوورتز، تعیین سقف‌های سخت (Hard Limits) و محدودیت نرخ درخواست (Rate Limits)، لایه‌های حفاظتی حیاتی هستند. در حالی که هشدارها فقط دید ایجاد می‌کنند، تنها سقف‌های سخت می‌توانند کابوس‌های صورت‌حساب ناشی از عامل‌های خارج از کنترل در محیط عملیاتی را متوقف کنند. از سوی دیگر، باید توجه داشت که بسیاری از این خطاهای اجرایی با مکانیزم‌های خودترمیمی قابل جبران هستند، اما مدیریت مالی باید پیش از هر هرگونه ترمیم، تضمین شود.

این تغییر، گذاری از «پایش» به «اجبار» است. توسعه‌دهندگان باید هزینه API را نه به عنوان یک جزئیات حسابداری، بلکه به عنوان یک آسیب‌پذیری امنیتی ببینند. با جدا کردن کلیدهای شرکتی از زمان اجرای عامل، ریسک تخلیهٔ فاجعه‌بار کارت‌های اعتباری بر اثر تزریق پرامپت (Prompt Injection) یا خطاهای تجزیه (Parsing) از بین می‌رود.

گام بعدی شما

• بررسی کنید که آیا محدودیت‌های بودجهٔ شما در داخل زمان اجرا (Runtime) است یا در لایهٔ میان‌افزار شبکه.
• پیاده‌سازی نسخهٔ مینیمال این معماری را با استفاده از پروژه valta-audit-chain در گیت‌هاب آزمایش کنید.
• سقف‌های سخت (Hard Caps) را جایگزین هشدارهای ایمیلی کنید.

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