سهم عامل هوش مصنوعی را پیش از خرج‌کردن رزرو کنید

هشت عامل هوش مصنوعی برای خرید گزارش و استفاده از ابزارهای پولی یک بودجه مشترک دارند. ساعت ده صبح، مانده ۹۰۰ دلار است. پنج عامل تقریباً هم‌زمان مانده را می‌خوانند؛ هرکدام خریدی ۲۵۰ دلاری را مجاز می‌بینند و درخواستش را می‌فرستد. هیچ خریدی به‌تنهایی از سقف هر اقدام عبور نکرده، اما تعهد تازه به ۱۲۵۰ دلار رسیده است.

هشدار داشبورد بعدتر می‌رسد. هر عامل هم می‌تواند نشان دهد که مانده را بررسی کرده است. هیچ‌یک پول ازدست‌رفته را برنمی‌گرداند.

پرسش عملی این است: این اقدام مشخص اکنون اجازه خرج دارد، باید ابتدا از بودجه سهم بگیرد، به تأیید مقید نیاز دارد یا باید رد شود؟ اگر سقف تجمعی دارید، پیش از رسیدن درخواست به نقطه تعهد بیرونی، بیشینه زیان معتبر آن را به‌صورت اتمیک رزرو کنید. گزارش هزینه شاهد خرج است؛ مجوز خرج نیست.

این مطلب چارچوب مهندسی و کنترلی است، نه مشاوره حسابداری، پرداخت یا حقوقی. رویه ارز، مالیات، تدارکات، شبکه پرداخت و اختیار تأیید به سازمان و حوزه قضایی وابسته است.

سه معنای متفاوت بودجه را یکی نگیرید

برنامه مالی می‌گوید سازمان قصد دارد چقدر خرج کند. پایشگر، هزینه ثبت‌شده یا برآوردی را با آن برنامه می‌سنجد. مانده مجوز اما باید همان لحظه پاسخ دهد که آیا یک تعهد تازه پذیرفتنی است یا نه.

فقط مورد سوم باید در مسیر هم‌زمان یک اقدام پیامددار قرار گیرد. دو مورد نخست برای پیش‌بینی، تخصیص هزینه، کشف ناهنجاری و پاسخ‌گویی ضروری‌اند؛ اما معمولاً پس از شروع مصرف به‌روز می‌شوند و دامنه‌شان با تصمیم تجاری عامل یکی نیست.

راهنمای رسمی AWS Budgets صریح است: میان مصرف منبع، ثبت هزینه و ارسال هشدار تأخیر وجود دارد و مبلغ می‌تواند پیش از اطلاع از آستانه عبور کند. سقف خرج Google Cloud کنترل قوی‌تری را برای بعضی سرویس‌ها در مرحله پیش‌نمایش ارائه می‌کند، اما آن هم بی‌درنگ اعمال نمی‌شود؛ درخواست‌های در حال اجرا کامل می‌شوند، بعضی هزینه‌های ثابت ادامه دارند و اضافه‌هزینه ناشی از تأخیر گزارش وصول می‌شود. این ابزارها شعاع زیان را کم می‌کنند؛ ثابت نمی‌کنند یک سفارش، فراخوانی یا خرید واگذارشده هنگام تعهد در حدود اختیار تجاری بوده است.

منابع معتبر چه می‌گویند و تحلیل ژرف کجا آغاز می‌شود

اصل پایه، کمترین اختیار است. فهرست کنترل‌های NIST SP 800-53 کنترل‌هایی برای کمترین اختیار، تفکیک وظایف، مجوز، حسابرسی و محدودکردن استفاده ارائه می‌کند. این سند انعطاف‌پذیر است و معماری خرج عامل را تجویز نمی‌کند.

