عوامل هوش مصنوعی و استفاده از ابزار

سود:

• تعریف یک عامل به عنوان "مدل + ابزار + حلقه" و تصمیم گیری در مورد نیاز آن
• نوشتن تعریف ابزار با نام، توضیحات و input_schema
• نظارت بر جریان و رسیدگی به خطای حلقه tool_use و tool_result

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

نماینده چیست؟ مدل + ابزار + حلقه

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

تمایز مهم: یک فراخوانی تک الگو یک عامل نیست. عامل فرآیندی است که در آن مدل گام به گام پیش می رود و در هر مرحله حرکت بعدی را بر اساس نتیجه ابزار انتخاب می کند. "مثل یک انسان فکر کنید، از دستان خود استفاده کنید، به نتیجه نگاه کنید، دوباره فکر کنید."

یک واقعیت مهم: خود مدل وسیله نقلیه را راه اندازی نمی کند. مدل فقط می گوید "من می خواهم این ابزار را با این ورودی ها فراخوانی کنم". برنامه شما (به نام هارنس) ابزار را اجرا می کند و نتیجه را به مدل برمی گرداند. این برای امنیت حیاتی است: مدل مستقیماً سیستم شما را لمس نمی کند. هر اقدامی تحت کنترل شماست.

نکته: سعی نکنید هر مشکلی را با نماینده حل کنید. نماینده؛ خطر تاخیر، هزینه و خطا را افزایش می دهد. ابتدا بپرسید: "آیا این مشکل با یک تماس یا یک گردش کار ثابت حل می شود؟" اگر پاسخ مثبت است نیازی به نماینده نیست. Agent برای وظایف باز است که در آن مراحل نمی توان از قبل شناخته شد.

تعریف ابزار: نام، توضیحات، input_schema

برای معرفی یک ابزار به مدل، شما سه چیز را ارائه می دهید:

• نام: هویت وسیله نقلیه، به عنوان مثال. دریافت_آب و هوا.
• توضیحات: ابزار چه کاری انجام می دهد و چه زمانی باید آن را فراخوانی کرد. این مهم ترین قسمتی است که به مدل اجازه می دهد ابزار مناسب را در زمان مناسب انتخاب کند. نه فقط «چه می‌کند»، بلکه «زمان تماس» را نیز بنویسید.
• input_schema (طرحواره ورودی): طرح JSON که پارامترهایی را که ابزار انتظار دارد، در کدام نوع تعریف می کند.

# تعریف وسیله نقلیه (مفهومی - طرحواره JSON){ "name": "get_order_status"، "description": "وضعیت حمل و نقل فعلی یک سفارش را بازیابی می کند. زمانی که کاربر می پرسد شماره سفارش کجاست یا چه زمانی می رسد، تماس بگیرید." "description": "شماره سفارش، به عنوان مثال SP-1024"} }, "required": ["order_no"] }}

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

منطقه

چه کاری انجام می دهد؟

مثال خوب

مثال بد

نام

شناسه خودرو

order_status_getir

آوردن

توضیحات

چه کاری انجام می دهد + چه زمانی تماس بگیرید

"وضعیت محموله را برمی گرداند؛ هنگامی که کاربر از شما می پرسد سفارش کجاست، تماس بگیرید"

"واکشی داده ها"

input_schema

نوع پارامتر و نیاز

{order_no: رشته، حاشیه نویسی}

بدون نمودار / بدون شرح

tool_use → tool_result حلقه

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

1. شما سوال کاربر + توضیحات ابزار را برای مدل ارسال می کنید.
2. مدل یا مستقیما پاسخ می دهد یا یک بلوک tool_use ایجاد می کند: "call order_durumu_getir with order_no=SP-1024."
3. برنامه شما در واقع ابزار را اجرا می کند (پرس و جو از پایگاه داده).
4. شما نتیجه را به عنوان tool_result به مدل برمی‌گردانید.
5. با این نتیجه، مدل یا پاسخ نهایی را تولید می کند یا ابزار دیگری را فراخوانی می کند. این چرخه تا زمانی ادامه می‌یابد که مدل می‌گوید «تمام کردم».

# Agent loop (conceptual)messages = [user_question]while True: answer = model.uret(messages, tools=tool_definitions) if answer.tur == "tool_use": result = harness.run(response.tool_name, answer.entries) # APPLICATION [result breaks tools, result, results: results, otherrespons] =_____________ #پاسخ نهایی؛ حلقه به پایان می رسد

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

مدیریت خطا

ابزارها ممکن است شکست بخورند: سفارش یافت نشد، زمان API به پایان رسید، ورودی نامعتبر است. اگر نمی توانید ابزار را اجرا کنید، خطا را به عنوان یک tool_result توصیفی ("خطا: شماره سفارش SP-9999 یافت نشد") و پرچم خطا را به مدل برگردانید. مدل می تواند این را ببیند و به آرامی آن را برای کاربر توضیح دهد یا راه دیگری را امتحان کند. خطا را قورت ندهید و نتایج خالی را برگردانید. مدل باید بداند چه اشتباهی رخ داده است.

توضیحات خودرو ضعیف/قوی

ضعیف (اسم نامعین، بدون "وقتی"):

نام: "داده"، توضیحات: "داده ها را واکشی می کند"# مدل نمی داند چه زمانی و چگونه تماس بگیرد. یا اصلا زنگ نمی زند یا اشتباه زنگ می زند.

قوی (نام خالص + وقتی + توضیحات پارامتر):

name: "musteri_bakiyesi_getir"description: "موجودی حساب جاری مشتری را برمی‌گرداند. هنگامی که کاربر درخواست بدهی، اعتبار یا موجودی می‌کند، تماس بگیرید. پرداخت را انجام نمی‌دهد."input_schema: {custeri_id: string ("شناسه مشتری")}# مدل در زمان مناسب، با پارامترهای مناسب، با دانستن محدودیت‌های خود تماس می‌گیرد.

سه کیف کوچک

مورد 1 - عامل غیر ضروری. یک تیم تجارت «خلاصه متن» را با یک عامل چند ابزاری ایجاد کرد. هر خلاصه 4 تماس مدل و 9 ثانیه طول می کشد. کار در واقع یک کار تک تماسی بود. وقتی نماینده را حذف کردیم و آن را به یک تماس کاهش دادیم، زمان به 1.5 ثانیه کاهش یافت و هزینه به یک چهارم کاهش یافت. درس: در صورت لزوم از عامل استفاده کنید.

مورد 2 - توضیح ضعیف، تماس اشتباه. در یک عامل پشتیبانی، یک ابزار مبهم به نام واکشی به طور تصادفی توسط مدل در سؤال تعادل و سؤال حمل و نقل فراخوانی شد. هنگامی که وسایل نقلیه به balance_getir و cargo_durumu_getir تقسیم شدند و توضیحات "زمان تماس بگیرید" اضافه شد، انتخاب اشتباه خودرو از 18 به 1 در 50 نمونه کاهش یافت.

مورد 3 - خطا بلعیده شد. یک نماینده در حال بازگرداندن نتایج خالی بود که سفارش پیدا نشد. مدل این را به عنوان "سفارش تحویل داده شد" تفسیر کرد و مشتری را گمراه کرد. هنگامی که پیام خطا به صراحت در tool_result ("سفارش یافت نشد") نوشته می شود، مدل به درستی می گوید "من نتوانستم این شماره را پیدا کنم، می توانید آن را بررسی کنید؟" شروع کرد به گفتن

اشتباهات رایج

• تبدیل همه چیز به یک نماینده: در حالی که یک تماس کافی است، نماینده هزینه و تاخیر را اضافه می کند.
• توضیحات مبهم خودرو: مدل نمی داند چه زمانی تماس بگیرد. اشتباه انتخاب می کند
• فکر کردن به اینکه مدل وسیله نقلیه را اجرا می کند: مهار وسیله نقلیه را اجرا می کند. مدل فقط می خواهد
• بلعیدن خطا: مدل باید بداند چه اشتباهی رخ داده است. خطا را به عنوان open tool_result بدهید.
• تعداد زیاد وسایل نقلیه مشابه: مدل گیج می شود. مجموعه ابزار را متمرکز و حداقل نگه دارید.

توجه: فقط به این دلیل که مدل می گوید "به آن وسیله نقلیه زنگ بزن" به این معنی نیست که باید اقدام کرد. در ابزارهای مخرب (حذف، پرداخت، ایمیل) برنامه شما نباید کورکورانه تماس را اجرا کند - این هسته موضوع امنیتی در واحد بعدی است.

به طور خلاصه

• عامل = مدل (تصمیم) + ابزارها (توابع) + حلقه (ابزار فراخوانی، نتیجه گرفتن، دوباره تصمیم گیری).
• تماس با الگوی واحد یک عامل نیست. عامل یک فرآیند گام به گام است.
• مدل وسیله نقلیه را اجرا نمی کند. برنامه شما اجرا می شود (Harness) و نتیجه را به عنوان tool_result برمی گرداند.
• ابزار با نام، توضیحات (مخصوصاً «زمان تماس») و input_schema شناسایی می‌شود.
• حلقه به صورت tool_use ادامه می یابد. خطاها به صراحت به مدل گزارش می شوند.

وظیفه کاربردی

3 ابزار از کسب و کار خود طراحی کنید که می تواند در اختیار نماینده قرار گیرد. (1) نام، توضیحات را با "call when" و input_schema برای هر کدام بنویسید. بگذارید حداقل یکی ابزار خواندن غیر مخرب باشد و یکی محاسبات. (2) یک سوال واقعی کاربر را انتخاب کنید و به صورت دستی گام به گام (در یک حلقه) بنویسید که مدل کدام یک از این ابزارها را با کدام ورودی ها فراخوانی می کند و بعد از رسیدن tool_result چه کاری انجام می دهد. (3) سناریویی را تنظیم کنید که در آن یکی از ابزارها از کار بیفتد و نشان دهید که چگونه پیام خطا به مدل باز می گردد.

چک لیست

• [ ] من می توانم عامل را به عنوان "model + tools + loop" تعریف کنم و تصمیم بگیرم که چه زمانی به آن نیاز است.
• [ ] من می دانم که مهار وسیله نقلیه را اجرا می کند، مدل فقط آن را می خواهد.
• من می توانم یک توضیح کامل خودرو با نام [ ]، توضیحات ("زمان تماس") و input_schema بنویسم.
• من می توانم چرخه [ ] tool_use → tool_result را گام به گام دنبال کنم.
• [ ] من خطاهای ابزار را به عنوان open tool_result به مدل گزارش می کنم.