تصور کنید تیمی از توسعه‌دهندگان دارید که هر کدام از ابزاری متفاوت برای تعامل با هوش مصنوعی استفاده می‌کنند؛ یکی در محیط Cursor کد می‌زند، دیگری از Claude Desktop استفاده می‌کند و سومی ابزاری داخلی دارد. در این وضعیت، شما مجبورید کلیدهای API، مستندات فنی و URLهای بازگشتی را برای هر کاربر به‌صورت جداگانه تعریف کنید و هر تغییر کوچک در سیستم قدیمی شرکت، به یک کابوس به‌روزرسانی دستی برای تمام اعضا تبدیل شود.
این پراکندگی باعث ایجاد یک کابوس مدیریتی می‌شود. وقتی یک سیستم قدیمی (Legacy) متد احراز هویت خود را به‌روزرسانی می‌کند، پیکربندی تک‌تک کلاینت‌ها باید به‌صورت دستی تغییر کند. این اصطکاک عملیاتی اغلب باعث توقف استقرار عامل‌های هوش مصنوعی در محیط‌های سازمانی می‌شود؛ محیط‌هایی که در آن‌ها امنیت و یکپارچگی غیرقابل مذاکره است.
Baize، یک محیط اجرای متن‌باز که با زبان Go 1.25+ توسعه یافته و تحت لایسنس MIT منتشر شده است، با تبدیل شدن به یک لایه اجرای متمرکز این معادله را تغییر می‌دهد. به‌جای پیکربندی سیستم‌های تجاری در هر کلاینت، شما مستندات OpenAPI را وارد کرده، فرآیند ورود را تکمیل می‌کنید و قوانین تأیید دسترسی (Write-approval audits) را یک‌بار در کنسول Baize تعریف می‌کنید.
طبق مستندات این پروژه، Baize سپس این قابلیت‌ها را از طریق یک نقطه اتصال HTTP قابل استریم (Streamable HTTP endpoint) به هر کلاینتی که از پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) پشتیبانی کند، صادر می‌کند. در این ساختار، کلاینت (مثلاً Cursor) تصمیم می‌گیرد کدام ابزار فراخوانی شود، اما Baize عملیات واقعی و احراز هویت با سیستم قدیمی را مدیریت می‌کند.
تفکیک تصمیم‌گیری از اجرا
نکته کلیدی در معماری Baize، درک دقیق محل وقوع تصمیم‌گیری است. وقتی ابزارها صادر می‌شوند، Baize دیگر کنترلی روی مرحله «استدلال» یا Reasoning ندارد. مدل زبانی موجود در Cursor یا مدل موجود در Claude Desktop همچنان تصمیم می‌گیرد چه ابزاری فراخوانی شود و چه آرگومان‌هایی برای آن ارسال گردد.
به نقل از مستندات فنی Baize، این سیستم تنها دو مؤلفه خاص را صادر می‌کند:
- کاتالوگ ابزارها (Tool Catalog): شامل نام ابزار، شرح آن و اسکیمای پارامترها.
- کانال اجرا (Execution Channel): مسیری که پس از تصمیم کلاینت برای فراخوانی، جهت فعال‌سازی ابزار استفاده می‌شود.
در این مسیر صادرات، حلقه‌های داخلی ReAct، مدل اصلی، لایه تصمیم‌گیری، حافظه و فشرده‌سازی زمینهٔ Baize دخالت نمی‌کنند. این طراحی تضمین می‌کند که لایه تصمیم‌گیری در سمت کلاینت آزاد بماند — یعنی اینکه کاربر در Cursor از چه مدلی استفاده می‌کند به Baize مربوط نیست — در حالی که لایه اجرا برای حفظ امنیت، متمرکز باقی می‌ماند.
حفاظ‌های امنیتی چهارلایه
برای جلوگیری از حذف تصادفی داده‌های محیط عملیاتی (Production) توسط عامل‌های هوش مصنوعی، Baize چهار محدودیت سخت‌گیرانه را در سیاست صادرات خود پیاده کرده است. در اینجا «فقط خواندنی» (Read-only) صرفاً یک شعار تبلیغاتی نیست، بلکه مجموعه‌ای از موانع فنی است. این رویکرد یادآور مکانیزم‌های کنترلی است که در گیت‌وی‌های قطعی برای جلوگیری از رفتارهای ریسکی عامل‌ها به کار می‌روند تا از اجرای دستورات غیرمنتظره جلوگیری شود.
- لایه ۱: فیلترینگ متدهای HTTP: به‌صورت پیش‌فرض، تنها متدهای GET و HEAD صادر می‌شوند. Baize متد HTTP هر ابزار را بازرسی می‌کند و هر متد دیگری مسدود می‌شود، مگر اینکه ابزار به‌طور صریح با برچسب
force_allowعلامت‌گذاری شده باشد. - لایه ۲: رد کلمات کلیدی: Baize می‌تواند به‌عنوان یک کلاینت به سرورهای MCP خارجی متصل شود. ابزارهایی که از این سرورها می‌آیند، اگر در نام یا شرح آن‌ها کلماتی مانند
insert،update،delete،drop،truncateیاexecute_writeوجود داشته باشد، به‌طور سخت‌گیرانه رد می‌شوند. این ابزارها حتی اگر کاربر سعی کند ازforce_allowاستفاده کند، باز هم مسدود می‌مانند. - لایه ۳: گیت تأیید انسانی: هر عملیاتی که در Baize با برچسب «نیاز به تأیید انسان قبل از فراخوانی» (مانند ایجاد یک رکورد جدید) مشخص شده باشد، به‌طور خودکار از سطح صادرات حذف می‌شود. از آنجایی که کانال صادرات فاقد کارت تأیید (Approval Card) است، نمایش این ابزارها باعث می‌شد بررسی انسانی به‌طور خطرناکی دور زده شود.
- لایه ۴: اعتبارسنجی لحظه‌ای: سیاست‌های دسترسی در لحظه فراخوانی (Invocation) دوباره بررسی می‌شوند. ابزارها یک‌بار هنگام ثبت در کاتالوگ MCP و بار دیگر هنگام فراخوانی واقعی چک می‌شوند. اگر ابزاری در بک‌اند Baize غیرفعال شود، فراخوانی کلاینت خارجی فوراً با شکست مواجه می‌شود و هیچ شکاف زمانی بین لیست کاتالوگ و وضعیت واقعی ابزار وجود نخواهد داشت.
پل ارتباطی هویت و انتقال داده
مدیریت دسترسی در Baize از طریق MCP Streamable HTTP بدون وضعیت (Stateless) و با استفاده از کلیدهای Bearer در هدر درخواست‌ها انجام می‌شود. لایه انتقال برای جداسازی سخت‌گیرانه طراحی شده است:
- مدیریت کلیدها: کلیدها فقط به‌صورت هش ذخیره می‌شوند و هرگز به‌صورت متن ساده (Plaintext) ذخیره نمی‌شوند. نبود کلید یا اشتباه بودن آن منجر به خطای 401 می‌شود.
- جداسازی هویت: به هر کلاینت (مثلاً «کلاینت Cursor» در مقابل «کلاینت Claude Desktop») یک هویت صادراتی مجزا و یک کلید منحصربه‌فرد اختصاص می‌یابد. این کار از آلودگی متقاطع بین کلاینت‌ها جلوگیری می‌کند.
- ابطال فوری: کلیدها را می‌توان در هر لحظه ابطال کرد که منجر به قطع فوری اتصال آن کلاینت خاص می‌شود. علاوه بر این، یک سوئیچ اصلی (Master Toggle) وجود دارد که در صورت فعال شدن، برای تمام درخواست‌ها خطای 503 برمی‌گرداند.
نکته حیاتی این است که Baize از «پل هویت» (Identity Bridging) برای مدیریت وضعیت‌های ورود به APIهای قدیمی استفاده می‌کند. هر هویت صادراتی به یک هویت داخلی مجزا با فضای نام (Namespace) نشست مخصوص به خود متصل است که با پیشوند mcp-export-id: به همراه شناسه هویت تعریف می‌شود.
وقتی کاربر در Cursor ابزاری را فراخوانی می‌کند، Baize از اعتبارنامه‌هایی که پیش‌تر برای آن «هویت Cursor» خاص پیکربندی شده است، برای دسترسی به سیستم قدیمی استفاده می‌کند. «کلید Claude Desktop» از هویت متفاوت و وضعیت ورود متفاوتی استفاده می‌کند. در نتیجه، کاربر نهایی هرگز صفحه ورود سیستم قدیمی را نمی‌بیند و اعتبارنامه‌ها هرگز به سمت کلاینت نشت نمی‌کنند.
گردش‌کار پیاده‌سازی
راه‌اندازی این خط لوله شامل سه گام اصلی است:
۱. اتصال سیستم تجاری: در کنسول Baize، مستندات OpenAPI را وارد کنید، فرآیند ورود را به اتمام برسانید و قوانین تأیید را پیکربندی کنید.
۲. ایجاد هویت صادراتی: یک هویت صادراتی خاص و یک کلید Bearer متناظر در بخش تنظیمات تولید کنید.
۳. اتصال کلاینت: نقطه اتصال MCP Streamable HTTP و کلید Bearer را در کلاینت عامل مورد نظر (Cursor، Claude Desktop یا هر ابزار پشتیبانی‌کننده از MCP) وارد کنید.
این قابلیت، با تکیه بر کارهای قبلی پروژه در زمینه یکپارچه‌سازی سیستم‌های قدیمی جاوا (۱۰ ساله) بدون تغییر در کد، حلقه ارتباطی دوطرفه را کامل می‌کند. اکنون Baize می‌تواند ابزارها را از سرورهای خارجی دریافت کند و کاتالوگ متصل‌شده‌ی خود را به هر کلاینت تیمی ارسال نماید.
برای یک توسعه‌دهنده، این رویکرد پشته‌ی هوش مصنوعی را از یک مدل «کلاینت‌محور» به یک مدل «اجرا‌محور» تغییر می‌دهد. شما دیگر به کلاینت عامل اعتماد نمی‌کنید تا منطق حساس تجاری یا اعتبارنامه‌ها را مدیریت کند؛ بلکه با کلاینت به‌عنوان یک رابط کاربری نازک (Thin UI) برای یک موتور اجرای متمرکز و حساب‌رسی‌شده برخورد می‌کنید.
این معماری به‌طور مؤثری استدلال LLM (که در کلاینت می‌ماند) را از اختیار سیستم (که در Baize می‌ماند) جدا می‌کند. این امر به تیم‌ها اجازه می‌دهد مدل‌های خود را در Cursor یا Claude بدون اینکه نیاز باشد دوباره به پیکربندی‌های API تجاری دست بزنند، تعویض کنند.
برای مشاهده نحوه مدیریت پشته‌های قدیمی شما، می‌توانید کد منبع را در گیت‌هاب به آدرس https://github.com/rebornace/baize بررسی کنید یا قابلیت MCP Export را با یک کلید Read-only آزمایش نمایید.
گام بعدی شما
- اگر از سیستم‌های Legacy با مستندات OpenAPI استفاده می‌کنید، Baize را برای متمرکز کردن دسترسی‌های تیمتان تست کنید.
- برای بررسی لایه‌های امنیتی، کد منبع را در گیت‌هاب بررسی کرده و متدهای فیلترینگ را با نیازهای سازمانتان تطبیق دهید.
- قابلیت MCP Export را با یک کلید Read-only آزمایش کنید تا سرعت پاسخ‌دهی لایه انتقال را بسنجید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو