انواع ایجنت‌های هوش مصنوعی و کاربرد هر کدام

انواع ایجنت‌های هوش مصنوعی

انواع ایجنت‌های هوش مصنوعی از یک طبقه‌بندی واحد سرچشمه می‌گیرند: ایجنت‌های واکنشی ساده (simple reflex)، واکنشی مبتنی بر مدل (model-based reflex)، مبتنی بر هدف (goal-based)، مبتنی بر مطلوبیت (utility-based) و ایجنت‌های یادگیرنده (learning agents). هر نام بیانگر یک ویژگی است: این‌که ایجنت چقدر از گذشته را به یاد می‌آورد و پیش از اقدام، تا چه حد آینده را پیش‌بینی می‌کند. دو اصطلاح دیگر، یعنی چند-ایجنت (multi-agent) و سلسله‌مراتبی (hierarchical)، نحوه اتصال چندین ایجنت به یکدیگر را توصیف می‌کنند، نه نحوه تصمیم‌گیری یک ایجنت واحد.

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

عامل‌های بازتابی ساده: یک شرط، یک کنش

یک عامل بازتابی ساده، ورودی فعلی را به یک کنش نگاشت می‌کند و هیچ حافظه‌ای از رویدادهای پیشین نگه نمی‌دارد. اگر دما بالای 25 باشد، فن را روشن کن. این تمام مکانیزم آن است.

شما تقریباً به‌طور قطع یکی از آن‌ها را اجرا کرده‌اید. یک webhook که یک workflow در n8n را فعال می‌کند، فرمی را می‌خواند و یک ردیف در دیتابیس می‌نویسد، یک عامل بازتابی ساده است. حتی اگر یک مدل زبانی در میانه قرار بگیرد و دسته‌بندی آن ردیف را انتخاب کند، باز هم همین‌طور باقی می‌ماند. از آن بپرسید یک ساعت پیش چه کاری انجام داده است؛ نمی‌تواند به شما بگوید، زیرا هیچ‌چیز پاسخ را ذخیره نکرده است.

این نوع عامل، بیش از آنچه مردم انتظار دارند، درست عمل می‌کند. اجرای آن ارزان است و شکست آن به‌راحتی قابل‌تشخیص است: یا شرط برقرار بوده یا نبوده است. وقتی کار واقعاً به صورت «وقتی X رسید، Y را انجام بده» است، حافظه فقط راه‌هایی برای اشتباه کردن اضافه می‌کند و هیچ دستاوردی ندارد. یک عامل n8n مبتنی بر webhook همین ردیف از طبقه‌بندی است که یک رابط کاربری روی آن قرار گرفته است.

این عامل در لحظه‌ای که کنش صحیح به تاریخچه وابسته باشد، از کار می‌افتد. یک ربات پاسخ‌دهنده بدون وضعیت گفتگو (thread state)، در پیام سوم با خودش تناقض پیدا می‌کند، زیرا دو پیام اول هرگز بخشی از ورودی آن نبوده‌اند.

عامل‌های بازتابی مبتنی بر مدل: حفظ وضعیت بین رویدادها

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

یک قانون اتوماسیون خانگی که چراغ‌ها را پس از بیست دقیقه عدم تشخیص حرکت خاموش می‌کند، مبتنی بر مدل است. این عامل ناچار است چنین باشد. «عدم حرکت در حال حاضر» و «عدم حرکت از ساعت 21:40» برای یک عامل بازتابی ساده، ورودی‌های یکسانی هستند؛ بنابراین تنها وضعیت ذخیره‌شده است که تفاوت آن‌ها را مشخص می‌کند.

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

وضعیت، هزینه دارد. یک واقعیت قدیمی (stale) از نداشتن واقعیت بدتر است، زیرا عامل با اطمینان کامل و بدون هیچ هشداری بر اساس آن عمل می‌کند. هر چیزی که ذخیره می‌کنید باید راهی برای انقضا یا بازبینی داشته باشد، در غیر این صورت عامل همچنان درباره سروری که در ماه مارس از رده خارج کرده‌اید، استدلال خواهد کرد.

عامل‌های مبتنی بر هدف: برنامه‌ریزی به سمت وضعیتی که قابل بررسی باشد

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

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

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

عامل‌های مبتنی بر مطلوبیت: انتخاب بین چندین پاسخ مناسب

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

یک عملیات پشتیبان‌گیری که باید پیش از شروع روز کاری و بدون اشباع کردن پهنای باند آپلینک به پایان برسد، یک مسئلهٔ مطلوبیت است. در اینجا پاسخ واحد و درستی وجود ندارد، بلکه تنها یک بده‌بستان (trade-off) مطرح است. مسیریابی که تصمیم می‌گیرد کدام مدل، کدام درخواست را مدیریت کند و قیمت را در برابر کیفیت پاسخ می‌سنجد، ساختاری مشابه دارد.

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

