ایجنت هوش مصنوعی برنامه‌ای است که برای انجام یک هدف، از مدل زبانی برای انتخاب گام بعدی و از ابزارهای مشخص برای خواندن داده یا انجام کار استفاده می‌کند. مثلاً در پاسخ به «وضعیت سفارش ۲۳۴ چیست؟» میتواند پایگاه سفارش را بخواند، نتیجه را توضیح دهد و تنها با مجوز کاربر، یک پیگیری بسازد. داشتن چند پیام در یک چت به‌تنهایی ایجنت نمی‌سازد.
چه زمانی ایجنت لازم است؟
اگر ورودی و مسیر کار از پیش روشن است، کد معمولی یا یک گردش کار ثابت قابل‌اعتمادتر و ارزان‌تر است. ایجنت زمانی ارزش دارد که برای حل مسئله، انتخاب میان چند ابزار یا تصمیم بر پایه نتیجه گام قبل لازم باشد. برای نمونه، بررسی خرابی تجهیز ممکن است به خواندن هشدار، یافتن دستورالعمل مرتبط و مقایسه با سوابق تعمیر نیاز داشته باشد.
پیش از ساخت، هدف را به صورت قابل آزمون بنویسید: «برای هر هشدار پمپ، شماره تجهیز، سه شاهد داده‌ای و پیشنهاد بررسی را در کمتر از دو دقیقه آماده کند.» عبارت «یک ایجنت هوشمند برای کارخانه» معیار موفقیت ندارد.
اجزای معماری ساده
- دستور و محدوده: نقش، هدف، داده مجاز و شرط توقف.
- ابزار: تابع‌های محدود برای جست‌وجوی سند، خواندن رکورد یا ایجاد پیش‌نویس.
- حالت کار: شناسه درخواست، نتیجه گام‌ها و شمارنده سقف تلاش.
- کنترل: بررسی ورودی و خروجی ابزار، مجوز هر کاربر و تأیید برای اقدام حساس.
- ارزیابی: مجموعه وظایف واقعی با پاسخ یا نتیجه مورد انتظار.
برای بخش دانش اسناد، RAG یک ابزار مناسب است. مدل زبانی و محدودیت‌های آن را در راهنمای LLM توضیح داده‌ایم. راهنمای عامل‌های OpenAI نیز ابزار و مدیریت کار چندمرحله‌ای را توضیح میدهد.
نمونه: دستیار بررسی هشدار پمپ
ورودی شامل شناسه تجهیز و زمان هشدار است. عامل ابتدا داده ارتعاش و دما را با ابزار خواندنی می‌گیرد. سپس دستورالعمل همان مدل پمپ را بازیابی می‌کند. خروجی باید شامل «آنچه مشاهده شد»، «آنچه سند می‌گوید»، «توضیح احتمالی» و «اقدام پیشنهادی» باشد. اگر داده ناقص است، باید نقص را بیان کند. ایجاد دستور کار، تغییر تنظیمات یا توقف تجهیز باید در اختیار انسان مجاز بماند.
این نمونه به تجربه نگهداری و تعمیرات پیش‌بینانه نزدیک است؛ تصمیم نگهداشت بدون شناخت فرایند و پیامد خطا نباید خودکار شود.
طراحی ابزار امن
به‌جای ابزار کلی «اجرای هر دستور»، تابع‌های کوچک بسازید: get_equipment_status(id)، search_manual(query, equipment_id) و draft_work_order(...). هر تابع ورودی معتبر، خروجی محدود و خطای روشن داشته باشد. دسترسی خواندن را از نوشتن جدا کنید. برای هر درخواست، کاربر، ابزار، آرگومان و نتیجه را ثبت کنید؛ داده حساس را در گزارش‌ها بی‌جهت ذخیره نکنید.
متن صفحه وب یا PDF ممکن است حاوی دستور مخرب باشد. آن متن را داده بدانید، نه فرمانی برای عامل. تعداد گام، هزینه و زمان اجرا را سقف‌گذاری کنید تا حلقه بی‌پایان رخ ندهد.
ارزیابی پیش از انتشار
۲۰ تا ۵۰ وظیفه واقعی تهیه کنید: موارد معمول، داده ناقص، ابزار ازکارافتاده، سند قدیمی و درخواست خارج از مجوز. برای هر مورد بررسی کنید آیا عامل به هدف رسید، از ابزار درست استفاده کرد، منبع را درست نقل کرد و در زمان لازم متوقف شد. معیار «پاسخ قانع‌کننده» کافی نیست؛ نتیجه عمل و هزینه خطا اهمیت دارد. بعد از استقرار نیز نمونه‌ای از اجراها را بازبینی کنید.
نقشه اجرای کم‌هزینه
با یک وظیفه خواندنی و بدون اقدام برگشت‌ناپذیر شروع کنید. خط مبنای انسانی، زمان و خطا را ثبت کنید. ابزارها را محدود و خروجی را ساخت‌یافته کنید. سپس ارزیابی را اجرا کنید و فقط اگر بهبود واقعی دیده شد، اختیار اقدام بیشتری بدهید. در هر گسترش، مجوز و نقطه تأیید انسانی را دوباره بررسی کنید.
برای ساخت نمونه عملی با ابزار اتوماسیون، آموزش نصب n8n با Docker Compose روی ویندوز را ببینید.
پرسش‌های متداول
تفاوت ایجنت و چتبات چیست؟
چتبات معمولاً پاسخ متنی میدهد؛ ایجنت برای رسیدن به هدف میتواند ابزارهای تعریفشده را فراخوانی کند و نتیجه هر گام را بررسی کند.
آیا هر کار خودکار به ایجنت نیاز دارد؟
خیر. اگر مسیر کار ثابت و قابل پیشبینی است، یک گردش کار معمولی سادهتر و قابلکنترلتر است.
مهمترین خطر ایجنت چیست؟
اجرای اقدام اشتباه یا دسترسی بیشازحد به داده و ابزار؛ محدودکردن مجوز، ثبت رویداد و تأیید انسانی برای اقدامات حساس ضروری است.