اگر مدل زبانی خودش تصمیم نمی‌گیرد کدام ابزار را کی صدا بزند، ایجنت هوش مصنوعی ندارید — یک workflow با ظاهر ایجنت دارید. هزینه‌ی واقعی ساخت ایجنت عملیاتی نه در کدنویسی حلقه، بلکه در ارزیابی غیرقطعی و پیاده‌سازی Budget Guard نهفته است؛ چیزی که آموزش‌های مقدماتی درباره‌اش سکوت می‌کنند.

ایجنت هوش مصنوعی چیست و چه فرقی با چت‌بات و workflow دارد؟#

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

سه‌ضلعی تشخیص: چت‌بات stateless است، هر ورودی مستقل از قبلی پاسخ می‌گیرد. workflow ترتیب گام‌هایش را کد شما تعیین می‌کند. ایجنت حلقه‌ی تصمیم‌گیری شرطی دارد — مدل خودش branch را انتخاب می‌کند.

معیار عملی: حلقه‌ی تصمیم‌گیری شرطی#

معیار عملی برای تشخیص ایجنت از workflow یک سؤال است: اگر مدل زبانی نتواند خودش بگوید «مرحله‌ی بعدی کدام است»، سیستم باز هم کار می‌کند؟ اگر بله، ایجنت نیست — فقط یک pipeline با چند call به LLM است. اگر نه، حلقه‌ی تصمیم‌گیری شرطی دارید و آن ایجنت است.

نمونه‌ی شبه‌کد برای درک تفاوت:

# Workflow — ترتیب ثابت
result = search(query)
summary = llm.summarize(result)
output = format(summary)

# Agent — تصمیم شرطی
while not done:
  action = llm.decide(history, tools)
  observation = execute(action)
  history.append(observation)
  done = check_stop(history)

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

RAG ایجنت نیست (مگر اینکه...)#

RAG ایجنت نیست مگر اینکه مدل خودش تصمیم بگیرد چندبار retrieve کند، از چه پایگاه داده‌ای بخواند، یا آیا اصلاً به retrieval نیاز دارد یا نه. در حالت عادی، RAG یک workflow با سه گام ثابت است: retrieve → inject → generate. ترتیب را کد شما تعیین کرده، نه مدل.

بسیاری از پروژه‌های RAG (Retrieval-Augmented Generation) را ایجنت صدا می‌کنند. اگر این تصمیم‌گیری شرطی وجود ندارد، یک chain ساده دارید نه ایجنت. برچسب‌زدنِ اشتباه هزینه دارد: انتظار رفتار تطبیقی از سیستمی دارید که هیچ‌وقت تطبیقی نبوده است.

معماری ایجنت: حلقه‌ی ادراک-تصمیم-عمل#

معماری ایجنت هوش مصنوعی از چهار لایه‌ی اصلی ساخته می‌شود: حافظه (Memory)، برنامه‌ریزی (Planning)، استفاده از ابزار (Tool Use) و حلقه‌ی کنترل (Agent Loop) که این سه را به هم وصل می‌کند. حذف هر لایه، سیستم را از ایجنت به ابزار ساده تنزل می‌دهد — و این تنزل اغلب بی‌صدا رخ می‌دهد.

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

حافظه: چرا LLM stateless است و ایجنت باید حافظه داشته باشد#

حافظه‌ی ایجنت باید در لایه‌ی orchestration پیاده شود، نه در مدل؛ چون مدل زبانی ذاتاً stateless است و هر call جدید صفحه‌ی سفید محسوب می‌شود. دو نوع حافظه لازم است: کوتاه‌مدت در context window و بلندمدت در vector database یا relational database. الگوی رایج: observation را به context اضافه کنید، و وقتی context پر شد، خلاصه‌سازی و انتقال به بلندمدت.

دو نوع حافظه:

  • حافظه‌ی کوتاه‌مدت (Short-term Memory): context window فعلی. تاریخچه‌ی گفت‌وگو و نتایج tool call‌های اخیر.
  • حافظه‌ی بلندمدت (Long-term Memory): vector database یا relational database. دانشی که بین session‌ها باقی می‌ماند.

Tool Use: از Function Calling تا MCP#

Tool Use از Function Calling شروع می‌شود: schema ابزار را به مدل بدهید، مدل JSON تولید کند، شما execute کنید. Model Context Protocol (MCP) که Anthropic معرفی کرده، این الگوی سفارشی را به پروتکل مشترک تبدیل می‌کند — مشابه USB-C در سخت‌افزار. به‌جای نوشتن adapter برای هر ابزار، همه‌ی ایجنت‌ها از یک پروتکل استفاده می‌کنند.

ساختار پوشه‌ی نمونه:

agent_project/
  ├── core/
  │   ├── loop.py      # حلقه‌ی ادراک-تصمیم-عمل
  │   ├── memory.py    # short-term + long-term
  │   └── budget.py    # Budget Guard
  ├── tools/
  │   ├── search.py
  │   ├── code_exec.py
  │   └── file_io.py
  ├── evals/
  │   ├── dataset.json
  │   └── harness.py
  └── config.yaml

شرط توقف: مهم‌ترین بخش حلقه که همه نادیده می‌گیرند#

شرط توقف مهم‌ترین بخش حلقه‌ی ایجنت است و همزمان بیشترین نادیده‌گرفته‌شده‌ی آن. بدون شرط توقف صریح، حلقه‌ی ادراک-تصمیم-عمل به infinite loop تبدیل می‌شود. سه شرط حداقلی لازم است: اعلام final answer توسط مدل، رسیدن به سقف iteration، و فعال شدن Budget Guard. اتکا به شرط اول به‌تنهایی در production شکست می‌خورد.

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

الگوهای برنامه‌ریزی: از ReAct تا Tree of Thoughts#

الگوهای برنامه‌ریزی ایجنت تعیین می‌کنند مدل چطور مسیر حل مسئله را بچیند. ReAct (Reasoning + Acting) که در مقاله‌ی Yao et al. (2022) معرفی شد، پایه‌ی حلقه‌ی تصمیم‌گیری در ایجنت‌های مدرن است: مدل به‌نوبت فکر می‌کند و عمل می‌کند. Plan-and-Execute ابتدا کل نقشه را می‌چیند و Tree of Thoughts چند مسیر موازی را کاوش می‌کند.

ReAct: الگوی پیش‌فرض ایجنت‌های امروزی#

ReAct ساختار Thought → Action → Observation را تکرار می‌کند تا مدل پاسخ نهایی بدهد. مزیت اصلی‌اش انعطاف‌پذیری است: تسک بازکاوشی مثل «مقاله‌ای پیدا کن که X را بررسی کرده باشد» با ReAct حل می‌شود چون مدل می‌تواند مسیر را وسط راه اصلاح کند. محدودیتش برای تسک‌های ساختارمند است: مدل هر بار فکر می‌کند و token مصرف می‌کند.

چه زمانی Plan-and-Execute بهتر از ReAct است؟#

Plan-and-Execute زمانی از ReAct بهتر عمل می‌کند که تسک ساختارمند باشد و مراحل از پیش معلوم‌اند. مدل ابتدا کل plan را یک‌جا می‌نویسد، سپس هر مرحله execute می‌شود — overhead فکرکردنِ تکراری حذف می‌شود. Tree of Thoughts برای مسئله‌هایی مناسب است که چند مسیر موازی دارند و باید backtracking کرد؛ هزینه‌ی token بالایی دارد و فقط وقتی توجیه‌پذیر است که ReAct واقعاً گیر کرده باشد.

Reflexion الگوی مکمل است: ایجنت پس از شکست، خودارزیابی می‌کند، lesson می‌نویسد و دوباره تلاش می‌کند.

