ایجنت‌های هوش مصنوعی که در محیط تولید دوام می‌آورند، هسته‌ی منطقی‌شان را با کد قطعی می‌سازند و مدل زبانی را فقط در لبه‌ها — جایی که تصمیم باز لازم است — فراخوانی می‌کنند. این الگوی «Deterministic Core, LLM Shell» برخلاف آنچه اکثر آموزش‌ها نشان می‌دهند، هزینه را کاهش و قابلیت‌اطمینان را بالا می‌برد.

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

ایجنت هوش مصنوعی (AI Agent) سیستمی است که در حلقه‌ی خودگردان تفکر → اقدام → مشاهده کار می‌کند و مسیر اجرا را در لحظه تصمیم می‌گیرد؛ چت‌بات فقط ورودی را به خروجی نگاشت می‌کند. مرز عملی این دو، «کنترل جریان» است: ایجنت خودش جریان را می‌سازد، چت‌بات جریانش از بیرون تزریق شده.

تمایز عملی بر اساس معیار «تصمیم‌یابی بدون پیش‌نویس»#

معیار ساده‌ای برای تشخیص ایجنت از چت‌بات وجود دارد: اگر سیستم بتواند در لحظه تصمیم بگیرد کدام ابزار را صدا بزند، آیا نتیجه کافی است و آیا باید دور بعدی اجرا شود، ایجنت است. اگر همه‌ی این تصمیم‌ها از قبل در یک Workflow ثابت نوشته شده‌اند، صرفاً اتوماسیون است.

یک چت‌بات با پرامپت مهندسی‌شده و چند ابزار می‌تواند در دمو شبیه ایجنت به نظر برسد. اما تفاوت در «کنترل جریان» است. ایجنت خودش جریان را می‌سازد؛ چت‌بات جریانش از بیرون تزریق شده.

پدیده Agent Washing — چرا بسیاری از اتوماسیون‌ها ایجنت نیستند#

Agent Washing به بازاریابی‌ای گفته می‌شود که هر سیستم مبتنی بر LLM را «ایجنت» جا می‌زند. یک چت‌بات که با پرامپت ثابت پاسخ می‌دهد، ایجنت نیست. یک RPA که با شرط‌های if-else کار می‌کند، ایجنت نیست.

نشانه‌های Agent Washing: ادعای خودمختاری بدون حلقه‌ی مشاهده، استفاده از کلمه «ایجنت» برای هر فراخوانی API به مدل زبانی، و نبودِ قابلیت «رد کردن» تصمیم خود. ایجنت واقعی می‌تواند خروجی‌اش را نقد کند و دور بعدی بزند.

Workflow در برابر Agent به سبک Andrew Ng — معیار ساده برای تصمیم‌گیری#

اندرو نگ (Andrew Ng) معیار عملی‌ای ارائه داده: اگر مسیر اجرا از قبل قابل‌پیش‌بینی است، Workflow بسازید. ایجنت فقط وقتی توجیه دارد که ورودی نامعلوم باشد و تصمیم در لحظه لازم باشد.

این معیار در پروژه‌های واقعی اعضای کامیونیتی بارها تأیید شده. تیم‌هایی که ایجنت‌های پیچیده برای وظایف ساده ساختند، بعداً به Workflow برگشتند — چون هزینه‌ی دیباگ رفتار غیرقطعی LLM از سود انعطاف بیشتر بود.

معماری ایجنت: حافظه، برنامه‌ریزی، ابزار و حلقه اجرا#

معماری ایجنت هوش مصنوعی از چهار جزء اصلی تشکیل شده: حافظه (Memory) برای نگهداری زمینه، برنامه‌ریز (Planner) برای شکستن هدف، ابزارها (Tools) برای تعامل با جهان بیرون، و حلقه اجرا (Agent Loop) که این سه را به‌صورت چرخه‌ای به هم متصل می‌کند.

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

حافظه کوتاه‌مدت و بلندمدت — چرا Vector Database تنها گزینه نیست#

حافظه‌ی ایجنت دو سطح دارد: کوتاه‌مدت (Context Window) که در هر فراخوانی LLM منتقل می‌شود، و بلندمدت که بین دورهای اجرا نگهداری می‌شود.

