گران‌ترین اشتباه در پروژه‌های ایجنت هوش مصنوعی، ساختن ایجنت بد نیست؛ ساختن ایجنت در جایی است که یک workflow خطی با حدود یک‌دهم هزینه و سطح شکست بسیار پایین‌تر، همان کار را انجام میدهد. این مقاله معماری، الگوی ReAct، هزینهی توکنی هر step و معیارهای عملی آن مرز را بررسی میکند — یعنی کی ایجنت بسازید و کی نسازید.
ایجنت هوش مصنوعی چیست و چه فرقی با chatbot و workflow دارد؟#
ایجنت هوش مصنوعی (AI Agent) سیستمی است که خودش تعداد مراحل، ترتیب اجرا و ابزارهای موردنیاز را در لحظه تصمیم می‌گیرد. chatbot یک ورودی می‌گیرد و یک خروجی میدهد؛ agentic workflow ساختار ثابت دارد و LLM فقط در گره‌های از پیش‌تعریف‌شده تصمیم می‌گیرد. ایجنت هیچ‌کدام از این دو نیست — مسیر اجرا را خودش در runtime می‌سازد.
تمایز سه‌گانه را این‌طور در نظر بگیرید: chatbot یک ورودی می‌گیرد و یک خروجی میدهد. agentic workflow یک ساختار از پیش‌تعریف‌شده دارد (مثلاً 3 stage) و LLM در هر stage تصمیم می‌گیرد. agent اما خودش میگوید چند stage لازم است، به چه ابزاری نیاز دارد و در چه ترتیبی.
مثال عملی: یک ایجنت پشتیبانی مشتری که خودش تصمیم می‌گیرد اول database را query کند، بعد email بفرستد و بعد ticket ببندد. ترتیب و تعداد مراحل از قبل مشخص نیست — این جایی است که agent واقعاً تفاوت ایجاد میکند.
چرا اصطلاح «agentic» بدون تعریف فنی بی‌فایده است#
هر کسی که یک prompt با چند tool call بنویسد، خودش را «agentic» صدا می‌زند. اگر مسیر اجرا از پیش ثابت است، شما یک workflow ساختهاید نه یک agent. این ابهام در استخدام، بودجه‌بندی و انتخاب معماری هزینهی واقعی دارد — نه فقط هزینهی فنی.
مقایسه با RAG و function calling#
RAG (Retrieval-Augmented Generation) یک تکنیک بازیابی است، نه یک سیستم. Function calling یک سازوکار است که LLM درخواست صدا زدن ابزار میدهد. ایجنت، function calling را در حلقه‌ی reasoning و planning استفاده میکند. بدون حلقه‌ی تکراری، function calling فقط tool use است نه agent.
برای درک دقیق‌تر تفاوت RAG با ایجنت، راهنمای RAG را مطالعه کنید.
پنج لایه‌ی معماری هر ایجنت AI#
معماری ایجنت از پنج لایه تشکیل شده: perception (ورودی و context)، planning (تعیین مسیر)، memory (حفظ اطلاعات بین مراحل)، tool use (دسترسی به ابزارهای خارجی) و action (اجرای تصمیم). حذف یا ضعیف‌بودن هر لایه، ایجنت را به chatbot با delay برگرداند — نه یک ایجنت نصفه‌نیمه، بلکه یک chatbot گران‌قیمت.
Perception — ایجنت چه چیزی می‌بیند؟#
ورودی‌های perception سه منبع دارد: پیام کاربر، نتیجهی tool call قبلی و وضعیت فعلی task. اگر ایجنت فقط پیام کاربر را می‌بیند و نتیجهی اجرای قبلی را به context اضافه نمی‌کند، عملاً perception لایه ندارد.
Planning — ایجنت چطور مسیر را تعیین میکند؟#
در هر step، ایجنت یک تصمیم می‌گیرد: الان باید tool صدا بزند یا پاسخ نهایی بدهد؟ این تصمیم‌گیری میتواند مرحله‌به‌مرحله باشد (الگوی ReAct) یا کل مسیر در ابتدا برنامه‌ریزی شود (الگوی Plan-and-Execute).
Memory — ایجنت چطور اطلاعات قبلی را نگه می‌دارد؟#
حافظه‌ی ایجنت دو نوع دارد: short-term که همان context window است و long-term که به vector database یا summary structure نیاز دارد. بدون memory، ایجنت در step پنجم نمی‌داند در step دوم چه نتیجه‌ای گرفته است.
Tool Use — ایجنت چطور با جهان بیرون تعامل میکند؟#
Function calling زیرمجموعه‌ی tool use است، نه معادل کامل آن. Tool use شامل انتخاب ابزار، ساخت parameter، ارسال درخواست و تفسیر نتیجه است. اگر ایجنت نتیجه را تفسیر نکند، tool use ناقص است.
Action — ایجنت چطور خروجی تولید میکند؟#
ساختار حلقه‌ی اصلی به این شکل است:
while not stop_condition:
observation = perceive(input, previous_result)
thought = plan(observation, memory)
if thought == "respond": break
result = execute_tool(thought.tool, thought.params)
memory.update(result)
الگوی ReAct: حلقه‌ی reasoning و acting#
الگوی ReAct (Reasoning + Acting) در paper Yao et al. نشان داد که ترکیب reasoning و acting در یک حلقه‌ی تکراری، بهبود معناداری نسبت به baselineهای reasoning-only و acting-only در benchmarkهای HotpotQA و FEVER ایجاد میکند. این الگو در عمل یعنی ایجنت قبل از هر ابزار یک thought تولید میکند، ابزار را صدا می‌زند، observation را می‌بیند و دوباره فکر میکند.
ساختار حلقه: Thought → Action → Observation → Thought → ... ایجنت قبل از هر ابزار، یک thought تولید میکند (چرا این ابزار؟ چه چیزی انتظار دارد؟)، ابزار را صدا می‌زند، observation را می‌بیند و دوباره فکر میکند.
محدودیت‌های ReAct#
هر Thought اضافه، توکن مصرفی را افزایش میدهد. در کارهای deterministic — مثلاً استخراج نام از یک ایمیل — ReAct overhead بی‌مورد است. اگر مسیر مشخص است، reasoning مجدد فقط هزینه و latency اضافه میکند. این اشتباه در پروژه‌های واقعی مکرر دیده میشود: تیمی که برای یک کار سه‌مرحله‌ای ثابت، حلقه‌ی ReAct با 12 step اجرا میکند.
Plan-and-Execute به‌عنوان جایگزین#
در Plan-and-Execute، کل مسیر در ابتدا برنامه‌ریزی میشود و سپس sequential اجرا می‌گردد. مزیت: توکن کمتر و قابل‌پیش‌بینی‌تر. عیب: اگر محیط عوض شود، plan از کار می‌افتد و ایجنت نمی‌تواند adapt کند.
Tree of Thoughts (ToT) — چه زمانی لازم است؟#
ToT کاوش چند مسیر همزمان است. مناسب برای problems با فضای جستجوی بزرگ که یک مسیر خطی کافی نیست. در عمل، ToT برای ایجنتهای ساده‌ی production نادر است و بیشتر در research و benchmarkها دیده میشود. اگر کسی در یک meeting production ToT پیشنهاد داد، احتمالاً مسئله‌ی شما به آن پیچیدگی نیست.
برای بهینه‌سازی reasoning در prompt، راهنمای پرامپت‌نویسی پیشرفته را ببینید.
حافظه‌ی ایجنت: context window کافی است یا vector database لازم است؟#
حافظه‌ی ایجنت دو نوع دارد: short-term که همان context window است و long-term که به vector database یا summary structure نیاز دارد. معیار عملی: اگر تعداد round-trip کم است و حجم داده‌ی reference در context window جا میشود، memory را به context window بسپارید. اگر round-trip زیاد است یا داده‌ی reference بزرگ، به vector database و RAG نیاز دارید.
Short-term memory (context window)#
مزیت: ساده، بدون latency اضافه. محدودیت: با افزایش مراحل، context پر میشود و quality افت میکند. ایجنت در step بیستم، step دوم را فراموش کرده است.
Long-term memory (vector database + RAG)#
الگوی مشاهده‌شده در پروژه‌های اعضای کامیونیتی: ایجنت‌هایی که بیش از 15 مرحله اجرا می‌شوند، بدون external memory quality از دست میدهند. ساختار پیشنهادی: summary هر مرحله در metadata ذخیره شود و retrieval بر اساس similarity انجام گیرد.
الگوی memory overflow و راه‌حل آن#
اشتباه رایج: ذخیره‌ی همه‌ی tool outputs خام بدون خلاصه‌سازی. ایجنت 20 مرحله اجرا میشود، context پر میشود و اطلاعات اولیه حذف میشود. راه‌حل: sliding window + summary compression.
memory/ ├── short_term.py # context window management ├── long_term.py # vector DB retrieval ├── summarizer.py # compress old steps └── config.py # max_context_tokens, summary_strategy
مقایسه‌ی فریمورک‌های ساخت ایجنت#
فریمورک‌های ساخت ایجنت هر کدام مدل معماری متفاوتی دارند: LangChain برای چرخ‌های tool use و orchestration ساده، CrewAI برای تعریف نقش‌محور، AutoGen مایکروسافت برای هماهنگی ایجنت‌ها از طریق مکالمه‌ی ساختاریافته، و OpenAI Assistants API برای ایجنتهای managed با memory داخلی مناسب‌اند. انتخاب فریمورک بدون درک معماری، فقط lock-in ایجاد میکند.
| فریمورک | مدل معماری | مناسب برای | محدودیت اصلی | Vendor lock-in |
|---|---|---|---|---|
| LangChain / LangGraph | DAG برای orchestration | چرخ tool use ساده، prototyping سریع | Abstraction زیاد؛ در پروژه‌های کوچک، مستقیم function calling بنویسید | کم |
| CrewAI | Role-based (persona + goal) | کارهایی با نقش‌های واقعاً جدا (researcher + writer + reviewer) | Overhead برای کارهای تک‌نقشی | کم |
| AutoGen (Microsoft) | Conversation-based | هماهنگی چند ایجنت از طریق پیام‌رسانی ساختاریافته | دیباگ مکالمه‌های چندتوره سخت است | متوسط |
| OpenAI Assistants API | Managed (thread + tool + memory) | ایجنتهای ساده با memory داخلی بدون زیرساخت | کنترل کمتر روی معماری | بالا |
| Anthropic tool use | Function calling + computer use | ایجنتهای با نیاز به تعامل با GUI | اکوسیستم کوچکتر | متوسط |
نکته‌ی عملی: اگر فقط یک ایجنت با چند tool می‌خواهید، مستقیم با function calling API شروع کنید و حلقه را خودتان بنویسید. LangChain و CrewAI وقتی ارزش دارند که orchestration پیچیده‌تر شود.
multi-agent orchestration کی واقعاً لازم میشود؟#
Multi-agent orchestration فقط وقتی لازم است که نقش‌های واقعی و مجزا وجود داشته باشند — مثلاً یک ایجنت داده جمع میکند، دیگری تحلیل میکند، سومی گزارش می‌نویسد. در اکثر پروژه‌ها، یک ایجنت با چند tool کافی است و تفکیک به ایجنتهای متعدد، complexity و هزینهی coordination اضافه میکند بدون اینکه خروجی بهتری بدهد.
الگوی مشاهده‌شده: پروژه‌هایی که از ابتدا multi-agent شروع کردند#
در پروژه‌های واقعی، اکثر تیم‌هایی که از ابتدا multi-agent طراحی کردند، بعداً به یک ایجنت + چند tool ساده برگشتند. هزینهی پنهان coordination: هر پیام بین ایجنت‌ها یک API call است. 3 ایجنت با 5 مرحله = 15 فراخوانی، در حالی که یک ایجنت همان کار را با 5 فراخوانی انجام میدهد.
معیارهای تصمیم‌گیری برای multi-agent#
- آیا نقش‌ها واقعاً متفاوت‌اند یا فقط stageهای یک pipelineاند؟
- آیا هر ایجنت context متفاوتی نیاز دارد؟
- آیا خطای یک ایجنت نباید روی دیگری اثر بگذارد؟
- آیا هر ایجنت به model متفاوتی نیاز دارد؟
الگوی orchestration: supervisor + workers#
ساختار رایج: یک supervisor task را بین workers تقسیم میکند و نتایج را جمع میکند.
supervisor → [worker_1, worker_2, worker_3]
worker_1: research → result_1
worker_2: analyze(result_1) → result_2
worker_3: write(result_2) → final_output
supervisor: validate(final_output) → deliver
گام‌به‌گام ساخت اولین ایجنت#
ساخت اولین ایجنت از تعریف دقیق task و stop condition شروع میشود، نه از انتخاب فریمورک. هفت گام عملی وجود دارد که ترتیب آن‌ها اهمیت دارد — و ترتیب غلط، همان اشتباهی است که تیم‌ها را سه هفته به عقب می‌اندازد.
- task را بنویسید: ورودی چیست، خروجی چیست، چه زمانی تمام شده محسوب میشود
- tools را تعریف کنید: هر tool یک function signature با docstring دقیق
- stop condition را از بیرون مشخص کنید: max_iterations + success_criteria
- system prompt را بنویسید: نقش، محدودیت‌ها، فرمت خروجی
- حلقه‌ی اصلی را پیاده‌سازی کنید: observe → think → act → check stop
- memory اضافه کنید: اگر بیش از 10 مرحله لازم است
- ارزیابی کنید: روی 10 تا 20 مثال test کنید و failure modes را ثبت کنید
ساختار پوشه‌ی پروژه#
agent_project/
├── agent.py # حلقه‌ی اصلی
├── tools/
│ ├── search.py
│ ├── database.py
│ └── email.py
├── memory/
│ ├── context_manager.py
│ └── summarizer.py
├── prompts/
│ └── system.py
├── config.py # max_iterations, model, temperature
└── tests/
└── test_agent.py
اشتباه رایج در گام اول#
انتخاب فریمورک قبل از تعریف task. نتیجه: abstractionهایی که لازم ندارید، debugging سخت‌تر و هزینهی یادگیری اضافه. اول task را بنویسید، بعد ابزار را انتخاب کنید.
هزینهی پنهان هر step ایجنت#
هزینهی پنهان هر step ایجنت در demoها دیده نمی‌شود. هر step یک فراخوانی API محسوب میشود. ایجنتی با 10 مرحله و 3 tool call در هر مرحله، 30 فراخوانی inference دارد. این یعنی هزینهی توکنی و latency ده‌برابر یک پاسخ ساده — و این عدد در production به‌سرعت به فاکتور ماهانه تبدیل میشود.
مدل هزینه: step × tool_calls × tokens_per_call#
هر tool call یک round-trip به LLM است (نه فقط یک HTTP request به ابزار). توکن‌های context هر step با اضافه‌شدن observationها رشد میکند. به‌عنوان مثال، step اول 500 توکن است، step دهم 3000 توکن.
latency: چرا ایجنت کند است؟#
هر step شامل network latency + model inference time است. ایجنت 10 مرحله‌ای با 3 ثانیه per step حداقل 30 ثانیه طول می‌کشد. کاربر منتظر است و timeout میشود.
بهینه‌سازی هزینه#
- کاهش max_iterations
- استفاده از model کوچکتر برای steps ساده (routing) و model بزرگ فقط برای reasoning
- cache کردن tool results تکراری
- حذف thoughtهای زائد با prompt engineering
هزینهی managed API در مقابل self-hosted#
OpenAI Assistants API pricing بر اساس توکن مصرفی دارد (نیازمند راستی‌آزمایی برای قیمت دقیق لحظه‌ای). Self-hosted با model باز، هزینهی inference را از API call به GPU تبدیل میکند — برای حجم بالا مقرون‌به‌صرفه‌تر است ولی latency و overhead عملیاتی اضافه دارد.
برای جزئیات بیشتر، راهنمای بهینه‌سازی هزینهی API را ببینید.
اشتباهات رایج: infinite loop، tool hallucination و memory overflow#
رایج‌ترین الگوی شکست در ایجنت‌ها، infinite loop است: ایجنت ابزاری را صدا می‌زند، نتیجه را تفسیر نمی‌کند و دوباره همان ابزار را صدا می‌زند. راه‌حل: max iterations + reflection step + stop condition صریح از بیرون. سه اشتباه دیگر — tool hallucination، memory overflow و self-determined stopping — هم هر کدام الگوی مشخصی دارند.
Infinite loop of tool calls#
الگو: ایجنت بدون reasoning نتیجه را تفسیر نمی‌کند و ابزار را تکرار میکند. راه‌حل عملی: max_iterations + reflection step (بعد از هر N مرحله، ایجنت از خودش بپرسد: آیا پیشرفتی داشته؟). راه‌حل دوم: stop condition صریح از بیرون + fallback message.
Tool hallucination#
ایجنت ابزاری را صدا می‌زند که وجود ندارد یا parameter اشتباه میدهد. راه‌حل: strict schema validation + retry با error message به ایجنت. ایجنت باید بداند tool وجود ندارد و tool درست را انتخاب کند.
Memory overflow#
Context window پر میشود و ایجنت اطلاعات اولیه را فراموش میکند. راه‌حل: summary compression + sliding window. ایجنت باید خلاصه‌ی مراحل قبلی را داشته باشد نه همه‌ی raw outputها.
Self-determined stopping#
ایجنت‌هایی که خودشان تصمیم می‌گیرند کی متوقف شوند: یا زودتر متوقف می‌شوند یا وارد حلقه می‌شوند. Stop condition باید از بیرون تزریق شود — نه از داخل prompt. این یک اصل معماری است، نه یک توصیه.
ارزیابی و دیباگ#
معیارهای کلیدی: task completion rate، average steps، failure mode distribution. ابزارهای tracing: LangSmith، Weights & Biases. بدون tracing، debugging ایجنت مثل debugging distributed system است — کورکورانه.
چه زمانی ایجنت نسازیم و workflow خطی کافی است؟#
ایجنت برای کارهای deterministic و تک‌مرحله‌ای overhead بی‌مورد است. تبدیل CSV به JSON، استخراج فیلد از یک فرم، یا ارسال ایمیل template — این‌ها با یک script یا workflow خطی با حدود یک‌دهم هزینه و سطح شکست بسیار پایین‌تر حل می‌شوند. ساخت ایجنت برای این کارها نه فقط هزینهی توکنی اضافه دارد، بلکه debugging را از یک خط ساده به یک حلقه‌ی غیرقابل‌پیش‌بینی تبدیل میکند.
معیارهای «ایجنت لازم نیست»#
- مسیر از پیش مشخص است (تعداد مراحل ثابت)
- ورودی و خروجی deterministic هستند
- خطا پذیرفتنی نیست (مثلاً ویرایش دیتابیس production)
- یک script ساده کار را حل میکند
معیارهای «ایجنت لازم است»#
- تعداد و ترتیب مراحل از پیش معلوم نیست
- محیط متغیر است و ایجنت باید adapt کند
- کار چندمرحله‌ای با تصمیم‌گیری بین مراحل
- ورودی‌ها heterogeneous هستند (متن، فایل، URL)
تمایز research agent و execution agent#
ایجنتهای research (جمع‌آوری اطلاعات): tolerance بالا برای خطا، نیاز به guardrail کمتر. ایجنتهای execution (ارسال ایمیل، ویرایش فایل): guardrail سخت‌گیرانه، confirmation step، rollback plan. این تمایز در اکثر محتواها نادر است و در پروژه‌های واقعی هزینهی آن سنگین است — یک ایجنت execution بدون confirmation میتواند email اشتباه بفرستد.
الگوی میانه: agentic workflow#
LLM در حلقه‌ی تصمیم است ولی ساختار ثابت — مناسب برای اکثر پروژه‌ها. مثال: pipeline با 3 stage که در هر stage LLM تصمیم می‌گیرد ولی تعداد stages ثابت است. این الگو، تعادل بین سادگی workflow و انعطاف agent است.
نتیجهی عملی: قبل از نوشتن هر خط کد، بپرسید «آیا تعداد و ترتیب مراحل از پیش معلوم است؟» اگر بله، workflow خطی بنویسید. اگر نه، ایجنت بسازید ولی stop condition را از بیرون تزریق کنید. اگر می‌خواهید با n8n ایجنت و اتوماسیون بسازید، دوره‌ی «ساخت AI Agent با N8N» در کامیونیتی اسکول این مسیر گام‌به‌گام را پوشش میدهد.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.