چت‌باتی که توضیح می‌دهد چگونه یک درخواست پشتیبانی ثبت شود، با سامانه‌ای که واقعاً درخواست را ثبت می‌کند تفاوت دارد. دومی به ابزار، مجوز و راه بررسی نتیجه نیاز دارد. در بحث عامل‌های هوشمند، همین فاصله میان گفت‌وگو و اقدام اهمیت پیدا می‌کند. این مقاله یک الگوی مهندسی برای اتصال ابزارها ارائه می‌دهد و به معنی فعال بودن این قابلیت‌ها در همه محصولات شرکت نیست.
گردش کار یا عامل؟
در راهنمای Building effective agents از Anthropic، گردش کار با مسیرهای از پیش تعیین‌شده از عاملی که مسیر و استفاده از ابزار را به صورت پویا انتخاب می‌کند جدا می‌شود. این تمایز برای طراحی مفید است. سامانه ثبت درخواست با چند مرحله ثابت ممکن است به یک عامل آزاد نیاز نداشته باشد؛ انعطاف بیشتر زمانی ارزش دارد که مسئله واقعاً آن را طلب کند.
یک نمونه فرضی را در نظر بگیرید: کاربر می‌خواهد وضعیت سفارش را بداند. اگر مسیر همیشه احراز هویت، دریافت شناسه و خواندن وضعیت است، اجرای صریح مراحل قابل فهم‌تر خواهد بود. اگر لازم است چند سند بررسی شود و اطلاعات متناقض کنار هم قرار گیرند، انتخاب پویا می‌تواند موضوع آزمایش باشد. پیشنهاد ما این است که اختیار هر مرحله را بر اساس نیاز همان کار تعیین کنید.
MCP چه نقشی دارد؟
طبق معرفی رسمی Model Context Protocol، MCP یک استاندارد باز برای اتصال برنامه‌های هوش مصنوعی به سامانه‌های خارجی مانند داده و ابزار است. این استاندارد، قالب مشترکی برای ارتباط فراهم می‌کند. با این حال، استاندارد بودن اتصال به معنای درست بودن داده، مجاز بودن هر اقدام یا امن بودن هر سرور متصل نیست؛ این تصمیم‌ها همچنان به طراحی و اداره سامانه وابسته‌اند.
برای یک تیم نرم‌افزاری، ارزش یک اتصال مشترک در روشن شدن قراردادهاست. مثلاً ابزار «خواندن وضعیت درخواست» باید ورودی، خروجی و خطاهای مشخص داشته باشد. بهتر است یک ابزار واحد مسئول خواندن و حذف و تغییر هم‌زمان نباشد. نام دقیق، توضیح کوتاه و چند مثال مرزی، برای کاربر فنی و مدل هر دو مفیدند. چنین قراردادی هنگام عوض شدن مدل هم قابل استفاده باقی می‌ماند.
اختیار را در برنامه کنترل کنید
راهنمای امنیت MCP خطرهایی مانند سوءاستفاده از اتصال و نشانی‌های نامعتبر را بررسی می‌کند. این راهنما در شاخه پیش‌نویس قرار دارد و هنگام پیاده‌سازی باید نسخه انتخاب‌شده دوباره بررسی شود. برای معماری پیشنهادی ما، نتیجه اصلی این است که کنترل دسترسی و اعتبارسنجی نباید فقط در متن دستور مدل نوشته شوند.
ابزار خواندنی را از ابزار تغییردهنده جدا کنید. برای عملیات حساس، خلاصه‌ای از اقدام پیشنهادی نشان دهید: چه چیزی تغییر می‌کند، برای کدام کاربر و با چه نتیجه‌ای. سپس خود برنامه مجوز لازم را بررسی کند. شناسه کاربر و نقش او باید از نشست معتبر بیاید، نه از جمله‌ای که مدل تولید کرده است. این قاعده در پشتیبانی، منابع انسانی و مدیریت پروژه کاربرد یکسانی دارد.
خطا و تکرار را از ابتدا طراحی کنید
قطع ارتباط یا پاسخ نامعلوم ابزار، بخشی از اجرای واقعی است. برای هر عملیات، وضعیت‌هایی مانند در حال انجام، موفق، ناموفق و نیازمند بررسی تعریف کنید. اگر نتیجه ثبت درخواست معلوم نیست، پیش از تکرار آن وضعیت را با شناسه عملیات بخوانید. کاربر نباید به دلیل چند بار فشردن یک دکمه، چند درخواست یکسان داشته باشد. محدودیت تعداد تلاش و زمان اجرا نیز مانع ادامه بی‌نتیجه می‌شود.
آزمایش با ابزارهای بی‌خطر
پیش از اتصال به محیط اصلی، یک ابزار آزمایشی بسازید که پاسخ‌های عادی و خطای کنترل‌شده برگرداند. بررسی کنید عامل ابزار درست را انتخاب می‌کند، ورودی مجاز می‌فرستد و نتیجه ناموفق را موفق گزارش نمی‌کند. نمونه‌ای با داده ناقص و نمونه‌ای با درخواست خارج از اختیار هم لازم است. ثبت انتخاب ابزار و نتیجه آن، علت خطا را روشن‌تر از ذخیره تنها متن نهایی می‌کند.
یک اجرای حرفه‌ای از فهرست بلند ابزارها شروع نمی‌شود؛ از یک کار مشخص و قرارداد دقیق شروع می‌شود. وقتی مسیر ساده قابل اتکا شد، می‌توان ابزار و استقلال بیشتری افزود. هر افزایش اختیار باید همراه با روش سنجش و امکان توقف باشد. این رویکرد کمک می‌کند عامل هوشمند به بخشی قابل نگهداری از سامانه سازمان تبدیل شود و مسئولیت عملیات در میان اجزای مبهم گم نشود.
منابع و مطالعهٔ بیشتر
بررسی منابع: ۲۱ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
