WeavePort: حذف نیاز به بازنویسی C# برای پلاگین‌های هوش مصنوعی

تصور کنید یک برنامه‌نویس C# هستید که می‌خواهد یک دستیار هوش مصنوعی بسازد. شما می‌خواهید از قدرتمندترین کتابخانه‌های هوش مصنوعی پایتون استفاده کنید، اما نمی‌خواهید کل زیرساخت سازمانی خود را تغییر دهید یا ابزارهای موجود در پایتون و تایپ‌اسکریپت را دوباره در C# بنویسید. با WeavePort، که یک محیط اجرای پلاگین (Plugin Runtime) متن‌باز است، دیگر نیازی به بازنویسی ابزارهای موجود در زبان‌های دیگر نیست و می‌توانید آن‌ها را مستقیماً به‌عنوان پلاگین‌های جایگزین‌پذیر در اکوسیستم .NET ادغام کنید، بدون اینکه پایداری یا امنیت سیستم را فدا کنید.

ادغام قابلیت‌های هوش مصنوعی معمولاً توسعه‌دهندگان را در یک دوراهی سخت قرار می‌دهد. بسیاری از پیشرفته‌ترین کتابخانه‌ها در پایتون هستند، اما برنامه‌های سازمانی اغلب روی .NET بنا شده‌اند. طبق مستندات این پروژه، راهکار سنتی یا بازنویسی ابزار در C# بود که منجر به نگهداری دو نسخه از یک منطق می‌شد، یا مهاجرت کامل برنامه به زبانی که شاید برای محیط سازمانی مناسب نبود. انتخاب C# برای بدنه اصلی برنامه نباید به این معنا باشد که برای هر قابلیتی که در آینده نیاز دارید نیز مجبور به استفاده از C# باشید. WeavePort این مشکل را با تبدیل اسکریپت‌های خارجی به «کارگران مدیریت‌شده» (Managed Workers) به‌جای کدهای داخلی حل می‌کند؛ این رویکرد اجازه می‌دهد دپارتمانی که با پایتون کار می‌کند، کدهای مفید خود را به پروژه اضافه کند، بدون اینکه نیاز باشد ابتدا به یک تیم C# تبدیل شود.

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

سازوکار اجرای بین‌زبانی

WeavePort با مدیریت فرآیندهای مجزا برای زبان‌های مختلف عمل می‌کند. پلاگین‌های پایتون در فرآیندهای پایتون و پلاگین‌های تایپ‌اسکریپت از طریق Node اجرا می‌شوند. میزبان .NET این کارگران را مدیریت می‌کند؛ به این معنا که پایتون را مستقیماً داخل یک Worker سی‌شارپ اجرا نمی‌کند. برای اجرای محلی از طریق stdio، درخواست‌ها و پاسخ‌ها به‌صورت JSONهای قاب‌بندی‌شده (Framed JSON) از طریق stdin و stdout منتقل می‌شوند. این یعنی برای هر پلاگین نیازی به تخصیص و مدیریت پورت‌های شنود (Listening Ports) نیست.

برای نمایش این سازوکار، یک مثال تحت عنوان «اتاق تصمیم» (Decision Room) در پروژه گنجانده شده است که در آن یک دستیار هوش مصنوعی، پیشنهادهای بهبود را با یکدیگر مقایسه می‌کند. این سیستم می‌تواند به‌طور یکپارچه بین یک استراتژی نوشته شده با C# و یک استراتژی نوشته شده با پایتون جابه‌جا شود. میزبان فارغ از زبان مورد استفاده، همان جریان کاری (Workflow) را اجرا می‌کند. در یکی از تست‌ها، با پیکربندی پیش‌فرض، گزینه «اتوماسیون پشتیبانی» (Automate support) برنده شد؛ اما با افزایش جریمه ریسک در استراتژی، نتیجه تغییر کرد و گزینه «بهبود مستندات» (Improve documentation) برنده شد.

