بیشتر تیمهای هوش مصنوعی برای بهبود عملکرد عاملها به همان اهرمهای همیشگی روی میآورند: پنجرههای زمینه بزرگتر، اسناد بیشتر و اعلانهای هوشمندتر. این مقاله استدلال میکند که این غریزه کاملاً اشتباه است. عنصر گمشده، اطلاعات بیشتر نیست. کنترل است. یک لایه کنترل با طراحی مناسب، عامل موفق در نسخه نمایشی را از عامل موفق در محیط عملیاتی متمایز میکند.
حافظه بزرگتر، اسناد بیشتر یا پنجره زمینه طولانیتر، عامل هوش مصنوعی را باهوشتر نمیکند؛ فقط آن را کندتر و پرهزینهتر میکند. پیشرفت واقعی زمانی حاصل میشود که عامل یاد بگیرد آنچه را نیاز دارد، در زمان نیاز انتخاب کند، نه اینکه همهچیز را یکجا مصرف کند.
قابلیت اعتماد از حلقه میآید، نه مدل. تفاوت عامل چشمگیر در نسخه نمایشی با عاملی که در محیط عملیاتی دوام میآورد، کیفیت هوش مصنوعی نیست؛ مهم این است که سیستم کار خودش را بررسی کند. عاملهایی که در هر گام برنامهریزی، اقدام، مشاهده و راستیآزمایی میکنند، بهجای اشتباهکردن با اطمینان کامل، خطاهای خود را تشخیص میدهند.
بیشتر عاملهای هوش مصنوعی امروز اساساً چتباتهایی با چند مرحله اضافهاند؛ هیچ سازوکاری ندارند تا بفهمند در مسیر درستاند، چه وقت متوقف شوند یا چه وقت رویکرد دیگری را امتحان کنند. افزودن یک لایه کنترل مناسب—معیارهای موفقیت روشن، وضعیت ساختیافته و بررسیهای اعتبارسنجی—چیزی عاملنما را به سیستمی تبدیل میکند که واقعاً میتوان به آن اعتماد کرد.
دیروز برای ناهار چه خوردید؟
احتمالاً همه خاطرات عمرتان را مرور نکردید تا به «دیروز + ناهار» برسید؛ مستقیم سراغ بخشی از تجربهتان رفتید که این مفاهیم در آن قرار دارند. این الگوی ذهنی مفیدی برای ساخت عاملها است:
یک پنجره زمینه عظیم، حافظه نیست.
انبوهی از اسناد بازیابیشده، درک نیست.
زنجیره تفکر طولانی، قابلیت اعتماد نیست.
اینها مواد اولیهاند. اما آنچه باعث میشود یک عامل واقعاً شبیه عامل باشد، همان چیزی است که مانع میشود مغزتان تمام تاریخ زندگیتان را با آزمونوخطا بگردد: کنترل.
یک بررسی تازه با عنوان استدلال عاملیتی برای مدلهای زبانی بزرگ، تغییری را که بسیاری از ما هنگام ساخت سیستمها حس کردهایم بهخوبی خلاصه و نامگذاری کرده است: گذار از استدلال درون مدل به استدلال از طریق تعامل. این نوشته خلاصه آن مقاله نیست. تلاشی است برای تبدیل این تغییر به طراحی عملی سیستم:
اگر عاملها را مانند چتباتهای مجهز به ابزار بسازید، همچنان با همان حالتهای شکست چتبات روبهرو میشوید، فقط با اشتباهاتی پرهزینهتر.
مدتی راهکار پیشفرض ما برای «هوشمندترکردن مدل» چنین بود: اعلانهای بهتر، زنجیره تفکر، خودسازگاری یا بهبودهای مبتنی بر نمونهگیری و شاید کمی جستوجو.
ReAct نقطه عطفی بود، چون «فکر ← اقدام ← مشاهده» را طبیعی جلوه داد. اما به محدودیت ضمنی توجه کنید: بخش زیادی از این رویکرد همچنان به «استنتاج بدون نمونه، اما با توکنهای بیشتر» ختم میشود. صورتبندی این بررسی دقیقتر است: استدلال عاملیتی بر گسترش تعامل در زمان آزمون تأکید دارد و استنتاج را به فرایندی تکرارشونده تبدیل میکند که مدل، حافظه و محیط همگی در حلقه باقی میمانند.
اگر عاملهایی ساختهاید یا بهکار بردهاید که در نمایشها چشمگیر اما در گردشکارهای واقعی شکنندهاند، این مطلب برای شماست.
بگذارید الگویی را شرح دهم که بارها دیدهام و قطعاً خودم نیز نسخههایی از آن ساختهام:
یک مدل چت خوب بردارید
چند ابزار اضافه کنید (جستوجو، پرسوجوی پایگاه داده و شاید اجرای کد)
RAG اضافه کنید
یک اعلان سیستمی با مضمون «تو یک عامل خودمختار هستی» اضافه کنید
همه را در یک حلقه while قرار دهید تا متوقف شود یا مهلتش به پایان برسد
تبریک، حالا یک موجود عاملنما دارید. اما معمولاً به روشهایی قابل پیشبینی شکست میخورد:
تورم زمینه: هر مشاهدهای اضافه میشود و اعلانها به لایههای باستانشناسی تبدیل میشوند.
سردرگمی در ابزارها: «ابزار اشتباه، اما با اعتمادبهنفس» به حالت شکست پیشفرض تبدیل میشود.
نبود شرط توقف: فقط چون میتواند ادامه میدهد، نه چون باید ادامه دهد.
نبود قاعده زمین گیر سازی: تا وقتی مجبورش نکنید، متوجه اشتباه خود نمیشود.
حافظه = تاریخچه چت: یعنی عملاً گزارش مینویسیم و نامش را یادگیری میگذاریم.
به همین دلیل «عاملها» اغلب در نمایشها جادویی و در محیط عملیاتی آشفته بهنظر میرسند. تجربه ما از استقرار سیستمهای عاملیتی در محیط عملیاتی نیز همین را نشان میدهد: وقتی دیگر یک مدل را ارزیابی نمیکنید و با یک سیستم روبهرو هستید، حالتهای شکست شامل مسیریابی، استفاده صحیح از ابزار، هرس زمینه و طراحی ارزیابی میشوند، نه فقط اینکه «آیا مدل پاسخ درست داد؟»
پس پرسش این است: عامل هدفمند چیست؟
برای ملموسترشدن موضوع، این گردشکار ساده را در نظر بگیرید که بیشتر افراد میتوانند تصورش کنند: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
یک پیادهسازی رایج که «شکل عامل» دارد، چنین است:
بلافاصله انبوهی از اسناد خطوط هوایی و سیاستهای سفر را بازیابی میکند، حتی اگر هنوز هیچکدام لازم نباشند.
ابزار جستوجو را فراخوانی میکند، فهرست بلندی از نتایج را در اعلان میچسباند و «یکی را انتخاب میکند».
بدون بررسی محدودیتها—زمان رسیدن، بار، صندلی و سیاستها—شتابزده رزرو میکند.
اگر شکست بخورد، با روشی کمی متفاوت دوباره تلاش میکند، اما درک روشنی از تغییرات یا آموختههایش ندارد.
مشکل این نیست که مدل نمیتواند استدلال کند؛ مشکل این است که سیستم گردشکار را کنترل نمیکند.
نسخهای عاملمحورتر، وظیفه را فرایندی تعاملی با وضعیت و بررسیهای صریح در نظر میگیرد:
برنامهریزی: بازگویی محدودیتها و فهرستکردن اطلاعات ناقص (مثلاً «کدام فرودگاه را ترجیح میدهید؟» یا «یک توقف قابل قبول است؟»).
اقدام: فراخوانی جستوجوی پرواز با پرسوجویی ساختیافته (بازه تاریخ، محدودیت زمان رسیدن و بودجه).
مشاهده: ذخیره نتایج در یک شیء وضعیت فشرده (۵ گزینه برتر همراه با قیمت، زمان رسیدن و توقفها)، نه انبوهی عظیم از متن چسباندهشده.
بهروزرسانی: اگر محدودیتها برآورده نشدند، پرسوجو را اصلاح کنید (مثلاً «رسیدن پیش از ساعت ۶ عصر بیش از حد سختگیرانه است؛ بازه زمانی را بیشتر کنیم یا بودجه را افزایش دهیم؟»).
راستیآزمایی: اجرای اعتبارسنجها («زمان رسیدن < 18:00»، «قیمت ≤ £900»، «مطابق سیاستها» و «امکان انتخاب صندلی»).
توقف: فقط وقتی API رزرو تأییدیه برگرداند و همه اعتبارسنجها تأیید کنند.
تغییر ایجادشده ظریف اما تعیینکننده است. بازیابی مشروط است، نه واکنشی؛ زمینه مدیریت میشود، یعنی وضعیت ساختیافته است نه انباشته؛ و راستیآزمایی درون حلقه انجام میشود، نه اینکه به کاربر واگذار شود. «رزرو پرواز» را با «ایجاد سفارش خرید»، «صدور بازپرداخت»، «تغییر پیکربندی محیط عملیاتی» یا «انتشار یک PR» جایگزین کنید؛ ماجرا همان است: وقتی عامل بتواند اقدام کند، حلقه از اعلان مهمتر میشود.
بررسی یادشده، استدلال عاملیتی را در سه لایه سازماندهی میکند: بنیادی (برنامهریزی، استفاده از ابزار و جستوجو)، خودتکاملی (بازخورد و حافظه) و جمعی (هماهنگی چندعاملی).
اما ایده عمیقتر این است: استدلال به اصل سازماندهنده برنامهریزی، تصمیمگیری و راستیآزمایی تبدیل میشود، نه صرفاً ابزاری برای تولید زنجیره تفکرِ باورپذیر. این موضوع انتزاعی بهنظر میرسد، تا زمانی که آن را با تغییرات معماری خود تطبیق دهید. سه نکته اصلی را باید به خاطر بسپارید:
یک عامل خوب نباید بازیابی را کاری بداند که «همیشه باید انجام شود». بازیابی یک تصمیم است، نه واکنش خودکار.
یک قاعده سرانگشتی کاربردی:
اگر سیستم شما در هر نوبت بازیابی میکند، بازیابی نساختهاید؛ فقط مالیات زمینه ایجاد کردهاید.
این مسئله همیشه در کار واقعی دیده میشود. هنگام اشکالزدایی یک رخداد محیط عملیاتی، همه گزارشها را در زمینه نمیریزید؛ براساس فرضیه فعلی خود تصمیم میگیرید در گام بعد کدام سنجهها یا گزارشها را دریافت کنید. این همان «بازیابی عاملیتی» است. الگویی ملموستر:
تصمیم بگیرید آیا به بازیابی نیاز دارید
اگر بله: پرسوجویی بنویسید، دریافت کنید، سریع مرور کنید و اطلاعات لازم را استخراج کنید
اگر شواهد متناقض بود: دوباره دریافت کنید
فقط پس از آن جمعبندی کنید
در همینجا «RAG عاملیتی» از RAG سنتی متمایز میشود: بازیابی به گامی سنجیده در استدلال تبدیل میشود، نه مرحلهای پیشفرض در خط پردازش.
همین که بهجای ارزیابی «یک مدل»، ارزیابی «یک سیستم» را آغاز کنید، ثبت و ردیابی وضعیت اهمیت پیدا میکند.
یکی از موضوعاتی که صنعت تاکنون آن را صریحتر کرده، مشاهدهپذیری گردشکارهای عامل است. برای مثال، کیت توسعه Agents شرکت OpenAI قابلیت ردیابی داخلی و داشبورد Traces دارد که اجرای عاملها را ثبت میکند—از جمله تولیدها، فراخوانی ابزارها، واگذاریها، حفاظها و رویدادهای سفارشی—تا بتوانید آنچه را گامبهگام رخ داده اشکالزدایی و ممیزی کنید.
این قابلیتی «خوب اما غیرضروری» نیست؛ تفاوت میان سیستمی است که میتوانید اشکالزدایی کنید و سیستمی که فقط میتوانید با حسوحال بسنجید.
بهنظر من، کاربردیترین بخش این بررسی، صراحت آن درباره بازخورد است. این بررسی بازخورد را به سه الگو تقسیم میکند: بازخورد تأملی (تولید ← نقد ← بازبینی)، سازگاری پارامتری (یادگیری با تنظیم دقیق یا RL) و بازخورد اعتبارسنجمحور (تلاش دوباره تا تأیید اعتبارسنج).
بیشتر تیمها بهتر است با بازخورد اعتبارسنجمحور شروع کنند، چون ساده و مؤثر است. اگر بتوانید هر نوع اعتبارسنجی بنویسید که آزمون واحد اجرا کند، الگو را بررسی کند، قواعد و محدودیتهای کسبوکار را اعمال کند («بازپرداخت بیش از X بدون ارجاع ممنوع») یا صحت واقعیتها را بسنجد («ذکر منبع الزامی است»)، میتوانید خروجی غیردeterministic مدل را به چیزی تبدیل کنید که واقعاً قابل اعتماد باشد.
یکی از تغییرات ساده اما پیشبینینشده این است: در دنیای عاملها، قابلیت اعتماد اغلب بیشتر از حلقه میآید تا مدل.
این کوچکترین قاعده حلقهای است که یافتهام و بدون آموزش، رفتار را بهشکلی قابل اعتماد بهبود میدهد:
گامبهگام عمل کنید: برنامهریزی ← اقدام ← مشاهده ← بهروزرسانی،
پس از هر اقدام، مشاهده را در ۱ تا ۳ مورد خلاصه کنید،
وقتی معیارهای موفقیت برآورده شد یا بودجه به پایان رسید، متوقف شوید؛ بهترین نتیجه موجود و ابهامهای باقیمانده را ارائه کنید.
هدف، پرحرفکردن مدل نیست. هدف، فهمپذیرکردن سیستم و واداشتن آن به «تماس با واقعیت» در هر گام است. نمونهای بسیار ملموس برای مهندسان، زمین گیر سازی حلقهبسته به سبک CI است:
برنامهریزی: پیشنهاد فهرست تغییرات
اقدام: اجرای آزمونها و lint
مشاهده: تجزیه خطاها
بهروزرسانی: اصلاح و تلاش دوباره
چند پرسش که معمولاً طراحیهای ناخواسته عاملگونه را آشکار میکنند:
«آیا عامل من انتخاب میکند چه چیزی را بازیابی کند، یا من همیشه همهچیز را بازیابی میکنم؟»
اگر بازیابی بیقیدوشرط باشد، هزینهاش را با تأخیر، مخارج بیشتر، رقیقشدن زمینه و افزایش خطر «ورودی بیکیفیت، خروجی بیکیفیت» میپردازید.
«آیا عامل من میتواند متوجه اشتباهش شود؟»
اگر تنها نشانه بازخورد عامل شما «کلافهشدن کاربر» است، درواقع با رنج انسان RL انجام میدهید. حلقه تلاش مجدد مبتنی بر اعتبارسنج، تمیزترین راه برای روبهروکردن آن با واقعیت است.
«آیا حافظه قابل نوشتن است و با گذشت زمان بهتر میشود؟»
اگر «حافظه» شما فقط تاریخچه چت را اضافه میکند، عملاً در حال ثبت گزارش هستید. نگاه این بررسی به حافظه مهم است: حافظه به زمینهای پویا و روبهرشد تبدیل میشود که عاملها بهمرور آن را پالایش میکنند، نه صرفاً یک رونوشت مکالمه.
گزارشها میگویند چه اتفاقی افتاد؛ حافظه میگوید دفعه بعد چه کنید. تاریخچه چت، رونوشت مکالمه است. حافظه، خطمشی در حال تکاملی است درباره اینکه چه چیزهایی ارزش انتقال به آینده را دارند.
برای شروع میتوانید جدول کوچکی از «درسهای آموختهشده» بسازید که کلیدهای آن نوع وظیفه، ابزار و حالت شکست و مقادیرش کارهای مؤثر و موارد قابل اجتناب باشد. هدف، ساختن یک گراف دانش بینقص نیست. هدف، ایجاد رفتاری انباشتی است: حافظه همراه با بازخورد، عاملها را از «دستیاران بدون وضعیت» به سیستمهایی تبدیل میکند که بهمرور بهتر میشوند.
وسوسهانگیز است که عاملهای بیشتری را به مسئله اضافه کنیم، اما این کار اغلب سربار هماهنگی را چندبرابر میکند. یک الگوی مناسب برای «تیم حداقلی کارآمد»:
هماهنگکننده: تجزیه و واگذاری کارها
مجری: فراخوانی ابزارها و اعمال تغییرات
منتقد/ارزیاب: بررسی درستی و ریسک
متولی حافظه: ثبت و پالایش درسها
اگر نمیتوانید مسئولیت هر عامل را توضیح دهید، احتمالاً هنوز به چند عامل نیاز ندارید.
اگر واقعاً این تغییر پارادایم را بپذیریم، احتمالاً دیگر همهچیز را در اعلانها نمیچپانیم، شکستها را خروجی نهایی نمیدانیم و عاملها را مانند چتباتها ارزیابی نمیکنیم. در عوض، عاملها را همان چیزی در نظر میگیریم که هستند: سیستمهای نرمافزاریای که زبان در آنها صفحه کنترل است و قابلیت اعتماد از حلقه میآید.
پیش از افزودن یک مدل دیگر، یک حلقه ارزیابی دیگر اضافه کنید. پیش از بازیابی همهچیز، بازیابی را مشروط کنید. پیش از انتشار ده اعتبارسنج، یکی را منتشر کنید. با حافظه مانند تصمیمهای مربوط به خطمشی رفتار کنید، نه یک پایگاه داده. و هنگام حرکت بهسوی معماری چندعاملی، با دو عامل شروع کنید، نه بیست عامل. اینها قانون نیستند؛ الگوهاییاند که در محیط عملیاتی دوام آوردهاند.