الگوساختارهزینه‌ی tokenمناسب برای
ReActThought → Action → Observationمتوسطتسک‌های بازکاوشی
Plan-and-ExecutePlan once → Execute stepsکمترتسک‌های ساختارمند
Tree of ThoughtsBranch → Evaluate → Pruneبالامسئله‌های پیچیده
ReflexionAttempt → Self-evaluate → Retryمتوسطتسک‌های تکرارشونده

مقایسه فریمورک‌های ساخت ایجنت: LangChain، AutoGen، CrewAI و Semantic Kernel#

مقایسه فریمورک‌های ساخت ایجنت نشان می‌دهد انتخاب اشتباه، هزینه‌ی بازگشت دارد. LangChain برای ایجنت‌های تک‌نفره با چرخه‌ی توسعه سریع، AutoGen برای سیستم‌های چندایجنتی مبتنی بر گفت‌وگو، CrewAI برای نقش‌های سازمانی با ارکستراسیون ساده، و Semantic Kernel برای یکپارچگی با اکوسیستم مایکروسافت مناسب است.

فریمورکمدل ارکستراسیونپیچیدگیمناسب برایریسک
LangChain AgentReAct / Plan-and-Executeمتوسطایجنت تک‌نفره با tool‌های متنوعAbstraction سنگین، debugging دشوار
AutoGenگفت‌وگوی چندایجنتیبالاپروژه‌های تحقیقاتی و Multi-AgentCoordination overhead بالا
CrewAIنقش‌محور (Role-based)پاییناتوماسیون اداری با نقش‌های مشخصانعطاف‌پذیری کمتر برای تسک‌های پیچیده
Semantic KernelPlanner + Pluginمتوسطاکوسیستم مایکروسافت و .NETمحدودیت در مدل‌های غیر OpenAI

توصیه‌ی عملی: اگر با یک switch-case ساده حل می‌شود، فریمورک سنگین استفاده نکنید. LangChain abstraction layer اضافی دارد که debugging را دشوار می‌کند — این را در پروژه‌های اعضای کامیونیتی بارها دیده‌ایم: کسی LangChain نصب می‌کند، سه tool اضافه می‌کند، و بعد دو هفته صرف فهمیدن اینکه چرا tool call انجام نمی‌شود. برای پروژه‌های کوچک، پیاده‌سازی دستی از LangChain سبک‌تر و قابل‌فهم‌تر است.

سیستم چندایجنتی چه زمانی واقعاً لازم است؟#

سیستم چندایجنتی (Multi-Agent System) زمانی لازم است که تسک به نقش‌های تخصصی با scope محدود تقسیم شود و coordination overhead کمتر از هزینه‌ی یک ایجنت بزرگ با بیش از 10 tool باشد؛ در غیر این صورت، Single-Agent ارزان‌تر و قابل‌اعتمادتر است.

مشاهده‌ی مکرر در پروژه‌های عملیاتی: ایجنت با بیش از 5-6 tool نرخ خطا بالا می‌برد. مدل در انتخاب tool درست گیج می‌شود. راه‌حل: split به ایجنت‌های کوچک‌تر با scope محدود.

الگوی Supervisor: یک ایجنت هماهنگ‌کننده، چند ایجنت تخصصی#

الگوی Supervisor رایج‌ترین مدل ارکستراسیون چندایجنتی است: یک ایجنت هماهنگ‌کننده وظیفه‌ی تقسیم کار را دارد و ایجنت‌های تخصصی هر کدام 2-3 tool دارند. مثال: ایجنت محقق (search + read) + ایجنت نویسنده (draft + edit) + ایجنت ویرایشگر (review + format). هر کدام scope محدود، هر کدام قابل ارزیابی مستقل.

چه زمانی Multi-Agent ضرر دارد؟#

Multi-Agent ضرر دارد وقتی coordination overhead از خود تسک بیشتر شده باشد. هر پیام بین‌ایجنتی حداقل دو call به LLM است. اگر تسک به‌قدری ساده است که یک ایجنت با 4 tool حلش می‌کند، split به سه ایجنت فقط token اضافه و latency اضافه می‌سازد.

