Làm sao biết một workflow thật sự cần AI Agent?

Hãy thử hình dung một buổi planning khá quen thuộc.

Team đang bàn về workflow xử lý yêu cầu hoàn tiền. Hiện tại, nhân viên phải đọc nội dung khách hàng gửi, kiểm tra đơn hàng, đối chiếu chính sách, quyết định có hoàn tiền hay không rồi cập nhật lại hệ thống.

Một người trong phòng đề xuất:

“Hay mình làm một AI Agent xử lý hết?”

Ý tưởng nghe rất hợp thời. Agent có thể đọc yêu cầu, truy cập dữ liệu, đưa ra quyết định rồi gửi email cho khách hàng. Một quy trình mất mười phút có thể chỉ còn vài giây.

Nhưng rồi những câu hỏi bắt đầu xuất hiện.

Nếu chính sách hoàn tiền đã được quy định rõ, tại sao không dùng rule?

Nếu AI chỉ cần phân loại nội dung, tại sao phải cho nó quyền cập nhật đơn hàng?

Nếu Agent hoàn nhầm một giao dịch lớn, ai chịu trách nhiệm?

Và câu quan trọng nhất:

Workflow này thật sự cần AI Agent, hay chúng mình chỉ đang thuê một công nghệ rất đắt để làm công việc của vài câu if/else?

Chapter 01

Trước hết, đừng gọi mọi thứ là Agent

Trong những cuộc thảo luận về sản phẩm, AI Agent đang dần trở thành một cái tên khá tiện lợi.

Một chatbot là Agent.

Một tính năng tóm tắt văn bản cũng là Agent.

Một chuỗi ba prompt nối với nhau vẫn được giới thiệu là Agent.

Việc gọi tên không chính xác tưởng như vô hại, nhưng nó ảnh hưởng trực tiếp đến cách team đánh giá độ phức tạp, chi phí và rủi ro của giải pháp.

Để đơn giản, chúng mình có thể chia một workflow thành ba mức.

Automation: Máy làm theo đường đi đã định sẵn

Với automation truyền thống, team biết trước các bước và điều kiện xử lý.

Ví dụ:

• Nếu đơn hàng chưa giao và được tạo dưới 24 giờ, cho phép hủy.
• Nếu số tiền hoàn lớn hơn 10 triệu đồng, chuyển quản lý phê duyệt.
• Nếu thanh toán thất bại ba lần, khóa giao dịch và gửi cảnh báo.

Input A đi vào, hệ thống kiểm tra điều kiện B rồi thực hiện hành động C.

Không có gì hào nhoáng, nhưng lại nhanh, rẻ, dễ kiểm thử và tương đối dễ giải thích.

AI-assisted: AI xử lý một phần, con người hoặc hệ thống vẫn quyết định

Có những phần của workflow khó viết thành rule vì input không có cấu trúc.

Chẳng hạn, khách hàng gửi một đoạn văn khá dài:

“Mình đặt nhầm địa chỉ, gọi shipper không được, đơn vẫn đang trên đường nhưng giờ mình không còn ở thành phố đó nữa.”

AI có thể đọc nội dung này, phân loại lý do liên hệ và tạo bản tóm tắt cho nhân viên hỗ trợ.

Tuy nhiên, AI chưa cần tự quyết định toàn bộ quy trình. Nó chỉ xử lý một bước mà mô hình ngôn ngữ làm tốt hơn rule cố định.

AI Agent: Hệ thống tự chọn đường đi để hoàn thành mục tiêu

Agent không chỉ tạo ra một câu trả lời. Nó được giao một mục tiêu, tự quyết định cần thực hiện những bước nào, chọn công cụ phù hợp, quan sát kết quả rồi điều chỉnh hành động tiếp theo.

Anthropic phân biệt khá rõ: workflow đi theo những nhánh được lập trình trước, còn Agent tự điều phối quá trình và cách sử dụng công cụ. Họ cũng khuyến nghị bắt đầu bằng giải pháp đơn giản nhất, chỉ tăng mức độ tự chủ khi bài toán thật sự cần đến nó. Anthropic

Trong ví dụ hoàn tiền, một Agent có thể:

1. Đọc yêu cầu của khách hàng.
2. Tìm đúng đơn hàng.
3. Kiểm tra lịch sử giao dịch.
4. Đối chiếu chính sách hiện hành.
5. Phát hiện một chi tiết bất thường.
6. Truy vấn thêm dữ liệu vận chuyển.
7. Đề xuất hoặc thực hiện hành động phù hợp.
8. Kiểm tra kết quả rồi thông báo cho khách hàng.

Điểm khác biệt không nằm ở việc workflow có bao nhiêu bước.

Điểm khác biệt nằm ở việc ai quyết định bước tiếp theo.

Chapter 02

Năm câu hỏi để kiểm tra một workflow

Không phải cứ nhiều bước là cần Agent. Một quy trình 20 bước nhưng luôn đi theo cùng một đường vẫn có thể được xử lý tốt bằng automation.

Ngược lại, một nhiệm vụ chỉ có vài bước nhưng đường đi thay đổi liên tục theo dữ liệu thực tế có thể phù hợp với Agent hơn.

Trước khi đưa Build an AI Agent vào roadmap, mình nghĩ PM nên cùng team trả lời năm câu hỏi sau.

1. Chúng mình có biết trước đường đi hay không?

Hãy bắt đầu bằng việc vẽ workflow hiện tại.

Nếu team có thể mô tả gần như đầy đủ:

• Các loại input;
• Những nhánh quyết định;
• Điều kiện của từng nhánh;
• Hành động tương ứng;
• Điểm bắt đầu và kết thúc;

thì nhiều khả năng chúng mình đang đứng trước một bài toán automation.

Ví dụ, quy trình duyệt một khoản hoàn tiền chỉ phụ thuộc vào giá trị đơn hàng, thời gian mua và trạng thái giao hàng. Các điều kiện này đều rõ ràng và ổn định.

Dùng Agent trong trường hợp đó không làm sản phẩm thông minh hơn. Nó chỉ thay một hệ thống có kết quả tương đối chắc chắn bằng một hệ thống có kết quả mang tính xác suất.

Agent bắt đầu có giá trị khi team không thể biết trước toàn bộ đường đi.

Chẳng hạn, việc điều tra một giao dịch bất thường có thể đòi hỏi kiểm tra nhiều nguồn dữ liệu khác nhau. Mỗi phát hiện lại quyết định bước tiếp theo. Có trường hợp cần xem lịch sử đăng nhập, trường hợp khác phải kiểm tra thiết bị hoặc so sánh hành vi với những tài khoản liên quan.

Biết trước đường đi: ưu tiên automation.

Chỉ biết mục tiêu, chưa biết các bước: bắt đầu cân nhắc Agent.

2. Workflow có thật sự cần khả năng phán đoán không?

Một task phù hợp với AI thường chứa dữ liệu khó chuẩn hóa: email, tài liệu, hình ảnh, đoạn hội thoại hoặc những tình huống có nhiều sắc thái.

Nhưng cần hiểu ngôn ngữ tự nhiên chưa đồng nghĩa với cần Agent.

Nếu hệ thống chỉ phải đọc phản hồi rồi gắn một trong năm nhãn có sẵn, một lần gọi model có thể đã đủ. Nếu hệ thống tóm tắt cuộc gọi để nhân viên ra quyết định, đó là AI-assisted.

Agent chỉ cần thiết khi kết quả của bước phán đoán này phải quyết định chuỗi hành động tiếp theo.

Đây là một ranh giới nhỏ nhưng khá đắt tiền.

Một model phân loại sai tạo ra một nhãn sai.

Một Agent phán đoán sai có thể chọn nhầm công cụ, lấy nhầm dữ liệu rồi tiếp tục thực hiện thêm ba hành động dựa trên sai lầm ban đầu.

3. Agent có quan sát được kết quả để tự điều chỉnh không?

Agent hoạt động theo một vòng lặp:

Lập kế hoạch → hành động → quan sát → điều chỉnh.

Nếu Agent không thể quan sát kết quả đủ rõ, nó chẳng khác nào một người vừa nhắm mắt vừa lái xe, nhưng vẫn rất tự tin báo rằng “mọi thứ đang diễn ra đúng kế hoạch”.

Một coding agent có thể chạy test để biết đoạn code vừa sửa có hoạt động hay không.

Một Agent tìm vé máy bay có thể kiểm tra giá, thời gian bay và trạng thái còn chỗ.

Nhưng với nhiệm vụ như “hãy làm khách hàng cảm thấy thương hiệu đáng tin hơn”, kết quả không xuất hiện ngay sau hành động. Agent khó biết mình đang tiến gần mục tiêu hay chỉ tạo thêm nội dung.

Vì vậy, PM cần xác định trước:

• Agent sẽ nhận feedback nào từ môi trường?
• Dấu hiệu nào cho thấy nó đang đi đúng hướng?
• Khi nào nó biết nhiệm vụ đã hoàn thành?
• Điều kiện nào buộc nó phải dừng lại?

Nếu không trả lời được, team chưa có một Agent.

Team mới chỉ có một hệ thống được trao quyền hành động nhưng chưa có chiếc la bàn đủ tốt.

4. Nếu Agent làm sai, hành động đó có đảo ngược được không?

Không phải sai lầm nào cũng có cùng mức độ nghiêm trọng.

Gợi ý sai một nhãn phân loại có thể được sửa trong vài giây.

Gửi nhầm một email cho khách hàng đã khó xử hơn.

Hoàn nhầm tiền, xóa dữ liệu hoặc ký thay người dùng vào một quyết định pháp lý sẽ tạo ra rủi ro lớn hơn nhiều.

Agent càng tự chủ, PM càng phải hiểu rõ blast radius — phạm vi thiệt hại nếu một hành động sai xảy ra.

Anthropic mô tả một nguyên tắc quan trọng của Agent đáng tin cậy: con người phải giữ được quyền kiểm soát có ý nghĩa, chẳng hạn cho phép Agent tự đọc dữ liệu nhưng yêu cầu phê duyệt trước khi thực hiện hành động nhạy cảm. Anthropic

Do đó, câu hỏi không chỉ là:

“Model có làm được việc này không?”

Mà còn là:

“Nếu nó làm sai, chúng mình có phát hiện và khôi phục được không?”

Một cách triển khai thận trọng có thể chia quyền theo cấp độ:

• Agent được tự do đọc và phân tích.
• Agent được tạo bản nháp nhưng chưa được gửi.
• Agent được thực hiện giao dịch nhỏ trong một giới hạn xác định.
• Hành động ảnh hưởng lớn luôn cần con người phê duyệt.

Agent không nhất thiết phải nhận toàn bộ quyền tự chủ ngay từ ngày đầu tiên.

5. Giá trị tạo ra có lớn hơn chi phí của Agent không?

Agent thường phải gọi model nhiều lần, sử dụng nhiều công cụ và duy trì context qua nhiều bước. Điều đó làm tăng độ trễ, chi phí vận hành và số điểm có thể xảy ra lỗi.

Google Cloud đề xuất đánh giá ít nhất bốn nhóm yếu tố trước khi chọn kiến trúc agentic: đặc điểm của nhiệm vụ, yêu cầu về độ trễ, ngân sách và mức độ cần con người tham gia. Với những quy trình dễ dự đoán hoặc có cấu trúc rõ, giải pháp không dùng Agent có thể kinh tế hơn. Google Cloud

Giả sử một nhân viên chỉ mất 30 giây để duyệt một tác vụ diễn ra 20 lần mỗi tháng. Việc xây Agent có thể tạo ra một demo rất đẹp, nhưng chưa chắc tạo ra business value tương xứng.

Ngược lại, nếu một tác vụ mất hai giờ, xuất hiện hàng nghìn lần và đòi hỏi tìm kiếm qua nhiều hệ thống, khoản đầu tư có thể hợp lý hơn.

PM cần tính cả những chi phí ít khi xuất hiện trên slide demo:

• Chi phí inference;
• Thời gian phản hồi;
• Công sức xây eval;
• Hệ thống quan sát và lưu vết;
• Xử lý exception;
• Human review;
• Support khi kết quả sai;
• Chi phí cơ hội so với giải pháp đơn giản hơn.

Đôi khi một nút bấm và ba rule rõ ràng vẫn là quyết định sản phẩm tốt hơn.

Không được “agentic” lắm, nhưng chạy ổn.

Chapter 03

