Workflows vs. Agents – Hai cách xây dựng AI hoàn toàn khác nhau mà bạn cần phân biệt

Chào mừng bạn đến với Fx Studio.

Nếu bạn đang tìm hiểu về AI agents, có lẽ bạn đã thấy hai từ này xuất hiện khắp nơi: workflows và agents. Nhiều người dùng chúng lẫn lộn, hoặc mặc định nghĩ rằng “agent” là phiên bản cao cấp hơn của “workflow“. Thực tế phức tạp hơn — và thú vị hơn — thế nhiều.

Anthropic (công ty đứng sau Claude) đã đưa ra một cách phân biệt rất rõ ràng trong tài liệu Building Effective AI Agents. Bài viết này sẽ tổng hợp và phân tích sự khác biệt đó, kèm các ví dụ cụ thể để bạn hình dung dễ hơn.

Trước hết: Cả hai đều thuộc “agentic systems”

Anthropic gộp tất cả các hệ thống có LLM tham gia vào xử lý tác vụ dưới một thuật ngữ chung: agentic systems (hệ thống tác tử). Nhưng bên trong đó, họ vẽ ra một ranh giới kiến trúc quan trọng:

• Workflows là hệ thống mà LLM và công cụ được điều phối qua các luồng code định nghĩa trước.
• Agents là hệ thống mà LLM tự chủ động điều hướng quy trình và quyết định sử dụng công cụ nào.

Nghe có vẻ trừu tượng, nên hãy thử dùng một phép so sánh đời thường.

Phép so sánh nhà bếp

Hãy tưởng tượng bạn điều hành một nhà bếp.

Workflow giống như bạn viết sẵn một công thức nấu ăn chi tiết: bước 1 sơ chế, bước 2 xào, bước 3 nêm gia vị, bước 4 trình bày. Đầu bếp (LLM) rất giỏi — họ xào tuyệt vời, nêm nếm chuẩn xác — nhưng họ không tự quyết định nấu món gì hay thay đổi thứ tự. Bạn (developer) là người thiết kế toàn bộ quy trình.

Agent giống như bạn nói với đầu bếp: “Hôm nay có khách VIP, làm một bữa tối ấn tượng đi.” Đầu bếp tự kiểm tra nguyên liệu trong tủ lạnh, tự quyết định thực đơn, tự chọn kỹ thuật nấu, và tự điều chỉnh nếu giữa chừng phát hiện hết một nguyên liệu nào đó. Bạn chỉ đặt mục tiêu và cung cấp công cụ (bếp, dao, gia vị), phần còn lại do đầu bếp tự xử.

Câu hỏi cốt lõi luôn là: Ai đang lái — developer hay model?

Workflows: Khi bạn biết trước đường đi

Workflows hoạt động theo luồng xử lý được lập trình sẵn. LLM được gọi tại từng bước như một công cụ mạnh mẽ, nhưng không có quyền quyết định bước tiếp theo.

Ví dụ thực tế

Giả sử bạn xây một hệ thống tạo nội dung đa ngôn ngữ cho công ty:

1. Nhận yêu cầu từ marketing team
2. LLM call #1: Viết bản nháp tiếng Anh
3. Gate: Kiểm tra tự động xem bản nháp có đạt tiêu chuẩn brand voice không
4. LLM call #2: Dịch sang tiếng Việt
5. LLM call #3: Dịch sang tiếng Nhật
6. Xuất kết quả

Mỗi bước đã được bạn thiết kế trước. Dù LLM tạo ra output rất sáng tạo, nó không tự quyết định “à, bài này nên viết thêm phiên bản cho Instagram nữa” — trừ khi bạn đã code sẵn nhánh đó.

Tại sao workflows lại hấp dẫn?

Vì chúng mang lại những thứ mà production system cần nhất: tính dự đoán được, dễ test, dễ debug, chi phí kiểm soát được, và latency có giới hạn rõ ràng. Cùng một input đi qua cùng một luồng, bạn biết chính xác chuyện gì sẽ xảy ra.

Anthropic mô tả năm pattern workflow chính, từ đơn giản đến phức tạp:

• Prompt Chaining — xâu chuỗi các bước tuần tự, output bước trước là input bước sau. Ví dụ: viết dàn ý → kiểm tra tiêu chí → viết tài liệu hoàn chỉnh.
• Routing — phân loại input rồi chuyển đến luồng xử lý chuyên biệt. Ví dụ: hệ thống support tự phân loại “hỏi về thanh toán” → chuyển đến agent thanh toán, “hỏi về kỹ thuật” → chuyển đến agent kỹ thuật.
• Parallelization — chạy nhiều LLM call song song. Có hai kiểu: sectioning (chia tác vụ thành phần độc lập chạy đồng thời) và voting (chạy cùng tác vụ nhiều lần để lấy đa góc nhìn). Ví dụ: review code bằng ba prompt khác nhau, mỗi prompt tìm một loại lỗ hổng riêng.
• Orchestrator-Workers — một LLM trung tâm phân tách tác vụ linh động, ủy thác cho các LLM worker. Khác với parallelization ở chỗ các tác vụ con không được định trước mà do orchestrator quyết định dựa trên input.
• Evaluator-Optimizer — một LLM tạo output, LLM khác đánh giá, lặp lại cho đến khi đạt chất lượng. Ví dụ: viết code → review code → sửa → review lại → đạt chuẩn thì dừng.

Dù orchestrator-workers hay evaluator-optimizer nghe khá “agent-like”, chúng vẫn là workflow — vì luồng xử lý tổng thể được developer thiết kế trước.

Agents: Khi bạn không biết trước đường đi

Agents hoạt động theo một vòng lặp khác hẳn. Bạn đưa cho model một mục tiêu, một bộ công cụ, và một điều kiện dừng. Phần còn lại — kế hoạch, thứ tự, công cụ nào dùng khi nào — do model tự quyết.

Ví dụ thực tế

Anthropic nêu hai trường hợp cụ thể:

Coding agent giải SWE-bench: Nhận mô tả một bug hoặc feature request, agent tự phân tích codebase, tự xác định cần sửa những file nào (có thể là 2 file, có thể là 15 file — không ai biết trước), tự viết code sửa, chạy test, và lặp lại cho đến khi test pass. Developer không thể thiết kế trước workflow cho trường hợp này vì mỗi task có số bước và bản chất hoàn toàn khác nhau.

Computer use agent: Claude được giao tác vụ “đặt vé máy bay từ Hà Nội đi Tokyo”, rồi tự điều khiển trình duyệt — mở trang web, điền form, so sánh giá, chọn chuyến. Không ai biết trước trang web nào sẽ load, form nào sẽ xuất hiện, hay có cần đăng nhập không.

Cơ chế hoạt động của agent

Vòng lặp cơ bản khá đơn giản:

1. Nhận mục tiêu từ người dùng
2. Suy luận và lập kế hoạch
3. Chọn công cụ và thực thi
4. Quan sát kết quả (“ground truth” từ môi trường)
5. Đánh giá tiến độ — đã xong chưa?
6. Nếu chưa → quay lại bước 2
7. Nếu xong, hoặc đạt giới hạn lặp → dừng

Điểm quan trọng mà Anthropic nhấn mạnh: agent phải liên tục thu thập “ground truth” từ môi trường thực — kết quả chạy code, phản hồi từ API, nội dung trang web… — chứ không phải chỉ dựa vào suy luận nội bộ. Đây là thứ giữ agent “chân đất” thay vì trôi vào ảo giác.

Đây không phải “chọn A hoặc B”

Một điểm hay mà nhiều người bỏ qua: trong thực tế, hầu hết hệ thống production là sự kết hợp của cả workflows và agents.

Hình dung thế này: bạn có một workflow routing ở tầng trên — phân loại yêu cầu khách hàng thành “hỏi thông tin”, “khiếu nại”, “yêu cầu hoàn tiền”. Mỗi nhánh này có thể gọi đến một agent chuyên biệt có khả năng tự chủ ở mức độ nhất định. Hoặc ngược lại — một agent tự chủ nhưng bên trong nó sử dụng prompt chaining cho những bước con nhất định.

