ساخت AI agent روی VPS

یک عامل هوش مصنوعی (AI agent) در واقع چیست

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

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

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

ابزارها: یک agent چگونه عمل می‌کند

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

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

اینجا همان جایی است که کنترل شما قرار دارد. مدل می‌تواند درخواست اجرای یک دستور را بدهد، اما هیچ چیزی اجرا نمی‌شود مگر اینکه کد شما تصمیم به اجرای آن بگیرد. این فاصله همان جایی است که شما تاییدیه (approval prompts) برای اقدامات خطرناک، محدودیت‌هایی برای آنچه یک tool می‌تواند لمس کند، و لاگ (log) از تمام کارهای انجام شده توسط agent را قرار می‌دهید. امنیت یک agent به اندازه ابزارهایی که به آن می‌دهید و بررسی‌هایی که در مقابل آن‌ها قرار می‌دهید، ایمن است.

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

نوشتن یک integration جدید برای هر سرویس به صورت دستی، خیلی زود خسته‌کننده می‌شود. Model Context Protocol یا MCP، یک استاندارد باز است که این مشکل را حل می‌کند. به جای کدنویسی یک tool جدید برای فایل‌ها، database و issue tracker خود، agent را به یک MCP server متصل کنید که قبلاً این موارد را به عنوان tool ارائه داده است. agent از یک پروتکل واحد استفاده می‌کند؛ سرور وظیفه صحبت کردن با سیستم واقعی را بر عهده دارد.

مزیت این کار، استفاده مجدد (reuse) است. یک MCP server که شخص دیگری برای سرویسی که شما استفاده می‌کنید نوشته است، بدون نیاز به کدنویسی جدید برای integration، در دسترس agent شما قرار می‌گیرد، و سروری که شما می‌نویسید، توسط هر agent دیگری که از این پروتکل پشتیبانی می‌کند، قابل استفاده است. در یک VPS این موضوع اهمیت دارد، زیرا می‌توانید MCP serverها را به عنوان سرویس‌های کوچک و مجزا در کنار agent اجرا کنید، که هر کدام فقط دسترسی مورد نیاز خود را دارند. من مراحل را در running MCP servers on a VPS پوشش داده‌ام.

حافظه و بازیابی (Retrieval)

یک مدل زبانی هیچ حافظه‌ای بین فراخوانی‌ها ندارد. تمام آنچه درباره وظیفه فعلی می‌داند باید در هر مرحله به آن داده شود. برای یک کار کوتاه این کافی است، زیرا کل گفتگو در یک request جا می‌شود. برای هر چیزی طولانی‌تر، باید خودتان حافظه را مدیریت کنید و دو الگوی وجود دارد که دانستن آن‌ها ضروری است.

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

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

چندین agent، یک هماهنگ‌کننده

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

مزیت این کار، تمرکز است. یک sub-agent با یک وظیفه محدود و یک مجموعه ابزار کوچک، تصمیمات بهتری نسبت به یک generalist که با همه چیز سر و کله می‌زند، می‌گیرد، و بخش‌های مستقل می‌توانند همزمان اجرا شوند. هزینه آن هماهنگی (coordination) است که واقعی است، پس تا زمانی که یک وظیفه به وضوح به چیزی بیشتر نیاز ندارد، از یک agent واحد استفاده کنید. ساده شروع کنید و فقط زمانی agent اضافه کنید که یک agent به وضوح تحت فشار است.

Self-hosted یا Hosted: کدام مدل agent شما را اجرا می‌کند

