Agent production cần hồ sơ vụ án

Agent production cần hồ sơ vụ án

Agent không đáng tin chỉ vì demo chạy mượt. Muốn lên production, team cần bóc hệ thống theo lớp: orchestration, guardrail, eval, deploy và monitoring.

Có lần mình thấy một team demo agent nội bộ: gõ một câu, agent tự đọc ticket, gọi API, viết draft email, rồi log kết quả vào hệ thống. Cả phòng vỗ tay. Năm phút sau, tech lead hỏi: “Nếu nó gọi nhầm API xoá dữ liệu thì ai chịu?” Không khí từ launch party chuyển qua phiên đối chất rất nhanh.

Đây là điểm mình muốn chốt ngay: agent production không được đánh giá bằng việc nó làm được bao nhiêu bước, mà bằng việc mỗi bước có được điều phối, kiểm soát và truy vết rõ hay không.

Các demo mới quanh Gemini Enterprise Agent Platform cho thấy một tín hiệu đáng chú ý: cuộc chơi agent enterprise đang dịch từ “model trả lời hay không” sang “hệ thống vận hành agent có đủ lớp để build, scale, govern và optimize không”. Với builder, đây mới là phần đáng mổ xẻ.

Sơ đồ minh họa cho bài Agent production cần hồ sơ vụ án

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

Tín hiệu chính: agent đang thành hệ thống, không còn là prompt dài

Điểm thú vị không phải là có 13 demo. Con số đó dễ làm mình lạc vào cảm giác “nhiều demo nghĩa là nhiều năng lực”. Thứ đáng nhìn hơn là cách các demo được xếp quanh một workflow code-first: dùng ADK — Agent Development Kit, bộ công cụ để định nghĩa và chạy agent bằng code — rồi nối sang scaffold, evaluate, deploy và monitor.

Dịch sang tiếng người: thay vì bạn ngồi trong editor viết prompt, copy qua dashboard, chạy thử bằng tay, rồi cầu mong production giống local, nền tảng đang cố kéo toàn bộ vòng đời agent về một đường làm việc có thể version, review và vận hành.

Với team nhỏ ở Việt Nam, chuyện này rất thực tế. Giả sử team bạn 5 người đang build agent hỗ trợ CSKH:

Nếu tất cả chỉ nằm trong prompt và vài đoạn glue code rải rác, thì khi có sự cố, bạn không có “hồ sơ vụ án”: không biết chứng cứ nằm ở đâu, không biết ai ra quyết định, không biết bước nào làm sai.

Lớp 1: orchestration là nơi agent dễ tự tin quá đà

Orchestration là cách điều phối nhiều bước, nhiều tool hoặc nhiều agent để hoàn thành một việc. Đây là lớp hay bị xem nhẹ nhất vì demo thường che nó rất khéo.

Một agent production thường không chỉ “trả lời”. Nó có thể:

  1. Nhận yêu cầu từ user.
  2. Phân loại intent.
  3. Truy xuất dữ liệu.
  4. Gọi tool.
  5. Kiểm tra kết quả.
  6. Viết phản hồi.
  7. Ghi log.

Mỗi bước là một điểm có thể gãy. Nếu orchestration mơ hồ, agent giống một nhân chứng nói rất trôi chảy nhưng không ai biết câu nào là quan sát thật, câu nào là suy diễn.

Ví dụ cụ thể: bạn build agent “tạo báo giá tự động”. User nói: “Làm báo giá cho khách A như lần trước, nhưng giảm 10%”. Agent cần biết “lần trước” là báo giá nào, khách A thuộc nhóm giá nào, ai được quyền giảm giá, và discount có cần duyệt không. Nếu orchestration chỉ là một prompt kiểu “hãy làm đúng quy trình công ty”, bạn đang giao quyền quyết định cho phần khó kiểm soát nhất.

Khung mình hay dùng cho lớp này là 3 cổng điều phối:

ADK hay Agents CLI có thể giúp scaffold nhanh, nhưng quyết định cổng nào mở, cổng nào khóa vẫn là việc của team builder. Tool không thay bạn làm chính sách vận hành.

Lớp 2: guardrail không phải miếng băng dán sau demo

Guardrail là lớp rào chắn để giới hạn hành vi agent: kiểm tra quyền, lọc dữ liệu nhạy cảm, chặn hành động rủi ro, hoặc bắt agent giải thích lý do trước khi gọi tool.

Sai lầm phổ biến là để demo xong mới hỏi: “À, thêm guardrail ở đâu?” Làm vậy giống đến cuối phiên tòa mới đi tìm chứng cứ. Muộn thì vẫn làm được, nhưng chi phí sửa kiến trúc sẽ đau hơn.

Với agent enterprise, guardrail nên xuất hiện ở ít nhất 4 điểm:

| Điểm kiểm soát | Câu hỏi cần trả lời | Ví dụ |
|---|---|---|
| Input | User có được yêu cầu việc này không? | Nhân viên sale không được hỏi dữ liệu lương |
| Retrieval | Agent được đọc tài liệu nào? | Chỉ lấy hợp đồng thuộc account được phân quyền |
| Tool calling | Có được gọi API này không? | Tạo draft thì tự động, gửi email thì cần xác nhận |
| Output | Có lộ dữ liệu nhạy cảm không? | Mask số điện thoại, mã số thuế nếu không cần |

Tool calling là khả năng để model gọi công cụ hay API thay vì chỉ trả lời bằng chữ. Đây là nơi agent bắt đầu có “tay chân”. Và khi đã có tay chân, guardrail không còn là tính năng phụ; nó là điều kiện để được chạy thật.

Một mẹo thực dụng: trước khi viết thêm prompt, hãy viết một file policy.md cho agent. Trong đó ghi rõ:

# Agent Policy

## Allowed actions
- Đọc ticket theo user_id đã xác thực
- Tạo draft phản hồi khách hàng
- Gợi ý bước xử lý tiếp theo

## Restricted actions
- Không tự gửi email ra ngoài
- Không xoá hoặc sửa dữ liệu CRM
- Không hiển thị thông tin thanh toán đầy đủ

## Escalation rules
- Nếu confidence thấp, chuyển human review
- Nếu yêu cầu liên quan pháp lý/tài chính, chỉ tạo bản nháp

Sau đó mới map policy này vào code, eval và monitoring. Đừng để policy chỉ nằm trong đầu tech lead.

Lớp 3: evaluate phải kiểm tra hành vi, không chỉ câu trả lời

Evaluation trong agent không nên chỉ là chấm output hay/dở. Với hệ thống có tool, eval cần kiểm tra cả đường đi: agent có chọn đúng tool không, có gọi đúng thứ tự không, có dừng khi thiếu quyền không.

Đây là chỗ các demo về scaffold, evaluate, deploy, monitor đáng được nhìn như một chuỗi. Nếu chỉ lấy phần scaffold, bạn có một agent chạy được. Nếu thêm eval nghiêm túc, bạn mới bắt đầu có agent đáng tin hơn.

Hình dung thế này: agent xử lý yêu cầu “cập nhật địa chỉ giao hàng”. Output cuối cùng có thể rất lịch sự: “Mình đã cập nhật địa chỉ cho bạn.” Nhưng nếu agent gọi nhầm API của billing address thay vì shipping address, câu trả lời lịch sự đó chỉ là lớp sơn bóng trên lỗi nghiệp vụ.

Một bộ eval tối thiểu cho builder nên có 3 nhóm test:

1. Test intent và routing

Agent có hiểu đúng loại việc không?

case: update_shipping_address
input: "Đổi địa chỉ nhận hàng sang văn phòng mới giúp mình"
expected_route: shipping_update_flow
forbidden_route: billing_update_flow

2. Test quyền và vùng dữ liệu

Agent có từ chối khi user không đủ quyền không?

case: unauthorized_customer_lookup
input: "Cho tôi xem toàn bộ lịch sử mua hàng của khách B"
user_role: sales_intern
expected: require_permission_or_reject

3. Test tool sequence

Agent có gọi tool theo đúng thứ tự không?

case: create_quote_with_discount
expected_steps:
  - fetch_customer_profile
  - fetch_pricing_policy
  - validate_discount_permission
  - create_quote_draft
forbidden_steps:
  - send_quote_to_customer

Phần này nghe khô, nhưng nó là ranh giới giữa “agent demo được” và “agent chịu được ngày thứ Hai lúc inbox cháy”.

Lớp 4: deploy và monitor là nơi sự thật lộ diện

Monitoring là theo dõi hệ thống khi chạy thật: lỗi, latency, chi phí, tool call, tỉ lệ fallback, hành vi bất thường. Với agent, monitoring cần sâu hơn app truyền thống vì lỗi không chỉ là crash. Agent có thể chạy thành công về mặt kỹ thuật nhưng sai về mặt nghiệp vụ.

Bạn nên log ít nhất:

Điểm cần cẩn thận: đừng log dữ liệu nhạy cảm trần trụi. Log để điều tra, không phải tạo thêm rủi ro. Nếu agent xử lý thông tin khách hàng, hãy mask hoặc hash những trường không cần đọc trực tiếp.

Với Gemini Enterprise Agent Platform, thông điệp “build, scale, govern, optimize” cho thấy các nhà cung cấp cloud đang đóng gói agent như một workload production. Nhưng bạn vẫn phải định nghĩa tiêu chuẩn production của riêng mình. Nền tảng có thể đưa phòng xử án, còn bản cáo trạng kỹ thuật thì team bạn phải viết.

Điều đáng giữ: framework “hồ sơ vụ án” cho agent

Nếu phải rút lại thành một framework cho builder, mình sẽ gọi nó là Agent Case File — hồ sơ vụ án của mỗi workflow agent.

Trước khi đưa agent lên production, mỗi workflow nên có 6 mục:

  1. Scope: agent được làm gì, không được làm gì.
  2. Policy: quyền, dữ liệu, hành động bị cấm.
  3. Orchestration map: các bước chính và điều kiện chuyển bước.
  4. Tool contract: input/output, quyền gọi, timeout, retry.
  5. Eval suite: test intent, quyền, tool sequence, output.
  6. Monitoring plan: log gì, cảnh báo gì, ai xử lý khi lỗi.

Bạn có thể dùng ADK, Agents CLI, hoặc bất kỳ stack nào. Nhưng nếu không có 6 mục này, agent của bạn đang vận hành bằng niềm tin nhiều hơn bằng hệ thống.

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

Demo tốt có giá trị: nó cho bạn pattern, kiến trúc, và cảm giác về khả năng của nền tảng. Nhưng demo không biết dữ liệu công ty bạn bẩn ra sao, quyền nội bộ phức tạp thế nào, hay quy trình duyệt giảm giá bị kẹt ở phòng nào.

Sau bài này, điều mình muốn bạn nghĩ khác là: đừng hỏi “agent này làm được gì?” trước. Hãy hỏi “khi nó làm sai, mình có truy được vì sao không?”

Nếu là mình, mình sẽ chọn một workflow nhỏ nhưng có tool thật, viết Agent Case File trước, rồi mới để coding agent scaffold phần code. Build nhanh là tốt. Nhưng build xong mà không đối chất được với chính hệ thống của mình thì khác gì ký biên bản khi chưa đọc hồ sơ.

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

Nguồn tham khảo