جزئیات پیاده‌سازی فنی

در میزبان C#، پس از اتصال یک استراتژی به یک Worker، فراخوانی به صورت زیر آغاز می‌شود:

await using var client = new LocalPluginClient(strategy);
Evaluation evaluation = await client.CallAsync<DecisionRequest, Evaluation>("strategy.evaluate", new DecisionRequest(participant.Id, state), token);

وقتی زبان پایتون انتخاب شود، درخواست به تابعی در پلاگین پایتون می‌رسد که با دکوراتور @app.function("strategy.evaluate") علامت‌گذاری شده است. منطق پایتون امتیازها را با استفاده از یک مکانیسم خاص محاسبه می‌کند:

• ورودی‌ها: درخواست شامل اطلاعات شرکت‌کننده و وضعیت اتاق، از جمله پیشنهادها است.
• محاسبات: امتیازها از طریق ضرب «سود» در «وزن‌ها»، کسر «هزینه» ضرب در «وزن‌ها» و کسر «ریسک» ضرب در «وزن‌ها» و یک ضریب ریسک (RISK_MULTIPLIER) به دست می‌آیند.
• کنترل نسخه: در نسخه ۱ این استراتژی، ضریب ریسک برابر با ۱ است؛ اما در نسخه ۲، این عدد به ۱۰ افزایش یافته است.
• خروجی‌ها: پلاگین یک دیکشنری شامل شرکت‌کننده، منبع، ریسک‌ها، امتیازها و نسخه پلاگین (pluginVersion) را برمی‌گرداند.

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

کنترل داده‌ها و امنیت

یکی از حیاتی‌ترین ویژگی‌های WeavePort نحوه مدیریت دانش متعلق به برنامه است. به‌جای دادن دسترسی مستقیم به پایگاه‌داده به پلاگین پایتون، پلاگین باید از یک Callback یا فراخوانی بازگشتی به میزبان استفاده کند. این امر تضمین می‌کند که استراتژی نتواند به‌طور خودسرانه شناسه (ID) مشتری دیگری را در درخواست خود انتخاب کند.

• فراخوانی بازگشتی: پلاگین داده‌ها را از طریق await context.call_host("knowledge.read", {}) درخواست می‌کند.
• بررسی مجوز: WeavePort بررسی می‌کند که آیا مجوز knowledge.read صادر شده است یا خیر.
• منطق برنامه: میزبان .NET دقیقاً تصمیم می‌گیرد که کدام رکوردها بر اساس مستأجر (Tenant) متصل شده و پروفایل دانش، مجاز به دسترسی باشند.

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

ادغام با MCP و عملکرد

WeavePort همچنین از پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) پشتیبانی می‌کند. این سیستم می‌تواند یک سرور MCP محلی مورد اعتماد را اجرا کرده، ابزارهای آن را با استفاده از McpMethods.ListTools شناسایی کند و آن‌ها را تحت همان چرخه حیات میزبان و بودجه‌های ظرفیتی پلاگین‌های بومی فراخوانی نماید. این قابلیت به توسعه‌دهندگان اجازه می‌دهد از ابزارهای سازگار با MCP بدون نوشتن Wrapperهای جدید استفاده کنند.

برای مثال، فراخوانی یک ابزار نرمال‌سازی متن به این صورت است:

var result = await session.InvokeAsync(McpMethods.CallTool, JsonSerializer.SerializeToElement(new { name = "normalize", arguments = new { text = " hello world " } }));

اگرچه MCP برای مصرف ابزارهای موجود مفید است، اما به‌طور خودکار جایگزین Callbackهای بومی یا جریان‌های نتیجه (Result Streams) نمی‌شود. برنامه همچنان تصمیم می‌گیرد که دستیار مجاز به فراخوانی چه چیزی باشد. ادغام فعلی شامل شناسایی و فراخوانی ابزارهای stdio محلی است؛ سرورهای HTTP راه دور و درخواست‌های تعاملی بازگشتی به میزبان نیازمند ادغام‌های متفاوتی هستند.

