Agent chạy thật cần cầu chì theo chặng

Agent chạy thật cần cầu chì theo chặng

Một agent production không nên bị chặn bằng một cánh cổng chung. Cách đúng là đặt guardrail ở từng chặng, rồi quyết định block, retry hay log theo ngưỡng rõ ràng.

Có lần mình xem một agent nội bộ làm việc rất ngoan: nhận yêu cầu, gom tài liệu, gọi tool, rồi viết draft. Đến lúc gần xong, nó lại suýt đưa ra một câu trả lời chứa dữ liệu nhạy cảm vì đoạn tool output lẫn vào final prompt. Không ai cố tình sai; chỉ là vòng lặp bị cấp điện quá thẳng tay, không có cầu chì ở đúng nhánh.

Nói thẳng ra thì, với agent production, guardrail không phải cánh cổng đầu vào. Nó là bộ cầu chì đặt theo từng chặng: chỗ nào có dòng điện mạnh thì chỗ đó cần ngắt riêng, không phải đợi nổ aptomat cả hệ thống.

Sơ đồ minh họa cho bài Agent chạy thật cần cầu chì theo chặng

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: đừng hỏi "có guardrail chưa?"

Câu hỏi đúng không phải là có một lớp chặn chung hay không. Câu hỏi đúng là: chặng nào của agent cần kiểm tra, kiểm tra bằng tín hiệu gì, và vượt ngưỡng thì làm gì.

Điểm mới của kiểu API như InvokeGuardrailChecks là bạn không phải dựng hẳn một guardrail resource cồng kềnh cho mọi tình huống. Bạn có thể gọi kiểm tra ở bất kỳ turn nào trong agentic loop — tức vòng lặp tác vụ của agent — rồi để ứng dụng quyết định block, retry, bypass, hay log. API này chạy ở chế độ detect-only (chỉ phát hiện, chưa tự chặn), nên quyền quyết định vẫn nằm trong code của bạn.

Đó là thay đổi rất đáng kể trong tư duy vận hành. Trước đây nhiều team đặt an toàn như một cổng duy nhất ở đầu vào hoặc đầu ra. Với agent, như vậy hơi giống cắt điện cả tầng chỉ vì một ổ cắm có dấu hiệu chập mạch. Bạn sẽ an toàn hơn một chút, nhưng hệ thống cũng dễ bị ì và khó hiểu vì sao nó dừng.

Checklist trước khi gắn cầu chì

Trước khi viết code, mình thường buộc team trả lời 5 câu này:

| Câu hỏi | Việc cần chốt |
|---|---|
| Agent có những chặng nào? | Prompt người dùng, tool call, tool output, memory write, final response |
| Chặng nào rủi ro nhất? | Chỗ nào có thể rò dữ liệu, gọi nhầm tool, hoặc khuếch đại prompt injection |
| Mỗi chặng cần kiểm tra gì? | PII, policy, nội dung độc hại, dữ liệu nội bộ, prompt tampering |
| Vượt ngưỡng thì làm gì? | block, retry, bypass, hay log |
| Ai theo dõi kết quả? | Người sở hữu agent, không phải chỉ team platform |

Ví dụ cụ thể: nếu agent của bạn chỉ đọc tài liệu nội bộ rồi tóm tắt, rủi ro lớn nhất có thể nằm ở đoạn final response. Nhưng nếu agent còn được gọi tool bên ngoài, thì nguy cơ thật sự lại nằm ở output của tool. Một câu trả lời từ tool đôi khi nguy hiểm hơn cả prompt của người dùng, vì nó đi vào model với vẻ rất "hợp lệ".

Khi đã có checklist này, bạn mới chọn được ngưỡng. threshold (ngưỡng) không phải con số trang trí trong config; nó là quyết định vận hành. Ngưỡng quá thấp thì agent sẽ tắc thở. Ngưỡng quá cao thì guardrail thành đồ trang trí.

Từng bước trong một buổi chiều

Nếu mình phải triển khai cho một team nhỏ, mình sẽ đi theo 4 bước này.

1. Vẽ lại vòng lặp agent

