آینده عامل‌های هوش مصنوعی یا AI Agent چه خواهد بود؟

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

مرور سریع: عامل هوشمند دقیقاً چیست؟

قبل از ورود به آینده، لازم است تعریفی مهندسی و دقیق از عامل داشته باشیم که بشود روی آن معماری ساخت. عامل هوشمند در ادبیات مهندسی، سیستمی است که در یک حلقه بسته از درک محیط (perception)، استدلال (reasoning)، اقدام (action) و بازخورد (feedback) کار می‌کند و بین چند گام تصمیم‌گیری، حالت خودش را حفظ می‌کند. تفاوت بنیادی عامل با یک مدل زبانی بزرگ (LLM - Large Language Model) ساده در همین حلقه بسته است؛ یک LLM خام، در هر فراخوانی بی‌حافظه است، اما عامل، یک فرآیند حالت‌دار (stateful) است که در طول زمان یاد می‌گیرد و مسیر خودش را اصلاح می‌کند.

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

یک نکته که کمتر گفته می‌شود: عامل‌ها در ادبیات کلاسیک هوش مصنوعی (AI - Artificial Intelligence) از دهه ۱۹۸۰ وجود داشته‌اند؛ آنچه امروز متفاوت است، ورود مدل‌های زبانی بزرگ به‌عنوان هسته استدلال است. این جایگزینی، هزینه‌های محاسباتی را بالا برده اما توانایی حل مسائل باز (open-ended) را چند برابر کرده است. مسئله‌ای که آینده عامل‌ها را تعیین می‌کند این است که آیا این هسته استدلالی می‌تواند به سطحی از پایداری برسد که در محیط‌های حساس و پرهزینه قابل اتکا باشد. همین پرسش، محور همه بحث‌های مهندسی امروز است.

عامل هوشمند، یک برنامه نیست؛ یک فرآیند زنده است که در هر گام دوباره تصمیم می‌گیرد و همین بازتصمیم‌گیری، منبع قدرت و شکنندگی اوست.

وضعیت امروز: از شعار تا واقعیت

بازار عامل‌های هوش مصنوعی امروز در وضعیت دوگانه‌ای است. از یک سو، دموهای چشمگیر و پروژه‌های تحقیقاتی که قابلیت‌های خیره‌کننده نشان می‌دهند؛ از سوی دیگر، استقرارهای تولیدی که در عمل بسیار محدودتر از آنچه تبلیغ می‌شود کار می‌کنند. تجربه من از بررسی پروژه‌های واقعی نشان می‌دهد که عامل‌ها امروز در سه دسته کاربرد به بلوغ نسبی رسیده‌اند: خودکارسازی تک‌کاره و محدود (single-task automation)، دستیارهای گفتگو با ابزار محدود، و جریان‌های کاری که انسان در حلقه (human-in-the-loop) دارد. خارج از این سه دسته، ادعای خودمختاری کامل بیشتر از واقعیت، یک روایت بازاریابی است.

در بررسی‌های واقعی، عامل‌ها در حل مسائل چندمرحله‌ای با محیط پایدار و محدود خوب عمل می‌کنند. اما به محض اینکه محیط غیرقطعی (stochastic) یا دارای ابزارهای آسیب‌پذیر می‌شود، نرخ شکست به سرعت بالا می‌رود. این الگو را در پروژه‌های خودکارسازی فرآیند هم دیده‌ام؛ عامل‌های هوش مصنوعی در اتوماسیون فرآیندها را اگر خوانده باشید، همین مرز را با جزئیات توصیف کرده‌ام.

سه دلیل بنیادین برای این فاصله میان ادعا و واقعیت وجود دارد. اول، مسئله زمین‌گیر شدن خطای مرکب: اگر هر گام عامل با دقت ۹۹٪ انجام شود، در یک زنجیره ۵۰ گامی، احتمال موفقیت کل به کمتر از ۶۰٪ می‌رسد. دوم، مسئله حافظه بلندمدت که در ادامه جداگانه بررسی می‌کنم. سوم، مسئله ارزیابی: هنوز معیار دقیق و همه‌جانبه‌ای برای سنجش عاملیت (agency) در مسائل واقعی وجود ندارد. این سه مسئله، به‌نظر من مرزهای اصلی تعیین‌کننده آینده پنج‌ساله خواهند بود.

معماری‌های عاملی: ReAct، ToT، LATS و Reflexion

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

ReAct: استدلال و اقدام در هم تنیده

الگوی ReAct (Reasoning and Acting) که در سال ۲۰۲۲ توسط تیم‌های تحقیقاتی معرفی شد، به‌عنوان پایه اصلی تقریباً همه عامل‌های امروزی عمل می‌کند. در این الگو، مدل به‌جای اینکه یک بار پاسخ نهایی بدهد، در چرخه‌ای از گام‌های استدلال و اقدام حرکت می‌کند. هر گام شامل یک بلوک Thought (اندیشه)، یک بلوک Action (اقدام) و یک Observation (مشاهده) است. مزیت این ساختار در قابلیت رهگیری است: هر تصمیم، اثر انگشت قابل بازبینی دارد.

در کد، این الگو معمولاً به شکلی شبیه زیر پیاده‌سازی می‌شود:

while not done:
    thought = llm_think(state, goal)
    action = llm_choose_action(thought, tools)
    observation = execute(action)
    state = update(state, thought, action, observation)
    if should_stop(observation):
        done = True

نقطه ضعف ReAct در مسائل پیچیده‌ای است که نیاز به بازگشت و تصحیح مسیر دارند؛ چرا که این الگو خطی است و حافظه‌اش محدود به پنجره زمینه (context window) مدل است.

Tree of Thoughts (ToT): جستجو در فضای راه‌حل

ToT (Tree of Thoughts) مسئله را به‌صورت یک درخت تصمیم مدل می‌کند: در هر گام، چند مسیر جایگزین ساخته می‌شود و بر اساس یک تابع ارزیابی، امیدبخش‌ترین‌ها انتخاب می‌شوند. این الگو برای مسائلی که نیاز به برنامه‌ریزی استراتژیک دارند، برتری محسوسی نشان می‌دهد. اما هزینه محاسباتی‌اش به‌شدت بالا می‌رود؛ چرا که به‌جای یک مسیر، ده‌ها مسیر موازی بررسی می‌شود.

LATS: ترکیب درخت و اقدام

الگوی LATS (Language Agent Tree Search) که در سال ۲۰۲۳ معرفی شد، سعی می‌کند مزیت ToT را با قابلیت اقدام ReAct ترکیب کند. در این معماری، عامل به‌جای یک مسیر خطی، یک درخت از حالت‌ها می‌سازد و از هر گره، چند اقدام جایگزین را امتحان می‌کند. سپس با استفاده از بازخورد محیط، درخت را هرس کرده و بهترین مسیر را انتخاب می‌کند. این معماری در مسائلی مثل تعامل با رابط‌های کاربری و اجرای کد، نتایج بهتری از ReAct می‌گیرد.

Reflexion: بازتاب و تصحیح خودآگاه

Reflexion یک مکانیزم خودبازتابی است: بعد از هر شکست یا نتیجه نامطلوب، عامل یک بازخوانی خودآگاه (self-reflection) انجام می‌دهد و درس‌های آن را در حافظه ذخیره می‌کند. در اجرای بعدی، این درس‌ها به‌عنوان زمینه استفاده می‌شوند. این مکانیزم، ترکیبی شبیه یادگیری تجربی (experiential learning) در انسان است و در آینده، به‌نظر من پایه اصلی سازگاری پیوسته عامل‌ها خواهد بود.

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

برنامه‌ریزی و استدلال در افق بلند

برنامه‌ریزی در افق بلند، یکی از سخت‌ترین مسائل حل‌نشده در معماری عامل‌هاست. مشکل این است که مدل‌های زبانی، در سطح گام (step) خوب عمل می‌کنند اما در سطح برنامه (plan) که نیاز به نگهداشت هدف در افق چندین گام دارد، دچار واگرایی (divergence) می‌شوند. این واگرایی در مسائل واقعی خودش را به شکل‌های مختلف نشان می‌دهد: تکرار یک گام، فراموش کردن هدف میانی، انتخاب مسیر کوتاه‌مدت که هدف بلندمدت را نقض می‌کند.

