پوشه‌های بودجه؛ سدی برای نشت داده‌ها و هزینه‌های سرسام‌آور در عامل‌های AI

تصور کنید یک کاربر در سامانه مالی، دکمه «خلاصه‌سازی و بایگانی» را می‌زند، اما به دلیل یک خطای سیستمی، سند او در فضای کاری مشتری دیگری ذخیره می‌شود. این کابوس امنیتی، نتیجه‌ی مستقیم نادیده گرفتن مرزهای دسترسی در طراحی عامل‌های هوش مصنوعی است. به نقل از گزارشی در ۱۳ سپتامبر ۲۰۲۶ در وب‌سایت dev.to، این اتفاق زمانی رخ داد که یک متخصص عملیات مالی روی دکمه کلیک کرد و در حالی که یک آیکون در حال چرخش (Spinner) را می‌دید و سپس یک پاراگراف تمیز را مشاهده می‌کرد، تصور می‌کرد عملیات بایگانی با موفقیت انجام شده است؛ در حالی که سیستم در سکوت شکست خورده بود و رکورد را در فضای کاری مشتری دیگری فرستاده بود، زیرا فراخوانی مدل مانند یک جعبه چت ساده سیم‌کشی شده بود.

بسیاری از تیم‌های توسعه، عامل‌های هوش مصنوعی را صرفاً یک چالش در مهندسی پرامپت (Prompt Engineering) — شبیه هنر سؤال درست پرسیدن از یک مشاور باتجربه — می‌بینند. آن‌ها تمام تمرکز خود را روی این می‌گذارند که آیا مدل می‌تواند کد بنویسد یا متن را خلاصه کند یا خیر. یک استدلال رایج این است که مدل‌ها در حال حاضر بهتر از اکثر توسعه‌دهندگان فعال کد می‌نویسند، اما این استدلال زمانی که محصول شما باید یک رکورد را بایگانی کند، از یک کارت اعتباری وجه برداشت کند یا به یک انسان اطلاع دهد، به یک موضوع فرعی و بی‌اهمیت تبدیل می‌شود. در دنیای واقعی، اولین نقطه شکست به‌ندرت مربوط به نحو (Syntax) است؛ بلکه تقریباً همیشه ریشه در محدوده دسترسی مشتری (Tenant Scope)، تکرارپذیری (Idempotency) یا نبود سقف هزینه دارد. این ضعف‌های ساختاری دقیقاً همان دلایلی است که باعث می‌شود کدهای تولیدشده توسط هوش مصنوعی بدون زیرساخت معماری فرو بپاشند، چرا که مدل‌ها ذاتاً از منطق لایه‌بندی‌شده‌ی نرم‌افزار بی‌اطلاع‌اند.

همان‌طور که در تحلیل قبلی ما درباره‌ی «حفاظ‌های حلقه» (Loop Guards) برای جلوگیری از سوختن بودجه اشاره کردیم، اکنون تمرکز باید روی «پوشه» (Envelope) ساختاری باشد که هر درخواست را در بر می‌گیرد. این پوشه در واقع یک قرارداد سخت‌گیرانه است که مشخص می‌کند چه کسی درخواست می‌دهد، کدام مشتری درگیر است، چه داده‌ای تغییر می‌کند و چند توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک — باقی مانده است. اگر هر یک از این فیلدها در این قرارداد ناقص باشد، سیستم باید پیش از آنکه مدل حتی یک بایت داده ببیند، درخواست را رد کند. این «رد کردن درخواست» است که در واقع محصول واقعی است، نه خودِ خلاصه‌سازی. تفاوت بین تزیین یک نمونه اولیه (Prototype) و تبدیل یک ویژگی به محصول تولیدی (Productionizing) در همین نقطه نهفته است.

طبق مستندات dev.to، یک پوشه آماده برای محیط تولید باید شامل موارد زیر باشد:

• شناسه فضای کاری (Workspace ID): یک رشته متنی برای اطمینان از اینکه درخواست در محدوده مشتری درست است.
• شناسه کاربر (Actor ID): یک رشته متنی برای تأیید هویت شخصی که اقدام را آغاز کرده است.
• شناسه سند/فاکتور (Invoice/Artifact ID): یک رشته متنی برای گره زدن اقدام به یک رکورد خاص.
• کلید تکرارپذیری (Idempotency Key): رشته‌ای منحصربه‌فرد برای جلوگیری از ثبت دوبرابره یا برداشت تکراری وجه در زمان تلاش‌های مجدد (Retries).
• حداکثر توکن‌های خروجی: عددی برای اعمال سقف هزینه سخت روی هر درخواست خاص (مثلاً ۸۰۰ توکن).
• شمارنده تلاش‌ها: عددی برای ردیابی تعداد دفعاتی که درخواست تکرار شده است.