راهنمای اختیار بیش‌ازحد در OWASP ریشه اقدام زیان‌بار را در قابلیت، دسترسی یا خودمختاری بیش‌ازحد می‌بیند و محدودکردن ابزار و اقدام پراثر را توصیه می‌کند. محدودیت نرخ ممکن است زیان را کوچک کند، اما نمی‌فهمد ده خرید جداگانه چگونه یک سقف پولی مشترک را مصرف می‌کنند.

دو سامانه غیرمالی سازوکار مفیدی نشان می‌دهند. ResourceQuota در Kubernetes مصرف تجمعی را دنبال می‌کند و درخواست ناقض حد سخت را پیش از پذیرش رد می‌کند. مستندات تراکنش‌های سریال‌پذیر PostgreSQL توضیح می‌دهد که اثر تراکنش‌های هم‌زمان موفق باید با یک ترتیب تک‌به‌تک سازگار باشد؛ ناسازگاری به شکست سریال‌سازی می‌رسد و برنامه باید آن را مدیریت کند. هیچ‌کدام سیاست مالی شما را تعریف نمی‌کنند. دو ویژگی لازم را نشان می‌دهند: رد پیش از پذیرش و حفاظت از یک ناوردای مشترک در رقابت هم‌زمان.

واقعیت تأییدشده: منابع بالا محدودیت گزارش هزینه، پذیرش سخت، کمترین اختیار و تضمین هم‌زمانی را همراه قیدهایشان مستند کرده‌اند. تحلیل ژرف: این اجزا باید در یک خدمت مستقل مجوز خرج جمع شوند تا پیش از دسترسی عامل به عرضه‌کننده یا درگاه پرداخت، ظرفیت را رزرو کند. این «دفتر رزرو» یک الگوی پیاده‌سازی است؛ استاندارد تازه یا تضمین ایمنی با انتخاب یک پایگاه داده نیست.

نخست بگویید چه چیزی خرج محسوب می‌شود

خرج فقط پرداخت کارت نیست. توکن مدل، جست‌وجوی پولی، رایانش ابری، ثبت سفارش، بازپرداخت به مشتری یا قراردادی با حداقل تعهد آینده همگی اثر اقتصادی می‌سازند. بعضی ابزارهای ظاهراً عملیاتی نیز منبع تازه ایجاد می‌کنند یا سرویس گران‌تری را فعال می‌سازند.

برای هر رده اقدام، این قرارداد را بنویسید:

مطلب قرارداد کمیت برای واحد، ارز و گردکردن توضیح می‌دهد چرا یک عدد عریان برای تصمیم کافی نیست. مدل نباید قیمت نمایشی را خودش به مبلغ مجاز تبدیل کند. کد قطعی باید واحد خرد پول، تعداد، مالیات و حاشیه محدود را محاسبه کند.

چهار سرنوشت برای هر درخواست تعیین کنید

موتور سیاست یکی از این چهار پاسخ را برگرداند:

1. رد: اقدام، مبلغ، عرضه‌کننده، هدف، مقصد یا شاهد بیرون سیاست است.
2. نیازمند تأیید: فرد واجد صلاحیت باید همین شرایط مادی را ببیند؛ تأیید کلی به درخواست تازه منتقل نمی‌شود.
3. رزرو: ظرفیت موجود است و برای این نیت تغییرناپذیر نگه داشته می‌شود، اما تعهد بیرونی هنوز رخ نداده است.
4. تعهد در محدوده رزرو: اقدام با رزرو زنده‌ای که دامنه و بیشینه مبلغ را پوشش می‌دهد اجرا می‌شود.

«هشدار» پاسخ پنجم نیست؛ داده پایش است. «از مدل بخواه دوباره فکر کند» هم یک فراخوانی دیگر مدل است. این دو شاید رفتار را بهتر کنند، اما ظرفیت مشترک را حفاظت نمی‌کنند.

عامل فقط پاکت اقدام را پیشنهاد دهد. جزء مورد اعتماد، قیمت را قطعی، سیاست را بررسی، بودجه را رزرو و اقدام را اجرا کند. راهنمای کمترین دسترسی برای ابزار عامل مرز قابلیت را پوشش می‌دهد؛ درگاه خرج، ناوردای تجمعی را به آن اضافه می‌کند.