Đừng bắt đầu từ policy. Bắt đầu từ luồng thật: user hỏi gì, agent nghĩ gì, tool nào được gọi, dữ liệu nào đi qua, và ở đâu nó viết vào memory. Chỉ cần một sơ đồ đơn giản là đủ.

Điểm cần đánh dấu là những chỗ có thể làm hệ thống lệch nhịp: trước tool call, sau tool output, trước khi ghi nhớ dài hạn, và ngay trước final response.

2. Chèn kiểm tra ở chỗ có rủi ro

Nếu agent đi qua nhiều chặng, đừng áp cùng một kiểm tra cho mọi chặng. Mỗi chặng có một profile rủi ro khác nhau.

Phần hay của cách làm này là bạn không cần chặn từ đầu đến cuối. Bạn chỉ kiểm đúng nhánh đang nóng.

3. Quy ước rõ hành động

Ở đây mình thích một bảng quyết định rất thực dụng:

# ví dụ minh họa
scores = invoke_guardrail_checks(payload)

if scores["sensitive_info"] >= threshold_block:
    return block()

if scores["policy"] >= threshold_retry:
    return retry_with_tighter_prompt()

return log_and_continue()

Đây không phải công thức duy nhất, nhưng nó buộc team phải trả lời một điều quan trọng: khi score tăng, hệ thống sẽ làm gì. Không có câu trả lời này thì guardrail chỉ là dashboard đẹp.

4. Ghi trace để còn biết vì sao nó dừng

Một agent tốt không chỉ cần kiểm tra. Nó cần dấu vết đủ rõ để sau này còn biết chỗ nào hỏng. Nếu bạn chỉ lưu điểm số mà không lưu trace, bạn sẽ biết có chập mạch, nhưng không biết nhánh nào nóng.

Đó là chỗ mình thích ghép guardrail với failure diagnosis, tức phân tích nguyên nhân gốc. Cái này rất quan trọng khi agent đã chạy thật, vì lúc ấy câu hỏi không còn là "có lỗi hay không" mà là "lỗi nằm ở prompt, tool, hay orchestration".

Những chỗ hay chập mạch

Có 4 lỗi mình thấy team rất hay gặp:

  1. Một guardrail cho mọi chặng. Làm vậy nhìn gọn, nhưng rủi ro của tool output và final response không bao giờ giống nhau.
  2. Chỉ log mà không có quyền dừng. Có log để xem lại là tốt, nhưng nếu mọi thứ đều phải qua tay người trực thì agent không còn là agent nữa.
  3. Ngưỡng đặt theo cảm giác. Đây là kiểu "nghe hợp lý" lúc demo, rồi về production mới thấy hoặc quá chặt hoặc quá lỏng.
  4. Không tách an toàn khỏi vận hành. Nếu team platform làm hết còn team ứng dụng không hiểu vì sao bị block, hệ thống sẽ rất khó sống lâu.

Ngoài ra, đừng quên một bài toán khác: agent càng đọc nhiều thứ, càng chạy nhiều bước, càng dễ làm đầy context window — vùng ngữ cảnh mà model còn giữ được trong một lượt xử lý. Khi đó, kiểm tra an toàn không chỉ là chuyện policy; nó còn là chuyện giữ cho luồng điều phối không bị ngập.

Khi nào nên mở rộng, khi nào nên dừng

Nếu là mình, mình sẽ bắt đầu rất nhỏ: hai checkpoint là đủ cho bản đầu tiên — một ở trước tool call, một ở trước final response. Chỉ khi nào thấy rõ rủi ro mới mở rộng sang tool output hoặc memory write.

Bạn nên scale khi:

Bạn nên dừng lại và thu hẹp khi:

Điều mình muốn bạn mang về sau bài này là một đổi khác khá cụ thể: đừng thiết kế guardrail như một cổng an ninh chung, hãy thiết kế nó như hệ thống cầu chì theo từng nhánh của agent loop. Khi đó, bạn mới thật sự kiểm soát được orchestration (điều phối) thay vì chỉ đứng nhìn model chạy.

Xây agent production mà để an toàn ở đoạn cuối thì khác gì lắp cầu chì sau ổ cắm — nhìn thì yên tâm, nhưng lúc có tia lửa, mùi khét vẫn tới trước.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo