تصور کنید یک عامل هوش مصنوعی برای افزودن یک قابلیت ساده، بدون اجازه شما یک سرویس ابری گرانقیمت را به پروژه وصل کند و صورتحساب ماهانه شما را منفجر کند. برای جلوگیری از این کابوس، متدی به نام «بلیت قابلیت» (Capability Ticket) معرفی شده است که هر دسترسی به منابع سیستم را به یک توکن محدود تبدیل میکند. طبق این مکانیسم، هر قابلیت زمان اجرا از یک فایل بلیت مصرف میشود که فقط آداپتورهای محلی را لیست میکند و اگر یک وصله (Patch) سعی کند بلیت یا قابلیتی را مصرف کند که در لیست نیست، فرآیند بوت شدن برنامه متوقف میشود.
این محدودیت مکانیکی اکنون به یک بنیانگذار تکنفره اجازه میدهد تا یک API طراحی شده توسط هوش مصنوعی را بدون باز کردن حتی یک صورتحساب ابری عرضه کند. با پیادهسازی این روش، بنیانگذاران از ابزارهای کدنویسی AI جلوگیری میکنند تا بهصورت پنهانی SDKهای پولی را وارد کدبیس پروژه نکنند. در حالی که ابزارهای مدیریتی پیشرفتهتر مانند Kong AI Gateway 2.0 برای یکپارچهسازی ترافیک مدلها در مقیاس سازمانی طراحی شدهاند، این متد بر سادگی و کنترل هزینهها در مراحل اولیه تمرکز دارد.
عاملهای کدنویسی مدرن معمولاً «آمادهسازی برای تولید» (Production-ready) را بر «کنترل هزینه» ترجیح میدهند. برای مثال، وقتی از آنها میخواهید سیستم بازیابی رمز عبور بسازند، مدل بهطور غریزی سراغ یک سرویس ارسال ایمیل میزبانی شده مانند SendGrid, SES یا Postmark میرود. وقتی از مدل خواسته میشود پروژه را برای محیط تولید آماده کند، بلافاصله بروکرهایی مانند Redis, SQS یا Celery را اضافه میکند. برای یک عملیات تکنفره، این «بهبودها» اغلب برای تایپ کردن ارزان هستند اما برای حذف کردن و بازگشت به عقب گران تمام میشوند و بدهیهای مالی فوری ایجاد میکنند. SDKهای ابری یک بازسازی (Refactor) ساده در آینده نیستند؛ آنها در واقع یک محصول کاملاً متفاوت هستند.
برای مقابله با این وضعیت، سیستم بلیت قابلیت با هر قابلیت زمان اجرا به عنوان یک توکن قابل مصرف برخورد میکند. برنامه در صورتی که یک وصله سعی کند از قابلیتی استفاده کند که صراحتاً در یک فایل پیکربندی محلی ذکر نشده است، از بوت شدن باز میماند. این امر تعریف مهندسی را برای یک عرضه تکنفره تغییر میدهد: مهندسی یعنی اثبات اینکه ذخیرهسازی، صفها، ایمیلها و فایلها همچنان به آداپتورهایی ارجاع داده میشوند که روی یک لپتاپ یا یک هاست رایگان واحد اجرا میشوند. در اینجا، پیشنویس کردن کد شکست نیست؛ بلکه نامیدن این پیشنویس به عنوان «مهندسی»، شکست واقعی است.
مکانیسم فایل بلیت
مرکز این رویکرد، یک فایل capabilities.json در ریشه مخزن است. یک بلیت قابلیت، یک آداپتور نامگذاری شده است، نه یک شعار تبلیغاتی فروشنده. برای هر دغدغه (Concern) یک بلیت وجود دارد و هیچ نام مستعاری (Alias) که بتواند یک کلاینت پولی را پنهان کند، پذیرفته نیست.
به نقل از مستندات این متد، یک پیکربندی صفر-هزینه نمونه شامل موارد زیر است:
- ذخیرهسازی (Storage):
sqlite_file(یک فایل واحد در دایرکتوری دادهها) - صف (Queue):
memory_list(یک deque محلی در سطح فرآیند) - ایمیل (Mail):
maildir(نوشتن فایلهای .eml روی دیسک) - فایلهای حجیم (Blobs):
local_dir(فایلهای هش شده روی دیسک) - وظایف (Jobs):
inline(رشته درخواست، خودِ وظیفه را اجرا میکند) - احراز هویت (Auth):
hmac_cookie(یک کوکی امضا شده با یک فایل راز محلی) - پورت (Listen):
127.0.0.1:8080(اتصال به لوپبک)
هر مقداری خارج از این مجموعه محدود، به عنوان یک بلیت رد شده تلقی میشود. این شکستها در زمان Import رخ میدهند، نه بعد از کلیک کاربر؛ این امر تضمین میکند که فرآیند پیش از فراخوانی هرگونه API ابری، کرش کند.
جدول تصمیمگیری هفته اول
جدول زیر به عنوان قرارداد محصول عمل میکند. هر وصله توسط عامل AI که ردیف جدیدی را بدون ویرایش انسانی در این جدول معرفی کند، برای یک عرضه «صورتحساب صفر» خارج از محدوده (Out of scope) تلقی میشود:
| مورد | بلیت مجاز | جایگزین ممنوعه | دلیل هفته اول |
|---|---|---|---|
| ذخیرهسازی | sqlite_file |
Postgres, hosted MySQL | یک فایل، بدون هاست اضافی |
| صف | memory_list |
Redis, SQS, Celery | با بسته شدن فرآیند میمیرد (پذیرفتنی) |
| ایمیل | maildir |
SendGrid, SES, Postmark | بنیانگذار میتواند فایل .eml را باز کند |
| فایلها | local_dir |
S3, GCS, R2 | فایلهای هش شده در کنار SQLite |
| وظایف | inline |
Cloud scheduler, worker pool | هیچ فرآیند دومی برای صورتحساب وجود ندارد |
| احراز هویت | hmac_cookie |
Auth0, Cognito, Clerk | فقط فایل راز محلی |
| پورت | loopback | 0.0.0.0 | اتصال عمومی منتظر کاربر واقعی میماند |
کارخانه بسته-در-صورت-خطا (Fail-Closed Factory)
این سیستم بر پایه یک الگوی Factory پیادهسازی شده در ماژول budget.py است. برنامه هرگز SQLite، صفها یا ایمیلرها را بهصورت موردی (Ad hoc) نمیسازد؛ در عوض از یک کارخانه درخواست میکند. کارخانه فایل بلیت را یک بار میخواند و در صورت عدم تطابق، خطای BudgetError را صادر میکند.
بهطور حیاتی، کارخانه مسیر data_dir را اعتبارسنجی میکند. اگر یک عامل AI سعی کند دایرکتوری دادهها را به یک mount از راه دور یا یک مسیر سیستمی مانند /var/lib/postgresql تغییر دهد، کارخانه فرآیند بوت را مسدود میکند. این بررسی مسیر تضمین میکند که دایرکتوری دادهها از محدوده مخزن (Repo) خارج نشود. کارخانه مانند یک میز پرداخت (Spend desk) عمل میکند و کد برنامه اجازه ندارد با آن بحث کند.
آداپتورهای محلی خستهکننده
پیادهسازی از آداپتورهای «خستهکننده» (Boring) استفاده میکند تا هزینه صفر تضمین شود. در واقع، هدف همین خستهکننده بودن است:
- Store: از کتابخانه داخلی
sqlite3پایتون برای ایجاد یک جدولnotesبا فیلدهایid،bodyوcreated_atاستفاده میکند. دادهها را در فایلapp.sqliteدر دایرکتوری دادهها ذخیره میکند. - MailDir: فایلهای
.emlرا در یک پوشه محلی مینویسد. نام فایلها با استفاده از یک برچسب زمانی (Timestamp) و هش SHA256 آدرس گیرنده تولید میشوند. این به بنیانگذار اجازه میدهد ایمیلها را بهصورت دستی بازرسی کند. - MemoryQueue: محمولهها (Payloads) را در یک
dequeمحلی ذخیره میکند. هندلر HTTP وظایفی (مانندnote_mail) را به این صف میفرستد و پیش از بازگشت پاسخ، آنها را تخلیه میکند. اگرچه زیر بار زیاد کندتر است، اما رایگان و قابل بازرسی است. - BlobDir: بایتهای خام را به عنوان فایلهای هش شده روی دیسک با استفاده از دایجستهای SHA256 برای نام فایلها ذخیره میکند.
سطح HTTP و لوپبک
سیستم برای اولین مجموعه مسیرها (Routes) از کتابخانه استاندارد پایتون استفاده میکند؛ برای اثبات بودجه نیازی به استک ASGI نیست. کلاس Handler درخواستهای GET و POST را برای مسیر /notes مدیریت میکند.
لوپبک (Loopback) بخش حیاتی از بلیت است. اتصال به 0.0.0.0 تصمیمی است که بعد از وجود یک کاربر واقعی گرفته میشود، نه بعد از اینکه یک مدل پورت انتشار Docker را پیشنهاد داد. اگر هاست شنونده 127.0.0.1 یا localhost نباشد، سیستم SystemExit صادر میکند زیرا بلیت رد شده است.
اجبار به بودجه از طریق اثبات
یک عرضه (Ship) یک احساس نیست؛ بلکه یک فایل است. برای اطمینان از اینکه AI بهصورت پنهانی بودجه را دور نزده است، متد یک دستور prove_ship.py معرفی میکند. این اسکریپت مراحل زیر را انجام میدهد:
۱. برنامه را با استفاده از subprocess.Popen بوت میکند.
۲. منتظر میماند تا سرور به پورت لوپبک متصل شود.
۳. یک درخواست POST به /notes همراه با بدنه و ایمیل اطلاعرسانی میفرستد.
۴. تأیید میکند که یادداشت ایجاد شده و از طریق یک درخواست GET لیست شده است.
۵. بررسی میکند که app.sqlite و حداقل یک فایل .eml در دایرکتوری دادهها ظاهر شده باشند.
اگر اسکریپت اثبات پاس شود، یک فایل SHIP_PROOF.json حاوی ID یادداشت، اندازه بایتی SQLite و تعداد فایلهای ایمیل مینویسد. این فایل، در کنار فایل بلیت، به یک ورودی اجباری برای جلسه بعدی عامل AI تبدیل میشود. سپس عامل مجبور است با این محدودیتها به عنوان الزامات سختگیرانه برخورد کند، نه صرفاً پیشنهادات. این رویکرد به نوعی مشابه گردشکارهای ترکیبی AI و انسان در بازرسی قراردادهای هوشمند است که در آن نظارت انسانی بر خروجیهای مدل، دقت و امنیت سیستم را تضمین میکند.
محافظت از خط لوله CI
برای جلوگیری از اینکه یک مدل بهصورت پنهانی لیست ALLOWED را در کد گسترش دهد، سیستم یک تست واحد در test_budget.py پیشنهاد میکند. این تست بهطور خاص بررسی میکند که کارخانه جایگزینهای ممنوعه مانند Postgres یا دایرکتوریهای داده فرار (مانند ../outside) را رد کند.
با قرار دادن این تست در کنار فایل بلیت، هر وصلهای که بودجه را تغییر دهد، در زمان بررسی کد (Code Review) به عنوان یک «درخواست هزینه» (Spend request) قابل مشاهده میشود. وصلهای که فقط منطق برنامه را ویرایش میکند، بررسی آن ارزان است، اما وصلهای که budget.py را ویرایش میکند، درخواستی برای هزینه بیشتر است. دفاع در اینجا هم اجتماعی است و هم فنی.
زمان رها کردن آداپتورهای محلی
این رویکرد یک راهنمای مقیاسپذیری (Scaling) نیست. این روش برای هفته اول عمر یک محصول طراحی شده است. نویسنده اشاره میکند که برخی محدودیتها برای یک MVP پذیرفتنی اما برای یک محصول در حال رشد خطرناک هستند:
- صفهای حافظه: تمام کارهای منتظر با ریاستارت فرآیند ناپدید میشوند.
- Maildir: این یک راهکار برای تحویل ایمیل (Deliverability) نیست؛ فقط ثبت میکند که ایمیل ارسال شده است.
- SQLite: نمیتواند چندین نویسنده را در ماشینهای مختلف مدیریت کند.
- لوپبک: اتصال به
127.0.0.1مانع از لانچ عمومی میشود. - کوکیهای HMAC: اینها یک پلتفرم کامل مدیریت هویت نیستند.
بنیانگذاران باید در صورتی که محصول از قبل کاربران پرداختکننده دارد که به failover چند-نمونهای نیاز دارند، یا اگر فایلهای حجیم باید بهصورت جغرافیایی تکثیر شوند، یا اگر انطباق (Compliance) مستلزم یک فروشنده ابری نامدار است، از این رویکرد صرفنظر کنند. اینها بلیتهای متفاوتی هستند. آنها را بعد از کسب درآمد بخرید، نه بعد از یک پرامپت.
ادغام با محیطهای رایگان
یک بنیانگذار تکنفره همچنان باید اولین هندلرها را تولید کند. ابزارهایی مانند دسترسی رایگان به مدلهای MonkeyCode و گزینه سرور رایگان میتوانند این چرخه «تولید-و-اثبات» را بدون باز کردن یک حساب ابری پولی برای محیط کدنویسی میزبانی کنند. با این حال، فایل بلیت و prove_ship.py خودِ محصول هستند؛ محیط تنها جایی برای اجرای آنهاست. این متد به هیچ فروشنده خاصی وابسته نیست. اگر همان فایلها روی یک لپتاپ اجرا شوند، کار خود را انجام میدهند.
پیشنویسهای کمکگرفته از AI همچنان به یک انسان نیاز دارند تا لیست ALLOWED را کوچک نگه دارد. یک مدل میتواند budget.py را به همان راحتی app.py ویرایش کند. فایل بلیت مانند یک درخواست هزینه بررسی میشود و فایل اثبات، رسید آن است. آداپتورهای محلی را همین هفته عرضه کنید و بلیتها را پیش از بحث درباره اولین مشتری پولی، مهر و موم کنید.
گام بعدی شما
- فایل
capabilities.jsonرا به ریشه پروژه خود اضافه کنید و تمام وابستگیهای ابری را با جایگزینهای محلی (مثل SQLite) عوض کنید. - یک اسکریپت مشابه
prove_ship.pyبنویسید تا هر تغییر عامل هوش مصنوعی را با تستهای فیزیکی روی دیسک اعتبارسنجی کنید. - در فایل
budget.pyیک لایه اعتبارسنجی برای مسیرهای ذخیرهسازی قرار دهید تا از خروج دادهها از پوشه پروژه جلوگیری شود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو