Agent production cần bản mô tả công việc

Agent production cần bản mô tả công việc

Agent không hỏng vì thiếu thông minh. Nó hỏng vì team không đo đúng: tool nào được gọi, context trôi ở đâu, guardrail chặn được gì.

9:17 sáng, một bạn tech lead nhắn trong group nội bộ: team em vừa demo agent tìm sản phẩm, sếp thích lắm, giờ hỏi tuần sau mở cho sales dùng được chưa.

Mình đọc tới chữ tuần sau là đặt ly cà phê xuống. Không phải vì agent không làm được. Mà vì câu hỏi đúng phải là: nếu agent trả lời sai, team bạn biết sai ở bước nào không?

Với agent, production không phải là chuyện model thông minh thêm một nấc. Production là lúc bạn có thể chỉ vào từng quyết định của hệ thống: nó chọn tool nào, hiểu query ra sao, giữ context thế nào, và guardrail nào đã chặn nó trước khi gây chuyện.

Luận điểm của mình hôm nay rất gọn: agent chỉ đáng tin khi orchestration và guardrail được viết rõ như bản mô tả công việc của một đồng nghiệp mới. Không có phần đó, bạn không đang vận hành agent; bạn đang hy vọng nó cư xử tử tế.

Sơ đồ minh họa cho bài Agent production cần bản mô tả công việc

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

Cảnh của team An: demo chạy, niềm tin chưa chạy

Gọi nhân vật chính là An, tech lead của một marketplace ở Việt Nam. Team An build một agent cho đội vận hành tìm kiếm hàng tồn bằng ngôn ngữ tự nhiên. Người dùng có thể hỏi kiểu: xe hybrid dưới 5 năm, giá trong khoảng X, còn giấy tờ Y.

Demo rất mượt. Agent hiểu câu hỏi, gọi search API, trả về danh sách gọn đẹp. Nhưng khi mở rộng test, team thấy ba lỗi bắt đầu lộ ra:

Hình dung thế này: bạn onboard một bạn mới vào team sales ops, nhưng chỉ nói chung chung là hỗ trợ tìm dữ liệu cho anh chị. Ngày đầu bạn ấy làm được vài case dễ. Ngày thứ ba, gặp yêu cầu nhiều điều kiện, bạn ấy tự đoán quy trình. Agent cũng vậy. Nếu không có scope, tiêu chí đúng sai, và cách kiểm tra, nó sẽ có vẻ tự tin ngay cả khi đang đi lệch.

Điểm thú vị từ câu chuyện Motorway trên AWS là họ không dừng ở cảm giác demo ổn. Họ dựng pipeline đánh giá end-to-end cho agent tìm stock xe, và theo case đó, lỗi sai giảm từ 1 trong 8 query xuống 1 trong 50 query; thời gian phát hiện issue từ vài giờ xuống vài phút. Con số đáng chú ý không phải để khoe agent thần kỳ, mà để nhắc builder một điều: đo đúng hành vi sẽ đổi chất lượng vận hành.

Mục tiêu không phải là test prompt, mà là test quyết định

Nhiều team test agent như test chatbot: đưa vào vài câu hỏi, đọc output, thấy hợp lý thì gật. Cách đó quá mỏng.

Agent khác chatbot ở chỗ nó hành động. Nó có tool calling, tức khả năng gọi API hoặc công cụ ngoài thay vì chỉ trả lời bằng chữ. Vì vậy thứ cần đánh giá không chỉ là câu trả lời cuối, mà là chuỗi quyết định trước đó.

Một agent production nên được soi ở 5 lớp:

  1. Intent parsing: agent có hiểu đúng ý định và ràng buộc không?
  2. Tool selection: agent có chọn đúng công cụ cho nhiệm vụ không?
  3. Tool input: tham số truyền vào tool có đúng kiểu, đúng điều kiện, đúng giới hạn không?
  4. State handling: agent có giữ đúng thông tin qua nhiều lượt hội thoại không?
  5. Final answer: câu trả lời có trung thực với dữ liệu tool trả về không?

Nói thẳng ra thì, nếu bạn chỉ chấm final answer, bạn đang chấm báo cáo cuối ngày mà không biết đồng nghiệp đó đã lấy số liệu từ đâu.

Checklist một buổi: dựng khung eval cho agent

Nếu team bạn đã có agent đang chạy thử, đây là checklist đủ thực tế để làm trong một buổi chiều. Không cần mua thêm cả một nền tảng mới ngay lập tức. Cần nhất là đổi cách ghi nhận và chấm lỗi.

1. Viết lại job description của agent

Đừng bắt đầu bằng prompt. Bắt đầu bằng hợp đồng hành vi.

agent_role: dealer_stock_search_assistant
allowed_tools:
  - search_inventory
  - filter_by_vehicle_age
  - filter_by_fuel_type
  - explain_result
must_not:
  - invent_vehicle_availability
  - ignore_user_constraints
  - call_pricing_tool_without_price_intent
success_criteria:
  - correct_tool_selected
  - all_constraints_preserved
  - answer_grounded_in_tool_result
handoff_when:
  - query_ambiguous
  - tool_result_conflicts
  - user_requests_policy_exception

Đoạn này không phải tài liệu trang trí. Nó là brief cho agent. Brief lệch thì output lệch; prompt hay đến mấy cũng chỉ đang vá phần ngọn.

2. Tạo golden set từ lỗi thật

Golden set là bộ ca kiểm thử chuẩn để chấm hệ thống qua nhiều lần thay đổi. Với agent, đừng chỉ lấy câu hỏi đẹp. Hãy gom các ca khó:

Ví dụ cụ thể: giả sử team bạn có agent nội bộ tìm khách hàng tiềm năng trong CRM. Golden set nên có câu như: tìm khách enterprise ở miền Nam, chưa được contact trong 30 ngày, có deal thua vì giá trong quý trước. Đây là câu khiến agent phải hiểu intent, chọn đúng tool CRM, lọc thời gian, và không bịa lý do deal thua nếu dữ liệu không có.

3. Ghi trace cho từng lần chạy

Trace là nhật ký từng bước agent đã đi qua: prompt, tool được gọi, input, output, thời gian, lỗi, và câu trả lời cuối. Không có trace thì debug agent giống như đi họp daily standup mà ai cũng nói hôm qua em có làm gì đó, nhưng không ai nhớ ticket nào.

Một log tối thiểu nên có:

{
  "query": "hybrid cars under 5 years old",
  "detected_constraints": {
    "fuel_type": ["hybrid"],
    "max_age_years": 5
  },
  "tool_calls": [
    {
      "name": "search_inventory",
      "input": {
        "fuel_type": "hybrid",
        "max_age_years": 5
      }
    }
  ],
  "guardrail_events": [],
  "final_answer_grounded": true
}

Bạn có thể dùng SDK như Strands Agents để cấu trúc phần build-time evaluation, rồi dùng lớp vận hành như Bedrock AgentCore nếu hệ thống đã nằm trong AWS. Nhưng quyết định công cụ nên đến sau quyết định đo cái gì.

4. Chấm theo ma trận lỗi, không chấm cảm tính

Một lỗi agent cần được phân loại để sửa đúng chỗ.

| Loại lỗi | Dấu hiệu | Cách xử lý |
|---|---|---|
| Sai intent | Hiểu nhầm việc người dùng muốn làm | Bổ sung ví dụ đối nghịch vào golden set |
| Sai tool | Gọi nhầm API hoặc gọi dư | Ràng buộc tool schema, thêm rule chọn tool |
| Sai tham số | Tool đúng nhưng input sai | Validate input trước khi gọi tool |
| Trôi context | Quên điều kiện ở lượt trước | Tách state rõ, test multi-turn |
| Bịa kết quả | Trả lời vượt quá dữ liệu tool | Guardrail bắt buộc grounding |

Guardrail là lớp rào kiểm soát hành vi, ví dụ chặn câu trả lời không có dữ liệu hoặc bắt agent hỏi lại khi query mơ hồ. Với builder, guardrail không phải phanh tay cho vui; nó là phần biến agent từ demo thành hệ thống có trách nhiệm.

Những bẫy làm agent trông ổn nhưng chưa ổn

Bẫy đầu tiên: chọn model mới nhất rồi nghĩ eval nhẹ đi cũng được. Model tốt hơn có thể giảm lỗi, nhưng không thay thế được orchestration, tức cách điều phối nhiều bước, nhiều tool và nhiều trạng thái trong workflow.

Bẫy thứ hai: benchmark công khai làm bạn yên tâm quá sớm. Các leaderboard như EdgeBench hữu ích để hiểu năng lực tổng quát của agent qua nhiều task và ngân sách thời gian tương tác. Nhưng production của bạn có schema dữ liệu, tool nội bộ, quyền truy cập, latency, và người dùng rất riêng. Benchmark giống điểm phỏng vấn; còn vào công ty làm được việc không thì phải xem OKR hằng quý.

Bẫy thứ ba: monitoring chỉ đếm latency và cost. Hai thứ đó quan trọng, nhưng agent còn cần production monitoring, tức theo dõi hành vi thật sau khi deploy. Bạn cần biết tỷ lệ gọi tool sai, số lần guardrail kích hoạt, nhóm query hay gây lỗi, và case nào bị người dùng sửa lại nhiều lần.

Jefferies dùng agentic AI cho front-office trading vì trader cần insight nhanh từ nhiều nguồn dữ liệu, nhưng môi trường đó không cho phép agent nói đại. monday.com cũng đi theo hướng agent như teammate có scope, manager, performance score. Điểm chung không nằm ở tên stack. Điểm chung là agent được đối xử như một đơn vị vận hành có trách nhiệm, không phải một ô chat biết làm màu.

Nếu là mình, mình sẽ chốt decision thế này

Với team builder đang cân nhắc đưa agent vào production, mình sẽ không hỏi trước: dùng framework nào? Mình sẽ hỏi bốn câu này:

  1. Agent được phép quyết định gì, và không được phép quyết định gì?
  2. Mỗi quyết định có trace để audit không?
  3. Golden set có chứa lỗi thật và hội thoại nhiều lượt không?
  4. Guardrail chặn trước khi tool chạy, sau khi tool trả về, hay chỉ ở câu trả lời cuối?

Nếu bốn câu này chưa rõ, cứ giữ agent ở chế độ assisted workflow: người dùng duyệt trước khi hành động. Nếu đã rõ, hãy tăng dần quyền tự động hóa theo từng nhóm task ít rủi ro, rồi dùng production monitoring để mở rộng.

Sau bài này, điều mình muốn bạn nghĩ khác là: đừng xem agent evaluation như bài kiểm tra đầu ra; hãy xem nó như hệ thống quản lý trách nhiệm cho từng quyết định của agent.

Agent không cần được tin vì nó nói trơn tru. Agent cần đáng tin vì khi nó lạc đường, cả team biết nó rẽ sai ở ngã tư nào. Đồng nghiệp mới còn cần onboarding, agent mà không cần thì hơi thiệt cho đồng nghiệp.

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

Nguồn tham khảo