سه رهیافت اصلی برای حل این مسئله وجود دارد. اول، رویکرد برنامه‌ریزی سلسله‌مراتبی (hierarchical planning) که در آن، هدف کل به زیرهدف‌ها شکسته می‌شود و هر زیرهدف به‌صورت مستقل حل می‌شود. دوم، رویکرد برنامه‌ریزی انعکاسی (reflective planning) که در آن، عامل در حین اجرا، مدل خودش را از محیط بازنگری می‌کند و مسیر را اصلاح می‌کند. سوم، رویکرد یادگیری مبتنی بر جستجو (search-based learning) که از نمونه‌های موفق گذشته یک سیاست (policy) می‌سازد.

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

برنامه‌ریزی بلندمدت در عامل‌ها، بیشتر شبیه کشتیرانی در مه است تا مسیریابی روی نقشه؛ هدف را می‌دانی اما مسیر را هر لحظه از نو می‌کشی.

حافظه: گلوگاه بنیادین

حافظه، به‌نظر من مهم‌ترین گلوگاه معماری عامل‌های امروز است و در پنج سال آینده، بزرگ‌ترین تغییرات در همین لایه رخ خواهد داد. مسئله این است که مدل‌های زبانی بزرگ، پنجره زمینه محدودی دارند و از طرف دیگر، اطلاعات مهم در طول یک کار طولانی باید در جایی نگه داشته شوند. سه نوع حافظه در معماری عامل‌ها وجود دارد که هرکدام منطق خودشان را دارند.

حافظه کاری (Working Memory)

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

حافظه کوتاه‌مدت (Short-Term Memory)

حافظه کوتاه‌مدت معمولاً در یک نشست (session) کار می‌کند و شامل خلاصه‌های دوره‌ای، یادداشت‌های موقت و وضعیت فعلی کار است. پیاده‌سازی آن معمولاً با ذخیره‌سازی در یک پایگاه داده موقت یا در حافظه سرور انجام می‌شود.

حافظه بلندمدت (Long-Term Memory)

حافظه بلندمدت، جایی است که مسئله جدی می‌شود. عامل در طول هفته‌ها و ماه‌ها باید بتواند تجربیات خودش را ذخیره کند و در موقعیت‌های مناسب بازیابی کند. پیاده‌سازی امروز این نوع حافظه معمولاً بر پایه پایگاه‌داده برداری (vector database) است. اما دو مسئله جدی در این رویکرد وجود دارد. اول، مسئله درجه‌بندی اهمیت: همه تجربیات ارزش یکسانی ندارند و ذخیره همه‌چیز، به مرور پایگاه‌داده را به یک انبار بی‌فایده تبدیل می‌کند. دوم، مسئله زوال (decay) و به‌روزرسانی: تجربه‌ای که در گذشته درست بوده، ممکن است امروز غلط باشد.

پروژه‌های تحقیقاتی مثل MemGPT سعی کرده‌اند این مسئله را با شبیه‌سازی معماری سیستم‌عامل حل کنند: حافظه کاری سریع، حافظه اصلی متوسط و حافظه ذخیره‌سازی بزرگ، با سیاست‌هایی برای انتقال اطلاعات بین این سه لایه. در پروژه‌های واقعی که با آن‌ها کار کرده‌ام، این معماری چندلایه نتایج محسوسی در نگهداشت زمینه بلندمدت داده است.

در پنج سال آینده، پیش‌بینی من این است که شاهد سه تحول در این لایه باشیم. اول، ظهور معماری‌های حافظه سازمانی (organizational memory) که در آن، عامل‌های مختلف یک سازمان، یک لایه حافظه مشترک داشته باشند. دوم، ظهور مکانیزم‌های استدلال روی حافظه که به‌جای بازیابی سطحی برداری، یک مدل استدلالی حافظه را پیمایش کند. سوم، ظهور پروتکل‌های استاندارد برای انتقال حافظه بین عامل‌ها.

