هوش مصنوعی سازمانی ایجنتیک

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

نوشته: تیم Databricks
۲ تیر ۱۴۰۵ — Databricks
یادداشت: این مطلب یک اقتباس و بازنویسی فارسی بر اساس مقالهٔ اصلی Databricks با عنوان Guide to Agentic Systems and AI Agents است. متن حاضر ترجمهٔ خط‌ به خط مقالهٔ اصلی نیست و برای مخاطب فارسی‌زبان بازنویسی و بومی‌سازی شده است.

از «پاسخ دادن» به «اقدام کردن»

نسل اول ابزارهای مبتنی بر هوش مصنوعی عمدتاً منتظر یک درخواست می‌ماندند و سپس پاسخی تولید می‌کردند. شما سؤال می‌پرسید، مدل متن یا کد تولید می‌کرد و کار تمام می‌شد.

اما یک Agentic AI System با چنین مدلی کار نمی‌کند.

در یک سیستم Agentic، کاربر لزوماً یک سؤال مشخص نمی‌پرسد؛ بلکه یک هدف تعیین می‌کند. سیستم سپس می‌تواند وضعیت موجود را بررسی کند، اطلاعات لازم را از منابع مختلف به دست آورد، یک برنامهٔ چندمرحله‌ای بسازد، ابزارهای مناسب را فراخوانی کند، اقدامات لازم را انجام دهد، نتیجه را ارزیابی کند و در صورت نیاز مسیر خود را تغییر دهد.

به بیان ساده:

همین تفاوت میان «پاسخ دادن» و «اقدام کردن» یکی از مهم‌ترین تغییرات در معماری سیستم‌های هوش مصنوعی است.

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

تفاوت اصلی Agent با یک مدل سادهٔ AI این است که Agent صرفاً رابطهٔ «ورودی ← خروجی» ندارد.

یک Agent می‌تواند:

• وضعیت کار را در طول فرایند حفظ کند؛
• تصمیم بگیرد از کدام مدل یا ابزار استفاده کند؛
• به پایگاه‌های داده و APIها دسترسی پیدا کند؛
• نتیجهٔ اقدامات قبلی را بررسی کند؛
• و بر اساس بازخورد، گام بعدی خود را تغییر دهد.

برای مثال، یک مدل زبانی معمولی می‌تواند برای شما یک گزارش ارزیابی تأمین‌کننده بنویسد.

اما یک Agent می‌تواند:

۱. اطلاعات تأمین‌کننده را از CRM دریافت کند؛
۲. قرارداد را بررسی کند؛
۳. شرایط پرداخت و تعهدات را استخراج کند؛
۴. اطلاعات را با سوابق قبلی مقایسه کند؛
۵. ریسک را ارزیابی کند؛
۶. گزارش را تهیه کند؛
۷. آن را برای تأیید مدیر ارسال کند؛
۸. و نتیجه را در سیستم سازمان ثبت کند.

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

در مقیاس سازمانی، یک Agent به‌تنهایی کافی نیست.

یک AI System مجموعه‌ای بزرگ‌تر است که مدل‌ها، داده‌ها، APIها، حافظه، ابزارها، زیرساخت اجرا و لایه‌های governance را در کنار هم قرار می‌دهد.

وقتی یک یا چند Agent در چنین معماری‌ای به‌گونه‌ای قرار می‌گیرند که بتوانند با حداقل دخالت انسان به سمت یک هدف مشخص حرکت کنند، با یک Agentic AI System روبه‌رو هستیم.

بنابراین، یک سیستم Agentic معمولاً از چند لایه تشکیل می‌شود:

درک محیط → استدلال و برنامه‌ریزی → اجرای اقدام → ارزیابی نتیجه → تکرار

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

یکی از ساده‌ترین مدل‌ها برای درک نحوهٔ کار Agentها، چرخهٔ چهارمرحله‌ای زیر است:

۱. Perceive — درک کردن

Agent ابتدا اطلاعات مربوط به وضعیت فعلی را جمع‌آوری می‌کند.

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

۲. Reason — استدلال کردن

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

Agent ممکن است یک کار بزرگ را به چند وظیفهٔ کوچک‌تر تقسیم کند و برای هرکدام ابزار مناسبی را انتخاب کند.

۳. Act — اقدام کردن

در این مرحله، تصمیم به یک اقدام واقعی تبدیل می‌شود.

مثلاً:

• اجرای یک Query؛
• فراخوانی یک API؛
• ایجاد یا ویرایش یک فایل؛
• ارسال پیام؛
• ثبت اطلاعات در ERP؛
• اجرای کد؛
• یا ارجاع کار به Agent دیگری.

۴. Learn / Reflect — بررسی و یادگیری

Agent نتیجهٔ اقدام خود را بررسی می‌کند.

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

این چرخه می‌تواند بارها تکرار شود تا هدف نهایی محقق شود.

در بسیاری از سیستم‌های Agentic امروزی، Large Language Model نقش موتور استدلال را بر عهده دارد.

LLM می‌تواند:

• هدف را تفسیر کند؛
• context مورد نیاز را دریافت کند؛
• اطلاعات بازیابی‌شده از memory و ابزارها را تحلیل کند؛
• برنامهٔ انجام کار را پیشنهاد دهد؛
• تصمیم بگیرد قدم بعدی چه باشد؛
• و خروجی ساختاریافته‌ای مانند function call یا پارامترهای یک API ایجاد کند.

اما نکتهٔ مهم این است که LLM به‌تنهایی یک Agent نیست.

مدل زبانی در قلب یک Agent قرار می‌گیرد، اما برای تبدیل شدن به یک سیستم عملیاتی به ابزار، memory، execution environment، orchestration و governance نیاز دارد.

یک مدل زبانی به‌خودی‌خود نمی‌تواند به سیستم‌های سازمانی دسترسی داشته باشد.

برای اینکه یک Agent بتواند کاری در دنیای واقعی انجام دهد، باید به ابزارها متصل باشد.

این ابزارها می‌توانند شامل موارد زیر باشند:

• Web Search
• پایگاه‌های داده
• CRM
• ERP
• Email
• سیستم‌های مالی
• سیستم مدیریت اسناد
• ابزارهای ارتباطی
• Code Interpreter
• APIهای داخلی سازمان
• سیستم‌های مانیتورینگ

در واقع، ارزش یک Agent تا حد زیادی به این بستگی دارد که به چه context و چه actionهایی دسترسی دارد.

استانداردهایی مانند Model Context Protocol یا MCP نیز در حال شکل دادن به یک روش استاندارد برای معرفی و فراخوانی ابزارها توسط مدل‌ها و Agentها هستند.

Agentی که فقط به context یک مکالمه دسترسی دارد، برای انجام کارهای طولانی‌مدت محدود خواهد بود.

به همین دلیل، سیستم‌های Agentic معمولاً از چند نوع memory استفاده می‌کنند.

Short-term memory اطلاعات مربوط به کار فعلی را نگه می‌دارد؛ برای مثال، تصمیم‌هایی که در چند مرحلهٔ اخیر گرفته شده‌اند.

Long-term memory می‌تواند شامل ترجیحات کاربر، سوابق workflow، دانش سازمانی و اطلاعاتی باشد که در آینده دوباره مورد استفاده قرار می‌گیرند.

در یک محیط سازمانی، Agent می‌تواند به‌طور هم‌زمان از دادهٔ لحظه‌ای و اطلاعات تاریخی استفاده کند.

برای مثال، در یک فرایند خرید، Agent نه‌تنها قیمت و موجودی فعلی را می‌بیند، بلکه می‌تواند خریدهای گذشته، تأمین‌کنندگان قبلی و سیاست‌های سازمان را نیز در نظر بگیرد.