نشانه‌ی عملی: اگر بیشتر وقت صرف «گفت‌وگوی بین ایجنت‌ها» می‌شود تا «حل مسئله»، معماری را ساده کنید.

هزینه‌ی پنهان ایجنت: ارزیابی غیرقطعی، Budget Guard و حلقه‌ی بی‌پایان#

هزینه‌ی پنهان ایجنت در ارزیابی غیرقطعی نهفته است. برخلاف نرم‌افزار سنتی، ایجنت هوش مصنوعی ذاتاً non-deterministic است و نمی‌توان آن را با unit test معمولی تست کرد؛ باید evaluation harness با dataset و rubric بسازید. مشکل عملی: یک input ثابت، دو بار اجرا کنید، دو خروجی متفاوت می‌گیرید. assert_equal کار نمی‌کند. باید معیار کیفی داشته باشید.

Evaluation Harness: هزینه‌ای که در demo نمی‌بینید#

Evaluation harness باید قبل از اولین deploy وجود داشته باشد؛ بدون آن، نمی‌دانید ایجنت‌تان کار می‌کند یا نه. ساختار حداقلی سه جزء دارد: dataset ورودی با حداقل 20-30 نمونه‌ی تست و expected behavior، rubric برای نمره‌دهی کیفی، و LLM-as-Judge که خروجی را بر اساس rubric ارزیابی می‌کند. اکثر demoها این لایه را نشان نمی‌دهند.

ساختار حداقلی:

  1. Dataset ورودی: حداقل 20-30 نمونه‌ی تست با expected behavior.
  2. Rubric: معیارهای نمره‌دهی — آیا tool درست صدا زده شد؟ آیا پاسخ نهایی درست است؟ آیا در سقف budget ماند؟
  3. LLM-as-Judge: مدل دوم خروجی را بر اساس rubric نمره می‌دهد.

Budget Guard: سه سقفی که ایجنت را زنده نگه می‌دارد#

Budget Guard سه سقف در هر حلقه‌ی ایجنت تعریف می‌کند: سقف token، سقف iteration، و سقف زمان. الگوی Budget Guard در پروژه‌های عملیاتی مکرراً مشاهده شده. بدون این سه سقف، یک ایجنت در production می‌تواند صدها دلار token بسوزاند قبل از اینکه کسی متوجه شود.

class BudgetGuard:
  def __init__(self, max_tokens, max_iters, max_time_sec):
    self.max_tokens = max_tokens
    self.max_iters = max_iters
    self.max_time_sec = max_time_sec
    self.used_tokens = 0
    self.iter_count = 0

  def check(self):
    if self.iter_count >= self.max_iters:
      raise BudgetExceeded("max iterations")
    if self.used_tokens >= self.max_tokens:
      raise BudgetExceeded("max tokens")
    if elapsed() > self.max_time_sec:
      raise BudgetExceeded("max time")

Budget Guard را از روز اول پیاده کنید. نه بعد از اولین فاکتور سنگین.

Infinite Loop: باگ شماره‌ی یک ایجنت‌های عملیاتی#

Infinite Loop رایج‌ترین باگ ایجنت‌های عملیاتی است: مدل هر بار همان tool را صدا می‌زند، همان observation را می‌گیرد، همان Thought را تولید می‌کند. حلقه بی‌پایان. سه راه‌حل مؤثر: سقف iter (جزء Budget Guard)، detection دو observation یکسان پشت‌سرهم، و افزایش temperature اگر مدل در حالت deterministic گیر کرده باشد.

راه‌حل‌ها:

  • سقف iter (جزء Budget Guard).
  • Detection: اگر دو observation پشت‌سرهم یکسان بودند، loop را بشکن.
  • Temperature بالا: اگر مدل در حالت deterministic گیر کرده، temperature را کمی بالا ببرید.

از workflow شروع کن، به ایجنت ارتقا بده#

