ایجنت هوش مصنوعی (AI Agent) ابزاری نیست که برای هر مسئله‌ای لازم باشد. اگر مسیر اجرا از پیش مشخص است، یک workflow با چند شرط ساده همان کار را می‌کند — بدون loop، بدون توکن‌سوزی و بدون پیچیدگی debug. اما وقتی تصمیم بعدی به خروجی مرحله‌ی قبلی بستگی دارد، ایجنت می‌سازید. با 50 خط Python و raw API call، نه LangChain.

تفاوت ایجنت با chatbot و workflow: چه زمانی به loop نیاز دارید؟#

ایجنت هوش مصنوعی سیستمی است که مدل زبانی بزرگ (LLM) را با ابزار، حافظه و چرخه‌ی تصمیم‌گیری ترکیب می‌کند تا بدون دستور مستقیم کاربر چند مرحله را پشت‌سرهم اجرا کند. برخلاف chatbot که فقط پاسخ می‌دهد و برخلاف workflow که مسیرش ثابت است، ایجنت خودش تصمیم می‌گیرد مرحله‌ی بعدی چیست.

این تعریف در عمل یعنی یک loop. همین.

تعریف آکادمیک و تعریف عملیاتی#

تعریف کلاسیک از Wooldridge و Jennings در 1995 منتشر شد: ایجنت سیستمی خودمختار است که محیط را ادراک می‌کند، تصمیم می‌گیرد و عمل می‌کند. تعریف عملیاتی 2024 ساده‌تر است: یک loop که در هر تکرار مدل را صدا می‌زند، اگر tool call برگرداند آن را execute می‌کند، نتیجه را به context اضافه می‌کند و تا رسیدن به final answer ادامه می‌دهد.

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

تفاوت با chatbot#

Chatbot یک single-turn response تولید می‌کند. ایجنت چرخه‌ی perceive → think → act را چند بار تکرار می‌کند. تفاوت بنیادین در تعداد مراحل و در این است که ایجنت خروجی یک مرحله را ورودی مرحله‌ی بعدی قرار می‌دهد.

تفاوت با workflow#

Workflow مسیر ثابت دارد: اگر شرط A برقرار است به B برو، وگرنه به C. ایجنت مسیر را از پیش نمی‌داند؛ خودش بر اساس نتیجه‌ی هر مرحله تصمیم می‌گیرد که ابزار بعدی کدام باشد. این dynamic decision-making دقیقاً همان چیزی است که workflow ساده قادر به انجامش نیست — و همین، تنها دلیل موجه برای ساختن ایجنت است.

اجزای سازنده#

  • LLM هسته: مدل زبانی که reasoning و تصمیم‌گیری انجام می‌دهد
  • Tools: توابعی که ایجنت می‌تواند صدا بزند (search، API call، code execution)
  • Memory: context بین مراحل — کوتاه‌مدت یا بلندمدت
  • Planner: تعیین مسیر بعدی — که لزوماً یک ماژول جداگانه نیست، گاهی فقط یک جمله در system prompt است

الگوهای معماری: ReAct، Plan-and-Execute و Router کدام مناسب پروژه‌ی شماست؟#

الگوی ReAct برای ایجنت‌های کاوشی و تحلیلی مناسب است. Plan-and-Execute برای کارهایی که برنامه‌ریزی upfront لازم دارند. Router Pattern برای ایجنت‌های service که باید بر اساس نوع query مسیر را انتخاب کنند و latency پایین بخواهند. انتخاب اشتباه، توکن‌مصرفی و latency را بی‌دلیل بالا می‌برد.

بیشتر تیم‌هایی که الگوی ReAct را برای یک service ساده‌ی پاسخ‌دهی انتخاب می‌کنند، بعد از سه ماه به Router مهاجرت می‌کنند. این الگو در پروژه‌های اعضای کامیونیتی بارها تکرار شده.

الگوی ReAct#

ReAct (Reasoning and Acting) توسط Shunyu Yao و همکاران در 2022 منتشر شد. چرخه‌ی Thought → Action → Observation را تکرار می‌کند. مدل اول فکر می‌کند، بعد یک tool صدا می‌زند، نتیجه را می‌بیند و دوباره فکر می‌کند. برای research، تحلیل داده و کارهایی که مسیر از پیش معلوم نیست مناسب است.

الگوی Plan-and-Execute#

اول یک برنامه‌ی کامل می‌سازد، بعد مرحله‌به‌مرحله execute می‌کند. اگر query ساده باشد، ساخت برنامه‌ی کامل توکن‌مصرفی بی‌دلیل است. این الگو برای taskهای پیچیده‌ی چندمرحله‌ای که نیاز به ساختار مشخص دارند مناسب‌تر است — نه برای اکثر کارهایی که تیم‌ها با آن شروع می‌کنند.

الگوی Router#

Router Pattern بر اساس نوع ورودی مسیر را انتخاب می‌کند — بدون برنامه‌ریزی کامل. در ایجنت‌های service عملی‌تر است چون latency و هزینه را کنترل می‌کند. مثلاً اگر query درباره‌ی قیمت است به یک sub-agent بده، اگر درباره‌ی troubleshooting است به sub-agent دیگر.

الگوlatencyهزینه توکنپیچیدگی debugمناسب برای
ReActمتوسطمتوسط تا بالامتوسطکاوش و تحلیل
Plan-and-Executeبالابالابالاtaskهای ساختارمند
Routerپایینپایینپایینservice با انواع query
Reflexionبالابالامتوسطکارهایی که retry لازم دارند

ساخت ایجنت بدون فریم‌ورک: 50 خط Python به‌جای LangChain#

یک ایجنت پایه با raw OpenAI API، یک loop ساده و چند tool definition در کمتر از 50 خط کد ساخته می‌شود. LangChain و LangGraph فقط لایه‌ی ارکستراسیون و state management را آسان‌تر می‌کنند، نه اینکه بدون آن‌ها ایجنت قابل‌ساخت نباشد.

این ادعا را هر کسی که یک بار برای اولین‌بار LangChain نصب کرده و بعد از دو روز به raw API برگشته تأیید می‌کند.

ساختار پوشه‌ی یک ایجنت مینیمال#

برای شروع فقط سه فایل لازم است:

  • main.py — loop اصلی
  • tools.py — تعریف توابع قابل‌دسترس
  • config.py — model name، max_iterations، API key

شبه‌کد: loop اصلی با function calling#

OpenAI قابلیت Function Calling را در ژوئن 2023 معرفی کرد. ساختار loop ساده است:

while iterations < max_iterations: response = llm.call(messages, tools); if response.tool_calls: execute and append results; else: return response.content as final answer; iterations += 1

همین. نه graph، نه chain، نه callback manager. اگر به state پیچیده، checkpoint یا multi-agent نیاز دارید، آن‌وقت فریم‌ورک منطقی است — و نه قبل از آن.

چه زمانی فریم‌ورک واقعاً لازم می‌شود#

  • State پیچیده با چندین branch که باید resume شوند
  • Multi-agent orchestration با پیام‌رسانی بین agentها
  • Checkpoint و retry برای کارهای طولانی
  • Integration با ده‌ها ابزار مختلف بدون نوشتن boilerplate

حافظه، ابزار و planner: سه ستون ایجنت قابل‌اتکا#

حافظه‌ی ایجنت سه لایه دارد: کوتاه‌مدت (context window)، بلندمدت (vector database) و working memory. ابزارها از طریق Function Calling یا Tool Use صدا زده می‌شوند و planner مسیر بعدی را تعیین می‌کند. Anthropic قابلیت Tool Use را در مه 2024 به API خود اضافه کرد.

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

حافظه‌ی کوتاه‌مدت#

Context window محدود است. هر tool result که به context اضافه می‌شود، جای پیام‌های قبلی را می‌گیرد. اگر ایجنت شما 10 مرحله اجرا کند و هر مرحله یک tool result بزرگ برگرداند، context پر می‌شود و مدل پیام‌های اول را فراموش می‌کند. راه‌حل: summarization بین مراحل یا sliding window.

حافظه‌ی بلندمدت#

معمولاً با vector database پیاده‌سازی می‌شود. هر interaction یا fact به embedding تبدیل و در index ذخیره می‌شود. در هر query جدید، ایجنت از vector store relevant context را retrieve می‌کند و به prompt اضافه می‌کند. این معماری retrieve-and-inject stateless است و محدود به context window نیست.