یک سیستم Agentic تولیدی را می‌توان دست‌کم در سه لایهٔ اصلی دید:

Reasoning Layer

در این لایه، Agent تصمیم می‌گیرد چه کاری انجام شود.

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

Execution Layer

اینجا تصمیم‌ها به اثر واقعی تبدیل می‌شوند.

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

Orchestration Layer

این لایه هماهنگی کل فرایند را بر عهده دارد.

Orchestrator مشخص می‌کند:

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

برای بعضی از کارها، یک Agent واحد کافی نیست.

فرض کنید یک فرایند سازمانی به تحلیل مالی، بررسی حقوقی و ارزیابی فنی نیاز دارد. در چنین سناریویی می‌توان چند Agent تخصصی ساخت که هرکدام مسئول یک بخش باشند.

دو الگوی رایج وجود دارد.

معماری Hierarchical

یک Agent ناظر یا Supervisor وظیفهٔ اصلی را دریافت می‌کند و سپس آن را میان Agentهای تخصصی تقسیم می‌کند.

برای workflowهایی که ساختار مشخصی دارند، این الگو معمولاً قابل‌کنترل‌تر است.

معماری Decentralized

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

این روش انعطاف‌پذیری بیشتری دارد، اما مدیریت، audit و عیب‌یابی آن پیچیده‌تر است.

در سیستم‌های سازمانی بزرگ، ترکیبی از هر دو رویکرد نیز می‌تواند مورد استفاده قرار گیرد.

این دو مفهوم رقیب یکدیگر نیستند.

در واقع، Generative AI یکی از اجزای اصلی Agentic AI است.

Generative AI معمولاً برای تولید محتوا، خلاصه‌سازی، طبقه‌بندی، پاسخ به سؤال یا تولید کد به‌کار می‌رود.

اما وقتی همان مدل باید:

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

دیگر با یک تعامل سادهٔ Generative AI روبه‌رو نیستیم.

به‌همین دلیل می‌توان یک قاعدهٔ عملی ساده داشت:

در یک سیستم Agentic، LLM فکر می‌کند و Agent عمل می‌کند.

وقتی یک مدل فقط متن تولید می‌کند، خطای آن ممکن است صرفاً یک پاسخ اشتباه باشد.

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

به همین دلیل، سیستم‌های Agentic به governance بسیار جدی‌تری نیاز دارند.

یکی از اصول مهم، Least Privilege است:

هر Agent باید فقط به داده‌ها و ابزارهایی دسترسی داشته باشد که برای وظیفهٔ خودش ضروری است.

برای مثال، Agent منابع انسانی لازم نیست به سیستم مالی یا اطلاعات محرمانهٔ همهٔ مشتریان دسترسی داشته باشد.

همچنین بهتر است مجوزها در یک لایهٔ مستقل و قابل ممیزی تعریف شوند و صرفاً داخل منطق خود Agent قرار نگیرند.

خودکار بودن به معنای حذف انسان نیست.

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

مثلاً:

• حذف اطلاعات؛
• انجام تراکنش مالی؛
• انتشار یک سند رسمی؛
• تصمیم‌های حساس حقوقی؛
• یا اقدامات مهم عملیاتی

می‌توانند نیازمند تأیید انسانی باشند.

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

در یک سیستم Agentic، فقط دانستن نتیجه کافی نیست.

باید بتوانیم بعداً بفهمیم:

Agent چه دید؟
چه تصمیمی گرفت؟
از چه ابزاری استفاده کرد؟
چه داده‌ای دریافت کرد؟
چرا این اقدام را انجام داد؟
چه اتفاقی افتاد؟

به همین دلیل، Trace، Log و Metric بخش جدایی‌ناپذیر یک Agentic System در محیط production هستند.

هر Agent باید هویت مشخص داشته باشد و اقداماتش به‌گونه‌ای ثبت شود که بتوان مسیر تصمیم‌گیری را بازسازی کرد. این موضوع هم برای امنیت و هم برای compliance اهمیت حیاتی دارد.

Agentها در کنار ظرفیت بسیار بالای خود، ریسک‌های جدیدی نیز ایجاد می‌کنند.

Reward Hacking

اگر هدف به‌درستی تعریف نشده باشد، Agent ممکن است به‌جای انجام هدف واقعی، راهی پیدا کند که فقط معیار ظاهری موفقیت را بهتر کند.

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

دسترسی بیش از حد

اگر یک Agent به داده‌ها و ابزارهای زیادی دسترسی داشته باشد، یک خطا می‌تواند پیامد بسیار بزرگ‌تری ایجاد کند.

راهکار اصلی، محدود کردن دسترسی‌ها به حداقل مورد نیاز است.

Explainability

هرچه workflow پیچیده‌تر شود، توضیح اینکه Agent دقیقاً چرا به یک تصمیم رسیده دشوارتر می‌شود.

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

خدمات مشتری

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

این رویکرد برای حجم بالای درخواست‌های تکراری بسیار مناسب است.

توسعهٔ نرم‌افزار

Agentها می‌توانند یک Bug را بررسی کنند، آن را در محیط sandbox بازتولید کنند، کد مشکل‌دار را پیدا کنند، اصلاحیه پیشنهاد دهند، تست‌ها را اجرا کنند و حتی Pull Request ایجاد کنند تا مهندس آن را بازبینی کند.

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

زنجیرهٔ تأمین

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

مالی و مدیریت ریسک

Agentها می‌توانند جریان تراکنش‌ها را پایش کنند، الگوهای مشکوک را شناسایی کنند، سوابق مشتری را بررسی کنند، risk score تولید کنند و یک پروندهٔ بررسی را به‌صورت خودکار آغاز کنند.

در این سناریوها، Agent کارهای حجیم و تکراری را انجام می‌دهد، در حالی که تصمیم‌های حساس همچنان تحت اختیار انسان باقی می‌مانند.

یکی از اشتباهات رایج این است که سازمان‌ها از ابتدا سراغ یک سیستم پیچیده و کاملاً خودمختار بروند.

رویکرد بهتر، شروع با یک Agent کوچک و محدود است.

این Agent باید:

• یک هدف مشخص داشته باشد؛
• فقط به ابزارهای مورد نیاز دسترسی داشته باشد؛
• در محیط sandbox اجرا شود؛
• و نتواند به سیستم‌های production آسیب بزند.

این مرحله برای آزمایش چرخهٔ Perceive → Reason → Act بسیار مهم است.

همچنین مدیریت credentialها نباید داخل کد یا prompt Agent پراکنده باشد. استفاده از یک سیستم متمرکز برای مدیریت secrets و تعریف دسترسی مستقل برای هر Agent، یکی از اصول پایهٔ استقرار امن است.

بعد از ساخت یک Agent، کار تمام نشده است.

Agentی که در production اجرا می‌شود باید دائماً پایش شود.

AgentOps مجموعه‌ای از فرایندها و ابزارهایی است که برای deploy، monitor، version، ارزیابی و در نهایت بازنشسته کردن Agentها به کار می‌رود.

برخی از شاخص‌های مهم عبارت‌اند از:

• نرخ موفقیت workflow؛
• نرخ خطای tool call؛
• زمان اجرای هر فرایند؛
• هزینهٔ هر workflow؛
• تعداد دفعات ارجاع به انسان؛
• و میزان دستیابی به هدف نهایی.

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

یکی از دام‌های مهم در پروژه‌های Agentic، تمرکز بر معیارهای فنی به‌جای نتایج کسب‌وکار است.

مثلاً در یک Agent خدمات مشتری، تعداد تیکت‌های خودکارشده به‌تنهایی معیار مناسبی نیست.

مهم‌تر این است که بدانیم:

آیا رضایت مشتری افزایش یافته؟
آیا زمان حل مسئله کاهش یافته؟
آیا هزینهٔ پشتیبانی کمتر شده؟
و آیا کیفیت پاسخ حفظ شده است؟

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

