ابزار ایجنت یک قابلیت محدود با نام، توضیح، ورودی و خروجی مشخص است که مدل می تواند آن را انتخاب کند. طراحی خوب ابزار یعنی مدل دقیقا بداند چه زمانی آن را صدا بزند و سامانه نیز پیش از اجرا، داده و مجوز را مستقل از مدل بررسی کند.
بسیاری از ایجنت ها در گفتگو خوب به نظر می رسند اما هنگام اتصال به سامانه واقعی شکست می خورند. علت اغلب مدل نیست؛ ابزار مبهم است. تابعی با نام عمومی، ده ها پارامتر اختیاری و خروجی نامنظم، مدل را وادار به حدس زدن می کند. هر حدس در محیط عملیاتی می تواند به سفارش تکراری، پیام اشتباه یا تغییر ناخواسته داده برسد.
طراحی ابزار شبیه طراحی یک پنل کنترل ایمن است. هر دکمه باید یک کار روشن انجام دهد، وضعیت موفق یا ناموفق را برگرداند و برای کار حساس قفل جدا داشته باشد. مدل پیشنهاد می دهد، اما سرویس اجراکننده باید مرزها را تحمیل کند.
ابزار کوچک بهتر از ابزار همه کاره است
به جای تابعی با عنوان مدیریت مشتری، قابلیت ها را به کارهای روشن مانند یافتن مشتری با شماره، خواندن آخرین سفارش و ساخت پیش نویس پیگیری تقسیم کنید. ابزار کوچک انتخاب را برای مدل ساده می کند و ثبت رویداد را دقیق تر می سازد.
اندازه مناسب با مرز کسب و کار تعیین می شود. ابزار نباید آن قدر ریز باشد که ایجنت برای یک کار ساده ده ها رفت و برگشت داشته باشد. در مقابل، تابعی که هم جستجو می کند، هم داده را تغییر می دهد و هم پیام می فرستد، امکان تایید جداگانه را از بین می برد.
- هر ابزار یک فعل روشن داشته باشد.
- خواندن و نوشتن را جدا کنید.
- اقدام برگشت ناپذیر را ابزار مستقل بسازید.
- توضیح ابزار شامل زمان استفاده و زمان عدم استفاده باشد.
قرارداد ورودی را سخت گیرانه بنویسید
ورودی آزاد دشمن قابلیت اطمینان است. نوع داده، طول متن، قالب تاریخ، واحد پول و مقدارهای مجاز را مشخص کنید. اگر شناسه مشتری لازم است، ابزار نباید نام تقریبی را به جای شناسه بپذیرد. مدل می تواند ابتدا ابزار جستجو را صدا بزند و سپس شناسه معتبر را تحویل دهد.
توضیح هر فیلد باید برای مدل قابل فهم باشد، اما اعتبارسنجی باید در کد انجام شود. هیچ دستور سیستمی جای کنترل سرور را نمی گیرد. داده مشکوک باید با خطای قابل اقدام رد شود تا ایجنت بداند چه چیزی را اصلاح کند.
- فیلدهای الزامی را کم اما قطعی نگه دارید.
- برای مقدارهای محدود از enum استفاده کنید.
- مثال درست و نادرست در توضیح ابزار داشته باشید.
- داده حساس را از متن آزاد جدا کنید.
خروجی ابزار باید برای تصمیم بعدی ساخته شود
خروجی تنها برای نمایش به کاربر نیست؛ ورودی تصمیم بعدی ایجنت است. به جای جمله مبهم عملیات انجام نشد، کد خطا، دلیل، امکان تلاش دوباره و اقدام پیشنهادی را برگردانید. خروجی ساختاریافته احتمال برداشت نادرست را کم می کند.
نتیجه موفق هم باید شناسه عملیات، زمان و وضعیت نهایی داشته باشد. اگر سرویس بیرونی پردازش را در صف گذاشته، عبارت موفق نباید به معنای پایان کار باشد. ایجنت باید تفاوت میان پذیرفته شد، در حال پردازش و تکمیل شد را بداند.
- وضعیت استاندارد موفق، موقت و ناموفق تعریف کنید.
- شناسه رهگیری را همیشه برگردانید.
- پیام مناسب انسان را از داده مناسب مدل جدا کنید.
- داده اضافی و طولانی را حذف کنید.
مجوز و تایید را بیرون از مدل نگه دارید
مدل نباید با نوشتن یک استدلال قانع کننده مجوز تازه بگیرد. هویت کاربر، نقش، دامنه داده و سقف اقدام باید در لایه اجرا بررسی شود. اگر کاربر فقط اجازه خواندن پرونده خود را دارد، ابزار حتی با ورودی صحیح نباید پرونده دیگران را برگرداند.
برای حذف، پرداخت، انتشار عمومی یا تغییر گسترده، پیش نمایش بسازید و تایید انسانی بگیرید. تایید باید به همان ورودی قفل شود؛ اگر مبلغ یا گیرنده پس از تایید تغییر کرد، مجوز قبلی باطل است.
- اصل کمترین دسترسی را اجرا کنید.
- توکن سرویس را مستقیم به مدل ندهید.
- هر فراخوانی را با هویت و ورودی ثبت کنید.
- برای اقدام حساس از تایید وابسته به محتوا استفاده کنید.
ابزار را با شکست واقعی آزمایش کنید
تست ابزار فقط مسیر موفق نیست. قطع شبکه، پاسخ دیرهنگام، داده ناقص، اجرای تکراری و تغییر نسخه API باید در سناریوها باشند. درخواست نوشتنی بهتر است کلید یکتا داشته باشد تا تلاش دوباره عملیات را دو بار انجام ندهد.
در ارزیابی ایجنت، جداگانه بسنجید آیا ابزار درست انتخاب شد، آیا ورودی درست ساخته شد و آیا نتیجه درست تفسیر شد. این تفکیک نشان می دهد مشکل از تصمیم مدل است یا از قرارداد فنی.
- برای timeout رفتار روشن تعریف کنید.
- اجرای تکراری را بی اثر یا قابل تشخیص کنید.
- نسخه قرارداد را ثبت کنید.
- هشدار نرخ خطا و زمان پاسخ بسازید.
نمونه تفاوت ابزار ضعیف و ابزار خوب
| بخش | طراحی ضعیف | طراحی قابل اعتماد |
|---|---|---|
| نام | manage_data | create_support_draft |
| ورودی | متن آزاد | شناسه، موضوع و محدودیت روشن |
| خروجی | یک جمله | وضعیت، شناسه و خطای ساختاریافته |
| مجوز | بر اساس درخواست مدل | بر اساس هویت و سیاست سرور |
| تلاش دوباره | احتمال اجرای تکراری | دارای کلید یکتا |
چک لیست اجرایی کوتاه
- نام ابزار را با یک فعل مشخص آغاز کنید.
- طرح ورودی و خروجی را نسخه بندی کنید.
- اعتبارسنجی و مجوز را در سرور اجرا کنید.
- ثبت رویداد و شناسه رهگیری اضافه کنید.
- مسیرهای خطا و اجرای تکراری را آزمایش کنید.
پرسش های رایج
Function Calling یعنی مدل خودش کد را اجرا می کند؟
خیر. مدل فقط نام ابزار و ورودی پیشنهادی را می سازد. برنامه شما ورودی را بررسی و ابزار را اجرا می کند.
آیا هر API را می توان مستقیم به ایجنت داد؟
از نظر فنی ممکن است، اما بهتر است یک لایه محدود و ایمن میان ایجنت و API اصلی قرار گیرد.
چند ابزار برای یک ایجنت مناسب است؟
عدد ثابت وجود ندارد. ابزارهای همپوشان و مبهم را کم کنید و تنها قابلیت های لازم برای هدف همان ایجنت را در دسترس بگذارید.