Trả lời ngắn: Workflow Automation là cách biến một quy trình lặp lại thành đường chạy có trigger, state, step và điều kiện kết thúc. Mỗi step nhận dữ liệu hợp lệ, tạo đầu ra kiểm được rồi mới chuyển state. AI chỉ xử lý phần mơ hồ; workflow vẫn giữ quyền, chống chạy trùng và đưa lỗi vào đường recovery.

Đọc xong, bạn sẽ hiểu:

  • Workflow khác checklist, script và agent ở điểm nào.
  • Một Workflow Contract cần những trường gì.
  • Rule, AI, human và side-effect step nên đứng ở đâu.
  • Vì sao retry, idempotency và verification phải thiết kế từ đầu.

Lưu ý giáo dục: Các ví dụ dưới đây dùng yêu cầu hỗ trợ giả và note local. Không gửi email, tạo ticket, gọi API trả phí hoặc sửa production. Khi dùng dữ liệu thật, bạn còn phải tuân thủ quyền truy cập, bảo mật, lưu trữ và quy trình phê duyệt của tổ chức.

1. Workflow Automation là gì?

a. Từ việc lặp lại đến đường chạy có hợp đồng

Mỗi sáng, bạn mở form, kiểm tra nội dung, phân loại yêu cầu, chuyển đúng người rồi ghi lại kết quả. Làm tay, đó là quy trình. Viết một danh sách “bước 1, bước 2, bước 3”, đó là checklist. Khi một hệ thống nhận sự kiện, giữ trạng thái, thực thi từng bước theo điều kiện và xử lý cả đường lỗi, ta mới có workflow automation.

Anthropic phân biệt khá rõ: workflow điều phối model và tool theo code path định trước, còn agent để model tự quyết đường đi và cách dùng tool. Khi đường đi đã biết, workflow thường dễ dự đoán, test và kiểm soát chi phí hơn (Anthropic — Building Effective AI Agents).

b. AI là một step, không mặc định là người cầm lái

Ví dụ form hỗ trợ có bốn nhãn: billing, account, bug, other.

  • Email hợp lệ, nội dung không rỗng: rule.
  • Hiểu “tôi bị trừ hai lần” thuộc billing: AI classifier.
  • Chọn queue từ allowlist: rule.
  • Gửi hoặc sửa ticket thật: side effect cần quyền và verification.

c. Khi nào chưa nên tự động hóa?

Đừng tự động hóa một quy trình còn thay đổi mỗi ngày, không có owner hoặc chẳng ai thống nhất “xong” nghĩa là gì. Automation chỉ làm quy trình chạy nhanh hơn; nếu quy trình vốn mơ hồ, ta sẽ tạo ra lỗi nhanh và đều hơn.

Hình 1 — AI chỉ là một step trên execution rail; gate, verify và terminal route vẫn thuộc workflow.

2. Workflow Contract cần những trường nào?

a. Tám nhóm phải trả lời trước khi nối tool

Một sơ đồ đẹp chưa phải hợp đồng vận hành. Với mỗi workflow, hãy điền tối thiểu các nhóm sau:

Nhóm Câu hỏi cần trả lời
Goal và terminal state Success, rejected, needs review và failed được định nghĩa thế nào?
Trigger và instance ID Sự kiện nào bắt đầu? Record này có định danh duy nhất nào?
Input/output schema Step được nhận trường gì và phải trả cấu trúc gì?
State và transition Đang ở state nào? Điều kiện nào cho phép qua nhánh tiếp theo?
Step type Đây là rule, AI, human approval hay side effect?
Authority Workflow được đọc, ghi và gửi tới đâu? Ai phê duyệt phần nhạy cảm?
Verify và idempotency Bằng chứng thành công là gì? Chạy lại có tạo kết quả trùng không?
Recovery và owner Timeout, dữ liệu xấu hoặc kết quả mơ hồ đi đâu? Ai nhận cảnh báo?

Terminal state phải có nghĩa: rejected vì input sai khác failed vì hạ tầng lỗi; needs_review là đường hợp lệ khi máy chưa đủ chắc. Instance ID như R-1042 gắn mọi log, retry và approval với đúng lần chạy.

b. Mỗi step có hợp đồng nhỏ