Function Calling و Tool Use#

OpenAI از schema-based function calling استفاده می‌کند. Anthropic از Tool Use API با ساختار متفاوت. هر دو در نهایت یک JSON با نام تابع و پارامترها برمی‌گردانند. تفاوت در schema تعریف‌شده و نحوه‌ی parse کردن خروجی است.

اشتباه رایج: tool overload#

الگوی تکرارشونده در پروژه‌های اعضای کامیونیتی: اضافه کردن بیش از 10 ابزار به یک ایجنت و افت accuracy انتخاب ابزار. مدل وقتی 15 ابزار دارد، اغلب ابزار اشتباه را انتخاب می‌کند یا پارامترهای نادرست می‌فرستد. بهترین ایجنت‌ها 3 تا 5 ابزار دارند، نه 15 تا. این عدد را نه از paper گرفته‌ایم، از ده‌ها debug session.

چه زمانی ایجنت نسازم؟ معیارهای تصمیم‌گیری#

اگر کار شما با یک workflow ثابت، یک conditional branch یا یک prompt مهندسی‌شده انجام می‌شود، ایجنت نسازید. ایجنت فقط زمانی توجیه دارد که مسیر اجرا از پیش مشخص نیست و به تصمیم‌گیری dynamic نیاز دارد. ساخت ایجنت برای مسئله‌ای که با workflow حل می‌شود، فقط latency و هزینه اضافه می‌کند.

این جمله را هر کسی که یک ایجنت بی‌دلیل ساخته و بعداً با یک switch-case جایگزینش کرده، باور دارد.

چک‌لیست تصمیم‌گیری#

  1. مسیر از پیش قابل‌پیش‌بینی است؟ → workflow بسازید، نه ایجنت
  2. نیاز به tool selection dynamic دارید؟ → ایجنت توجیه دارد
  3. latency و هزینه‌ی multi-step قابل‌پذیرش است؟ → اگر نه، ایجنت نسازید
  4. یک prompt مهندسی‌شده همان کار را می‌کند؟ → ایجنت overkill است
  5. RAG (Retrieval-Augmented Generation) بدون reasoning کافی است؟ → ایجنت لازم نیست

جایگزین‌های عملی#

  • Workflow با conditional: اگر مسیر ثابت است، n8n یا یک switch-case ساده
  • RAG بدون reasoning: retrieve + single call، بدون loop
  • Single prompt: با few-shot examples و structured output

ایجنت چندتایی (Multi-Agent): overhead توکنی و پیچیدگی debug#

در ارکستراسیون چندایجنتی هر agent یک context window جداگانه دارد و توکن‌مصرفی به‌صورت ضربی افزایش می‌یابد. برای اکثر use cases یک ایجنت با چند tool کافی است. Multi-agent فقط زمانی ضروری است که تخصص‌های متفاوت نیاز به reasoning مستقل دارند.

هزینه‌ی پنهان#

مشاهده‌ی میدانی از پروژه‌های اعضای کامیونیتی: overhead توکنی multi-agent در عمل 2 تا 3 برابر single-agent است. هر agent یک system prompt دارد، هر پیام‌رسانی بین agentها توکن مصرف می‌کند و هر agent context window مستقل پر می‌کند.

چه واقعاً multi-agent لازم دارد#

  • Research با sub-tasks موازی که هرکدام reasoning مستقل می‌خواهند
  • Code review با چند reviewer که هرکدام یک lens متفاوت دارند
  • Taskهایی که یک agent نمی‌تواند همه‌ی ابزارها را با accuracy انتخاب کند

چه اشتباه است#

Multi-agent برای task ساده‌ای که یک ایجنت با 2 tool انجام می‌دهد. الگوی رایج: یک agent برای research، یک agent برای writing، یک agent برای review — وقتی یک ایجنت با prompt مناسب هر سه را انجام می‌دهد.

معیارSingle AgentMulti-Agent
هزینه توکنپایین2 تا 3 برابر
latencyکمتربیشتر
پیچیدگی debugمتوسطبالا
مناسب برایاکثر use casesتخصص‌های کاملاً مجزا

اشتباهات رایج: حلقه‌ی بی‌پایان (infinite loop)، ابزار بیش از حد و فقدان guardrail#

