اشتباهات رایج در Agent Orchestration — چرا RAG و Function Calling کافی نیستند

اکثر تیم‌هایی که با Agent Orchestration کار می‌کنند، یک اشتباه اساسی مرتکب می‌شوند: فکر می‌کنند مشکل، انتخاب ابزار است. یک RAG pipeline درست می‌کنند، چند Function Calling تعریف می‌کنند، یک LLM مناسب انتخاب می‌کنند — و انتظار دارند سیستم «کار کند». در محیط آزمایشگاهی کار می‌کند. در production، نمی‌کند.

مشکل اصلی کجاست؟

RAG و Function Calling هر دو ابزارهای خوبی هستند — اما ابزار هستند، نه معماری. اشتباه رایج این است که این دو را به‌عنوان جایگزین طراحی سیستمی در نظر می‌گیرند. یک Agent که فقط بر اساس retrieval و tool-use طراحی شده، بدون یک لایهٔ orchestration مشخص، اساساً یک LLM با دسترسی به داده است — نه یک سیستم عملیاتی.

مشکل اصلی این است: در سیستم‌های عملیاتی (Operational Systems)، تصمیم‌ها باید deterministic و قابل audit باشند. یک LLM به‌تنهایی این ضمانت را نمی‌دهد. وقتی Agent شما تصمیم می‌گیرد کدام tool را فراخوانی کند، کدام context را نادیده بگیرد، و چه زمانی escalate کند — این تصمیم‌ها باید از یک ساختار کنترل‌شده بیایند، نه از یک پاسخ probabilistic.

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

اشتباه اول: Context را یک مشکل retrieval می‌بینند. تیم‌ها ساعت‌ها وقت صرف بهینه‌سازی chunking، embedding، و similarity search می‌کنند — اما مشکل اصلی این نیست که کدام document بازیابی می‌شود. مشکل این است که Agent چه چیزی را در چه لحظه‌ای باید بداند. Context management یک مسئلهٔ معماری است، نه یک مسئلهٔ جستجو.

اشتباه دوم: Function Calling را به‌عنوان جایگزین Business Logic استفاده می‌کنند. وقتی یک LLM تصمیم می‌گیرد کدام function را call کند، این تصمیم از prompt می‌آید — نه از یک state machine یا workflow engine. در سیستم‌های مالی، حقوقی، یا عملیاتی، این رویکرد یک failure mode جدی است. Business logic باید خارج از LLM زندگی کند و LLM فقط باید آن را اجرا کند.

اشتباه سوم: هیچ لایهٔ Orchestration مستقلی وجود ندارد. در معماری‌های رایج مثل LangChain یا AutoGen، اغلب یک «agent loop» داریم که در آن LLM هم تصمیم می‌گیرد، هم اجرا می‌کند، هم evaluate می‌کند. این یعنی هیچ نقطهٔ کنترل مستقلی وجود ندارد. در production، این یعنی debugging کابوس است و هر failure یک black box.

چطور یک معمار به این مسئله نگاه می‌کند؟

یک سیستم Agent Orchestration سالم، سه لایهٔ جدا دارد: Planning Layer که تصمیم می‌گیرد چه کاری باید انجام شود، Execution Layer که tools را فراخوانی می‌کند، و Evaluation Layer که نتیجه را بررسی می‌کند. وقتی این سه لایه با هم merge می‌شوند — که در اکثر پیاده‌سازی‌های «سریع» اتفاق می‌افتد — سیستم شما یک monolith هوشمند است، نه یک سیستم هوشمند.

مثال واقعی: یک سیستم اتوماسیون پشتیبانی مشتری که برای یک fintech طراحی کرده بودم. تیم اولیه یک RAG pipeline روی knowledge base شرکت ساخته بود و چند function برای بررسی وضعیت حساب تعریف کرده بود. در تست، عالی کار می‌کرد. در production، وقتی کاربر یک سؤال ambiguous می‌پرسید، Agent شروع به hallucination می‌کرد — نه به دلیل کمبود داده، بلکه به دلیل نبود یک لایهٔ decision مستقل که مشخص کند این سؤال باید به انسان ارجاع شود. راه‌حل، اضافه کردن یک state machine صریح برای مدیریت escalation بود — نه بهتر کردن RAG.

محدودیت‌هایی که باید صادقانه بپذیریم

Agent Orchestration در سیستم‌های عملیاتی هنوز یک حوزهٔ در حال تکامل است. هیچ framework کاملی وجود ندارد. LangGraph از LangChain بهتر است، اما هنوز abstraction‌هایی دارد که در production مشکل‌ساز می‌شوند. AutoGen برای multi-agent conversation خوب است، اما control flow آن برای سیستم‌های strict نیاز به override دارد.

تریدآف اصلی این است: هرچه ساختار بیشتری به orchestration بدهید، flexibility کمتری دارید. یک state machine صریح، agent شما را predictable می‌کند — اما توانایی handle کردن edge case‌های غیرمنتظره را محدود می‌کند. این تریدآف را نمی‌توان حذف کرد، فقط می‌توان آگاهانه مدیریت کرد.

قانون طلایی: هرچه سیستم شما به دامنهٔ عملیاتی حساس‌تر — مالی، پزشکی، حقوقی — نزدیک‌تر است، باید از determinism بیشتر و از probabilism کمتر استفاده کنید. LLM در این سیستم‌ها باید مثل یک کارمند باهوش با دستورالعمل‌های مشخص رفتار کند، نه مثل یک مشاور مستقل با اختیار تام.

اگر سیستم شما در production failure دارد و هنوز دارید روی prompt engineering کار می‌کنید — احتمالاً مشکل جای دیگری است.