title: "Framework cho Agents: LangChain, CrewAI, AutoGen (Cái nào cho mục đích gì?)"
series: "AI-Native Solutions Architect: Từ Coder đến Kiến trúc sư AI"
season: "Season 3 — AI Agents & Platform Engineering"
order: 22
audience: "Software Engineer hướng tới Solutions Architect"
reading_time: "12 phút"
tags: ["ai-agents", "langchain", "crewai", "autogen", "multi-agent-systems", "solutions-architecture", "framework-selection"]

Framework cho Agents: LangChain, CrewAI, AutoGen (Cái nào cho mục đích gì?)

Team bạn vừa quyết định build một agent xử lý yêu cầu hỗ trợ khách hàng tự động. Bạn mở GitHub, gõ "agent framework python", và trong 10 phút bạn có 6 tab: LangChain, LangGraph, CrewAI, AutoGen, LlamaIndex Agents, OpenAI Swarm. Mỗi framework có docs riêng, philosophy riêng, và một cộng đồng đang tranh cãi cái nào "tốt hơn". Ba tuần sau, bạn đã viết 2000 dòng code trên LangChain, nhận ra nó quá thừa cho use case đơn giản của mình, rồi cân nhắc viết lại bằng CrewAI vì đọc được một bài blog nói CrewAI "dễ hơn nhiều".

Đây không phải vấn đề công nghệ — đây là vấn đề thiếu một mental model để đánh giá framework. Không có framework nào "tốt nhất" một cách tuyệt đối. Mỗi framework xoay quanh một triết lý điều phối (orchestration philosophy) khác nhau, và triết lý đó quyết định nó fit với loại bài toán nào. Chọn sai không chỉ tốn thời gian viết lại — nó còn khiến bạn convert vấn đề của mình theo khuôn của framework thay vì để framework phục vụ vấn đề.

Là Solutions Architect, việc bạn cần làm không phải là "học hết mọi framework" mà là nhận diện được: bài toán của mình thuộc dạng nào (single-agent, team theo vai trò, hay điều phối hội thoại phức tạp), rồi chọn công cụ có triết lý khớp nhất — hoặc thẳng thắn nhận ra mình không cần framework nào cả.

Vấn đề

Hệ sinh thái framework cho AI agent phát triển với tốc độ chóng mặt trong hai năm qua, và phần lớn tài liệu marketing của từng framework đều mô tả chính nó như một giải pháp tổng quát cho "mọi bài toán agent". Điều này tạo ra ba loại sai lầm phổ biến ở đội ngũ kỹ thuật:

Sai lầm 1 — Chọn theo độ hot, không theo bài toán. Team thấy framework X đang trending, quyết định dùng nó cho một tác vụ chỉ cần gọi API tuần tự 2 bước. Framework mang theo abstraction layer (agent executor, memory module, callback system) cho một việc mà một hàm Python 20 dòng có thể giải quyết.

Sai lầm 2 — Đánh giá framework qua feature list thay vì qua orchestration model. Một bảng so sánh liệt kê "hỗ trợ tool-calling: có/có/có" không nói lên điều gì về cách framework đó tư duy về việc điều phối nhiều bước, nhiều agent. Đây mới là điểm khác biệt cốt lõi, không phải danh sách tính năng bề mặt.

Sai lầm 3 — Bỏ qua chi phí di chuyển (migration cost). Một khi logic nghiệp vụ đã gắn chặt vào các class, decorator, và pattern riêng của một framework, việc chuyển sang framework khác — hoặc tệ hơn, chuyển sang gọi API thuần — trở thành một dự án tái viết, không phải một refactor.

Nhiệm vụ của kiến trúc sư là tách biệt hai câu hỏi: "Bài toán của tôi cần loại điều phối nào?" và "Framework nào hiện thực hoá loại điều phối đó tốt nhất, với chi phí lock-in chấp nhận được?". Phần tiếp theo đi vào triết lý thiết kế của ba framework phổ biến nhất, để bạn có cơ sở trả lời câu hỏi đầu tiên.

Kỹ thuật cốt lõi

Điểm chung: agent là gì trong mọi framework

Ở tầng thấp nhất, mọi framework agent đều xoay quanh cùng một vòng lặp — LLM nhận input, quyết định có cần gọi tool hay không, thực thi tool, đưa kết quả trở lại context, lặp lại đến khi có câu trả lời cuối (bài 23 đi sâu vào tool use và function calling). Sự khác biệt giữa các framework nằm ở cách chúng tổ chức nhiều vòng lặp đó khi bài toán cần nhiều hơn một "bộ não" làm việc cùng nhau.

flowchart TD
    A["Bài toán cần Agent"] --> B{Một agent, một việc?}
    B -->|Có| C["Framework tổng quát<br/>(LangChain / gọi API trực tiếp)"]
    B -->|Không| D{Nhiều agent,<br/>chia theo VAI TRÒ?}
    D -->|Có| E["Multi-agent role-based<br/>(CrewAI)"]
    D -->|Không| F{Nhiều agent,<br/>điều phối qua HỘI THOẠI?}
    F -->|Có| G["Conversation-driven<br/>(AutoGen)"]

LangChain — framework tổng quát, nhiều building block

LangChain ra đời sớm nhất trong nhóm này và định hình triết lý "cung cấp mọi mảnh ghép, để lập trình viên tự lắp ráp". Nó không áp đặt một mô hình điều phối cụ thể — thay vào đó, nó cho bạn một tập hợp lớn các building block: prompt templates, output parsers, retrievers, memory modules, document loaders, và (qua LangGraph) một engine để định nghĩa luồng điều phối dưới dạng state graph tường minh.

Triết lý cốt lõi: tùy biến sâu, độ phức tạp cao hơn. Bạn có thể build gần như bất kỳ pipeline agentic nào — từ RAG đơn giản đến multi-agent graph với vòng lặp có điều kiện, human-in-the-loop checkpoint, retry logic tùy chỉnh. Cái giá phải trả là learning curve dốc hơn và codebase có xu hướng phình to với các abstraction layer nếu không kỷ luật trong thiết kế.

LangChain phù hợp nhất khi bạn cần kiểm soát chi tiết luồng điều phối — agent phải rẽ nhánh dựa trên điều kiện nghiệp vụ phức tạp, cần checkpoint để con người duyệt giữa chừng, cần tích hợp nhiều nguồn dữ liệu không đồng nhất — hoặc khi team đã quen với graph-based state machine và muốn toàn quyền kiểm soát logic điều phối thay vì để framework quyết định thay.

CrewAI — multi-agent theo vai trò, tư duy "đội ngũ"

CrewAI xây dựng xoay quanh một ẩn dụ rất trực quan: bạn không lập trình một pipeline, bạn thành lập một đội ngũ. Mỗi agent trong CrewAI được định nghĩa bằng một role (vai trò), một goal (mục tiêu), và một backstory (bối cảnh) — giống như bạn đang viết job description cho một nhân viên. Các agent này sau đó được gán task cụ thể, và một Process (sequential hoặc hierarchical) quyết định các task được thực thi và bàn giao cho nhau như thế nào.

Triết lý cốt lõi: collaboration theo vai trò, dễ tư duy vì ánh xạ trực tiếp lên cách con người tổ chức công việc nhóm. Nếu bạn có thể mô tả bài toán như "một Researcher tìm thông tin, chuyển cho một Writer soạn báo cáo, rồi một Editor rà soát lại", CrewAI cho bạn viết code gần như là bản dịch trực tiếp của câu mô tả đó — không cần hiểu state graph, chỉ cần hiểu tổ chức nhóm.

Đánh đổi: sự trực quan này đến từ một mức trừu tượng hoá cao hơn về cách điều phối thực sự diễn ra bên dưới. Khi logic điều phối không khớp với mô hình "đội ngũ tuần tự/phân cấp" — ví dụ điều phối động dựa trên kết quả trung gian, vòng lặp có điều kiện phức tạp — CrewAI sẽ gò bó hơn LangChain.

AutoGen — điều phối theo hội thoại giữa nhiều agent

AutoGen (từ Microsoft Research) xuất phát từ một góc nhìn khác: thay vì mô hình hóa agent như nhân viên trong một tổ chức, AutoGen mô hình hóa chúng như những người tham gia một cuộc hội thoại. Mỗi agent là một "conversable agent" có thể gửi và nhận message. Việc giải quyết vấn đề diễn ra thông qua các agent trao đổi qua lại — một AssistantAgent đề xuất giải pháp, một UserProxyAgent (đại diện người dùng hoặc một executor) thực thi code và phản hồi kết quả, rồi cuộc hội thoại tiếp tục đến khi đạt điều kiện dừng.

Triết lý cốt lõi: conversation là đơn vị điều phối cơ bản, không phải task graph hay role hierarchy. Điều này làm AutoGen đặc biệt mạnh trong các bài toán cần lặp lại kiểu "đề xuất — phản biện — sửa" (một agent viết code, một agent khác review và tìm bug, vòng lặp tiếp tục đến khi code pass), hoặc khi số vòng trao đổi không biết trước và phụ thuộc vào nội dung hội thoại thực tế, chứ không phải một luồng task cố định.

