Lợi nhuận:
- Xác định tác nhân là 'mô hình + công cụ + vòng lặp' và quyết định khi nào cần
- Viết định nghĩa công cụ với tên, mô tả và input_schema
- Giám sát luồng và xử lý lỗi của vòng lặp tool_use và tool_result
Từ trước đến nay, mô hình luôn thực hiện một công việc: nhận văn bản nhập vào, đưa ra phản hồi văn bản. Nhưng công việc thực tế thường đòi hỏi nhiều thứ hơn là chỉ viết chữ; thực hiện tính toán, truy vấn cơ sở dữ liệu, gọi API, tìm ra tỷ giá hối đoái hiện tại. Người mẫu không thể tự mình làm những việc này - nhưng cô ấy có thể quyết định khi nào cần thực hiện và nhờ ai đó thực hiện chúng. Đây là những gì việc sử dụng công cụ mang lại cho mô hình và đây là nền tảng của các tác nhân AI. Trong phần này, chúng ta sẽ tìm hiểu tác nhân là gì, công cụ được xác định như thế nào và vòng lặp tool_use hoạt động như thế nào.
Đại lý là gì? Mô hình + Công cụ + Vòng lặp
Tác nhân AI bao gồm ba phần: mô hình (bộ não đưa ra quyết định), công cụ (các chức năng mà mô hình có thể gọi: thời tiết, truy vấn cơ sở dữ liệu, gửi email) và vòng lặp (vòng lặp; mô hình gọi công cụ, nhận kết quả, quyết định lại những việc cần làm, v.v.).
Sự khác biệt quan trọng: Một cuộc gọi mẫu đơn lẻ không phải là một tác nhân. Tác nhân là một quá trình trong đó mô hình tiến hành từng bước, tại mỗi bước chọn bước tiếp theo dựa trên kết quả của công cụ. "Hãy suy nghĩ như một con người, sử dụng đôi tay của bạn, nhìn vào kết quả và suy nghĩ lại."
Một thực tế quan trọng: Bản thân mẫu xe không vận hành phương tiện. Mô hình chỉ nói "Tôi muốn gọi công cụ này bằng những đầu vào này". Ứng dụng của bạn (được gọi là dây nịt) chạy công cụ và trả kết quả về mô hình. Điều này rất quan trọng đối với bảo mật: mô hình không chạm trực tiếp vào hệ thống của bạn; Mọi hành động đều nằm dưới sự kiểm soát của bạn.
Mẹo: Đừng cố gắng giải quyết mọi vấn đề với đại lý. Đại lý; làm tăng nguy cơ chậm trễ, chi phí và sai sót. Trước tiên hãy hỏi: “Việc này sẽ được giải quyết bằng một cuộc gọi hay một quy trình làm việc cố định?” Nếu câu trả lời là có thì không cần đến đại lý. Tác nhân dành cho các nhiệm vụ có kết thúc mở mà các bước không thể biết trước.
Định nghĩa công cụ: tên, mô tả, input_schema
Để giới thiệu một công cụ vào mô hình, bạn đưa ra ba điều:
- tên: Nhận dạng của chiếc xe, ví dụ: get_weather.
- mô tả: Công cụ này làm gì và khi nào nên gọi nó. Đây là khu vực quan trọng nhất cho phép mô hình chọn đúng công cụ vào đúng thời điểm. Viết không chỉ "làm gì" mà còn "gọi khi nào".
- input_schema (lược đồ đầu vào): lược đồ JSON xác định tham số nào mà công cụ mong đợi, thuộc loại nào.
# Định nghĩa phương tiện (khái niệm — lược đồ JSON){ "name": "get_order_status", "description": "Truy xuất trạng thái vận chuyển hiện tại của một đơn hàng. Gọi khi người dùng hỏi số đơn hàng ở đâu hoặc khi nào nó sẽ đến.", "input_schema": { "type": "object", "properties": { "order_no": {"type": "string", "description": "Số đơn hàng, ví dụ SP-1024"} }, "bắt buộc": ["order_no"] }}
Các quy tắc để có một mô tả công cụ tốt: tên rõ ràng và ngắn gọn, mô tả có "thời điểm sử dụng", mô tả cho từng tham số, đặt những tham số thực sự bắt buộc vào phần bắt buộc. Giữ số lượng xe tập trung; Hàng chục mẫu xe tương tự gây ngạc nhiên.
khu vực
Nó làm gì?
ví dụ tốt
ví dụ xấu
tên
Mã xe
order_status_getir
mang theo
mô tả
Nó làm gì + khi nào cần gọi
"Trả về trạng thái hàng hóa; gọi khi người dùng hỏi đơn hàng đang ở đâu"
"lấy dữ liệu"
lược đồ đầu vào
Loại thông số và yêu cầu
{order_no: chuỗi, có chú thích}
không có sơ đồ/không có mô tả
tool_use → tool_result Vòng lặp
Chu trình hoạt động như thế này, từng bước một:
- Bạn gửi câu hỏi của người dùng + mô tả công cụ cho mô hình.
- Mô hình sẽ phản hồi trực tiếp hoặc tạo khối tool_use: "gọi order_durumu_getir với order_no=SP-1024."
- Ứng dụng của bạn thực sự chạy công cụ (truy vấn cơ sở dữ liệu).
- Bạn gửi kết quả trở lại mô hình dưới dạng tool_result.
- Với kết quả này, mô hình sẽ đưa ra câu trả lời cuối cùng hoặc gọi một công cụ khác. Chu kỳ tiếp tục cho đến khi người mẫu nói "Tôi đã hoàn tất."
# Vòng lặp tác nhân (khái niệm)messages = [user_question]while True: reply = model.uret(messages, tools=tool_def địnhs) if reply.tur == "tool_use": result = harness.run(response.tool_name, reply.entries) # APPLICATION chạy tin nhắn += [response, tool_result(result)] # trả về kết quả khác: break # phản hồi cuối cùng; vòng lặp kết thúc
SDK hiện đại cung cấp trình chạy công cụ chạy vòng lặp này cho bạn; bạn chỉ cần viết các chức năng công cụ. Nhưng đó chính xác là những gì đang xảy ra đằng sau hậu trường.
Quản lý lỗi
Công cụ có thể bị lỗi: không tìm thấy thứ tự, API hết thời gian chờ, dữ liệu nhập không hợp lệ. Nếu bạn không thể chạy công cụ, hãy trả lại lỗi cho mô hình dưới dạng tool_result mô tả ("lỗi: Không tìm thấy số đơn hàng SP-9999") và cờ lỗi. Người mẫu có thể nhìn thấy điều này và nhẹ nhàng giải thích cho người dùng hoặc thử cách khác. Đừng nuốt lỗi và trả về kết quả trống; Người mẫu phải biết điều gì đã xảy ra.
Mô tả xe yếu/mạnh
Yếu (danh từ không xác định, không có “khi”):
name: "data", description: "fetch data"# Model không biết khi nào và làm thế nào để gọi; Nó không gọi được hoặc gọi không chính xác.
Mạnh (tên mạng + khi + mô tả tham số):
name: "musteri_bakiyesi_getir"description: "Trả về số dư tài khoản hiện tại của khách hàng. Gọi khi người dùng yêu cầu ghi nợ, ghi có hoặc số dư. KHÔNG thực hiện thanh toán."input_schema: {custeri_id: string ("ID khách hàng")}# Mô hình gọi đúng lúc, đúng thông số, biết giới hạn của nó.
Ba hộp nhỏ
Trường hợp 1 - Tác nhân không cần thiết. Một nhóm đã xây dựng hoạt động kinh doanh “tóm tắt văn bản” bằng một tác nhân đa công cụ; Mỗi bản tóm tắt cần 4 cuộc gọi mô hình và 9 giây. Công việc thực sự là một công việc một cuộc gọi. Khi chúng tôi loại bỏ đại lý và giảm xuống còn một cuộc gọi, thời gian giảm xuống còn 1,5 giây và chi phí giảm xuống còn một phần tư. Bài học: hãy sử dụng tác nhân khi thực sự cần thiết.
Trường hợp 2 - Giải thích yếu kém, gọi sai. Trong một tác nhân hỗ trợ, một công cụ ít người biết đến có tên là tìm nạp được mô hình gọi ngẫu nhiên trong cả câu hỏi về số dư và câu hỏi vận chuyển. Khi các phương tiện được chia thành các phần giải thích Balance_getir và Cargo_durumu_getir và "gọi khi nào" được thêm vào, việc lựa chọn phương tiện sai đã giảm từ 18 xuống 1 trên 50 ví dụ.
Trường hợp 3 - Lỗi nuốt phải. Một đại lý đã trả về kết quả trống khi không tìm thấy đơn hàng; Mô hình giải thích điều này là "đơn hàng đã được giao" và đánh lừa khách hàng. Khi thông báo lỗi được ghi rõ ràng vào tool_result ("không tìm thấy đơn hàng"), mô hình sẽ thông báo chính xác "Tôi không thể tìm thấy số này, bạn có thể kiểm tra nó không?" anh ấy bắt đầu nói.
Những lỗi thường gặp
- Chuyển mọi thứ sang đại lý: Mặc dù một cuộc gọi là đủ nhưng đại lý sẽ tăng thêm chi phí và độ trễ.
- Mô tả xe mơ hồ: Mẫu xe không biết khi nào nên gọi; chọn sai.
- Tưởng người mẫu chạy xe: Dây nịt chạy xe; người mẫu chỉ muốn.
- Nuốt lỗi: Người mẫu phải biết sai sót ở đâu; Báo lỗi là open tool_result.
- Quá nhiều xe giống nhau: Mẫu xe bị nhầm lẫn; Giữ bộ công cụ tập trung và tối thiểu.
Chú ý: Chỉ vì người mẫu nói "gọi chiếc xe đó" không có nghĩa là nên thực hiện hành động đó. Trên các công cụ phá hoại (xóa, kiểm tra, gửi email), ứng dụng của bạn không được thực hiện lệnh gọi một cách mù quáng — đây là cốt lõi của chủ đề bảo mật trong bài tiếp theo.
Tóm lại
- Tác nhân = mô hình (quyết định) + công cụ (chức năng) + vòng lặp (gọi công cụ, lấy kết quả, quyết định lại).
- Một cuộc gọi mẫu đơn không phải là một tác nhân; đại lý là một quá trình từng bước.
- Mẫu xe không chạy; Ứng dụng của bạn chạy (khai thác) và trả về kết quả là tool_result.
- Công cụ này được xác định theo tên, mô tả (cụ thể là "gọi khi") và input_schema.
- Vòng lặp tiếp tục khi tool_use → khai thác chạy → tool_result → mô hình tiếp tục cho đến khi mô hình báo "xong"; lỗi được báo cáo rõ ràng cho mô hình.
Nhiệm vụ ứng dụng
Thiết kế 3 công cụ từ doanh nghiệp của bạn để có thể trao cho đại lý. (1) Viết tên, mô tả bằng "gọi khi nào" và lược đồ đầu vào cho mỗi tên; Hãy để ít nhất một công cụ đọc không phá hủy và một công cụ tính toán. (2) Chọn một câu hỏi thực tế của người dùng và viết thủ công từng bước (trong một vòng lặp) công cụ nào trong số này mà mô hình sẽ gọi với đầu vào nào và nó sẽ làm gì sau khi tool_result đến. (3) Thiết lập tình huống trong đó một trong các công cụ bị lỗi và hiển thị cách thông báo lỗi sẽ quay trở lại mô hình.
danh sách kiểm tra
- [ ] Tôi có thể định nghĩa tác nhân là "mô hình + công cụ + vòng lặp" và quyết định khi nào cần.
- [ ] Tôi biết dây nịt chạy xe, người mẫu chỉ muốn thôi.
- Tôi có thể viết một mô tả cụ thể về xe với tên [ ], mô tả ("gọi khi nào") và input_schema.
- Tôi có thể thực hiện theo từng bước chu trình [ ] tool_use → tool_result.
- [ ] Tôi báo cáo lỗi công cụ cho mô hình dưới dạng open tool_result.