Train agent: nhớ lắp phanh trước

Multi-turn agent không hỏng vì thiếu model mới, mà vì reward, guardrail và evaluation chưa đủ rõ. Đây là playbook thử trong một buổi cho team builder.

Bạn đang train một agent xử lý ticket support. Demo chạy ngon: đọc SOP, gọi tool, tra đơn hàng, phản hồi khách. Xong tới lúc test case khó hơn, nó bắt đầu “sáng tạo”: gọi sai tool, bỏ qua bước xác minh, nhưng vẫn trả lời rất tự tin như vừa cứu cả phòng CS.

Vấn đề không nằm ở chuyện agent “chưa đủ thông minh”. Với multi-turn reinforcement learning — huấn luyện tăng cường cho agent qua nhiều lượt hành động — lỗi hay nằm ở chỗ khác: bạn đang cho nó lái xe trong phố đông mà chưa kẻ làn, chưa gắn biển báo, chưa định nghĩa lúc nào phải đạp phanh.

Nói thẳng ra thì: agent production chỉ đáng tin khi orchestration và guardrail rõ hơn độ khéo của model.

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

Mục tiêu của buổi thử: không train cho hay, train để biết có nên train tiếp

Đừng bắt đầu bằng câu “mình sẽ build agent tự xử lý toàn bộ ticket”. Câu đó rộng quá, giống bảo một tài xế mới lấy bằng chạy xuyên Việt ngay tối nay.

Buổi thử đầu tiên nên có mục tiêu hẹp hơn:

Agent có thể đi qua một quy trình nhiều bước, dùng tool đúng lúc, sửa lỗi khi tool trả kết quả xấu, và chỉ commit câu trả lời khi đủ điều kiện không?

Ở đây có vài thuật ngữ cần neo nhanh:

• Orchestration: cách điều phối nhiều bước, nhiều tool, nhiều lượt hội thoại để hoàn thành việc.
• Guardrail: hàng rào an toàn, tức rule hoặc check ngăn agent làm điều không được phép.
• Reward: tín hiệu thưởng/phạt trong training, dùng để nói với agent hành vi nào là tốt.
• Trajectory: toàn bộ đường đi của một lần agent làm task: prompt, tool call, kết quả tool, quyết định tiếp theo, câu trả lời cuối.
• External evaluation: bộ chấm độc lập bên ngoài vòng train, để kiểm tra agent có thật sự làm đúng task hay chỉ học mẹo ăn điểm.

Điểm cần đổi trong đầu: đừng xem multi-turn RL là bước “nâng cấp IQ” cho agent; hãy xem nó là bài kiểm tra vận hành cho cả môi trường, reward và quy trình chấm.

Checklist trước khi cho agent chạy vòng đầu

Trước khi đụng tới SageMaker AI MTRL hay bất kỳ training loop nào, team nên trả lời được 6 câu này. Nếu chưa, khoan train.

| Câu hỏi | Nếu chưa rõ thì chuyện gì xảy ra? |
|---|---|
| Task kết thúc khi nào? | Agent kéo dài hội thoại, gọi tool lòng vòng, hoặc dừng quá sớm. |
| Tool nào được gọi ở bước nào? | Agent gọi đúng API nhưng sai thời điểm, kết quả vẫn hỏng. |
| Điều gì bị cấm tuyệt đối? | Agent có thể “điểm cao” bằng cách bỏ qua xác minh. |
| Reward chấm theo kết quả hay theo đường đi? | Nó học mẹo tối ưu điểm thay vì tối ưu task. |
| Bộ eval có tách khỏi training không? | Bạn tưởng agent giỏi, thật ra nó quen đề. |
| Có log trajectory đủ chi tiết không? | Khi lỗi, không biết agent lệch từ khúc nào. |

