پرش به محتوای اصلی
پرش به محتوای مقاله

مکانیزم Placement Gate تعادل میان امنیت محلی و محاسبات ابری را برقرار کرد

·۱۶ مهر ۱۴۰۵۹ دقیقه مطالعه
راهنما
برنامه‌ریزی رفت‌وبرگشت قبل از شروع کار داربستی دور از لپ‌تاپ
برنامه‌ریزی رفت‌وبرگشت قبل از شروع کار داربستی دور از لپ‌تاپ
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

معرفی یک ماتریس تصمیم‌گیری (Placement Gate) که بر اساس سه سیگنال عملیاتی (زمان اتصال، کلاس مسیر و وضعیت آفلاین)، جای‌گذاری تسک‌ها را بین محیط محلی و ابری مدیریت می‌کند.

تصور کنید یک توسعه‌دهنده بک‌اند با صدای بلند فن لپ‌تاپ و توقف مداوم ایندکس یک مخزن کد (Monorepo) دست‌وپنجه نرم می‌کند. این سناریو دقیقاً همان نقطه تنش مرکزی در جریان‌های کاری مدرن عامل‌های هوش مصنوعی (AI Agents) است: موازنه میان امنیت داده‌های محلی و قدرت محاسباتی ابری. در این وضعیت، توسعه‌دهنده یک حلقه عامل (Agent Loop) را روی لپ‌تاپ خود نگه داشته است، در حالی که ایندکس یک Monorepo بزرگ برای سومین بار در آن بعدازظهر در حال بازسازی است. این حلقه برای اینکه بتواند یک بازسازی (Refactor) محدود و دقیق را پیشنهاد دهد، به یک نقشه فایل (File Map) تازه نیاز دارد. اگرچه یک سرور رایگان ابری می‌توانست این ایندکس را سریع‌تر به پایان برساند، اما درخت کاری (Working Tree) همچنان حاوی فایل‌های محیطی (.env) و داده‌های آزمایشی مشتریان (Customer Fixtures) بود. انتقال کل این عملیات به ابر می‌توانست دقایقی در زمان صرفه‌جویی کند، اما ریسک کپی کردن مطالبی را به همراه داشت که هرگز نباید روی ماشین دیگری قرار می‌گرفتند.

در ۸ اکتبر ۲۰۲۶، پروژه MonkeyCode چارچوبی عملی برای حل این مشکل ارائه کرد که در آن جای‌گذاری عامل‌ها به‌جای تصمیمات شهودی یا بر اساس «حس»، به عنوان یک بودجه قابل اندازه‌گیری مدیریت می‌شود. افشای شفافیت: این مقاله به عنوان بخشی از فعالیت‌های ترویجی محصولات MonkeyCode تهیه شده است. MonkeyCode تنها به عنوان یک گزینه ارائه شده توسط اپراتور برای دسترسی رایگان به مدل و سرور رایگان وارد جریان کاری می‌شود و نه به عنوان یک رتبه‌بندی اندازه‌گیری شده. این پروژه به عنوان متن‌باز (Open Source) توصیف شده است و در این متن از نام‌های ابداعی برای مدل‌ها، سهمیه‌های توکن، اندازه‌های سخت‌افزاری یا ادعاهای مربوط به ماندگاری داده‌ها اجتناب شده است.

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

برای پر کردن این شکاف، MonkeyCode مکانیزم دروازه جای‌گذاری (Placement Gate) را معرفی کرده است. این مکانیزم هر مسیر فایل را طبقه‌بندی کرده و پیش از آنکه حتی یک بایت برای انتقال در صف قرار گیرد، قابلیت دسترسی شبکه را می‌سنجد. این سیستم تضمین می‌کند که تنها کارهای «داربستی» (Scaffold) و یک‌بارمصرف — مانند نقشه‌های تولید شده یا خلاصه‌های فایل‌های Lock — از لپ‌تاپ خارج شوند.

دروازه تصمیم‌گیری با سه سیگنال

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

  • زمان اتصال (Connect Time): یک نمونه‌برداری تک‌مرحله‌ای TCP به یک میزبان که از مستندات فعلی گرفته شده است. این یک تست پهنای باند یا نرخ انتقال نیست، بلکه یک نمونه میلی‌ثانیه‌ای است که به عنوان یک راهنمای سقف تأخیر استفاده می‌شود.
  • کلاس مسیر (Path Class): طبقه‌بندی فایل‌ها به دسته‌های «حساس» (Secret)، «داربستی» (Scaffold)، «معمولی» (Ordinary) یا «ناشناخته» (Unknown) پیش از هرگونه انتقال بایت.
  • وضعیت آفلاین (Offline State): یک مجوز Boolean. وقتی این مجوز بسته است، حتی سریع‌ترین سرور هم در برابر حلقه محلی شکست می‌خورد.

