اگر امروز برای مدیریت اسناد شرکت خود از چت‌بات‌های عمومی استفاده می‌کنید، احتمالاً با پاسخ‌های متناقض یا توهمات مدل روبرو شده‌اید. بسیاری از دستیاران هوش مصنوعی عمومی به دلیل تکیه بیش از حد بر داده‌های نامرتبط، در پیمایش سیاست‌های محدود سازمانی شکست می‌خورند. مایکروسافت این تنش را با معرفی عامل‌های کوپایلت (Copilot Agents) حل کرده است؛ نسخه‌های تخصصی از کوپایلت که توسط یک نقش دائمی و یک میدان دید محدود تعریف می‌شوند.
در پوشش پیشین ما از مهندسی پرامپت در محیط‌های تجاری، دیدیم که تمرکز از «چگونه سؤال بپرسیم» به «چگونه ابزاری بسازیم که پاسخ دهد» تغییر کرده است. یک کوپایلت استاندارد شبیه کارمندی است که همه چیز را در سطح کلی می‌داند و تطبیق‌پذیر است، اما یک عامل (Agent) شبیه به یک متخصص دپارتمانی است که تنها یک حوزه خاص را به‌طور کامل و بی‌نقص می‌شناسد.
این تغییر در حالی رخ می‌دهد که سازمان‌ها با توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — در مدل‌های زبانی بزرگ دست‌وپنجه نرم می‌کنند. مایکروسافت برای حل این مسئله از مبنی‌سازی (Grounding) استفاده می‌کند؛ فرآیندی که پاسخ‌های هوش مصنوعی را به منابع تأییدشده و خاص متصل می‌کند تا سازمان‌ها مطمئن شوند که هوش مصنوعی آن‌ها در صورت نبود پاسخ، از حدس زدن پرهیز می‌کند.
کالبدشناسی یک عامل کوپایلت
به نقل از راهنمای فنی منتشر شده توسط JSystems، یک عامل کاربردی از سه ستون اصلی تشکیل شده است:
- دانش (مبنی‌سازی): عامل به سایت‌های خاص SharePoint یا پوشه‌های OneDrive متصل می‌شود. این عامل منحصراً بر اساس این مطالب پاسخ می‌دهد و برای حفظ تمرکز، سایر داده‌های شرکت را نادیده می‌گیرد.
- دستورالعمل‌ها: مجموعه‌ای از قوانین دائمی که به زبان طبیعی نوشته شده‌اند. این بخش لحن عامل، مواردی که باید از آن‌ها اجتناب کند و نحوه برخورد با شکاف‌های دانشی را تعیین می‌کند.
- اکشن‌ها (Actions): ابزارهای اختیاری که به عامل اجازه می‌دهد به‌جای چت ساده، کارهایی را اجرا کند؛ مانند ایجاد یک تیکت پشتیبانی یا به‌روزرسانی یک صفحه گسترده (Spreadsheet).
زمینه: چه زمانی از عامل استفاده کنیم و چه زمانی از کوپایلت عمومی؟
برای سؤالات تک‌باره و پراکنده، کوپایلت عمومی کافی است. اما وقتی سؤالات تکراری توسط افراد زیاد و بر اساس یک مجموعه سند ثابت پرسیده می‌شود، ساخت یک عامل ضروری است. موارد استفاده رایج شامل سیاست‌های داخلی شرکت، پیشنهادهای محصول یا مستندات پروژه است. به‌جای اینکه به هر کارمند یاد بدهید چگونه یک پرامپت عالی برای کوپایلت عمومی بنویسد، یک عامل می‌سازید که همیشه پاسخ‌های سازگار و زمینه‌مند ارائه می‌دهد.
در مقابل، اگر سؤالی تنها یک بار پرسیده شود و داده‌های آن به‌راحتی در یک چت استاندارد یافت شوند، ساخت عامل زیاده‌روی است. همچنین توصیه می‌شود از ساخت یک عامل «همه-کاره» پرهیز کنید؛ زیرا هرچه دامنه فعالیت عامل گسترده‌تر شود، ریسک بروز خطا افزایش می‌یابد. عامل‌ها در موضوعات محدود و تکرارپذیر با مجموعه‌ای مشخص از اسناد، بهترین عملکرد را دارند.
استقرار عامل‌های پیش‌فرض در برابر عامل‌های سفارشی
کاربران می‌توانند از طریق Agent Store در محیط Copilot Chat ابزارهای پیش‌ساخته را پیدا کنند. این فروشگاه شامل عامل‌های ساخته شده توسط مایکروسافت و همچنین عامل‌هایی است که توسط مدیران سازمان یا همکاران ایجاد شده‌اند. برای فعال‌سازی، کافی است روی کاشی مربوطه کلیک کنید یا در ابتدای پرامپت نام آن را صدا بزنید، مثلاً: «(Agent Analyst) این شیت را تحلیل کن».
مایکروسافت دو عامل قدرتمند پیش‌فرض را به‌صورت آماده ارائه داده است:
۱. Analyst (تحلیل‌گر): متخصص در کارهای عمیق داده‌ای است. این عامل استدلال‌های پیچیده روی صفحات گسترده انجام می‌دهد و به‌جای خلاصه‌های کوتاه، محاسبات را گام‌به‌گام ارائه می‌کند. در واقع این یک نسخه کنجکاوتر از Copilot in Excel است.
۲. Researcher (پژوهش‌گر): برای جمع‌آوری اطلاعات چندمرحله‌ای طراحی شده است. این عامل یک پرسش را به گام‌های مختلف تقسیم می‌کند، داده‌های داخلی و وب را جست‌وجو کرده و گزارشی ساختاریافته همراه با ارجاعات (Citations) می‌سازد. این ابزار برای بررسی جامع یک موضوع ایده‌آل است، نه برای پاسخ‌های تک‌جمله‌ای.
وقتی این عامل‌ها فعال می‌شوند، رفتار چت تغییر می‌کند. برای مثال، عامل Analyst می‌تواند داده‌های فروش را از فایلی مثل copilot-dane-sprzedazowe.xlsx (که شامل ستون‌های محصول، دسته‌بندی، سه ماهه اول تا چهارم و حاشیه سود است) پردازش کند تا درصد رشد فصلی (مثلاً Audio +۱۱.۷٪، Computers +۲۲.۶٪، Components -۲۱.۳٪) و ناهنجاری‌ها را در قالب یک جدول ساختاریافته شناسایی کند.
مسیر سریع: ساخت عامل‌های سبک در محیط چت
پیش از ورود به استودیو کامل، کاربران می‌توانند از گزینه New Agent در نوار کناری Copilot Chat استفاده کنند. این یک سازنده سبک (Lightweight) است که در آن عامل تنها با یک جمله توصیف می‌شود. رابط کاربری شامل یک چت در سمت چپ و یک پیش‌نویس در سمت راست است که نام، توصیف نقش و دستورالعمل‌ها (تقسیم شده به اهداف و قوانین پاسخ‌دهی) را نشان می‌دهد.
اما این مسیر محدودیت‌های شدیدی دارد. در حالی که اجازه تعریف نام، توصیف و دستورالعمل را می‌دهد، اما فاقد ابزارها، اکشن‌ها و منابع دانش متصل دائمی است. اگر از یک عامل سبک درباره اسناد خاص شرکت (مثلاً فرآیند Onboarding شرکت Nordvent) بپرسید، ممکن است به‌درستی از پاسخ دادن خودداری کند، زیرا نمی‌تواند به‌طور دائمی از طریق رابط چت روی فایل‌ها مبنی شود. سازنده ممکن است فایل‌های مشابه را پیدا کند، اما اگر لینک‌های دائمی نداشته باشند، از اتصال آن‌ها خودداری می‌کند.
برای افزودن دانش دائمی، کاربر باید به ویرایشگر کامل منتقل شود. در ویرایشگر، می‌توان منابع را از SharePoint، OneDrive for Business، وب‌سایت‌های عمومی، Azure SQL یا Salesforce اضافه کرد. اگر از مسیر سبک استفاده کنید، هر فایلی که از طریق علامت اسلش (/) در پرامپت اضافه شود، موقتی است و پس از پایان گفتگو ناپدید می‌شود.
فرآیند ساخت بدون کد در Copilot Studio
برای نیازهایی که عامل‌های پیش‌فرض پوشش نمی‌دهند، Copilot Studio امکان سفارشی‌سازی کامل را بدون نوشتن حتی یک خط کد فراهم می‌کند. فرآیند با تعریف یک نقش، مثلاً «دستیار منابع انسانی»، و تنظیم یک پیام خوش‌آمدگویی برای راهنمایی کاربر آغاز می‌شود.
جزئیات گام‌های ساخت
- نام‌گذاری و هویت: با نام‌گذاری عامل شروع کنید (مثلاً Asystent Kadr). این هویت به عنوان پیش‌نویس ذخیره شده و برچسب دائمی عامل می‌شود. از نام‌های کلی مثل Bot 1 پرهیز کنید.
- خوش‌آمدگویی و دستورات: در تنظیمات Greeting and Commands (موجود در More Options > Settings)، پیامی بنویسید که ۳ تا ۴ حوزه کمک را لیست کند. برای یک عامل HR، این می‌تواند باشد: «من می‌توانم درباره مرخصی، دورکاری، مزایا و رویه‌های شرکت پاسخ دهم». همچنین Suggested Commands را به عنوان سؤالات آماده و قابل مشاهده در ابتدا اضافه کنید.
- نوشتن دستورالعمل‌ها: این حیاتی‌ترین مرحله است. دستورالعمل‌های مؤثر باید شامل موارد زیر باشد:
- نقش: «تو دستیار دپارتمان منابع انسانی هستی».
- محدودیت سخت: «صرفاً و منحصراً بر اساس اسناد متصل شده HR پاسخ بده».
- ممنوعیت حدس زدن: «اطلاعات یا رکوردهایی که در اسناد یافت نمی‌شوند را اختراع نکن یا حدس نزن».
- مسیر ارجاع: «اگر پاسخ موجود نبود، کاربر را به ایمیل دپارتمان HR ارجاع بده».
- پیاده‌سازی مبنی‌سازی: آدرس‌های SharePoint یا پوشه‌های OneDrive for Business را اضافه کنید. توجه داشته باشید که نام کتابخانه‌هایی که دارای فاصله (Space) هستند باید از
%20استفاده کنند تا خطای Invalid URL رخ ندهد. همچنین مراقب باشید آرشیوهای قدیمی را حذف کنید تا عامل سیاست‌های منسوخ را نقل نکند.
مبنی‌سازی با افزودن URLهای SharePoint اجرا می‌شود. یک الزام فنی کلیدی این است که محیط باید دارای یک پایگاه‌داده Dataverse پیکربندی شده باشد؛ در غیر این صورت، ویرایشگر پیام Dataverse is not configured in this environment را نشان می‌دهد. کاربران ممکن است نیاز داشته باشند به یک محیط توسعه (Development Environment) منتقل شوند یا از مدیر سیستم بخواهند دیتابیس را اضافه کند، زیرا این موضوع بر ظرفیت Tenant تأثیر می‌گذارد.
چارچوب تست و اعتبارسنجی
برای جلوگیری از سلب اعتماد کاربر، راهنما یک پروتکل تست چهارمرحله‌ای را در تب Preview (نسخه پیش‌نمایش) پیش از انتشار توصیه می‌کند. توجه داشته باشید که این تست‌ها از اعتبارات (Credits) توابع کوپایلت اختصاص یافته به محیط استفاده می‌کنند.
- تست ضربه مستقیم (The Direct Hit): سؤالی بپرسید که جوابش را می‌دانید (مثلاً «چند روز مرخصی درخواستی در دسترس است؟»). بررسی کنید که عامل حتماً ارجاعی به فایل منبع (مثلاً
regulamin_urlopowy_demo.docx) بدهد. اگر جواب درست بود اما منبعی نیاورد، یعنی از دانش عمومی مدل استفاده کرده، نه فایل‌های شما. - تست مرزی (The Boundary Test): سؤالی بپرسید که فقط نیمی از اطلاعاتش موجود است (مثلاً «آیا می‌توانم از خارج از کشور دورکاری کنم؟»). عامل باید بتواند بین آنچه مستند شده و آنچه نشده تفکیک قائل شود، به‌جای اینکه آن‌ها را در یک پاراگراف روان با هم ترکیب کند.
- ممیزی عددی (The Numeric Audit): اعداد دقیق (مثلاً مهلت گزارش‌دهی ساعت ۹ صبح یا محدودیت ۴ روزه سالانه برای مرخصی درخواستی) را با سند اصلی مقایسه کنید تا دقت ۱۰۰٪ تضمین شود. اگر اعداد غلط بودند، وجود نسخه‌های تکراری یا آرشیوی از سند در کتابخانه منبع را بررسی کنید.
- سؤال تله (The Trick Question): درباره مزایایی بپرسید که شرکت اصلاً ارائه نمی‌دهد. عامل باید از پاسخ دادن خودداری کرده و کاربر را به HR ارجاع دهد. اگر توهم زد، یک ممنوعیت سخت‌گیرانه‌تر به دستورالعمل‌ها اضافه کنید.
تبدیل چت‌بات به ابزار با استفاده از اکشن‌ها
عامل‌ها زمانی واقعاً بهره‌ور می‌شوند که بتوانند عملیاتی را اجرا کنند. در Copilot Studio، این قابلیت‌ها در منوی Tools (ابزارها) یافت می‌شوند. با استفاده از کانکتور Excel Online (Business)، می‌توان عامل را برای «افزودن ردیف جدید به یک جدول» پیکربندی کرد.
جزئیات پیکربندی اکشن
- الزام جدول: کانکتور فقط «جداول نام‌گذاری شده» (Named Tables) را در اکسل می‌بیند، نه محدوده‌های سلولی خام. برای مثال، فایل
wnioski_urlopowe_nordvent.xlsxباید شامل جدولی به نامTabWnioskiبا ستون‌هایی برای شماره درخواست، کارمند، نوع مرخصی، تاریخ شروع، تاریخ پایان، جایگزین، وضعیت و تاریخ ارسال باشد. - دستورالعمل مدل: توصیف ابزار در واقع دستورالعملی برای هوش مصنوعی است. برای جلوگیری از ورودی‌های خالی، توصیف باید بیان کند: «تنها زمانی از این ابزار استفاده کن که هر چهار مورد (نوع مرخصی، تاریخ شروع، تاریخ پایان و شخص جایگزین) را داشته باشی و کاربر خلاصه را تأیید کرده باشد».
- نگاشت ورودی‌ها:
- پر شده توسط AI: داده‌های متغیر مانند تاریخ‌ها و نام‌ها روی حالت AI قرار می‌گیرند تا مدل آن‌ها را از چت استخراج کند (مثلاً تبدیل «دوشنبه آینده» به یک تاریخ دقیق).
- مقدار ثابت (Fixed-value): نام مکان، کتابخانه، فایل و جدول روی حالت Value قرار می‌گیرند تا هوش مصنوعی مقصد فایل را حدس نزند.
- فرمت داده‌ها: چون کانکتورها اغلب تاریخ‌ها را به صورت متن ذخیره می‌کنند، کاربران باید فرمت دقیق (مثلاً YYYY-MM-DD) را در توصیف ورودی ذکر کنند تا خطاهای گزارش‌دهی رخ ندهد. برای مثال، اگر عامل «06.10.2026» را به‌جای «2026-10-06» بنویسد، فیلترها و مرتب‌سازی‌ها مختل می‌شوند.
استقرار و حاکمیت
پس از تست، عامل باید Publish (منتشر) شود و سپس Share (به اشتراک گذاشته) گردد. انتشار، نسخه فعلی را ذخیره می‌کند، اما اشتراک‌گذاری تعیین می‌کند چه کسی به آن دسترسی دارد — از یک گروه کوچک پایلوت تا کل سازمان.
گردش کار انتشار
۱. انتشار (Publish): کلیک روی Publish باعث می‌شود پیش‌نویس فعلی برای اشتراک‌گذاری در دسترس قرار گیرد. هر تغییر بعدی در دستورالعمل‌ها یا دانش باید دوباره منتشر شود تا به دست کاربران برسد. یک عامل منتشر شده تا زمانی که به اشتراک گذاشته نشود، در هیچ کانالی در دسترس نیست.
۲. اشتراک‌گذاری (Share): دسترسی به افراد، گروه‌ها یا کل سازمان اعطا می‌شود. توصیه می‌شود ابتدا با یک گروه کوچک پایلوت شروع کنید تا دستورالعمل‌ها اصلاح شوند.
۳. اطلاع‌رسانی: کاربران عامل را در نوار کناری Copilot Chat می‌بینند. ارائه پرامپت‌های نمونه به پذیرش سریع‌تر ابزار کمک می‌کند.
نکته حیاتی این است که عامل‌ها به مجوزهای موجود در Microsoft 365 احترام می‌گذارند. اگر کاربری به یک پوشه خاص در SharePoint دسترسی ندارد، عامل اطلاعات آن پوشه را به او نشان نمی‌دهد، حتی اگر خودِ عامل به آن پوشه متصل باشد. این موضوع تضمین می‌کند که اشتراک‌گذاری جهانی یک عامل باعث نشت تصادفی اسناد محرمانه نشود.
تحلیل: چرخش به سمت میکرو-هوش مصنوعی
این حرکت به سمت عامل‌های تخصصی، پایان عصر «یک بات برای همه کارها» را اعلام می‌کند. با تکه‌تکه کردن هوش مصنوعی به عامل‌های کوچک، محدود و با دقت بالا، شرکت‌ها ریسک توهم را کاهش و تجربه کاربری را بهبود می‌بخشند.
برای یک کارمند عادی، این یعنی زمان کمتری برای مهندسی پرامپت. به‌جای اینکه به مدل بگوید «به عنوان متخصص HR عمل کن و این PDF خاص را بخوان»، کاربر صرفاً عامل HR را باز می‌کند که از پیش دارای شخصیت (Persona) و داده‌های لازم است.
خلاصه بهترین شیوه‌ها
- دامنه محدود: برای HR و پشتیبانی محصول، دو عامل جداگانه بسازید، نه یک بات کلی. برای مثال، یک عامل «پشتیبانی محصول» باید صرفاً بر اساس یک پایگاه دانش خاص، روی پیکربندی، خطاها و گارانتی تمرکز کند.
- دستورالعمل‌های سخت: از عبارات مبهم مثل «کمک‌کننده باش» پرهیز کنید؛ به‌جای آن ممنوعیت‌های صریح برای حدس زدن بگذارید. مشخص کنید که عامل باید موجز باشد و از Bullet Points استفاده کند.
- منابع به‌روز: مطمئن شوید کتابخانه مبنی‌سازی فقط شامل آخرین نسخه‌های سیاست‌هاست و آرشیوها حذف شده‌اند. این رایج‌ترین علت خطاهای شناسایی‌نشده است.
- تأیید انسانی (Human-in-the-Loop): هر اکشنی که داده‌ای را تغییر می‌دهد، باید قبل از اجرا، تأیید انسانی روی یک خلاصه را بخواهد. عامل باید خلاصه‌ای را ارائه دهد (مثلاً «در حال ذخیره درخواست: مرخصی، ۶ تا ۱۷ جولای، جایگزین: Tomasz Lis») و منتظر تأیید بماند.
- اول پایلوت: ابتدا برای گروه کوچکی مستقر کنید. عاملی که در لحظه لانچ شکست می‌خورد، اعتماد کاربر را سریع‌تر از آنکه بتوان بازگرداند، از دست می‌دهد.
اشتباهات رایج
- فراموش کردن انتشار: به‌روزرسانی دستورالعمل‌ها اما عدم کلیک روی Publish، که باعث می‌شود کاربران از نسخه قدیمی استفاده کنند.
- منابع بیش از حد گسترده: متصل کردن کل سایت شرکت به‌جای یک کتابخانه خاص، که باعث می‌شود عامل در نویز داده‌ها گم شود.
- نادیده گرفتن تست تله: تست کردن فقط سؤالاتی که جوابشان را می‌دانید، به‌جای تست نحوه برخورد مدل با نبود کامل اطلاعات.
گام بعدی شما
- اگر دسترسی به Microsoft 365 دارید، یک عامل سبک (Light Agent) بسازید تا تفاوت بین دانش عمومی و مبنی‌سازی را درک کنید.
- برای سازمان‌های بزرگ، ابتدا یک «عامل مستندات داخلی» بسازید و آن را در یک گروه ۵ نفره تست کنید تا نرخ توهم را بسنجید.
- بررسی کنید آیا دیتابیس Dataverse در محیط شما فعال است تا در زمان ساخت عامل‌های پیشرفته با خطای پیکربندی مواجه نشوید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو