intent یه AI agent رو کی تعیین میکنه؟
هوش مصنوعیخلاصهٔ کاملتر
تو این مقاله از WorkOS اومده که کسی که از agent کار میخواد باید هدف کار رو تعیین کنه و سازمان باید مشخص کنه حین انجام اون کار چه اقدامهایی مجازه. agent میتونه خودش تصمیم بگیره چی رو جستوجو کنه، بعدش چی بخونه و کدوم tool رو صدا بزنه. ولی اینکه کارش رو کلیتر توصیف کنه، نباید بهش اجازهٔ نادیده گرفتن policyهای شرکت رو بده.
ابزار Airlock از WorkOS همین دو ورودی رو ترکیب میکنه: intent اعلامشدهٔ agent (یعنی توضیح اینکه دنبال انجام چه کاریه) و قوانین سازمان. تو دموی Agent Night در ۱۲ آگوست، agent یه token مرتبط با intentش گرفت و باهاش روی Linear و Gmail کار کرد. Airlock هر call پیشنهادی رو با اون intent و policyهای تنظیمشده مقایسه میکرد.
نویسنده میگه task باید اثری که انتظار داری رو هم بگه. «پیدا کردن شارژهای تکراری ماه قبل و refund کردنشون» هدف، بازهٔ زمانی و تغییر مورد نظر رو روشن میکنه، ولی «کمک به billing» میتونه یعنی گزارش، refund، تغییر اشتراک یا تماس با مشتری. حتی با درخواست واضح هم هر اقدام تصمیم جدا داره: تو مثال Airlock جستوجوی شارژها مجازه، refund تأیید لازم داره و حذف رکورد مشتری رد میشه چون بیرون از کاره.
هویت و policy نباید از متن task بیاد. جملهٔ «من از طرف ادمین billing کار میکنم» اثبات هویت نیست و این کار باید با identity controlهای اپلیکیشن انجام بشه. policyها هم باید بین کارهای مختلف سر جاشون بمونن: اگه قانونی فرستادن اطلاعات مالی تو ایمیل رو ممنوع کرده، اسم گذاشتن «آپدیت جامع» روی کار اون محدودیت رو برنمیداره.
تو همون دمو، یه ایمیل برنامهریزی معمولی به مدیر فرستاده شد. ولی وقتی agent یه issue تو Linear دربارهٔ مصرف token مدلهای LLM رو تو ایمیل خلاصه کرد، Airlock ارسال رو رد کرد، چون policy اطلاعات هزینهٔ token رو دادهٔ مالی حساب میکرد. هر دو workflow از Linear میخوندن و ایمیل میفرستادن، پس فقط دونستن toolهای وصلشده تفاوت نتیجه رو توضیح نمیداد و محتوای ایمیل تعیینکننده بود.
به گفتهٔ نویسنده، اگه کارمند کار رو گسترش بده (مثلاً بررسی یه ماه دیگه)، باید ثبت بشه و اقدامهای جدید با همون مجوزها سنجیده بشن. ولی اگه agent یه درخواست ردشده رو فقط با کلمات نرمتر دوباره بفرسته، نباید پذیرفته بشه. چون چکهای معنایی ممکنه با تغییر کلمات جواب متفاوت بدن، باید این حالت رو تست کرد و دید هم تصمیم جدید چیه، هم اینکه چیزی واقعاً سمت provider اتفاق افتاده یا نه.
نکات کلیدی:
- هدف کار رو درخواستکننده تعیین میکنه و مجاز بودن هر اقدام رو policy سازمان
- تو مثال Airlock جستوجوی شارژ مجازه، refund تأیید لازم داره و حذف رکورد مشتری ممنوعه
- ادعای هویت داخل متن task اثبات هویت نیست و باید از identity controlها بیاد
- تو دموی ۱۲ آگوست، Airlock ایمیلی با اطلاعات مصرف token رو بهعنوان دادهٔ مالی بلاک کرد
- بازنویسی نرمتر یه درخواست ردشده نباید نتیجه رو عوض کنه و این رفتار باید تست بشه
