Μονάδα 9 / 11

Πράκτορες AI και χρήση εργαλείων

Κέρδη:

  • Ορισμός ενός πράκτορα ως «μοντέλο + εργαλεία + βρόχος» και απόφαση πότε χρειάζεται
  • Γράψτε τον ορισμό του εργαλείου με όνομα, περιγραφή και input_schema
  • Παρακολούθηση της ροής και του χειρισμού σφαλμάτων του βρόχου tool_use και tool_result

Μέχρι τώρα, το μοντέλο έκανε πάντα μια δουλειά: λήψη εισαγωγής κειμένου, παραγωγή απαντήσεων κειμένου. Αλλά η πραγματική δουλειά απαιτεί συχνά περισσότερα από κείμενο. εκτέλεση υπολογισμού, αναζήτηση μιας βάσης δεδομένων, κλήση ενός API, εύρεση τρέχουσας συναλλαγματικής ισοτιμίας. Το μοντέλο δεν μπορεί να κάνει αυτά τα πράγματα μόνη της — αλλά μπορεί να αποφασίσει πότε πρέπει να γίνουν και να ζητήσει από κάποιον να τα κάνει. Αυτό δίνει στο μοντέλο η χρήση εργαλείου και αυτή είναι η βάση των πρακτόρων AI. Σε αυτή την ενότητα, θα μάθουμε τι είναι ένας πράκτορας, πώς ορίζεται το εργαλείο και πώς λειτουργεί ο βρόχος tool_use.

Τι είναι ο Πράκτορας; Μοντέλο + Εργαλεία + Βρόχος

Ένας πράκτορας AI αποτελείται από τρία μέρη: το μοντέλο (ο εγκέφαλος που παίρνει την απόφαση), τα εργαλεία (τις λειτουργίες που μπορεί να καλέσει το μοντέλο: καιρός, ερώτημα βάσης δεδομένων, αποστολή email) και το βρόχο (ο βρόχος, το μοντέλο καλεί το εργαλείο, παίρνει το αποτέλεσμα, αποφασίζει ξανά τι να κάνει κ.λπ.).

Κρίσιμη διάκριση: Μια κλήση μεμονωμένου μοτίβου δεν είναι πράκτορας. Ο παράγοντας είναι μια διαδικασία στην οποία το μοντέλο προχωρά βήμα προς βήμα, σε κάθε βήμα επιλέγοντας την επόμενη κίνηση με βάση το αποτέλεσμα του εργαλείου. «Σκέψου σαν άνθρωπος, χρησιμοποίησε τα χέρια σου, κοίτα το αποτέλεσμα, ξανασκέψου».

Ένα σημαντικό γεγονός: Το ίδιο το μοντέλο δεν λειτουργεί το όχημα. Το μοντέλο λέει απλώς "Θέλω να καλέσω αυτό το εργαλείο με αυτές τις εισόδους". Η εφαρμογή σας (που ονομάζεται πλεξούδα) εκτελεί το εργαλείο και επιστρέφει το αποτέλεσμα στο μοντέλο. Αυτό είναι ζωτικής σημασίας για την ασφάλεια: το μοντέλο δεν αγγίζει απευθείας το σύστημά σας. Κάθε ενέργεια είναι υπό τον έλεγχό σας.

Συμβουλή: Μην προσπαθείτε να λύσετε κάθε πρόβλημα με τον πράκτορα. Μέσο; αυξάνει τον κίνδυνο καθυστερήσεων, κόστους και σφαλμάτων. Ρωτήστε πρώτα: "Θα λυθεί αυτό με μία μόνο κλήση ή μια σταθερή ροή εργασίας;" Εάν η απάντηση είναι ναι, δεν υπάρχει ανάγκη για πράκτορα. Το Agent είναι για εργασίες ανοιχτού τύπου όπου τα βήματα δεν είναι γνωστά εκ των προτέρων.