پاکت بودجه را تصمیم‌کامل بسازید

عبارت «ماهانه پنج‌هزار دلار برای عامل» مبهم است. رکورد باید مالک، منبع تأمین، عامل و کارگردان، مستأجر، گردش‌کار، هدف، اقدام‌های مجاز، عرضه‌کنندگان، مقصدها، ارز و بازه دقیق را داشته باشد. سقف هر اقدام، سقف تجمعی، آستانه تأیید، مبلغ متعهد، مبلغ رزروشده، مهلت رزرو، قاعده آزادسازی، اضافه‌خرج و رفتار زمان خرابی نیز لازم‌اند.

محدودیت‌های هم‌پوشان را حفظ کنید. یک خرید ممکن است هم‌زمان بودجه عامل، گردش‌کار، تیم، عرضه‌کننده و سقف اضطراری کل سازمان را مصرف کند. مجوز انسان سقف بالادستی را بزرگ نمی‌کند، مگر همان فرد اختیار جداگانه و ثبت‌شده‌ای برای اصلاح آن سقف داشته باشد. محدودکننده‌ترین نتیجه را اعمال کنید.

مرز زمانی را مبهم نگذارید. «روزانه» باید منطقه زمانی و رفتار تغییر ساعت را مشخص کند. با اصلاح سیاست، معنای رزروهای باز را پنهانی عوض نکنید. نسخه تازه بسازید و برای انتقال یا انقضای رزرو قبلی قاعده صریح داشته باشید.

رزرو باید در مرز اثر اتمیک باشد

ناوردای اصلی این است:

مبلغ متعهد + رزروهای زنده + بیشینه درخواست <= سقف

بررسی شرط و نوشتن رزرو باید یک عمل اتمیک روی همه مانده‌های مربوط باشد. اگر برنامه ابتدا available را بخواند، بیرون تراکنش تصمیم بگیرد و بعد بنویسد، در رقابت باز می‌شود. کش، پایگاه برداری یا متن ورودی مدل مرجع اختیار نیست.

تراکنش سریال‌پذیر فقط یک گزینه است. قفل صریح، مقایسه و جابه‌جایی نسخه‌دار یا دفتر توزیع‌شده با سازگاری قوی هم می‌تواند مناسب باشد. انتخاب به بار و الگوی خرابی بستگی دارد؛ قرارداد ثابت است: دو درخواست هم‌زمان نباید یک واحد مانده را دوبار خرج کنند. تعارض نسخه یا شکست سریال‌سازی، تلاش ردشده‌ای است که فقط با حالت تازه دوباره بررسی می‌شود؛ مجوز دورزدن دفتر نیست.

درگاه را تا جای ممکن به تعهد بیرونی نزدیک کنید. اگر عامل بتواند مستقیماً ابزار پولی را صدا بزند، کنترل صرفاً توصیه است. پس از رزرو، یک قابلیت کوتاه‌عمر و تک‌نیت صادر کنید یا اجرای عمل را به کارگزار بسپارید. الگوی دسترسی کوتاه‌عمر عامل اینجا هم صدق می‌کند: اختیار باید محدود، وابسته به کار و پس از انقضا بی‌استفاده باشد.

پیشنهاد، رزرو، تعهد و تسویه را جدا ثبت کنید

یک پرچم «خرج شد» نمی‌تواند واقعیت را نشان دهد. چرخه به حالت‌های جدا نیاز دارد:

• پیشنهادشده: قیمت‌گذاری شده، اما چیزی نگه نمی‌دارد؛
• رزروشده: بیشینه زیان تا مهلت معین نگه داشته شده است؛
• ارسال‌شده: سامانه بیرونی نیت را گرفته، ولی نتیجه شاید هنوز نامعلوم باشد؛
• متعهد: رسید سفارش، مصرف یا مجوز پرداخت وجود دارد؛
• تسویه‌شده: مبلغ نهایی روشن است؛
• آزادشده: سهم استفاده‌نشده پیش از تعهد برگشته است؛
• منقضی: مهلت بدون ارسال پایان یافته است؛
• نیازمند تطبیق: حالت داخلی و بیرونی ناسازگار یا نامعلوم مانده است.

هر گذار شناسه رویداد تغییرناپذیر می‌خواهد. کلید یکتایی نیز باید به پارامترهای معیارشده نیت متصل باشد. پایان مهلت پس از ارسال، شکست پاک نیست؛ عرضه‌کننده شاید درخواست را پذیرفته باشد. مطابق راهنمای تلاش دوباره و جلوگیری از اثر تکراری، پیش از ارسال دوباره با مرجع پایدار از سامانه بیرونی استعلام بگیرید و فقط به‌دلیل گم‌شدن پاسخ شبکه، رزرو جدید نسازید.

برآورد را با بیشینه زیان اشتباه نگیرید

هزینه نهایی معمولاً همان قیمت اولیه نیست. ورودی ذخیره‌نشده، طول خروجی، فراخوانی ابزار، فضای ذخیره، مسیر منطقه‌ای و تلاش دوباره هزینه مدل را تغییر می‌دهد. سفارش هم ممکن است مالیات، حمل، کارمزد، انعام، تسویه بخشی یا نوسان ارز داشته باشد.

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

مستندات رسمی کنترل خرج Stripe Issuing نمونه‌ای واقعی از کنترل لایه‌ای و محدودیت آن است: کنترل پیش از مجوز پرداخت اجرا می‌شود، مبلغ در واحد خرد ارز کارت است، تجمیع ممکن است عقب بماند و کارمزد دیررس از سقف عبور کند. راهنمای مجوز هم‌زمان Stripe تصمیم پذیرش یا رد و امکان نگه‌داشتن مبلغ را نشان می‌دهد؛ رفتار پایان مهلت هم باید از پیش تعیین شود. کنترل عرضه‌کننده را مرز دوم بدانید، نه جایگزین سیاست هدف، گردش‌کار و بودجه چندابزاری سازمان.

تأیید انسان را به شرایط و رزرو گره بزنید

بازبین باید عرضه‌کننده، قلم، تعداد، ارز، بیشینه زیان، شاهد، مقصد، تعهد تکرارشونده، مانده پس از رزرو و زمان انقضا را ببیند. تأیید را با شناسه تغییرناپذیر یا امضای مناسب به همین شرایط و شناسه رزرو وصل کنید.

با تغییر مبلغ، فروشنده، تعداد، مقصد، هدف، نسخه سیاست یا شاهد مادی، تأیید قبلی باطل و قیمت دوباره محاسبه شود. تصویر صفحه‌ای با واژه «تأیید شد» اختیار قابل استفاده مجدد نیست. ظرفیت هم باید هنگام تأیید حفاظت شده باشد؛ وگرنه دو بازبین می‌توانند دو خرید را مجاز بدانند که در لحظه نمایش هرکدام جا داشته است.

در اقدام پراثر، پیشنهاددهنده، تأییدکننده، اجراکننده و تطبیق‌دهنده را تا جای عملی مستقل نگه دارید. مطلب تفکیک وظایف برای هوش مصنوعی نشان می‌دهد چند پیام یا چند عامل در یک حوزه کنترل، نظارت مستقل نمی‌سازد.

مثال عملی خرید هم‌زمان گزارش تأمین‌کنندگان

یک گردش‌کار خرید برای گزارش‌های پولی سقف هفتگی ۱۰۰۰ دلار، سقف ۳۰۰ دلار برای هر اقدام و سقف ۶۰۰ دلار برای هر عرضه‌کننده دارد. شش عامل تأمین‌کنندگان متفاوت را بررسی می‌کنند. سه عامل هم‌زمان گزارش‌های ۲۵۰ دلاری یک شرکت را می‌خواهند.