Step “phân loại bằng AI” không nên nhận cả đống context rồi trả văn xuôi tùy hứng. Hợp đồng nhỏ có thể là:

  • Input: request_id, subject, body_clean.
  • Output: label, confidence, reason_summary.
  • Verify: đúng schema; label thuộc allowlist bốn nhãn.
  • Timeout: 15 giây; confidence dưới 0,75 thì needs_review.

Ngưỡng 0,75 chỉ minh họa; ngưỡng thật phải dựa trên dữ liệu đại diện và chi phí của từng loại sai.

Hình 2 — Contract Card buộc ta mô tả cả đường chạy lại và owner, không chỉ happy path.

3. Một workflow chạy từ trigger đến terminal state ra sao?

a. Trace một instance thành công

Giả sử form tạo event R-1042 với nội dung “Thẻ của tôi bị tính phí hai lần”. Workflow phiên bản 1.3 chạy như sau:

  1. Trigger: tạo instance key R-1042:v1.3.
  2. Validate: kiểm email, độ dài; state thành validated.
  3. Classify: AI trả billing, confidence 0,94; schema và allowlist pass.
  4. Route gate: rule map billing sang queue Billing.
  5. Action: chỉ tạo draft route local, không gửi ra ngoài.
  6. Verify: kiểm request_id, route và input hash.
  7. Record: ghi audit event, chuyển sang success.

HTTP 200 chưa chứng minh kết quả nghiệp vụ đúng; verify phải kiểm đối tượng, phiên bản và dữ liệu.

b. Ba record khác, ba đường khác

Record R-1043 thiếu email: validate fail, đi thẳng tới rejected, không gọi AI. Record R-1044 có câu quá mơ hồ và confidence 0,51: đi needs_review. Record R-1045 gọi classifier bị timeout: lỗi có vẻ tạm thời nên retry một lần với backoff; nếu vẫn lỗi thì failed và báo owner.

received → validated → classified → routed → success là happy path; validated → needs_review cũng là đường hợp lệ.

c. Checkpoint và observability

Workflow dài cần lưu checkpoint sau step đã verify. Azure Durable Functions mô tả runtime quản lý state, checkpoint, retry và recovery để workflow có thể chạy tin cậy trong thời gian dài (Microsoft — Durable Functions overview).

Log nên có instance ID, version, step, attempt, input hash, output summary, state trước/sau và error class. Không ghi secret hay private chain-of-thought; chỉ cần action, evidence và state delta.

4. Lỗi phổ biến và thiết kế recovery

a. Không phải lỗi nào cũng retry

Nếu dịch vụ bận tạm thời, workflow thử lại vài lần với thời gian chờ tăng dần. Nếu lỗi không thể sửa bằng thử lại, hệ chuyển bước dự phòng hoặc dừng và báo rõ. AWS Step Functions hỗ trợ cả hai cách xử lý này; một số lỗi vận hành hoặc dữ liệu quá lớn buộc quy trình phải dừng. (AWS — Error handling)

Tình huống Route đúng Vì sao
Mạng chập chờn, service tạm bận Retry có cap và backoff Lỗi có thể tự hết
Email sai hoặc body rỗng Reject Cùng input sẽ tiếp tục sai
AI trả nhãn ngoài allowlist Review hoặc fail Output vi phạm contract
Confidence thấp, hai nhãn sát nhau Human review Cần phán đoán, không phải hạ tầng lỗi
Timeout sau lệnh tạo ticket Reconcile trước khi retry Side effect có thể đã xảy ra

b. Idempotency cứu bạn khỏi “bấm hai lần”

Giả sử lệnh tạo ticket đã chạy, nhưng response bị mất. Workflow thấy timeout rồi gọi lại. Nếu không có idempotency key, ta có thể tạo hai ticket cho cùng R-1042.

Với key R-1042:create-ticket:v1, hệ thống đích có thể trả kết quả cũ thay vì tạo mới. Nếu không hỗ trợ, workflow phải reconcile theo external reference trước khi gọi lại. Microsoft khuyến nghị function nên stateless, idempotent và tiếp tục được từ failure point (Azure Functions reliability).

Hình 3 — Recovery bắt đầu bằng phân loại lỗi; retry chỉ là một trong bốn đường.

c. Năm lỗi thiết kế hay gặp

  1. Quy trình chưa ổn định: “xong” chưa thống nhất.
  2. AI quá nhiều quyền: model tự thực hiện side effect.
  3. Chỉ có happy path: lỗi không có route.
  4. Retry mọi lỗi: input sai bị gọi lại vô ích.
  5. Không có owner: cảnh báo không ai xử lý.

Approval cũng cần timeout. Durable Task cho workflow chờ external event cùng timer; quá hạn thì đi nhánh timeout thay vì treo (Microsoft — Human interaction pattern).

5. Bài tập 15 phút: vẽ Workflow Canvas

a. Chuẩn bị miễn phí

Dùng giấy, Markdown hoặc Google Sheets. Tạo sáu yêu cầu giả: bốn câu rõ, một câu mơ hồ và một record thiếu email. Không kết nối app thật.

Dùng sáu record R-01–R-06 bên dưới; che cột expected terminal state, chạy tay workflow, rồi mở đáp án để so transition và evidence.

b. Làm theo năm bước

  1. Vẽ success, rejected, needs_review, failed.
  2. Điền trigger, instance ID và input schema.
  3. Đánh dấu từng step: RULE, AI, HUMAN hoặc SIDE EFFECT.
  4. Thêm verify, idempotency và recovery route.
  5. Chạy tay sáu record, ghi evidence mỗi lần đổi state.

c. Mẫu đối chiếu đã điền

Trường Mẫu
Trigger Form mới có request_id
Input Email hợp lệ, body không rỗng
Rule Billing rõ → queue Billing
AI Chỉ phân loại câu mơ hồ thành 1/4 nhãn
Authority Tạo draft local; không gửi hoặc sửa ticket thật
Idempotency request_id + workflow_version
Verify Schema pass, route tồn tại, ID khớp
Recovery Timeout→retry; input xấu→reject; mơ hồ→review

d. Kết quả mong đợi

Bạn phải giải thích được terminal state của mỗi record. Nếu hai nhánh không có điều kiện phân biệt, Contract còn thiếu. Đây là rủi ro phải sửa trước khi kết nối app thật.

6. Tổng kết: tự động hóa tốt phải chạy lại được và giải thích được

a. Năm ý chính

  • Workflow dùng đường đi định trước; agent chỉ cần khi model phải tự chọn đường.
  • Mỗi step cần schema, transition và bằng chứng verify.
  • AI phải bị giới hạn bởi allowlist, authority và fallback.
  • Retry dành cho lỗi tạm thời; side effect không rõ phải reconcile.
  • Production cần idempotency, checkpoint, audit log, terminal state và owner.

b. Câu hỏi tự kiểm tra

  • Workflow và agent khác nhau ở đâu?
  • Vì sao HTTP 200 chưa đủ để đánh dấu success?
  • Timeout sau side effect nên xử lý thế nào?
  • Confidence thấp có nên retry không?

c. Gợi ý đáp án

Xem gợi ý câu 1Workflow theo code path định trước; agent để model tự quyết quá trình và tool. Xem lại mục 1.
Xem gợi ý câu 2HTTP 200 chỉ xác nhận giao thức; còn phải verify đối tượng và dữ liệu nghiệp vụ. Xem lại mục 3.
Xem gợi ý câu 3Dùng idempotency hoặc reconcile trước khi retry vì action có thể đã thành công. Xem lại mục 4.
Xem gợi ý câu 4Thường chuyển human review hoặc bổ sung dữ liệu; retry cùng input không giảm mơ hồ. Xem lại mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Workflow Đường chạy gồm các step và transition đã định.
Trigger Sự kiện bắt đầu một workflow instance.
Instance ID Định danh duy nhất cho một lần chạy.
Schema Cấu trúc dữ liệu được phép nhận hoặc trả.
State Trạng thái nghiệp vụ hiện tại của instance.
Transition Quy tắc chuyển từ state này sang state khác.
Side effect Hành động làm thay đổi hệ thống bên ngoài.
Idempotency Chạy lại cùng yêu cầu không tạo kết quả trùng.
Backoff Tăng thời gian chờ giữa các lần retry.
Reconcile Đối chiếu để biết side effect đã xảy ra chưa.

e. Nguồn tham khảo

f. Học tiếp gì?

Xem lại Framework Agentic Loop #40 nếu chưa rõ state và cửa thoát. Bài tiếp theo là AI Copilot #42 — khi nào hệ thống nên hỗ trợ con người thay vì tự động chạy hết quy trình.

Disclaimer cuối bài: Nội dung nhằm mục đích giáo dục về thiết kế hệ thống AI. Ví dụ, ngưỡng và dữ liệu đều là giả lập; không thay thế security review, privacy review hoặc quy trình phê duyệt khi triển khai thật.