Ορισμός εργαλείου: όνομα, περιγραφή, input_schema

Για να εισάγετε ένα εργαλείο στο μοντέλο, δίνετε τρία πράγματα:

  • όνομα: Ταυτότητα οχήματος, π.χ. get_weather.
  • περιγραφή: Τι κάνει το εργαλείο και πότε να το καλέσετε. Αυτή είναι η πιο σημαντική περιοχή που επιτρέπει στο μοντέλο να επιλέξει το σωστό εργαλείο την κατάλληλη στιγμή. Γράψτε όχι μόνο «τι κάνει» αλλά και «καλέστε πότε».
  • input_schema (σχήμα εισόδου): σχήμα JSON που ορίζει ποιες παραμέτρους αναμένει το εργαλείο, σε ποιο τύπο.

# Ορισμός οχήματος (εννοιολογικό — σχήμα JSON){ "όνομα": "get_order_status", "description": "Ανακτά την τρέχουσα κατάσταση αποστολής μιας παραγγελίας. Καλέστε όταν ο χρήστης ρωτήσει πού βρίσκεται ο αριθμός παραγγελίας ή πότε θα φτάσει.", "input_schema": { "type": "object", "":"{ordere":" {ordere_no": "description": "Αριθμός παραγγελίας, π.χ. SP-1024"} }, "required": ["order_no"] }}

Κανόνες για μια καλή περιγραφή εργαλείου: σαφές και συνοπτικό όνομα, περιγραφή με "πότε να χρησιμοποιείται", περιγραφή για κάθε παράμετρο, βάζοντας τις πραγματικά υποχρεωτικές. Διατηρήστε εστιασμένο τον αριθμό των οχημάτων. Δεκάδες παρόμοια μοντέλα οχημάτων προκαλούν έκπληξη.

περιοχή

Τι κάνει;

καλό παράδειγμα

κακό παράδειγμα

όνομα

Ταυτότητα οχήματος

order_status_getir

φέρτε

περιγραφή

Τι κάνει + πότε να καλέσετε

"Επιστρέφει την κατάσταση φορτίου. Καλέστε όταν ο χρήστης ρωτήσει πού είναι η παραγγελία"

"ανακτά δεδομένα"

input_schema

Τύπος παραμέτρου και απαίτηση

{order_no: string, annotated}

χωρίς διάγραμμα / χωρίς περιγραφή

tool_use → tool_result Βρόχος

Ο κύκλος λειτουργεί ως εξής, βήμα προς βήμα:

  1. Στέλνετε την ερώτηση χρήστη + περιγραφές εργαλείου στο μοντέλο.
  2. Το μοντέλο είτε ανταποκρίνεται άμεσα είτε δημιουργεί ένα μπλοκ tool_use: "call order_durumu_getir with order_no=SP-1024."
  3. Η εφαρμογή σας εκτελεί πραγματικά το εργαλείο (ερωτάται στη βάση δεδομένων).
  4. Στέλνετε το αποτέλεσμα πίσω στο μοντέλο ως tool_result.
  5. Με αυτό το αποτέλεσμα, το μοντέλο είτε παράγει την τελική απάντηση είτε καλεί ένα άλλο εργαλείο. Ο κύκλος συνεχίζεται μέχρι το μοντέλο να πει "τέλειωσα".

# Agent loop (εννοιολογικά)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 break returns messages,ult=_ult] # τελική απάντηση άκρα βρόχου

Τα σύγχρονα SDK προσφέρουν προγράμματα εκτέλεσης εργαλείων που εκτελούν αυτόν τον βρόχο για εσάς. απλά γράφετε τις λειτουργίες του εργαλείου. Αλλά αυτό ακριβώς συμβαίνει στα παρασκήνια.

Διαχείριση σφαλμάτων