ابزار، فراخوانی تابع و پروتکل‌های ارتباطی

ابزار، به‌معنای توانایی عامل برای انجام اقدام در دنیای بیرون است. از نقطه نظر مهندسی، فراخوانی ابزار (tool calling) یکی از پیچیده‌ترین بخش‌های معماری عامل است؛ چون عامل باید نه‌فقط بداند که کدام ابزار را انتخاب کند، بلکه باید پارامترهای درست را هم بسازد، خطاها را مدیریت کند و در صورت لزوم مسیر را عوض کند.

در سال‌های اخیر، دو تحول مهم در این لایه رخ داده است. اول، ظهور استانداردهایی مثل Function Calling که ساختار خروجی مدل را به شکل JSON (JavaScript Object Notation) قابل‌اعتبارسنجی درآورد. دوم، ظهور پروتکل‌های ارتباطی برای عامل‌ها که در ادامه به آن‌ها می‌پردازم.

Model Context Protocol (MCP)

MCP (Model Context Protocol) که توسط Anthropic معرفی شد، تلاش می‌کند استانداردی برای اتصال مدل‌ها به منابع داده و ابزارها بسازد. این پروتکل، شبیه USB-C برای ابزارهای هوش مصنوعی است: یک رابط استاندارد که به هر ابزار اجازه می‌دهد بدون پیاده‌سازی اختصاصی، با هر مدلی کار کند. در آینده نزدیک، انتظار می‌رود MCP به استاندارد صنعتی تبدیل شود و بخش بزرگی از ادغام‌های اختصاصی امروز را حذف کند.

Agent-to-Agent (A2A)

A2A (Agent-to-Agent) یک پروتکل سطح بالاتر است: ارتباط بین عامل‌ها به‌جای انسان-عامل. در این پروتکل، عامل‌ها می‌توانند درخواست‌ها، وضعیت‌ها و ظرفیت‌های خودشان را با یکدیگر به اشتراک بگذارند. این پروتکل، در آینده نزدیک پایه ساخت اکوسیستم‌هایی خواهد بود که در آن، عامل‌های تخصصی از فروشندگان مختلف، در یک جریان کاری مشترک با هم کار می‌کنند.

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

چندعاملی: از AutoGen تا A2A

سیستم‌های چندعاملی (multi-agent systems) یکی از داغ‌ترین حوزه‌های تحقیق امروز است و در پنج سال آینده، به‌نظر من یکی از مسیرهای اصلی گسترش قابلیت‌های هوش مصنوعی خواهد بود. پایه این ایده ساده است: اگر یک عامل نمی‌تواند مسئله پیچیده را حل کند، چرا آن را به چند عامل تخصصی نشکنیم؟

واقعیت اما پیچیده‌تر است. در بررسی‌های واقعی، سه مسئله بنیادین در سیستم‌های چندعاملی دیده‌ام. اول، مسئله هماهنگی (coordination): عامل‌ها باید روی یک هدف مشترک توافق کنند و در طول کار، این توافق را حفظ کنند. دوم، مسئله تخصیص نقش (role allocation): کدام عامل کدام بخش کار را انجام دهد و این تخصیص چه زمانی بازنگری شود. سوم، مسئله همگرایی (convergence): در برخی پروژه‌ها، دیده‌ام که چند عامل بدون رسیدن به نتیجه نهایی، در یک حلقه از بحث و بازبینی گرفتار می‌شوند.

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

در آینده، به‌نظر من دو تحول در این لایه رخ می‌دهد. اول، ظهور پروتکل‌های استاندارد برای هماهنگی بین عامل‌ها (که A2A یکی از نمونه‌های اولیه آن است). دوم، ظهور مکانیزم‌های یادگیری چندعاملی که در آن، عامل‌ها در طول همکاری، نقش‌ها و استراتژی‌های خودشان را بازتنظیم می‌کنند. این دومی، به‌طور مستقیم با مسئله یادگیری پیوسته پیوند دارد که در بخش بعدی به آن می‌پردازم.