از workflow شروع کن، به ایجنت ارتقا بده: ابتدا با یک chain ثابت شروع کنید و فقط وقتی مدل واقعاً نیاز به تصمیم‌گیری شرطی دارد به ایجنت ارتقا دهید. اکثر تسک‌های خطی با یک پرامپت یا workflow ساده بهتر و ارزان‌تر انجام می‌شوند. ایجنت ساختن برای تسکی که workflow حلش می‌کند، فقط هزینه‌ی اضافه است.

نشانه‌هایی که می‌گویند «ایجنت لازم نیست»#

ایجنت لازم نیست وقتی ترتیب مراحل از پیش معلوم است و مدل نقشی در تصمیم‌گیری بین گام‌ها ندارد. پاسخ‌دهی با template ثابت، تبدیل فرمت (JSON → CSV، Markdown → HTML)، extraction ساده از متن، ترجمه، خلاصه‌سازی، بازنویسی — همه‌ی این‌ها workflow هستند، نه ایجنت. ساخت ایجنت برای این تسک‌ها فقط token اضافه و latency اضافه است.

  • پاسخ‌دهی با template ثابت.
  • تبدیل فرمت (JSON → CSV، Markdown → HTML).
  • Extraction ساده از متن.
  • ترجمه، خلاصه‌سازی، بازنویسی.
  • هر تسکی که ترتیب مراحلش از پیش معلوم است.

نشانه‌هایی که می‌گویند «workflow دیگر جواب نمی‌دهد»#

Workflow دیگر جواب نمی‌دهد وقتی مدل باید خودش branch را انتخاب کند و ترتیب گام‌ها از پیش قابل‌پیش‌بینی نیست. تسک بازکاوشی، کدنویسی با debug loop، پشتیبانی چندمرحله‌ای — این‌ها بدون حلقه‌ی تصمیم‌گیری شرطی حل نمی‌شوند.

  • تسک بازکاوشی: «مقاله‌ای پیدا کن که...»
  • کدنویسی با debug loop: run → error → fix → run.
  • پشتیبانی چندمرحله‌ای: شنیدن مشکل → تصمیم به tool → اجرای چند tool.
  • وقتی مدل باید خودش branch را انتخاب کند.

معیار تصمیم نهایی یک سؤال است: آیا مدل باید خودش تصمیم بگیرد قدم بعدی چیست؟ اگر نه، workflow کافی است. اگر بله، ایجنت لازم است.

گام‌های ساخت ایجنت عملیاتی از صفر تا production:

  1. تعریف دقیق تسک و معیار موفقیت (rubric).
  2. انتخاب الگوی برنامه‌ریزی (ReAct / Plan-and-Execute / ToT).
  3. تعریف ابزارها (حداکثر 5-6 tool per agent).
  4. پیاده‌سازی حلقه‌ی ادراک-تصمیم-عمل با شرط توقف صریح.
  5. افزودن Budget Guard: سقف token، سقف iter، سقف زمان.
  6. ساخت evaluation harness با حداقل 20-30 نمونه‌ی تست.
  7. لاگ‌برداری structured (trace) برای دیباگ.
  8. Deploy با monitoring و alert روی budget breach.

جمع‌بندی عملی: ایجنت هوش مصنوعی یک حلقه‌ی تصمیم‌گیری شرطی است، نه صرفاً LLM + ابزار. اگر این حلقه نیست، ایجنت ندارید. اگر حلقه هست ولی Budget Guard و evaluation harness ندارید، یک بمب زمان‌دار دارید. اگر با workflow ساده حل می‌شود، ایجنت نسازید — ارزان‌تر و قابل‌تست‌تر است.

اگر می‌خواهید این حلقه را در عمل بسازید و از صفر تا deploy پیش بروید، دوره‌ی «ساخت Ai Agent با N8N» در کامیونیتی N8N اسکول دقیقاً همین مسیر را پوشش می‌دهد — از طراحی حلقه تا پیاده‌سازی Budget Guard و ارزیابی.