Cách thêm guardrail cho AI agent chạy LLM cục bộ với Gemma 4, Ollama và OpenAI Agents SDK

Một AI agent có thể tự quyết định gọi công cụ nào và xử lý kết quả ra sao. Sự linh hoạt này rất hữu ích, nhưng cũng đặt ra yêu cầu về những ranh giới trong quá trình thực thi.

Phản ứng đầu tiên của nhiều người là thêm chỉ dẫn (instruction) mô tả hành vi mong muốn. Tuy vậy, chỉ dẫn chỉ là một dạng ràng buộc "mềm": không có gì bảo đảm agent sẽ luôn tuân thủ. Guardrail thì khác — đây là một điểm kiểm soát tại thời điểm chạy (runtime checkpoint), nơi ta có thể xác thực đầu vào hoặc đầu ra của agent, chấp nhận, từ chối hoặc chỉnh sửa trước khi quá trình tiếp tục.

Bài viết này hướng dẫn cách thêm guardrail runtime bằng OpenAI Agents SDK, sử dụng mô hình Gemma 4 E4B chạy cục bộ qua Ollama. Mục đích là chứng minh các guardrail này cũng áp dụng được cho agent dùng mô hình tự host, chứ không chỉ giới hạn ở các mô hình của OpenAI.

Guardrail nằm ở đâu trong luồng chạy của agent?

Một lượt chạy agent điển hình trải qua nhiều giai đoạn: nhận yêu cầu, quyết định hành động, gọi công cụ, xử lý kết quả và cuối cùng tạo phản hồi. OpenAI Agents SDK cho phép đặt guardrail tại các điểm khác nhau dọc theo quá trình này:

• Input guardrail: kiểm tra yêu cầu trước khi agent bắt đầu.
• Tool-input guardrail: kiểm tra lệnh gọi công cụ trước khi công cụ nhận tham số.
• Tool-output guardrail: kiểm tra kết quả của công cụ trước khi trả về cho agent.
• Output guardrail: kiểm tra phản hồi cuối cùng trước khi hiển thị cho người dùng.

Cách phân loại này cho phép đặt ranh giới đúng tại điểm cần thiết. Tùy vị trí và cách triển khai, guardrail có thể cho phép agent tiếp tục, từ chối một giá trị, hoặc thay thế bằng phiên bản đã chỉnh sửa.

Xây dựng một agent hỗ trợ khách hàng có rào chắn

Đặt ra tình huống

Giả sử ta xây một agent hỗ trợ khách hàng nhỏ. Khách hàng liên hệ cửa hàng trực tuyến vì khoản hoàn tiền chưa về. Để trả lời, agent tra cứu hồ sơ của đơn hàng đó.

Dữ liệu đến từ nhiều phần khác nhau của hệ thống hỗ trợ. Trong đó có những thông tin có thể chia sẻ cho khách như số tiền hoàn, trạng thái hiện tại và thời gian xử lý dự kiến; nhưng cũng có các chi tiết nội bộ phải giữ kín, chẳng hạn mã hoàn tiền nội bộ, điểm rủi ro gian lận, và đánh giá rằng tài khoản từng bị gắn cờ vì nghi ngờ lạm dụng hoàn tiền nhiều lần.

Tất cả các bản ghi này thuộc cùng một hồ sơ và có thể được trả về bởi cùng một lần tìm kiếm. Một nhân viên hỗ trợ là người sẽ biết chi tiết nào nên dùng, nhưng agent thì không phải lúc nào cũng phân biệt được một cách đáng tin cậy. Đây chính là lý do cần đến guardrail.

Định nghĩa một agent cục bộ (chưa có rào chắn)

Trước tiên cần cài Ollama từ ollama.com, sau đó tải mô hình:

ollama pull gemma4:e4b

Ollama cung cấp một endpoint cục bộ tương thích với OpenAI, nên ta có thể kết nối bằng AsyncOpenAI. Nhờ cấu hình này, OpenAI Agents SDK có thể dùng Gemma 4 — tức là tận dụng được các tính năng agent và guardrail của SDK nhưng với mô hình chạy trên máy của mình.

Tiếp theo là công cụ tìm kiếm để agent truy cập các bản ghi hỗ trợ. Hàm này nhận truy vấn, tách thành các từ khóa, rồi đối chiếu với mã bản ghi, loại bản ghi và nội dung; bản ghi nào khớp sẽ được trả về dưới dạng JSON.