در سیستم چندعاملی، هوش جمعی زمانی ظاهر می‌شود که هماهنگی، آسان‌تر از کنترل مرکزی باشد.

یادگیری و سازگاری پیوسته

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

یادگیری درون‌زمینه (In-Context Learning)

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

تنظیم دقیق (Fine-Tuning) دوره‌ای

رویکرد دوم، تنظیم دقیق دوره‌ای مدل روی داده‌های جمع‌آوری‌شده از تجربیات عامل است. این روش، در پروژه‌های سازمانی که حجم داده کافی دارند نتایج خوبی می‌دهد، اما چالش‌هایی مثل هزینه و نبود بازخورد سریع دارد.

یادگیری تقویتی از بازخورد (RLHF / RLAIF)

RLHF (Reinforcement Learning from Human Feedback) و RLAIF (Reinforcement Learning from AI Feedback) رویکردهایی هستند که در آن‌ها، مدل از بازخورد (انسانی یا هوش مصنوعی) یاد می‌گیرد. این رویکردها در پنج سال آینده، به‌نظر من به ستون اصلی سازگاری پیوسته عامل‌ها تبدیل می‌شوند؛ چرا که نیازی به تنظیم دقیق کل مدل ندارند و می‌توانند تنها روی یک لایه سبک از سیاست‌ها (policy) عمل کنند.

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

ارزیابی: معیارهای واقعی در برابر دمویی

اگر بخواهم یک ضعف جدی در حوزه عامل‌ها نام ببرم، آن ضعف، مسئله ارزیابی است. ما امروز معیار دقیقی نداریم که بگوید یک عامل در یک کار واقعی چند درصد موفق است. معیارهای موجود (مثل GAIA، SWE-Bench و WebArena) مفیدند اما هرکدام محدودیت‌های خودشان را دارند.

GAIA (General AI Assistants Benchmark)

GAIA یک معیار عمومی برای سنجش توانایی عامل‌ها در حل مسائل واقعی است. مسائل این معیار، چندمرحله‌ای و ترکیبی هستند و نیاز به استفاده از ابزار و استدلال پیچیده دارند. این معیار، در سال‌های اخیر به معیار استاندارد تبدیل شده، اما چون مسائل آن از فضای اینترنت انتخاب می‌شوند، امکان تقلب (benchmark contamination) بالاست.

SWE-Bench (Software Engineering Benchmark)

SWE-Bench به‌طور خاص روی حل مسائل واقعی GitHub تمرکز دارد. عامل باید بتواند issue را بفهمد، کد را بفهمد، تغییر را طراحی و پیاده‌سازی کند. این معیار، نزدیک‌ترین معیار به واقعیت برای کارهای نرم‌افزاری است، اما فقط بخشی از قابلیت‌های عامل را می‌سنجد.

WebArena

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

مسئله‌ای که در همه این معیارها مشترک است، مسئله انتقال (transfer) است: یک عامل که در محیط آزمایشگاهی موفق می‌شود، لزوماً در محیط واقعی موفق نخواهد بود. به‌نظر من، در پنج سال آینده، تمرکز تحقیقات به سمت معیارهای محیطی واقعی (realistic environment benchmarks) با پیچیدگی و عدم قطعیت بیشتر خواهد رفت. مسئله اعتمادپذیری عامل‌ها را هم در آیا عامل‌های هوش مصنوعی قابل اعتماد هستند؟ به تفصیل بررسی کرده‌ام.

ایمنی، همسویی و نظارت الگوریتمی

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

سه لایه ایمنی

در نگاه مهندسی، ایمنی عامل‌ها را می‌توان به سه لایه تقسیم کرد. لایه اول، ایمنی مدل پایه (foundation model safety) که همان همسویی مدل زبانی است. لایه دوم، ایمنی ابزار (tool safety) که مربوط به محدودکردن دسترسی‌های ابزار است. لایه سوم، ایمنی جریان کار (workflow safety) که مربوط به منطق تصمیم‌گیری عامل در طول اجراست.

همسویی (Alignment)

مسئله همسویی عامل‌ها، پیچیده‌تر از همسویی مدل‌های گفتگویی است. در مدل گفتگویی، هدف «تولید پاسخ مفید» است. در عامل، هدف «رسیدن به نتیجه مطلوب در محیط» است و این «نتیجه مطلوب» ممکن است به‌طور دقیق تعریف نشده باشد. این مسئله، در ادبیات با نام مسئله تعریف پاداش (reward specification problem) شناخته می‌شود.

نظارت الگوریتمی (Algorithmic Oversight)

چالش دیگری که در سال‌های اخیر ظاهر شده، مسئله نظارت است: وقتی عامل‌ها سریع‌تر از انسان‌ها تصمیم می‌گیرند، چطور می‌توان بر آن‌ها نظارت کرد؟ رهیافت‌های مختلفی برای این مسئله پیشنهاد شده، از جمله نظارت با مدل‌های کمکی، نظارت با وقفه‌های اجباری در نقاط بحرانی، و نظارت با جداسازی سطح تصمیم (decision-level isolation). به‌نظر من، در پنج سال آینده شاهد ظهور استانداردهای نظارتی برای عامل‌ها خواهیم بود، شبیه آنچه امروز در صنعت امنیت نرم‌افزار وجود دارد.

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

مشاهده‌پذیری و اشکال‌زدایی

مشاهده‌پذیری (observability) در عامل‌ها، امروز نه یک ویژگی لوکس، بلکه یک ضرورت عملیاتی است. مسئله این است: وقتی یک عامل نتیجه اشتباه می‌دهد، باید بتوانیم بفهمیم کجا اشتباه شده. این کار در مدل‌های ساده گفتگویی آسان است، اما در عامل‌ها که در طول چند ده گام تصمیم گرفته‌اند، بسیار پیچیده می‌شود.

ابزارهای مشاهده‌پذیری مثل LangSmith و LangFuse امروز این مسئله را تا حدی حل کرده‌اند. اما این ابزارها معمولاً در سطح رهگیری گام‌ها (step tracing) کار می‌کنند و نمی‌توانند بگویند چرا یک تصمیم گرفته شده. به‌نظر من، در پنج سال آینده، دو تحول در این لایه رخ می‌دهد. اول، ظهور مکانیزم‌های خودتفسیری (self-explanation) که در آن، عامل خودش دلیل تصمیمش را به‌طور ساختاریافته توضیح می‌دهد. دوم، ظهور ابزارهای اشکال‌زدایی تعاملی که به مهندس اجازه می‌دهند در یک گام خاص مداخله کند و ببیند اگر تصمیم تغییر کند چه اتفاقی می‌افتد.

اقتصاد و مهندسی هزینه و تأخیر

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

سه رهیافت اصلی برای کاهش هزینه وجود دارد. اول، استفاده از مدل‌های سبک‌تر برای گام‌های ساده و مدل‌های قوی‌تر برای گام‌های پیچیده (model routing). دوم، استفاده از مکانیزم‌های کشینگ (caching) برای گام‌های تکراری. سوم، استفاده از مدل‌های استنتاج سریع (speculative decoding) برای کاهش تأخیر.

مسئله تأخیر (latency) هم به‌همین اندازه مهم است. در کاربردهای گفتگویی، کاربر انتظار پاسخ در چند ثانیه را دارد؛ اما یک عامل که در طول چند گام فکر می‌کند، می‌تواند ده‌ها ثانیه طول بکشد. این مسئله، کاربردهای گفتگویی و کاربردهای جریان کاری را از هم جدا می‌کند. در آینده، پیش‌بینی من این است که معماری‌های هیبریدی (hybrid) رایج می‌شوند: یک هسته سریع که پاسخ‌های فوری می‌دهد و یک هسته کند که در پس‌زمینه کار می‌کند.

RAG عاملی و بازیابی پویا

