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