اگر یک LLM فقط بتواند به سؤال شما جواب بدهد، هنوز الزاماً یک Agent نیست.

اما اگر بتواند:

• هدف را بفهمد
• وضعیت فعلی را بررسی کند
• تصمیم بگیرد قدم بعدی چیست
• ابزار مناسب را انتخاب کند
• نتیجه ابزار را بررسی کند
• در صورت نیاز برنامه خود را تغییر دهد
• چند مرحله را پشت سر هم انجام دهد
• و در نهایت تشخیص دهد که کار تمام شده است

در این حالت وارد دنیای AI Agents و Agentic AI شده‌ایم.

در این مقاله با مهم‌ترین مفاهیم این حوزه آشنا می‌شویم:

1. AI Agent چیست؟
2. Agentic AI چیست؟
3. Agent Loop
4. Planning
5. Reasoning
6. Memory
7. Tool Calling
8. Multi-step Tasks
9. Error Handling
10. Human-in-the-loop
11. معماری یک Agent واقعی
12. مثال کامل Agentic CRM

1. AI Agent چیست؟

یک تعریف کاربردی برای AI Agent این است:

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

در ساده‌ترین حالت:

Goal → Observe → Decide → Act → Observe → ... → Finish

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

2. تفاوت Chatbot و Agent

فرض کنید کاربر می‌گوید:

وضعیت مشتری Acme را بررسی کن.

یک Chatbot ساده ممکن است درباره روش بررسی وضعیت مشتری توضیح بدهد.

اما یک Agent می‌تواند:

1. نام مشتری را تشخیص دهد.
2. CRM را جستجو کند.
3. اطلاعات Account را دریافت کند.
4. Opportunityهای باز را بررسی کند.
5. Ticketهای پشتیبانی را بخواند.
6. وضعیت مشتری را تحلیل کند.
7. نتیجه نهایی را به کاربر بدهد.

بنابراین:

Chatbot معمولاً پاسخ می‌دهد.

Agent برای رسیدن به هدف، اقدام می‌کند.

3. Agentic AI چیست؟

Agentic AI اصطلاح گسترده‌تری است و به سیستم‌هایی گفته می‌شود که رفتار آن‌ها بر پایه درجاتی از خودمختاری، تصمیم‌گیری و اقدام طراحی شده است.

یک سیستم Agentic ممکن است بتواند:

• هدف را به Taskهای کوچک تقسیم کند
• ابزار انتخاب کند
• اطلاعات جمع‌آوری کند
• تصمیم قبلی خود را اصلاح کند
• از Memory استفاده کند
• از خطا Recover کند
• در صورت ریسک بالا از انسان کمک بگیرد

بنابراین Agentic بودن یک ویژگی صفر و یک نیست.

یک سیستم ممکن است استقلال کمی داشته باشد و سیستم دیگری استقلال بسیار بیشتری.

4. مدل ذهنی ساده یک Agent

می‌توان یک Agent را به پنج بخش اصلی تقسیم کرد:

Goal

↓

Observe

↓

Think / Decide

↓

Act

↓

Evaluate

و سپس دوباره چرخه ادامه پیدا می‌کند.

این چرخه همان چیزی است که معمولاً Agent Loop نامیده می‌شود.

5. Agent Loop چیست؟

Agent Loop قلب بسیاری از Agentهاست.

فرض کنید کاربر می‌گوید:

بهترین مشتریانی که احتمال خرید دوباره دارند پیدا کن و برایشان Draft ایمیل آماده کن.

Agent نمی‌تواند این درخواست را در یک قدم انجام دهد.

ممکن است Loop زیر شکل بگیرد:

Step 1

مشاهده هدف:

Find customers likely to repurchase and prepare email drafts.

Step 2

Agent تصمیم می‌گیرد ابتدا مشتریان را از CRM بگیرد.

Tool:

search_customers()

Step 3

نتیجه ابزار بررسی می‌شود.

Step 4

Agent تصمیم می‌گیرد Purchase History را دریافت کند.

Tool:

get_purchase_history(customer_ids)

Step 5

داده‌ها تحلیل می‌شوند.

