Workflow Design cho hệ thống AI #19

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Workflow Design cho hệ thống AI là việc thiết kế state, transition, owner, input/output contract, failure policy và evidence cho từng bước. Một workflow tốt không chỉ mô tả happy path; nó còn biết khi nào retry, wait, handoff, reconcile, stop và resume mà không nhân đôi side effect.

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

• Cách biến flowchart thành một state machine có thể vận hành và kiểm thử.
• Cách chọn retry, catch, wait, compensation hoặc stop theo error class.
• Cách dựng Blueprint và Run Ledger cho một workflow AI có checkpoint rõ.

1. Workflow Design là gì, và vì sao flowchart chưa đủ?

Flowchart cho biết A đi tới B rồi tới C. Nó hữu ích để trao đổi ý tưởng, nhưng chưa trả lời: B nhận input gì, ai chạy B, B tạo artifact nào, evidence nào chứng minh B xong, và timeout ở B thì đi đâu.

Trong Workflow Design, state là trạng thái hiện tại có tên và dữ liệu. Transition là việc chuyển từ state này sang state khác. Guard là điều kiện bắt buộc trước transition. Nếu guard chưa đạt, workflow phải giữ state, chọn failure path hoặc handoff; nó không được “đi tiếp cho đủ luồng”.

Ví dụ tracking vận đơn không chỉ vẽ đường từ kho tới nhà. Nó có trạng thái picked_up, in_transit, out_for_delivery, mỗi trạng thái gắn scan time và location. Nếu thiếu scan, hệ thống không nên tự gọi kiện hàng là đã giao.

Một workflow AI cũng vậy. Message “agent đã làm xong” chưa phải evidence. Evidence có thể là sources@v1, test report, schema validation, approval ID hoặc receipt từ downstream.

Mỗi state nên có contract tối thiểu:

Hình 1 — Mũi tên chỉ hướng; workflow vận hành cần contract và evidence cho từng transition.

Điều này không có nghĩa mọi bước đều phải dùng LLM. Validation, permission, budget và routing rõ quy tắc nên để code deterministic giữ. LLM phù hợp hơn với phần mơ hồ như tóm tắt, phân loại có ngữ cảnh hoặc tạo draft; output của nó vẫn đi qua gate.

2. Workflow Blueprint: state, guard, owner, artifact và evidence

Workflow Blueprint là bản thiết kế executable contract, không phải ảnh trang trí. Bắt đầu bằng terminal state: thế nào là complete, waiting, stopped hay failed? Sau đó đi ngược lại để xác định evidence cần ở mỗi bước.

Một blueprint nên có:

• danh sách state và terminal state;
• input/output schema;
• owner cho từng task;
• artifact name và version;
• transition guard;
• timeout và error classes;
• retry/catch/wait/handoff path;
• checkpoint và audit record;
• permission, budget và approval.

Checkpoint là snapshot đủ để resume. Nó không nhất thiết lưu mọi token hoặc lời suy nghĩ; chỉ cần state, artifact versions, completed actions, remaining budget, errors và pending approvals.

Khi workflow restart, orchestrator đọc checkpoint thay vì hỏi model “lần trước đã làm gì”. Với write action, idempotency giúp cùng request không tạo side effect trùng. Nếu result không rõ, workflow reconcile trạng thái thật trước retry.

Anchor của workflow có thể viết:

RECEIVED → VALIDATED → EXECUTED → VERIFIED → DECIDED → RECORDED

Mỗi transition cần hai phần: guard pass và evidence được ghi. VERIFIED → DECIDED không mở chỉ vì reviewer nói “ổn”; nó cần review artifact/version và gate result tương ứng.

Hình 2 — Transition chỉ xảy ra khi guard pass và evidence của state hiện tại đã được ghi.

OpenAI mô tả workflow như chuỗi bước để đạt goal và khuyến nghị routine có action rõ, conditional branch và edge case. Run loop cũng cần exit condition. Đây là nguyên tắc orchestration; cách lưu state, permission và business evidence vẫn do hệ thống triển khai.

3. Failure policy: retry, catch, wait, compensate hay stop?

Retry không phải thuốc chữa mọi lỗi. Trước hết phải phân loại:

Catch/fallback là nhánh xử lý khi task fail. Nó có thể chuyển sang nguồn dự phòng, lưu partial result hoặc handoff. Fallback không được lặng lẽ hạ success criteria chỉ để báo complete.

Wait dùng khi cần input, approval hoặc external event. State phải ghi đang chờ gì, từ ai, hết hạn lúc nào. “Pending” không có owner và timeout là một workflow bị treo.

Compensation là action bù cho side effect trước, không làm lịch sử biến mất. Refund có thể bù charge, nhưng charge vẫn từng xảy ra; email xin lỗi không thu hồi được email đã đọc. Vì vậy, high-impact action cần prevention/approval trước, không dựa vào lời hứa “undo”.

AWS Step Functions hỗ trợ Retry và Catch theo error, đồng thời khuyến nghị timeout rõ để task không chờ vô hạn. Tài liệu cũng cho thấy có error terminal hoặc không retriable theo cách mặc định. Bài học tổng quát: error taxonomy phải quyết định policy, không phải một retry wildcard cho mọi thứ.

Hình 3 — Retry chỉ dành cho lỗi phù hợp; các lỗi khác phải wait, reconcile, handoff hoặc stop.