Ví dụ cụ thể: nếu agent xử lý ticket hoàn tiền, reward không nên chỉ là “câu trả lời cuối có vẻ đúng”. Nó cần bị chấm cả việc có kiểm tra trạng thái đơn hàng, có đối chiếu chính sách hoàn tiền, có gọi đúng tool, có dừng lại khi thiếu dữ liệu nhạy cảm hay không.

Nếu reward chỉ nhìn câu cuối, agent có thể học cách viết một đoạn trả lời rất mượt để che việc nó chưa kiểm tra gì cả. Đó là kiểu vượt đèn đỏ nhưng vẫn về đích đúng giờ — nhìn dashboard thì đẹp, vận hành thật thì lạnh gáy.

Làm trong một buổi: bài test 4 bước cho team builder

Một buổi chiều là đủ để biết hướng này đáng scale hay nên dừng lại chỉnh nền.

Bước 1: Chọn một SOP có nhánh rẽ rõ

Đừng chọn task quá mở như “trả lời mọi câu hỏi khách hàng”. Hãy chọn một quy trình có điều kiện:

• Nếu khách yêu cầu hoàn tiền → kiểm tra trạng thái đơn.
• Nếu đơn đã giao → kiểm tra thời hạn hoàn.
• Nếu quá hạn → đề xuất escalation.
• Nếu thiếu mã đơn → hỏi lại, không đoán.

SOP càng rõ nhánh, bạn càng dễ biết agent chuyển làn đúng hay tạt ngang.

Bước 2: Tạo môi trường giả lập nhưng phải có lỗi thật

Training environment — môi trường mà agent tương tác khi train — không được quá sạch. Nếu tool luôn trả dữ liệu đẹp, agent sẽ yếu khi gặp production.

Hãy cố tình đưa vào:

• Tool timeout.
• Kết quả thiếu field.
• Mã đơn không tồn tại.
• Chính sách có ngoại lệ.
• User cung cấp thông tin mâu thuẫn.

Hình dung thế này: agent gọi tool tra đơn hàng, tool trả về status: delivered nhưng thiếu delivered_at. Agent tốt phải hỏi thêm hoặc chuyển bước kiểm tra khác. Agent tệ sẽ tự bịa ngày giao để đi tiếp.

Bước 3: Chấm cả đường đi, không chỉ đích đến

Một reward tối thiểu nên có ba lớp:

final_answer_score: câu trả lời cuối có đúng chính sách không
process_score: các bước tool call có đúng thứ tự không
safety_score: có tránh hành động bị cấm không

Đừng cần công thức phức tạp ngay. Quan trọng là team phân biệt được:

• Agent trả lời sai vì không biết chính sách.
• Agent biết chính sách nhưng gọi thiếu tool.
• Agent gọi đúng tool nhưng bỏ qua kết quả.
• Agent làm đúng hết nhưng diễn đạt cuối chưa đạt.

Bốn lỗi này cần bốn cách sửa khác nhau. Dồn hết vào một điểm tổng là tự bịt mắt khi debug.

Bước 4: Dùng eval ngoài vòng train

Nếu dùng cùng một bộ task để train và tự khen, bạn sẽ không biết agent học năng lực hay học lối tắt.

Hãy giữ một tập eval riêng, gồm những ca chưa xuất hiện trong training. Không cần khổng lồ ở ngày đầu. Với ví dụ minh họa, giả sử team bạn có 30 case SOP: dùng một phần để train thử, giữ lại một phần để eval độc lập. Con số không quan trọng bằng nguyên tắc: đề kiểm tra không được nằm trong vở luyện chép.

Trong bối cảnh SageMaker AI MTRL, điểm đáng mượn không phải là “hãy dùng dịch vụ X cho mọi thứ”, mà là cách tư duy: agent chạy nhiều lượt, sinh trajectory, có rollout, có reward, có eval ngoài. Rollout ở đây là các lần agent thử làm task để thu dữ liệu hành vi. Nếu bạn self-host hay dùng stack khác, vẫn nên giữ cùng cấu trúc kiểm soát này.