Vector Database فقط برای بازیابی معنایی (Semantic Retrieval) مناسب است. اما ایجنت‌های صنعتی به حافظه‌ی ساختاریافته هم نیاز دارند: وضعیت تسک، تاریخچه‌ی تصمیم‌ها، و متادیتای ابزارها. این‌ها را نمی‌توان با Embedding ذخیره کرد.

الگوی Structured Memory در ایجنت‌های صنعتی#

در پروژه‌های واقعی، Structured Memory معمولاً ترکیبی از این اجزاست:

  • یک JSON یا دیتابیس رابطه‌ای برای وضعیت تسک‌ها
  • یک Vector Store برای بازیابی اسناد و دانش
  • یک لاگ ساده (مثلاً SQLite یا فایل JSON) برای تاریخچه‌ی تصمیم‌ها

ایجنت‌هایی که فقط به Vector Store تکیه می‌کنند، در وظایف چندمرحله‌ای حالت (State) را گم می‌کنند. این یکی از رایج‌ترین دلایل شکست ایجنت در تولید است.

حلقه اجرای ایجنت و هزینه پنهان هر دور#

هر دور حلقه‌ی ایجنت حداقل یک فراخوانی LLM دارد. اگر ایجنت 10 دور اجرا کند، 10 فراخوانی LLM پرداخت کرده‌اید — حتی اگر 9 دور بی‌فایده بوده باشد.

هزینه‌ی پنهان اینجاست: رفتار غیرقطعی LLM یعنی نمی‌توانید تعداد دورها را از قبل تضمین کنید. در بدترین حالت، ایجنت در حلقه‌ی بی‌نهایت می‌افتد. راه‌حل: محدودسازی تعداد دور (Max Iterations) و کد قطعی برای تشخیص «تمام شد».

الگوهای طراحی ایجنت: از ReAct تا Plan-and-Execute#

الگوی ReAct (مقاله Yao و همکاران، 2022) حلقه‌ی تفکر-اقدام-مشاهده را استاندارد کرد؛ Plan-and-Execute ابتدا کل مسیر را برنامه‌ریزی و سپس اجرا می‌کند و Reflexion با بازاندیشی پس از شکست، کیفیت را بالا می‌برد.

ReAct — مناسب چه نوع وظایفی؟#

ReAct برای وظایفی مناسب است که تعداد ابزار کم است و تصمیم بعدی به نتیجه‌ی تصمیم قبلی وابسته است. مثلاً «باگ را پیدا کن و اصلاح کن» — ایجنت اول جستجو می‌کند، بعد بر اساس نتیجه تصمیم می‌گیرد.

نقطه‌ضعف ReAct: اگر وظیفه 20 مرحله داشته باشد، ایجنت ممکن است در مرحله‌ی 7 فراموش کند هدف اصلی چه بوده. Context Window محدود است و هر دور، اطلاعات قدیمی را از بین می‌برد.

Plan-and-Execute — تفاوت عملی با ReAct در هزینه و قابل‌پیش‌بینی بودن#

در Plan-and-Execute، ابتدا یک فراخوانی LLM کل مسیر را برنامه‌ریزی می‌کند و خروجی ساختارمند است. سپس هر مرحله بدون فراخوانی مجدد LLM (یا با فراخوانی کم‌هزینه‌تر) اجرا می‌شود.

تفاوت عملی: هزینه‌ی LLM در Plan-and-Execute قابل‌پیش‌بینی‌تر است چون تعداد فراخوانی‌ها از قبل معلوم است. اما اگر برنامه‌ریزی اولیه غلط باشد، کل اجرا خراب می‌شود. ReAct انعطاف‌پذیرتر است اما هزینه‌اش غیرقابل‌پیش‌بینی.

Reflexion و الگوی Deterministic Core, LLM Shell#

Reflexion یک لایه‌ی بازاندیشی اضافه می‌کند: اگر ایجنت شکست بخورد، نتیجه را نقد می‌کند و دور بعدی با آگاهی از خطا شروع می‌شود. این الگو کیفیت را بالا می‌برد اما هزینه‌ی هر دور را تقریباً دو برابر می‌کند.

الگوی Deterministic Core, LLM Shell — زاویه‌ی اصلی این مقاله — می‌گوید: هسته‌ی منطق (شرط‌ها، حلقه‌ها، مدیریت وضعیت) را با Python یا JavaScript بنویسید. LLM فقط در «لبه‌ها» فراخوانی شود: جایی که ورودی نامعلوم است و تصمیم باز لازم است.