Step 6

Agent مشتریان مناسب را انتخاب می‌کند.

Step 7

برای هر مشتری Draft ایمیل تولید می‌کند.

Step 8

بررسی می‌کند آیا هدف کامل شده است یا نه.

اگر بله:

Finish

اگر خیر:

Loop ادامه پیدا می‌کند.

6. ساختار ساده Agent Loop

از نظر برنامه‌نویسی می‌توان Agent Loop را تقریباً چنین تصور کرد:

while not finished:
    observe()
    decide_next_action()
    execute_action()
    inspect_result()

اما یک Agent واقعی باید محدودیت هم داشته باشد.

مثلاً:

MAX_STEPS = 10

چرا؟

چون بدون Stop Condition ممکن است Agent وارد Loop بی‌نهایت شود.

7. Stop Condition

Agent باید بداند چه زمانی کار را متوقف کند.

چند Stop Condition رایج:

• هدف کامل شده است
• اطلاعات کافی نیست
• نیاز به سؤال از کاربر وجود دارد
• عملیات نیازمند تأیید انسان است
• تعداد مراحل از حد مجاز گذشته است
• Tool چند بار شکست خورده است
• هزینه از Budget عبور کرده است

بنابراین Agent نباید فقط بداند چگونه ادامه دهد؛ باید بداند چه زمانی نباید ادامه دهد.

8. Planning چیست؟

Planning یعنی Agent قبل یا حین اجرای کار تصمیم بگیرد برای رسیدن به هدف چه مراحلی لازم است.

مثلاً هدف:

Prepare a sales report for last quarter.

ممکن است به مراحل زیر تبدیل شود:

1. دریافت داده فروش
2. حذف سفارش‌های Cancel شده
3. محاسبه Revenue
4. پیدا کردن Top Customers
5. مقایسه با فصل قبلی
6. ساخت Summary

این فرآیند همان Task Decomposition است.

9. Static Planning و Dynamic Planning

Planning می‌تواند به دو شکل کلی انجام شود.

Static Planning

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

مثلاً:

Step 1 → Step 2 → Step 3 → Step 4

مزیت:

ساختار مشخص است.

مشکل:

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

Dynamic Planning

Agent بعد از هر مرحله تصمیم می‌گیرد قدم بعدی چیست.

مثلاً:

Observe → Choose next action → Execute → Observe again

این مدل انعطاف بیشتری دارد و برای محیط‌های غیرقابل پیش‌بینی مناسب‌تر است.

بسیاری از Agentهای واقعی ترکیبی از هر دو روش هستند.

10. Plan-and-Execute

یکی از معماری‌های مهم Agentها Planner-Executor است.

در این معماری دو نقش داریم:

Planner

کار را به مراحل کوچک‌تر تقسیم می‌کند.

Executor

هر مرحله را اجرا می‌کند.

مثلاً:

Planner:

1. Search customer
2. Get opportunities
3. Check support issues
4. Calculate account risk
5. Generate summary

Executor سپس این مراحل را یکی‌یکی انجام می‌دهد.

مزیت این معماری این است که Planning و Execution از هم جدا می‌شوند.

11. Reasoning در Agentها یعنی چه؟

Reasoning یعنی Agent بتواند بر اساس اطلاعات موجود، گزینه‌ها و محدودیت‌ها تصمیم مناسب برای قدم بعدی را انتخاب کند.

مثلاً:

کاربر می‌گوید:

برای مشتری ایمیل Follow-up بفرست.

Agent ممکن است ابتدا بررسی کند:

• آیا Email مشتری موجود است؟
• آیا مشتری Opt-out نکرده؟
• آیا آخرین ایمیل دیروز ارسال نشده؟
• آیا کاربر اجازه ارسال Email دارد؟

سپس تصمیم بگیرد:

Send

یا:

Ask

یا:

Abstain

یا:

Escalate

این همان Reasoning کاربردی در Agent است.

12. Reasoning با Chain of Thought یکی نیست

در طراحی سیستم Agent لازم نیست Reasoning داخلی مدل را به کاربر نمایش دهیم.

چیزی که برای نرم‌افزار اهمیت دارد، تصمیم قابل بررسی است.

مثلاً به جای ذخیره یک استدلال طولانی داخلی، می‌توان خروجی ساختاریافته داشت:

{
  "action": "ASK_USER",
  "reason_code": "MISSING_EMAIL",
  "message": "Customer email address is missing."
}

این روش برای Production بسیار بهتر است، چون:

• قابل Log کردن است
• قابل تست است
• قابل Audit است
• ساده‌تر Validate می‌شود

13. Tool Calling

Agent برای انجام کار واقعی به Tool نیاز دارد.

Tool می‌تواند شامل موارد زیر باشد:

• Database Query
• CRM API
• Search
• Email Service
• Calendar
• Calculator
• File System
• Payment API
• Internal Business Service

مثلاً:

get_account(account_id)
get_opportunities(account_id)
create_task(data)
send_email(data)

LLM مشخص می‌کند چه Toolی لازم است.

اما Backend باید اجرای Tool را کنترل کند.

14. Tool Description اهمیت زیادی دارد

فرض کنید Tool زیر داریم:

search()

این نام بسیار مبهم است.

اما:

search_crm_accounts_by_name(name)

واضح‌تر است.

Description مناسب Tool باعث می‌شود Agent بهتر تصمیم بگیرد چه زمانی از آن استفاده کند.

برای هر Tool باید مشخص باشد:

• چه کاری انجام می‌دهد؟
• چه ورودی‌هایی دارد؟
• چه زمانی باید استفاده شود؟
• چه زمانی نباید استفاده شود؟
• خروجی آن چیست؟

15. Tool Schema

Toolها بهتر است Schema مشخص داشته باشند.

مثلاً:

{
  "name": "get_customer",
  "arguments": {
    "customerId": "string"
  }
}

Backend باید قبل از اجرا بررسی کند که:

• پارامتر وجود دارد
• Type صحیح است
• مقدار مجاز است
• کاربر Permission دارد

Agent نباید Validator نهایی Tool باشد.

16. Tool Result

نتیجه Tool دوباره وارد Context می‌شود.

مثلاً:

{
  "customerId": "C-104",
  "name": "Acme",
  "status": "Active",
  "openOpportunities": 2
}

Agent حالا می‌تواند براساس این اطلاعات تصمیم بعدی را بگیرد.

یعنی Tool Calling معمولاً یک فرآیند رفت‌وبرگشتی است:

LLM → Tool → Result → LLM → Next Tool → Result → ...

17. Multi-step Tasks

یکی از تفاوت‌های اصلی Agent با یک LLM ساده، توانایی انجام کارهای چندمرحله‌ای است.

مثلاً:

سه مشتری مهمی که بیشترین ریسک Churn دارند پیدا کن، دلیل را مشخص کن و برای Account Manager آن‌ها Task بساز.

این درخواست ممکن است نیاز داشته باشد به:

1. دریافت لیست مشتریان
2. دریافت Usage
3. دریافت Support Tickets
4. دریافت Payment History
5. محاسبه Churn Risk
6. Ranking مشتریان
7. پیدا کردن Account Manager
8. ساخت Task
9. تولید Summary

هیچ‌کدام از این مراحل به تنهایی هدف نهایی نیستند.

Agent باید همه را به صورت هماهنگ انجام دهد.

18. State چیست؟

برای انجام Multi-step Task، Agent باید بداند تا این لحظه چه اتفاقی افتاده است.

به این اطلاعات معمولاً State گفته می‌شود.

مثلاً:

{
  "goal": "Find churn-risk customers",
  "step": 4,
  "customersLoaded": true,
  "supportDataLoaded": true,
  "paymentDataLoaded": false
}

State کمک می‌کند Agent بداند:

• کجای کار است
• چه چیزی انجام شده
• چه چیزی هنوز باقی مانده

19. Memory چیست؟

Memory در Agentها یعنی اطلاعاتی که Agent می‌تواند در مراحل مختلف یا حتی Sessionهای مختلف دوباره استفاده کند.

Memory را نباید با Context Window یکی بدانیم.

