چرا Rust برای سیستم‌های ایجنت مستقل از پروایدر مناسب است؟

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

این قاب‌بندی سؤال‌ها را عوض می‌کند. نه «این هفته کدام مدل باهوش‌تر است؟» بلکه «وقتی این پروایدر خوابید یا منسوخ شد یا یهو گران شد چه می‌شود؟ این ایجنت به چه چیزهایی حق دست‌زدن دارد و چه چیزی ثابت می‌کند از مرز رد نشده؟ کدام بخش‌ها باید قطعی باشند، با اینکه مدل نیست؟» سیستم‌های ایجنت سیستم‌های بک‌اندند با یک هستهٔ احتمالی و همان سخت‌گیری بک‌اند را می‌خواهند.

سیستم Rustای که رویش کار کردم از طراحی مستقل از پروایدر بود: هر پروایدر مدل پشت یک رابط واحد می‌نشیند تا عوض کردن یا اضافه کردنش یک تغییر محدود باشد، نه بازنویسی. این انتزاع برای خود انتزاع نیست؛ پروایدرها قیمت و سقف نرخ و شرایط و کیفیت را با برنامهٔ خودشان عوض می‌کنند، نه تو. سیستمی که به SDK یک فروشنده جوش خورده همهٔ این‌ها را به‌عنوان نقشهٔ راه ناخواسته به ارث می‌برد.

Arlene از سمت کاربر همان قاعده را دارد: مدل محلی و پروایدر ابری از یک سطح یکسان دیده می‌شوند، پس خط لوله‌ای که کاربر امروز طراحی می‌کند فردا که نظرش دربارهٔ مدل عوض شد باز هم اجرا می‌شود. استقلال از پروایدر هم پوشش تجاری است هم مهندسی؛ مجبورت می‌کند تعریف کنی سیستمت واقعاً از یک مدل چه می‌خواهد، با تایپ‌های خودت، نه اینکه واژگان یک فروشنده در همهٔ لایه‌ها نشت کند.

معماری ایجنت Rust عمداً چندلایه است. در تجربهٔ من جداسازی مفید این شکلی است: لایهٔ پروایدر که فقط حرف زدن با مدل را بلد است؛ لایهٔ ارکستراسیون که مالک حلقهٔ ایجنت و وضعیت و سیاست‌هاست؛ لایهٔ ابزارها که هر قابلیت در آن صریح و مجوزدار است؛ و رابط‌های بیرونی — API و CLI و UI — که مصرف‌کنندهٔ واقعی لمسشان می‌کند. هر لایه بی‌دیگری قابل تست است و این وقتی یکی از مواد سیستم مدلی است که جواب‌هایش تغییر می‌کند، فوق‌العاده مهم می‌شود.

مرز صادق یک وضعیت امنیتی هم هست و امنیت برای من نقطهٔ شروع است نه پایان. ایجنتی که می‌تواند ابزار صدا بزند ایجنتی است که می‌شود با حرف وادارش کرد ابزار اشتباه را صدا بزند. نگه داشتن ابزارها پشت یک لایهٔ باریک و تایپ‌دار و مجوزدار — به جای اینکه خروجی مدل سرگردان به اجرای رشته‌ای برسد — فرق ایجنتی است که می‌شود حسابرسی‌اش کرد با ایجنتی که فقط به آن امید داری. همین غریزه است که Sonobe برای ایجنت‌ها مستندات و پشتیبانی MCP تولید می‌کند: ایجنت‌ها داخل سیستمی که قواعد خودش را توضیح می‌دهد بهتر کار می‌کنند.

Rust در زیرساخت ایجنت به سه دلیل مشخص پیچیدگی‌اش را پس می‌دهد. اول عملکرد قابل پیش‌بینی: ارکستراتوری که کلی فراخوانی هم‌زمان مدل و استریم و اجرای ابزار را جابه‌جا می‌کند نباید خودش به سیستمی که از قبل متغیر است، غافلگیری تأخیر و حافظه اضافه کند. دوم سیستم تایپ: وقتی پیام پروایدر و آرگومان ابزار و وضعیت ایجنت تایپ‌های جدا هستند، دستهٔ کاملی از «مدل چیز عجیبی برگرداند و همه‌جا جاری شد» اصلاً کامپایل نمی‌شود. سوم هم‌روندی قابل فهم؛ مالکیت (ownership) وضعیت مشترک را به یک تصمیم صریح تبدیل می‌کند و دقیقاً همین را می‌خواهی وقتی قدم‌های موازی ایجنت به یک کانتکست دست می‌زنند.

هیچ‌کدام از این‌ها Rust را برای هر چیز ایجنت‌شکلی درست نمی‌کند. نمونهٔ اولیه و رپر نازک و آزمایشی که دورش می‌اندازی را پایتون سریع‌تر می‌رساند و من هم برای کارهای کنار ایجنت از پایتون استفاده می‌کنم. Rust برای آن لایه‌ای است که باید وقتی همهٔ دور و برش — مدل و پروایدر و پرامپت — مدام عوض می‌شود، ثابت رفتار کند؛ دقیقاً همان لایه‌ای که محصول ایجنت جدی با آن زنده می‌ماند یا می‌میرد.

Arlene جایی است که این ایده‌ها به جای پلتفرم، یک کاربر تنها را ملاقات می‌کنند: دستیار چندسکویی Electron با طراح خط لولهٔ کشیدن و رها کردنی در حال‌وهوای n8n؛ ایجنت‌ها و ابزارها به جای زنجیرهٔ پرامپت پنهان، قطعه‌های دیدنی و قابل جابه‌جایی می‌شوند. هارنس‌های آماده شکل‌های رایج کار را پوشش می‌دهند و قابلیت‌های خودیادگیری و خودبهبودی کمک می‌کنند رفتار خودش را به مرور بهتر کند.

دسکتاپ محدودیت‌ها را عوض می‌کند نه اصول را. خط لوله باز استقلال از پروایدر می‌خواهد (مدل محلی در قطار، مدل ابری پشت میز). ابزار باز مجوز صریح می‌خواهد — بیشتر هم می‌خواهد، چون حالا روی ماشین خود کاربر اجرا می‌شود. و شخصی‌سازی باید ساختاری باشد نه یک صفحهٔ تنظیمات؛ اگر کاربر نتواند شکل کار دستیار را عوض کند، دستیار من می‌ماند که او فقط اپراتورش است. Arlene را طوری می‌سازم که بعداً متن‌باز شود؛ معماری‌اش باید از خوانده شدن توسط بقیه سالم بیرون بیاید و این بهترین فشار طراحی‌ ای است که می‌شناسم.

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

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