Τα εργαλεία ενδέχεται να αποτύχουν: η παραγγελία δεν βρέθηκε, το API λήγει, η εισαγωγή δεν είναι έγκυρη. Εάν δεν μπορείτε να εκτελέσετε το εργαλείο, επιστρέψτε το σφάλμα στο μοντέλο ως περιγραφικό εργαλείο_αποτέλεσμα ("σφάλμα: Ο αριθμός παραγγελίας SP-9999 δεν βρέθηκε") και τη σημαία σφάλματος. Το μοντέλο μπορεί να το δει και να το εξηγήσει απαλά στον χρήστη ή να δοκιμάσει έναν διαφορετικό τρόπο. Μην καταπιείτε το σφάλμα και μην επιστρέψετε κενά αποτελέσματα. Το μοντέλο πρέπει να ξέρει τι πήγε στραβά.

Περιγραφή αδύναμου/ισχυρού οχήματος

Αδύναμο (αόριστο ουσιαστικό, όχι "πότε"):

όνομα: "δεδομένα", περιγραφή: "ανακτά δεδομένα"# Το μοντέλο δεν γνωρίζει πότε και πώς να καλέσει. Είτε δεν καλεί καθόλου είτε καλεί λάθος.

Ισχυρό (όνομα δικτύου + όταν + περιγραφή παραμέτρου):

name: "musteri_bakiyesi_getir"description: "Επιστρέφει το υπόλοιπο του τρέχοντος λογαριασμού ενός πελάτη. Καλέστε όταν ο χρήστης ζητά χρέωση, πίστωση ή υπόλοιπο. ΔΕΝ πραγματοποιεί πληρωμή."input_schema: {custeri_id: string ("Customer ID")}# Το μοντέλο καλεί τη σωστή στιγμή, με τις σωστές παραμέτρους, γνωρίζοντας.

Τρεις Μίνι Θήκες

Περίπτωση 1 — Περιττός πράκτορας. Μια ομάδα δημιούργησε την επιχείρηση «σύνοψης κειμένου» με έναν πράκτορα πολλαπλών εργαλείων. Κάθε ανακεφαλαίωση διαρκεί 4 κλήσεις μοντέλου και 9 δευτερόλεπτα. Η δουλειά ήταν στην πραγματικότητα μια δουλειά με ένα τηλεφώνημα. Όταν αφαιρέσαμε τον πράκτορα και τον μειώσαμε σε μία κλήση, ο χρόνος μειώθηκε στο 1,5 δευτερόλεπτο και το κόστος μειώθηκε στο ένα τέταρτο. Μάθημα: χρησιμοποιήστε τον πράκτορα όταν είναι πραγματικά απαραίτητο.

Περίπτωση 2 — Αδύναμη εξήγηση, λάθος κλήση. Σε έναν αντιπρόσωπο υποστήριξης, ένα σκοτεινό εργαλείο που ονομάζεται fetch κλήθηκε τυχαία από το μοντέλο τόσο στην ερώτηση ισορροπίας όσο και στην ερώτηση αποστολής. Όταν τα οχήματα χωρίστηκαν σε balance_getir και cargo_durumu_getir και προστέθηκαν επεξηγήσεις "call when", η λάθος επιλογή οχήματος μειώθηκε από 18 σε 1 στα 50 παραδείγματα.

Περίπτωση 3 — Σφάλμα κατάποσης. Ένας πράκτορας επέστρεφε κενά αποτελέσματα όταν η παραγγελία δεν βρέθηκε. Το μοντέλο το ερμήνευσε αυτό ως «η παραγγελία παραδόθηκε» και παραπλάνησε τον πελάτη. Όταν το μήνυμα σφάλματος γράφεται ρητά στο tool_result ("η παραγγελία δεν βρέθηκε"), το μοντέλο λέει σωστά "Δεν μπόρεσα να βρω αυτόν τον αριθμό, μπορείτε να τον ελέγξετε;" άρχισε να λέει.

