اگه خودت نمی‌تونی اتوماتیکش کنی، ایجنت کاربرت هم نمی‌تونه
هوش مصنوعیخلاصهٔ کامل‌تر
نویسنده با یه مثال شروع می‌کنه: فرض کن داری یه eval (یعنی تستی که می‌سنجه یه ایجنت هوش مصنوعی چقدر کارشو درست انجام می‌ده) می‌سازی تا ببینی ایجنت می‌تونه یه اپ رو روی پلتفرم ابری‌ت deploy کنه یا نه. وسط کار می‌بینی بعضی مراحل نیاز به پورتال دارن، احراز هویت تعاملیه و حتی فهمیدن موفق بودن deploy هم ساده نیست. حرف اصلی مقاله اینه: اگه خودت نمی‌تونی ورک‌فلوت رو اتوماتیک کنی، ایجنت‌های کاربرهات هم دقیقاً با همین مشکل‌ها درگیرن. پس دور زدنش توی هارنس فقط مشکل رو برای بقیه باقی می‌ذاره.
به گفتهٔ نویسنده، خیلی از ورک‌فلوها برای آدم طراحی شدن؛ ما یاد گرفتیم با ترفندها کنار بیایم ولی ایجنت این تجربه رو نداره. طبق گزارش Databricks، الان ایجنت‌ها ۸۰ درصد دیتابیس‌ها و ۹۷ درصد branchهای دیتابیس روی Neon رو می‌سازن. اصطکاک هزینه هم داره: ایجنت ورک‌فلو رو بارها اجرا می‌کنه و هر مرحلهٔ اضافه و هر retry، زمان و inference می‌خوره. یعنی یه ورک‌فلو می‌تونه از نظر فنی قابل اجرا باشه ولی Agent Experience (AX) یعنی تجربهٔ کار ایجنت با محصول، ضعیفی داشته باشه.
راه‌حل اول اینه که قابلیت‌ها رو با API، CLI یا ابزارهای MCP در اختیار بذاری، ولی نویسنده می‌گه پیچیدگی سر جاش می‌مونه و ایجنت هنوز باید همهٔ مراحل رو پیدا و هماهنگ کنه. یه skill هم می‌تونه راه‌حل موقت خوبی باشه، ولی کاربر باید بدونه وجود داره، نصبش کنه و به‌روز نگهش داره. فرصت بلندمدت اینه که خود ورک‌فلو ساده بشه؛ مثلاً یه عملیات واحد که از provisioning تا اعتبارسنجی رو با پیام‌های پیشرفت و خطاهای قابل‌فهم انجام بده.
برای پیدا کردن نقطه‌های اصطکاک، نویسنده پیشنهاد می‌کنه یه کار رایج رو با یه پرامپت ساده و هدف‌محور به ایجنت بدی و مراحل رو بهش دیکته نکنی. مراقب تخصص خودت باش، چون راحت ایجنت رو ناخواسته از مشکلاتی که کاربر کم‌تجربه بهشون می‌خوره رد می‌کنی. ببین کجا گیر می‌کنه، می‌تونه احراز هویت کنه، خطاها رو می‌فهمه یا نه. حتی ایجنتی که بعد از ده‌ها tool call اضافه موفق میشه، داره یه ورک‌فلوی گرون رو نشونت می‌ده.
یه نکتهٔ مهم دیگه دربارهٔ telemetry هست: ورک‌فلویی که ایجنت‌ها کم ازش استفاده می‌کنن ممکنه کم‌اهمیت به نظر بیاد، ولی شاید دلیلش اینه که اصلاً نمی‌تونن تمومش کنن. پس استفادهٔ کم می‌تونه نشونهٔ یه مانع باشه، نه تقاضای کم. نویسنده معتقده این ارزیابی باید بخشی از چرخهٔ توسعهٔ محصول باشه، چون مدل‌ها و هارنس‌ها مدام عوض می‌شن. همه‌چیز هم نیاز به اصلاح فوری نداره؛ گاهی پذیرفتن یه محدودیت تصمیم درستیه، به شرطی که آگاهانه باشه.
نکات کلیدی:
- سختی اتوماتیک کردن ورک‌فلو توی eval معمولاً یه مشکل محصوله، نه مشکل هارنس تست.
- طبق Databricks، ایجنت‌ها ۸۰ درصد دیتابیس‌ها و ۹۷ درصد branchها رو روی Neon می‌سازن.
- API و ابزار MCP دسترسی می‌دن ولی پیچیدگی هماهنگ کردن مراحل رو حذف نمی‌کنن.
- skillها به نصب و به‌روزرسانی توسط کاربر وابسته‌ن و راه‌حل موقت حساب می‌شن.
- استفادهٔ کم ایجنت‌ها از یه ورک‌فلو توی telemetry می‌تونه نشونهٔ مانع باشه، نه کم بودن تقاضا.