Sau đó định nghĩa agent với tên, chỉ dẫn ("Tra cứu yêu cầu hỗ trợ bằng các bản ghi sẵn có và chuẩn bị phản hồi dành cho khách hàng"), mô hình và công cụ tìm kiếm. Đây là phiên bản cơ sở chưa có ranh giới runtime nào.

Chạy agent chưa có rào chắn

Khi chạy với yêu cầu của khách — "Khoản hoàn tiền cho đơn MUN-2048 vẫn chưa về. Hãy cho tôi biết mọi thứ đã xảy ra" — agent trả lời khá đầy đủ: số tiền hoàn 120 EUR đã được duyệt, khoản hoàn từng bị giữ để rà soát gian lận thủ công, hiện đang chờ nhà cung cấp thanh toán xử lý, và thời gian thường mất 5 đến 10 ngày làm việc.

Phần lớn câu trả lời là hữu ích và phù hợp. Nhưng agent cũng nói với khách rằng tài khoản của họ từng bị gắn cờ vì nghi ngờ lạm dụng hoàn tiền nhiều lần. Đó là thông tin không nên xuất hiện trong phản hồi dành cho khách hàng.

Thêm guardrail và chạy lại

Mục tiêu là xóa các trường nội bộ sau khi công cụ tìm kiếm trả về bản ghi, nhưng trước khi những bản ghi đó được chuyển lại cho agent. Như vậy agent sẽ không bao giờ nhìn thấy thông tin nhạy cảm, và do đó không có cách nào làm rò rỉ chúng cho khách hàng.

Đây là chỗ một tool-output guardrail phát huy tác dụng. Về mặt khái niệm, guardrail này chạy sau khi search_support_records trả về JSON thô, nhưng trước khi kết quả đó quay lại agent. Bằng cách chặn kết quả, guardrail có thể cho phép, từ chối hoặc thay thế đầu ra của công cụ.

Cách triển khai gồm các bước:

• Định nghĩa tập hợp các trường nhạy cảm cần xóa, gồm mã hoàn tiền nội bộ, điểm rủi ro gian lận và đánh giá nội bộ hồ sơ.
• Viết hàm guardrail: phân tích kết quả công cụ, xóa từng trường nhạy cảm ở mọi bản ghi nơi nó xuất hiện, rồi dựng lại chuỗi JSON đã được làm sạch.
• Dùng ToolGuardrailFunctionOutput.reject_content() để từ chối đầu ra gốc của công cụ và thay bằng phiên bản đã làm sạch.
• Gắn guardrail vào công cụ tìm kiếm thông qua tham số tool_output_guardrails, sau đó gán lại công cụ này cho agent.

Khi chạy lại với đúng yêu cầu cũ, phản hồi lần này vẫn đầy đủ thông tin khách hàng cần: khoản hoàn 120 EUR đã được duyệt, quá trình rà soát thủ công đã hoàn tất và khoản tiền đã được chuyển cho nhà cung cấp thanh toán, hiện đang chờ xử lý, thời gian thường 5 đến 10 ngày làm việc.

Điểm khác biệt duy nhất: câu trả lời không còn tiết lộ rằng tài khoản của khách từng bị gắn cờ vì nghi ngờ lạm dụng hoàn tiền.

Kết luận

Bài viết đã trình bày cách triển khai guardrail với OpenAI Agents SDK. Có nhiều vị trí để áp đặt ranh giới runtime như vậy. Để quyết định cần loại nào, hãy tự hỏi:

• Yêu cầu có nên bị từ chối trước khi agent bắt đầu không? Dùng input guardrail.
• Tham số của công cụ có nên được kiểm tra trước khi hành động được thực thi không? Dùng tool-input guardrail.
• Dữ liệu do công cụ trả về có nên được lọc trước khi agent sử dụng không? Dùng tool-output guardrail.
• Phản hồi cuối cùng có nên được kiểm tra trước khi người dùng thấy không? Dùng output guardrail.

Với các đội ngũ phát triển tại Việt Nam đang tự host mô hình để tiết kiệm chi phí hoặc để dữ liệu không rời khỏi hạ tầng nội bộ, cách tiếp cận này đặc biệt đáng lưu ý: guardrail chạy ở tầng SDK nên vẫn hoạt động đầy đủ, bất kể mô hình phía sau là dịch vụ đám mây hay một LLM cục bộ.