ایجنت هوش مصنوعی چیست؟ حلقه‌ای که همه‌چیز از آن ساخته می‌شود

چرا یک فراخوانی ساده‌ی مدل کافی نیست

از یک مدل زبانی بپرسید «وضعیت فاکتور ۴۸۲ چیست؟». مدل هر چقدر هم بزرگ باشد جواب درست ندارد؛ آن عدد در دیتابیس شماست، نه در وزن‌های مدل. یا می‌گوید نمی‌دانم، یا بدتر، چیزی سرِ هم می‌کند. ایجنت هوش مصنوعی دقیقاً برای پر کردن همین شکاف ساخته می‌شود: به‌جای اینکه از مدل انتظار دانستن داشته باشیم، به آن اجازه می‌دهیم کاری انجام دهد — کوئری بزند، API صدا کند، فایل بخواند — و بعد با نتیجه‌ی واقعی جواب بدهد.

این جمله ساده به نظر می‌رسد ولی یک تغییر معماری است. در حالت معمول، شما متن می‌فرستید و متن می‌گیرید: یک درخواست، یک پاسخ، تمام. در حالت ایجنتی، خروجی مدل می‌تواند به‌جای متن نهایی، یک درخواست اجرا باشد؛ و کسی باید آن درخواست را اجرا کند و نتیجه را برگرداند. هر چیزی که در ادامه درباره‌ی ایجنت می‌خوانید، از همین یک نکته بیرون می‌آید.

حلقه‌ای که اسمش ایجنت است

کل ایده در چهار گام خلاصه می‌شود: مدل تصمیم می‌گیرد → ابزاری را فرا می‌خواند → نتیجه برمی‌گردد → مدل دوباره تصمیم می‌گیرد. این حلقه تا وقتی می‌چرخد که مدل دیگر ابزاری نخواهد و جواب نهایی بدهد.

messages = [{"role": "user", "content": user_input}]

while True:
    response = model(messages, tools=TOOLS)
    messages.append(response)

    if not response.tool_calls:
        return response.text          # مدل ابزاری نخواست: حلقه تمام است

    for call in response.tool_calls:
        result = run_tool(call.name, call.arguments)
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": result,
        })

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

دو نکته‌ی مهم در این کد پنهان است. اول اینکه مدل خودش ابزار را اجرا نمی‌کند؛ فقط می‌گوید «این تابع را با این ورودی‌ها صدا بزن». اجرا کاملاً در کد شماست، پس کنترل و مسئولیت هم آنجاست. دوم اینکه نتیجه‌ی ابزار به‌عنوان یک پیام جدید به تاریخچه اضافه می‌شود؛ یعنی مدل در دور بعد، ورودی متفاوتی می‌بیند. همین «ورودی متفاوت در هر دور» است که به سیستم اجازه می‌دهد پیش برود، نه اینکه در جا بزند.

چه چیزی یک سیستم را ایجنت می‌کند

خیلی از چیزهایی که امروز ایجنت نامیده می‌شوند در واقع یک prompt طولانی‌اند. تفاوت را می‌شود با چهار معیار سنجید:

• تصمیم درباره‌ی گام بعدی با مدل است، نه با کد. اگر شما در کد نوشته‌اید «اول جستجو کن، بعد خلاصه کن، بعد ایمیل بفرست»، این یک workflow است و اتفاقاً چیز خوبی هم هست. در ایجنت، ترتیب و تعداد گام‌ها از قبل معلوم نیست.
• دسترسی به ابزار. بدون ابزار، مدل فقط می‌تواند حرف بزند. ابزار همان چیزی است که خروجی مدل را به اثر بیرونی وصل می‌کند.
• حالت در طول اجرا. ایجنت باید بداند تا حالا چه کرده و چه دیده. در ساده‌ترین شکل، همان آرایه‌ی messages است.
• شرط توقف. بدون آن، حلقه‌ای دارید که یا هزینه‌ی نامحدود می‌سازد یا در یک چرخه‌ی بی‌ثمر گیر می‌کند.

اگر هر چهار مورد را نداشتید، احتمالاً به چیزی ساده‌تر نیاز دارید و این خبر خوبی است.

یک درخواست، چند گام

