AI Agent چیست و چه تفاوتی با Chatbot و AI Assistant دارد؟

در کاتالوگ ابزارهای ۲۰۲۶ تقریباً هر محصولی خودش را Agent می‌نامد؛ در حالی که همان محصول یک حالت Chat، یک حالت تکمیل کد، و یک حالت اجرای چندگامی دارد. اگر تیم این سه برچسب را یکی بگیرد، دو اشتباه رایج رخ می‌دهد: یا به یک چت ساده دسترسی ابزار بیش از حد می‌دهد، یا از یک عامل واقعی فقط مثل «پاسخ‌گو» استفاده می‌کند و ارزشش را هدر می‌دهد.

مقالهٔ ۱۰۱ سری قبل روی تعریف Agent در برابر Chatbot تمرکز داشت. اینجا زاویه فرق می‌کند: مقایسهٔ سه‌جانبهٔ AI Agent، Chatbot و AI Assistant، با نگاشت به محصولات واقعی (Cursor، GitHub Copilot) و معیار عملی برای سیاست تیم. تعریف‌ها از مستندات سازندگان می‌آیند، نه از شعار بازاریابی.

پاسخ کوتاه

Chatbot عمدتاً مکالمه و پاسخ متنی است. AI Assistant (دستیار هوش مصنوعی) معمولاً داخل گردش‌کار شما می‌نشیند—تکمیل کد، توضیح، پیشنهاد بازنویسی—و اغلب یک اقدام محدود با تأیید شما انجام می‌دهد. AI Agent هدف‌محور است: برنامه می‌چیند، ابزار صدا می‌زند، نتیجه را می‌بیند و تا اتمام یا توقف ادامه می‌دهد. مرز عملی: اگر سیستم فقط جواب می‌دهد Chatbot است؛ اگر کمکتان می‌کند در همان IDE بدون حلقهٔ چندگامی مستقل Assistant است؛ اگر چند فایل را می‌خواند/ویرایش می‌کند، تست اجرا می‌کند و روی شاخه کار می‌کند، وارد قلمرو Agent شده‌اید.

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

چرا این تمایز برای تیم نرم‌افزار مهم است؟

هر سطح، سطح حمله و سطح نظارت متفاوتی می‌طلبد. OWASP در LLM03:2026 Excessive Agency هشدار می‌دهد که ریشهٔ آسیب اغلب ترکیبی از کارکرد بیش از حد، مجوز بیش از حد و خودمختاری بیش از حد است—نه فقط «مدل بد». اگر Chatbot را Agent بنامید، احتمال می‌دهید ابزار shell و نوشتن در Production را روشن کنید؛ اگر Agent را Assistant بنامید، ممکن است بدون Approval انسانی اجازهٔ Merge یا Deploy بدهید.

NIST در AI RMF و پروفایل Generative AI (NIST AI 600-1) بر حاکمیت، نگاشت ریسک، اندازه‌گیری و مدیریت تأکید دارد. ترجمهٔ تیمی: قبل از خرید یا روشن‌کردن حالت Agent، نقش سیستم، شعاع انفجار، و نقطهٔ نظارت انسانی را بنویسید.

تعریف کاری هر سه مفهوم

Chatbot

Chatbot رابط گفت‌وگویی است: پیام می‌گیرد، متن برمی‌گرداند. ممکن است به پایگاه دانش یا Retrieval وصل باشد، اما معمولاً وضعیت مخزن شما را تغییر نمی‌دهد و حلقهٔ اقدام چندگامی مستقل ندارد. مناسب توضیح مفهوم، FAQ داخلی، یا brainstorm بدون دسترسی نوشتنی.

AI Assistant

دستیار در بستر کار شما زندگی می‌کند: تکمیل خط در IDE، توضیح تابع زیر نشانگر، پیشنهاد تست، بازنویسی انتخاب‌شده. مشخصهٔ Assistant این است که معمولاً هم‌زمان با شما کار می‌کند و اقدام‌های تغییردهنده یا تک‌گامی‌اند و زیر کنترل مستقیم شما (Accept/Reject). GitHub Copilot در نقش تکمیل و چت IDE، و حالت Ask در Cursor (فقط خواندنی) نمونه‌های نزدیک به Assistant/کمک بدون اجرای خودمختارند.

AI Agent

طبق OpenAI Agents SDK، Agent یک LLM مجهز به instructions و tools است که حلقهٔ اجرا را تا اتمام کار ادامه می‌دهد. Anthropic هم Agent را برنامه‌ای می‌داند که گام‌ها را برنامه‌ریزی و ابزارهایی مثل خواندن/ویرایش فایل یا اجرای فرمان را صدا می‌زند. Cursor Agent را ترکیبی از Instructions + Tools + Model توصیف می‌کند که می‌تواند جست‌وجو کند، ویرایش کند و ترمینال اجرا کند. GitHub Copilot cloud agent در محیط Actions مخزن را تحقیق می‌کند، برنامه می‌سازد، روی شاخه تغییر می‌دهد و در صورت تمایل Pull Request باز می‌کند—متمایز از agent mode داخل IDE.

جدول مقایسهٔ سه‌جانبه

نگاشت به محصولات واقعی

Cursor

مستندات Cursor چهار حالت اصلی را جدا می‌کند: Agent برای ساخت/بازنویسی/رفع باگ با ویرایش؛ Ask فقط خواندنی برای فهم کد؛ Plan برای طرح قابل‌بازبینی قبل از پیاده‌سازی؛ Debug برای باگ‌های نیازمند شواهد زمان اجرا. این دقیقاً طیف Assistant→Agent را داخل یک محصول نشان می‌دهد: Ask نزدیک Assistant/تحلیل است؛ Agent و Cloud Agents روی cursor.com/agents وارد اقدام چندگامی می‌شوند. Checkpoints امکان برگشت محلی تغییرات Agent را می‌دهند—نشانهٔ اینکه محصول خودش را عامل تغییردهنده می‌داند، نه فقط چت.

GitHub Copilot

سه چهرهٔ متمایز در اسناد رسمی دیده می‌شود: (۱) تکمیل و Copilot Chat در IDE به‌عنوان دستیار؛ (۲) agent mode در IDE که ویرایش خودمختار محلی می‌کند؛ (۳) Copilot cloud agent که در محیط Actions روی GitHub تحقیق، برنامه، تغییر شاخه و PR اختیاری انجام می‌دهد. جدا از این‌ها، Copilot code review بازبینی Pull Request و پیشنهاد اصلاح است—نزدیک به Assistant تخصصی Review، نه جایگزین انسان. خود GitHub تأکید می‌کند بازخورد Copilot را با دقت اعتبارسنجی کنید و با Review انسانی تکمیل کنید.

SDKها و Agentهای سفارشی

اگر با OpenAI Agents SDK یا Anthropic Agent SDK عامل خودتان را می‌سازید، شما صریحاً tools، guardrails و حلقه را تعریف می‌کنید. اینجا برچسب Agent معنی مهندسی دارد: بدون ابزار و بدون حلقه، فقط یک فراخوانی مدل دارید.

طیف عملی؛ نه سه جعبهٔ بسته

در واقعیت یک محور پیوسته است:

1. پاسخ متنی محض (Chatbot کلاسیک).
2. پاسخ با Retrieval یا یک ابزار خواندنی.
3. دستیار IDE با Accept دستی (Assistant).
4. همکار با چند ویرایش و اجرای تست پس از تأیید (Agent محدود / human-in-the-loop).
5. عامل ابری که شاخه و PR می‌سازد با سیاست مخزن (Cloud Agent).
6. عامل با دسترسی گسترده به شبکه/چندسیستم — فقط با کنترل قوی قابل‌قبول.

سیاست تیم باید روی این محور سطح مجوز را قفل کند، نه روی نام تجاری دکمه.

چه زمانی کدام را انتخاب کنید؟

Chatbot کافی است وقتی

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

Assistant مناسب است وقتی

• روی یک فایل یا تکهٔ کوچک کار می‌کنید و می‌خواهید سرعت تایپ/یادآوری API بالا برود.
• توضیح کد موجود یا پیشنهاد نام/تست سریع می‌خواهید.
• هنوز هدف چندفایلی با معیار Done روشن ندارید.

Agent ارزش دارد وقتی

• کار چندمرحله‌ای است: پیدا کردن محل باگ، ویرایش چند فایل هم‌سبک، اجرای تست، گزارش Diff.
• می‌خواهید پیش‌نویس PR روی شاخهٔ جدا با شفافیت commitها ساخته شود (مثل cloud agent).
• Plan Mode برای معماری کوچک قبل از کد لازم است.

اشتباه‌های رایج نام‌گذاری و سیاست

• هر چت داخل IDE را Agent نامیدن → مجوز ابزار اشتباه.
• فرض اینکه Assistant یعنی بی‌خطر → Accept بی‌Review همان مسیر بدهی است.
• معادل دانستن cloud agent با Chatbot پشتیبانی → سطح حمله و هزینهٔ Actions/اعتبار را دست‌کم می‌گیرید.
• روشن کردن همهٔ MCP و ابزارهای باز به‌عنوان پیش‌فرض «قدرت بیشتر» → دقیقاً Excessive Functionality از نظر OWASP.
• انتظار اینکه code review خودکار جایگزین Review انسانی شود → خلاف توصیهٔ رسمی GitHub.

چک‌لیست تشخیص برای تیم

1. آیا سیستم بدون پرامپت جدید چند اقدام پشت‌سرهم انجام می‌دهد؟
2. آیا ابزاری فراتر از تولید متن دارد (ویرایش، ترمینال، API)؟
3. آیا نتیجهٔ ابزار را مشاهده و در گام بعد استفاده می‌کند؟
4. آیا سیاست مجوز جدا از «باهوش بودن مدل» نوشته شده؟
5. آیا برای اقدام‌های پرریسک Approval انسانی اجباری است؟

صفر یا یک بلهٔ ضعیف: Chatbot/Assistant. چند بلهٔ قوی: Agent—و باید مثل بازیگر عملیاتی با دسترسی کنترل‌شده مدیریت شود.

مثال سناریوی یک روز کاری

صبح: با Chatbot یا Ask دربارهٔ trade-off دو الگوی کش صحبت می‌کنید—بدون نوشتن. ظهر: با Assistant تکمیل تست واحد برای یک تابع خالص. عصر: به Agent می‌سپارید «این flaky test را بازتولید کن، علت را در Diff توضیح بده، فقط همان فایل‌های مرتبط را اصلاح کن، تست را سبز کن». شب: cloud agent روی یک issue مستندسازی یک API پیش‌نویس PR می‌سازد؛ شما فردا Review می‌کنید. سه برچسب، سه شعاع انفجار، یک استاندارد کیفیت.

امنیت و حاکمیت در یک پاراگراف عملی

حداقل ابزار، حداقل مجوز، حداقل خودمختاری—سه‌گانهٔ کاهش Excessive Agency. خروجی مدل را قبل از اجرای پایین‌دستی اعتبارسنجی کنید (موضوع LLM10 Improper Output Handling). برای سازمان، توابع GOVERN/MAP/MEASURE/MANAGE در NIST را به زبان تیم ترجمه کنید: صاحب سیاست، فهرست حالت‌های مجاز ابزار، متریک شکست CI پس از PRهای agentic، و ممنوعیت Deploy مستقیم از خروجی مدل.

سوالات متداول

آیا AI Assistant همان Chatbot داخل IDE است؟

گاهی ظاهر مشابه است، اما Assistant معمولاً به فایل باز، زبان پروژه و تکمیل زمینه‌دار وصل است. اگر فقط پنجرهٔ چت بدون زمینهٔ IDE باشد، رفتارش به Chatbot نزدیک‌تر است.

آیا Copilot code review یک Agent است؟

قابلیت‌های agentic برای جمع‌آوری زمینه دارد، اما نقش محصولی‌اش بازبینی و پیشنهاد است؛ GitHub صراحتاً می‌گوید همهٔ مسائل را پیدا نمی‌کند و باید با انسان تکمیل شود. آن را Assistant تخصصی Review ببینید مگر اینکه پیشنهادها را به cloud agent برای اعمال خودکار بسپارید—که آن بخش وارد قلمرو Agent می‌شود.

آیا Plan Mode هنوز Agent است؟

Plan در Cursor قبل از ساخت، طرح قابل‌ویرایش می‌سازد. از نظر طیف، مرحلهٔ برنامه‌ریزیِ گردش Agent است؛ تا وقتی کد ننوشته، ریسک تغییر مخزن کمتر است—اما بعد از Build همان کنترل‌های Agent لازم است.

برای تیم کوچک از کجا شروع کنیم؟

