Agent hỏng thì đừng chỉ nhìn điểm số

Agent hỏng thì đừng chỉ nhìn điểm số

Một playbook mổ xẻ agent production theo dấu vết lỗi: từ trace, detector, causal chain đến guardrail đủ rõ để sửa đúng chỗ.

Có một kiểu báo động làm tech lead mất ngủ: dashboard báo agent tụt chất lượng, nhưng không nói vì sao. Goal completion rơi xuống. Tool selection lệch. User bắt đầu gửi screenshot kỳ quặc. Cả team mở trace lên như đứng trước hiện trường, ai cũng thấy có chuyện, nhưng chưa ai tìm được dấu vân tay.

Điểm số evaluation cho bạn biết agent đã ngã. Nhưng production không thưởng huy chương cho người phát hiện cái xác đầu tiên. Câu hỏi đáng tiền hơn là: nó ngã ở đâu, vì quyết định nào, và sửa ở lớp nào?

Luận điểm của mình trong bài này: hệ thống agent chỉ đáng tin khi bạn thiết kế được đường đi từ failure signal đến root cause rồi đến fix ownership. Không có đường đó, orchestration dù bóng bẩy đến đâu cũng chỉ là một màn demo biết đi.

Sơ đồ minh họa cho bài Agent hỏng thì đừng chỉ nhìn điểm số

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

Đừng hỏi “agent có pass không”, hãy hỏi “lỗi thuộc lớp nào”

Nhiều team đang dùng evaluation như bài kiểm tra cuối kỳ: chạy bộ test, lấy điểm, rồi tranh luận model nào thông minh hơn. Cách này ổn ở giai đoạn prototype, nhưng khi agent vào production, điểm tổng hợp dễ che mất nguyên nhân thật.

Một agent fail có thể vì nhiều lớp khác nhau:

Strands Evals đưa ra một hướng đáng chú ý: dùng detector để đọc execution trace, tức nhật ký từng bước agent đã làm, rồi phân loại failure, gán confidence score và dựng causal chain — chuỗi nguyên nhân dẫn đến triệu chứng phía sau. Điểm hay không nằm ở tên SDK, mà ở tư duy vận hành: evaluation không dừng ở chấm điểm; nó phải mở được hồ sơ điều tra.

Framework 4 lớp: Trace → Detector → Causal Chain → Guardrail

Nếu team bạn đang build agent cho coding, research, phân tích tài liệu hay automation nội bộ, mình sẽ không bắt đầu bằng câu “thêm subagent đi”. Mình sẽ bắt đầu bằng bốn lớp sau.

1. Trace: giữ lại hiện trường đủ sạch

Trace không chỉ là log dài ngoằng. Trace tốt cần trả lời được:

Hình dung thế này: nếu một bạn thực tập sinh gửi nhầm email cho khách hàng, bạn không chỉ hỏi “em có sai không?”. Bạn cần xem brief ban đầu, tài liệu bạn ấy đọc, người duyệt, và phiên bản file cuối. Agent cũng vậy. Không có trace, bạn chỉ đang đoán mò trên đống tro.

2. Detector: biến trace thành loại lỗi có tên

Detector là lớp tự động đọc trace để tìm pattern lỗi. Với builder, giá trị của detector không phải “AI đi chẩn đoán AI” cho vui. Giá trị là chuẩn hóa ngôn ngữ giữa các vai:

Nếu detector nói “tool parameter mismatch” hoặc “instruction conflict”, cuộc họp sửa lỗi ngắn hơn rất nhiều so với câu “agent ngu quá”.

3. Causal chain: đừng sửa triệu chứng cuối cùng

Một output sai thường là đoạn cuối của chuỗi lỗi. Ví dụ minh họa: giả sử agent research đối thủ cạnh tranh tạo báo cáo thiếu nguồn. Triệu chứng nhìn thấy là phần report không có citation. Nhưng trace cho thấy nguyên nhân trước đó là browser subagent trả về dữ liệu quá thô, coordinator nén context quá mạnh, analyst subagent chỉ còn vài bullet mơ hồ để viết.

Nếu bạn chỉ thêm prompt “hãy trích nguồn đầy đủ”, bạn đang dán băng cá nhân lên vết nứt tường. Sửa đúng hơn có thể là đổi contract giữa subagent research và subagent analyst: mỗi finding bắt buộc có source_url, claim, evidence_text, confidence.

4. Guardrail: sửa ở nơi agent thật sự lệch

Guardrail là rào vận hành giúp agent không đi quá biên. Nhưng guardrail không chỉ là content moderation. Trong hệ thống agent, guardrail có thể nằm ở:

Nói thẳng ra thì, guardrail tốt không phải là cấm agent làm mọi thứ nguy hiểm. Guardrail tốt là chỉ đúng đường ray cho từng loại hành động.

Playbook một buổi: dựng vòng chẩn đoán agent

Bạn có thể làm phiên bản tối thiểu trong một buổi chiều, không cần đại tu cả stack.

Bước 1: Chọn một luồng agent hay fail nhất

Đừng lấy luồng đẹp nhất để thử. Hãy chọn flow đang làm team khó chịu: tạo PR tự động, research thị trường, phân loại ticket, hoặc cập nhật CRM.

Mục tiêu là gom 20-50 trace đại diện, gồm cả pass và fail. Nếu chưa có trace chuẩn, hãy bắt đầu bằng JSON đơn giản:

{
  "user_goal": "...",
  "plan": ["..."],
  "tool_calls": [{"name": "...", "input": {}, "output": "..."}],
  "final_output": "...",
  "expected_outcome": "..."
}

Bước 2: Đặt taxonomy lỗi trước khi chọn tool

Taxonomy là bảng phân loại lỗi. Team builder nên thống nhất 6-8 nhãn trước:

Có nhãn rồi, detector mới có nơi để “đặt hồ sơ”. Không có nhãn, bạn sẽ nhận về một đống nhận xét nghe hợp lý nhưng khó đưa vào dashboard.

Bước 3: Gắn detector vào evaluation pipeline

Nếu bạn đã có Cases, Experiments, Evaluators theo kiểu Strands Evals, hãy thêm bước diagnosis sau khi test fail. Nếu chưa có framework, vẫn có thể làm thô:

  1. Chạy agent trên test cases cố định.
  2. Lưu trace cho từng case.
  3. Với case fail, gọi detector để phân loại lỗi.
  4. Lưu failure_type, confidence, root_cause, recommended_fix.
  5. Mở ticket theo lớp sở hữu: prompt, tool, orchestration, sandbox, evaluator.

Điểm quan trọng: đừng để diagnosis nằm trong đầu một người senior. Hãy đưa nó vào pipeline, vì production không chờ người đó rảnh.

Bước 4: Biến mỗi lỗi thành một test mới

Khi agent fail vì thiếu context, thêm test ép agent xử lý tài liệu dài. Khi agent gọi sai API, thêm test với tham số dễ nhầm. Khi agent trả lời thiếu nguồn, thêm evaluator kiểm tra evidence.

Đây là chỗ nhiều team bỏ sót. Root cause analysis mà không sinh ra regression test thì chỉ là biên bản họp được viết đẹp.

Khi subagent làm hệ thống mạnh hơn — và khó soi hơn

Các nguồn gần đây đều chỉ về một hướng: agent đang phân lớp. Deep Agents có coordinator, browser subagents, analyst subagent, code interpreter, memory. Claude Code tách memory, hooks, skills, subagents, MCP. Sakana Marlin đi theo hướng agent nghiên cứu chạy lâu, lập giả thuyết, duyệt nguồn, tạo báo cáo dài.

Điều này hợp lý. Một agent ôm hết việc giống một người vừa đọc web, vừa chạy Python, vừa viết báo cáo, vừa tự kiểm định lập luận. Tách vai giúp context sạch hơn và execution cô lập hơn.

Nhưng đổi lại, failure cũng phân tán hơn. Một report sai có thể đến từ browser subagent lấy nguồn kém, analyst subagent suy luận quá tay, memory kéo lại insight cũ, hoặc coordinator ghép kết quả sai thứ tự. Khi hệ thống có nhiều “nghi phạm”, trace phải đủ chi tiết để không bắt nhầm người.

Với multi-agent, mình sẽ thêm ba guardrail:

Bẫy dễ dính: detector cũng cần bị kiểm tra

Detector không phải thẩm phán tuyệt đối. Nó cũng có thể đọc nhầm trace, gán sai nguyên nhân, hoặc đề xuất sửa prompt trong khi lỗi nằm ở tool schema.

Vì vậy, với lỗi nghiêm trọng, hãy dùng detector như người phụ trách khám nghiệm ban đầu, không phải bản án cuối cùng. Cách thực tế:

Càng tự động hóa diagnosis, bạn càng cần log sạch và taxonomy rõ. Nếu input bẩn, detector chỉ giúp bạn sai nhanh hơn.

Sau bài này, nên đổi cách nghĩ thế nào?

Đừng xem agent reliability là chuyện chọn model mới hơn. Hãy xem nó là bài toán điều tra có quy trình: giữ trace, phân loại failure, nối causal chain, rồi đặt guardrail đúng lớp.

Nếu là mình, mình sẽ ưu tiên dựng vòng chẩn đoán trước khi thêm agent mới. Vì thêm subagent khi chưa biết lỗi cũ đến từ đâu chỉ làm hiện trường rộng hơn, manh mối nhiều hơn, và cuộc họp postmortem dài hơn.

Agent production không cần bạn tin nó ngoan. Nó cần bạn biết chính xác khi nào nó hư, hư ở đâu, và ai phải sửa. Nói vui một chút: nuôi agent mà không giữ trace thì khác gì làm thám tử nhưng quên mang kính lúp.

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

Nguồn tham khảo