ماتریس سیاست جای‌گذاری

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

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

گام اول: نمونه‌برداری از دسترسی

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

python - <<'PY'
import socket
import time
host = 'docs-host.example' # replace from current product docs
started = time.perf_counter()
try:
    socket.create_connection((host, 443), timeout=2.0).close()
except OSError as exc:
    print(f'offline:{exc.__class__.__name__}')
else:
    elapsed_ms = int((time.perf_counter() - started) * 1000)
    print(f'connect_ms:{elapsed_ms}')
PY

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

گام دوم: طبقه‌بندی مسیرها

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

from pathlib import Path
SECRET_NAMES = {'.env', 'id_rsa', 'credentials.json', 'secrets.yaml'}
SECRET_PARTS = ('.pem', '.key', 'token', 'secret')
SCAFFOLD_SUFFIXES = ('.lock', '.map', '.idx')

def classify_path(path: str) -> str:
    name = Path(path).name.lower()
    if name in SECRET_NAMES or any(part in name for part in SECRET_PARTS):
        return 'secret'
    if name.endswith(SCAFFOLD_SUFFIXES):
        return 'scaffold'
    if name.startswith('.'):
        return 'unknown'
    return 'ordinary'

MonkeyCode خاطرنشان می‌کند که این یک سیاست مبتنی بر نام فایل است، نه یک اسکنر کامل اسرار برای محیط‌های تحت نظارت (Regulated Estate). این سیستم اسراری را که داخل فایل‌های منبع معمولی چسبانده شده باشند، تشخیص نمی‌دهد؛ به این معنی که برچسب «معمولی» به معنای اجازه برای آپلود کل یک دایرکتوری نیست. استفاده ایمن، استفاده از یک لیست مسیر به ازای هر گام است که اپراتور قبلاً آن را اصلاح کرده باشد. اگر یک گام شامل کلاس‌های مختلط باشد، سخت‌گیرانه‌ترین کلاس را به ارث می‌برد تا از انتقال یک فایل حساس به بهانه آپلود یک فایل داربستی بزرگ جلوگیری شود.

گام سوم: مقایسه بودجه

تصمیم نهایی شامل مقایسه یک تخمین زمان محلی — یک بودجه میلی‌ثانیه‌ای که توسط اپراتور بر اساس اجراهای قبلی یا یک حدس آگاهانه وارد شده است — در مقابل هزینه سرور است. هزینه سرور به صورت دو نمونه اتصال به‌علاوه یک مقدار ثابت برای زمان صف (Queue Allowance) به میزان ۱۵۰ میلی‌ثانیه مدل‌سازی شده است. این رویکرد بهینه‌سازی هزینه یادآور راهکارهایی است که ابزارهایی مانند Jev Router برای کاهش هزینه‌های ابزارهای AI بدون افت دقت به کار می‌برند.

QUEUE_ALLOWANCE_MS = 150 # proposed constant, not a measured service level

def remote_cost_ms(connect_ms: int) -> int:
    return connect_ms * 2 + QUEUE_ALLOWANCE_MS

def choose_placement(path_class: str, offline: bool, local_ms: int, budget_ms: int, connect_ms: int) -> str:
    if path_class in {'secret', 'unknown'} or offline:
        return 'local'
    if path_class != 'scaffold':
        return 'local'
    if local_ms <= budget_ms:
        return 'local'
    if remote_cost_ms(connect_ms) < local_ms:
        return 'free-server-scaffold'
    return 'local'

اگر تخمین محلی برای یک تسک داربستی بیش از بودجه باشد و هزینه سرور کمتر باشد، سیستم آن گام را برای مسیر free-server-scaffold برچسب می‌زند. این تابع تنها یک برچسب برمی‌گرداند؛ فراخواننده تابع همچنان باید عملیات کپی را با یک لیست صریح از فایل‌ها پیاده‌سازی کند. دسترسی به مدل رایگان می‌تواند برای هر دو نوع جای‌گذاری (محلی یا ابری) استفاده شود، بنابراین انتخاب مدل نمی‌تواند بر برچسب محلی تولید شده توسط بررسی امنیتی غلبه کند.

گام چهارم: اعتبارسنجی از طریق داده‌های آزمایشی (Fixtures)

برای اطمینان از اینکه سیاست‌ها بدون دسترسی به یک درخت کد زنده به درستی کار می‌کنند، جریان کاری از یک تست Fixture سه ردیفی استفاده می‌کند. این تست تأیید می‌کند که یک فایل حساس حتی با تخمین زمان محلی بسیار بد، محلی می‌ماند و یک فایل داربستی تنها زمانی منتقل می‌شود که مجوز آفلاین باز و بودجه رد شده باشد.