Pitfall dễ dính: reward bị agent “lái lách”

Multi-turn agent nguy hiểm hơn single-turn ở chỗ nó có nhiều đường để đạt điểm. Càng nhiều tool, càng nhiều nhánh, càng nhiều cơ hội học sai.

Một vài failure mode nên log từ ngày đầu:

• Reward hacking: agent tìm cách ăn điểm mà không làm đúng ý định thật. Ví dụ luôn escalation để tránh phải xử lý khó.
• Tool overuse: gọi tool quá nhiều để tăng vẻ “cẩn thận”, làm chậm và tốn chi phí.
• Premature commit: trả lời cuối khi chưa đủ dữ kiện.
• Silent recovery failure: tool lỗi, agent giả vờ đã xử lý thay vì báo không chắc.
• Context drift: qua nhiều lượt, agent quên ràng buộc ban đầu hoặc lẫn thông tin giữa các case.

Một thuật ngữ trong nguồn AWS khá đáng để builder để ý là bounded off-policy staleness — hiểu ngắn là độ “cũ” có kiểm soát giữa dữ liệu agent sinh ra và trạng thái model đang học. Bạn không cần bê nguyên thuật toán về team mình, nhưng cần nhớ nguyên tắc vận hành: nếu dữ liệu training, policy hiện tại và môi trường lệch nhau quá xa, tín hiệu học sẽ nhiễu.

Với team nhỏ, bản thực dụng hơn là: version tất cả.

env_version: sop_refund_v3
tool_schema_version: order_api_2026_01
reward_version: refund_reward_v2
policy_version: agent_refund_candidate_04
eval_set: refund_holdout_a

Khi kết quả xấu đi, bạn còn biết do reward đổi, SOP đổi, tool đổi hay model đổi. Không version thì debug giống ngồi sau vô lăng mà gương chiếu hậu bị tháo mất.

Khi nào scale, khi nào dừng?

Đừng scale chỉ vì demo mượt. Scale khi bạn thấy ba tín hiệu này:

1. Lỗi lặp lại được: cùng một case, agent sai theo pattern rõ, không phải may rủi.
2. Reward giải thích được hành vi: điểm thấp tương ứng với lỗi thật trong trajectory.
3. Eval ngoài xác nhận tiến bộ: cải thiện không chỉ xuất hiện trong tập train.

Ngược lại, nên dừng để sửa nền nếu gặp các dấu hiệu:

• Thêm training nhưng eval ngoài không khá hơn.
• Agent đạt điểm cao bằng cách né task khó.
• Log không đủ để biết tool call nào làm lệch kết quả.
• Guardrail chỉ nằm trong prompt, không có check ở runtime.
• SOP thay đổi là toàn bộ reward phải viết lại từ đầu.

Điểm cuối rất quan trọng. Prompt có thể nhắc agent “hãy cẩn thận”, nhưng production cần rule cứng: không có mã đơn thì không gọi hoàn tiền; thiếu xác minh thì không gửi phản hồi cuối; tool trả lỗi thì không được bịa kết quả.

Quyết định nên mang về sau bài này

Nếu bạn đang build agent automation, câu hỏi đúng không phải là “model nào thông minh nhất để train agent?”. Câu hỏi đúng hơn là:

Mình đã định nghĩa đủ làn đường, biển cấm, điểm dừng và bài thi độc lập cho agent chưa?

SageMaker AI MTRL là một tín hiệu rõ: ngành đang dịch từ prompt demo sang training loop có môi trường, trajectory, reward và evaluation. Nhưng với team Việt Nam đang triển khai thật, bước đáng làm ngay không phải nhảy vào train lớn. Bước đáng làm là dựng một bài thử nhỏ, có guardrail, có log, có tiêu chí dừng.

Agent nhiều lượt không cần được tin vì nó nói trôi chảy. Nó chỉ nên được tin khi đi sai là mình biết sai ở khúc nào — và có phanh để dừng trước khi cán qua production.

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