چرا مدل‌های قدرتمندتر هم نمی‌توانند عامل‌های هوش مصنوعی شما را نجات دهند؟

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

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

تعریف آستانهٔ عامل‌گونه

برای تشخیص اینکه آیا یک سیستم واقعاً عامل است یا خیر، نویسنده سه آزمون تعیین‌کننده پیشنهاد می‌کند:

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

طبق گزارش فنی دقیقی که در ۸ ژوئن ۲۰۲۶ در وب‌سایت dev.to منتشر شد، تیم‌هایی که در محیط عملیاتی موفق بوده‌اند، به دنبال آخرین نسخه‌های مدل‌ها نیستند. در عوض، آن‌ها روی سه ستون تمرکز کرده‌اند: طراحی ابزار، مدیریت شکست و قابلیت مشاهده (Observability). آن‌ها به‌جای ساخت موتورهای استدلالی عمومی، خط‌لول‌های محدود و هدفمندی را برای وظایفی خاص مثل دسته‌بندی پشتیبانی مشتری، استخراج داده از اسناد یا بازبینی کد در یک مخزن کد خاص می‌سازند.

واقعیت‌های محیط عملیاتی

تیم‌هایی که نتایج ضعیفی می‌گیرند، معمولاً فقط GPT-4 را با آخرین مدل‌های پیشرو جایگزین می‌کنند و انتظار تغییر رفتار دارند، بدون اینکه سیستم زیربنایی را تغییر دهند. در مقابل، تیم‌های موفق بر این موارد تمرکز می‌کنند:

• طراحی ابزار: اطمینان از اینکه رابط کاربری تمیز است و عامل دقیقاً می‌داند چه چیزی را می‌تواند فراخوانی کند.
• مدیریت شکست: تعریف دقیق اتفاقاتی که هنگام بازگشت اطلاعات بی‌فایده از یک ابزار رخ می‌دهد.
• قابلیت مشاهده: ایجاد ردپایی (Trace) که دقیقاً توضیح دهد چرا عامل تصمیم خاصی گرفته است.

در مورد «جنگ فریمورک‌ها»، نویسنده استدلال می‌کند ابزارهایی مثل LangChain، LangGraph، CrewAI، AutoGen و Semantic Kernel صرفاً داربست هستند. معماری واقعی — یعنی خودِ ساختمان — بر سه الگوی تکرارپذیر استوار است که فارغ از فریمورک مورد استفاده، کار می‌کنند:

• برنامه‌ریزی سپس اجرا: جداسازی گام استدلالی که برنامه را تولید می‌کند از گام اجرایی که پس از آن می‌آید. این دو را با هم ترکیب نکنید.
• بازیابی در برابر استدلال: متمایز نگه داشتن فرآیند دریافت متن (Context) از فرآیند استفاده از آن. سیستم‌هایی که این دو وظیفه را با هم ادغام می‌کنند، اغلب دچار سردرگمی می‌شوند.
• تحویل صریح: اطمینان از اینکه وقتی یک عامل کار را به دیگری می‌سپارد، این انتقال ساختارمند و ثبت‌شده باشد، نه اینکه صرفاً یک رشته متن خام از طریق پرامپت منتقل شود.

یکی از شکست‌های رایج و مداوم در محیط عملیاتی، «مشکل بازیابی» در سیستم‌های RAG (تولید بازیابی‌افزا) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — است. نویسنده اشاره می‌کند که اکثر آموزش‌ها این حقیقت را نادیده می‌گیرند که مرزهای تکه‌تکه‌سازی متن (Chunking) اغلب اشتباه هستند. وقتی یک سند به تکه‌ها تقسیم و جاسازی (Embed) می‌شود، فرض‌هایی درباره اینکه کدام بخش‌های متن متعلق به یکدیگر هستند، پذیرفته می‌شود.

سازوکار شکست در RAG

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

برای رفع این مشکل، مهندسان باید به سمت تکه‌تکه‌سازی معنایی، پنجره‌های هم‌پوشان یا بازیابی سند والد حرکت کنند. در بسیاری از موارد، راه حل یک مدل بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه «همسایه‌ی» چه کلمات دیگری است — بهتر نیست، بلکه ذخیره نمایش‌های ساختارمند اطلاعات به‌جای متن خام است. اگر یک خط‌لول RAG نتایجی برمی‌گرداند که از نظر فنی درست اما از نظر زمینه‌ای بی‌فایده است، مشکل قطعاً در تکه‌تکه‌سازی یا متادیتا است.

این تغییر تمرکز به این معناست که ارزشمندترین مهندسان در دو سال آینده، کسانی نخواهند بود که در مهندسی پرامپت یا تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — تخصص دارند. صنعت به کسانی پاداش می‌دهد که هوش مصنوعی را یک چالش طراحی سیستم ببینند و بر حاکمیت و استفاده قابل‌اعتماد از ابزارها تمرکز کنند تا سیستم‌هایی بسازند که سایر مهندسان بتوانند واقعاً آن‌ها را نگهداری کنند و به آن‌ها اعتماد کنند.

اکوسیستم گسترده‌تر

در حالی که صنعت روی هزینه ابزارهایی مثل Claude Code (عامل ترمینالی آنتروپیک برای کدنویسی، دیباگ و استقرار کد) که می‌تواند تا ۲۰۰ دلار در ماه هزینه داشته باشد نظارت می‌کند، جایگزین‌هایی مثل Goose قابلیت‌های مشابه را رایگان ارائه می‌دهند. هم‌زمان، زیرساخت‌های بومی هوش مصنوعی در حال تکامل‌اند؛ برای مثال Railway، پلتفرمی در سان‌فرانسیسکو که ۱۰۰ میلیون دلار سرمایه جذب کرد تا با جذب دو میلیون توسعه‌دهنده بدون هزینه برای بازاریابی، AWS را به چالش بکشد.

حتی پایدارترین رابط‌ها در حال تغییرند؛ گوگل اخیراً کادر جستجوی خود را برای اولین بار در ۲۵ سال گذشته بازطراحی کرد که نشان‌دهنده تغییر در نحوه تعامل کاربران با اطلاعات است. با این حال، چالش مهندسی بنیادی یکسان باقی می‌ماند: ساخت اعتماد از طریق قابلیت مشاهده و استفاده قابل‌اعتماد از ابزارها، به‌جای تعقیب بنچمارک‌ها.

گام بعدی شما

• پشتهٔ عامل‌های فعلی خود را ارزیابی کنید: آیا به فریمورک تکیه کرده‌اید تا کارهای سخت را انجام دهد، یا معماری سخت‌گیرانه «برنامه‌ریزی سپس اجرا» را پیاده کرده‌اید؟
• استراتژی تکه‌تکه‌سازی (Chunking) در سیستم RAG خود را بازرسی کنید تا ببینید آیا نتایج «از نظر فنی درست» شما، در واقع از نظر زمینه‌ای بی‌فایده هستند یا خیر.
• برای کاهش هزینه‌ها، ابزارهای متن‌باز جایگزین برای Agentهای گران‌قیمت را بررسی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.