رایج‌ترین شکست ایجنت‌ها حلقه‌ی بی‌پایان است که با max_iterations، timeout و reflection checkpoint قابل‌حل است. دومین اشتباه بزرگ اضافه کردن ابزارهای بی‌حساب و سوم فراموش کردن guardrail و سندباکس‌سازی (Sandboxing) است. الگوی تکرارشونده از پروژه‌های اعضای کامیونیتی: infinite loop بدون max_iterations شایع‌ترین شکست عملیاتی است.

Infinite loop#

ایجنت گیر می‌کند چون مدل هر بار همان tool را صدا می‌زند و همان نتیجه را می‌بیند. سه راه‌حل عملی: max_iterations به‌عنوان ceiling، timeout برای هر tool call، و یک reflection step که بعد از N تکرار بدون پیشرفت، مدل را مجبور به تغییر استراتژی می‌کند.

Prompt Injection از طریق ابزار#

اگر ایجنت یک web search tool دارد و نتیجه‌ی search شامل دستور مخفی باشد، ایجنت آن را execute می‌کند. دفاع: sanitize کردن خروجی ابزار قبل از اضافه کردن به context، و محدود کردن دسترسی ایجنت به ابزارهای read-only در محیط‌های حساس.

Sandboxing و Human-in-the-Loop#

ایجنت‌های قابل‌اتکا در تولید حضور انسانی در حلقه (Human-in-the-Loop) دارند، نه خودمختاری کامل. هر عمل غیرقابل‌بازگشت — حذف داده، ارسال ایمیل، پرداخت — باید تأیید انسانی بخواهد. ایجنت بدون محدودیت دسترسی، بمب ساعتی است.

ارزیابی، دیباگ و انتخاب فریم‌ورک عملیاتی#

دیباگ ایجنت با مشاهده‌ی مبتنی بر trace (trace-based observation) انجام می‌شود نه log سنتی. LangGraph برای کنترل state دقیق، CrewAI برای prototyping سریع multi-agent و AutoGen برای سناریوهای گفتگوی چندایجنتی مناسب‌ترند. LangChain در اکتبر 2022 توسط Harrison Chase ساخته شد و در سال‌های بعد به یکی از پرستاره‌ترین پروژه‌های open-source ارکستراسیون LLM تبدیل شد.

Trace-based debugging#

در هر مرحله باید سه چیز را ببینید: چه tool‌ای صدا زده شد، ورودی‌اش چه بود و خروجی‌اش چه شد. بدون این trace، دیباگ ایجنت یعنی حدس زدن. ابزارهایی مثل LangSmith یا W&B این observation را فراهم می‌کنند.

مقایسه‌ی فریم‌ورک‌ها#

فریم‌ورکمنحنی یادگیریکنترل stateمناسب برای
Raw APIسادهکاملاً دستیایجنت‌های کوچک و قابل‌فهم
LangGraphمتوسطدقیق (graph-based)State پیچیده و checkpoint
CrewAIسادهمحدودPrototyping سریع multi-agent
AutoGenمتوسطمحدودسناریوهای گفتگوی چندایجنتی

مدیریت هزینه#

  • Caching: اگر ابزارهای idempotent دارید، نتیجه را cache کنید
  • Model routing: برای مراحل ساده از مدل ارزان‌تر استفاده کنید
  • Batch: اگر ایجنت شما چند query مستقل دارد، batch call بزنید

ایجنت قابل‌اتکا در تولید، ایجنتی است که max_iterations دارد، ابزارهایش محدودند، عملیات غیرقابل‌بازگشتشان تأیید انسانی می‌خواهد و trace کاملشان در دسترس است. بقیه‌ی چیزها — فریم‌ورک، multi-agent، planner ماژولار — ابزارند، نه ضرورت.

اگر می‌خواهید ایجنت بسازید و نگرانید که از کجا شروع کنید، دوره‌ی «ساخت Ai Agent با N8N» در کامیونیتی اسکول دقیقاً همین مسیر را پوشش می‌دهد — از تعریف ابزار تا loop و deploy. برای کسایی که بدون کدنویسی می‌خواهند ایجنت و اتوماسیون بسازند، این مسیر عملی‌تر از شروع با raw Python است.