# Workflow hay agent: chọn mẫu thiết kế nào khi khách nói "chúng tôi muốn một agent"

> Khách thường xin một agent, nhưng câu hỏi bạn cần mang vào buổi họp lại khác: bạn có liệt kê trước được các bước hệ thống phải đi hay không.

Bản gốc: https://fdetimes.net/vi/bach-khoa/workflow-hay-agent-chon-mau-thiet-ke/

Buổi họp đầu tiên với khách hàng thường mở đầu bằng một yêu cầu rất tự tin: "Chúng tôi muốn một agent xử lý email khách hàng." Họ đã xem demo, đã đọc tin tức, và trong đầu họ "agent" là thứ hiện đại nhất.

Việc của FDE không phải là gật đầu. Bạn phải tìm ra mẫu thiết kế nào giải quyết được bài toán với độ trễ, chi phí và độ tin cậy mà khách chấp nhận được. Chọn sai ở bước này thì ba tháng sau bạn sẽ ngồi debug một hệ thống không ai giải thích nổi vì sao hôm nay nó trả lời khác hôm qua.

Kỹ năng bài này bàn tới không lớn nhưng bạn sẽ cần đến gần như mỗi tuần: đọc bài toán của khách rồi quyết định nên dùng workflow, agent, hay một thứ đơn giản hơn cả hai.

## Ai quyết định bước tiếp theo?

Anthropic có một định nghĩa gọn. Workflow là hệ thống trong đó LLM và công cụ được điều phối qua các đường code định sẵn. Agent là hệ thống trong đó LLM tự điều hướng quy trình và việc dùng công cụ, tức là model nắm quyền quyết định cách hoàn thành nhiệm vụ.

Tài liệu của LangGraph cũng chia như vậy. Workflow có đường đi xác định trước và chạy theo một thứ tự đã thiết kế. Agent dành cho những tình huống mà cả vấn đề lẫn lời giải đều không đoán trước được.

Vì thế câu hỏi để phân loại rất đơn giản: **ai quyết định bước tiếp theo, code của bạn hay model?** Nếu bạn ngồi xuống viết được sơ đồ các nhánh trước khi chạy, đó là workflow. Nếu bạn không thể liệt kê các bước vì chúng phụ thuộc vào thứ model phát hiện ra giữa chừng, đó mới là chỗ của agent.

## Thang leo độ phức tạp

Lời khuyên cốt lõi của Anthropic là tìm giải pháp đơn giản nhất có thể và chỉ tăng độ phức tạp khi thật sự cần. Họ còn 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 bằng retrieval và ví dụ trong ngữ cảnh là thường đã đủ.

Lý do nằm ở đánh đổi. Hệ thống agentic thường chấp nhận độ trễ cao hơn và chi phí lớn hơn để đổi lấy chất lượng tốt hơn. Ngược lại, workflow mang lại tính dự đoán được và nhất quán cho những nhiệm vụ đã xác định rõ. Với khách doanh nghiệp, "nhất quán" thường là thứ họ cần nhất, chỉ là họ không gọi nó bằng cái tên đó.

Bậc cao nhất là multi-agent, nơi nhiều agent chạy song song. Anthropic ghi nhận hệ thống multi-agent của họ dùng khoảng 15× token so với chat thông thường. Theo họ, kiểu hệ thống này hợp với những việc có giá trị cao và song song hóa được nhiều, trong khi phần lớn việc lập trình lại khó song song hóa hơn nghiên cứu.

**Điểm mấu chốt:** Chỉ leo lên bậc trên khi bậc dưới đã được thử trên dữ liệu thật và không giải được bài toán.

## Một ví dụ làm từ đầu đến cuối

Thử hình dung một công ty logistics muốn tự động trả lời email khách hàng. Bạn xin 50 email thật và phân loại tay. Giả sử kết quả là phần lớn email hỏi tình trạng đơn hàng, một phần là câu hỏi chính sách có trong FAQ, và một phần nhỏ là khiếu nại phức tạp.

Với hai nhóm đầu, bạn viết được các bước ngay trên giấy: nhận diện ý định, lấy mã đơn, tra database, soạn trả lời. Không có gì bất ngờ ở đây, nên đây là workflow:

```python
# Workflow: code quyết định đường đi
def handle_email(email):
intent = classify(email)  # 1 lệnh gọi LLM, chỉ trả về nhãn cố định
if intent == "tra_cuu_don":
order = db.get_order(extract_order_id(email))
return draft_reply(email, context=order)
if intent == "chinh_sach":
return draft_reply(email, context=search_faq(email))
if intent == "khieu_nai":
return investigate_complaint(email)  # nhánh duy nhất có agent
return escalate_to_human(email)
```

Phiên bản agent mà khách hình dung trong đầu thường là một vòng lặp `while True` với đủ bộ tool, kể cả `issue_refund`. Khi đó việc có hoàn tiền hay không do model quyết định trong vòng lặp, và không dòng code nào chặn trước được.

Bản workflow thì mỗi email đi qua một số lệnh gọi LLM cố định, nên bạn ước được chi phí, đo được độ trễ, và khi có lỗi thì biết ngay nhánh nào sai.

Agent không bị loại bỏ, nó chỉ bị thu hẹp lại. Nếu nhóm khiếu nại thật sự đòi hỏi điều tra nhiều nguồn theo thứ tự không đoán trước được, bạn đặt agent ngay tại nhánh đó, với bộ tool hạn chế và giới hạn số bước:

```python
# Agent chỉ ở nhánh khiếu nại: model quyết định đường đi, nhưng trong rào chắn
COMPLAINT_TOOLS = [get_order, search_faq]  # chỉ đọc, không có issue_refund
MAX_STEPS = 6

def investigate_complaint(email):
messages = [COMPLAINT_PROMPT, email]
for _ in range(MAX_STEPS):
step = llm(messages, tools=COMPLAINT_TOOLS)
if step.is_final:
return draft_for_human_review(email, findings=step.text)
messages.append(run_tool(step))
return escalate_to_human(email)  # hết số bước: chuyển cho người
```

Đó là thiết kế lai mà bạn có thể bảo vệ trước khách: phần đoán trước được chạy bằng code, phần không đoán trước được mới giao cho model. Ngay cả ở phần đó, model chỉ đọc và đề xuất, còn quyết định hoàn tiền vẫn nằm trong tay người.

## Tự làm theo năm bước

Bước một: thu thập mẫu thật, đừng dùng mô tả của khách. Ba mươi đến năm mươi trường hợp thật sẽ cho bạn thấy bài toán đoán trước được đến mức nào, điều mà buổi họp đầu không bao giờ cho thấy.

Bước hai: thử bậc thấp nhất trước. Viết một prompt tốt, thêm retrieval và vài ví dụ, rồi chạy trên bộ mẫu. Nếu kết quả đã đạt, dừng ở đó.

Bước ba: vẽ sơ đồ nhánh cho những trường hợp bậc một chưa giải được. Nhánh nào vẽ ra được thì viết thành workflow.

Bước bốn: chỉ dùng agent cho phần còn lại, tức phần mà bạn thật sự không liệt kê được các bước. Đặt giới hạn số vòng lặp và chỉ đưa vào những tool cần thiết, như hàm `investigate_complaint` ở trên.

Bước năm: chỉ cân nhắc multi-agent khi nhiệm vụ chia được thành các phần độc lập, chạy song song, và giá trị kết quả đủ lớn để gánh khoản token tăng thêm.

## Những lỗi hay gặp

Lỗi phổ biến nhất là chọn agent vì demo đẹp. Demo chạy trên vài ca dễ, còn production phải chạy trên hàng nghìn ca mà khách cần kết quả giống nhau mỗi lần.

Lỗi thứ hai là chia nhỏ thành nhiều agent mà không chia sẻ ngữ cảnh. Cognition, công ty làm Devin, khuyên nên chia sẻ ngữ cảnh và chia sẻ toàn bộ trace của agent chứ không chỉ từng tin nhắn riêng lẻ.

Họ cũng chỉ ra rằng mỗi hành động đều mang theo một quyết định ngầm, và khi các agent song song đưa ra quyết định mâu thuẫn nhau thì kết quả sẽ tệ.

Lỗi thứ ba là không đo. Nếu bạn không biết mỗi yêu cầu tốn bao nhiêu lệnh gọi và chờ bao lâu, bạn không thể giải thích với khách vì sao nên leo thêm một bậc, hay vì sao không nên.

## Biến kỹ năng này thành lợi thế khi đi xin việc

Nếu JD bạn đang nhắm có nhắc đến agent, hãy chuẩn bị giải thích vì sao bạn chọn kiến trúc đó, chứ đừng chỉ kể rằng bạn đã dựng được một agent. Cách bạn lập luận về đánh đổi mới là thứ đáng đem ra nói.

Vì vậy trong CV, đừng chỉ ghi "xây dựng AI agent". Hãy mô tả quyết định: bạn đã thử những bậc nào, đo cái gì, và vì sao dừng ở workflow hay leo lên agent.

Một câu như "chuyển phần tra cứu từ vòng lặp agent sang workflow cố định để kết quả nhất quán" cho thấy bạn hiểu đánh đổi. Đó cũng là kiểu phán đoán bạn sẽ phải đưa ra mỗi tuần khi ngồi cạnh khách.

## Bài tập: để agent tự chỉ ra phần nào nên là workflow

Lấy một vòng lặp agent bạn đang có, hoặc tự viết một bản giống `investigate_complaint` cho bài toán email ở trên. Cho nó chạy 20 lần trên 20 đầu vào khác nhau và ghi lại chuỗi tool mà model đã gọi ở mỗi lần.

Sau đó xếp các chuỗi cạnh nhau. Chuỗi nào lặp lại gần như y hệt là ứng viên để viết lại thành một nhánh workflow, còn chuỗi nào mỗi lần một khác mới là phần đáng giữ cho agent. Ghi thêm số bước trung bình của mỗi lần chạy để biết `MAX_STEPS` nên đặt bao nhiêu.

Lần tới khách nói "chúng tôi muốn một agent", hãy hỏi họ năm mươi email gần nhất trước. Rất có thể chính những email đó sẽ cho bạn câu trả lời.

**Thử ngay tuần này:**

- Lấy 20 yêu cầu thật từ một quy trình ở công ty bạn, ghi các bước xử lý của từng yêu cầu, rồi đánh dấu yêu cầu nào liệt kê trước được các bước.
- Viết cùng một tính năng theo hai cách, một hàm workflow có if/else và một vòng lặp agent có tool, rồi đo số lệnh gọi LLM và thời gian chạy của mỗi cách.
- Thêm vào CV một dòng mô tả quyết định chọn mẫu thiết kế bạn từng đưa ra và lý do chọn nó.

## Nguồn

- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

- [How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)

- [Don't Build Multi-Agents](https://cognition.com/blog/dont-build-multi-agents)

- [Workflows and agents (LangGraph docs)](https://docs.langchain.com/oss/python/langgraph/workflows-agents)