Đã 3 giờ sáng. Tác nhân của bạn đã xử lý một hàng dài các yêu cầu hỗ trợ trong khi bạn đang ngủ. Một yêu cầu trông giống như một sự leo thang, vì vậy tác nhân đã viết một bản tóm tắt và gửi email cho sếp của bạn. Bản tóm tắt chính xác. Ngữ pháp sạch sẽ. Vấn đề là không ai yêu cầu email đó, không ai đọc nó trước, và không có gì có thể ngăn cản nó một khi tác nhân đã quyết định gửi. Tác nhân đã làm đúng những gì hướng dẫn cho phép. Đó là điều nên khiến bạn phải thức trắng đêm.
Những thất bại gây tổn hại nhiều nhất không phải là khi mô hình bị "ảo giác" hay quy trình bị lỗi. Những lỗi đó ồn ào và dễ bị phát hiện. Những lỗi nguy hiểm thường im lặng. Tác nhân làm chính xác những gì đã được chỉ dẫn, và kết quả vẫn tệ, bởi vì nó đã gửi email, xóa hồ sơ hoặc đặt hàng, và không có gì ngăn cản giữa quyết định của mô hình và hành động thực tế.
Hàng rào bảo vệ (Guardrails) là những thứ nằm ở đó. Một hàng rào bảo vệ là lớp kiểm tra một hành động trước khi nó xảy ra và quyết định liệu có cho phép, chặn nó, hay hỏi ý kiến con người trước. Hướng dẫn này bao gồm bốn loại bạn có thể xây dựng (danh sách hành động được phép, cổng phê duyệt, chế độ chạy thử, và giới hạn phạm vi ảnh hưởng) và sau đó là bước mà hầu hết các nhóm bỏ qua: chứng minh hàng rào bảo vệ hoạt động. Nếu bạn muốn bối cảnh rộng hơn trước, bài viết chính của chúng tôi về lý do các tác nhân AI gặp lỗi trong môi trường sản xuất phân loại các lỗi của tác nhân thành năm chế độ, và thiếu hàng rào bảo vệ là chế độ thứ năm.
Sắp xếp các hành động dựa trên mức độ gây hại của chúng
Không phải mọi hành động đều cần một cổng kiểm soát. Một tác nhân đọc lịch, tìm nạp dự báo hoặc truy vấn một báo cáo chỉ đọc có thể chạy với tốc độ tối đa mà không cần sự giám sát của con người. Việc yêu cầu phê duyệt cho những hành động này chỉ làm cho nhóm của bạn có thói quen nhấp "có" mà không suy nghĩ, điều này khiến các phê duyệt trở nên vô giá trị khi chúng thực sự cần thiết.
Vì vậy, hàng rào bảo vệ đầu tiên là công việc sắp xếp. Chia các hành động mà tác nhân của bạn có thể thực hiện thành hai danh sách. Danh sách cho phép (allowlist) chứa các lệnh gọi an toàn để chạy tự động: đọc, tìm kiếm, tra cứu bất biến (idempotent lookups), bất cứ điều gì có thể hoàn tác. Mọi thứ khác đều cần một cổng kiểm soát: gửi, xóa, thanh toán, ghi vào hệ thống hồ sơ, bất cứ điều gì khách hàng hoặc đồng nghiệp sẽ thấy. Một bài kiểm tra hữu ích cho danh sách thứ hai là câu hỏi "nếu tác nhân làm điều này một trăm lần do nhầm lẫn, thì hậu quả sẽ tệ đến mức nào." Nếu câu trả lời tệ hơn một cái nhún vai, hành động đó không thuộc về danh sách cho phép.
Hãy thành thật về các trường hợp trung gian. Một lệnh POST tạo bản nháp có thể hoàn tác. Một lệnh POST tạo bản nháp và gửi email thì không. Hai lệnh gọi trông tương tự trong mã của bạn có thể nằm ở hai phía đối diện của ranh giới. Sắp xếp theo hậu quả, không phải theo động từ HTTP.
Đưa con người vào quy trình cho các hành động gây phá hoại
Khi bạn đã biết những hành động nào là nguy hiểm, hàng rào bảo vệ tiếp theo là cổng phê duyệt: tác nhân sẽ tạm dừng trước khi thực hiện hành động, hiển thị những gì nó muốn làm và chờ một người xác nhận. Đây là mô hình "human-in-the-loop" (con người tham gia vào quy trình), và nó là hàng rào bảo vệ có giá trị cao nhất mà bạn có thể thêm vào, bởi vì nó biến một sai lầm không thể hoàn tác thành một yêu cầu bị từ chối.
Một cổng tốt sẽ hiển thị đủ thông tin để con người quyết định. Không phải "tác nhân muốn gửi email," mà là người nhận, chủ đề và nội dung. Không phải "xóa một bản ghi," mà là bản ghi nào và tại sao. Nhà phát triển phê duyệt hành động không bao giờ nên tin tưởng vào bản tóm tắt của tác nhân về những gì nó sắp làm. Hãy hiển thị yêu cầu thực tế.
Giữ cho việc từ chối tại cổng dễ dàng. Nếu việc từ chối một hành động chậm hoặc không rõ ràng, mọi người sẽ phê duyệt theo phản xạ, và bạn sẽ trở lại trạng thái không có hàng rào bảo vệ nào cả. Các diễn đàn SDK của Anthropic có một cuộc thảo luận định kỳ về việc thêm một bước phê duyệt của con người trước khi tác nhân hành động, và chủ đề luôn quay trở lại là cổng phải rõ ràng: một người đánh giá không thể nhìn thấy tải trọng cụ thể thì không thể đưa ra quyết định thực sự. Hãy ghi lại mọi phê duyệt và từ chối. Khi có điều gì đó lọt qua, nhật ký là cách bạn tìm ra cổng nào đã thất bại.
Cung cấp cho tác nhân chế độ chạy thử (dry-run mode)
Cổng phê duyệt bảo vệ môi trường sản xuất. Chế độ chạy thử bảo vệ sự tự tin của bạn trước khi bạn đạt được điều đó. Trong chế độ chạy thử, tác nhân làm mọi thứ như bình thường, chọn công cụ, xây dựng yêu cầu, quyết định các đối số, nhưng dừng lại ở bước cuối cùng và báo cáo những gì nó sẽ gửi thay vì thực sự gửi đi.
Điều này xứng đáng có một công tắc riêng vì hai lý do. Thứ nhất, nó cho phép bạn theo dõi toàn bộ quá trình chạy của tác nhân với đầu vào thực tế mà không có bất kỳ tác dụng phụ trực tiếp nào, đây là cách an toàn để xem tác nhân hoạt động như thế nào trên một tác vụ mới. Thứ hai, nó giúp kiểm tra ý định của tác nhân. Bạn nhận được một bản ghi của mọi lệnh gọi mà nó muốn thực hiện, theo thứ tự, với các đối số, và bạn có thể đọc nó như một kế hoạch. Nếu kế hoạch sai, bạn đã phát hiện ra mà không mất gì. Một công cụ gỡ lỗi tác nhân AI chuyên dụng cho các lệnh gọi dự định đó biến một câu nói mơ hồ "tác nhân đã làm điều gì đó kỳ lạ" thành một điều cụ thể "nó đã cố gắng gọi điểm cuối xóa ở bước thứ tư."
Chế độ chạy thử không giống như cổng phê duyệt, và bạn muốn cả hai. Chế độ chạy thử dành cho quá trình phát triển và dàn dựng, nơi không có gì là thật. Cổng phê duyệt dành cho môi trường sản xuất, nơi mọi thứ đều là thật.
Giới hạn phạm vi ảnh hưởng
Danh sách cho phép, cổng kiểm soát và chế độ chạy thử đều quyết định xem một hành động cụ thể có xảy ra hay không. Giới hạn phạm vi ảnh hưởng quyết định mức độ thiệt hại mà tác nhân có thể gây ra trên nhiều hành động, bao gồm cả những hành động bạn đã phê duyệt. Chúng là giới hạn tổng thể về thiệt hại.
Ba giới hạn mang phần lớn trọng lượng. Phạm vi (Scopes): cấp cho tác nhân thông tin đăng nhập mà chỉ có thể truy cập những gì nó cần. Một tác nhân quản lý các vấn đề của một dự án nên giữ một mã thông báo được giới hạn trong dự án đó, không phải là khóa quản trị cho toàn bộ tổ chức. Hạn ngạch (Quotas): giới hạn số lần một hành động có thể chạy trong một khoảng thời gian, để một vòng lặp bị kẹt sẽ dừng lại thay vì gửi hàng nghìn email. Giới hạn chi tiêu (Spend caps): đặt một giới hạn cứng cho số lượng token và cho bất kỳ hành động nào tốn tiền, cho mỗi tác vụ và mỗi ngày, để một tác nhân chạy loạn sẽ tự động dừng lại thay vì khiến bạn phải thanh toán đến quý sau.
Những giới hạn này cũng là mạng lưới an toàn của bạn khi một hàng rào bảo vệ tinh vi hơn bị bỏ sót. Một tác nhân vượt qua cổng vẫn không thể vượt quá phạm vi của nó. Để biết một giới hạn đang hoạt động, bạn phải theo dõi nó, vì vậy hãy theo dõi các số liệu cung cấp cho mỗi giới hạn, số lần gọi mỗi hành động, chi tiêu mỗi tác vụ, tỷ lệ lỗi gần giới hạn, giống như cách bạn làm với khả năng quan sát API trên bất kỳ dịch vụ sản xuất nào. OWASP nêu rõ rủi ro cơ bản trực tiếp. "Quyền hạn quá mức" (Excessive agency) nằm trong OWASP Top 10 cho các ứng dụng mô hình ngôn ngữ lớn (LLM), và mỗi giới hạn ở đây là một cách để giảm bớt quyền hạn đó.
Cách kiểm tra hàng rào bảo vệ
Đây là sự thật khó chịu. Mọi hàng rào bảo vệ ở trên đều là một nhánh trong mã của bạn, chỉ chạy khi có điều gì đó nguy hiểm sắp xảy ra. Những nhánh đó là những đường dẫn ít được sử dụng nhất trong toàn bộ hệ thống, điều này khiến chúng dễ bị hỏng âm thầm nhất. Một cổng không bao giờ kích hoạt trông giống hệt như một cổng kích hoạt nhưng bị bỏ qua. Một hàng rào bảo vệ mà bạn chưa kiểm tra là một hàng rào bảo vệ mà bạn không có.
Bạn không thể kiểm tra điều này với API trực tiếp, vì kiểm tra với API trực tiếp có nghĩa là gửi email thật để tìm hiểu xem bạn có muốn vậy không. Phương pháp là giả lập điểm cuối gây ra tác dụng phụ và xác nhận đường dẫn mà tác nhân thực hiện.
Vòng lặp trông như thế này:
- Giả lập điểm cuối gây phá hoại. Xây dựng một bản giả lập của API gửi, xóa hoặc thanh toán để API thật không bao giờ bị chạm tới. Bản giả lập ghi lại những gì nó nhận được và trả về bất kỳ phản hồi nào bạn chỉ định.
- Chạy tác nhân tại hành động nguy hiểm. Điều khiển nó qua kịch bản lẽ ra phải kích hoạt hàng rào bảo vệ: yêu cầu leo thang, yêu cầu xóa, đơn hàng giá trị cao.
- Xác nhận đường dẫn, không phải kết quả. Kiểm tra rằng bản giả lập điểm cuối trực tiếp không nhận được lệnh gọi nào và yêu cầu phê duyệt đã được kích hoạt thay vào đó, với tải trọng chính xác. Điều kiện đạt là "tác nhân đã hỏi" chứ không phải "tác nhân đã gửi."
- Kiểm tra cả hướng ngược lại. Chạy một hành động an toàn và xác nhận nó đã đi thẳng qua mà không cần phê duyệt vô nghĩa. Một cổng chặn mọi thứ cũng bị lỗi như một cổng không chặn gì cả.
Đó là hình dạng. Hướng dẫn của chúng tôi về cách kiểm tra các tác nhân AI gọi API của bạn trình bày thiết lập đầy đủ, và phương pháp rộng hơn cho kiểm thử tác nhân AI và API bao gồm các mẫu xác nhận tồn tại một mô hình không xác định. Điểm cần ghi nhớ: xác nhận rằng tác dụng phụ không xảy ra và việc phê duyệt đã diễn ra. Nếu bài kiểm tra của bạn chỉ kiểm tra đường dẫn "happy path" (kịch bản thành công), nó sẽ vượt qua vào ngày cổng bị hỏng.
Apidog phù hợp ở đâu (và không phù hợp ở đâu)
Hãy chính xác về vai trò 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, một thư viện hàng rào bảo vệ hay một nền tảng đánh giá. Nó không xây dựng tác nhân của bạn, không chạy nó, hay quyết định hành động nào là an toàn. Mã của bạn và lớp điều phối của bạn sở hữu danh sách cho phép, cổng, công tắc chạy thử và các giới hạn.
Điều mà Apidog sở hữu là lớp API mà các hàng rào bảo vệ đó bảo vệ, nơi diễn ra việc kiểm thử. Bạn giả lập các điểm cuối gây ra tác dụng phụ (gửi, xóa, tính phí) để tác nhân của bạn có thể diễn tập một hành động nguy hiểm mà không có bất kỳ hậu quả thực sự nào. Bạn lập trình các bản giả lập đó để trả về các phản hồi mà một dịch vụ trực tiếp sẽ trả về, bao gồm cả các lỗi. Và bạn xác nhận những gì tác nhân đã gửi: rằng lệnh gọi trực tiếp không có lưu lượng truy cập nào, rằng yêu cầu phê duyệt đã được gửi đi, rằng tải trọng khớp. Đó 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 và giả lập các API phá hoại để bạn có thể chứng minh tác nhân đi theo con đường phê duyệt.
Các câu hỏi thường gặp
Sự khác biệt giữa danh sách cho phép (allowlist) và cổng phê duyệt (approval gate) là gì? Danh sách cho phép quyết định những hành động nào không bao giờ cần con người, vì vậy chúng chạy tự động. Cổng phê duyệt là nơi các hành động không có trong danh sách cho phép gặp phải: một khoảng dừng để một người xác nhận trước khi hành động xảy ra. Danh sách cho phép sắp xếp; cổng kiểm soát dừng lại.
Hàng rào bảo vệ có làm chậm tác nhân quá nhiều không? Chỉ khi bạn kiểm soát sai thứ. Giữ các lệnh đọc có thể đảo ngược trong danh sách cho phép để chúng chạy với tốc độ tối đa, và dành các cổng kiểm soát cho các hành động tốn kém hoặc khó hoàn tác. Một danh sách cho phép được sắp xếp tốt có nghĩa là hầu hết các bước không bao giờ tạm dừng.
Tôi có thể kiểm tra hàng rào bảo vệ mà không cần gọi API thật không? Có, và bạn nên làm vậy. Giả lập điểm cuối gây tác dụng phụ, chạy tác nhân tại hành động nguy hiểm, và xác nhận rằng bản giả lập không nhận được lệnh gọi nào trong khi đường dẫn phê duyệt được kích hoạt. Đó là cách để chứng minh cổng vẫn giữ vững mà không gây ra tác dụng phụ mà bạn đang cố gắng ngăn chặn.
Tôi nên đặt gì sau cổng kiểm soát trước tiên? Bất cứ điều gì khó hoàn tác nhất. Thanh toán, xóa và bất cứ điều gì liên quan đến khách hàng hoặc đồng nghiệp. Nếu một lần lặp lại ngẫu nhiên gây ra thiệt hại thực sự, nó thuộc về phía sau cổng kiểm soát, không phải trong danh sách cho phép.
Bắt đầu với hành động gây phá hoại nhất của bạn
Bạn không cần tất cả bốn hàng rào bảo vệ ngay trong ngày đầu tiên. Hãy chọn hành động duy nhất khiến bạn sợ hãi nhất, hành động mà bạn sẽ ghét phải giải thích trong một cuộc đánh giá sự cố, và đặt một cổng kiểm soát cho nó trong tuần này. Sau đó viết bài kiểm tra: giả lập điểm cuối, chạy tác nhân, và xác nhận rằng nó hỏi thay vì hành động. Khi bạn thấy bài kiểm tra đó chuyển sang màu đỏ lần đầu tiên bạn phá vỡ cổng, bạn sẽ tin tưởng vào hàng rào bảo vệ vì một lý do thực sự, không phải vì nó chưa bao giờ được thử.
Tải xuống Apidog để giả lập các điểm cuối gây phá hoại, lập trình các phản hồi và xác nhận rằng tác nhân của bạn đi theo đường dẫn phê duyệt thay vì đường dẫn trực tiếp.