فرق ایجنت با چت‌بات چیه و کِی واقعاً به ایجنت نیاز داری؟

تفاوت واقعی در یک جمله

تعریف‌های رایج معمولاً روی چیزهای اشتباه تمرکز می‌کنن: اینکه ابزار داره یا نه، چند مرحله‌ایه یا نه، حافظه داره یا نه. هیچ‌کدوم مرز درستی نمی‌کشن.

تفاوت اصلی یه چیز دیگه‌ست: چه کسی تصمیم می‌گیره قدم بعدی چیه. توی یه چت‌بات، مسیر رو تو تعیین می‌کنی؛ سؤال می‌پرسی، جواب می‌گیری، سؤال بعدی رو خودت انتخاب می‌کنی. توی یه ایجنت، مدل تصمیم می‌گیره برای رسیدن به هدفی که دادی، قدم بعد چی باشه.

آناتومی حلقهٔ ایجنت

هر ایجنتی که واقعاً کار می‌کنه، یه حلقه‌ی ساده رو تکرار می‌کنه. پیچیدگی از تعداد تکرارها میاد، نه از خود حلقه:

1. جمع‌کردن زمینه — وضعیت فعلی چیه؟ چه اطلاعاتی برای تصمیم بعدی لازمه؟
2. عمل‌کردن — یه ابزار صدا زده می‌شه، یه فایل نوشته می‌شه، یه درخواست فرستاده می‌شه.
3. راستی‌آزمایی — نتیجه چی شد؟ آیا به هدف نزدیک‌تر شدیم یا نه؟
4. تکرار یا توقف — اگه کار تموم نشده، برگرد به یک؛ اگه تموم شده یا گیر کردیم، بایست.

ضعیف‌ترین حلقه‌ی این زنجیره تقریباً همیشه مرحله‌ی سوم است. ایجنتی که نمی‌تونه بفهمه کارش درست بوده یا نه، فقط داره با اعتماد به نفس اشتباه می‌کنه. برای همین توی کارهای کدنویسی، تست خودکار و typecheck اهمیت دارن: اون‌ها راستی‌آزماییِ ماشینی فراهم می‌کنن.

مرحله‌ی چهارم هم کمتر از چیزی که فکر می‌کنی بدیهیه. شرط توقف باید صریح باشه، وگرنه ایجنت یا زودتر از موعد دست می‌کشه یا توی یه حلقه‌ی بی‌پایان می‌افته و هزینه بالا می‌ره.

کِی چت‌بات کافیه

واگذارکردن تصمیم، هزینه داره: عدم قطعیت، هزینه‌ی محاسباتی، و سخت‌تر شدن دیباگ. اگه به این هزینه نیاز نداری، نده. این نشانه‌ها می‌گن چت‌بات کافیه:

• مسیر کار مشخصه و همیشه یه شکله.
• یک مرحله کافیه؛ ورودی می‌گیری، خروجی می‌دی، تموم.
• کاربر می‌خواد در هر مرحله کنترل داشته باشه — مثل نوشتن یه متن با بازخورد رفت‌وبرگشتی.
• هزینه‌ی اشتباه بالاست و بازگردانی سخته.

یه اشتباه رایج اینه که مسئله‌ای که با یه فرم و یه تابع حل می‌شه، با ایجنت حل بشه. اگه می‌تونی جریان کار رو روی کاغذ به‌صورت یه نمودار قطعی بکشی، احتمالاً کد معمولی جواب بهتری می‌ده.

کِی ایجنت ارزشش رو داره

ایجنت وقتی می‌ارزه که مسیر از قبل معلوم نباشه و کشف‌کردنش بخشی از کار باشه. سه تا نشونه‌ی روشن:

• تعداد مراحل از قبل معلوم نیست. «این باگ رو پیدا کن» یعنی نمی‌دونی سه تا فایل باید خونده بشه یا سی تا.
• نتیجه‌ی هر مرحله، مرحله‌ی بعد رو تعیین می‌کنه. جست‌وجو، تحقیق و عیب‌یابی همه همین شکلن.
• راستی‌آزمایی ماشینی داری. تست، لینتر، اسکیما، یا هر چیزی که بدون آدم بگه درست شد یا نه.

اون نشانه‌ی سوم مهم‌تر از دو تای اوله. ایجنت بدون راه راستی‌آزمایی، یه مولد حدسه. با راستی‌آزمایی، یه سیستمی‌ست که می‌تونه خودش رو اصلاح کنه — و همین‌جاست که ارزش واقعی‌ش ظاهر می‌شه.