مدل تنها بخشی از یک agent است که مجبور نیستید خودتان آن را اجرا کنید، و انتخاب محل قرارگیری آن بزرگترین تصمیمی است که خواهید گرفت. یک مدل hosted که از طریق یک API در دسترس است، قوی‌ترین استدلال را بدون نیاز به مدیریت عملیاتی به شما می‌دهد: شما متن می‌فرستید و متن دریافت می‌کنید. یک مدل self-hosted روی سرور خودتان اجرا می‌شود، که باعث می‌شود هر request خصوصی بماند، به جای هزینه per token، هزینه ثابت داشته باشد، و هرگز به بالا ماندن (uptime) شخص دیگری وابسته نباشد. معامله بر سر قابلیت و تلاش است. بهترین مدل‌های hosted از آنچه می‌توانید خودتان اجرا کنید جلوتر هستند، و اجرای مدل خودتان به معنای تامین حافظه کافی برای آن است.

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

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

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

یک agent که می‌تواند shell commands را اجرا کند و فایل‌ها را بنویسد، قدرتمند است و دقیقاً به همین دلیل خطرناک است. قضاوت مدل خوب است اما کامل نیست، و یک دستور اشتباه، یک bug، یا یک ورودی مخرب می‌تواند یک agent مفید را به agentی تبدیل کند که چیز اشتباهی را حذف می‌کند یا اطلاعات محرمانه را لو می‌دهد. کار امنیتی اختیاری نیست، و در یک سرور، این مهم‌ترین بخش است.

چند عادت، بخش اصلی مسئولیت را بر عهده دارند. agent را به عنوان یک unprivileged user اختصاصی اجرا کنید، هرگز به عنوان root، تا در صورت بروز اشتباه، محدودیت داشته باشد؛ همین استدلال در running services as an unprivileged user آمده است. اسرار آن، مانند API keys، را خارج از کد نگه دارید و فقط برای همان کاربر قابل خواندن باشد. و ابزارهایی که با سیستم در تماس هستند را sandbox کنید، تا agent فقط به آنچه واقعاً نیاز دارد دسترسی داشته باشد. برای یک مثال عملی از مقاوم‌سازی (hardening) یک self-hosted agent واقعی، running OpenClaw safely on a VPS را ببینید. اگر ترجیح می‌دهید از یک مدل hosted برای هوشمندی استفاده کنید، راهنمای مکمل در building an agent with Claude on a VPS همین ایده‌ها را با یک مدل خاص ترکیب می‌کند.

برای یک مثال عملی، building an OpenClaw-style personal agent این قطعات را به کار می‌گیرد، و اگر ترجیح می‌دهید از یک نسخه آماده استفاده کنید، با self-hosting Hermes Agent on a VPS یا running Agent Zero on your own server شروع کنید، و the best self-hosted AI agents in 2026 تمام گزینه‌های آماده‌ای که ما پوشش می‌دهیم را در کنار هم مقایسه می‌کند.

FAQ

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

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

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

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

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

MCP یا Model Context Protocol، یک استاندارد باز برای اتصال یک agent به ابزارها و منابع داده است. شما لزوماً به آن نیاز ندارید، زیرا می‌توانید هر tool را به صورت دستی بنویسید. MCP با اجازه دادن به شما برای استفاده مجدد از سرورهای موجود برای سرویس‌های رایج و ارائه سیستم‌های خودتان برای هر agent، در آن کار صرفه‌جویی می‌کند. این یک قابلیت راحتی است که با افزایش تعداد integrationها، ارزشمند می‌شود.

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

اگر آن را مهار کنید، می‌تواند ایمن باشد. یک agent که دستورات را اجرا می‌کند، تنها به اندازه حسابی که با آن اجرا می‌شود و ابزارهایی که اجازه می‌دهید، ایمن است. آن را به عنوان یک unprivileged user اجرا کنید، اسرار آن را دور از دسترس نگه دارید، ابزارهایی که با filesystem در تماس هستند را sandbox کنید، و برای اقداماتی که بازگشت‌پذیری سختی دارند، تاییدیه بخواهید. با agent مانند یک کد غیرقابل اعتماد که هوشمند است رفتار کنید و فقط آنچه را که وظیفه نیاز دارد به آن بدهید.