در نمونه‌های اولیه که با رویکرد Vibe Coding ساخته می‌شوند، توسعه‌دهندگان معمولاً SDK شرکت ارائه‌دهنده را مستقیماً به یک مسیر (Route) متصل می‌کنند و امیدوارند که پرامپت درست رفتار کند. این رویکرد مسیری ایجاد می‌کند که صرفاً متن PDF را به هم می‌چسباند، SDK ارائه‌دهنده را اجرا می‌کند و خروجی JSON را درج می‌کند. در حالی که خلاصه تولید شده ممکن است بسیار زیبا باشد، اما عملیات درج (Insert) همچنان یک نوشتنِ متقاطع بین مشتریان (Cross-tenant write) در کابینت اشتباه است. این وضعیت اجازه می‌دهد شناسه‌های مشتری ناپدید شوند و تلاش‌های مجدد باعث ثبت دوبرابره رکوردها شوند.

راهکار حرفه‌ای این است که مدل را به عنوان یک سرویس پایین‌دستی (Downstream) در نظر بگیرید که پشت دروازه‌ای از احراز هویت، بررسی بودجه و تأیید تکرارپذیری قرار دارد. مدل نباید مانند کاغذ رنگی در تمام بخش‌های برنامه پس از یک روز دمو پخش شود؛ بلکه باید یک درگاه واحد وجود داشته باشد که پوشه را می‌پذیرد و پیش‌نویسی را برمی‌گرداند تا بقیه برنامه بتواند آن را ذخیره (Persist) کند. مدل در هر تلاش، پایین‌دستِ احراز هویت، بودجه و کلید تکرارپذیری قرار می‌گیرد. این رویکرد در واقع همان منطقی است که در پروتکل رسید میزبان برای جلوگیری از توهمات عامل‌های کدنویس به کار گرفته شد تا محیط اجرا با واقعیت‌های سیستم تطبیق یابد.

برای اجرای این ساختار، منطق برنامه باید به یک «برش عمودی» (Vertical Slice) تقسیم شود تا اطمینان حاصل شود که عامل پیشنهاد می‌دهد، اما پوشه تصمیم می‌گیرد که آیا کسی اجازه درخواست دارد یا خیر:

• مدیریت‌کننده (The Handler): یک مسیر FastAPI که workspace_id و invoice_id را از مسیر (Path) و x-actor-id و idempotency-key را از هدرها استخراج می‌کند. این بخش یک پوشه ثبت (FilingEnvelope) می‌سازد و به جای میدان بازی پرامپت، نقش یک دروازه‌بان را دارد. این بخش درخواست را رد می‌کند مگر اینکه این سه حقیقت — کوکی، شناسه فضای کاری و شناسه فاکتور — در هر گام تا رسیدن به کلاینت مدل باقی بمانند.
• سرویس (The Service): سرویس ثبت (FilingService) پیش از تماس با AI، سه گام حیاتی را طی می‌کند:
  1. بررسی مالکیت (Tenancy Check): فاکتور را تحت فضای کاری خاص بارگذاری می‌کند؛ اگر یافت نشود، خطای TenantMismatch (منجر به کد ۴۰۳) صادر می‌کند.
  2. بررسی تکرارپذیری (Idempotency Check): دفتر کل (Ledger) را برای idempotency_key چک می‌کند؛ اگر پیش‌نویسی از قبل وجود داشته باشد، بلافاصله آن را برمی‌گرداند تا از یک تماس پولی دیگر جلوگیری شود.
  3. بررسی بودجه (Budget Check): بررسی می‌کند آیا بودجه باقی‌مانده در دفتر کل کمتر از max_output_tokens است یا خیر؛ در این صورت استثنای BudgetExceeded (منجر به کد ۴۰۲) صادر می‌کند.
• درگاه مدل (The Model Port): پروتکلی که پوشه و متن را گرفته و یک پیش‌نویس ثبت (FilingDraft) شامل خلاصه، نام ارائه‌دهنده و میزان واقعی توکن‌های مصرف‌شده (usage_tokens) را برمی‌گرداند. این کار باعث می‌شود برنامه به نام یا مدل خاصی وابسته نباشد.

تیم‌ها پیش از بحث درباره اینکه کدام مدل «باهوش‌تر» است، باید یک تمرین خسته‌کننده روی یک میزبان موقت (Throwaway host) اجرا کنند. هدف اینجا یافتن زیباترین پاراگراف نیست، بلکه شکار کدهای وضعیت HTTP است تا ثابت شود سیستم در صورت خطا، دسترسی را می‌بندد (Fail Closed). این تمرین شامل راه‌اندازی سروری است که همان پوشه مدیریت‌کننده تولید را می‌شناسد و فاکتورهای ضبط‌شده را تا زمانی که کدهای وضعیت قابل پیش‌بینی شوند، بازپخش می‌کند:

• ۴۰۳ Forbidden: وقتی فضای کاری اشتباه درخواست شود (عدم تطابق مشتری).
• ۴۰۲ Payment Required: وقتی بودجه پیش از تماس با ارائه‌دهنده تمام شود.
• ۴۰۹ Conflict: وقتی کلید تکرارپذیری برای جلوگیری از درج‌های تکراری دوباره استفاده شود.
• ۲۰۱ Created: تنها مسیر موفق (Happy Path) پس از عبور از تمام دروازه‌ها.