یک مسئله، دو طراحی

انتزاع بالا کمکی نمی‌کنه تا وقتی روی یه مسئله‌ی مشخص پیاده نشه. مسئله: «گزارش بده این هفته چه تغییراتی روی محصول اعمال شده». ببینیم دو طراحی چه شکلی می‌شن.

طراحی چت‌باتی

تو کامیت‌های هفته رو می‌گیری، به مدل می‌دی، و می‌گی خلاصه کن. اگه خروجی کلی بود، می‌گی روی تغییرات کاربرمحور تمرکز کن. اگه چیزی جا افتاد، خودت پیداش می‌کنی و اضافه می‌کنی. سه تا رفت‌وبرگشت و تمام.

این طراحی قابل پیش‌بینیه، ارزونه، و اگه خروجی بد باشه بلافاصله می‌بینی. هزینه‌اش وقت خودته: هر هفته باید همین سه رفت‌وبرگشت رو تکرار کنی.

طراحی ایجنتی

هدف رو می‌دی و ابزارها رو: خواندن تاریخچه‌ی مخزن، خواندن دیف یه کامیت، خواندن تیکت‌های بسته‌شده. ایجنت خودش تصمیم می‌گیره کدوم کامیت‌ها ارزش باز کردن دارن، کدوم‌ها تغییر داخلی‌ان و به گزارش نمی‌رسن، و برای کدوم باید تیکت مرتبط رو هم بخونه.

این وقتی می‌ارزه که تعداد کامیت‌ها زیاد باشه و تشخیص «مهم» از «داخلی» خودش کار باشه. وقتی هفته‌ای پنج تا کامیت دارید، طراحی اول بهتره؛ وقتی دویست تا دارید، طراحی دوم.

هزینه، ریسک و مرزها

یه ایجنت که سی مرحله می‌ره، سی برابر یه فراخوانی ساده هزینه نداره؛ بیشتر داره. چون در هر مرحله تاریخچه هم بزرگ‌تر شده و دوباره فرستاده می‌شه. این یکی از دلایلیه که مدیریت کانتکست در ایجنت‌ها از چت‌بات‌ها حیاتی‌تره.

ریسک هم متفاوته. چت‌بات جواب اشتباه می‌ده و تو می‌بینی؛ ایجنت کار اشتباه می‌کنه و ممکنه تا چند مرحله بعد معلوم نشه. مرزهایی که باید از اول بذاری:

• سقف تعداد مراحل و سقف هزینه، با توقف خودکار.
• جداسازی خواندن از نوشتن: خواندن آزاد، نوشتن با تأیید.
• قابل بازگشت‌کردن هر عمل مخرب — یا اجازه ندادنش.
• لاگ کامل از اینکه کدوم ابزار با چه ورودی‌ای صدا زده شد.

اولین ایجنتت رو کوچک شروع کن

بهترین نقطه‌ی شروع، کاری‌ست که الان دستی انجام می‌دی، تکراریه، و اگه اشتباه بشه ضرر بزرگی نداره. مثلاً دسته‌بندی تیکت‌های ورودی، یا جمع‌کردن تغییرات هفته از مخزن کد.

1. هدف رو بنویس، نه مراحل رو. اگه مراحل رو نوشتی، یعنی هنوز چت‌بات می‌خوای.
2. کمترین ابزار لازم رو بده، و اول همه‌شون فقط‌خواندنی.
3. سقف مراحل رو کم بذار — مثلاً پنج. اگه گیر کرد، بهتره زود بایسته.
4. خروجی رو یه هفته کنار نسخه‌ی دستی بذار و مقایسه کن، بدون اینکه جایگزینش کنی.

بعد از اون هفته، شکست‌ها رو دسته‌بندی کن: انتخاب ابزار اشتباه، زمینهٔ ناکافی، توقف زودهنگام یا خروجی نادرست. هر کدوم راه‌حل متفاوتی داره و قاطی‌کردنشون باعث می‌شه ماه‌ها روی چیز اشتباهی کار کنی.

ساده‌ترین بخشی که بیشترین خطا رو کم می‌کنه اول اصلاح کن. معمولاً این کار، تیزکردن توضیح ابزارها یا اضافه‌کردن یه راه راستی‌آزمایی‌ست — نه عوض‌کردن مدل.