آموزش ساخت AI agent روی سرور مجازی VPS

ماهیت واقعی یک AI agent

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

بخش مهم، همان اقدام (action) است. یک مدل زبانی به‌تنهایی فقط متن تولید می‌کند. این مدل نمی‌تواند فایلی را بخواند، API فراخوانی کند یا دستوری را اجرا نماید. یک agent مجموعه‌ای از ابزارها را که مدل اجازه استفاده از آن‌ها را دارد، به همراه روشی برای درخواست استفاده از آن‌ها در اختیارش می‌گذارد. وقتی مدل می‌خواهد در وب جستجو کند یا فایلی بنویسد، خودش کار را انجام نمی‌دهد. مدل یک درخواست ساختاریافته صادر می‌کند، کد شما ابزار را اجرا می‌کند و پاسخ به‌عنوان ورودی بعدی به مدل بازمی‌گردد. مدل قضاوت را ارائه می‌دهد و سرور شما نقش بازوهای اجرایی را ایفا می‌کند.

همه وظایف به یک agent نیاز ندارند و استفاده پیش‌فرض از آن یک اشتباه رایج است. اگر مراحل از قبل مشخص باشند، یک اسکریپت ساده، سریع‌تر، مطمئن‌تر و کارآمدتر است. «این صفحه را هر ساعت بررسی کن و قیمت را برایم ایمیل کن» یک وظیفه زمان‌بندی‌شده (scheduled job) است، نه یک agent. زمانی یک agent بسازید که مسیر از پیش تعیین‌شده نباشد و مدل مجبور باشد آنچه را که می‌یابد بررسی کرده و برای گام بعدی تصمیم‌گیری کند. هزینه استفاده از یک agent، غیرقابل‌پیش‌بینی بودن آن است؛ بنابراین تنها زمانی این هزینه را بپردازید که انعطاف‌پذیری آن ارزشش را داشته باشد.

ابزارها: نحوه عملکرد یک عامل

ابزار، هر قابلیتی است که در اختیار مدل قرار می‌دهید و به‌قدری دقیق توصیف شده است که مدل بداند چه زمانی باید از آن استفاده کند. خواندن یک فایل، اجرای یک دستور shell، پرس‌وجو از یک پایگاه داده، یا ارسال یک پیام: هر کدام یک ابزار با نام، توضیحی کوتاه و فهرستی از ورودی‌ها هستند. شما ابزارها را تعریف می‌کنید؛ مدل تصمیم می‌گیرد که چه زمانی آن‌ها را فراخوانی کند. جستجوی وب معمولاً اولین ابزاری است که ارزش افزودن دارد و اگر در حال حاضر نمونه SearXNG خود را اجرا می‌کنید، می‌توانید آن را به backend جستجوی عامل تبدیل کنید و از پرداخت هزینه برای APIهای جستجوی تجاری بی‌نیاز شوید.

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

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

MCP: روشی استاندارد برای اتصال ابزارها

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

مزیت اصلی این روش، قابلیت استفادهٔ مجدد است. سرور MCP که شخص دیگری برای سرویسی که شما استفاده می‌کنید نوشته است، بدون نیاز به کدنویسی جدید در دسترس عامل شما قرار می‌گیرد و سروری که شما می‌نویسید توسط هر عاملی که از این پروتکل پشتیبانی کند، قابل استفاده است. برخی از برنامه‌های self-hosted اکنون یکی از این سرورها را همراه خود ارائه می‌دهند: openGym، یک ردیاب تمرینات ورزشی، یک سرور MCP فقط‌خواندنی ارائه می‌دهد تا عامل بتواند بدون داشتن دسترسی برای تغییر داده‌ها، به پرسش‌های مربوط به تاریخچهٔ تمرینات شما پاسخ دهد. این موضوع در یک VPS اهمیت دارد، زیرا می‌توانید سرورهای MCP را به‌عنوان سرویس‌های کوچک و مجزا در کنار عامل اجرا کنید که هر کدام فقط دسترسی‌های موردنیاز خود را دارند. هنگامی که سیستم‌های پشت این سرورها در شبکه‌ای قرار دارند که VPS به آن دسترسی ندارد (مانند پایگاه‌داده‌ای در خانه یا دفتر کار)، معرفی آن شبکه به tailnet با استفاده از یک subnet router به عامل اجازه می‌دهد تا از طریق آدرس‌های خصوصی به آن‌ها دسترسی پیدا کند، بدون آنکه چیزی را در معرض اینترنت عمومی قرار دهد. من نحوهٔ راه‌اندازی این مورد را در اجرای سرورهای MCP روی یک VPS توضیح داده‌ام.

حافظه و بازیابی

یک مدل زبانی بین فراخوانی‌ها هیچ حافظه مستقلی ندارد. هر آنچه درباره وظیفه فعلی می‌داند، باید در هر نوبت به آن داده شود. برای یک کار کوتاه، این موضوع مشکلی ایجاد نمی‌کند، زیرا کل گفتگو در یک درخواست جای می‌گیرد. میزان گنجایش به پنجره زمینه (context window) بستگی دارد و مدلی که توسط Ollama میزبانی می‌شود، یک مقدار پیش‌فرض کوچک دارد که به‌طور خودکار قدیمی‌ترین نوبت‌ها را حذف می‌کند؛ بنابراین تنظیم num_ctx متناسب با ترافیکی که حلقه شما تولید می‌کند پیش از آنکه عامل (agent) را به فراموشی متهم کنید، اقدامی ضروری است. برای کارهای طولانی‌تر، باید حافظه را خودتان مدیریت کنید و دو الگو برای این کار وجود دارد که ارزش شناختن دارند.

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

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

چندین عامل، یک هماهنگ‌کننده

یک عامل با ابزارهای متعدد برای اکثر وظایف کافی است. زمانی که یک کار بزرگ است یا به‌طور طبیعی به بخش‌های مختلف تقسیم می‌شود، ساختار متفاوتی کارآمدتر است: یک عامل هماهنگ‌کننده که وظایف را به زیر-عامل‌های تخصصی محول می‌کند. هماهنگ‌کننده هدف را به قطعات کوچک‌تر تقسیم کرده، هر قطعه را به زیر-عاملی که برای آن نوع کار ساخته شده می‌سپارد و در نهایت نتایج را با هم ترکیب می‌کند. تفویض وظایف نیازمند یک کانال ارتباطی بین بخش‌هاست و ساده‌ترین نسخهٔ آن هم‌اکنون روی سرور شما در دسترس است: دو نشست Claude Code روی یک VPS می‌توانند برای یکدیگر پیام ارسال کنند، که روشی کم‌هزینه برای درک نحوهٔ عملکرد انتقال وظایف پیش از ساخت هرگونه زیرساخت هماهنگی اختصاصی است.

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

میزبانی شخصی یا سرویس ابری: مدل شما کجا اجرا می‌شود

مدل، تنها بخشی از یک عامل (agent) است که مجبور نیستید خودتان آن را اجرا کنید؛ انتخاب محل اجرای آن، مهم‌ترین تصمیمی است که خواهید گرفت. یک مدل میزبانی‌شده که از طریق API در دسترس است، قوی‌ترین قابلیت‌های استدلال را بدون نیاز به مدیریت زیرساخت در اختیار شما می‌گذارد: متن را ارسال می‌کنید و پاسخ را دریافت می‌کنید. یک مدل خود-میزبان (self-hosted) روی سرور شخصی شما اجرا می‌شود که باعث می‌شود تمام درخواست‌ها خصوصی بمانند، هزینه به‌صورت ثابت پرداخت شود (به‌جای پرداخت به ازای هر توکن) و عملکرد آن به پایداری سرویس‌دهنده دیگری وابسته نباشد. هزینه این استقلال، توانایی کمتر و تلاش بیشتر است. بهترین مدل‌های میزبانی‌شده از مدل‌هایی که می‌توانید شخصاً اجرا کنید پیشرفته‌تر هستند و اجرای مدل شخصی مستلزم تأمین حافظه کافی برای بارگذاری آن است.

نکته آخر، چالش عملی کار است. مدل باید در حافظه سرور شما جای بگیرد و اگر از GPU استفاده می‌کنید، باید در حافظه ویدیویی (VRAM) آن قرار گیرد. مدلی که برای سخت‌افزار شما بیش از حد بزرگ باشد، بارگذاری نخواهد شد. پیش از برنامه‌ریزی برای یک عامل خود-میزبان، بررسی کنید که آیا مدل مورد نظر شما با سخت‌افزار فعلی‌تان سازگار است یا خیر:

اگر اعداد با هم همخوانی ندارند، سه راه پیش رو دارید: انتخاب یک مدل کوچک‌تر، استفاده از quantization تهاجمی‌تر برای کاهش حجم مدل، یا استفاده از یک API میزبانی‌شده برای استدلال و نگهداری ابزارها و داده‌ها روی سرور شخصی. بسیاری از عوامل خود-میزبان با یک مدل محلی از طریق Ollama روی یک VPS شروع می‌شوند و برای دشوارترین مراحل، به یک API میزبانی‌شده متوسل می‌شوند.

سرور بخش خطرناک ماجرا است

عاملی که می‌تواند دستورات shell را اجرا کند و فایل بنویسد، قدرتمند است و دقیقاً به همین دلیل خطرناک محسوب می‌شود. قضاوت مدل خوب است اما بی‌نقص نیست؛ یک دستور اشتباه، یک باگ یا ورودی مخرب می‌تواند یک عامل مفید را به عاملی تبدیل کند که فایل‌های اشتباه را حذف می‌کند یا اطلاعات محرمانه را لو می‌دهد. اقدامات امنیتی اختیاری نیستند و در یک سرور، این مهم‌ترین بخش کار است.

چند عادت ساده، بخش بزرگی از بار امنیتی را به دوش می‌کشند. عامل را با یک کاربر اختصاصی و بدون دسترسی‌های ویژه (unprivileged) اجرا کنید و هرگز از root استفاده نکنید تا در صورت بروز خطا، خسارت محدود بماند؛ منطق مشابهی در اجرای سرویس‌ها با کاربر بدون دسترسی ویژه وجود دارد. اسرار آن، مانند API keys را خارج از کد نگه دارید و دسترسی به آن‌ها را فقط برای همان کاربر محدود کنید. ابزارهایی که با سیستم در تعامل هستند را در محیط sandbox قرار دهید تا عامل فقط به آنچه واقعاً نیاز دارد دسترسی داشته باشد. اگر ترجیح می‌دهید تمام بررسی‌ها را دستی ننویسید، پلاگین‌های DeepSeek Harness که ارزش نصب دارند همان موارد را به صورت آماده پوشش می‌دهند: قوانین دسترسی ابزارها، اسکن برای جلوگیری از prompt injection و تعیین سقف هزینه برای عامل پیش از توقف خودکار. برای مشاهده یک نمونه عملی از ایمن‌سازی یک عامل self-hosted واقعی، به اجرای ایمن OpenClaw روی VPS مراجعه کنید. اگر ترجیح می‌دهید برای بخش هوش مصنوعی از یک مدل میزبانی‌شده (hosted) استفاده کنید، راهنمای همراه در ساخت یک عامل با Claude روی VPS همین ایده‌ها را به کار گرفته و یک مدل خاص را در پشت آن‌ها قرار می‌دهد.

برای یک نمونه عملی، ساخت یک عامل شخصی به سبک OpenClaw این قطعات را کنار هم می‌گذارد و اگر ترجیح می‌دهید از یک نمونه آماده استفاده کنید، با میزبانی شخصی Hermes Agent روی VPS یا اجرای Agent Zero روی سرور شخصی شروع کنید، و بهترین عامل‌های هوش مصنوعی self-hosted در سال 2026 تمام گزینه‌های آماده‌ای که پوشش داده‌ایم را با هم مقایسه می‌کند.

FAQ

تفاوت بین یک AI agent و یک chatbot چیست؟

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

آیا برای اجرای یک AI agent روی VPS به GPU نیاز دارم؟

فقط در صورتی که مدل را روی سرور شخصی خود میزبانی (self-host) کنید. حلقهٔ agent، ابزارها و حافظه، کدهای معمولی هستند که به خوبی روی یک VPS عادی بدون GPU اجرا می‌شوند. GPU زمانی اهمیت پیدا می‌کند که بخواهید مدل زبانی را روی سخت‌افزار خودتان اجرا کنید، زیرا مدل باید در حافظه جای بگیرد. اگر از یک مدل میزبانی‌شده از طریق API استفاده کنید، محاسبات سنگین در جای دیگری انجام می‌شود و یک VPS معمولی کافی است.

پروتکل MCP چیست و آیا برای ساخت یک agent به آن نیاز دارم؟

MCP یا Model Context Protocol، یک استاندارد باز برای اتصال یک agent به ابزارها و منابع داده است. شما لزوماً به آن نیاز ندارید، چرا که می‌توانید هر ابزار را به صورت دستی بنویسید. MCP با امکان استفادهٔ مجدد از سرورهای موجود برای سرویس‌های رایج و ارائهٔ سیستم‌های خودتان برای استفاده توسط هر agent، این کار را برای شما ساده می‌کند. این یک ابزار تسهیل‌کننده است که با افزایش تعداد یکپارچه‌سازی‌ها، ارزش آن مشخص می‌شود.

آیا دادن دسترسی به یک AI agent برای سرور من امن است؟

اگر آن را محدود کنید، می‌تواند امن باشد. امن بودن یک agent که دستورات را اجرا می‌کند، به حسابی که با آن اجرا می‌شود و ابزارهایی که به آن اجازه می‌دهید، بستگی دارد. آن را با یک کاربر بدون امتیاز (unprivileged) اجرا کنید، اسرار (secrets) آن را دور از دسترس نگه دارید، ابزارهایی که با سیستم فایل در تماس هستند را در sandbox قرار دهید و برای اقداماتی که بازگشت آن‌ها دشوار است، تأییدیه بگیرید. با agent مانند کدی غیرقابل‌اعتماد رفتار کنید که اتفاقاً هوشمند است و فقط دسترسی‌هایی را به آن بدهید که برای انجام وظیفه نیاز دارد.