مثلاً: ایجنتی که ایمیل‌ها را دسته‌بندی می‌کند. حلقه‌ی اصلی، شرط‌های فیلتر، و ساختار خروجی — کد قطعی. فقط مرحله‌ی «فهمیدن محتوای ایمیل» — فراخوانی LLM. این معماری هزینه را به‌شدت کاهش می‌دهد.

چه زمانی اصلاً نباید ایجنت بسازید؟#

اگر ورودی و مسیر اجرا از قبل معلوم است، اتوماسیون سنتی یا Workflow ارزان‌تر و قابل‌اعتمادتر است؛ ایجنت فقط وقتی توجیه دارد که تصمیم‌گیری در لحظه و بدون پیش‌نویس لازم باشد.

معیار Andrew Ng — پیش‌بینی‌پذیری مسیر#

سؤال کلیدی: آیا می‌توانید همه‌ی مسیرهای ممکن را از قبل بنویسید؟ اگر بله، Workflow بسازید. اگر خیر — چون ورودی متنوع است یا تصمیم بعدی به نتیجه‌ی قبلی وابسته است — ایجنت منطقی است.

جایگزین‌های ایجنت: RPA، Workflow، چت‌بات با پرامپت ثابت#

قبل از ساخت ایجنت، این سه گزینه را بررسی کنید:

  1. چت‌بات با پرامپت ثابت: اگر فقط «متن بده، پاسخ بگیر» لازم دارید، ایجنت اضافه است.
  2. Workflow (n8n، Make، Zapier): اگر چند ابزار باید به‌ترتیب مشخص اجرا شوند، بدون LLM در حلقه، Workflow بسازید.
  3. RPA: اگر تعامل با رابط کاربری گرافیکی لازم است و منطق از قبل معلوم است، RPA ارزان‌تر است.

پادالگوی «ایجنت = اتوماسیون هوشمند» و هزینه واقعی آن#

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

قاعده‌ی عملی: اگر با 50 خط Python و یک فراخوانی LLM مشکل حل می‌شود، ایجنت نسازید.

مراحل عملی ساخت ایجنت: از پیش‌نیاز تا استقرار#

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

پیش‌نیازهای فنی — چه باید بلد باشید؟#

  • Python در سطح متوسط (تابع، کلاس، مدیریت خطا)
  • آشنایی با REST API و JSON
  • درک مفهوم Prompt Engineering (نه صرفاً «پرامپت خوب بنویسید»)
  • مفاهیم پایه‌ی معماری نرم‌افزار (Separation of Concerns)

گام‌به‌گام ساخت با نمونه شبه‌کد (Python + OpenAI Function Calling)#

OpenAI Function Calling — قابلیتی که از ژوئن 2023 در دسترس است — به مدل زبانی اجازه می‌دهد نام و آرگومان‌های یک تابع را تولید کند. این قابلیت هسته‌ی فنی بسیاری از ایجنت‌های مبتنی بر ابزار است.

ساختار شبه‌کد یک ایجنت ساده:

def agent_loop(goal):
  messages = [{"role": "system", "content": SYSTEM_PROMPT}]
  messages.append({"role": "user", "content": goal})

  for i in range(MAX_ITERATIONS):
    response = llm_call(messages, tools=TOOL_DEFINITIONS)

    if response.is_final_answer:
      return response.content

    if response.tool_calls:
      for call in response.tool_calls:
        result = execute_tool(call.name, call.args)
        messages.append(tool_result(result))

  return "Max iterations reached"

نکته‌ی کلیدی: حلقه‌ی اصلی (for loop، شرط‌ها، مدیریت پیام‌ها) کد قطعی است. LLM فقط در llm_call فراخوانی می‌شود. این همان Deterministic Core, LLM Shell است.

ساختار پوشه‌ی پروژه‌ای ایجنت#

agent_project/
  ├── core/
  │   ├── loop.py       # حلقه‌ی اصلی (قطعی)
  │   ├── state.py       # مدیریت وضعیت
  │   └── guardrails.py  # محدودسازها
  ├── tools/
  │   ├── search.py
  │   └── calculator.py
  ├── llm/
  │   └── client.py      # لایه‌ی LLM (لبه)
  ├── config.py
  └── main.py

این ساختار را در پروژه‌های واقعی اعضای کامیونیتی بارها دیده‌ایم. تفکیک core از llm باعث می‌شود دیباگ آسان‌تر شود و هزینه‌ی LLM قابل‌کنترل بماند.

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

LangChain انعطاف بالا و اکوسیستم وسیع دارد اما در پروژه‌های بزرگ لایه‌های انتزاعی‌اش دیباگ را سخت می‌کند؛ CrewAI برای سناریوهای چند-عاملی ساده‌تر است و AutoGen (Microsoft) بر گفتگوی عامل‌محور تمرکز دارد.

جدول مقایسه‌ای — کاربرد مناسب، پیچیدگی، اکوسیستم#

فریمورککاربرد مناسبپیچیدگینقطه‌ضعف اصلی
LangChainایجنت تک-عاملی با ابزارهای متنوعمتوسطلایه‌های انتزاعی زیاد، دیباگ سخت
CrewAIسناریوهای چند-عاملی سادهکمکنترل محدود بر حلقه‌ی اجرا
AutoGenگفتگوی عامل‌محور و کدنویسی مشارکتیمتوسطتوابع وابسته‌ی سنگین، مستندات ضعیف
LlamaIndexایجنت مبتنی بر بازیابی دانش (RAG)کمبرای ایجنت‌های غیر-RAG اضافه است
کد مستقیم APIایجنت‌های تولیدی با کنترل کاملمتوسط تا بالانیاز به پیاده‌سازی دستی همه‌چیز

چرا بسیاری از تیم‌های تولیدی از LangChain به سمت کد مستقیم API می‌روند؟#

LangChain در مرحله‌ی Prototype سریع است. اما وقتی ایجنت وارد تولید می‌شود، لایه‌های انتزاعی آن باعث می‌شوند خطاها غیرقابل‌ردیابی شوند. تیم‌هایی که در پروژه‌های واقعی با LangChain کار کرده‌اند، اغلب بعد از 2 تا 3 ماه به کد مستقیم API مهاجرت می‌کنند.

دلیل: در کد مستقیم، حلقه‌ی اجرا شفاف است. هر فراخوانی LLM، هر ابزار، هر شرط — همه قابل‌لاگ و قابل‌تست هستند.

LlamaIndex و OpenAI Function Calling — چه زمانی فریمورک لازم نیست؟#

اگر ایجنت شما تک-ابزار است (مثلاً فقط جستجوی وب + پاسخ‌دهی)، به فریمورک نیاز ندارید. OpenAI Function Calling + 50 خط Python کافی است. فریمورک فقط وقتی ارزش دارد که ابزارها و سناریوهای پیچیده‌ای دارید.

هزینه، زمان و اشتباهات رایج در ساخت ایجنت#

ایجنت ساده (تک-ابزار، تک-حلقه) در چند روز قابل ساخت است اما هزینه‌ی هر دور حلقه (فراخوانی LLM) در مقیاس تولید، بودجه را تعیین می‌کند؛ رایج‌ترین اشتباه Tool Overload و خودمختاری مطلق بدون Human-in-the-Loop است.

Tool Overload — چرا بیشتر ابزار = بیشتر خطا؟#

هر ابزاری که به ایجنت می‌دهید، فضای انتخاب LLM را بزرگ‌تر می‌کند. با 10 ابزار، احتمال انتخاب ابزار غلط به‌شدت بالا می‌رود. اندرو نگ صریحاً توصیه می‌کند ابزارها را محدود نگه دارید.

الگوی تکرارشونده در پروژه‌های اعضای کامیونیتی: تیمی 15 ابزار به ایجنت می‌دهد، کیفیت افت می‌کند، بعد 3 ابزار نگه می‌دارند و کیفیت برمی‌گردد. این چرخه بارها دیده شده.

Human-in-the-Loop در مقابل خودمختاری مطلق#

ایجنت‌های خودمختار در وظایف حساس (ویرایش کد، ارسال ایمیل، تراکنش مالی) خطرناک‌اند. الگوی امن: ایجنت پیشنهاد می‌دهد، انسان تأیید می‌کند. این الگو در AutoGen به‌صورت built-in پشتیبانی می‌شود.

در عمل، Human-in-the-Loop هزینه‌ی انسانی اضافه می‌کند اما ریسک فاجعه را حذف می‌کند. برای ایجنت‌های تولیدی، این مبادله ارزشش را دارد.

هزینه‌ی پنهان Agent Loop — محاسبه فراخوانی‌های LLM در بدترین حالت#

هزینه‌ی ایجنت = تعداد دور × هزینه‌ی هر فراخوانی. اگر ایجنت 20 دور اجرا کند و هر دور 0.01 دلار باشد، 0.2 دلار هزینه‌ی یک تسک است. در مقیاس هزاران تسک، این عدد بودجه‌ساز می‌شود.

راه‌حل‌های عملی:

  • تعیین Max Iterations (معمولاً 5 تا 10)
  • استفاده از مدل ارزان‌تر برای دورهای ساده و مدل قوی‌تر فقط برای تصمیم‌های کلیدی
  • کد قطعی برای تشخیص «تمام شد» به‌جای اعتماد به LLM

ارزیابی و تست ایجنت: چگونه بفهمیم درست کار می‌کند؟#

ایجنت باید با سناریوهای چند-مرحله‌ای (نه فقط ورودی-خروجی تک‌تایی) تست شود؛ رویکرد Eval-Driven Development و بنچمارک‌هایی مثل SWE-bench و Voyager این روش را در عمل نشان داده‌اند.

تفاوت تست چت‌بات و تست ایجنت — چرا ورودی-خروجی کافی نیست؟#

تست چت‌بات: یک ورودی بدهید، خروجی را بررسی کنید. تست ایجنت: باید مسیر اجرا را بررسی کنید — آیا ابزار درست صدا زده شد؟ آیا حلقه‌ی تکرار بی‌فایده نبود؟ آیا خروجی نهایی درست است؟

ایجنت‌ها غیرقطعی‌اند. یک ورودی می‌تواند چند مسیر مختلف تولید کند. پس تست باید روی «خروجی نهایی صحیح» باشد، نه «مسیر دقیقاً یکسان».

SWE-bench و Voyager — نمونه‌های واقعی ارزیابی ایجنت#

SWE-bench یک بنچمارک حل باگ واقعی در مخازن GitHub است. ایجنت باید باگ را پیدا و اصلاح کند — بدون راهنمایی. Voyager (ایجنت ماینکرفت) با معیار «آیا تسک در محیط شبیه‌سازی کامل شد؟» ارزیابی می‌شود.

الگوی مشترک: ارزیابی بر اساس نتیجه‌ی نهایی، نه مسیر. این روش (Outcome-Based Evaluation) در پروژه‌های واقعی هم قابل‌استفاده است.

نوشتن Eval ساده برای ایجنت — شبه‌کد و ساختار#

def evaluate_agent(task, expected_result):
  # اجرای ایجنت
  result = agent.run(task.input)

  # بررسی خروجی نهایی (نه مسیر)
  is_correct = check_result(result, expected_result)

  # بررسی هزینه
  iterations = result.metadata["iteration_count"]
  cost = result.metadata["total_llm_cost"]

  return {
    "correct": is_correct,
    "iterations": iterations,
    "cost": cost
  }

# اجرای Eval روی مجموعه‌ای از تسک‌ها
tasks = load_test_suite("tasks.json")
results = [evaluate_agent(t, t.expected) for t in tasks]

این ساختار را در پروژه‌های واقعی اعضای کامیونیتی استفاده کرده‌ایم. نکته: expected_result باید با فاکتورهای انعطاف‌پذیر تعریف شود (مثلاً regex یا semantic match) چون خروجی LLM دقیقاً یکسان نیست.

نتیجه‌ی عملی: ایجنت نسازید مگر وقتی تصمیم‌گیری در لحظه لازم است. اگر ساختید، هسته‌ی قطعی داشته باشید، ابزارها را محدود نگه دارید، و با سناریوهای چندمرحله‌ای تست کنید. اگر می‌خواهید این الگوها را در پروژه‌ی واقعی پیاده‌سازی کنید، دوره‌ی ساخت Ai Agent با N8N در کامیونیتی اسکول، دقیقاً همین معماری را گام‌به‌گام می‌سازد.