درگاه، مبلغ‌ها را به واحد خرد دلار تبدیل و شناسه قلم و هدف را بررسی می‌کند. سپس مانده گردش‌کار و عرضه‌کننده را در یک تراکنش می‌بندد. دو رزرو نخست موفق‌اند. سومی زیان عرضه‌کننده را به ۷۵۰ دلار می‌رساند و رد می‌شود، هرچند هنوز ۵۰۰ دلار در بودجه کل گردش‌کار مانده است. مدیر می‌تواند منبع دیگری برگزیند؛ بدون اختیار اصلاح سقف عرضه‌کننده، تأیید دستی راه عبور نیست.

یکی از درخواست‌های بیرونی پس از ارسال به پایان مهلت می‌خورد. رزرو ۲۵۰ دلاری در حالت «ارسال‌شده» می‌ماند. استعلام با مرجع بیرونی، مجوز ۲۳۰ دلاری را تأیید می‌کند؛ دفتر ۲۳۰ دلار را متعهد و ۲۰ دلار را آزاد می‌کند. گزارش دوم با مالیات ۲۵۸ دلار تسویه می‌شود. پس ۲۵۰ دلار بیشینه معتبری نبوده است؛ رویداد به تطبیق می‌رود و پیش از خودکارشدن دوباره این قلم، قاعده قیمت اصلاح می‌شود.

مدل تشخیص داده کدام گزارش مفید است؛ جزء قطعی تصمیم گرفته این خرید مشخص در همه سقف‌های زنده جا می‌شود یا نه.

ناوردا را زیر فشار بیازمایید

مانده را نزدیک صفر بگذارید و درخواست‌های فراوان را هم‌زمان بفرستید. ثابت کنید مجموع تعهد و رزرو پذیرفته‌شده هیچ سقفی را نمی‌شکند. تعارض پایگاه داده، مرگ کارگر، پیام تکراری، تأخیر رسید، پایان مهلت عرضه‌کننده، تسویه دیررس، برگشت بخشی، انقضای رزرو، اختلاف ساعت و اصلاح بودجه را تزریق کنید.

این سنجه‌ها مفیدند:

• تعداد پذیرش، رد، انقضا و نیاز به تأیید به تفکیک دلیل؛
• اوج مجموع تعهد و رزرو نسبت به هر سقف؛
• عمر رزرو و سهم رزرو بی‌صاحب؛
• خطای برآورد تا تسویه به تفکیک اقدام، فروشنده، ارز و مسیر مدل؛
• نتیجه بیرونی نامعلوم و زمان رسیدن به تطبیق؛
• تلاش تکراری مسدودشده با کلید یکتایی؛
• تأیید باطل‌شده پس از تغییر شرایط؛
• خرج بیرون کارگزار یا بدون رسید رزرو.

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

شکست‌ها و هزینه واقعی کنترل را ببینید

• شمردن در مدل: عامل‌ها حالت کهنه دارند و ممکن است خطا کنند یا دست‌کاری شوند.
• فقط سقف هر درخواست: انبوه خرید کوچک از کنترل اقدام بزرگ عبور می‌کند.
• هشدار دیررس: برای حاکمیت مفید است، برای مجوز هم‌زمان دیر می‌رسد.
• نشت رزرو: مهلت بلند کار مفید را می‌بندد؛ مهلت کوتاه وسط اقدام معتبر تمام می‌شود.
• عبور هنگام خرابی: دسترس‌پذیری با رهاکردن ناوردای مالی حفظ می‌شود.
• توقف هنگام خرابی: زیان مهار می‌شود، اما کار فوری می‌خوابد؛ مسیر اضطراری مستقل لازم است.
• برآورد سست: رزرو کم اضافه‌خرج می‌سازد و رزرو افراطی کار درست را رد می‌کند.
• یک قفل جهانی: فهم درستی ساده است، ولی توان عملیاتی و شعاع خرابی بدتر می‌شود.
• تأیید تغییرپذیر: شرایط پس از بازبینی عوض می‌شود و همان مجوز باقی می‌ماند.