RAG (Retrieval-Augmented Generation) یکی از ستون‌های معماری عامل‌های امروز است و به‌نظر من، در پنج سال آینده شکل بنیادینی تغییر خواهد کرد. RAG کلاسیک، در یک گام انجام می‌شود: بازیابی، سپس تولید. اما این الگو، در مسائل پیچیده چندمرحله‌ای جواب نمی‌دهد.

RAG عاملی (agentic RAG) این مسئله را حل می‌کند: به‌جای یک گام بازیابی، عامل در طول اجرا، چندین بار بازیابی می‌کند و هر بار بر اساس اطلاعات جدید، مسیر جستجوی بعدی‌اش را اصلاح می‌کند. این الگو در پروژه‌های تحقیقاتی و تحلیل اسناد پیچیده، نتایج محسوسی می‌دهد.

اگر با مفهوم RAG پایه آشنا نیستید، RAG چیست و چرا دقت مدل‌ها را بالا می‌برد را بخوانید. کاربردهای RAG در چت‌بات‌ها را هم در پیاده‌سازی RAG در چت‌بات‌ها بررسی کرده‌ام.

RAG کلاسیک، جستجو در یک قفسه کتاب است؛ RAG عاملی، یک کتابخانه‌دار باتجربه است که می‌داند کدام کتاب را در کدام لحظه بیاورد.

عامل‌های استفاده‌کننده از کامپیوتر

عامل‌های استفاده‌کننده از کامپیوتر (Computer Use Agents) یکی از جذاب‌ترین حوزه‌های امروز است و در پنج سال آینده، به‌نظر من بیشترین تحول را در کاربردهای کاربردی خواهد داشت. این عامل‌ها به‌جای تعامل با APIها، مستقیم با رابط‌های گرافیکی کار می‌کنند: مرورگر، سیستم‌عامل، نرم‌افزارهای دسکتاپ.

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

سه رهیافت برای کاهش این شکنندگی وجود دارد. اول، ترکیب مدل بصری با مدل ساختاری DOM (Document Object Model) که در آن، عامل هم تصویر را می‌بیند و هم ساختار HTML را. دوم، استفاده از ساب‌روتین‌های آماده برای کارهای تکراری. سوم، ترکیب مستقیم API و رابط گرافیکی بر اساس نوع کار.

استقرار سازمانی: از POC تا تولید

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

مانع اول: ادغام با سیستم‌های موجود

سازمان‌ها معمولاً سیستم‌های قدیمی و اختصاصی دارند که مستندات API ضعیفی دارند. عامل‌ها برای کار در این محیط‌ها، نیاز به لایه‌های انطباق (adapter layer) دارند که کار سنگینی است. اگر روی پروژه‌های سازمانی کار می‌کنید، کاربردهای عامل‌های هوش مصنوعی در کسب‌وکار را برای دیدن سناریوهای واقعی بخوانید.

مانع دوم: مسئله حکومت داده (Data Governance)

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

مانع سوم: مسئله مسئولیت (Liability)

وقتی یک عامل اشتباه می‌کند، مسئولیت با کیست؟ توسعه‌دهنده، سازمان، یا کاربر؟ این مسئله هنوز از نظر حقوقی حل نشده و همین، استقرارهای جدی را کند می‌کند. در سناریوهای حساس مثل پزشکی و مالی، این مسئله حتی مانع اصلی است.

بررسی کاربردهای عملیاتی در کاربرد عامل‌های هوش مصنوعی در پشتیبانی مشتری آمده است. همچنین نگاه کلی به خودکارسازی هوشمند در اتوماسیون با هوش مصنوعی چیست و چه مزایایی دارد و چشم‌انداز آن در آینده اتوماسیون با هوش مصنوعی بررسی شده است.

چشم‌انداز مقرراتی

مقررات در حوزه عامل‌ها، به‌نظر من در پنج سال آینده یکی از عوامل تعیین‌کننده مسیر تکامل خواهد بود. در حال حاضر، دو چارچوب اصلی وجود دارد: EU AI Act در اروپا و Executive Orderهای آمریکا. هر دو، عامل‌های خودمختار را در سطح ریسک بالاتر از مدل‌های گفتگویی می‌بینند.

سه مسئله کلیدی که مقررات آینده احتمالاً باید حل کنند: اول، الزام به تفسیرپذیری (explainability) در تصمیم‌های حساس؛ دوم، الزام به امکان بازگشت (rollback) در اقدام‌های خودمختار؛ سوم، الزام به افشای سطح عاملیت (agency disclosure) یعنی کاربر باید بداند در حال تعامل با یک عامل است یا یک انسان.

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

مسائل باز و نیمه‌باز

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

مسئله زمین‌گیر شدن خطای مرکب

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

مسئله حافظه واقعی

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

مسئله هماهنگی چندعاملی در مقیاس

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

مسئله هدف‌گذاری باز

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

سه سناریو برای پنج سال آینده

بر اساس همه آنچه در بخش‌های قبلی بررسی کردیم، سه سناریو برای آینده پنج‌ساله عامل‌ها می‌بینم. این سناریوها را نه به‌عنوان پیش‌بینی قطعی، بلکه به‌عنوان چارچوبی برای فکر کردن ارائه می‌کنم.

سناریوی محافظه‌کارانه: تخصص‌گرایی عمیق

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

سناریوی میانی: ترکیب انسان و عامل

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

سناریوی رادیکال: عامل‌های خودمختار در مقیاس

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

پرسش‌های پرتکرار درباره آینده عامل‌های هوشمند

آیا عامل‌های هوش مصنوعی تا پنج سال آینده جایگزین کارمندان می‌شوند؟ در بعضی از کارهای تکراری بله، اما جایگزینی کامل نه. تجربه من نشان می‌دهد که همکاری انسان و عامل، احتمالاً رایج‌ترین شکل همزیستی خواهد بود.

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

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

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

آیا عامل‌ها جایگزین مدل‌های زبانی می‌شوند؟ خیر. عامل‌ها روی مدل‌های زبانی ساخته می‌شوند و خودشان یک لایه بالاتر هستند. نقش مدل زبانی به‌عنوان هسته استدلال در LLM و انقلاب مدل‌های زبانی بزرگ بررسی شده است.

آیا حافظه بلندمدت عامل‌ها به سطح حافظه انسان می‌رسد؟ به‌نظر من، در پنج سال آینده، حافظه عامل‌ها در بعضی جنبه‌ها از حافظه انسان بهتر و در بعضی جنبه‌ها ضعیف‌تر خواهد بود. تکامل این لایه، یکی از جذاب‌ترین حوزه‌های تحقیق فعلی است.

آیا امکان همکاری بین عامل‌های شرکت‌های مختلف وجود دارد؟ در حال حاضر در سطح پروتکل‌های اولیه مثل A2A، بله. اما تجربه من این است که در پنج سال آینده، شاهد استانداردهای صنعتی بیشتر و ادغام‌های گسترده‌تر خواهیم بود.

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

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

آیا یادگیری عامل‌ها در آینده پیوسته می‌شود؟ این یکی از محتمل‌ترین تحولات پنج سال آینده است، هرچند در سطح لایه‌های سیاست (policy layer) و نه بازآموزی کامل مدل پایه.

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

چه زبان‌ها یا چارچوب‌هایی برای ساخت عامل‌ها مناسب‌ترند؟ Python زبان اصلی این حوزه است و چارچوب‌هایی مثل LangGraph، AutoGen و CrewAI محبوب‌ترین‌ها هستند. اما به‌نظر من، انتخاب چارچوب ثانویه است؛ مهم‌تر از آن، درک بنیادی معماری عاملی است.

افق پیش‌رو؛ نگاه یک معمار به نقشه پنج‌ساله

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

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

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

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

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

اگر در پروژه‌ای با یکی از این معماری‌ها کار کرده‌اید - مخصوصاً اگر به یک محدودیت غیرمنتظره برخورده‌اید - در دیدگاه‌ها بنویسید. همان تجربه‌های میدانی، دقیق‌ترین تصویر از آینده این حوزه را می‌سازد. 🤖