Печалби:
- Дефиниране на агент като „модел + инструменти + цикъл“ и решаване кога е необходим
- Написване на дефиницията на инструмента с име, описание и input_schema
- Наблюдение на потока и обработката на грешките на цикъла tool_use и tool_result
Досега моделът винаги е вършил една работа: получаване на въвеждане на текст, създаване на текстови отговори. Но истинската работа често изисква повече от текст; извършване на изчисление, запитване към база данни, извикване на API, откриване на текущ обменен курс. Моделът не може да направи тези неща сам - но тя може да реши кога трябва да бъдат направени и да помоли някой да ги направи. Това е, което използването на инструмента дава на модела и това е основата на AI агентите. В тази част ще научим какво е агент, как се дефинира инструментът и как работи цикълът tool_use.
Какво е агент? Модел + Инструменти + Примка
AI агентът се състои от три части: моделът (мозъкът, който взема решението), инструментите (функциите, които моделът може да извика: прогноза за времето, заявка в базата данни, изпращане на имейл) и цикълът (цикълът; моделът извиква инструмента, получава резултата, решава отново какво да прави и т.н.).
Критично разграничение: Едно извикване на шаблон не е агент. Агентът е процес, при който моделът върви стъпка по стъпка, като на всяка стъпка избира следващия ход въз основа на резултата от инструмента. "Мислете като човек, използвайте ръцете си, вижте резултата, помислете отново."
Важен факт: Самият модел не управлява автомобила. Моделът просто казва „Искам да извикам този инструмент с тези входове“. Вашето приложение (наречено сбруя) изпълнява инструмента и връща резултата към модела. Това е жизненоважно за сигурността: моделът не докосва директно вашата система; Всяко действие е под ваш контрол.
Съвет: Не се опитвайте да разрешите всеки проблем с агента. агент; увеличава риска от забавяния, разходи и грешки. Първо попитайте: „Това ще бъде ли решено с едно обаждане или с фиксиран работен процес?“ Ако отговорът е да, няма нужда от агент. Агентът е за задачи с отворен край, при които стъпките не могат да бъдат известни предварително.
Дефиниция на инструмента: име, описание, input_schema
За да въведете инструмент в модела, вие давате три неща:
- име: Идентификация на превозното средство, напр. get_weather.
- описание: Какво прави инструментът и кога да го извикате. Това е най-важната област, която позволява на модела да избере правилния инструмент в точното време. Напишете не само „какво прави“, но и „кога се обадете“.
- input_schema (входна схема): JSON схема, която определя кои параметри очаква инструментът, в кой тип.
# Дефиниция на превозно средство (концептуална — JSON схема){ "name": "get_order_status", "description": "Извлича текущия статус на доставка на поръчка. Обажда се, когато потребителят попита къде е номерът на поръчката или кога ще пристигне.", "input_schema": { "type": "object", "properties": { "order_no": {"type": "string", "description": "Номер на поръчка, напр. SP-1024"} }, "задължително": ["order_no"] }}
Правила за добро описание на инструмента: ясно и кратко име, описание с „кога да се използва“, описание за всеки параметър, поставяне на наистина задължителните в задължителните. Поддържайте фокус върху броя на превозните средства; Десетки подобни модели превозни средства са изненадващи.
площ
Какво прави?
добър пример
лош пример
име
ID на превозното средство
получаване_статус на поръчка
донеси
описание
Какво прави + кога да се обадя
„Връща статуса на товара; обадете се, когато потребителят попита къде е поръчката“
"извлича данни"
входна_схема
Тип параметър и изискване
{order_no: низ, анотирано}
без диаграма / без описание
tool_use → tool_result Loop
Цикълът работи по следния начин, стъпка по стъпка:
- Изпращате потребителския въпрос + описания на инструмента към модела.
- Моделът или отговаря директно, или генерира tool_use блок: "извикване на order_durumu_getir с order_no=SP-1024."
- Вашето приложение всъщност изпълнява инструмента (запитва базата данни).
- Изпращате резултата обратно към модела като tool_result.
- С този резултат моделът или произвежда окончателния отговор, или извиква друг инструмент. Цикълът продължава, докато моделът каже „Готово съм“.
# Agent loop (conceptual)messages = [user_question]while True: response = model.uret(messages, tools=tool_definitions) if response.tur == "tool_use": result = harness.run(response.tool_name, response.entries) # ПРИЛОЖЕНИЕТО изпълнява съобщения += [response, tool_result(result)] # връща резултат else: break # окончателен отговор; цикъл завършва
Съвременните комплекти за разработване на софтуер (SDK) предлагат инструменти за изпълнение, които изпълняват този цикъл вместо вас; просто пишете функциите на инструмента. Но точно това се случва зад кулисите.
Управление на грешки
Инструментите може да се провалят: поръчката не е намерена, API изтече, въвеждането е невалидно. Ако не можете да стартирате инструмента, върнете грешката към модела като описателен tool_result („грешка: Номер на поръчката SP-9999 не е намерен“) и флага за грешка. Моделът може да види това и внимателно да го обясни на потребителя или да опита по различен начин. Не преглъщайте грешката и не връщайте празни резултати; Моделът трябва да знае какво се е объркало.
Слабо/силно описание на превозното средство
Слаб (неопределено съществително, без „кога“):
име: "данни", описание: "извлича данни"# Моделът не знае кога и как да извика; Или изобщо не звъни, или звъни неправилно.
Силен (нетно име + кога + описание на параметъра):
име: "musteri_bakiyesi_getir"описание: "Връща текущото салдо по сметката на клиент. Обадете се, когато потребителят поиска дебит, кредит или салдо. НЕ ИЗВЪРШВА плащане."input_schema: {custeri_id: низ ("Идентификационен номер на клиента")}# Моделът се обажда в точното време, с правилните параметри, знаейки своя лимит.
Три мини калъфа
Случай 1 — Ненужен агент. Един екип изгради бизнеса с „резюмиране на текст“ с агент с множество инструменти; Всяко обобщение отнема 4 обаждания на модел и 9 секунди. Работата всъщност беше работа с едно повикване. Когато премахнахме агента и го намалихме до едно обаждане, времето намаля до 1,5 секунди, а цената намаля до една четвърт. Урок: използвайте агента, когато наистина е необходимо.
Случай 2 — Слабо обяснение, грешно обаждане. В агент за поддръжка, неясен инструмент, наречен fetch, беше извикан на случаен принцип от модела както във въпроса за баланс, така и във въпроса за доставка. Когато превозните средства бяха разделени на balance_getir и cargo_durumu_getir и бяха добавени обяснения „обадете се, когато“, грешният избор на превозно средство намаля от 18 на 1 на 50 примера.
Случай 3 — Грешка е погълната. Агент връщаше празни резултати, когато поръчката не беше намерена; Моделът изтълкува това като "поръчката е доставена" и подведе клиента. Когато съобщението за грешка е написано изрично в tool_result ("поръчката не е намерена"), моделът правилно казва "Не можах да намеря този номер, можете ли да го проверите?" започна да казва той.
Често срещани грешки
- Обръщане на всичко към агент: Докато едно обаждане е достатъчно, агентът добавя разходи и забавяне.
- Неясно описание на автомобила: Моделът не знае кога да се обади; избира грешно.
- Мислейки, че моделът управлява превозното средство: Сбруята управлява превозното средство; моделът просто иска.
- Преглъщане на грешката: Моделът трябва да знае какво се е объркало; Дайте грешката като open tool_result.
- Твърде много подобни превозни средства: Моделът се обърква; Поддържайте набора от инструменти фокусиран и минимален.
Внимание: Само защото моделът казва „обадете се на това превозно средство“ не означава, че трябва да се предприемат действия. При разрушителни инструменти (изтриване, плащане, имейл) вашето приложение не трябва да изпълнява сляпо повикването - това е сърцевината на темата за сигурността в следващия раздел.
В обобщение
- Агент = модел (решение) + инструменти (функции) + цикъл (инструмент за извикване, получаване на резултат, решаване отново).
- Едно извикване на шаблон не е агент; агент е процес стъпка по стъпка.
- Моделът не управлява автомобила; Вашето приложение се изпълнява (впрегне) и връща резултата като tool_result.
- Инструментът се идентифицира по име, описание (по-специално „извикване, когато“) и input_schema.
- Цикълът продължава като tool_use → harness работи → tool_result → model продължава, докато моделът каже „готово“; грешките се съобщават изрично на модела.
Задача за приложение
Проектирайте 3 инструмента от вашия собствен бизнес, които могат да бъдат дадени на агента. (1) Напишете име, описание с „повикване, когато“ и input_schema за всеки; Нека поне един да е инструмент за неразрушително четене и един да е изчисление. (2) Изберете реалистичен потребителски въпрос и ръчно напишете стъпка по стъпка (в цикъл) кой от тези инструменти моделът ще извика с какви входове и какво ще направи след пристигането на tool_result. (3) Настройте сценарий, при който един от инструментите се проваля и покажете как съобщението за грешка ще се върне към модела.
контролен списък
- [ ] Мога да дефинирам агента като „модел + инструменти + цикъл“ и да реша кога е необходим.
- [ ] Знам, че коланът управлява превозното средство, моделът просто го иска.
- Мога да напиша солидно описание на превозното средство с [ ] име, описание („повикване, когато“) и input_schema.
- Мога да следвам цикъла [ ] tool_use → tool_result стъпка по стъпка.
- [ ] Докладвам грешки в инструмента на модела като отворен tool_result.