4. Case WF-19: từ BRIEF-19 đến local approval

Workflow WF-19 nhận BRIEF-19 với mục tiêu tạo một article draft có ba nguồn và citation đầy đủ. Publish không thuộc quyền local run.

State graph:

RECEIVED → INPUT_VALIDATED → SOURCES_READY → DRAFT_READY → REVIEW_PENDING → LOCAL_APPROVED → WAITING_PUBLISH_APPROVAL

Ở INPUT_VALIDATED, schema và required fields pass. Workflow thu thập nguồn. Fetch S2 timeout; error class là transient nên retry đúng 1/1, lần hai thành công. Artifact sources@v1 gồm S1/S2/S3 và source IDs.

Writer tạo article@v1; state sang REVIEW_PENDING. Reviewer phát hiện claim C3 thiếu citation. Đây không phải network error, nên workflow không rerun fetch vô hạn. Nó tạo repair contract đúng finding, budget 1/1. Writer tạo article@v2; reviewer kiểm lại và pass.

Run Ledger:

Final state là local_approved_waiting_publish. Retry 1, repair 1, external actions 0. Workflow không nói “published” và cũng không gọi local approval là production release.

Hình 4 — S2 retry một lần và article v1 repair một lần; publish vẫn disabled.

Nếu process chết sau article@v2, checkpoint cho biết sources/draft versions đã tồn tại và review pass. Resume chuyển tới pending publish approval; nó không tạo lại draft hoặc giả định approval.

5. Sai lầm, giới hạn và rủi ro vận hành

Sai lầm đầu tiên là chỉ thiết kế happy path. Production thường hỏng ở thiếu input, partial write, timeout, duplicate event, expired approval và version mismatch. Mỗi task cần ít nhất success, retryable failure, non-retryable failure và timeout path.

Sai lầm thứ hai là state quá mơ hồ. PROCESSING không nói đang ở task nào, artifact nào đã xong hay ai giữ ownership. State nên đủ cụ thể để người vận hành biết hành động tiếp.

Sai lầm thứ ba là cho LLM sửa transition guard. Model có thể đánh giá nội dung, nhưng không được tự tăng retry budget, đổi permission hoặc hạ acceptance gate để chuyển state.

Sai lầm thứ tư là nhầm persistence với correctness. Durable execution nghĩa state được lưu để process tiếp tục sau gián đoạn. Azure Durable Functions tự persist parameters, return values và state cho reliable execution, nhưng persistence cũng có cost và không tự làm business logic đúng.

Sai lầm thứ năm là deploy workflow version mới lên run cũ mà không có strategy. State names, schema hoặc next transition có thể đổi. Cần version workflow/artifact, policy migrate hoặc để run cũ hoàn tất trên version cũ.

Cuối cùng, observability không phải log mọi thứ. Cần log structured run ID, state transition, artifact version, error class, budget, approval và result; tránh secret/PII. Metric hữu ích gồm state dwell time, retry rate, handoff rate và terminal outcomes.

6. Bài tập 15 phút: dựng Workflow Blueprint

Dùng spreadsheet hoặc diagram tool miễn phí. Không gọi API, gửi email hoặc publish thật.

Ba phút đầu, ghi bảy state của WF-19 và success criteria. Ba phút tiếp theo, điền input/output/owner cho mỗi state. Sau đó thêm transition guard và error class.

Ba phút kế tiếp, đi qua case S2 timeout và review finding C3. Hãy kiểm rằng timeout dùng retry, còn missing citation dùng repair. Ba phút cuối, ghi checkpoint, final state và external actions.

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

Kết quả phải là local_approved_waiting_publish. Nếu bạn ghi published, quay lại sửa terminal state. Đây là dữ liệu giả và bài tập thiết kế hệ thống, không dùng tiền thật.

7. Tổng kết và bài học tiếp theo

Năm ý chính

• Workflow Design cần state contract, không chỉ mũi tên.
• Transition cần guard, artifact version và evidence.
• Retry, wait, catch, reconcile, compensation và stop xử lý error khác nhau.
• Checkpoint/idempotency giúp resume an toàn hơn nhưng không tự tạo correctness.
• Terminal state phải phản ánh đúng side effect đã xảy ra.

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

• Vì sao message “done” chưa đủ mở transition?
• Khi write timeout, vì sao cần reconcile trước retry?
• Compensation khác rollback hoàn hảo ở đâu?

Gợi ý đáp án

Xem gợi ý câu 1

Vì transition cần artifact/version và evidence từ guard, không chỉ lời báo. Xem mục 1–2.

Xem gợi ý câu 2

Action có thể đã chạy; retry mù có thể tạo side effect trùng. Xem mục 2–3.

Xem gợi ý câu 3

Compensation tạo action bù nhưng side effect và lịch sử ban đầu vẫn tồn tại. Xem mục 3.

Thuật ngữ cần nhớ

Bài trước, Autonomous Agent #18, đặt envelope cho dynamic path. Bài tiếp theo, AI Architecture #20, sẽ ghép model, orchestration, data, tool, security, eval và observability thành hệ thống production.

Nguồn tham khảo

• OpenAI — A practical guide to building agents
• AWS Step Functions — Handling errors in workflows
• AWS Step Functions — Best practices and timeouts
• Microsoft Learn — Durable Functions state persistence
• Microsoft Learn — Azure Functions reliability and idempotency

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.