هم‌زمانی رایگان نیست. سازگاری قوی، تأخیر و پیچیدگی عملیاتی می‌آورد. آن را برای تعهدهای تجمعی یا پیامددار به کار ببرید. فراخوانی کم‌خطر را شاید بتوان با مخزن پیش‌پرداخت کوچک یا سهمیه عرضه‌کننده مهار کرد. هرجا سامانه پایین‌دستی پیش‌مجوز سخت ندارد، بیشینه اضافه‌خرج باقیمانده را آشکار ثبت کنید.

فهرست کنترل پیش از دادن اختیار خرج

پیش از فعال‌کردن خرج عامل مطمئن شوید:

• نقطه تعهد و مالک هر اثر اقتصادی معلوم است؛
• عامل راهی برای دورزدن کارگزار ندارد؛
• سقف هر اقدام، دامنه تجمعی، زمان، فروشنده و وضعیت اضطراری را می‌پوشاند؛
• مبلغ، ارز، تعداد، مالیات، کارمزد و حاشیه قطعی محاسبه می‌شوند؛
• رزرو روی همه مانده‌های مربوط اتمیک است؛
• تأیید به شرایط تغییرناپذیر و ظرفیت زنده وصل است؛
• تلاش دوباره همان نیت و رزرو را استفاده می‌کند؛
• پایان مهلت، برگشت، تسویه، مبلغ اضافی و نتیجه نامعلوم حالت جدا دارند؛
• رسید بیرونی با دفتر داخلی تطبیق می‌شود؛
• رفتار زمان خرابی مستند و آزموده است؛
• مسئول عملیات می‌تواند رزرو تازه را متوقف کند، بی‌آنکه شاهد را پاک کند؛
• هشدار سلامت کنترل را گزارش می‌کند و هرگز جای اجرای آن نمی‌نشیند.

با ورود هر ابزار پولی، ارز، شیوه قیمت‌گذاری، تعهد تکراری، مسیر جایگزین یا لایه واگذاری تازه، طراحی را بازبینی کنید. عامل زمانی آماده خرج‌کردن است که یک درخواست هم‌زمان نتواند برنامه مالی دیروز را به تعهد بی‌مجوز امروز تبدیل کند.

یادداشت منابع

منابع در ۵ سپتامبر ۲۰۲۶ بازبینی شدند:

• NIST SP 800-53 و مواد انتشار تکمیلی جاری — کنترل‌های عمومی کمترین اختیار، مجوز، تفکیک، محدودیت و حسابرسی؛ نه مشخصات خرج عامل.
• OWASP LLM06:2025 درباره اختیار بیش‌ازحد — قابلیت، دسترسی و خودمختاری بیش‌ازحد و مرزهای کاهنده آن‌ها.
• سقف خرج صورتحساب Google Cloud — دامنه پیش‌نمایش، رفتار اجرا، تأخیر گزارش، درخواست جاری و محدودیت اضافه‌هزینه.
• راهنمای مدیریت هزینه AWS Budgets — تأخیر مستند میان مصرف، ثبت هزینه و هشدار.
• ResourceQuota در Kubernetes — پایش تجمعی و رد درخواست ناقض حد سخت پیش از پذیرش.
• جداسازی تراکنش در PostgreSQL — تضمین اجرای سریال‌پذیر، تعارض و مدیریت لازم برای شکست.
• کنترل مخارج Stripe Issuing — سقف پیش از مجوز، واحد ارز، تأخیر تجمیع و هزینه دیررس.
• مجوزهای هم‌زمان Stripe Issuing — تصمیم هم‌زمان، مبلغ نگه‌داشته‌شده، سیاست پایان مهلت و نشانه‌های تطبیق.