Context Window اطلاعاتی است که مدل همین الان می‌بیند.

Memory اطلاعاتی است که سیستم ذخیره کرده و در صورت نیاز دوباره Retrieve می‌کند.

20. انواع Memory

می‌توان Memory را به چند نوع کاربردی تقسیم کرد.

Working Memory

اطلاعات مربوط به Task فعلی.

مثلاً:

• هدف فعلی
• Tool Results
• Plan
• Step Number

این اطلاعات معمولاً با پایان Task اهمیت خود را از دست می‌دهند.

Conversation Memory

اطلاعات مربوط به مکالمه.

مثلاً:

کاربر قبلاً گفته:

منظورم Account اروپایی بود.

Agent باید در سؤال بعدی این Context را در نظر بگیرد.

Long-term Memory

اطلاعاتی که ممکن است در آینده هم مفید باشند.

مثلاً:

• Preference کاربر
• Workflow مورد علاقه
• اطلاعات پایدار پروژه

Long-term Memory باید با احتیاط طراحی شود، چون مشکلات Privacy، Staleness و داده‌های اشتباه را ایجاد می‌کند.

Episodic Memory

Memory مربوط به تجربه‌های قبلی Agent.

مثلاً:

در Task قبلی API فروش با Timeout مواجه شد و Retry دوم موفق شد.

Semantic Memory

دانش عمومی یا سازمانی.

مثلاً:

• مستندات شرکت
• Policyها
• Knowledge Base

این نوع Memory معمولاً با Retrieval و RAG ترکیب می‌شود.

21. Memory باید Selective باشد

اشتباه رایج این است که تمام Conversation را برای همیشه ذخیره و دوباره به Agent بدهیم.

این کار مشکلات زیادی ایجاد می‌کند:

• هزینه بالا
• Context شلوغ
• اطلاعات قدیمی
• Privacy Risk
• تصمیم‌گیری ضعیف

Memory خوب باید بتواند تصمیم بگیرد:

Store?

Retrieve?

Forget?

یعنی Memory Management خودش یک مسئله طراحی است.

22. ReAct چیست؟

یکی از الگوهای مشهور Agentها ReAct است.

نام آن از ترکیب:

Reason + Act

می‌آید.

مدل کلی:

Observe → Decide → Act → Observe → Decide → Act

مثلاً:

کاربر:

وضعیت سفارش 5421 را پیدا کن و اگر دیر شده بود Ticket بساز.

Agent:

1. وضعیت سفارش را می‌گیرد.
2. می‌بیند Delivery Date گذشته است.
3. تصمیم می‌گیرد Ticket لازم است.
4. Ticket ایجاد می‌کند.
5. نتیجه را گزارش می‌دهد.

23. Reflection چیست؟

Reflection یعنی Agent نتیجه کار خود را بررسی کند و بپرسد:

آیا خروجی من مناسب است؟

مثلاً Agent گزارشی تولید کرده است.

یک مرحله Verification ممکن است بررسی کند:

• آیا همه داده‌های لازم وجود دارند؟
• آیا عددها با Tool Result مطابقت دارند؟
• آیا Task کامل شده؟

اگر پاسخ منفی باشد، Agent می‌تواند اصلاح انجام دهد.

اما Reflection نباید بدون محدودیت تکرار شود، چون هزینه و Latency را بالا می‌برد.

24. Verification

برای Taskهای حساس، یک مرحله Verification مستقل بسیار مفید است.

مثلاً:

Generator → Verifier → Action

Generator پیشنهاد می‌دهد:

Discount = 40%

Verifier بررسی می‌کند:

Maximum allowed discount for this role = 20%

در نتیجه عملیات Reject می‌شود.

برای Ruleهای قطعی، Verification بهتر است در Code انجام شود نه توسط LLM.

25. Error Handling

Agent باید بتواند خطاها را مدیریت کند.

فرض کنید Tool پاسخ می‌دهد:

503 Service Unavailable

Agent یا Controller می‌تواند:

1. Retry کند
2. Tool دیگری انتخاب کند
3. مدتی صبر کند
4. از کاربر سؤال کند
5. Task را متوقف کند

Agent نباید خطای Tool را با موفقیت اشتباه بگیرد.

26. Retry Strategy

Retry باید محدود باشد.

مثلاً:

MAX_RETRIES = 3

و بهتر است Backoff داشته باشد:

1 second
2 seconds
4 seconds

Retry بدون محدودیت می‌تواند باعث Loop، هزینه زیاد و فشار روی API شود.

27. Human-in-the-loop

همه چیز نباید به صورت کاملاً خودکار اجرا شود.

برای عملیات حساس بهتر است Agent بتواند کار را به انسان بسپارد.

مثلاً:

• حذف مشتری
• ارسال Refund
• تخفیف بسیار بالا
• تغییر Contract
• ارسال ایمیل حساس

Flow می‌تواند چنین باشد:

Agent proposes action

↓

Human approves

↓

Backend executes

این همان Human-in-the-loop است.

28. Ask, Act, Abstain, Escalate

یک Agent خوب همیشه نباید Act کند.

چهار خروجی بسیار مهم برای Agent عبارت‌اند از:

ACT

اطلاعات کافی است و عملیات مجاز است.

ASK

اطلاعات کافی نیست؛ از کاربر سؤال شود.

ABSTAIN

Agent نباید عمل کند.

ESCALATE

تصمیم باید به انسان سپرده شود.

این مدل برای Agentهای قابل اعتماد بسیار مهم است.

29. Agent Autonomy

سطح Autonomy می‌تواند متفاوت باشد.

Level 0 — Suggest Only

Agent فقط پیشنهاد می‌دهد.

Level 1 — Draft

Agent Draft تولید می‌کند اما اجرا نمی‌کند.

Level 2 — Act with Confirmation

Agent عملیات را آماده می‌کند ولی تأیید انسان لازم است.

Level 3 — Autonomous Low-risk Actions

Agent عملیات کم‌ریسک را خودکار انجام می‌دهد.

Level 4 — High Autonomy

Agent بخش بزرگی از Workflow را مستقل انجام می‌دهد.

در سیستم‌های واقعی بهتر است Autonomy متناسب با Risk باشد.

30. معماری ساده یک Agent

یک معماری ساده می‌تواند چنین باشد:

User
 ↓
Agent Controller
 ↓
LLM
 ↓
Decision
 ↓
Tool Router
 ↓
Tools / APIs / Database
 ↓
Result
 ↓
Agent Controller
 ↓
LLM
 ↓
Final Answer / Next Action

Agent Controller یکی از مهم‌ترین بخش‌های سیستم است.

31. Agent Controller چه کاری انجام می‌دهد؟

Controller معمولاً مسئول موارد زیر است:

• مدیریت Loop
• Step Counter
• Context Construction
• Tool Execution
• Tool Permissions
• State Management
• Retry
• Timeout
• Logging
• Cost Limits
• Human Approval
• Stop Conditions

این مسئولیت‌ها را نباید کاملاً به LLM واگذار کرد.

32. مثال شبه‌کد Agent

state = initialize_task(user_request)

for step in range(MAX_STEPS):

    context = build_context(state)

    decision = llm.decide(context)

    if decision.type == "FINISH":
        return decision.response

    if decision.type == "ASK":
        return ask_user(decision.question)

    if decision.type == "ESCALATE":
        return request_human_review(decision)

    if decision.type == "TOOL_CALL":
        validate(decision.tool)
        result = execute(decision.tool)
        state.add(result)

return stop_due_to_step_limit()

این ساختار ساده بسیاری از مفاهیم Agentic AI را در خود دارد.

33. Example: Agentic CRM

حالا یک مثال واقعی‌تر بررسی کنیم.

کاربر می‌گوید:

مشتریانی را پیدا کن که احتمال Churn بالایی دارند، سه مورد مهم را انتخاب کن و برای Account Manager آن‌ها Task بساز.

Step 1 — Goal Understanding

Agent هدف را مشخص می‌کند:

Identify high-risk customers and create follow-up tasks.

Step 2 — Planning

Plan:

1. Load active accounts
2. Get usage metrics
3. Get support tickets
4. Get payment history
5. Estimate churn risk
6. Rank customers
7. Select top 3
8. Find account managers
9. Create tasks
10. Report results

Step 3 — Tool Calling

Agent اجرا می‌کند:

get_active_accounts()

سپس:

get_usage_metrics(accountIds)

و بعد:

get_support_history(accountIds)

Step 4 — Reasoning

Agent داده‌ها را تحلیل می‌کند.

مثلاً:

Acme:
Usage ↓ 45%
3 unresolved tickets
Payment delayed 12 days

در نتیجه Risk بالا تشخیص داده می‌شود.

34. Structured Decision

خروجی بهتر است ساختاریافته باشد:

{
  "accountId": "A-192",
  "riskLevel": "HIGH",
  "signals": [
    "USAGE_DROP",
    "OPEN_SUPPORT_CASES",
    "PAYMENT_DELAY"
  ],
  "recommendedAction": "CREATE_FOLLOW_UP_TASK"
}

35. Permission Check

قبل از ساخت Task، Backend بررسی می‌کند:

• آیا کاربر Permission دارد؟
• آیا Account Manager مشخص است؟
• آیا Task مشابه از قبل وجود ندارد؟

سپس عملیات انجام می‌شود.

36. Multi-step Execution

Agent برای هر سه مشتری:

find_account_manager()

و سپس:

create_follow_up_task()

را اجرا می‌کند.

در پایان بررسی می‌کند:

3/3 tasks created successfully

و Task را Finish می‌کند.

37. اگر یکی از مراحل شکست بخورد چه؟

فرض کنیم برای یک Account، Account Manager پیدا نمی‌شود.

Agent نباید Manager را حدس بزند.

می‌تواند تصمیم دهد:

{
  "action": "ESCALATE",
  "reason": "ACCOUNT_MANAGER_NOT_FOUND"
}

و دو Task دیگر را ایجاد کند.

این رفتار بسیار بهتر از Hallucination است.

38. Observability

Agent بدون Logging تقریباً غیرقابل Debug است.

برای هر Task بهتر است موارد زیر Log شوند:

• User Request
• Agent Goal
• Plan
• Step Number
• Tool Call
• Tool Arguments
• Tool Result
• Error
• Retry
• Final Status
• Cost
• Latency

مثلاً:

Task ID: 9182
Step 1: get_accounts → success
Step 2: get_usage → success
Step 3: get_tickets → timeout
Step 3 retry 1 → success
Step 4: calculate_risk → success

39. Agent Evaluation

یک Agent را نباید فقط با کیفیت متن نهایی ارزیابی کرد.

معیارهای مهم‌تر عبارت‌اند از:

• Task Success Rate
• Tool Selection Accuracy
• Tool Argument Accuracy
• Number of Steps
• Cost per Task
• Latency
• Error Recovery Rate
• Hallucination Rate
• Human Escalation Rate
• Unsafe Action Rate

40. Common Failure Modes

Agentها می‌توانند به روش‌های مختلف شکست بخورند.

Infinite Loop

Agent مدام مراحل را تکرار می‌کند.

راه‌حل:

MAX_STEPS

Wrong Tool

Tool اشتباه انتخاب می‌شود.

راه‌حل:

Tool Description بهتر و Tool Set محدودتر.

Invalid Arguments

Agent پارامتر اشتباه ارسال می‌کند.

راه‌حل:

Schema Validation.

Hallucinated State

Agent تصور می‌کند عملی انجام شده در حالی که Tool اجرا نشده است.

راه‌حل:

فقط Tool Result واقعی State را تغییر دهد.

Premature Finish

Agent قبل از کامل شدن هدف Finish می‌کند.

راه‌حل:

Explicit Completion Criteria.

Excessive Autonomy

Agent بیش از حد اختیار دارد.

راه‌حل:

Permission، Risk Policy و Human Approval.

41. Agent Security

Agentها سطح حمله بیشتری نسبت به Chatbotهای ساده دارند، چون به Toolها و داده واقعی متصل هستند.

بنابراین باید مراقب موارد زیر بود:

• Prompt Injection
• Tool Abuse
• Unauthorized Actions
• Data Leakage
• Malicious Tool Output
• Indirect Prompt Injection

قاعده مهم:

محتوای دریافت‌شده از وب‌سایت، ایمیل، فایل یا Tool را Instruction معتبر سیستم فرض نکنید.

42. Permission باید بیرون از LLM باشد

مدل نباید تصمیم نهایی Permission را بگیرد.

مثلاً:

LLM:
User is probably allowed to refund this payment.

این کافی نیست.

Backend باید واقعاً بررسی کند:

RBAC
ABAC
Ownership
Financial Limits
Organization Policy

43. Deterministic Code و Agentic Decisions

یک اصل طراحی بسیار مهم:

LLM مناسب است برای:

• فهم زبان
• Classification
• Planning
• Tool Selection
• Summarization
• Flexible Decision Making

Code مناسب است برای:

• Permission
• Money Calculation
• Validation
• Hard Limits
• Database Transactions
• Security Rules

همه چیز نباید Agentic شود.

44. Single Agent یا Multi-Agent؟

بسیاری از پروژه‌ها با یک Agent به‌خوبی کار می‌کنند.

Multi-Agent زمانی معنا پیدا می‌کند که نقش‌های مستقل واقعی وجود داشته باشند.

مثلاً:

Research Agent
↓
Analysis Agent
↓
Verification Agent
↓
Execution Agent

اما Multi-Agent هزینه و پیچیدگی بیشتری ایجاد می‌کند.

بنابراین اصل خوب:

اگر یک Agent کافی است، Multi-Agent نسازید.

45. Agent Development Checklist

قبل از Production بررسی کنید:

• آیا Goal واضح است؟
• آیا Completion Criteria داریم؟
• آیا MAX_STEPS مشخص است؟
• آیا Toolها محدود و واضح هستند؟
• آیا Tool Inputها Validate می‌شوند؟
• آیا Permission بیرون از LLM بررسی می‌شود؟
• آیا State قابل اعتماد است؟
• آیا Memory کنترل‌شده است؟
• آیا Retry Limit داریم؟
• آیا Timeout داریم؟
• آیا عملیات حساس Approval دارند؟
• آیا Agent می‌تواند Ask کند؟
• آیا Agent می‌تواند Abstain کند؟
• آیا Agent می‌تواند Escalate کند؟
• آیا Logs کامل هستند؟
• آیا Cost Limit داریم؟
• آیا Failure Recovery تست شده است؟

46. مدل ذهنی نهایی

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

Goal
 ↓
Plan
 ↓
Observe
 ↓
Decide
 ↓
Use Tool
 ↓
Observe Result
 ↓
Update State / Memory
 ↓
Evaluate Progress
 ↓
Continue / Ask / Abstain / Escalate / Finish

این ساختار پایه تعداد زیادی از Agentهای مدرن است.

جمع‌بندی

AI Agent سیستمی است که برای رسیدن به یک هدف، چند مرحله تصمیم و عمل انجام می‌دهد.

Agent Loop چرخه Observe، Decide، Act و Evaluate است.

Planning هدف بزرگ را به مراحل کوچک‌تر تبدیل می‌کند.

Reasoning به Agent کمک می‌کند قدم بعدی مناسب را انتخاب کند.

Tool Calling Agent را به دنیای واقعی و APIها متصل می‌کند.

Memory اطلاعات لازم را بین مراحل یا Sessionها نگه می‌دارد.

Multi-step Tasks باعث می‌شوند Agent بتواند Workflow کامل اجرا کند.

و مهم‌تر از همه:

یک Agent قابل اعتماد فقط یک LLM با Tool نیست. Agent واقعی به State Management، Permission، Validation، Error Handling، Stop Conditions، Logging، Risk Control و در مواقع لازم Human Approval نیاز دارد.

پس از تسلط بر این مفاهیم، مرحله بعدی منطقی ورود عمیق‌تر به Agent Architecture است؛ یعنی ReAct، Planner-Executor، Reflection، Verification، Orchestration و طراحی معماری‌های حرفه‌ای Agent.