Agent đáng tin nhờ khung nuôi nhốt

Agent đáng tin nhờ khung nuôi nhốt

Đừng chọn agent như chọn model thắng benchmark. Với production, thứ cần thiết hơn là một harness thay model được, đo được đường đi, và chặn rủi ro đúng chỗ.

Một team bảo mật khoe với mình: agent của họ tìm được bug trong repo demo. Ba ngày sau, cũng agent đó chạy trên monorepo thật thì trả về một rổ cảnh báo nhìn rất thuyết phục, nhưng triage xong mới thấy phần lớn là báo động giả. Không ai giận model cả. Chỉ hơi buồn, kiểu phát hiện ra con chó giữ nhà sủa rất hăng… nhưng sủa cả lá rơi.

Vấn đề không nằm ở chuyện agent có thông minh không. Vấn đề là bạn đang thả agent vào hệ thống production mà chưa có harness.

Harness ở đây là lớp kiểm thử, điều phối, lưu trạng thái và guardrail bao quanh agent. Nó không làm model giỏi lên ngay lập tức, nhưng nó quyết định model được phép nhìn gì, thử gì, xác nhận ra sao, và khi nào phải dừng. Với hệ thống agentic, đặc biệt là automation cho security, coding, ops, hay data workflow, đây mới là khác biệt giữa demo đẹp và pipeline dùng được.

Sau bài này, mình muốn bạn đổi một cách nghĩ: đừng hỏi model nào làm agent tốt nhất; hãy hỏi hệ thống của bạn có thay model, kiểm chứng hành vi, và hạ rủi ro theo từng bước được không.

Sơ đồ minh họa cho bài Agent đáng tin nhờ khung nuôi nhốt

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

Mục tiêu: dựng harness, không dựng sân khấu demo

Một agent chạy việc thật thường đi qua nhiều vòng:

  1. nhận mục tiêu,
  2. lập giả thuyết,
  3. đọc code hoặc tài liệu,
  4. gọi tool,
  5. sửa kế hoạch,
  6. đưa kết luận,
  7. có thể tạo patch hoặc ticket.

Nếu bạn chỉ gắn guardrail ở đầu vào và đầu ra, bạn đang bỏ trống phần nguy hiểm nhất: giữa vòng lặp.

Trong vulnerability scanning, ví dụ từ Cloudflare rất đáng chú ý: họ không xem mô hình đơn lẻ, prompt đơn lẻ, hay một phiên agent đơn lẻ là tương lai của workflow dạng này. Khi chuyển từ một skill bảo mật cục bộ sang pipeline quét liên tục ở quy mô fleet, model phải được coi là thành phần có thể thay thế. Một model có thể dùng cho discovery, model khác dùng cho validation. Mục tiêu là giảm việc cả hệ thống nhìn code qua cùng một lăng kính.

Nói thẳng ra thì: agent production giống một khu rừng có nhiều tầng tán. Model là một loài trong đó, không phải toàn bộ hệ sinh thái. Nếu chỉ chăm một cây cao nhất, bạn vẫn có thể mất cả rừng khi sâu bệnh đến từ tầng dưới.

Checklist 6 lớp cho một agent harness

Đây là checklist mình sẽ dùng nếu phải review một hệ thống agent trước khi cho chạy trên repo thật hoặc workflow thật.

| Lớp | Câu hỏi phải trả lời | Nếu thiếu thì sao |
|---|---|---|
| Model routing | Việc nào dùng model nào, có thay được không? | Lock-in vào một model, khó so sánh và khó phục hồi khi model đổi behavior |
| State control | Agent nhớ giả thuyết, bước đã thử, bằng chứng ở đâu? | Lặp việc, nhảy kết luận, hoặc quên lý do đã loại một hướng |
| Tool boundary | Tool nào được gọi, với tham số nào, trong trạng thái nào? | Agent gọi bừa, tốn tiền, hoặc đụng vùng không nên đụng |
| Process eval | Có đo đường đi, không chỉ kết quả cuối không? | Một đáp án đúng có thể đến từ quy trình rất nguy hiểm |
| Guardrail per turn | Mỗi bước có check rủi ro riêng không? | Một output sạch cuối cùng che mất hành vi bẩn ở giữa |
| Triage queue | Candidate được gom, lọc, dedupe, ưu tiên thế nào? | Team người bị ngập trong cảnh báo giả |

Hai thuật ngữ cần neo nhanh:

Nguồn từ Hugging Face nhấn mạnh một ý rất thực dụng: với phần mềm dành cho agent sử dụng, không phải thành công nào cũng giống nhau. Agent có thể ra kết quả đúng nhưng đi đường vòng, bỏ qua API chính thức, tự viết lại logic, hoặc dùng tool theo cách tốn kém. Vì vậy benchmark cho agent nên nhìn vào cả trace, marker, và hành vi khi tool thay đổi.

Từng bước: một buổi chiều dựng bản harness tối thiểu

Bạn không cần làm một hệ thống enterprise ngay. Nhưng bạn có thể dựng bản tối thiểu đủ để thấy agent có đáng tin hơn không.

Bước 1: Tách vai trò model theo pha

Đừng để một model làm từ đầu đến cuối nếu task có rủi ro cao. Với security scanning hoặc code automation, chia thành ba pha:

Ví dụ cấu hình đơn giản:

