از چت‌بات تا ایجنت

چت ساده است: تو می‌نویسی، جواب می‌گیری. و دقیقاً به‌خاطر همین سادگی یک سقف دارد که زود به آن می‌خوری.

در چت، تنها چیزی که مدل می‌بیند همان است که تو تایپ کرده‌ای (به‌علاوه‌ی چیزی که از داده‌ی آموزشش می‌آید — فصل ۱.۱). یعنی:

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

در فصل ۰.۲ همین را دیدی: با چت‌بات باید هشت فایل را یکی‌یکی باز کنی و بچسبانی. کار شدنی است؛ فقط تمام زحمتِ رساندنِ اطلاعات با توست.

تعریف رسمی‌ای که سازنده‌های این ابزارها می‌دهند کوتاه است: ایجنت یعنی یک LLM که در یک حلقه از ابزارها استفاده می‌کند. (رفرنسش پایین همین فصل است.)

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

این تفاوت همان چیزی است که در فصل ۰.۱ دیدی، فقط دقیق‌تر: قاعده‌ی ثابت مسیرش از پیش نوشته شده؛ ایجنت مسیر را در لحظه می‌سازد.

اینجا مهم‌ترین نکته‌ی این فصل است، و برخلاف تصور همه است.

به‌خاطر بسپار مدل خودش هیچ کاری انجام نمی‌دهد. فایل نمی‌خواند، دستور اجرا نمی‌کند، چیزی را پاک نمی‌کند. کاری که می‌کند این است که یک درخواستِ ساختاریافته تولید می‌کند — «ابزارِ خواندنِ فایل را با این آدرس صدا بزن» — و برنامه‌ی اطرافش آن را اجرا می‌کند و نتیجه را برایش برمی‌گرداند.

به این کار tool یا function-calling می‌گویند. مراحلش دقیقاً این است:

1. به مدل می‌گویند چه ابزارهایی در دسترس است و هرکدام چه کار می‌کند.
2. مدل تصمیم می‌گیرد که برای این درخواست، کدام ابزار لازم است.
3. به‌جای متن، یک درخواست صدا زدن ابزار برمی‌گرداند.
4. برنامه‌ی بیرونی آن را اجرا می‌کند — نه مدل.
5. نتیجه به مدل برگردانده می‌شود، و مدل با آن ادامه می‌دهد.

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

چیزی که ایجنت را از یک صدا زدنِ ساده جدا می‌کند، تکرار است. این چهار قدم یک بار اتفاق نمی‌افتند؛ می‌چرخند:

1. می‌بیند — چه چیزی تا اینجا هست: درخواست تو، و نتیجه‌ی کارهای قبلی.
2. نقشه می‌کشد — قدم بعدی چه باید باشد.
3. درخواست ابزار می‌دهد — و برنامه اجرایش می‌کند.
4. نتیجه را می‌خواند — و برمی‌گردد به قدم اول.

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

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

حالا جواب سؤالی که شاید در فصل ۰.۱۰ برایت پیش آمد: چرا وسط کار اجازه می‌خواهد؟

چون همان‌طور که دیدیم، بین «مدل تصمیم گرفت» و «کار انجام شد» یک مرحله فاصله هست — برنامه باید اجرایش کند. و هر جایی که فاصله باشد، می‌شود یک دروازه گذاشت. permission همان دروازه است.

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

و سطوح خودمختاری یعنی: این دروازه کجاها باز بماند.

• هر قدم اجازه بگیرد — کندترین، امن‌ترین. برای شروع و برای کار روی فایل‌های واقعی.
• فقط کارهای تغییردهنده اجازه بگیرند — خواندن آزاد، نوشتن و پاک‌کردن با اجازه. تعادلِ رایج.
• بدون اجازه — سریع‌ترین، پرریسک‌ترین. فقط در زمین بازی (فصل ۰.۹) یا جایی که واقعاً هیچ‌چیزش مهم نیست.

اینکه قبل از زدن «بله» چه چیزی را باید بخوانی، خودش یک درس کامل است: درس ۳.۳.