یک هفته فقط Assistant + Ask. هفتهٔ بعد Agent روی کارهای کم‌ریسک با شاخهٔ جدا و Review اجباری. cloud agent را وقتی Branch protection و قالب PR دارید روشن کنید.

خلاصه

Chatbot پاسخ می‌دهد؛ Assistant در جریان کار کمکتان می‌کند؛ Agent برای هدف، ابزار و حلقهٔ مشاهده دارد. محصولات مدرن هر سه را زیر یک سقف می‌فروشند—سیاست شما باید آن‌ها را از هم جدا کند. کم‌ترین سطح خودمختاریِ کافی را انتخاب کنید؛ مجوز را با همان سطح هم‌تراز کنید؛ و هیچ برچسب بازاریابی را جایگزین Diff و تست نکنید.

معیارهای تصمیم خرید و روشن‌کردن حالت Agent

قبل از ارتقا از Assistant به Agent در سازمان، پنج سؤال را مکتوب کنید: (۱) چه هدف‌های تکراری ارزش حلقهٔ چندگامی دارند؟ (۲) کدام مخزن‌ها و محیط‌ها مجازند؟ (۳) سقف هزینهٔ Actions/اعتبار ماهانه چیست؟ (۴) چه کسی مالک حوادث ناشی از اقدام Agent است؟ (۵) چه متریکی بعد از چهار هفته موفقیت را نشان می‌دهد؟ بدون پاسخ، روشن‌کردن Agent فقط هزینه و سطح حمله را بالا می‌برد.

برای تیم‌های کوچک، یک مخزن پایلوت با Branch protection کامل کافی است. برای سازمان بزرگ‌تر، ابتدا سیاست Copilot/Cursor را در سطح org قفل کنید، بعد مخزن به مخزن opt-in کنید—نه برعکس.

نقش AI Assistant در برابر «همکار ارشد»

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

تمرین مفید: هر پیشنهاد معماری از Assistant را در قالب ADR یک‌صفحه‌ای بنویسید. اگر نتوانستید trade-off را بدون مدل توضیح دهید، هنوز برای Merge آماده نیستید.

تفاوت برند و رفتار در عمل روزمره

ممکن است هر سه حالت را در یک اشتراک ببینید. صبح Ask می‌پرسید «این سرویس کجا rate limit می‌کند؟»—رفتار Chatbot/Assistant. ظهر تکمیل می‌نویسید—Assistant. عصر به Agent می‌سپارید flaky test را سبز کند—Agent. شب cloud agent روی Issue مستندسازی PR می‌سازد—باز Agent اما با شفافیت تیمی بیشتر. هزینهٔ اشتباه وقتی است که شب، بدون تغییر سیاست، همان دسترسی Ask را به Agent بدهید.

یک کارت کوچک روی ویکی تیم بگذارید: «الان در چه وضعیتی هستم؟» با سه رنگ. تغییر رنگ یعنی چک‌لیست مجوز.

ارتباط با سری مقالات

بعد از این مقایسه، مقالهٔ ۱۲۸ ایستگاه‌های SDLC را باز می‌کند؛ ۱۲۹ توضیح می‌دهد چرا خروجی هر سه—مخصوصاً Agent—بدون Review وارد Production نشود؛ ۱۳۰ و ۱۳۱ Review و تست را لایه لایه می‌کنند. مقالهٔ ۱۲۳ روی خود Coding Assistant متمرکز است و ۱۲۵/۱۲۶ توهم و پاسخ مطمئن غلط را می‌شکافند—پیش‌نیاز ذهنی برای اعتماد نکردن به لحن.

منابع و مراجع

• OpenAI Agents SDK — Agents as LLMs with instructions and tools — https://openai.github.io/openai-agents-python/
• Cursor Agent overview — Instructions, Tools, Model — https://cursor.com/docs/agent/overview
• Cursor Agent modes (Agent / Ask / Plan / Debug) — https://cursor.com/help/ai-features/agent
• GitHub Copilot cloud agent — https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent
• GitHub Copilot code review — https://docs.github.com/en/copilot/concepts/agents/code-review
• OWASP GenAI LLM Top 10 2026 — LLM03 Excessive Agency — https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
• NIST AI RMF — https://www.nist.gov/itl/ai-risk-management-framework
• NIST AI 600-1 Generative AI Profile — https://doi.org/10.6028/NIST.AI.600-1