عوامل یادگیرنده: نوعی که اکثر افراد تصور می‌کنند از قبل دارند

یک عامل یادگیرنده رفتار خود را بر اساس بازخورد نتایج گذشته تغییر می‌دهد. این عامل به چیزی نیاز دارد که نتیجه را ارزیابی کند و چیزی که در پاسخ به آن، سیاست (policy) را تغییر دهد.

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

اگر به بخش یادگیری نیاز دارید، ابتدا ارزیابی (evaluation) را بسازید. یک مجموعه تست امتیازدهی‌شده، اجرای تغییرات شما روی آن، و تصمیم‌گیری برای حفظ یا حذف تغییر، یک حلقهٔ بسته است که در آن شما نقش مؤلفهٔ یادگیرنده را ایفا می‌کنید. این فرآیند از آنچه به نظر می‌رسد کندتر است و تنها نسخه‌ای است که امروزه روی بخش‌های self-hosted کار می‌کند. میزبانی یک ابزار ارزیابی (eval harness) نقطهٔ شروع این کار است.

سیستم‌های چندعاملی و سلسله‌مراتبی: چیدمان‌ها، نه انواع

این موارد، نوع ششم و هفتم نیستند. آن‌ها نحوه چیدمان عامل‌ها را توصیف می‌کنند.

یک سیستم چندعاملی (multi-agent)، چندین عامل را به‌طور هم‌زمان در یک محیط مشترک، مانند یک صف یا یک مخزن git، اجرا می‌کند. از آنجا که محیط مشترک است، عامل‌ها با یکدیگر تداخل پیدا می‌کنند. ویرایش یک فایل توسط دو عامل، خطای استاندارد این سیستم‌هاست و راه‌حل آن استفاده از قفل (lock) یا صف کاری (work queue) است. هیچ پرامپتی این مشکل را حل نمی‌کند.

یک سیستم سلسله‌مراتبی، یک ناظر را بالای سرِ عامل‌های اجرایی قرار می‌دهد. ناظر، وظیفه را تقسیم می‌کند، بخش‌ها را توزیع کرده و خروجی‌های بازگشتی را با هم ادغام می‌کند. این مدل به این دلیل محبوب است که با نحوه تقسیم کار توسط انسان‌ها مطابقت دارد، و به این دلیل پرهزینه است که با خواندن هر گزارش، حجم context ناظر افزایش می‌یابد. یک مهار چندعاملی (A multi-agent harness) نحوه پیاده‌سازی عملی این ساختار را نشان می‌دهد.

یک عامل که به‌درستی کار می‌کند، بهتر از چهار عاملی است که عمدتاً کار می‌کنند.

هر مرحله انتقال کار (handoff)، مکانی برای از دست رفتن اطلاعات است. با یک حلقه واحد شروع کنید. تنها زمانی آن را تقسیم کنید که بتوانید مرحله‌ای که گلوگاه (bottleneck) است را نام ببرید.

چرا تقریباً تمام سیستم‌های واقعی ترکیبی هستند

یک عامل استقرار (deployment agent) را در نظر بگیرید که ممکن است خودتان آن را اجرا کنید. یک webhook آن را راه‌اندازی می‌کند که واکنشی (reflex) است. این عامل وضعیت انتشار فعلی را می‌خواند که مبتنی بر مدل (model-based) است. مراحل رسیدن از نسخه در حال اجرا به نسخه هدف را برنامه‌ریزی می‌کند که مبتنی بر هدف (goal-based) است. یک بازه زمانی برای rollout بر اساس بار فعلی انتخاب می‌کند که مبتنی بر مطلوبیت (utility-based) است. این عامل هرگز سیاست‌های خود را ویرایش نمی‌کند، بنابراین در حال یادگیری نیست.

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

کدام نوع برای کدام کار مناسب است

• تریگر ثابت، پاسخ ثابت، بدون نیاز به تاریخچه: بازتاب ساده (simple reflex).
• پاسخ صحیح به آنچه قبلاً رخ داده وابسته است: بازتاب مبتنی بر مدل (model-based reflex).
• وضعیت نهایی قابل بررسی است اما مسیر از پیش مشخص نیست: مبتنی بر هدف (goal-based).
• چندین نتیجهٔ قابل‌قبول با موازنهٔ واقعی بین آن‌ها وجود دارد: مبتنی بر مطلوبیت (utility-based).
• برای بهبود نتایج در طول زمان به یک حلقه ارزیابی نیاز دارید: یک حلقه ارزیابی بسازید و بپذیرید که خودتان بخش یادگیرندهٔ سیستم هستید.

آیا می‌توان این عامل‌ها را شخصاً میزبانی کرد و هزینه آن چقدر است؟