Ranh giới giữa workflows và agents không phải đường kẻ cứng, mà là một phổ liên tục — từ hoàn toàn xác định (workflow thuần) đến hoàn toàn tự chủ (agent thuần), với đa số hệ thống nằm ở đâu đó giữa.

Ba cấp quyết định: Bạn thực sự cần gì?

Anthropic đưa ra một hướng dẫn rất thực dụng, có thể tóm thành ba cấp:

Cấp 1: Single LLM call (đa số trường hợp)

Tối ưu prompt, thêm retrieval (RAG), thêm ví dụ in-context — rồi dừng lại. Anthropic nói thẳng rằng với nhiều ứng dụng, chỉ cần tối ưu một lệnh gọi LLM đơn lẻ là đủ. Đây là điều nhiều team bỏ qua vì vội nhảy sang xây agent.

Cấp 2: Workflow (khi cần nhiều bước, nhưng dự đoán được)

Bạn biết trước tác vụ cần những bước gì, theo thứ tự nào. Ví dụ: pipeline xử lý tài liệu, hệ thống customer support có luồng rõ ràng, hệ thống tạo báo cáo tự động.

Cấp 3: Agent (khi tác vụ mở, không thể hardcode luồng)

Tác vụ phức tạp mà không biết trước cần bao nhiêu bước hay bước gì. Ví dụ: coding tasks phức tạp, nghiên cứu đa nguồn cần nhiều vòng tìm kiếm, hoặc tác vụ đòi hỏi tương tác với môi trường không dự đoán trước.

Quy tắc vàng: chỉ tăng độ phức tạp khi có bằng chứng đo lường được rằng nó cải thiện kết quả.

Bài học từ thực tế: Agent không phải lúc nào cũng tốt hơn

Một chi tiết thú vị: ngay cả trong lĩnh vực coding — nơi agents được kỳ vọng rất cao — thực tế cho thấy các agent tự chủ hoàn toàn (như Devin) hoạt động tốt với tác vụ đơn giản, rõ ràng, nhưng lại gặp khó khăn với tác vụ phức tạp hoặc mơ hồ. Trong khi đó, các công cụ dạng workflow nâng cao (như Cursor) — nơi con người vẫn giữ vai trò điều hướng — lại cho kết quả ổn định hơn.

Điều này không có nghĩa agents vô dụng. Nó có nghĩa là agent phù hợp với đúng loại bài toán — những bài toán đòi hỏi cả hội thoại lẫn hành động, có tiêu chí thành công rõ ràng, có vòng phản hồi, và tích hợp được giám sát từ con người.

Customer support là một ví dụ điển hình: tương tác tự nhiên theo dạng hội thoại, cần truy xuất dữ liệu khách hàng và thực hiện hành động (hoàn tiền, cập nhật ticket), có tiêu chí thành công rõ (khách hàng được giải quyết vấn đề), và có thể chuyển cho con người khi cần.

Tạm kết: Xây đúng, không xây “xịn”

Thông điệp xuyên suốt từ Anthropic rất nhất quán: thành công không phải là xây hệ thống phức tạp nhất, mà là xây hệ thống phù hợp nhất.

• Bắt đầu với prompt đơn giản.
• Tối ưu chúng bằng đánh giá toàn diện.
• Thêm workflow khi single call không đủ.
• Và chỉ dùng agent khi workflow thực sự không đáp ứng được.

Nghe có vẻ thiếu tham vọng?

Có lẽ. Nhưng đây là lời khuyên đến từ chính công ty xây dựng những model AI mạnh nhất thế giới — và họ nói điều này sau khi làm việc với hàng loạt khách hàng đang deploy agentic systems ở production. Đôi khi, lời khuyên tốt nhất là biết khi nào nên dừng lại.

Cảm ơn bạn đã đọc bài viết này!

Written by chuotfx

Hãy ngồi xuống, uống miếng bánh và ăn miếng trà. Chúng ta cùng nhau đàm đạo về đời, về code nhóe!