فرض کنید کاربر می‌نویسد: «فاکتورهای پرداخت‌نشده‌ی این ماه را برایم خلاصه کن و اگر مبلغی بالای صد میلیون بود جدا بنویس.» مسیر معمول اجرا چیزی شبیه این است:

1. مدل تشخیص می‌دهد به داده نیاز دارد و list_invoices را با بازه‌ی تاریخ و وضعیت unpaid صدا می‌زند.
2. ابزار ۲۳ رکورد برمی‌گرداند. مدل می‌بیند فیلد مبلغ به ریال است، نه تومان.
3. مدل تصمیم می‌گیرد رکوردهای بالای آستانه را جدا کند — این گام هیچ ابزاری لازم ندارد و در خود مدل انجام می‌شود.
4. برای دو مورد، شناسه‌ی مشتری خالی است. مدل get_customer را برای آن دو صدا می‌زند.
5. مدل خلاصه‌ی نهایی را می‌نویسد و حلقه تمام می‌شود.

نکته این است که هیچ‌کس گام ۴ را از قبل برنامه‌ریزی نکرده بود. آن گام از دیدن داده‌ی واقعی بیرون آمد. اگر داده کامل بود، اصلاً اتفاق نمی‌افتاد. این انعطاف، همان چیزی است که بابتش هزینه می‌دهید — و در بخش بعد می‌بینید هزینه‌اش چیست.

شرط توقف، خطا و هزینه

حلقه‌ی ایجنتی سه جای شکست دارد که باید از روز اول برایشان فکر کرد:

گیر کردن در چرخه. مدل یک ابزار را با همان ورودی چند بار پشت‌سر هم صدا می‌زند. راه‌حل عملی، سقف گام است (مثلاً ۱۵ دور) به‌علاوه‌ی تشخیص فراخوانی تکراری. وقتی به سقف رسیدید، شکست را صریح اعلام کنید؛ نیمه‌کاره‌ی بی‌صدا بدترین حالت است.

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

رشد هزینه. در هر دور، کل تاریخچه دوباره فرستاده می‌شود. یعنی هزینه‌ی توکن با تعداد گام‌ها به‌صورت خطی رشد نمی‌کند، تقریباً درجه‌دو رشد می‌کند. ایجنتی که ده گام برمی‌دارد بسیار گران‌تر از ده برابرِ یک فراخوانی است. اینجا مدیریت context و prompt caching از تزئین به ضرورت تبدیل می‌شوند.

کجا به ایجنت نیاز ندارید

این بخش را جدی بگیرید، چون بیشتر پروژه‌های شکست‌خورده از همین‌جا شروع می‌شوند.

• وقتی مسیر ثابت است. «متن را بگیر، دسته‌بندی کن، در جدول بنویس» یک تابع است. ایجنت کردنش فقط تأخیر و عدم‌قطعیت اضافه می‌کند.
• وقتی خطا گران است و برگشت‌ناپذیر. انتقال وجه، حذف رکورد، ارسال به مشتری. اینها یا باید تأیید انسانی داشته باشند یا اصلاً در دست ایجنت نباشند.
• وقتی فقط به دانش نیاز دارید، نه به عمل. برای پاسخ از روی اسناد، معماری RAG ساده‌تر، ارزان‌تر و قابل‌ارزیابی‌تر از یک ایجنت کامل است.
• وقتی تأخیر مهم است. هر گام یک رفت‌وبرگشت شبکه است. ایجنت پنج‌گامی، پنج برابر تأخیر دارد.

قاعده‌ی ساده: اگر می‌توانید مسئله را با یک فراخوانی یا یک workflow ثابت حل کنید، همان را بسازید. ایجنت را وقتی بیاورید که ندانستن مسیر، خودِ مسئله باشد.

قبل از نوشتن اولین خط کد

چند چیز را روشن کنید، چون بعداً تغییرشان گران است:

• ایجنت به کدام ابزارها دسترسی دارد و هر کدام دقیقاً چه کاری می‌کنند؟ طراحی ابزار بیش از جمله‌بندی prompt روی کیفیت اثر دارد.
• کدام عمل‌ها بدون تأیید انسانی مجاز نیستند؟
• سقف گام و سقف هزینه‌ی هر اجرا چقدر است؟
• موفقیت را چطور می‌سنجید؟ بدون مجموعه‌ای از نمونه‌های واقعی، هر تغییری در prompt یک قمار است.

جمع‌بندی

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