AI Agentها جذاب‌اند چون می‌توانند درباره Step بعدی تصمیم بگیرند، Tool انتخاب کنند، نتیجه را ببینند و بر اساس آن ادامه دهند. همین قابلیت آن‌ها را برای بعضی مسئله‌ها واقعاً مفید می‌کند.

اما هر سیستمی که از LLM استفاده می‌کند، به Agent نیاز ندارد.

اگر مسیر حل از قبل روشن باشد و Branchها را بتوانیم مشخص کنیم، سپردن انتخاب مسیر به مدل معمولاً فقط Complexity بیشتری وارد سیستم می‌کند. (OpenAI, Anthropic, Microsoft)

قاعده‌ای که من معمولاً استفاده می‌کنم این است:

> اگر بتوانم مسیر حل را با اطمینان روی کاغذ رسم کنم، اول Workflow می‌سازم، نه Agent.

برای من Agent زمانی جدی می‌شود که نتیجه هر Step واقعاً روی Step بعدی اثر بگذارد و نتوان مسیر اجرا را از قبل با چند Branch مشخص طراحی کرد.

اول یک تعریف عملیاتی: Agent دقیقاً چیست؟

یکی از مشکلات بحث درباره AI Agent این است که تعریف واحدی برای آن وجود ندارد. OpenAI، Anthropic و Microsoft هرکدام روی بخش متفاوتی از مفهوم Agent تأکید می‌کنند.

OpenAI روی سیستمی تأکید می‌کند که LLM اجرای Task را مدیریت می‌کند و بر اساس وضعیت کار از Toolها استفاده می‌کند. Anthropic مرز روشن‌تری میان Workflow و Agent می‌گذارد: در Workflow مسیر اصلی از قبل در Code مشخص است، اما در Agent خود مدل به‌صورت پویا فرایند و Tool Usage را هدایت می‌کند. (OpenAI, Anthropic, Microsoft)
برای این مقاله از این تعریف عملیاتی استفاده می‌کنم:

AI Agent سیستمی است که برای رسیدن به یک Goal، درباره Step بعدی تصمیم می‌گیرد، در صورت نیاز Tool انتخاب و اجرا می‌کند، نتیجه را می‌بیند و این Loop را تا رسیدن به شرط پایان ادامه می‌دهد.

با این تعریف، یک LLM Call ساده Agent نیست. Function Calling هم به‌تنهایی Agent محسوب نمی‌شود. اینکه مدل بتواند یک Function را با پارامتر مشخص صدا بزند، با سیستمی که خودش درباره مسیر اجرا تصمیم می‌گیرد فرق دارد. (OpenAI, Anthropic)

این تفاوت مهم است، چون خیلی از پروژه‌هایی که با عنوان Agent ساخته می‌شوند، در عمل فقط به یکی از این‌ها نیاز دارند: - یک Prompt - یک Function Calling - یک Workflow مشخص - یا یک Agentic Workflow محدود

قانون اصلی من: آیا می‌توانم مسیر حل را روی کاغذ بکشم؟

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

اگر قبل از اجرا بتوانم این Flow را دقیق رسم کنم، ترجیح می‌دهم همان Workflow را پیاده کنم.

تعداد Stepها هم معیار خوبی نیست. یک Pipeline بیست‌مرحله‌ای که مسیرش از ابتدا مشخص است، هنوز Workflow است. در مقابل ممکن است Task فقط پنج Step داشته باشد، اما نتیجه هر Step مسیر بعدی را تغییر دهد و Branchها از قبل قابل پیش‌بینی نباشند. آنجا Agent می‌تواند منطقی‌تر باشد.

پس سؤال مهم این نیست که «Task چند مرحله دارد؟»؛ سؤال بهتر این است: «آیا Branching واقعی و غیرقابل‌پیش‌بینی داریم؟»

چهار جایی که Agent بیشتر Complexity اضافه می‌کند تا Value

۱. پشتیبانی با چند Intent محدود

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

اما بیشتر درخواست‌ها در چند دسته مشخص قرار می‌گرفتند؛ مثل «سفارشم کجاست؟»، «می‌خواهم لغو کنم» یا «فاکتور می‌خواهم». در چنین سناریویی، یک Classification اولیه با LLM و بعد یک Workflow ثابت برای هر Intent، از نظر من انتخاب ساده‌تر و قابل‌کنترل‌تری بود.

Agent از عهده این کار برمی‌آید، اما سؤال این است که چرا باید تصمیمی را هر بار به Agent بدهیم که ساختارش را از قبل می‌دانیم؟

۲. استخراج اطلاعات از فاکتور یا قرارداد

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

در بسیاری از موارد، یک LLM Call با Structured Output و JSON Schema مشخص کافی است. بعد Validationهای قطعی را Code انجام می‌دهد.

مثلاً اگر قرار است بررسی کنیم مجموع مبلغ ردیف‌ها با مبلغ کل برابر است یا نه، این یک مسئله deterministic است. من ترجیح می‌دهم این کنترل در Code انجام شود، نه اینکه مدل دوباره درباره آن «فکر» کند.

اینجا Agent Loop می‌تواند فقط یک لایه عدم‌قطعیت اضافه کند.

۳. گزارش‌گیری دوره‌ای

فرض کنید هر روز یک Query مشخص اجرا می‌شود، داده گرفته می‌شود، LLM خلاصه می‌نویسد و گزارش ارسال می‌شود. این از نظر معماری یک Pipeline است.

اگر Query مشخص است و Business Logic تغییر نمی‌کند، Agent لازم نیست هر بار تصمیم بگیرد چه Queryای بسازد یا چه داده‌ای بخواند. در یکی از الگوهایی که دیده‌ام، همین آزادی باعث می‌شد Queryها متفاوت شوند و مقایسه عددهای روزهای مختلف سخت‌تر شود.

در اینجا deterministic بودن یک مزیت است.

۴. Routing ساده

گاهی کل مسئله این است که مدل تشخیص دهد کدام Function باید اجرا شود؛ مثلاً `get_order_status`، `cancel_order` یا `send_invoice`.

در این سناریو Function Calling تک‌مرحله‌ای می‌تواند کافی باشد. مدل Function مناسب و پارامترها را انتخاب می‌کند و Code آن را اجرا می‌کند.

اگر بعد از اجرای Function قرار نیست مدل دوباره درباره مسیر بعدی تصمیم بگیرد، ساخت Agent Loop لزوماً ارزش اضافه نمی‌کند. (OpenAI, Anthropic)

یک Decision Framework ساده

برای اینکه بفهمم Agent واقعاً لازم است یا نه، چند سؤال می‌پرسم.

مسیر قابل‌پیش‌بینی است؟

اگر ورودی‌ها محدودند و هر ورودی به یک مسیر مشخص می‌رود، Workflow معمولاً انتخاب ساده‌تری است. منابع رسمی OpenAI، Anthropic و Microsoft هم روی همین اصل تأکید دارند: Complexity را فقط وقتی اضافه کنید که مسئله واقعاً به آن نیاز دارد. (OpenAI, Anthropic, Microsoft)

Step بعدی از قبل معلوم است؟

اگر Step سوم همیشه Step سوم است، Agent دقیقاً قرار است چه تصمیمی بگیرد؟ Agent زمانی معنی پیدا می‌کند که نتیجه Step دوم تعیین کند اصلاً Step سوم چیست.

Step زیاد است یا Branching زیاد؟

این دو را نباید یکی گرفت. Task طولانی الزاماً Agentic نیست. اگر مسیر ثابت باشد، فقط با یک Workflow طولانی طرفیم.

Latency و Cost مهم‌اند؟

Agentic systemها معمولاً Model Call، Tool Call و Loop بیشتری دارند؛ بنابراین نسبت به یک راه‌حل ساده‌تر می‌توانند Cost و Latency بیشتری داشته باشند. ( Anthropic)

این ادعا را نباید به یک عدد عمومی تبدیل کرد. مقدار واقعی به Model، تعداد Stepها، Toolها و معماری بستگی دارد.

Debugging و Reproducibility مهم‌اند؟

هرچه مسیر سیستم dynamicتر باشد، فهم اینکه چرا یک Run به نتیجه خاصی رسیده سخت‌تر می‌شود. Agentهای چندمرحله‌ای هم به Evaluation و Observability جدی‌تری نیاز دارند. (OpenAI, Anthropic)
اگر Business باید بتواند Runها را Audit کند یا خروجی تا حد زیادی قابل بازتولید باشد، میزان Autonomy باید با احتیاط بیشتری انتخاب شود.

هزینه خطا چقدر است؟

