اگر امروز یک عامل هوش مصنوعی میسازید که «روی کلید API من کار میکند»، احتمالاً در حال مدیریت یک پروژه نیستید، بلکه صرفاً یک صورتحساب پنهان را به تعویق انداختهاید. حقیقت این است که هر عامل (Agent) که نتواند رسید هزینههای خود را ارائه دهد، در واقع یک چک سفید است که هر لحظه میتواند حساب بانکی شما را تخلیه کند.
به گزارش dev.to در مقالهای که در ۲۳ سپتامبر ۲۰۲۶ منتشر شد، بسیاری از توسعهدهندگان از کوپنهای ابری یا کارتهای اعتباری شخصی برای تست مدلها استفاده میکنند و همین موضوع، هزینه واقعی حلقههای بازگشتی را میپوشاند. در دنیای عاملهای هوش مصنوعی، وقتی یک مدل میتواند بهطور متوالی جستوجو کند، بخواند و کد بزند، هزینه اصلی نه در پرامپت اولیه، بلکه در خودِ این حلقه است. همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، نبودِ یک سقف سخت برای هزینهها، یعنی تبدیل کردن هوش مصنوعی به ابزاری که بدون محدودیت منابع مصرف میکند. این چالش دقیقاً با برخی باورهای غلط درباره توسعه عاملها مرتبط است که در نهایت منجر به ایجاد بدهیهای فنی خطرناک میشوند.
این رویکرد جدید بر پایه یک معماری «بستن در صورت خطا» (fail-closed) بنا شده است. در این سیستم، عامل هوش مصنوعی — شبیه به یک حسابدار سختگیر که قبل از هر خرید، موجودی کیف پول را چک میکند — اگر ببیند تراکنش بعدی مجموع هزینهها را از حد مجاز میگذرد، از اجرای آن خودداری میکند. این با لیستهای مجاز (allowlist) متفاوت است؛ لیست مجاز میپرسد «آیا این ابزار اجازه اجرا دارد؟»، اما سقف هزینه میپرسد «حتی اگر اجازه داشته باشد، آیا بودجهای برای این واحد هزینه باقی مانده است؟»
برای پیادهسازی این سیستم، چهار فایل حیاتی تعریف شده است:
- spend-cap.json: قراردادی که بودجه کلی و هزینه هر اقدام را تعیین میکند.
- ledger.ndjson: دفتر کلی که هر فراخوانی مدل یا ابزار را بهصورت خطبهخط ثبت میکند.
- agent.mjs: اجراکنندهای که در صورت عبور از سقف هزینه، عملیات را متوقف میکند.
- grade.mjs: ابزار ارزیابی که صحت محاسباتی دفتر کل را بررسی میکند.
در این چارچوب، هزینهها با «توکنهای آزمایشگاهی» سنجیده میشوند تا تمرکز از «استفاده از مدل ارزانتر» به «محدود کردن رفتار عامل» منتقل شود. برای مثال، اگر سقف هزینه ۸۰۰۰ واحد باشد و هر فراخوانی مدل ۴۰۰ واحد هزینه داشته باشد، عاملی که ۲۰ بار در یک حلقه تکرار شود، پیش از آنکه بتواند «باهوش» شود، به سقف برخورد کرده و متوقف میشود. این امر توسعهدهنده را مجبور میکند منطق عامل را بهینه کند، نه اینکه به قدرت خام یک کلید API با سقف بالا تکیه کند. این رویکرد در واقع پاسخی به این نیاز است که بودجهی حلقهها به عنوان معیار اصلی در سنجش مهارت توسعهدهندگان قرار گیرد.
طبق مستندات این آزمایشگاه، دفتر کل (ledger) اصلیترین اثرِ کار است. اگر فایل ledger.ndjson حذف شود یا حتی یک خط از آن با فرمت JSON سازگار نباشد، کل پروژه نمره صفر میگیرد. نویسنده صراحتاً تأکید میکند که «دفتر کلی را که تقریباً درست باشد، نمیپذیرم». هر ورودی باید شامل برچاس زمانی، نوع عملیات، گام اجرایی، واحد هزینه و مجموع هزینههای جاری باشد.
سه شرط بحرانی وجود دارد که منجر به شکست فوری پروژه میشود:
۱. فقدان دفتر کل: نبود فایل یا خالی بودن آن.
۲. ابزارهای بدون قیمت: استفاده از هر ابزاری که در فایل سقف هزینه تعریف نشده است (مثلاً ابداع یک ابزار shell بدون قیمت).
۳. خطاهای محاسباتی: هرگونه عدم تطابق بین مجموع واحدها و مقدار running_total.
برای حذف شکاف مالی بین دانشجویان (کسانی که حسابهای شرکتی دارند در برابر کسانی که از طرحهای رایگان استفاده میکنند)، استفاده از MonkeyCode پیشنهاد شده است. این ابزار دسترسی رایگان به مدلها و محیط سرور مشترک را فراهم میکند تا معیار ارزیابی برای همه یکسان باشد. همچنین برای جلوگیری از تداخل دادهها در سرورهای مشترک، هر کاربر باید یک فضای نام (namespace) اختصاصی داشته باشد تا شواهد اجراییاش توسط دیگران پاک نشود. این نوع جداسازی محیطی برای دستیابی به تکرارپذیری، یادآور بحث تثبیت سختافزاری در برابر تاریخچه چت است تا از خطاهای تصادفی در بررسی عملکرد عامل جلوگیری شود.
از نظر فنی، توسعهدهندگان باید از Node 20 به بالا استفاده کنند و ابتدا سقف هزینه را بنویسند و سپس عامل را طراحی کنند. در واقع سقف هزینه، «مشخصات فنی» (specification) است و عامل چیزی است که باید در برابر این مشخصات تسلیم شود.
برای کسب نمره قبولی، پنج نقطه بازرسی ضروری است:
- اعتبارسنجی سقف: مثبت بودن اعداد و فعال بودن حالت fail-closed.
- ردیف صادقانه: تولید حداقل یک خط فراخوانی مدل که توسط ارزیاب تأیید شود.
- دموی توقف: ایجاد یک وضعیت که در آن عامل به سقف برخورد کرده و خطای سیستم را صادر کند.
- زیرمجموعه ابزارها: اطمینان از اینکه تمام ابزارهای استفاده شده در فایل سقف تعریف شدهاند.
- مجموع یکنواخت: بررسی اینکه مجموع هزینهها بهصورت صعودی و دقیق ثبت شده باشد.
سیستم نمرهدهی بهصورت باینری (صفر یا صد) است تا از «میانگینگیری برای قبولی» جلوگیری شود. برای اثبات مکانیزم توقف، کاربر باید علاوه بر دفتر کل، فایلی به نام trip.txt ارائه دهد که حاوی متن «spend trip» در خروجی خطا (stderr) باشد.
برای کسانی که در سطح پایه موفق شدهاند، اهداف پیشرفتهتری تعریف شده است:
- تخمینگرهای پیشاجرا: افزودن پرچمی که مجموع هزینه احتمالی را بدون ثبت در دفتر کل چاپ کند.
- سقفهای تفکیکی: محدود کردن تعداد دفعات فراخوانی یک ابزار خاص (مثلاً حداکثر ۳ بار برنامهریزی).
- بازپخش دفتر کل: توانایی بازسازی خط زمانی عملیات تنها با استفاده از فایل ledger.
- تعویض آداپتور: تغییر ارائهدهنده مدل در حالی که وزن هزینههای آزمایشگاهی ثابت بماند.
البته باید توجه داشت که این سیستم یک ابزار آموزشی است و برای خط لولههای پرداخت تجاری طراحی نشده است. این مدل مواردی مثل توکنهای استریمینگ، کش پرامپتها یا هزینههای پنهان در SDKهای سازندگان را محاسبه نمیکند. ارزش واقعی این تمرین در شناسایی «باگهای جالب» است؛ همان جایی که عامل برای بار دوم برنامهریزی میکند یا یک وصله (patch) را دو بار اعمال میکند.
در نهایت، برای قبولی، توسعهدهنده باید به سه پرسش کلیدی پاسخ دهد: عامل در کدام خط دفتر کل متوقف شد؟ از افزودن کدام ابزار بدون قیمت خودداری کردید و چرا؟ و اگر سقف هزینه نصف میشد، کدام گام ابتدا حذف میشد؟
این تغییر در رویکرد، فرض بنیادی توسعه عاملهای هوش مصنوعی را تغییر میدهد. ما از «بودجهبندی بر اساس حس» (vibe-based budgeting) — که در آن توسعهدهنده امیدوار است بودجهاش تمام نشود — به سمت یک سیستم حسابداری دقیق حرکت میکنیم که در آن اجراکننده، همان حسابدار اصلی است.
گام بعدی شما
- در پروژههای فعلی خود، یک فایل JSON برای تعریف قیمت هر ابزار (Tool) ایجاد کنید.
- یک لایه میانی (Middleware) بنویسید که قبل از هر فراخوانی API، مجموع هزینههای جاری را با سقف تعیینشده مقایسه کند.
- برای هر اجرای عامل، یک فایل
.ndjsonمحلی ایجاد کنید تا تاریخچه هزینهها را برای تحلیلهای بعدی ذخیره نمایید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو