آموزش ساخت 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) بستگی دارد و یک مدل self-hosted که توسط Ollama روی سروری با کمتر از 24 GiB حافظه GPU یا بدون آن اجرا می‌شود، به‌طور پیش‌فرض از یک پنجره کوچک 4k استفاده می‌کند که قدیمی‌ترین نوبت‌های گفتگو را به‌آرامی حذف می‌کند؛ بنابراین تنظیم num_ctx متناسب با ترافیکی که حلقهٔ شما تولید می‌کند پیش از آنکه عامل (agent) را به فراموشی متهم کنید، ارزشمند است. برای کارهای طولانی‌تر، باید حافظه را خودتان مدیریت کنید و دو الگو برای این کار وجود دارد که دانستن آن‌ها مفید است.

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

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

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

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

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

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

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

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

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

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

عاملی که می‌تواند دستورات 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 مانند کدی غیرقابل‌اعتماد رفتار کنید که اتفاقاً هوشمند است و فقط دسترسی‌هایی را به آن بدهید که برای انجام وظیفه نیاز دارد.