Chuyển tới nội dung chính

Chọn AI Agent Workflow Pattern có thể đưa vào production

· 5 phút để đọc
Claude Dev
Claude Dev
Claude Dev

Phần lớn team thất bại với agent không phải vì model kém.

Họ thất bại vì chọn sai workflow pattern quá sớm: orchestration quá mức, quá nhiều thành phần, nhưng không có lý do rõ ràng cho độ phức tạp đó.

Bài chính thức gần đây của Anthropic về các pattern workflow cho agent rất hữu ích, nhưng bài này viết lại theo góc nhìn developer đang xây hệ thống production.

Quy tắc mà hầu hết team bỏ qua​

Hãy bắt đầu từ pattern đơn giản nhất vẫn đạt quality bar.

Trong thực tế:

  1. Thử single-agent call trước
  2. Chỉ thêm các bước tuần tự khi dependency bắt buộc
  3. Chỉ thêm worker song song khi tác vụ thật sự độc lập và độ trễ quan trọng
  4. Chỉ thêm evaluator-optimizer loop khi mức cải thiện đo được

Nếu bỏ qua thứ tự này, bạn thường trả giá bằng latency, token cost và pain khi debug.

Pattern 1: Sequential Workflows​

Dùng sequential khi bước B phụ thuộc vào kết quả của bước A.

Hãy nghĩ nó như pipeline:

  • extract
  • transform
  • validate
  • route

Khi phù hợp​

  • Tác vụ nhiều bước có dependency cứng
  • Pipeline dữ liệu mà mỗi stage thêm một loại giá trị khác nhau
  • Luồng Draft -> review -> polish

Khi không phù hợp​

  • Một agent đã làm việc ổn định
  • Các bước tách ra chỉ mang tính hình thức và có thể gộp

Tradeoff cho developer​

  • Latency cao hơn
  • Kiểm soát tốt hơn và observability rõ hơn theo từng stage

Bài test nhanh​

Nếu bỏ một stage mà chất lượng đầu ra gần như không đổi, stage đó có thể không cần.

Pattern 2: Parallel Workflows​

Dùng parallel khi các subtasks độc lập và có thể chạy cùng lúc.

Theo ngôn ngữ distributed systems, đây là fan-out/fan-in:

  • fan out công việc cho nhiều agents
  • fan in bằng một chiến lược tổng hợp

Khi phù hợp​

  • Đánh giá đa chiều (an toàn, văn phong, tính đúng)
  • Security/code review theo từng nhóm tiêu chí
  • Phân tích tài liệu bằng các góc nhìn độc lập

Khi không phù hợp​

  • Agents cần chia sẻ context thay đổi liên tục
  • Không có chiến lược tổng hợp đủ chắc chắn
  • Giới hạn quota/concurrency API làm mất lợi ích tốc độ

Tradeoff cho developer​

  • Hoàn thành nhanh hơn
  • Chi phí cao hơn + độ phức tạp tổng hợp cao hơn

Bài test nhanh​

Nếu logic tổng hợp còn phức tạp hơn mỗi worker song song, bạn đã parallel quá tay.

Pattern 3: Evaluator-Optimizer Workflows​

Dùng evaluator-optimizer khi chất lượng lần đầu chưa đủ và tiêu chí chất lượng được định nghĩa rõ.

Cấu trúc:

  • Generator tạo bản nháp
  • Evaluator chấm theo tiêu chí cụ thể
  • Generator sửa lại
  • Dừng khi đạt ngưỡng hoặc chạm số vòng lặp tối đa

Khi phù hợp​

  • Sinh code với tiêu chuẩn nghiêm ngặt
  • Tài liệu/giao tiếp rủi ro cao cần đúng giọng và chính xác
  • Sinh SQL/query cần kiểm tra security/performance

Khi không phù hợp​

  • Tương tác thời gian thực cần phản hồi ngay
  • Tác vụ có tiêu chí quá chủ quan, evaluator khó chấm nhất quán
  • Trường hợp đã có công cụ deterministic để validate (linters, schema validators)

Tradeoff cho developer​

  • Chất lượng có thể tăng rõ rệt
  • Tốn token hơn, chậm hơn, và có rủi ro lặp vi chỉnh vô tận

Bài test nhanh​

Nếu vòng lặp từ lần 3 trở đi cải thiện rất nhỏ, hãy giảm iteration cap.

Decision Tree thực dụng​

Dùng phần này trong design review hoặc planning docs:

  1. Một agent có giải được ổn định không? Nếu có, dừng lại.
  2. Có dependency cứng giữa các bước không? Nếu có, chọn sequential.
  3. Subtasks có độc lập và nhạy với độ trễ không? Nếu có, thêm nhánh parallel.
  4. Chất lượng lượt đầu có dưới chuẩn và đo được không? Nếu có, thêm evaluator-optimizer ở những điểm cần thiết.

Cách này giữ độ phức tạp tương xứng với nhu cầu thực.

Cần định nghĩa xử lý lỗi ngay từ đầu​

Bất kể pattern nào, hãy định nghĩa trước khi rollout:

  • Retry policy theo từng stage
  • Timeout budget
  • Fallback behavior
  • Chiến lược xử lý lỗi một phần
  • Quy tắc xử lý output mâu thuẫn

Không có phần này, “agent architecture” chỉ là demo.

Đặt baseline trước khi orchestration​

Khuyến nghị của Anthropic đi đúng hướng: hãy có baseline từ cách đơn giản trước.

Với team kỹ thuật, ít nhất cần theo dõi:

  • task success rate
  • latency p50/p95
  • token cost trên mỗi lần chạy thành công
  • tỷ lệ cần con người sửa kết quả

Chỉ giữ orchestration bổ sung nếu có chỉ số cải thiện rõ.

Các tổ hợp pattern thường hiệu quả​

Pattern là các khối lắp ghép, không loại trừ nhau.

Hai tổ hợp phổ biến:

  • Sequential + Parallel: pipeline tuần tự, nhưng có 1-2 stage chạy song song nặng
  • Parallel + Evaluator: nhiều nhánh sinh hoặc review đổ vào một bước evaluator tập trung

Tránh lồng quá sâu nếu bạn không giải thích được tác động chất lượng/chi phí bằng số liệu.

Kết luận​

Workflow patterns không phải “diễn kiến trúc”, mà là bộ điều khiển chi phí/chất lượng.

Nếu bạn muốn hệ thống ship được và dễ bảo trì:

  • bắt đầu đơn giản
  • chỉ thêm cấu trúc khi bottleneck đã được chứng minh
  • đo lường mọi lần tăng độ phức tạp

Đó là cách biến thử nghiệm agent thành workflow production.

Nguồn​