Tác nhân của bạn đã hoạt động trong bản demo. Nó đọc phiếu, gọi ba API và đăng một bản tóm tắt rõ ràng. Sau đó, bạn đã triển khai nó. Một tuần sau, nó gửi email cho cùng một khách hàng hai lần, đốt cháy ngân sách token trong ngày cho một vòng lặp thử lại, và giao cho giao diện người dùng của bạn một payload mà nó không thể phân tích cú pháp.
Khoảng cách giữa một nguyên mẫu hoạt động và một tác nhân đáng tin cậy là nơi hầu hết các nhóm gặp khó khăn. Mô hình hiếm khi là thủ phạm. Vấn đề nằm ở phần được coi là đường ống dẫn: các cuộc gọi API mà tác nhân thực hiện trên đường đến một câu trả lời. Một tác nhân là một vòng lặp các cuộc gọi công cụ, và mỗi cuộc gọi công cụ là một yêu cầu HTTP có thể thất bại, bị giới hạn tốc độ, hết thời gian chờ hoặc trả về thứ gì đó mà bạn không mong đợi. Bỏ qua việc kiểm thử các cuộc gọi đó theo cách bạn kiểm thử bất kỳ API sản xuất nào, và tác nhân của bạn chỉ còn một phản hồi xấu nữa là xảy ra sự cố.
Đây là phần trấn an: độ tin cậy của tác nhân có thể kiểm thử được. Bạn không cần phải tin rằng mô hình sẽ hoạt động đúng. Bạn chủ động thực hiện các đường dẫn lỗi, trước khi người dùng của bạn tìm thấy chúng. Hướng dẫn này phân loại các lỗi của tác nhân thành năm chế độ và chỉ ra cách bắt từng lỗi. Công việc diễn ra ở ranh giới API, vì vậy bạn cần một nền tảng mà bạn có thể chỉ vào các phụ thuộc của tác nhân để thiết kế hợp đồng, mô phỏng các lỗi và kiểm tra những gì trả về. Apidog bao gồm công việc đó và nó chạy qua các ví dụ dưới đây.
Tác nhân thất bại ở ranh giới API, không phải trong lời nhắc
Khi một tác nhân hoạt động sai trong môi trường sản xuất, bản năng là chỉnh sửa lời nhắc. Đôi khi điều đó hữu ích. Thường xuyên hơn, lỗi không liên quan gì đến cách diễn đạt. Tác nhân đã yêu cầu một API thực tế một thứ gì đó, và phản hồi chậm, sai định dạng, bị giới hạn tốc độ, hoặc có hình dạng khác với những gì tác nhân mong đợi. Mô hình sau đó suy luận dựa trên đầu vào xấu và làm một điều gì đó tự tin nhưng sai.
Hãy xem một bước tác nhân duy nhất bao gồm những gì. Mô hình chọn một công cụ. Mã của bạn biến lựa chọn đó thành một yêu cầu HTTP. Một dịch vụ bên ngoài trả lời. Mã của bạn đưa kết quả trở lại mô hình. Bốn lần chuyển giao, và ba trong số đó là tích hợp API thông thường, không phải học máy. Đó là tin tốt, vì tích hợp API là một vấn đề kiểm thử đã được giải quyết. Bạn đã biết cách mô phỏng một điểm cuối chậm hoặc xác nhận một lược đồ JSON. Tác nhân làm tăng thêm rủi ro, bởi vì mô hình hành động dựa trên bất cứ thứ gì nó nhận được thay vì ném ra một ngoại lệ rõ ràng.
Vì vậy, câu hỏi về độ tin cậy không phải là "mô hình có đủ thông minh không". Mà là "tôi đã kiểm thử mọi cách mà các cuộc gọi API của tác nhân có thể đi chệch hướng chưa." Năm chế độ bao gồm hầu hết các trường hợp đó.
Chế độ lỗi 1: các cuộc gọi công cụ đi chệch khỏi hợp đồng
Lỗi tác nhân phổ biến nhất là một cuộc gọi công cụ không khớp với API mà nó đang gọi. Mô hình tự tạo một tham số, bỏ một trường bắt buộc, gửi một chuỗi trong khi lược đồ muốn một số nguyên, hoặc gọi đúng điểm cuối với các đối số không hợp lý. Chẳng hạn, một tác nhân đặt chỗ gọi POST /reservations với guests: "two" thay vì guests: 2. API trả về 400, hoặc tệ hơn, 200 với một lỗi ẩn trong nội dung, và tác nhân tiếp tục như thể nó đã thành công.
Bạn bắt lỗi này bằng cách kiểm thử cuộc gọi công cụ như một hợp đồng. Định nghĩa lược đồ cho mỗi công cụ mà tác nhân có thể gọi, sau đó xác nhận rằng yêu cầu gửi đi khớp: các trường bắt buộc phải có, loại dữ liệu chính xác, enum hợp lệ. Khi tác nhân tạo ra một cuộc gọi vi phạm hợp đồng, bạn muốn điều đó thất bại rõ ràng trong một bài kiểm thử, chứ không phải âm thầm trong môi trường sản xuất. Hướng dẫn chi tiết của chúng tôi về kiểm thử các cuộc gọi công cụ của tác nhân AI đi sâu vào vấn đề này, và phương pháp rộng hơn để kiểm thử các tác nhân gọi API của bạn bao gồm việc thiết lập từ đầu đến cuối.
Hành động thực tế: nắm bắt các lược đồ công cụ mà tác nhân của bạn sử dụng, tải chúng vào Apidog, và chạy các cuộc gọi công cụ thực tế của tác nhân dựa trên các định nghĩa đó. Các sai lệch sẽ xuất hiện dưới dạng lỗi xác thực nêu rõ trường chính xác đã gây ra lỗi.
Chế độ lỗi 2: lỗi upstream và giới hạn tốc độ
Mọi cuộc gọi bên ngoài mà tác nhân thực hiện đều có thể trả về 429, 500, hoặc không có gì cả trước khi hết thời gian chờ. Một tác nhân được xây dựng tốt sẽ xử lý những lỗi này bằng cách thử lại và chờ. Một tác nhân yếu kém thì hoặc bỏ cuộc ngay khi gặp lỗi đầu tiên hoặc, nguy hiểm hơn, thử lại quá mạnh đến mức kích hoạt thêm giới hạn tốc độ và quay vòng trong một vòng lặp làm cạn kiệt ngân sách của bạn. Câu hỏi được hỏi nhiều nhất trên diễn đàn thảo luận SDK của Anthropic thực sự là về các mẫu phục hồi lỗi tác nhân, điều này cho thấy mức độ phổ biến của nỗi đau này.
Bạn không thể kiểm thử việc phục hồi lỗi với một API khỏe mạnh, vì một API khỏe mạnh không bao giờ trả về các lỗi mà bạn cần xử lý. Đây là lúc mocking phát huy tác dụng. Thiết lập một mock cho phụ thuộc của tác nhân và lập trình một chuỗi: 429 với header Retry-After, sau đó là 500, rồi thành công. Bây giờ hãy xem tác nhân của bạn làm gì. Nó có chờ với sự ngẫu nhiên không? Nó có tôn trọng header không? Nó có bỏ cuộc một cách duyên dáng sau một số lần thử hợp lý, hay mở một cầu dao để nó ngừng tấn công một dịch vụ rõ ràng là đang ngừng hoạt động? Và nếu một hành động thử lại không bất biến, thì việc lặp lại có tính phí gấp đôi hoặc gửi gấp đôi không? Một khóa bất biến là thứ giúp việc thử lại an toàn để lặp lại.
Giới hạn tốc độ xứng đáng được diễn tập riêng. Nếu bạn chưa thấy tác nhân của mình hoạt động như thế nào khi một nhà cung cấp giới hạn tốc độ nó, hãy đọc hướng dẫn của chúng tôi về ý nghĩa của phản hồi vượt quá giới hạn tốc độ và sau đó mô phỏng nó. Hướng dẫn chuyên sâu về phục hồi lỗi tác nhân AI bao gồm các mẫu thử lại, hết thời gian chờ, chờ và cầu dao đầy đủ.
Chế độ lỗi 3: đầu ra không xác định
Đặt nhiệt độ về 0 và bạn vẫn sẽ không nhận được đầu ra giống hệt byte qua các lần chạy. Các nhà phát triển liên tục khám phá lại điều này; có một chuỗi vLLM dài về việc các seed và nhiệt độ không đủ để tái tạo. Phần cứng, xử lý theo lô và các thay đổi phía nhà cung cấp đều gây ra sự biến đổi. Nếu các bài kiểm thử của bạn khẳng định các chuỗi chính xác, chúng sẽ trở nên không ổn định, và các bài kiểm thử không ổn định sẽ bị bỏ qua, điều này tệ hơn là không có bài kiểm thử nào. Bài viết của chúng tôi về những nguyên nhân gây ra các bài kiểm thử không ổn định áp dụng trực tiếp ở đây.
Giải pháp là khẳng định về cấu trúc và ý nghĩa, không phải về văn bản chính xác. Kiểm tra xem phản hồi có hợp lệ theo một lược đồ JSON hay không. Kiểm tra xem cuộc gọi công cụ có hình dạng và mục tiêu chính xác hay không. Kiểm tra xem một câu trả lời số có nằm trong một phạm vi hợp lý hay không. Kiểm tra xem các khóa bắt buộc có tồn tại và các trường bị cấm có vắng mặt hay không. Một bài kiểm thử nói rằng "phản hồi chứa một tổng số nằm giữa 0 và giá trị giỏ hàng" sẽ tồn tại qua sự biến đổi tự nhiên của mô hình trong khi vẫn bắt được một lỗi hồi quy thực sự. Hướng dẫn về kiểm thử các tác nhân AI không xác định trình bày toàn bộ các chiến lược, và bài viết về cách bộ nhớ tác nhân hoạt động cho thấy tại sao trạng thái làm cho việc này khó hơn.
Chế độ lỗi 4: chi phí vượt tầm kiểm soát
Các tác nhân lặp lại, và các vòng lặp tốn tiền. Một tác nhân bị kẹt duy nhất thử lại một cuộc gọi lỗi vài nghìn lần có thể biến một hóa đơn nhỏ thành một hóa đơn lớn chỉ sau một đêm. Một báo cáo thực địa trong các cuộc thảo luận SDK đã mô tả việc giảm chi phí của một tác nhân từ 500 đô la một tháng xuống còn 80 đô la mà không làm mất chất lượng, điều này cho thấy cả tốc độ tăng chi phí và mức độ lỏng lẻo thường ẩn trong thiết kế.
Chi phí là một vấn đề về độ tin cậy, không chỉ là vấn đề tài chính, bởi vì các lỗi lãng phí tiền (vòng lặp, các cuộc gọi thừa, ngữ cảnh quá lớn) cũng làm cho tác nhân chậm và không thể đoán trước. Theo dõi token trên mỗi lần chạy, giới hạn ngân sách cho mỗi tác vụ và lưu trữ những gì bạn có thể. Đối với khía cạnh dòng lệnh của vấn đề này, hướng dẫn của chúng tôi về giảm chi phí token tác nhân có các đòn bẩy cụ thể. Khi bạn kiểm thử các đường dẫn phục hồi với một mock, hãy theo dõi cả số lượng cuộc gọi. Một tác nhân thành công nhưng thực hiện bốn mươi cuộc gọi để đạt được điều đó là một sự cố chi phí đang chờ xảy ra.
Chế độ lỗi 5: thiếu hàng rào bảo vệ
Những lỗi gây tổn hại nhất là những lỗi mà tác nhân làm chính xác những gì được yêu cầu và kết quả vẫn tệ. Nó gửi email, xóa hồ sơ hoặc đặt hàng, bởi vì không có gì ngăn cản quyết định của mô hình và hành động trực tiếp. Các bảng SDK có một luồng đáng nhớ được xây dựng xung quanh một tác nhân đã gửi một email lúc ba giờ sáng cho sếp của ai đó. Buồn cười một lần, tốn kém hai lần.
Hàng rào bảo vệ là dây an toàn. Đặt một danh sách cho phép các hành động mà tác nhân có thể thực hiện mà không cần phê duyệt. Đặt các cuộc gọi phá hủy hoặc không thể đảo ngược phía sau sự xác nhận của con người. Cung cấp cho tác nhân một chế độ chạy thử mô tả những gì nó sẽ làm mà không thực sự làm. Sau đó kiểm tra xem hàng rào bảo vệ có giữ được không: mô phỏng điểm cuối gây tác dụng phụ, chạy tác nhân và khẳng định rằng nó đi vào đường dẫn xác nhận thay vì hành động trực tiếp. Hướng dẫn bảo mật như OWASP Top 10 cho các ứng dụng mô hình ngôn ngữ lớn là một danh sách kiểm tra vững chắc về những gì cần bảo vệ. Hướng dẫn về hàng rào bảo vệ tác nhân AI bao gồm các cổng phê duyệt và kiểm soát phạm vi tác động một cách chuyên sâu.
Cách cấu trúc một bài kiểm thử tác nhân
Năm chế độ chia sẻ một hình dạng kiểm thử, và bạn có thể tái sử dụng nó:
- Nắm bắt các lược đồ công cụ mà tác nhân của bạn có thể gọi, để bạn có một hợp đồng để khẳng định.
- Mô phỏng từng phụ thuộc để bạn kiểm soát thời gian, mã trạng thái và nội dung, và để bạn tránh các tác dụng phụ thực tế.
- Đưa tác nhân qua kịch bản, bao gồm các đường dẫn không vui mà một API trực tiếp sẽ không tạo ra theo yêu cầu.
- Khẳng định những gì tác nhân đã gửi và cách nó phản ứng: hình dạng yêu cầu, hành vi phục hồi, số lượng cuộc gọi và liệu các hàng rào bảo vệ có hoạt động hay không.
Chạy vòng lặp đó cho một công cụ, sau đó thêm công cụ tiếp theo. Việc thiết lập sẽ tự đền đáp lần đầu tiên nó bắt được một cuộc gọi công cụ bị hỏng trước khi người dùng phát hiện ra.
Danh sách kiểm tra độ tin cậy của tác nhân
Trước khi một tác nhân được đưa vào sản xuất, hãy xem qua danh sách này:
- Mỗi cuộc gọi công cụ được xác thực dựa trên một lược đồ, và các vi phạm hợp đồng sẽ làm thất bại một bài kiểm thử.
- Các phản hồi 429, 500 và hết thời gian chờ của upstream được mô phỏng, và tác nhân phục hồi với chế độ chờ.
- Các hành động được thử lại là bất biến, vì vậy việc lặp lại không thể tính phí gấp đôi hoặc gửi gấp đôi.
- Các bài kiểm thử khẳng định về cấu trúc và ý nghĩa, không phải chuỗi chính xác, để sự biến đổi thông thường không gây ra sự không ổn định.
- Việc sử dụng token trên mỗi lần chạy được đo lường, và một giới hạn ngân sách sẽ ngăn chặn các vòng lặp vượt tầm kiểm soát.
- Các hành động phá hủy nằm sau một danh sách cho phép hoặc một cổng phê duyệt của con người.
- Đường dẫn hàng rào bảo vệ được kiểm thử bằng một mock, không phải được giả định.
Đánh dấu vào cả bảy mục và bạn đã kiểm thử các cách mà tác nhân bị lỗi trong môi trường sản xuất.
Apidog phù hợp ở đâu (và không phù hợp ở đâu)
Hãy rõ ràng về công việc của công cụ. Apidog không phải là một framework tác nhân, một máy chủ mô hình, hay một bộ kiểm tra đánh giá. Nó không xây dựng hay chạy tác nhân của bạn. Điều nó làm là quản lý lớp API mà tác nhân của bạn phụ thuộc vào, đó chính xác là nơi các lỗi này tồn tại.
Trong thực tế, điều đó có nghĩa là ba điều. Bạn thiết kế và lưu trữ các hợp đồng cho các công cụ mà tác nhân của bạn gọi, để bạn có thể xác thực các yêu cầu gửi đi dựa trên chúng. Bạn mô phỏng các phụ thuộc đó và lập trình các phản hồi lỗi (429, 500, hết thời gian chờ, nội dung sai định dạng) mà một API trực tiếp sẽ không tạo ra theo yêu cầu, để bạn có thể diễn tập phục hồi. Và bạn viết các khẳng định về các phản hồi (lược đồ, hình dạng, phạm vi, các khóa bắt buộc) tồn tại qua đầu ra không xác định. Đó là sự phù hợp trung thực: Apidog kiểm thử các API mà tác nhân của bạn gọi, mô phỏng các lỗi bạn cần xử lý và kiểm tra những gì trả về. Tổng quan của chúng tôi về kiểm thử AI tác nhân đặt điều này vào bức tranh QA rộng lớn hơn.
Các câu hỏi thường gặp
Độ tin cậy của tác nhân là vấn đề của mô hình hay vấn đề kỹ thuật? Chủ yếu là kỹ thuật. Lựa chọn mô hình quan trọng, nhưng các lỗi gây ra sự cố (các cuộc gọi công cụ xấu, giới hạn tốc độ không được xử lý, thiếu hàng rào bảo vệ) là các vấn đề tích hợp và kiểm thử mà bạn có thể giải quyết mà không cần thay đổi mô hình.
Tôi có thể kiểm thử một tác nhân mà không cần truy cập các API thực tế mà nó gọi không? Có, và bạn nên làm vậy. Hãy mô phỏng các phụ thuộc để bạn có thể buộc các phản hồi lỗi, kiểm soát thời gian và tránh các tác dụng phụ. Đó là cách đáng tin cậy duy nhất để kiểm thử các đường dẫn phục hồi và hàng rào bảo vệ.
Làm thế nào để tôi viết các bài kiểm thử khi đầu ra thay đổi mỗi lần chạy? Khẳng định về cấu trúc và ý nghĩa thay vì văn bản chính xác. Xác thực phản hồi dựa trên một lược đồ, kiểm tra hình dạng cuộc gọi công cụ và sử dụng các phạm vi cho các số. Hướng dẫn kiểm thử các tác nhân AI không xác định bao gồm chi tiết này.
Tôi nên kiểm thử điều gì trước? Hàng rào bảo vệ trên các hành động phá hủy, sau đó là phục hồi lỗi. Hai điều đó bảo vệ bạn khỏi những lỗi tốn kém nhất: một tác nhân thực hiện một hành động có hại, hoặc một tác nhân lặp lại và làm cạn kiệt ngân sách của bạn.
Bắt đầu với một chế độ lỗi
Bạn không cần phải kiểm thử tất cả năm chế độ cùng một lúc. Hãy chọn chế độ làm bạn sợ nhất, thường là các hàng rào bảo vệ hoặc phục hồi lỗi, và diễn tập nó với một mock trong tuần này. Lập trình lỗi, chạy tác nhân và xem nó làm gì. Lần đầu tiên bạn thấy tác nhân của mình xử lý một lỗi 429 mô phỏng với chế độ chờ sạch sẽ thay vì một vòng lặp làm cạn kiệt ngân sách, bạn sẽ tin tưởng nó hơn, và vì một lý do tốt hơn là một bản demo xanh.
Tải xuống Apidog để thiết kế các hợp đồng, mô phỏng các lỗi và khẳng định các phản hồi mà tác nhân của bạn phụ thuộc vào.