بله، و هزینه به دو بخش تقسیم می‌شود. ارکستراسیون ارزان است. یک نمونه n8n یا یک حلقه عامل در Python بیشتر زمان خود را در انتظار پاسخ‌های شبکه سپری می‌کند، بنابراین 2 هسته vCPU و 4 گیگابایت رم برای آن کافی است. هزینه اصلی مربوط به مدل است.

اگر عامل از یک API میزبانی‌شده استفاده کند، سرور تقریباً به هیچ منبعی نیاز ندارد و هزینه بر اساس تعداد توکن‌ها محاسبه می‌شود. برای یک عامل مبتنی بر هدف، این یعنی هزینه با تعداد مراحل برنامه‌ریزی که مجاز می‌دانید افزایش می‌یابد، پس تعداد دفعات حلقه را محدود کنید.

اگر مدل را روی سخت‌افزار خود اجرا کنید، مقدار رم تعیین می‌کند که اصلاً چه چیزی را می‌توانید اجرا کنید. ارقام زیر اندازه‌های فایل‌های منتشرشده برای وزن‌های کوانتایز شده 4 بیتی در اوت 2026 هستند، که در کنار یک رقم برنامه‌ریزی برای کل رم قرار گرفته‌اند؛ زیرا پنجره کانتکست و زمان اجرا (runtime) هر دو به فضایی فراتر از وزن‌ها نیاز دارند.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

یک مدل 8B با کوانتایز 4 بیتی حدود 4.9 گیگابایت وزن دارد و سیستمی با 10 گیگابایت رم آن را بدون استفاده از swap اجرا می‌کند. یک مدل 70B با همان کوانتایز، 43 گیگابایت وزن دارد و به حدود 64 گیگابایت رم نیاز دارد. توجه کنید که این اعداد چه چیزی را نادیده می‌گیرند: سرعت. روی یک VPS بدون GPU، یک مدل 8B با کوانتایز 4 بیتی، توکن‌ها را با سرعت تک‌رقمی در ثانیه تولید می‌کند. این سرعت برای عاملی که در طول شب یک صف را پردازش می‌کند مناسب است، اما برای هر کاری که کاربر منتظر آن باشد، بسیار کند است. استنتاج محلی (local inference) را برای کارهای دسته‌ای (batch) نگه دارید و برای بخش‌های تعاملی از GPU یا API استفاده کنید. فهرست کوتاه عامل‌های هوش مصنوعی قابل میزبانی شخصی پروژه‌هایی را که ارزش فضای دیسک را دارند معرفی می‌کند و مسیر یادگیری عامل‌ها در سال 2026 توضیح می‌دهد که چه چیزی را به چه ترتیبی بیاموزید.

جایی که طبقه‌بندی دیگر کمکی نمی‌کند

این طبقه‌بندی هیچ اشاره‌ای به ابزارها یا سطوح دسترسی ندارد. در کتاب‌های درسی، عامل‌ها (agents) صرفاً درک می‌کنند و عمل می‌کنند. هیچ‌کس در زمان نگارش آن فصل، نگران این نبوده است که یک عامل، توکن API محیط production را در اختیار داشته باشد. یک عاملِ مبتنی بر هدف با دسترسی shell و یک عاملِ مبتنی بر هدف با اتصال read-only به پایگاه داده، در یک ردیف از جدول قرار می‌گیرند، در حالی که ریسک آن‌ها کاملاً متفاوت است. پیش از آنکه تصمیم بگیرید یک عامل چقدر باید هوشمند باشد، تعیین کنید که به چه منابعی اجازه دسترسی دارد و پیش از آنکه اعتباری (credential) به آن بدهید، نحوه دور نگه داشتن اسرار از عامل‌های هوش مصنوعی را مطالعه کنید.

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

FAQ

پنج نوع عامل هوش مصنوعی کدامند؟

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

برای یک اتوماسیون ساده از چه نوع عامل هوش مصنوعی استفاده کنم؟

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

آیا می‌توانم عامل‌های هوش مصنوعی خودم را روی یک VPS اجرا کنم؟

بله. لایهٔ ارکستراسیون سبک است، بنابراین 2 vCPU و 4 GB رم برای اجرای راحت یک موتور گردش کار یا حلقهٔ عامل کافی است. تصمیم اصلی این است که مدل کجا اجرا شود. استفاده از یک API میزبانی‌شده، سرور را سبک نگه می‌دارد و هزینه را به سمت توکن‌ها می‌برد. یک مدل محلی به رم متناسب با تعداد پارامترهایش نیاز دارد و بدون GPU، تنها چند توکن در ثانیه تولید می‌کند که برای کارهای دسته‌ای (batch) در صف مناسب‌تر است تا یک پنجرهٔ چت.

آیا یک مدل زبانی بزرگ (LLM) به‌تنهایی یک عامل هوش مصنوعی است؟

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

آیا به یک سیستم چندعاملی نیاز دارم؟

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