Đánh đổi: vì đơn vị điều phối là message hội thoại chứ không phải task rời rạc, việc kiểm soát tường minh "agent nào chạy khi nào" đòi hỏi định nghĩa rõ speaker selection logic (ai được nói tiếp theo trong group chat) — nếu không cấu hình cẩn thận, luồng hội thoại có thể trở nên khó dự đoán hoặc lặp vòng không cần thiết.

Bảng tóm tắt triết lý

Lưu ý: đây là mô tả về triết lý thiết kế, không phải cam kết tính năng hay giá cả cụ thể — các framework này cập nhật API liên tục. Trước khi implement, luôn kiểm tra documentation chính thức mới nhất.

Thực hành

Bảng quyết định chọn framework theo use case

Bảng dùng trực tiếp trong design review khi team tranh luận nên chọn công cụ nào:

Minh hoạ khác biệt cách tiếp cận qua code tối giản

Đoạn code dưới đây không phải cú pháp API thật — đây là pseudo-syntax đại diện để minh hoạ khác biệt trong cách mỗi framework yêu cầu bạn tư duy khi khởi tạo một agent cơ bản. Trước khi viết code thật, luôn tham khảo documentation chính thức mới nhất vì API thay đổi thường xuyên.

# ============================================================
# Cách 1 — Triết lý "building block, tự lắp ráp" (kiểu LangChain)
# Bạn định nghĩa từng thành phần rời rạc rồi ghép thành một chain/graph
# ============================================================

from representative_framework import Agent, Tool, StateGraph

search_tool = Tool(name="web_search", func=search_web)
llm = ChatModel(model="claude-opus-4-8")

# Bạn tự định nghĩa luồng điều phối dưới dạng graph có state tường minh
graph = StateGraph()
graph.add_node("research", lambda state: llm.invoke(state, tools=[search_tool]))
graph.add_node("summarize", lambda state: llm.invoke(state))
graph.add_edge("research", "summarize")
graph.set_entry_point("research")

app = graph.compile()
result = app.invoke({"input": "Tổng hợp xu hướng thị trường SaaS Việt Nam 2026"})


# ============================================================
# Cách 2 — Triết lý "đội ngũ có vai trò" (kiểu CrewAI)
# Bạn mô tả agent như một nhân viên: có vai trò, mục tiêu, bối cảnh
# ============================================================

from representative_framework import Agent, Task, Crew, Process

researcher = Agent(
    role="Market Researcher",
    goal="Tìm dữ liệu thị trường SaaS Việt Nam mới nhất, có nguồn trích dẫn",
    backstory="Chuyên gia phân tích thị trường B2B SaaS khu vực Đông Nam Á",
    tools=[search_tool],
)

writer = Agent(
    role="Report Writer",
    goal="Viết báo cáo tổng hợp súc tích từ dữ liệu researcher cung cấp",
    backstory="Content writer chuyên viết báo cáo kinh doanh cho ban lãnh đạo",
)

research_task = Task(
    description="Tìm và tổng hợp 5 xu hướng thị trường SaaS Việt Nam 2026",
    agent=researcher,
)
write_task = Task(
    description="Viết báo cáo 500 từ dựa trên kết quả research_task",
    agent=writer,
    context=[research_task],  # bàn giao kết quả từ researcher sang writer
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process=Process.sequential,  # hoặc Process.hierarchical
)
result = crew.kickoff()


# ============================================================
# Cách 3 — Triết lý "hội thoại giữa các agent" (kiểu AutoGen)
# Bạn định nghĩa ai nói chuyện với ai, và điều kiện dừng hội thoại
# ============================================================

from representative_framework import ConversableAgent

coder = ConversableAgent(
    name="Coder",
    system_message="Bạn viết code Python để giải bài toán được giao.",
    llm_config={"model": "claude-opus-4-8"},
)

reviewer = ConversableAgent(
    name="Reviewer",
    system_message="Bạn review code, chỉ ra bug, và yêu cầu sửa nếu chưa đạt.",
    llm_config={"model": "claude-opus-4-8"},
)

executor = ConversableAgent(
    name="Executor",
    human_input_mode="NEVER",
    code_execution_config={"use_docker": True},  # chạy code trong sandbox
)

# Cuộc hội thoại tự lặp: Coder viết -> Executor chạy -> Reviewer nhận xét
# -> Coder sửa (nếu cần) -> ... đến khi Reviewer xác nhận đạt hoặc hết max_turns
chat_result = coder.initiate_chat(
    reviewer,
    message="Viết hàm kiểm tra số nguyên tố, kèm test case.",
    max_turns=6,
)

Điểm cần rút ra không phải là cú pháp — mà là đơn vị tư duy khi thiết kế: LangChain bắt bạn nghĩ bằng graph và state; CrewAI bắt bạn nghĩ bằng vai trò và bàn giao nhiệm vụ; AutoGen bắt bạn nghĩ bằng lượt hội thoại và điều kiện dừng. Chọn framework tức là chọn ngôn ngữ tư duy khớp với cách bạn đã hình dung giải pháp.

Cạm bẫy thường gặp

1. Dùng framework agent cho một việc chỉ cần một lệnh gọi API tuần tự. Một tác vụ như "gọi LLM tóm tắt văn bản, rồi gọi LLM lần hai để dịch kết quả" không cần bất kỳ framework agent nào — nó chỉ cần hai lời gọi API nối tiếp trong một hàm Python bình thường. Import một framework agent đầy đủ (executor, memory, callback, tool registry) cho việc này giống như dùng Kubernetes để deploy một script cron chạy mỗi ngày một lần — thêm bề mặt lỗi, thêm dependency phải maintain, thêm thời gian onboard, mà không thu lại giá trị tương xứng. Quy tắc kinh nghiệm: nếu luồng xử lý vẽ được bằng một mũi tên thẳng, không rẽ nhánh, không cần nhiều "bộ não" ra quyết định độc lập — đừng dùng framework agent.

2. Phụ thuộc quá sâu vào API riêng của một framework khiến khó migrate sau này. Khi logic nghiệp vụ cốt lõi (prompt, quy tắc rẽ nhánh, cách xử lý lỗi) bị viết xen lẫn với các class, decorator, và convention đặc thù của framework, bạn đã tạo ra một dạng vendor lock-in — không phải với nhà cung cấp LLM, mà với chính framework điều phối. Sáu tháng sau, framework đó có thể ngừng được maintain tích cực, thay đổi breaking API ở major version tiếp theo, hoặc không còn phù hợp khi bài toán phát triển phức tạp hơn phạm vi ban đầu. Giảm thiểu rủi ro bằng cách tách rõ domain logic (prompt template, business rule, validation) ra khỏi orchestration glue code (cách framework gọi các bước) — domain logic nên là hàm/class thuần, độc lập với framework, còn framework chỉ đóng vai trò "dây nối" mỏng nhất ở lớp ngoài cùng.

3. Đánh giá framework qua độ phổ biến trên mạng xã hội thay vì qua fit với bài toán thực tế. Framework "hot" tuần này thường phản ánh nó phù hợp với demo ấn tượng và use case phổ biến trong cộng đồng open-source — không nhất thiết phù hợp với ràng buộc kỹ thuật cụ thể của bạn (compliance, latency, kiểm soát chi phí, khả năng audit từng bước quyết định của agent trong production). Trước khi quyết định, tự hỏi: "Bài toán của tôi thuộc dạng điều phối nào trong ba dạng đã nêu ở trên?" trước khi hỏi "Framework nào đang được nói đến nhiều nhất?".

🧭 Góc nhìn Solutions Architect

Nếu phải thay framework điều phối sau sáu tháng, bao nhiêu phần trăm codebase hiện tại là logic nghiệp vụ thuần có thể tái sử dụng, và bao nhiêu là glue code gắn chặt vào API riêng của framework?

Bài toán của mình có thực sự cần nhiều agent phối hợp, hay đây là một tác vụ đơn agent mà mình đang overengineer vì "ai cũng đang xây multi-agent system"?

Nếu phải giải thích luồng ra quyết định của hệ thống agent này cho một auditor không biết gì về AI, mô hình điều phối hiện tại (graph, role-based, hay conversation-based) có đủ minh bạch để giải thích không, hay nó là một hộp đen mà chính team cũng khó truy vết?

🔗 Bài viết liên quan

• Bài 21: Introduction to AI Agents — nền tảng khái niệm về agent trước khi đi vào lựa chọn framework cụ thể.
• Bài 23: Tool Use & Function Calling — đi sâu vào cơ chế tool-calling nằm bên dưới mọi framework đã nhắc ở bài này.
• Bài 24: Multi-Agent Systems — áp dụng thực tế mô hình multi-agent (coder/reviewer/tester) mà CrewAI và AutoGen đều có thể hiện thực hoá.

Bài trước: Introduction to AI Agents · Bài tiếp theo: Tool Use & Function Calling