سرویس MonkeyCode یک گزینه رایگان برای این تمرینات و دسترسی رایگان به مدل‌ها فراهم می‌کند تا آزمایش‌ها از بودجه تولید و دیتابیس مشتریان دور بمانند. این به توسعه‌دهندگان اجازه می‌دهد از بازپخش محلی — مانند یک دستور curl به یک مبدأ موقت — استفاده کنند تا یک فاکتور سانسور شده را به عنوان یک مورد ثابت (Fixture) منجمد کرده و هدرها را بدون ریسک دیتابیس زنده تست کنند. یک بازپخش معمولی را می‌توان به مبدأ محلی مانند http://127.0.0.1:8088 با هدرهای خاص برای x-actor-id و idempotency-key هدف گرفت تا پاسخ قطعی (Deterministic) باشد.

بسیاری از تیم‌ها در تله‌ای می‌افتند که فقط «مقاله» (خروجی AI) را نمره می‌دهند، در حالی که «شیار» (درگاه API) برای هر فضای کاری باز است. این مثل صندوق بانکی است که متنِ رسیدِ متصدی درباره پول مهم نیست، چون صندوق به حساب اشتباهی باز می‌شود. اگر نمی‌توانید مراحل بارگذاری یک فاکتور، بررسی دفتر کل و درخواست از درگاه را بدون ذکر نام یک مدل خاص توضیح دهید، برش شما هنوز یک اسباب‌بازی است، نه یک محصول.

این فقدان ساختار منجر به حوادث خاص و قابل پیش‌بینی می‌شود:

• ثبت دوبرابره (Double-Filing): یک Timeout در درگاه باعث تلاش مجدد مدیریت‌کننده می‌شود و چون بررسی تکرارپذیری وجود ندارد، همان فاکتور دو بار ثبت می‌شود.
• نشت متقاطع مشتریان (Cross-Tenant Leaks): یک کوکی محیط تست (Staging) قرض گرفته شده اجازه می‌دهد خلاصه‌ای در فضای کاری نوشته شود که متعلق به آن کاربر نیست.
• جهش هزینه‌ها (Cost Spikes): یک شمارنده تلاش بدون سقف که به بهانه «کمک‌رسانی» طراحی شده، بودجه را می‌مکد.

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

تحلیل: تغییر از پرامپت به لوله‌کشی

این رویکرد نشان‌دهنده تغییر در مهندسی AI از توسعه «پرامپت-محور» به توسعه «لوله‌کشی-محور» (Plumbing-centric) است. برای یک توسعه‌دهنده عمل‌گرا، این بدان معناست که ارزشمندترین بخش یک ویژگی AI دیگر پرامپت نیست، بلکه دفتر کل (Ledger) و منطق تکرارپذیری پیرامون آن است. طرحواره (Schema) دفتر کل باید بخشی از مسیر مهاجرت واقعی دیتابیس باشد، زیرا ردیف‌های بودجه، داده‌های برنامه هستند، نه تزئینات پرامپت. در واقع، جایگزینی کدهای چسبناک و شکننده با عامل‌های تحت نظارت Omnifys گامی در همین راستای تبدیل لوله‌کشی‌های آماتور به زیرساخت‌های صنعتی است.

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

چه کسانی نباید از این الگو استفاده کنند؟

در حالی که پوشه برای برنامه‌های تولیدی ضروری است، اما برای همه نیست:

• آموزش مدل‌ها (Weight Trainers): اگر در حال آموزش وزن‌ها در یک محیط آزمایشگاهی هستید، این پوشه کمکی به شما نمی‌کند.
• کاربران نوت‌بوک (Notebook Users): اگر برنامه شما هیچ مشتری (Tenant) و هیچ ذخیره‌سازی دائمی ندارد، می‌توانید در نوت‌بوک بمانید و از پنجره چت لذت ببرید.
• محیط‌های حقوقی سخت‌گیر: اگر بخش حقوقی شما نیاز دارد پیش از دیدن متن توسط هر میزبان شخص ثالث، بررسی ارائه‌دهنده را انجام دهد، باید همین تست‌ها را روی یک درگاه جعلی محلی (Local Fake Port) اجرا کنید.

برای تأیید پیاده‌سازی خود، سعی کنید یک درخواست تکراری با همان کلید تکرارپذیری به مسیر ثبت خود بفرستید. اگر دیتابیس شما به جای یک رکورد، دو رکورد نشان داد، ویژگی AI شما هنوز یک نمونه اولیه است. تست واقعی این است که آیا کد ۴۰۲ پیش از ۴۰۳ ظاهر می‌شود (زمانی که هر دو دروازه باید فعال شوند)؛ این ترتیب نشان می‌دهد که آیا پول یا مالکیت داده، قفل ضعیف‌تری روی کابینت شماست.

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