Agent hỏng lặp lại là tín hiệu vàng

Agent hỏng lặp lại là tín hiệu vàng

Đừng chỉ đổi model khi agent fail. Với builder, lỗi lặp lại nên được xem như bản đồ capability để huấn luyện, điều phối và đặt guardrail.

Có một kiểu bug làm team AI mất ngủ rất đều: agent không hỏng ngẫu nhiên, nó hỏng có cá tính. Hôm nay quên kiểm tra precondition trước khi gọi API. Mai vẫn vậy. Tuần sau đổi prompt dài hơn, model mới hơn, logging đẹp hơn — nó vẫn bẻ ghi sai ở đúng khúc cua đó.

Câu hỏi khó chịu là: nếu một agent fail cùng một kiểu nhiều lần, bạn nên coi đó là lỗi vận hành, lỗi prompt, hay lỗi năng lực của model?

Luận điểm của mình: hệ thống agent chỉ đáng tin khi bạn biến failure lặp lại thành capability rõ ràng, rồi gắn nó vào orchestration và guardrail. Đừng mặc định model mới nhất là đầu máy kéo được mọi toa. Có khi đường ray phía dưới mới là thứ đang lệch.

Sơ đồ minh họa cho bài Agent hỏng lặp lại là tín hiệu vàng

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

Tín hiệu chính: agent không chỉ fail, nó fail theo cụm

TRACE, một hệ thống training agentic từ Stanford, đáng soi không phải vì nó thêm một tên mới vào danh sách framework. Điểm đáng giữ là cách nó nhìn lỗi.

Thay vì gom mọi rollout thất bại rồi ném vào fine-tuning đại trà, TRACE hỏi: thiếu capability nào khiến agent fail lặp lại?

Một vài thuật ngữ cần neo nhanh:

TRACE chia các trajectory thành nhóm thành công và thất bại, rồi gắn nhãn từng cặp trajectory-capability: không liên quan, có mặt, hoặc thiếu. Một capability chỉ được giữ nếu nó vừa contrastive vừa high-coverage: nghĩa là thiếu nó xuất hiện rõ hơn ở nhóm fail, và nó bao phủ đủ nhiều lỗi để đáng xử lý.

Dịch sang tiếng người: nếu 10 lỗi khác nhau đều có mùi agent không kiểm tra dữ liệu đầu vào trước khi ghi database, thì đừng gọi đó là 10 bug. Hãy gọi đó là một capability gap.

Lớp ẩn bên dưới: training chỉ là một phần của đường ray

TRACE đi tiếp bằng cách tạo một synthetic environment — môi trường giả lập có kiểm chứng — cho từng capability được giữ lại. Mỗi môi trường cô lập một kỹ năng, giữ schema tool và format giống môi trường thật, rồi sinh task bằng seed. Vì verifier chạy bằng luật hoặc thuật toán, reward không cần người gắn nhãn hay LLM judge.

Sau đó, mỗi capability được train bằng một LoRA adapter — lớp tinh chỉnh nhẹ gắn lên model gốc — với GRPO, một thuật toán reinforcement learning dùng so sánh theo nhóm thay vì chỉ một đáp án đơn lẻ.

Nhưng nếu bạn đang build production, đừng đọc đoạn này rồi nghĩ: “À, vậy cứ train adapter là xong.” Không. TRACE cho mình một khung nghĩ lớn hơn:

Failure lặp lại phải đi qua ba tầng: diagnose → isolate → enforce.

Trong đó, orchestration là cách điều phối nhiều bước, nhiều tool, nhiều agent để hoàn thành việc. guardrail là rào kiểm soát để chặn hành vi sai trước khi nó gây hỏng thật.

Nếu chỉ train mà không enforce ở workflow, agent vẫn có thể trượt lại khi context dài, tool đổi schema, hoặc task production có nhiễu.

Ví dụ cụ thể: agent hỗ trợ vận hành đơn hàng

Ví dụ cụ thể: team bạn có agent xử lý ticket giao hàng. Agent được phép đọc order, kiểm tra trạng thái kho, gửi yêu cầu hoàn tiền, và trả lời khách.

Sau hai tuần, team thấy các lỗi sau:

  1. Agent hoàn tiền khi đơn vẫn đang trong thời gian giao lại.
  2. Agent báo hết hàng dù kho phụ còn tồn.
  3. Agent trả lời khách trước khi kiểm tra policy mới nhất.

Nhìn bề mặt, đây là ba bug. Nhìn theo capability, có thể chúng cùng nằm ở một chỗ: agent thiếu bước verify precondition trước hành động irreversible. Hành động irreversible là hành động khó quay lại, như hoàn tiền, khóa tài khoản, gửi email chính thức, hoặc ghi database.

Nếu xử lý kiểu cũ, team có thể thêm prompt:

Trước khi hành động, hãy kiểm tra cẩn thận mọi điều kiện liên quan.

Prompt này giống thông báo ở ga: nghe thì đúng, nhưng tàu đang chạy nhanh có khi chẳng ai kịp đọc.

Cách chắc hơn là biến nó thành lớp hệ thống:

capability: verify_precondition_before_irreversible_action
applies_to:
  - refund_order
  - cancel_subscription
  - send_customer_notice
required_checks:
  - latest_policy_loaded
  - order_status_verified
  - warehouse_fallback_checked
block_if_missing: true
log_fields:
  - missing_check
  - tool_call_id
  - proposed_action

Lúc này, capability không chỉ nằm trong đầu model. Nó nằm trong orchestration. Agent muốn gọi refund_order thì phải có bằng chứng đã qua các check bắt buộc. Nếu thiếu, workflow dừng hoặc chuyển sang human review.

Mổ hệ thống thành bốn lớp, đừng mổ theo tên tool

Một framework mình thấy hữu ích cho builder là COVE:

| Lớp | Câu hỏi cần trả lời | Artifact nên có |
|---|---|---|
| C — Capability | Agent thiếu kỹ năng tái dùng nào? | failure taxonomy, capability labels |
| O — Orchestration | Kỹ năng đó nằm ở bước nào trong workflow? | state machine, tool policy, routing rule |
| V — Verifier | Làm sao biết agent làm đúng mà không tự khen mình? | test, rule check, metric, sandbox |
| E — Economics | Có cần model lớn làm mọi bước không? | cost trace, cache plan, model routing |

Lớp E quan trọng hơn nhiều team nghĩ. Pattern kiểu model lớn làm planner, model nhỏ làm executor không chỉ là chuyện tiết kiệm token. Nó ép bạn tách vai trò: ai lập kế hoạch, ai thực thi, ai kiểm chứng.

Nguồn liên quan về Anthropic cho thấy một hướng thực dụng: dùng model đắt như manager hoặc advisor, còn model rẻ hơn xử lý phần chạy việc. Trong sản phẩm thật, điều này nên được nhìn như decision routing, không phải mẹo giảm bill.

Tương tự, loop engineering cũng nhắc một điều rất căn bản: loop đáng tiền khi có verifier — bộ kiểm chứng kết quả, state — trạng thái ghi lại đã thử gì, và stop condition — điều kiện dừng để tránh chạy vô hạn. Không có ba thứ này, agent loop chỉ là đoàn tàu đi chung ray nhưng không ai biết ga cuối ở đâu.

Điều đáng giữ: đừng sửa agent bằng cảm hứng

TRACE đáng học ở thái độ: sửa lỗi bằng capability có đo được, không sửa bằng linh cảm.

Nếu team bạn muốn áp dụng trong một buổi chiều, không cần dựng toàn bộ pipeline RL. Làm bản nhẹ trước:

  1. Lấy 30-50 trajectory gần nhất từ logs, gồm cả success và fail.
  2. Gắn nhãn lỗi theo capability, không theo symptom. Ví dụ: missing_precondition_check, wrong_record_retrieval, no_result_verification.
  3. Chọn capability có mặt trong nhiều fail nhưng ít thấy ở success. Chưa cần công thức phức tạp; chỉ cần đủ rõ để team đồng ý.
  4. Viết một verifier nhỏ cho capability đó. Có thể là unit test, rule check, hoặc script đọc trace.
  5. Đưa verifier vào orchestration trước tool nguy hiểm hoặc trước bước trả lời cuối.

Giả sử team bạn 5 người, agent đang xử lý internal support. Chỉ cần một capability như must_cite_source_before_policy_answer được enforce tốt, bạn đã giảm được một lớp rủi ro: agent trả lời policy theo trí nhớ thay vì theo tài liệu hiện hành.

Điểm mấu chốt: capability phải thành artifact. Nếu nó chỉ nằm trong postmortem, tuần sau nó lại biến thành bug mới.

Điều nên bỏ qua: chạy theo agent ồn ào nhất

Có ba thứ dễ bị thổi quá mức.

Thứ nhất, đổi model để né thiết kế hệ thống. Model mạnh hơn có thể giảm lỗi, nhưng không thay thế verifier và guardrail. Nếu failure nằm ở workflow, model mới chỉ giúp bạn chạy nhanh hơn tới cùng một điểm trật ray.

Thứ hai, synthetic data không mục tiêu. Dữ liệu giả lập rộng có thể hữu ích, nhưng nếu không nhắm vào capability thiếu, bạn đang chi compute cho những kỹ năng model đã có.

Thứ ba, multi-agent cho mọi việc. Nhiều agent không tự động làm hệ thống thông minh hơn. Nếu không rõ planner, executor, verifier, state và stop condition, bạn chỉ nhân số chỗ có thể fail.

Sau bài này, thứ mình muốn bạn nghĩ khác là: agent reliability không bắt đầu từ câu hỏi chọn model nào, mà từ câu hỏi lỗi lặp lại đang chỉ vào capability nào. Khi capability đã rõ, bạn mới quyết định nên train, thêm guardrail, đổi orchestration, hay route sang model khác.

Agent production không cần thêm khẩu hiệu tự tin. Nó cần bản đồ đường ray, tín hiệu dừng, và người biết bẻ ghi đúng lúc — không thì ga cuối sẽ là phòng incident lúc nửa đêm.

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

Nguồn tham khảo