Συνήθη λάθη

  • Μετατρέποντας τα πάντα σε έναν πράκτορα: Ενώ μια κλήση είναι αρκετή, ο πράκτορας προσθέτει κόστος και καθυστέρηση.
  • Ασαφής περιγραφή οχήματος: Το μοντέλο δεν ξέρει πότε να καλέσει. επιλέγει λάθος.
  • Σκεπτόμενος ότι το μοντέλο κινεί το όχημα: Η ζώνη κινεί το όχημα. το μοντέλο απλά θέλει.
  • Κατάποση του λάθους: Το μοντέλο πρέπει να γνωρίζει τι πήγε στραβά. Δώστε το σφάλμα ως open tool_result.
  • Πάρα πολλά παρόμοια οχήματα: Το μοντέλο μπερδεύεται. Διατηρήστε το σύνολο εργαλείων εστιασμένο και ελάχιστο.
Προσοχή: Το ότι το μοντέλο λέει "καλέστε αυτό το όχημα" δεν σημαίνει ότι πρέπει να ληφθούν μέτρα. Σε καταστροφικά εργαλεία (διαγραφή, ολοκλήρωση αγοράς, email) η εφαρμογή σας δεν πρέπει να εκτελεί τυφλά την κλήση — αυτός είναι ο πυρήνας του θέματος ασφαλείας στην επόμενη ενότητα.

Συνοπτικά

  • Πράκτορας = μοντέλο (απόφαση) + εργαλεία (συναρτήσεις) + βρόχος (εργαλείο κλήσης, λήψη αποτελέσματος, απόφαση ξανά).
  • Μια κλήση μεμονωμένου μοτίβου δεν είναι πράκτορας. ο πράκτορας είναι μια διαδικασία βήμα προς βήμα.
  • Το μοντέλο δεν κινεί το όχημα. Η εφαρμογή σας εκτελείται (harness) και επιστρέφει το αποτέλεσμα ως tool_result.
  • Το εργαλείο προσδιορίζεται με όνομα, περιγραφή (συγκεκριμένα "call when") και input_schema.
  • Ο βρόχος συνεχίζεται ως tool_use → harness runs → tool_result → model συνεχίζεται έως ότου το μοντέλο λέει "done"; τα σφάλματα αναφέρονται ρητά στο μοντέλο.

Εργασία εφαρμογής

Σχεδιάστε 3 εργαλεία από τη δική σας επιχείρηση που μπορούν να δοθούν στον πράκτορα. (1) Γράψτε όνομα, περιγραφή με "call when" και input_schema για καθένα. Ας είναι τουλάχιστον ένα μη καταστροφικό εργαλείο ανάγνωσης και ένα υπολογισμός. (2) Επιλέξτε μια ρεαλιστική ερώτηση χρήστη και γράψτε χειροκίνητα βήμα προς βήμα (σε βρόχο) ποια από αυτά τα εργαλεία θα καλέσει το μοντέλο με ποιες εισόδους και τι θα κάνει μετά την άφιξη του εργαλείου_αποτέλεσμα. (3) Ρυθμίστε ένα σενάριο στο οποίο ένα από τα εργαλεία αποτυγχάνει και δείξτε πώς θα επιστρέψει το μήνυμα σφάλματος στο μοντέλο.

λίστα ελέγχου

  • [ ] Μπορώ να ορίσω τον πράκτορα ως "μοντέλο + εργαλεία + βρόχο" και να αποφασίσω πότε χρειάζεται.
  • [ ] Ξέρω ότι η ζώνη κινεί το όχημα, το μοντέλο απλώς το θέλει.
  • Μπορώ να γράψω μια συμπαγή περιγραφή οχήματος με [ ] όνομα, περιγραφή ("call when") και input_schema.
  • Μπορώ να ακολουθήσω τον κύκλο [ ] tool_use → tool_result βήμα προς βήμα.
  • [ ] Αναφέρω σφάλματα εργαλείου στο μοντέλο ως open tool_result.