بر اساس بنچمارک‌های انجام‌شده روی macOS arm64 با Node 24.21.0 و اسمبلی Hosting نسخه 0.3.0، هزینه‌های عبور از مرز فرآیندها قابل اندازه‌گیری اما برای واحدهای کاری قابل توجه، بسیار پایین است:

• فراخوانی‌های پروتکل بومی WeavePort: به‌طور متوسط حدود ۰.۰۵۷ میلی‌ثانیه.
• فراخوانی‌های MCP: به‌طور متوسط بین ۰.۰۸۶ تا ۰.۱۰۱ میلی‌ثانیه.
• فراخوانی‌های راه‌اندازی اولیه: بین ۵۹ تا ۱۱۱ میلی‌ثانیه.

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

مدیریت چرخه حیات پلاگین

این Runtime بخش‌های دشوار مدیریت فرآیند، از جمله راه‌اندازی، ضرب‌الاجل‌ها (Deadlines)، محدودیت‌های پذیرش و پاک‌سازی را بر عهده می‌گیرد. Workerها می‌توانند بر اساس چرخه حیات پیکربندی شده، حفظ شوند.

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

برای توسعه‌دهندگان، انتخاب بین استفاده از پلاگین در مقابل یک سرویس به مقیاس پروژه بستگی دارد:

• رابط معمولی (Ordinary Interface): بهترین گزینه برای افزونه‌های کوچک که کاملاً با C# نوشته شده‌اند.
• سرویس مجزا (Separate Service): بهترین گزینه برای قابلیت‌هایی که نیاز به استقرار مستقل، چندین برنامه مصرف‌کننده یا سیاست مقیاس‌پذیری خاص خود دارند.
• پلاگین مدیریت‌شده (Managed Plugin): بهترین گزینه برای رفتارهای قابل توجهی که باید جایگزین‌پذیر باشند یا با زبانی دیگر نوشته شوند، اما همچنان تحت مالکیت جریان کاری برنامه اصلی باقی بمانند.

این رویکرد سؤال اصلی توسعه‌دهنده را از «آیا مجبور به بازنویسی این هستم؟» به «آیا می‌توانم از این استفاده کنم؟» تغییر می‌دهد و به‌جای نحو زبان، بر ورودی‌ها، خروجی‌ها و مجوزها تمرکز می‌کند.

تست پیاده‌سازی

برای کسانی که می‌خواهند این پیاده‌سازی را تست کنند، پروژه تحت لایسنس MIT در گیت‌هاب در دسترس است. کاربران می‌توانند اسکریپت decision-room.sh را (با استفاده از شاخه v0.3.1) اجرا کنند تا مشاهده کنند چگونه تغییر زبان یک شرکت‌کننده، بدون تغییر در منطق میزبان، بر نتیجه نهایی تأثیر می‌گذارد.

نیازمندی‌ها برای اجرای این مراحل عبارتند از:

• .NET SDK (مطابق با آنچه در global.json انتخاب شده است).
• پایتون ۳.۱۱ به بالا به همراه venv و pip.

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

گام بعدی شما

• اگر پروژه‌ای در .NET دارید که نیاز به کتابخانه‌های تخصصی پایتون دارد، مخزن GitHub پروژه WeavePort را بررسی کنید.
• اسکریپت decision-room.sh را در شاخه v0.3.1 اجرا کنید تا تأثیر تغییر زبان پلاگین بر خروجی را مشاهده کنید.
• برای استفاده از این ابزار، .NET SDK و پایتون ۳.۱۱ به همراه venv را نصب داشته باشید.

اما تأثیر این رویکرد بر کاهش هزینه‌های استنتاج در مقیاس سازمانی موضوع دیگری است — به تحلیل ما درباره‌ی بهینه‌سازی GPU در محیط‌های توزیع‌شده مراجعه کنید.