Wywoływanie narzędzi: projektowanie narzędzi, których agent używa dobrze
Gdy agent zachowuje się źle, odruchem jest przepisanie promptu. Z naszego doświadczenia prompt jest przyczyną może w jednej trzeciej przypadków; w pozostałych narzędzia zaprojektowano dla programu, a nie dla czytelnika, który z nazw i opisów musi wywnioskować, co robi funkcja.
Narzędzia to cała zdolność agenta do wpływania na świat, a ich definicje są dosłownie częścią kontekstu modelu.
Siedem reguł, które zapobiegają większości złych wywołań#
- Jedno narzędzie, jedno zadanie. `search_orders` i `refund_order` biją `manage_order` z trybem.
- Typy zamiast prozy. Wyliczenia, zakresy i formaty robią to, czego opis nigdy nie zrobi.
- Nazwy mówiące, co się stanie. `send_email_to_customer` jest jednoznaczne; `notify` nie.
- Błędy jako instrukcje: co poszło źle i co zrobić dalej, w jednym krótkim zdaniu.
- Puste wyniki to wyniki. Jawne nie-znaleziono bije wyjątek.
- Klucze idempotencji na wszystkim, co ma skutek uboczny.
- Małe zwroty. Przycinajcie do potrzebnych pól; 40 KB JSON kupuje zamęt.
Przed i po#
| Słaby projekt | Dlaczego się sypie | Lepiej |
|---|---|---|
| `query(sql)` | Nieograniczona moc, brak audytu | `get_orders_by_customer(customer_id, limit)` |
| `date: string` | Model zmyśla formaty | `date: string, format RRRR-MM-DD` |
| `HTTP 500` | Nie sugeruje działania, ponawiane bez końca | `Usługa zamówień niedostępna. Poproś klienta o późniejszą próbę.` |
| Zwraca cały rekord | Zapycha kontekst, rozrzedza uwagę | Zwraca sześć nazwanych pól |
| `update_status(id, status)` | Dowolny status, dowolny rekord | `cancel_order(id)` ze sprawdzeniem uprawnień |
Opisy to prompt#
Pole opisu to nie dokumentacja dla kolegów; to tekst, który model czyta, podejmując decyzję. Powiedzcie, kiedy używać narzędzia, a kiedy nie, wskażcie jeden istotny warunek wstępny i podajcie jeden przykład argumentu.
Jeśli dwa narzędzia mogą obsłużyć to samo żądanie, agent czasem wybierze źle.
Zawsze walidujcie przed wykonaniem#
Nigdy nie przekazujcie wyjścia modelu do wywołania systemowego bez sprawdzenia. Walidujcie argumenty wobec schematu, rozwiązujcie identyfikatory wobec rekordów widocznych dla tego użytkownika i odrzucajcie to, co nie pasuje, zamiast naginać.
Najczęstsze pytania
Ile narzędzi to za dużo?
Powyżej mniej więcej dziesięciu w jednej pętli trafność wyboru spada, a opisy zapychają kontekst.
Czy narzędzia mają zwracać surowe odpowiedzi API?
Nie. Zwracajcie małą, stabilną formę z polami, które są naprawdę potrzebne.
Jak zapobiec zmyślaniu argumentów?
Ograniczając je: wyliczenia zamiast wolnego tekstu, jawne formaty i identyfikatory, które muszą się rozwiązać.
wywoływanie narzędzifunction calling agenciprojekt narzędzijson schema narzędziabłędy narzędzi llm
