Đừng xây agent khi workflow là đủ

Đừng xây agent khi workflow là đủ

Ai cũng muốn xây AI agent, nhưng đa số bài toán thực tế chỉ cần workflow đơn giản. Chọn sai kiến trúc là tốn tiền, tốn thời gian, và debug muốn khóc.

Sprint planning sáng thứ Hai

Sáng thứ Hai, sprint planning. Tech lead hào hứng: "Tuần này mình ship AI agent tự động xử lý ticket support nhé." Cả team gật gù. Hai tuần sau, con agent đó tự ý gửi email xin lỗi khách hàng vì một cái bug... chưa ai report. Vấn đề không phải model dở — mà là team chọn sai kiến trúc ngay từ bước đầu tiên.

Mình thấy pattern này lặp lại ở rất nhiều team: nghe "agent" là hào hứng, bê framework về, bắt đầu xây — rồi hai tuần sau nhận ra bài toán chỉ cần một cái workflow chạy tuần tự là xong. Anthropic — sau khi làm việc với hàng chục team xây agent — cũng đúc kết thẳng thắn: bắt đầu bằng giải pháp đơn giản nhất có thể, chỉ tăng phức tạp khi thực sự cần. Đôi khi "không xây agentic system" mới là lựa chọn đúng.

Workflow vs Agent — ranh giới mỏng nhưng chọn nhầm là đau

Workflow là khi bạn viết code quy định rõ "bước 1 → bước 2 → bước 3", LLM chỉ xử lý từng bước được giao. Agent là khi bạn đưa mục tiêu, LLM tự quyết định dùng tool nào, theo thứ tự nào, lặp bao nhiêu lần.

Hình dung thế này: workflow giống như đưa công thức nấu ăn cho đầu bếp — cứ theo từng bước mà làm. Agent giống như bạn nói "nấu cho tôi bữa tối ngon" rồi để đầu bếp tự chọn món, tự đi chợ, tự nêm nếm. Nghe thì agent "xịn" hơn, nhưng nếu bạn chỉ cần chiên trứng mà thuê Gordon Ramsay tự do sáng tạo... chưa chắc kết quả là cái trứng ốp la bạn muốn.

Vậy khác biệt cốt lõi nằm ở đâu? Ai điều khiển luồng xử lý. Workflow thì code của bạn điều khiển. Agent thì LLM điều khiển. Đơn giản vậy thôi, nhưng hệ quả về debug, chi phí, và độ tin cậy thì khác nhau một trời một vực.

Bẫy "multi-agent" mà team nào cũng dễ dính

Mình kể chuyện thật (đã đổi tên cho lịch sự). Team của anh Minh — startup edtech ở TP.HCM — muốn xây chatbot tư vấn khóa học. Anh Minh đọc blog thấy "multi-agent architecture" hay quá: một agent phân tích nhu cầu học viên, một agent tìm khóa học phù hợp, một agent soạn email follow-up. Ba agent "phối hợp" nhịp nhàng trên giấy.

Thực tế? Ba agent đá bóng trách nhiệm cho nhau như phòng ban trong một công ty lớn. Agent tìm khóa học trả kết quả, agent soạn email hiểu sai context. Debug thì không biết lỗi ở đâu. Chi phí API tăng gấp ba vì mỗi "cuộc hội thoại nội bộ" giữa các agent đều tốn token.

Cuối cùng anh Minh xóa sạch, viết lại bằng một workflow ba bước:

  1. Nhận input → gọi LLM phân tích nhu cầu
  2. Query database khóa học → rank kết quả
  3. Gọi LLM format response

Ba bước, một luồng cố định, chạy ổn, dễ debug, chi phí giảm rõ rệt. Multi-agent mà không có "huấn luyện viên" phân vai rõ ràng thì giống đội bóng toàn tiền đạo — trên giấy firepower ghê gớm, ra sân không ai phòng ngự thì thua là cái chắc.

Vậy khi nào MỚI nên dùng agent?

Agent phát huy sức mạnh khi bài toán có những đặc điểm:

Giả sử team bạn 5 người, đang xây internal tool review code tự động. Nếu luồng luôn là "nhận PR → chạy lint → gọi LLM review → post comment" thì workflow là đủ. Nhưng nếu bạn muốn tool tự quyết: "PR này cần check security không? Cần đọc thêm doc nào? Nên hỏi lại dev hay tự suggest fix?" — lúc đó agent mới hợp lý, vì luồng xử lý thay đổi tùy từng PR.

Thử ngay chiều nay: prototype trong 3 bước

Không cần framework phức tạp. Composable pattern đơn giản là đủ.

Bước 1 — Chọn đúng "hạng cân"

Tự hỏi: "Luồng xử lý có cố định không?" Nếu có → workflow. Nếu không → mới nghĩ đến agent.

Bước 2 — Bắt đầu với một LLM call + một tool

# Ví dụ minh họa: LLM quyết định có cần gọi tool hay không
tools = [{"type": "function", "function": {"name": "search_docs", ...}}]
response = openai.chat.completions.create(
    model="gpt-4o-mini",  # hoặc model open-source qua API
    messages=[{"role": "user", "content": user_query}],
    tools=tools,
    tool_choice="auto"
)

Muốn dùng open-source? smolagents từ Hugging Face là lựa chọn gọn nhẹ đáng thử — thư viện agent nhỏ, dễ hiểu, dễ hack. Mixtral hay các model mở khác hoàn toàn đủ sức làm reasoning engine cho agent workflow cơ bản.

Bước 3 — Thêm loop, nhưng LUÔN có phanh

max_iterations = 5  # Đừng bao giờ để agent chạy vô tận
for i in range(max_iterations):
    response = call_llm_with_tools(messages)
    if response.finish_reason == "stop":
        break
    # Xử lý tool call, append kết quả vào messages

Dịch sang tiếng người: bạn cho LLM một vòng lặp để tự gọi tool, nhưng luôn giới hạn số vòng. Đừng bao giờ tin agent sẽ tự biết lúc nào nên dừng — giống như đừng tin mình sẽ "chỉ lướt TikTok 5 phút thôi".

Vector search: đừng coi là hộp đen

Một sai lầm phổ biến khi xây agent có RAG: nhét document vào vector database, query ra, xong. Nhưng cách bạn cấu hình — HNSW parameters, chunking strategy, reranking — ảnh hưởng trực tiếp đến chất lượng output.

Qdrant gần đây ra tính năng "Skills" — encode kiến thức chuyên sâu về vector search để agent (hoặc chính bạn) có thể điều chỉnh cấu hình thông minh hơn, thay vì dùng default rồi thắc mắc sao retrieval kém. Weaviate cũng đang xây hệ sinh thái agent tích hợp — Query Agent, Transformation Agent — giúp bạn không cần tự xây mọi thứ từ đầu.

Nói thẳng ra thì: nếu RAG của bạn trả kết quả tệ, phần lớn không phải lỗi model — mà lỗi ở cách bạn chuẩn bị dữ liệu và cấu hình retrieval.

Một takeaway duy nhất

Trước khi hào hứng mở terminal xây "AI agent platform", hãy tự hỏi: "Một chuỗi if-else với vài LLM call có giải quyết được bài toán này không?" Nếu câu trả lời là có — chúc mừng, bạn vừa tiết kiệm vài tuần debug và một đống tiền API.

Agent là công cụ mạnh, nhưng mua máy khoan công nghiệp để treo một bức tranh thì ngoài việc tốn tiền, bạn còn có nguy cơ khoan thủ cả bức tường.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo