فضای کار مشترک آدم و ایجنت: ثبت، صف، ارزیابی
خلاصهٔ کاملتر
ادعای شروع مقاله اینه که بیشتر تیمها مشکل بهرهوری ندارن، مشکل «ثبت» دارن. ایدهها تو اسلک بالا میآن، تسکها زیر تردهای ایمیل دفن میشن و یه نکتهٔ خوب وسط جلسه تا استندآپ بعدی نصفهنیمه فراموش میشه. ایجنتها میتونن ۲۰ تسک رو موازی اجرا کنن، ولی وقتی ورودیها پراکنده و خروجیها بازبینینشده باشن، ارزش چندانی از این ظرفیت درنمیآد.
نویسنده سه ایراد رایج رو نام میبره: نبود یه نقطهٔ ثبت واحد، نبود منطق صف (ایجنتها موردی تریگر میشن و کار تکراری یا شکاف پیش میآد)، و نبود لایهٔ ارزیابی که باعث میشه خروجیها مستقیم بریزن تو اینباکس آدم و فقط شکل تازهای از شلوغی بسازن. به باور اون راهحل «اتوماسیون بیشتر» نیست، ساختار بهتره.
لایهٔ اول ثبت (capture) ـه و همونجاست که بیشتر سیستمها اول شکست میخورن. قاعدهٔ عملی مقاله اینه: اگه وارد کردن یه تسک بیشتر از ۱۵ ثانیه طول بکشه، آدمها مرتب انجامش نمیدن. طراحی درست یعنی موقع ثبت هیچ تصمیمی لازم نباشه — نه دستهبندی، نه اولویت. الگوهای کاربردی هم ایمیل اختصاصی، اسلشکامند اسلک، افزونهٔ مرورگر تککلیکی و فرم سادهست.
یه ایجنت سبک هم میتونه سر همین لایه بشینه و ورودی رو غنی کنه: کانتکست رو از لینک بکشه بیرون، تسک رو تگ بزنه، سطح تلاش رو تخمین بزنه و به زیرصف درست (تحقیق، نویسندگی، تحلیل داده) بفرسته. نتیجه اینه که ایجنتهای پاییندست به جای تسک خام و مبهم، تسک ساختاریافته تحویل میگیرن.
لایهٔ دوم صفه. برخلاف نرمافزار سنتی که تسکها رو پشت سر هم اجرا میکنه، سیستم چندایجنتی همزمان کار میکنه و زمان اتمام به کندترین تسک بستگی داره نه مجموع همه. شرط معماریش اینه که هر ایجنت نسبت به تسک بدون حالت باشه. ساختار صف هم بهتره سهردیفه باشه: فوری و بلاککننده، استاندارد، و بچ کماولویت که تو ساعات خلوت اجرا میشه.
وابستگیها هم باید مدیریت بشن. راه ساده اینه که موقع ثبت، تسکها با وابستگیشون تگ بشن و پردازشگر صف قبل از ارسال، کامل بودن تسک بالادست رو چک کنه. برای ورکفلوهای چندمرحلهای پیچیده، نویسنده پیشنهاد میده ایجنتها مستقیم به هم زنجیر بشن به جای اینکه همهچیز از صف رد بشه.
لایهٔ سوم ارزیابیه و به گفتهٔ نویسنده چکلیست ارزیابی چیزی نیست که آدم بخوندش؛ مجموعهای از معیارهاست که یه ایجنت دیگه برنامهای بررسیشون میکنه — مثل یه لینتر برای خروجی ایجنتها. معیارها باید مخصوص نوع تسک باشن: برای خروجی تحقیقی مثلاً حداقل سه منبع مجزا و خلاصهٔ زیر ۳۰۰ کلمه؛ برای پیشنویس محتوا تطابق لحن و حضور بخشهای الزامی؛ برای خلاصهٔ داده قابل ردیابی بودن همهٔ اعداد به منبع.
برای قضاوتهای ظریفتر الگوی LLM-as-judge پیشنهاد میشه: یه مدل توانمندتر خروجی رو با یه روبریک نمره میده و بالاتر از آستانه (مثلاً ۸۵ درصد) خودکار عبور میکنه و پایینتر برای بازبینی انسانی فلگ میخوره. نویسنده هشدار میده که این لایه رو کاملاً خودکار نکنید: هر چیز مشتریمحور، تنظیمشده یا پرپیامد باید آدم توش باشه. اشتباههای رایج دیگه هم ساختن یه ایجنت غولپیکر به جای ایجنتهای تخصصی، بیتوجهی به انباشت صف و لاگ نکردن تصمیمهای ایجنته.
نکات کلیدی:
- سه لایهٔ ثبت، صف و ارزیابی؛ نبود هرکدوم کل سیستم رو شکننده میکنه
- اگه ثبت یه تسک بیشتر از ۱۵ ثانیه طول بکشه، عملاً انجام نمیشه
- تسک بدون حالت شرط لازم اجرای موازیه؛ صف بهتره سهردیفه باشه
- چکلیست ارزیابی رو یه ایجنت دیگه اجرا میکنه، نه آدم
- ایجنتهای باریک و تخصصی از یه ایجنت همهکاره بهتر جواب میدن