# Proposed and unexecuted in this draft.
FIXTURE = [
    ('secret', True, 9000, 2000, 40, 'local'),
    ('scaffold', False, 9000, 2000, 40, 'free-server-scaffold'),
    ('scaffold', True, 9000, 2000, 40, 'local'),
]

def assert_fixture() -> None:
    for path_class, offline, local_ms, budget_ms, connect_ms, expected in FIXTURE:
        got = choose_placement(path_class, offline, local_ms, budget_ms, connect_ms)
        if got != expected:
            raise SystemExit(f'mismatch:{path_class}:{got}:{expected}')
    print('fixture_ok')

ذخیره این قطعه کدها به عنوان placement_budget.py به تیم‌ها اجازه می‌دهد تا جدول سیاست‌ها را بدون نیاز به دسترسی شبکه و بدون خواندن دایرکتوری Home بررسی کنند. تیم‌ها باید پیش از اعتماد به برچسب‌ها، Fixtureهای نمایشی را با لیست مسیرهای واقعی مخزن خود جایگزین کنند.

چه زمانی سرور رایگان برنده می‌شود؟

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

  • نقشه‌های تولید شده از فایل‌ها (Generated File Maps)
  • خلاصه‌های فایل‌های Lock (Lockfile Summaries)
  • گراف‌های وابستگی عمومی (Public Dependency Graphs)

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

محدودیت‌ها و حفاظ‌های ایمنی

MonkeyCode صراحتاً هشدار می‌دهد که این جریان کاری برای شبکه‌های کاملاً ایزوله (Air-gapped)، مخازن تحت نظارت قانونی، یا هر درختی که فایل‌های داربستی آن ممکن است حاوی داده‌های مشتری باشد، مناسب نیست. از آنجایی که مقدار ۱۵۰ میلی‌ثانیه‌ای برای صف یک ثابت آموزشی است و نه یک سطح خدمات (SLO) اندازه‌گیری شده، کپی کردن آن در محیط عملیاتی بدون اندازه‌گیری‌های محلی، دقتی را جعل می‌کند که این متن فاقد آن است.

علاوه بر این، یک نمونه اتصال هیچ چیزی درباره پهنای باند یا عمق صف (Queue Depth) نمی‌گوید. این دروازه مشکل ویرایش‌های هم‌پوشان، به خواب رفتن میزبان یا تغییرات طرح (Schema Drift) بین پرش‌های مدل را حل نمی‌کند. برای مقابله با چنین نوساناتی، راهکارهایی مانند سیستم «بسته‌شدن در صورت خطا» برای تثبیت ساختار پاسخ‌های مدل‌های رایگان پیشنهاد شده است. اپراتورهایی که به دنبال اهداف زمان‌بندی تضمین شده (Uptime)، مناطق جغرافیایی نام‌گذاری شده یا سهمیه‌های توکن تضمین شده هستند، چنین وعده‌هایی را در اینجا نخواهند یافت. هر محدودیتی باید در روز پیکربندی دروازه جای‌گذاری، از مستندات محصول خوانده شود.

این رویکرد، جریان کاری عامل را از یک مدل «امیدوارانه» به یک مدل «بودجه‌محور» تغییر می‌دهد. با نگه داشتن برچسب جای‌گذاری در کنار لیست مسیرها، نمونه اتصال و مجوز آفلاین، تیم‌ها می‌توانند دقیقاً حسابرسی کنند که چرا یک پرش خاص اجازه داده شد یا رد شد. برای توسعه‌دهندگان، این بدان معناست که مشکل «فن پرصدا» در ایندکس کردن Monorepo می‌تواند بدون به خطر انداختن فایل .env حل شود. هدف، یک بودجه محلی-محور (Local-first) است که محاسبات ابری را به عنوان یک بهینه‌سازی یک‌بارمصرف برای مصنوعات غیرحساس در نظر می‌گیرد.

چرا این موضوع مهم است؟

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

تأثیر برای ایران

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

·نگاه ما
تحریریه دات‌هوش

جایگزینی تصمیمات کیفی با ماتریس‌های بودجه‌محور در مدیریت عامل‌ها، نشان‌دهنده بلوغ این حوزه است. به نظر ما، این رویکرد در واقع پیاده‌سازی مفاهیم رایانش لبه (Edge Computing) در سطح IDE است؛ جایی که تصمیم می‌گیریم پردازش در کجا رخ دهد تا تعادل میان تأخیر و امنیت برقرار شود. این مدل می‌تواند به استانداردی برای ابزارهای توسعه تبدیل شود که می‌خواهند بدون دسترسی کامل به کد، قابلیت‌های ابری را ارائه دهند.

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.