هرچه Agent Permission بیشتری داشته باشد، خطای آن می‌تواند اثر بزرگ‌تری ایجاد کند. منابع Anthropic هم روی افزایش Risk Surface با Autonomy بیشتر تأکید می‌کنند. ([Anthropi)

اصل طراحی من این است:

هرچه هزینه خطا بالاتر باشد، Autonomy کمتری به سیستم می‌دهم.

از ساده‌ترین Pattern شروع کن

یک Heuristic که خودم استفاده می‌کنم این ترتیب است:

1. Prompt / LLM Call
2. Function Calling
3. Deterministic Workflow
4. Agentic Workflow
5. AI Agent

این یک استاندارد رسمی نیست. هدفش این است که از همان ابتدا سراغ پیچیده‌ترین معماری نرویم.

اگر یک Prompt مسئله را درست حل می‌کند، نیازی به Function Calling نیست. اگر Function Calling کافی است، Workflow اضافه نکن. اگر Workflow با Reliability مناسب مسئله را حل می‌کند، Agent لازم نیست. و اگر مشخص شد مسیر واقعاً dynamic است و سیستم باید بر اساس Observationهای جدید تصمیم بگیرد، آن وقت Agent توجیه بیشتری پیدا می‌کند.

این نگاه با توصیه Anthropic و Microsoft برای شروع از ساده‌ترین Pattern و اضافه‌کردن Complexity در صورت نیاز هم‌راستاست.

یک نمونه عملی از همین رویکرد را می‌توانید در (پروژه AI Car Deal Hunter) ببینید؛ جایی که Workflow مراحل مشخص را هماهنگ می‌کند و Agent فقط در بخشی به‌کار می‌رود که تحلیل پویا لازم است. (Anthropic, Microsoft)

مرز AI، Rule و Human Approval در عملیات حساس

در سیستم‌های حساس، مسئله فقط این نیست که Agent استفاده کنیم یا Workflow. باید مشخص باشد چه کسی اجازه اجرای Action را دارد.

اصل من این است:

AI پیشنهاد می‌دهد و آماده می‌کند؛ Rule یا انسان اجازه اجرا را می‌دهد.

من این مرز را در سه لایه می‌بینم.

لایه اول: AI آزادتر است

در کارهای Read-only، کم‌ریسک یا برگشت‌پذیر، AI می‌تواند آزادی بیشتری داشته باشد؛ مثل Search، Summarization، Classification، Drafting و Recommendation.

اگر مدل در این لایه اشتباه کند، معمولاً Blast Radius محدودتر است.

لایه دوم: Hard Rule باید در Code باشد

اگر یک محدودیت واقعاً مهم است، نباید فقط داخل Prompt نوشته شود. مثلاً جمله «بیشتر از این مبلغ Refund نکن» برای من Control کافی نیست.

محدودیت واقعی باید داخل Tool یا Backend enforce شود؛ مثل سقف مبلغ، لیست گیرندگان مجاز، Rate Limit، Parameter Validation و Permission Check.

Toolها مرز میان تصمیم non-deterministic مدل و عملیات deterministic سیستم هستند و طراحی آن‌ها باید دقیق باشد.

در پروژه AI Sales Assistant هم همین اصل دیده می‌شود: Agent از طریق Toolهای کنترل‌شده به قابلیت‌های سیستم دسترسی دارد، نه با دسترسی آزاد و مستقیم به منطق یا داده‌های حساس. (Anthropic)

لایه سوم: Human-in-the-loop

برای Actionهایی که برگشت‌ناپذیرند یا هزینه خطای بالایی دارند، Human Approval می‌تواند بخشی از معماری باشد.

در سیاست طراحی موردنظر من:

- پرداخت یا انتقال پول: AI اطلاعات را آماده می‌کند و انسان تأیید می‌کند.
- تغییر یا حذف داده مهم: AI Diff یا Preview می‌سازد و انسان تأیید می‌کند.
- پیام رسمی: AI Draft می‌نویسد و انسان ارسال را تأیید می‌کند.
- تصمیم‌های اثرگذار بر انسان‌ها: AI می‌تواند تحلیل یا Recommendation بدهد، اما تصمیم نهایی نباید بدون چارچوب کنترلی مناسب به مدل واگذار شود.

Anthropic نیز روی Human Control، Guardrail و محدودسازی Action Surface در Agentهای دارای Autonomy تأکید می‌کند. (Anthropic)

چه زمانی Agent واقعاً ارزش دارد؟

Agent زمانی ارزش بیشتری پیدا می‌کند که مسیر حل مسئله واقعاً از قبل قابل پیش‌بینی نباشد.

Research باز و چندمرحله‌ای

فرض کنید سیستم باید Search کند، نتایج را بخواند، تشخیص دهد اطلاعات کافی است یا نه، Search جدیدی طراحی کند، شاید Tool دیگری استفاده کند و در نهایت نتیجه را Synthesise کند.

اینجا نتیجه هر مرحله روی تصمیم مرحله بعد اثر دارد. این نوع Task به منطق Agent نزدیک‌تر است. (Anthropic)

Debugging و Investigation

وقتی از ابتدا نمی‌دانیم مشکل کجاست، سیستم ممکن است لازم باشد Log بخواند، Hypothesis بسازد، Test انجام دهد و بر اساس نتیجه تصمیم جدید بگیرد. این مسیر را همیشه نمی‌شود از قبل کامل Hard-code کرد.

محیط متغیر

اگر سیستم با محیطی تعامل می‌کند که State آن در طول اجرا تغییر می‌کند، Observation بعدی می‌تواند مسیر تازه‌ای ایجاد کند.

Tool Selection واقعاً پویا

اگر Toolهای متعدد وجود دارند و انتخاب Tool وابسته به Contextی است که نمی‌توان همه Branchهایش را از قبل تعریف کرد، Agentic orchestration معنی بیشتری پیدا می‌کند. (OpenAI)

Checklist قبل از ساخت Agent

قبل از اینکه پروژه‌ای را Agentic کنم، این سؤال‌ها را می‌پرسم:

- آیا مسیر حل را می‌توانم روی کاغذ رسم کنم؟
- آیا Step بعدی واقعاً غیرقابل‌پیش‌بینی است؟
- آیا یک LLM Call کافی است؟
- آیا Function Calling کافی است؟
- آیا Workflow ثابت کافی است؟
- آیا Cost و Latency اضافه توجیه دارد؟
- آیا می‌توانم سیستم را Debug و Evaluate کنم؟
- اگر Agent اشتباه کند، Blast Radius چقدر است؟
- کدام Actionها باید Hard Rule داشته باشند؟
- کدام Actionها Human Approval می‌خواهند؟

یک Pseudocode ساده برای این طرز فکر می‌تواند چیزی شبیه این باشد:

python
if intent in KNOWN_INTENTS:
    run_deterministic_workflow(intent)
else:
    escalate_to_agentic_flow()

قرار نیست معماری واقعی همیشه به همین سادگی باشد. نکته این مثال فقط این است که Agent نباید Default Branch سیستم باشد.

جمع‌بندی

Agent ابزار قدرتمندی است، اما هدف معماری نیست.

اگر مسیر حل مسئله از قبل مشخص است، ورودی‌ها محدودند و Ruleها را می‌توان دقیق پیاده کرد، Workflow یا Function Calling معمولاً انتخاب ساده‌تر و قابل‌کنترل‌تری است.(OpenAI, Anthropic, Microsoft)

اگر مسیر پویاست، نتیجه هر مرحله روی تصمیم بعدی اثر می‌گذارد و Hard-code کردن Branchها عملاً سیستم را شکننده یا بسیار پیچیده می‌کند، Agent ارزش واقعی پیدا می‌کند.

قاعده‌ای که من برای خودم نگه می‌دارم همان است:

از ساده‌ترین چیزی که مسئله را درست حل می‌کند شروع کن.

Agent را وقتی اضافه کن که Complexity آن واقعاً در مقابل Complexity خود مسئله توجیه داشته باشد.

یک نمونه عملی

اگر می‌خواهید نمونه‌ای از ترکیب Workflow و Agent را در یک پروژه واقعی ببینید، پروژه AI Car Deal Hunter را ببینید.

منابع

- OpenAI — A practical guide to building AI agents
- OpenAI Developers — Agents
- OpenAI Developers — Agents SDK
- Anthropic — Building effective agents
- Anthropic — Demystifying evals for AI agents
- Anthropic — Trustworthy agents in practice
- Anthropic — Writing effective tools for agents
- Microsoft Learn — Agent architecture components
- Microsoft Agent Framework — Workflows
- Microsoft Learn — Agent search and tool use architectures