فاز 13 · درس 1

رابط ابزار در ایجنت‌های هوش مصنوعی و چرخه‌ی چهارمرحله‌ای آن

نوع
مفهومی
زمان
حدود 45 دقیقه
زبان‌ها
Python (stdlib, no LLM)
پیش‌نیاز
فاز 11 (APIهای تکمیل متن مدل‌های زبانی)
نمودار مینیمال و سه‌بعدی از یک مکعب شفاف با چهار سوئیچ نوری که به ترتیب روشن می‌شوند و به یک شکاف خروجی متصل هستند
فهرست مطالب
  1. اهداف یادگیری
  2. صورت مسئله
  3. مفاهیم کلیدی
  4. مرحله‌ی اول: توصیف (Describe)
  5. مرحله‌ی دوم: تصمیم (Decide)
  6. مرحله‌ی سوم: اجرا (Execute)
  7. مرحله‌ی چهارم: مشاهده (Observe)
  8. تفکیک سطح اعتماد
  9. چرخه کجا اجرا می‌شود؟
  10. چرا فقط به مدل پرامپت ندهیم که خودش JSON تولید کند؟
  11. مدارشکن‌ها (Circuit Breakers)
  12. نقشه‌ی ادامه‌ی مسیر در فاز 13
  13. استفاده از ابزارهای واقعی
  14. خروجی این درس
  15. تمرین‌ها
  16. اصطلاحات کلیدی
  17. برای مطالعه‌ی بیشتر

مدل‌های زبانی بزرگ ذهن متنی فوق‌العاده‌ای دارند، اما بدون رابط دست و پا ندارند. یک LLM نمی‌تواند به‌تنهایی درخواست HTTP ارسال کند، داده‌ای در دیتابیس ثبت کند یا دمای فعلی هوا را مستقیماً بخواند. برای پر کردن این شکاف اساسی، مفهومی به نام «رابط ابزار» (Tool Interface) معرفی شده که زبان مدل را به اقدام عملی در محیط برنامه متصل می‌کند.

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

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

یک مدل زبانی توکن تولید می‌کند و یک برنامه دست به اقدام می‌زند. فاصله‌ی میان این دو را «رابط ابزار» (Tool Interface) پر می‌کند: قراردادی که به مدل امکان می‌دهد درخواست انجام یک اقدام را بدهد و به میزبان اجازه می‌دهد آن را اجرا کند. تک‌تک استک‌های سال 2026 — از فراخوانی تابع (Function Calling) در OpenAI، Anthropic و Gemini گرفته تا tools/call در MCP و بخش‌های وظیفه در A2A — بازنمایی‌های متفاوتی از همین چرخه‌ی چهارمرحله‌ای هستند. در این درس این چرخه را نام‌گذاری می‌کنیم و حداقل سازوکار لازم برای اجرای آن را نشان می‌دهیم.

اهداف یادگیری

  • توضیح دهید چرا یک مدل زبانی بزرگ (LLM) که صرفاً توانایی تولید متن دارد، نمی‌تواند به‌تنهایی در دنیای واقعی دست به اقدام بزند.
  • چرخه‌ی چهارمرحله‌ای فراخوانی ابزار (توصیف ← تصمیم ← اجرا ← مشاهده) را رسم کنید و مشخص کنید مالکیت هر مرحله با کیست.
  • یک تعریف ابزار (Tool Definition) متشکل از چهار بخش بنویسید: نام، توضیحات، ورودی مبتنی بر اسکیمای JSON (JSON Schema) و یک تابع اجرایی قطعی.
  • ابزارهای محض (Pure) و دارای اثر جانبی (Side-effecting) را از یکدیگر تفکیک کنید و بگویید چرا این تمایز برای امنیت اهمیت دارد.

صورت مسئله

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

هدف رابط ابزار، پر کردن همین شکاف است. برنامه‌ی میزبان (Host) — یعنی محیط اجرای ایجنت (Agent runtime)، کلاینت Claude Desktop، چت‌بات ChatGPT، ویرایشگر Cursor یا یک اسکریپت سفارشی — فهرستی از ابزارهای قابل فراخوانی را به مدل معرفی می‌کند. مدل هروقت تشخیص دهد اقدامی لازم است، یک پی‌لود ساختاریافته شامل نام ابزار و آرگومان‌های آن تولید می‌کند. میزبان این پی‌لود را پارس کرده، ابزار را واقعاً اجرا می‌کند و نتیجه را دوباره به مدل بازمی‌گرداند. این چرخه تا جایی ادامه می‌یابد که مدل تشخیص دهد دیگر نیازی به فراخوانی نیست.

اولین نسخه‌ی این قرارداد در ژوئن 2023 با پارامتر «functions» در OpenAI عرضه شد. سپس Anthropic با بلوک‌های tool_use در Claude 2.1 به این مسیر پیوست. Gemini نیز چند ماه بعد functionDeclarations را اضافه کرد. امروزه تمام ارائه‌دهندگان ساختار مشابهی ارائه می‌دهند: ورودی فهرستی از ابزارها با اسکیمای JSON است و خروجی یک فراخوانی ابزار در قالب پی‌لود JSON. پروتکل زمینه مدل یا MCP (در نوامبر 2024) این قرارداد را تعمیم داد تا یک رجیستری ابزار واحد بتواند به تمام مدل‌ها سرویس دهد. استاندارد A2A (در آوریل 2026، نسخه‌ی 1.0) نیز همین مفهوم بنیادین را برای واگذاری وظایف میان ایجنت‌ها لایه‌بندی کرد.

این چرخه‌ی چهارمرحله‌ای، اصل تغییرناپذیر زیربنای تمام این سیستم‌هاست. هر مبحث دیگری در فاز 13 صرفاً بسط همین چرخه است.

مفاهیم کلیدی

مرحله‌ی اول: توصیف (Describe)

میزبان هر ابزار را با سه فیلد به مدل معرفی می‌کند. بخش چهارم، یعنی مجری (Executor)، سمت میزبان باقی می‌ماند و هرگز به دست مدل نمی‌رسد.

  • نام (Name). یک شناسه‌ی پایدار و ماشین‌خوان؛ مثل get_weather، نه «weather thing».
  • توضیحات (Description). متنی کوتاه در حد یک پاراگراف به زبان طبیعی؛ مثلاً: «وقتی کاربر وضعیت فعلی آب‌وهوای یک شهر خاص را می‌پرسد از این ابزار استفاده کن. برای داده‌های تاریخی استفاده نشود.»
  • اسکیمای ورودی (Input schema). یک شیء اسکیمای JSON (پیش‌نویس 2020-12) که آرگومان‌های ابزار را توصیف می‌کند.

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

مرحله‌ی دوم: تصمیم (Decide)

مدل بر اساس پیام کاربر و ابزارهای دردسترس، یکی از سه رفتار زیر را انتخاب می‌کند:

  1. پاسخ مستقیم متنی. هیچ ابزاری فراخوانی نمی‌شود.
  2. فراخوانی یک یا چند ابزار. اشیای فراخوانی ساختاریافته تولید می‌شوند. در صورت فعال بودن parallel_tool_calls: true (که در OpenAI و Gemini به‌طور پیش‌فرض فعال و در Anthropic اختیاری است)، مدل می‌تواند در یک نوبت گفت‌وگو چندین فراخوانی صادر کند.
  3. امتناع (Refuse). خروجی‌های ساختاریافته در حالت سخت‌گیرانه (Strict mode) می‌توانند به‌جای فراخوانی، یک بلوک تایپ‌شده‌ی refusal تولید کنند.

پی‌لود فراخوانی ابزار سه فیلد ثابت دارد: شناسه‌ی فراخوانی (id)، نام ابزار (name) و شیء آرگومان‌ها (arguments) در قالب JSON. وجود شناسه برای این است که میزبان بتواند خروجی بعدی را به همان فراخوانی مشخص ربط دهد؛ این کار هنگام بازگشت نامرتب فراخوانی‌های موازی بسیار اهمیت دارد.

مرحله‌ی سوم: اجرا (Execute)

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

خود مجری یک کد معمولی است؛ پایتون، تایپ‌اسکریپت، دستور شل یا کوئری دیتابیس. مجری نتیجه‌ای تولید می‌کند که معمولاً یک رشته است، اما می‌تواند هر مقدار JSON یا یک بلوک محتوای ساختاریافته (متن، تصویر یا ارجاع به منبع در MCP) باشد. نتیجه در هر حال باید قابل سریال‌سازی باشد.

مرحله‌ی چهارم: مشاهده (Observe)

میزبان نتیجه‌ی ابزار را به مکالمه اضافه می‌کند (به‌عنوان پیامی با نقش tool و شناسه‌ی id منطبق) و مدل را دوباره فرا می‌خواند. اکنون مدل خروجی ابزار را در کانتکست خود دارد و می‌تواند پاسخ نهایی را تولید کند یا درخواست فراخوانی‌های بیشتری بدهد. این فرآیند تا زمانی ادامه می‌یابد که مدل دست از فراخوانی بردارد یا میزبان به سقف ایمنی شمارش تکرارها برسد.

تفکیک سطح اعتماد

ابزارها از نظر ایمنی به دو دسته‌ی مهم تقسیم می‌شوند:

  • محض (Pure). فقط‌خواندنی، قطعی و فاقد اثر جانبی؛ مثل get_weather، search_docs و get_current_time. اجرای حدسی و پیش‌دستانه‌ی آن‌ها بی‌خطر است.
  • دارای پیامد (Consequential). وضعیت را تغییر می‌دهند، هزینه مالی دارند یا به داده‌های کاربر دست می‌زنند؛ مثل send_email، delete_file و execute_trade. اجرای این ابزارها حتماً باید کنترل‌شده باشد.

«قاعده‌ی دوگانه» شرکت Meta در سال 2026 برای امنیت ایجنت‌ها می‌گوید در یک نوبت گفت‌وگو حداکثر دو مورد از این سه ویژگی می‌توانند هم‌زمان وجود داشته باشند: ورودی نامطمئن، داده‌های حساس و اقدام دارای پیامد. رابط ابزار دقیقاً همان نقطه‌ای است که باید این قاعده را در آن پیاده کنید — با رد درخواست‌ها، الزام به تأیید کاربر، یا ارتقای دامنه‌ها (Escalating scopes). برای مطالعه‌ی کامل مباحث امنیتی به فاز 13 · 15 و برای سیاست‌های مجوزدهی در سطح ایجنت به فاز 14 · 09 مراجعه کنید.

چرخه کجا اجرا می‌شود؟

بستر چه کسی توصیف می‌کند چه کسی تصمیم می‌گیرد چه کسی اجرا می‌کند
فراخوانی تابع تک‌نوبتی (OpenAI/Anthropic/Gemini) توسعه‌دهنده‌ی برنامه LLM توسعه‌دهنده‌ی برنامه
MCP سرور MCP مدل LLM از طریق کلاینت MCP سرور MCP
A2A ناشر شناسنامه‌ی ایجنت (Agent Card) ایجنت فراخوان ایجنت فراخوانده‌شده
مرورگر وب (ایجنت مجهز به فراخوانی تابع) افزونه‌ی مرورگر / WebMCP LLM محیط اجرای مرورگر

این چهار مرحله در همه‌جا یکسان است؛ نام ستون‌ها تغییر می‌کند، اما ساختار تغییری نمی‌کند.

چرا فقط به مدل پرامپت ندهیم که خودش JSON تولید کند؟

الگوی قبل از فراخوانی تابع این بود: «از مدل بخواهید با JSON پاسخ دهد». این روش در مدل‌های پیشرو حدود 5 تا 15 درصد مواقع و در مدل‌های کوچک‌تر بسیار بیشتر شکست می‌خورد. حالت‌های شکست شامل جا انداختن آکولادها، ویرگول‌های اضافه در انتها، فیلدهای ساختگی و نوع‌های اشتباه است. در نتیجه به یک مرحله‌ی ترمیم JSON، تلاش مجدد یا یک دیکودر مقید نیاز پیدا خواهید کرد.

فراخوانی بومی تابع به سه دلیل بهتر است: اول اینکه ارائه‌دهنده، مدل را به‌صورت سرتاسری روی ساختار دقیق فراخوانی آموزش می‌دهد؛ بنابراین نرخ تولید JSON معتبر در حالت سخت‌گیرانه (Strict mode) به 98 تا 99 درصد می‌رسد. دوم اینکه پی‌لود فراخوانی در جایگاه پروتکلی مجزایی قرار می‌گیرد، نه درون متن آزاد؛ در نتیجه فراخوانی ابزار هرگز وارد پاسخ نهایی کاربر نمی‌شود. سوم اینکه ارائه‌دهندگان تطابق با اسکیما (Schema Compliance) را با استفاده از دیکود مقید (Constrained Decoding) تضمین می‌کنند (مثل Strict mode در OpenAI، بلوک tool_use در Anthropic و responseSchema در Gemini)؛ بنابراین خروجی قطعاً اعتبارسنجی خواهد شد.

در فاز 13 · 02 کار با API این سه ارائه‌دهنده را کنار هم بررسی می‌کنیم و در فاز 13 · 04 عمیقاً وارد خروجی‌های ساختاریافته (Structured Output) می‌شویم.

مدارشکن‌ها (Circuit Breakers)

چرخه زمانی پایان می‌یابد که مدل دست از فراخوانی بکشد یا شمار نوبت‌های اجرای میزبان به سقف مشخصی برسد. سیستم‌های پروداکشن این سقف را بین 5 تا 20 نوبت تنظیم می‌کنند. فراتر از این مقدار، تقریباً شک نکنید که مدل در حلقه‌ای افتاده که توان خروج از آن را ندارد. پیش‌فرض Claude Code روی 20، ابزار Assistants در OpenAI روی 10 و حالت ایجنت در Cursor روی 25 تنظیم شده است.

نتیجه‌ی بی‌توجهی به این موضوع — یعنی حلقه‌های نامحدود — همان گزارش‌های کالبدشکافی است که هر شش ماه یک‌بار با عنوان «ایجنت دیشب 400 دلار هزینه‌ی API روی دستمان گذاشت» منتشر می‌شود. هرگز پروژه‌ای را بدون محدودیت بالا نیاورید.

فاز 14 · 12 بازیابی خطاها و خودترمیمی را دقیق بررسی می‌کند و فاز 17 به محدودیت‌های نرخ درخواست در محیط‌های عملیاتی می‌پردازد.

نقشه‌ی ادامه‌ی مسیر در فاز 13

  • درس‌های 02 تا 05 کار با رابط فراخوانی ابزار در سطح ارائه‌دهندگان را صیقل می‌دهند.
  • درس‌های 06 تا 14 این چرخه را به پروتکل MCP تعمیم می‌دهند.
  • درس‌های 15 تا 18 از این چرخه در برابر سرورهای مخرب، کاربران مهاجم و سطوح احراز هویت ناامن در مخزن راه‌دور محافظت می‌کنند.
  • درس‌های 19 تا 22 این الگو را به همکاری ایجنت با ایجنت، مشاهده‌پذیری، مسیریابی و بسته‌بندی گسترش می‌دهند.
  • درس 23 با ترکیب تمام این مفاهیم اولیه، یک اکوسیستم کامل ارائه می‌دهد.

تمامی درس‌های باقی‌مانده بسط همین چرخه‌ی چهارمرحله‌ای هستند. آن را به‌عنوان یک اصل تغییرناپذیر به ذهن بسپارید.

حلقه ابزارتوصیف، تصمیم، اجرا و مشاهده
TOOL LOOPEvery tool-calling stack runs the same four-step loop. The host describes the tools, the model decides which to call, the host executes it for real, and the model observes the result before the next turn. The packet circles because the loop repeats until the model needs no more calls.DESCRIBEمیزبانDECIDEمدلEXECUTEمیزبانOBSERVEمدل
هر پشته فراخوانی ابزار، همین حلقه چهارمرحله‌ای را اجرا می‌کند. میزبان ابزارها را توصیف می‌کند، مدل تصمیم می‌گیرد کدام را فراخوانی کند، میزبان آن را در عمل اجرا می‌کند، و مدل پیش از نوبت گفت‌وگوی بعدی نتیجه را مشاهده می‌کند. بسته در یک چرخه می‌گردد زیرا حلقه تا زمانی که مدل دیگر نیازی به فراخوانی نداشته باشد، تکرار می‌شود.

استفاده از ابزارهای واقعی

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

به این نکات دقت کنید:

  • رجیستری ابزار برای هر مورد چهار فیلد نگه می‌دارد: نام، توضیحات، اسکیما و ارجاع به مجری. فقط سه مورد اول به مدل ارسال می‌شوند.
  • اعتبارسنج، زیرمجموعه‌ی کوچکی از اسکیمای JSON است (نوع داده‌ها، فیلدهای اجباری، enum و حداقل/حداکثر) که صرفاً با کتابخانه‌ی استاندارد پایتون نوشته شده است. فاز 13 · 04 نسخه‌ی کامل‌تری از آن را ارائه می‌دهد.
  • چرخه‌ی برنامه سقف تکرار را روی عدد 5 می‌بندد. ایجنت‌های سطح پروداکشن دقیقاً به چنین مدارشکنی نیاز دارند.

خروجی این درس

خروجی این درس فایل outputs/skill-tool-interface-reviewer.md است. این مهارت با دریافت پیش‌نویس تعریف یک ابزار (نام + توضیحات + اسکیما + طرح کلی مجری)، آن را از نظر تناسب برای چرخه ارزیابی می‌کند: آیا نام برای سیستم‌ها پایدار است؟ آیا توضیحات یک راهنمای کاربردی کامل است؟ آیا اسکیما از استاندارد JSON Schema 2020-12 به‌درستی استفاده می‌کند؟ و آیا تفکیک ابزار به محض یا دارای پیامد تصریح شده است؟

تمرین‌ها

  1. ابزار چهارمی به نام get_stock_price(ticker) به فایل code/main.py اضافه کنید. توضیحات آن را این‌گونه بنویسید: «وقتی کاربر قیمت لحظه‌ای سهام را بر اساس نماد بورسی می‌پرسد از این ابزار استفاده کن. برای قیمت‌های تاریخی یا خلاصه وضعیت بازار استفاده نشود.» برنامه را اجرا کرده و مطمئن شوید تصمیم‌گیر ساختگی، پرسش‌های حاوی نماد سهم را به این ابزار جدید هدایت می‌کند.

  2. اعتبارسنج اسکیما را عمداً با خطا مواجه کنید. فراخوانی‌ای بفرستید که فیلد اجباری شیء arguments در آن جا افتاده باشد و ببینید میزبان چطور قبل از اجرا جلوی آن را می‌گیرد. سپس فراخوانی دیگری با یک فیلد ناشناخته‌ی اضافه ارسال کنید. تصمیم بگیرید: آیا میزبان باید آن را رد کند یا نادیده بگیرد؟ انتخاب خود را با یک دلیل امنیتی توجیه کنید.

  3. تک‌تک ابزارهای موجود در بستر را در دسته‌ی محض یا دارای پیامد طبقه‌بندی کنید. فلگ consequential: true را به موارد لازم در رجیستری اضافه کرده و چرخه را طوری تغییر دهید که هروقت ابزاری با این مشخصه انتخاب شد، پیام «would confirm with user» را چاپ کند. این گیت تأیید دقیقاً همان چیزی است که تمام سیستم‌های عملیاتی به آن نیاز دارند.

  4. چرخه‌ی چهارمرحله‌ای را روی کاغذ رسم کنید و جدول ارائه‌دهندگان بالا را برای کلاینت موردعلاقه‌ی خود (Claude Desktop، Cursor، ChatGPT یا استک اختصاصی خودتان) پر کنید. نتیجه را با نمونه‌ی اختصاصی MCP در فاز 13 · 06 مقایسه کنید.

  5. راهنمای فراخوانی تابع در OpenAI را از ابتدا تا انتها بخوانید. آن فیلدی را که در درخواست وجود دارد ولی در چرخه‌ی چهارمرحله‌ای این درس نیامده پیدا کنید. توضیح دهید این فیلد چه کاربردی دارد و چرا صرفاً یک امکان تسهیل‌کننده است نه یک بخش حیاتی.

اصطلاحات کلیدی

اصطلاح برداشتی که رایج است معنای واقعی آن
ابزار (Tool) «چیزی که مدل می‌تواند صدا بزند» سه‌گانه‌ای متشکل از نام + ورودی با نوع‌بندی اسکیمای JSON + تابع اجرایی
فراخوانی تابع (Function calling) «استفاده‌ی توکار از ابزار» پشتیبانی API در سطح ارائه‌دهنده برای تولید فراخوانی‌های ابزار ساختاریافته به‌جای متن معمولی
فراخوانی ابزار (Tool call) «درخواست اقدام از طرف مدل» یک پی‌لود JSON شامل id، name و arguments که مدل صادر می‌کند
نتیجه‌ی ابزار (Tool result) «خروجی‌ای که ابزار برگرداند» خروجی مجری در قالب پیامی با نقش tool و شناسه‌ی منطبق
فراخوانی موازی ابزار (Parallel tool calls) «چند فراخوانی هم‌زمان» چندین شیء فراخوانی مستقل در یک نوبت مدل که با شناسه مرتب می‌شوند
حالت سخت‌گیرانه (Strict mode) «JSON تضمین‌شده» دیکود مقید که خروجی مدل را وادار به تطابق با اسکیمای اعلام‌شده می‌کند
ابزار محض (Pure tool) «ابزار فقط‌خواندنی» فاقد اثر جانبی؛ تکرار اجرای آن کاملاً امن است
ابزار دارای پیامد (Consequential tool) «ابزار دست به عمل» وضعیت بیرونی را تغییر می‌دهد؛ نیازمند گیت کنترلی، بازرسی یا تأیید کاربر است
چرخه‌ی چهارمرحله‌ای (Four-step loop) «چرخه‌ی فراخوانی ابزار» توصیف ← تصمیم ← اجرا ← مشاهده
میزبان (Host) «محیط اجرای ایجنت» برنامه‌ای که رجیستری ابزار را نگه می‌دارد، مدل را فرا می‌خواند و مجری را اجرا می‌کند

برای مطالعه‌ی بیشتر

سؤالات متداول

چرا مدل زبانی نمی‌تواند مستقیماً کارها را در دنیای واقعی انجام دهد؟

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

چرخه‌ی چهارمرحله‌ای ابزار شامل چه مراحلی است؟

این چرخه شامل چهار گام پایدار است: توصیف (اعلام نام و اسکیمای ورودی ابزار به مدل)، تصمیم (انتخاب ابزار توسط مدل)، اجرا (اعتبارسنجی و اجرای کد روی میزبان) و مشاهده (برگرداندن نتیجه به کانتکست مدل).

تفاوت ابزار محض (Pure) با ابزار دارای پیامد (Consequential) چیست؟

ابزارهای محض فقط‌خواندنی، بدون اثر جانبی و کاملاً قطعی هستند (مانند دریافت ساعت فعلی)، در حالی که ابزارهای دارای پیامد می‌توانند داده‌ها را تغییر دهند، هزینه مالی بسازند یا پیامی ارسال کنند و نیازمند سازوکار تأیید کاربر یا گیت‌های امنیتی هستند.

چرا استفاده از پرامپت ساده برای خروجی JSON کافی نیست و به Function Calling بومی نیاز داریم؟

در پرامپت معمولی خطاهایی مثل ویرگول اضافه، اسکیپ نشدن کاراکترها و کلیدهای ساختگی بین 5 تا 15 درصد در مدل‌های قوی رخ می‌دهد؛ در حالی که ارائه‌دهندگان در حالت بومی با دیکودینگ مقید و آموزش اختصاصی، تولید JSON معتبر و بدون نشت به پاسخ کاربر را تا نزدیک 99 درصد تضمین می‌کنند.

ما رو توی گوگل بیشتر ببین

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