pipeline:
  discoverer:
    model: model_a
    tools: [repo_search, dependency_graph]
  validator:
    model: model_b
    tools: [static_check, test_runner]
  summarizer:
    model: model_c
    tools: [ticket_writer]

Điểm quan trọng không phải tên model. Điểm quan trọng là interface giữa các pha phải ổn định. Hôm nay bạn dùng model A, tuần sau đổi model B, pipeline vẫn chạy được.

Bước 2: Ghi trace như ghi nhật ký hiện trường

Trace là lịch sử từng bước agent đã làm: đọc file nào, gọi tool nào, input/output ra sao, vì sao chuyển hướng. Với builder, trace không phải để trang trí dashboard. Nó là vật chứng khi agent tạo kết quả lạ.

Hình dung thế này: agent báo có lỗ hổng auth bypass. Nếu trace chỉ có kết luận, reviewer phải đọc lại từ đầu. Nếu trace ghi rõ agent đã đi qua route nào, dependency nào, test nào, reviewer có thể xác nhận nhanh hơn và biết cảnh báo đó đáng tin đến đâu.

Một schema tối thiểu:

{
  "run_id": "scan-2026-06-20-001",
  "phase": "validator",
  "hypothesis": "auth bypass via missing tenant check",
  "evidence": ["apps/api/routes/billing.ts", "packages/auth/session.ts"],
  "tool_calls": ["repo_search", "static_check"],
  "decision": "needs_human_review",
  "confidence_label": "medium"
}

Nếu không muốn dùng JSON, dùng bảng cũng được. Miễn là bạn có thể trả lời: agent đã dựa vào đâu?

Bước 3: Đặt guardrail ở từng khúc cua

Guardrail là lớp kiểm tra an toàn hoặc chính sách. Với agentic workflow, guardrail không nên chỉ nằm ở prompt đầu và response cuối. AWS Bedrock Guardrails có hướng đi đáng chú ý với API dạng detect-only, trả về điểm số cho từng safeguard để ứng dụng tự quyết định block, retry, bypass, hay log.

Dù bạn dùng AWS hay tự dựng, pattern nên là:

Ví dụ minh họa, giả sử team bạn có agent tạo ticket bảo mật:

if guardrail.score(output, check = sensitive_data) > threshold:
    redact(output)
    log_event(run_id, check)

if guardrail.score(action, check = destructive_change) > threshold:
    require_human_approval(action)

Đừng hardcode mọi thứ thành block. Có bước nên chặn, có bước chỉ cần log, có bước nên retry với instruction hẹp hơn. Production hơn nhau ở chỗ đó.

Bước 4: Biến raw candidate thành queue có thể xử lý

Agent rất giỏi tạo danh sách. Người vận hành thì không thích chết chìm trong danh sách.

Với vulnerability harness, phần khó không chỉ là tìm ra hàng loạt candidate. Khó hơn là gom trùng, truy dependency xuyên repo, xác nhận bằng bằng chứng khác, rồi đưa ra hàng đợi triage đủ sạch để con người xử lý.

Ở đây, bạn nên có bốn trạng thái tối thiểu:

Trạng thái cuối rất quan trọng. Nếu không lưu lý do loại, lần chạy sau agent có thể đào lại đúng cái hố cũ. Trong rừng, xác mục không biến mất vô ích; nó nuôi tầng đất. Trong harness, false positive đã xử lý cũng phải trở thành dữ liệu vận hành.

Pitfall: benchmark cuối bài không cứu được agent giữa đường

Hiểu lầm phổ biến là: cứ chọn model đạt điểm cao nhất cho coding hoặc reasoning là agent sẽ ổn. Sai ở chỗ production không chỉ cần câu trả lời đúng. Production cần hành vi kiểm soát được.

Một agent có thể:

Đây là lý do process eval đáng tiền. Bạn nên chấm các marker như:

Với open-source model, bài toán còn thú vị hơn: bạn có thể giữ model và thay revision, hoặc giữ revision và so nhiều model nhỏ. Nhưng đừng biến việc này thành cuộc thi sắc đẹp benchmark. Hãy benchmark trên tool, repo, policy, và failure mode thật của bạn.

Nếu là mình, mình sẽ bắt đầu từ quyết định này

Mình sẽ không bắt đầu bằng câu: “team nên dùng agent framework nào?”. Câu đó đến sau.

Mình sẽ bắt đầu bằng decision memo ngắn:

  1. Task nào đủ giá trị để agent hóa? Chọn việc lặp lại, có bằng chứng kiểm tra được, và sai thì sửa được.
  2. Pha nào cần model khác kiểm tra chéo? Discovery và validation nên tách nếu rủi ro cao.
  3. Guardrail nào chạy ở bước nào? Mỗi tool call nhạy cảm phải có chính sách riêng.
  4. Trace nào bắt buộc lưu? Không có trace thì không có postmortem.
  5. Candidate đi vào queue nào? Không để agent ném thẳng kết luận vào Jira như lá rụng mùa mưa.

Khi làm xong năm câu này, bạn mới chọn framework, model, cloud API, hay self-host. Thứ tự này nghe kém hào nhoáng hơn, nhưng đỡ đau hơn khi có incident.

Takeaway gọn: agent production không đáng tin vì nó thông minh; nó đáng tin khi bị đặt trong một harness biết thay model, soi quá trình, và chặn đúng thời điểm. Còn nếu thả rông rồi cầu mong nó ngoan, thì chúc bạn may mắn — rừng nào cũng có muỗi.

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

Nguồn tham khảo