Quay lại workflow hoàn tiền

Bây giờ, hãy tách workflow ban đầu thành từng phần.

Xác định đơn hàng từ mã giao dịch

Dữ liệu có cấu trúc, đường đi cố định. Dùng truy vấn thông thường.

Đọc lý do hoàn tiền từ nội dung khách hàng viết

Input không có cấu trúc nhưng output khá rõ. Có thể dùng một model để phân loại hoặc tóm tắt.

Kiểm tra điều kiện hoàn tiền

Nếu chính sách có thể chuyển thành rule, hãy dùng rule. Hệ thống sẽ dễ kiểm tra và giải thích hơn.

Điều tra trường hợp bất thường

Đây có thể là nơi Agent tạo ra giá trị. Nó phải chọn nguồn dữ liệu, kiểm tra nhiều dấu hiệu và thay đổi hướng điều tra dựa trên điều vừa phát hiện.

Phê duyệt khoản hoàn tiền lớn

Agent có thể đề xuất, nhưng con người nên giữ quyền quyết định cuối cùng nếu hậu quả của sai sót đủ lớn.

Như vậy, câu trả lời không nhất thiết là “workflow này cần Agent” hoặc “workflow này không cần Agent”.

Một workflow có thể gồm nhiều cơ chế khác nhau:

Rule cho phần có thể dự đoán, AI-assisted cho phần cần diễn giải, Agent cho phần cần tự tìm đường và con người cho quyết định có hậu quả lớn.

Đây cũng là lý do PM nên phân rã workflow trước khi chọn công nghệ.

Nếu bắt đầu bằng câu hỏi “Agent có thể làm gì?”, mọi vấn đề sẽ trông giống một cơ hội để dùng Agent.

Nếu bắt đầu bằng từng task, team sẽ nhìn thấy nơi nào thực sự cần đến quyền tự chủ.

Chapter 04

Đừng pilot Agent bằng một nút “Go live”

Khi đã tìm được một task có vẻ phù hợp, team vẫn chưa cần trao quyền hành động ngay.

Có thể bắt đầu bằng shadow mode: Agent chạy cùng quy trình thật, đưa ra kế hoạch và đề xuất nhưng chưa được phép tác động đến người dùng hoặc dữ liệu. Team so sánh quyết định của Agent với kết quả thực tế để tìm ra các failure mode.

Sau đó, mở quyền theo từng lớp:

1. Chỉ đọc dữ liệu.
2. Đưa ra đề xuất.
3. Tạo bản nháp hành động.
4. Thực hiện sau khi được phê duyệt.
5. Tự thực hiện trong phạm vi rủi ro thấp.
6. Chuyển cho con người khi gặp tình huống ngoài giới hạn.

Và thay vì chỉ đo “Agent xử lý được bao nhiêu task”, PM nên theo dõi:

• Tỷ lệ hoàn thành đúng mục tiêu;
• Tỷ lệ cần con người can thiệp;
• Tỷ lệ exception;
• Thời gian hoàn thành;
• Chi phí cho mỗi task hoàn thành;
• Tỷ lệ hành động phải hoàn tác;
• Số lỗi nghiêm trọng;
• Mức độ người dùng hiểu và kiểm soát được Agent.

Một Agent tự động xử lý 90% yêu cầu nghe khá ấn tượng.

Nhưng nếu 10% còn lại là những trường hợp khó nhất, gây ra phần lớn khiếu nại và cần nhiều thời gian khắc phục hơn quy trình cũ, chúng mình chưa chắc đã cải thiện sản phẩm.

Lời nhắn

Trong một thảo luận gần đây trên r/ProductManagement, một PM kể rằng sau khi phân rã workflow, họ nhận thấy khoảng 70% tác vụ nên tiếp tục được xử lý theo cách deterministic; chỉ một phần nhỏ thật sự cần Agent. Reddit

Mình nghĩ đây là một quan sát đáng để chúng mình dừng lại một chút.

Sự trưởng thành của Product Management không nằm ở việc đưa Agent vào càng nhiều nơi càng tốt. Nó nằm ở khả năng nhận ra nơi nào sự linh hoạt của Agent đáng để đánh đổi bằng chi phí, độ trễ và rủi ro lớn hơn.