وقتی مدل زبانی زیرساخت یک Agent تغییر کند، رفتار خود Agent نیز ممکن است تغییر کند.

ممکن است مدل جدید روی یک benchmark عملکرد بهتری داشته باشد، اما در برخی workflowهای واقعی رفتار متفاوتی نشان دهد.

به همین دلیل، پیش از انتقال مدل جدید به production، بهتر است مجموعه‌ای از وظایف واقعی گذشته دوباره اجرا و رفتار Agent با نسخهٔ قبلی مقایسه شود.

Model versioning و regression testing در سیستم‌های Agentic یک ضرورت‌اند، نه یک قابلیت جانبی.

برای شروع یک پروژهٔ Agentic، بهترین گزینه معمولاً یک workflow است که سه ویژگی داشته باشد:

ارزش کسب‌وکاری بالا، ریسک پایین و نتیجهٔ قابل‌اندازه‌گیری.

کارهایی مانند:

• تولید گزارش؛
• اعتبارسنجی داده؛
• دسته‌بندی درخواست‌ها؛
• routing تیکت‌های داخلی؛
• یا جمع‌آوری و بررسی اطلاعات

برای یک pilot اولیه مناسب‌اند.

پیش از شروع باید معیار موفقیت به‌روشنی تعریف شود:

چه مقدار بهبود انتظار داریم؟
حداکثر خطای قابل قبول چقدر است؟
در چه شرایطی Agent باید کار را متوقف و به انسان ارجاع دهد؟

در مراحل اولیه نیز بهتر است انسان همهٔ تصمیم‌های Agent را زیر نظر داشته باشد. این دورهٔ shadowing کمک می‌کند edge caseها، نقص‌های workflow و مشکلات مربوط به permissionها پیش از افزایش سطح autonomy شناسایی شوند.

حرکت به سمت Agentic AI فقط به معنای ساختن Chatbotهای پیشرفته‌تر نیست.

ما به سمت محیطی حرکت می‌کنیم که در آن سازمان‌ها مجموعه‌ای از Agentهای تخصصی خواهند داشت که با یکدیگر و با سیستم‌های سازمانی همکاری می‌کنند.

استانداردهایی مانند MCP می‌توانند ارتباط میان Agentها و ابزارهای متعلق به پلتفرم‌های مختلف را ساده‌تر کنند.

هم‌زمان، احتمالاً بازارهایی برای Agentهای آماده شکل خواهد گرفت؛ Agentهایی تخصصی برای compliance، خرید، فروش، منابع انسانی، تحلیل مالی، پشتیبانی مشتری و ده‌ها کاربرد دیگر.

در نتیجه، نقش‌های جدیدی نیز شکل خواهند گرفت؛ از Agent Architect و AgentOps Engineer گرفته تا متخصصان AI Governance.

شاید مهم‌ترین نکته دربارهٔ Agentic AI این باشد که تغییر اصلی در «مدل» اتفاق نمی‌افتد؛ بلکه در سیستم اتفاق می‌افتد.

یک LLM می‌تواند بسیار قدرتمند باشد، اما برای تبدیل شدن به یک نیروی عملیاتی در سازمان، به مجموعه‌ای از قابلیت‌های دیگر نیاز دارد:

داده + حافظه + ابزار + استدلال + orchestration + اجرا + امنیت + governance + نظارت انسانی

در مدل سنتی، انسان از AI سؤال می‌پرسد و پاسخ دریافت می‌کند.

در مدل Agentic، انسان هدف را تعیین می‌کند و سیستم تلاش می‌کند تا خودش مسیر رسیدن به آن هدف را طی کند.

و همین‌جا یک مرز مهم شکل می‌گیرد:

این همان نقطه‌ای است که AI از یک ابزار تعاملی به یک همکار عملیاتی تبدیل می‌شود.