استخدام یک مدیرعامل برای خاموش کردن یک کلید برق، توصیفی دقیق از ساخت یک عامل (Agent) برای انجام کارهای پیش‌بینی‌پذیر است. شما به نتیجه می‌رسید، اما بهای گزافی از پیچیدگی در تصمیم‌گیری و ریسک‌های عملیاتی می‌پردازید.
به نقل از تحلیل فنی منتشر شده در dev.to در ۲۶ سپتامبر ۲۰۲۶، صنعت در تله‌ای افتاده است که هر تابع قدرت‌گرفته از هوش مصنوعی را یک «عامل» می‌نامد. ما اکنون تقریباً هر چیزی را عامل می‌نامیم. سیستمی که یک ایمیل را می‌خواند و چند فیلد را از آن استخراج می‌کند، تبدیل به یک عامل شده است. سیستمی که مکالمات مشتری را خلاصه می‌کند، عامل نامیده می‌شود. حتی سیستمی که صرفاً یک API را فراخوانی کرده و نتیجه را برمی‌گرداند، اکنون برچسب عامل می‌خورد. گاهی این برچسب مفید است و گاهی صرفاً نام جدیدی برای مشکلی است که نرم‌افزار سنتی پیش از این بلد بود حل کند.
این روند در حالی شکل می‌گیرد که سازمان‌ها برای ادغام مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در منطق اصلی کسب‌وکار عجله دارند. بسیاری از تیم‌ها تصور می‌کنند چون یک مدل «می‌تواند» به‌طور مستقل تصمیم بگیرد کدام ابزار را فراخوانی کند، پس «باید» این کار را بکند. این طرز فکر، تفاوت بنیادی بین هوش و استقلال (Autonomy) را نادیده می‌گیرد و این دو را یکی می‌پندارد. سؤال جالب این نیست که آیا یک مدل می‌تواند کاری را به‌طور مستقل انجام دهد، بلکه این است که آیا آن کار اصلاً در وهله اول به استقلال نیاز دارد یا خیر.
تصور کنید یک درخواست سازمانی ساده می‌رسد: «وضعیت فاکتور این مشتری چیست؟». در یک سیستم سنتی، مسیر یک خط مستقیم است: مشتری $\rightarrow$ CRM $\rightarrow$ سرویس فاکتور $\rightarrow$ پاسخ. این مسیر قطعی (Deterministic)، سریع و پیش‌بینی‌پذیر است. سیستم دقیقاً می‌داند چه اطلاعاتی نیاز دارد، از کجا باید آن‌ها را بگیرد و چگونه نتیجه را بازگرداند.
اما کاربران به‌ندرت سؤالات را دقیقاً به فرمتی که سیستم انتظار دارد می‌پرسند. آن‌ها ممکن است بپرسند: «آیا شرکت Acme آخرین فاکتور را پرداخت کرده؟» یا «چرا فاکتور ماه مارس هنوز باز نشان داده می‌شود؟». اینجاست که یک مؤلفه هوش مصنوعی برای درک قصد کاربر (Intent) و تبدیل زبان طبیعی به یک درخواست ساختاریافته مفید است. اما خودِ گردش‌کار همچنان می‌تواند قطعی باقی بماند. یعنی: هوش مصنوعی بله، عامل نه.
در مقابل، یک نسخه عامل‌محور (Agentic) سؤال را می‌گیرد، تصمیم می‌گیرد کدام ابزار را فراخوانی کند، نتیجه را تفسیر می‌کند و احتمالاً تصمیم می‌گیرد که آیا ابزار دیگری لازم است یا خیر. در این حالت، برنامه باید با مجموعه بسیار بزرگ‌تری از مسیرهای اجرای احتمالی دست‌وپنجه نرم کند. این حقیقت که یک عامل «می‌تواند» این گردش‌کار را انجام دهد، به این معنا نیست که «باید» این کار را بکند. سؤال معماری مهم این است: آیا مسئله آن‌قدر عدم‌قطعیت دارد که تصمیم‌گیری پویا را توجیه کند؟
مالیات استقلال
یک عامل صرفاً یک تابع هوشمندتر نیست، بلکه یک مدل اجرای متفاوت است. یک تابع سنتی قراردادی نسبتاً شفاف دارد: ورودی $\rightarrow$ منطق $\rightarrow$ خروجی. اما یک عامل یک چرخه ایجاد می‌کند: ورودی $\rightarrow$ استدلال $\rightarrow$ انتخاب $\rightarrow$ اقدام $\rightarrow$ مشاهده $\rightarrow$ استدلال مجدد.
این تفاوت پیامدهایی جدی دارد. عامل ممکن است نیاز به انتخاب ابزارها، حفظ وضعیت (State)، تلاش مجدد برای عملیات‌های شکست‌خورده، بازیابی از اختلالات، درخواست تأیید انسانی یا تعیین گام بعدی بر اساس اطلاعاتی داشته باشد که در ابتدا در اختیار نداشت. هر یک از این قابلیت‌ها یک مزیت بالقوه است، اما هر کدام یک مسئولیت معماری جدید نیز می‌سازند. به همین دلیل، بهترین تعریف برای عامل این است: «قابلیت + پیچیدگی».
این پیچیدگی چیزی را ایجاد می‌کند که نویسنده آن را «مالیات استقلال» می‌نامد. آزادی در تصمیم‌گیری برای گام بعدی، هزینه‌ای دارد. این رابطه از یک زنجیره خاص پیروی می‌کند: استقلال بیشتر $\rightarrow$ مسیرهای بیشتر $\rightarrow$ وضعیت‌های بیشتر $\rightarrow$ شکست‌های بیشتر $\rightarrow$ تست‌های بیشتر $\rightarrow$ نظارت بیشتر $\rightarrow$ حاکمیت بیشتر. این چالش‌های مدیریتی باعث شده تا برخی سازمان‌ها به جای استقلال کامل، به دنبال مدل‌های خودمختاری محدود باشند تا ریسک‌های عامل‌های تمام‌خودکار را کاهش دهند.
هر بار که به سیستم آزادی داده شود تا گام بعدی را تعیین کند، معماری گسترش می‌یابد و این گسترش، آبشاری از نیازهای جدید ایجاد می‌کند:
- مسیرهای اجرای بیشتر: به‌جای یک مسیر واحد، ده‌ها توالی احتمالی دارید. یک گردش‌کار قطعی با تفسیر AI به این شکل است: درخواست $\rightarrow$ تفسیر (AI) $\rightarrow$ اعتبارسنجی $\rightarrow$ فراخوانی API $\rightarrow$ بازگرداندن نتیجه. اما نسخه عامل‌محور به این شکل است: درخواست $\rightarrow$ مدل $\rightarrow$ انتخاب ابزار $\rightarrow$ فراخوانی ابزار $\rightarrow$ تفسیر نتیجه $\rightarrow$ تصمیم مجدد $\rightarrow$ فراخوانی ابزار دیگر $\rightarrow$ پاسخ نهایی.
- مدیریت وضعیت پیچیده‌تر: سیستم باید به خاطر بسپارد چه چیزهایی را امتحان کرده و چرا شکست خورده است تا از افتادن در حلقه‌های بی‌نهایت (Infinite Loops) جلوگیری کند.
- حالت‌های شکست جدید: مدل ممکن است برای یک کار ساده، ابزار اشتباهی را انتخاب کند یا نتواند از یک اختلال در مسیر بازیابی شود.
- تأخیر و هزینه بالاتر: هر گام «استدلال» نیازمند یک فراخوانی اضافی از LLM است که زمان پاسخ‌دهی را افزایش داده و هزینه محاسباتی را بالا می‌برد.
- بار حاکمیتی: شما به نظارت (Observability) و تست‌های بسیار بیشتری نیاز دارید تا مطمئن شوید عامل یک قانون کسب‌وکار را دچار توهم (Hallucination) — مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — نمی‌کند یا دسترسی‌های امنیتی را دور نمی‌زند.
طبقه‌بندی نوع کار
برای اجتناب از این مالیات، مهندسان باید وظایف را بر اساس سطح عدم‌قطعیت طبقه‌بندی کنند. این تحلیل سه دسته متمایز از کارها را بر اساس قوانین، پیش‌بینی‌پذیری و ابهام ورودی پیشنهاد می‌کند:
- کارهای قطعی (Deterministic): قوانین صریح، شفاف و پایدار هستند. مسیر پیش‌بینی‌پذیر است و ابهام ورودی کم است. برای مثال: «وقتی قرارداد امضا شد، فرصت را از مرحله پیشنهاد به بسته شد تغییر بده». اگر قانون کسب‌وکار صریح است، آن را در نرم‌افزار پیاده کنید؛ از یک عامل نخواهید که تصمیم بگیرد آیا این انتقال باید رخ دهد یا خیر.
- کارهای مبهم (Ambiguous): ورودی ساختارنیافته است (مانند زبان طبیعی یا یک ایمیل مشتری) و نیاز به تفسیر دارد، اما مسیر رسیدن به راه حل عمدتاً پیش‌بینی‌پذیر است. برای مثال: «مشکلات اخیر این مشتری را خلاصه کن و دغدغه اصلی را شناسایی کن». در اینجا، یک مؤلفه AI باید ورودی را به یک فرمت ساختاریافته تبدیل کند که سپس یک گردش‌کار قطعی و اعتبارسنجی شده توسط برنامه را فعال می‌کند.
- کارهای پویا (Dynamic): گام بعدی کاملاً به چیزی بستگی دارد که سیستم در طول فرآیند کشف می‌کند. قوانین به تنهایی برای تعیین مسیر کافی نیستند. برای مثال: «بررسی کن چرا این مشتری سفارش نمی‌دهد، اطلاعات را از CRM و سیستم‌های پشتیبانی جمع کن، فعالیت‌های اخیر را مقایسه کن و توصیه کن تیم فروش چه اقدامی انجام دهد». سیستم ممکن است تا پیش از شروع بررسی، نداند چه اطلاعاتی مفید خواهد بود. یک نتیجه ممکن است تعیین‌کننده فراخوانی ابزار بعدی باشد و نتیجه بعدی ممکن است دوباره برنامه را تغییر دهد.
راهکار معماری ترکیبی
مستحکم‌ترین سیستم‌های عملیاتی اجازه نمی‌دهند عامل مالک کل گردش‌کار باشد. در عوض، از یک مدل ترکیبی استفاده می‌کنند که در آن برنامه کنترل مرزها را در دست دارد. در این ساختار، عامل تفسیر و استدلال پویا را بر عهده دارد، اما برنامه مدیریت اجرا را انجام می‌دهد. برای مدیریت این تعادل، برخی متخصصان پیشنهاد می‌کنند یک چارچوب مهندسی یا «قانون اساسی» برای مدیریت مقیاس‌پذیر عامل‌ها تعریف شود تا از هرج‌ومرج در تصمیم‌گیری‌ها جلوگیری شود.
در یک معماری ترکیبی، جریان به این شکل است: کاربر $\rightarrow$ برنامه $\rightarrow$ گردش‌کار قطعی $\rightarrow$ عامل AI $\rightarrow$ اعتبارسنجی $\rightarrow$ قوانین کسب‌وکار $\rightarrow$ اجرا. عامل در گردش‌کار مشارکت می‌کند، اما مالک آن نیست.
مرزهای حیاتی که باید حتماً قطعی باقی بمانند عبارتند از:
- هویت و دسترسی‌ها: عامل نباید تصمیم بگیرد چه کسی به چه چیزی دسترسی دارد.
- قوانین کسب‌وکار: برنامه (و نه مدل) باید اعتبارسنجی کند که آیا یک انتقال یا تغییر مجاز است یا خیر. یک «توصیه» به معنای «مجوز» نیست.
- مرزهای تراکنش: اجرای نهایی و سوابق حسابرسی (Audit Records) باید توسط سیستم اصلی مدیریت شوند.
- وضعیت گردش‌کار: برنامه باید منبع حقیقت (Source of Truth) برای جایگاه فعلی فرآیند باشد.
تیمی را تصور کنید که گردش‌کار درخواست مشتری را می‌سازد. فرآیند پیش‌بینی‌پذیر است: درک درخواست، بازیابی رکورد مشتری، بررسی یک شرط کسب‌وکار و ایجاد یک تسک داخلی. در ابتدا آن‌ها یک عامل کامل برای مدیریت زبان طبیعی می‌سازند. در مرحله تست، متوجه می‌شوند که یک درخواست مشابه، توالی‌های ابزاری متفاوتی تولید می‌کند و عیب‌یابی را به یک کابوس تبدیل می‌کند. ردیابی شکست‌ها دشوار است زیرا مدل در هر گام مسیر را تصمیم می‌گیرد.
با تغییر طراحی به مدلی که در آن یک مؤلفه AI صرفاً درخواست را تفسیر کرده و نتیجه‌ای ساختاریافته برمی‌گرداند، تیم می‌تواند جست‌وجوی CRM و اعمال قوانین را از طریق یک گردش‌کار قطعی انجام دهد. آن‌ها استقلال بی‌مورد را حذف کردند اما هوش AI را حفظ نمودند.
موازنه استراتژیک
البته موارد مشروعی برای استفاده از عامل‌ها وجود دارد: کاربران واقعی پیش‌بینی‌ناپذیر هستند. سؤالات آن‌ها می‌تواند باز باشد، نیازهایشان در طول تعامل تغییر کند و اطلاعات مورد نیاز برای حل یک مشکل ممکن است از پیش شناخته شده نباشد. ساخت یک گردش‌کار مجزا برای هر تغییر احتمالی در پرسش‌های انسانی، شکننده و گران است.
یک عامل با دسترسی به مجموعه‌ای تعریف‌شده از ابزارها می‌تواند طیف وسیع‌تری از موقعیت‌ها را مدیریت کند بدون اینکه مهندسان مجبور باشند هر مسیر ممکن را به‌طور صریح کدنویسی کنند. اگر مسئله واقعاً پویا است، عامل انتزاع درستی است.
با این حال، هدف مهندسی «حداکثر استقلال» نیست، بلکه «استقلال مناسب» است. پیش از معرفی یک عامل، مهندسان باید بپرسند: آیا مسیر پیش‌بینی‌پذیر است؟ آیا قوانین صریح هستند؟ آیا ورودی واقعاً مبهم است؟ آیا گام بعدی به یافته‌های سیستم بستگی دارد؟ و مهم‌تر از همه: هزینه اشتباه چقدر است و آیا استقلال، ارزش کافی برای توجیه این پیچیدگی اضافی را ایجاد می‌کند؟
بهره‌برداری از سیستم
برای تبدیل یک دموی AI به سیستمی که قابل بهره‌برداری باشد، معماری باید اجازه بازسازی کامل رویدادها را بدهد. یک سیستم عملیاتی باید این امکان را فراهم کند که دقیقاً ببینیم مدل چه چیزی را تفسیر کرده، کدام ابزارها فراخوانی شده‌اند، چه تصمیماتی گرفته شده، کدام اعتبارسنجی‌ها پاس شده‌اند و در نهایت گردش‌کار به کجا رسیده است.
این امر مستلزم تعریف مرزهای عامل پیش از ساخت است: چه اطلاعاتی را می‌بیند؟ کدام ابزارها را فراخوانی می‌کند؟ کدام اقدامات نیاز به تأیید انسانی دارند؟ این موضوع هنگام تعامل عامل‌ها با سیستم‌های CRM، ERP، مالی یا سیستم‌های مدیریت هویت حیاتی است. مدل فضای استدلال می‌گیرد، اما برنامه کنترل پیامدها را حفظ می‌کند.
موفق‌ترین معماری‌های AI آن‌هایی هستند که دقیقاً به اندازه نیاز مسئله استقلال به کار می‌گیرند — نه بیشتر و نه کمتر. بخش دشوار، تصمیم‌گیری درباره قدرت عامل‌ها نیست، بلکه تصمیم‌گیری درباره این است که این قدرت کجا باید قرار بگیرد.
گام بعدی شما
- تمام گردش‌کارهای فعلی خود را بررسی کنید و هر جا که «مسیر اجرا» ثابت است، عامل را با یک تابع قطعی جایگزین کنید.
- برای عامل‌های موجود، یک لایه اعتبارسنجی (Validation) در سطح برنامه اضافه کنید تا قوانین کسب‌وکار را مستقل از مدل چک کند.
- سیستم لاگینگ خود را به‌گونه‌ای تغییر دهید که هر تصمیم عامل (Reasoning Step) به‌صورت مجزا ذخیره شود تا عیب‌یابی ممکن شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو