Agent không cần thông minh hơn, cần lái rõ hơn

Agent không cần thông minh hơn, cần lái rõ hơn

Một playbook cho builder: dùng benchmark, tracing và guardrail để biến agent từ demo biết diễn thành hệ thống chạy được trong production.

"Cứ lấy model mới nhất gắn vào agent là xong chứ gì?"

Câu này mình nghe nhiều tới mức nếu mỗi lần nghe được một đồng, chắc giờ đã đủ tiền mua cà phê cho cả team backend. Và công bằng mà nói, niềm tin đó không vô lý. Model mới thường reasoning tốt hơn, context window rộng hơn, tool calling mượt hơn. Demo chạy trên sân khấu thì đúng là trông như tàu vừa gặp gió thuận.

Nhưng production không phải clip demo. Production là lúc agent phải chạy trong hải trình dài: task lệch nhẹ, tool timeout, internet lúc có lúc không, user hỏi vòng vo, prompt đổi một dòng mà behavior đổi cả khúc. Sau bài này, mình muốn bạn đổi một cách nghĩ: agent đáng tin không bắt đầu từ model mạnh nhất, mà từ orchestration và guardrail đủ rõ để biết nó được phép làm gì, dừng ở đâu, và sai thì lộ ra chỗ nào.

Sơ đồ minh họa cho bài Agent không cần thông minh hơn, cần lái rõ hơn

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

Mục tiêu: đừng benchmark agent như thi hoa hậu model

EdgeBench đáng chú ý không phải vì nó thêm một leaderboard nữa cho vui. Điểm đáng lấy về cho builder là cách nó nhìn agent theo nhiều trục: loại task, runtime environment, yêu cầu internet, interaction-time budget, judge configuration và scoring metadata.

Dịch sang công việc: một agent không chỉ có câu trả lời cuối cùng. Nó có môi trường chạy, ngân sách tương tác, cách bị chấm, và đường đi qua các tool.

Nếu bạn chỉ hỏi "model nào đứng đầu leaderboard?", bạn đang nhìn hải đăng rồi tưởng đó là bản đồ biển. Leaderboard giúp định hướng, nhưng không thay bạn quyết định tàu của team cần đi tuyến nào.

Với team đang build agent cho coding, vận hành nội bộ, phân tích tài liệu hoặc automation, mục tiêu thực tế hơn là:

Đây là playbook để bạn kiểm tra mấy thứ đó trong một buổi chiều, không cần dựng cả phòng lab.

Checklist trước khi cho agent ra khơi

Trước khi viết thêm prompt hoặc đổi model, mở một file agent_eval_plan.md và điền 6 dòng này:

# Agent Eval Plan

1. Task chính:
2. Tool agent được phép gọi:
3. Tool bị cấm hoặc cần xác nhận:
4. Giới hạn thời gian / số bước:
5. Tiêu chí pass / fail:
6. Log cần xem lại sau mỗi run:

Nghe đơn giản, nhưng thiếu file này là nhiều team trôi rất nhanh từ "agent tự động" sang "agent tự ý".

Một vài thuật ngữ cần neo lại cho rõ:

Nói thẳng ra thì: nếu bạn không định nghĩa được 5 thứ trên, bạn chưa có agent production; bạn mới có một demo biết trả lời tự tin.

Bước 1: chia task theo vùng nước, không theo cảm giác

Đừng gom mọi thứ vào một benchmark kiểu "agent có làm được việc không?". Hãy chia task theo category giống tinh thần EdgeBench: mỗi loại task có môi trường và cách chấm riêng.

Ví dụ cụ thể: team bạn đang build coding agent nội bộ. Đừng chỉ test bằng câu "sửa bug này". Chia thành:

| Nhóm task | Ví dụ | Điều cần đo |
|---|---|---|
| Đọc hiểu codebase | Tìm nơi validate payment | Agent có trích đúng file không |
| Sửa lỗi nhỏ | Fix test fail do edge case | Patch có qua test không |
| Gọi tool | Chạy test, đọc log, mở issue | Gọi đúng tool, đúng thứ tự không |
| Task cần internet | Tra docs API mới | Có phân biệt nguồn đáng tin không |
| Task rủi ro cao | Thay đổi auth, migration DB | Có dừng để xin review không |

Hình dung thế này: nếu bạn là tech lead, bạn không cần biết agent "thông minh chung chung". Bạn cần biết nó có đáng cho chạm vào auth flow không, hay chỉ nên giao việc đọc log và đề xuất patch.

Mỗi nhóm task nên có 5-10 case nhỏ trước. Đừng bắt đầu bằng bộ eval khổng lồ. Bộ eval bé nhưng chạy hằng ngày còn có ích hơn benchmark hoành tráng mà tháng sau không ai mở lại.

Bước 2: đặt ngân sách tương tác, rồi mới so model

Một điểm hay trong cách phân tích EdgeBench là so hiệu năng qua nhiều mức interaction-time budget. Đây là thứ nhiều team bỏ qua.

Một agent chạy 30 giây khác agent chạy 5 phút. Một agent được gọi tool 3 lần khác agent được gọi tool 20 lần. Nếu không khóa ngân sách, bạn không biết model tốt hơn thật hay chỉ được "chèo lâu hơn".

Trong một buổi chiều, bạn có thể chạy ma trận nhỏ như sau:

Model A + 3 tool calls max
Model A + 10 tool calls max
Model B + 3 tool calls max
Model B + 10 tool calls max

Với mỗi run, ghi:

{
  "task_id": "fix-login-timeout-01",
  "model": "model-a",
  "max_tool_calls": 3,
  "passed": true,
  "latency_seconds": 42,
  "tool_errors": 0,
  "needs_human_review": false,
  "notes": "Found timeout config, changed test fixture"
}

Đừng vội chọn model có pass rate cao nhất nếu nó cần quá nhiều bước, latency cao, hoặc hay chạm tool nguy hiểm. Với production, điểm số là một phần; hành vi dưới giới hạn mới là thứ quyết định chi phí và rủi ro.

Bước 3: bật tracing trước khi sửa prompt

Khi agent trả lời sai, phản xạ phổ biến là thêm một đoạn system prompt: "Không được làm X, luôn làm Y, nhớ kiểm tra Z". Nhưng cuộc trò chuyện với team Claude Code cho thấy một tín hiệu đáng để builder để ý: với model mới, prompt dài nhồi quá nhiều ví dụ hoặc danh sách cấm đôi khi làm chất lượng giảm, không tăng.

Điểm này rất đời. Prompt dài giống neo thả quá nhiều chỗ: tưởng chắc hơn, nhưng lúc cần xoay hướng lại vướng.

Trước khi sửa prompt, hãy bật tracing. Nếu dùng LangChain, LangSmith là một cách nhanh để xem từng model call, tool call, latency và lỗi. Bạn cũng có thể tự log nếu không muốn dùng dịch vụ ngoài, miễn là log đủ chi tiết.

Tối thiểu, mỗi request nên có:

{
  "request_id": "uuid",
  "user_input": "...",
  "selected_tools": ["search_docs", "run_tests"],
  "tool_call_count": 4,
  "tool_failures": [],
  "final_answer": "...",
  "latency_ms": 0,
  "guardrail_triggered": false
}

Sau đó mới hỏi:

Nếu không có tracing, bạn chỉ đang sửa lá buồm trong sương mù.

Bước 4: viết guardrail như hợp đồng vận hành

Guardrail không nên là một câu trong prompt kiểu "hãy cẩn thận". Với builder, guardrail nên nằm ở nhiều lớp:

1. Tool permission

tools:
  read_file: allowed
  run_tests: allowed
  edit_file: allowed
  delete_file: denied
  deploy_prod: requires_human_approval

2. Step limit

limits:
  max_tool_calls: 10
  max_runtime_seconds: 180
  stop_on_repeated_tool_error: true

3. Review gate

review_required_if:
  - touches_auth_code
  - modifies_database_migration
  - changes_ci_config
  - confidence_below_threshold

4. Output contract

Agent must return:
- Summary of changes
- Files touched
- Tests run
- Known risks
- Whether human review is required

Cái đáng học từ các team dùng coding agent nghiêm túc không phải là họ để agent làm mọi thứ. Mà là họ biết lớp nào có thể tự động, lớp nào vẫn review thủ công, và lớp nào chỉ nên để agent đề xuất.

Những bẫy làm benchmark đẹp nhưng production mệt

Có vài bẫy mình thấy rất hay gặp:

Bẫy 1: Chỉ đo final answer.
Output đúng nhưng agent gọi nhầm tool, retry quá nhiều, hoặc đọc file không liên quan vẫn là tín hiệu xấu. Production trả tiền cho cả hành trình, không chỉ bến đỗ.

Bẫy 2: Dùng task quá sạch.
Task benchmark nội bộ chỉ toàn happy path thì agent sẽ nhìn rất ổn. Hãy thêm case tool timeout, docs thiếu, test flaky, requirement mơ hồ.

Bẫy 3: Không chuẩn hóa cách chấm.
Nếu hôm nay chấm bằng cảm giác của dev A, mai chấm bằng cảm giác của dev B, bạn không có eval; bạn có cuộc tranh luận.

Bẫy 4: Thấy model mới là đổi ngay.
Model mới có thể tốt hơn ở reasoning nhưng tệ hơn ở thói quen gọi tool, format output, hoặc độ tuân thủ guardrail. Đổi model mà không chạy lại eval theo category là tự tháo la bàn.

Nếu là mình, mình sẽ làm gì trong một buổi chiều

Nếu team bạn đang có một agent demo và muốn biết có nên đưa vào workflow thật chưa, mình sẽ làm gọn thế này:

  1. Chọn 15 task đại diện, chia thành 3 nhóm: an toàn, cần tool, rủi ro cao.
  2. Đặt 2 mức ngân sách: ít bước và nhiều bước.
  3. Chạy 2 model hoặc 2 cấu hình prompt, không nhiều hơn.
  4. Bật tracing hoặc log chi tiết từng tool call.
  5. Chấm theo 4 cột: passed, tool_behavior_ok, latency_ok, review_needed.
  6. Viết policy: task nào cho auto-run, task nào cần approval, task nào cấm agent đụng.

Kết quả bạn cần không phải là một biểu đồ thật đẹp. Kết quả bạn cần là quyết định vận hành:

Đó mới là khác biệt giữa agent demo và agent production.

Takeaway gọn: đừng hỏi agent có thông minh không; hãy hỏi nó có đi đúng tuyến, có báo khi lệch hướng, và có chịu dừng trước vùng nguy hiểm không. Tàu tốt không chỉ nhờ máy khỏe — còn nhờ người biết đọc bản đồ.

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

Nguồn tham khảo