Mô hình workflow AI agent: 7 mô hình và khi nào mỗi mô hình thực sự thắng (2026)

Mô hình workflow AI agent: 7 mô hình và khi nào mỗi mô hình thực sự thắng (2026)

Mô hình workflow AI agent cuối cùng cũng có con số đi kèm: tháng 1 năm 2026, Google Research đánh giá 180 cấu hình agent và phát hiện cùng một thay đổi phối hợp đã nâng khả năng suy luận tài chính song song hóa thêm 80,9% trong khi lại nghiền nát lập kế hoạch tuần tự tới 70% trên PlanCraft. Cùng một đòn bẩy, kết quả trái ngược. Biến số quyết định là khả năng phân rã của tác vụ, không phải số lượng agent, và bảy mô hình dưới đây được phán xử bằng dữ liệu đã công bố chứ không phải bằng sơ đồ của vendor.

• Bảy mô hình đáng kể: sequential, routing, song song hóa, orchestrator-workers, reflection, ReAct, plan-and-execute.
• Khả năng phân rã của tác vụ quyết định người thắng. Việc song song hóa được thì có lợi; việc tuần tự thì thoái lui.
• Bắt đầu với một agent. Chỉ thêm agent thứ hai khi một agent đơn chững lại dưới ngưỡng chính xác ~85%.

Mô hình workflow AI agent nhìn nhanh: dữ liệu nói gì

Bảy mô hình AI agent là sequential (chuỗi prompt), routing (handoff), song song hóa (fan-out/fan-in), orchestrator-workers, reflection (evaluator-optimizer), ReAct và plan-and-execute. Tài liệu của năm vendor gọi tên chúng khác nhau, nhưng bảy hình dạng này bao quát mọi hệ phân loại mà Anthropic, OpenAI, Vercel, Microsoft và Google Cloud hiện đang công bố. Human-in-the-loop không nằm trong số bảy mô hình: đó là một lớp kiểm soát bọc bên ngoài bất kỳ mô hình nào.

Hãy đọc cột đo được với sự hoài nghi. Ba hàng mang con số thật; bốn hàng ghi "chưa có phép đo công khai", và đó là trạng thái trung thực của lĩnh vực này trong năm 2026. Năm vendor công bố năm cái tên khác nhau cho thứ thực chất chỉ là ba hoặc bốn hình dạng nền tảng. Cột cuối tồn tại để bạn ánh xạ bất kỳ cái tên nào trong số đó về hình dạng bên dưới, và phần còn lại của bài sẽ bóc tách từng họ một.

Hai cột mà không ai trên SERP bàn tới là chi phí token và ngân sách độ trễ. Sequential và routing tốn ít nhất ở cả hai; orchestrator-workers tốn nhiều nhất ở cả hai; song song hóa đánh đổi chi tiêu token lấy thời gian thực. Hãy chọn mô hình theo tài nguyên mà tác vụ của bạn thực sự ràng buộc, không phải theo sơ đồ trông ấn tượng.

Mô hình workflow AI agent là gì (và 4 giai đoạn của một AI workflow)?

Design pattern của workflow AI agent là những hình dạng tái sử dụng được để sắp xếp các lời gọi LLM, việc dùng công cụ và logic điều khiển thành một hệ thống. Bảy mô hình lặp lại trong mọi hệ phân loại của vendor là sequential, routing, song song hóa, orchestrator-workers, reflection, ReAct và plan-and-execute. Mỗi mô hình đánh đổi chi phí token, độ trễ và độ chính xác theo cách khác nhau, nên lựa chọn đúng phụ thuộc vào cấu trúc của tác vụ chứ không phải framework bạn tình cờ dùng.

Một AI agent workflow điển hình chạy bốn giai đoạn theo một vòng lặp:

1. Plan: mô hình quyết định việc tiếp theo cần làm, dựa trên mục tiêu và lịch sử cho đến lúc đó.
2. Act: nó gọi một công cụ, mà vào năm 2026 thường nghĩa là một MCP server hoặc một function call. Model Context Protocol (MCP) chuẩn hóa lớp công cụ đó xuyên suốt các mô hình.
3. Observe: kết quả công cụ quay lại context dưới dạng một message mới.
4. Reflect / loop: mô hình phán đoán xem kết quả đã đủ tốt chưa, rồi lặp lại hoặc dừng.

Mọi mô hình trong bài này là một cách đi dây khác nhau cho bốn giai đoạn đó. Sequential cố định thứ tự trong code. ReAct để mô hình chọn giai đoạn tiếp theo ở mỗi lượt. Orchestrator-workers chia vòng lặp ra nhiều mô hình.

Một phân biệt quan trọng trước khi vào danh mục. Workflow là các đường dẫn code định trước; agent giao quyền điều khiển cho mô hình. Anthropic vạch ranh giới theo cách này trong Building Effective Agents: "Workflow mang lại khả năng dự đoán và tính nhất quán cho các tác vụ được định nghĩa rõ, trong khi agent là lựa chọn tốt hơn khi cần sự linh hoạt và ra quyết định do mô hình dẫn dắt ở quy mô lớn."

Nếu bạn đến đây để tìm các loại agent kinh điển trong AI (simple reflex, model-based, goal-based, learning), hệ phân loại đó có trước LLM; bảy mô hình ở trên mới là thứ quyết định bản build của bạn có ship được hay không.

Các mô hình tất định: Sequential, Routing và Parallelization

Ba mô hình giữ quyền điều khiển trong code của bạn thay vì trong mô hình. Chúng rẻ nhất để chạy và dễ debug nhất, và hướng dẫn tháng 3 năm 2026 của đội Claude nói thẳng về nơi bắt đầu: "Hãy bắt đầu với mô hình đơn giản nhất giải quyết được vấn đề của bạn. Mặc định là sequential."

Sequential (chuỗi prompt)

Một lời gọi tiếp nhiên liệu cho lời gọi tiếp theo. Bạn chia một tác vụ khó thành các bước có thứ tự, và mỗi bước nhận đầu ra của bước trước làm đầu vào. Cái lợi là tính dễ đọc: bạn có thể kiểm tra mọi kết quả trung gian và cache từng bước. Tránh dùng khi các tác vụ phụ độc lập, vì bạn đang trả độ trễ cho một thứ tự mà mình không cần. Nếu state phải sống sót giữa các bước hoặc xuyên suốt các phiên, đó là bài toán bộ nhớ, không phải bài toán chuỗi; xem hướng dẫn bộ nhớ agent của chúng tôi để biết cách chia tách. Sự chứng thực công khai duy nhất của nó là một mặc định: không có nghiên cứu nào đo lợi ích của bản thân việc chuỗi hóa, vì nó là baseline mà mọi mô hình khác phải trả thêm để đánh bại.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

Routing (handoff)

Một bộ phân loại rẻ đọc đầu vào và điều phối nó tới một prompt hoặc mô hình chuyên gia. OpenAI đóng khung nó trong tài liệu Agents SDK: "Agent phân loại định tuyến cuộc hội thoại tới một chuyên gia, và chuyên gia đó trở thành agent hoạt động cho phần còn lại của lượt." Tránh routing khi bộ phân loại kém tin cậy hơn việc chỉ chạy một đường tổng quát, vì mọi lần định tuyến sai là một câu trả lời sai thầm lặng. Chế độ lỗi có tên ở đây là mất context qua lần handoff: chuyên gia chỉ thấy những gì router chuyển tiếp. Mang theo toàn bộ trace là một quyết định context engineering, và làm sai là lý do các hệ thống được định tuyến có cảm giác hay quên. Dù sao thì toán token vẫn ủng hộ routing: bộ phân loại chạy trên một mô hình nhỏ (gpt-4o-mini ở trên), nên một router chỉ thêm vài trăm token rẻ mỗi request thay vì một lời gọi đắt tiền thứ hai.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

Parallelization (fan-out/fan-in)

Các tác vụ phụ độc lập chạy đồng thời, rồi một bước gộp kết hợp chúng lại. Anthropic chia mô hình này thành sectioning (chia nhỏ công việc) và voting (chạy cùng một tác vụ vài lần rồi so sánh). Đây là hình dạng mà Google Research đo được +80,9% so với một agent đơn trên suy luận tài chính song song hóa được vào tháng 1 năm 2026, chính xác là vì tác vụ phân rã sạch. Tránh dùng ngay khoảnh khắc bước n+1 phụ thuộc vào đầu ra của bước n; song song hóa một chuỗi phụ thuộc chỉ là sắp xếp lại các câu trả lời sai nhanh hơn. Độ trễ là nửa còn lại của cái lợi: các lời gọi độc lập chạy đồng thời, nên thời gian thực giảm xấp xỉ theo số worker trong khi tổng chi tiêu token giữ nguyên.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct và Plan-and-Execute: nên dùng mô hình suy luận nào?

ReAct xen kẽ suy luận với hành động: mô hình suy nghĩ, gọi công cụ, quan sát kết quả, và chỉ sau đó mới quyết định bước tiếp theo. Plan-and-execute viết toàn bộ kế hoạch trước khi bất kỳ công cụ nào chạy, rồi thực thi các bước theo thứ tự. ReAct thích ứng với bất ngờ giữa chừng; plan-and-execute trả trước cho một lời gọi lập kế hoạch lớn và tin vào lộ trình.

ReAct quyết định bước tiếp theo sau mỗi quan sát; plan-and-execute cam kết với toàn bộ lộ trình trước lần gọi công cụ đầu tiên.

ReAct đến từ Yao et al. (arXiv 2210.03629, v1 tháng 10 năm 2022, v3 tháng 3 năm 2023), báo cáo +34% thành công tuyệt đối trên ALFWorld và +10% trên WebShop so với các baseline imitation learning và reinforcement learning, chỉ dùng một hoặc hai ví dụ in-context. Nó là vòng lặp mặc định đằng sau hầu hết các agent dùng công cụ, và nó là một khoảng trống trong kết quả SERP #3: tài liệu orchestration dài 7.133 từ của Microsoft Learn bỏ qua ReAct hoàn toàn. Nhịp quan sát-rồi-quyết định đó là lý do ReAct xử lý các tác vụ mở ("duyệt cho đến khi tìm thấy X") tốt hơn bất kỳ kế hoạch định trước nào: kế hoạch sẽ phải đoán các trang chứa gì trước khi đọc chúng.

Plan-and-execute đến từ Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), trước tiên vạch ra một kế hoạch chia tác vụ thành các tác vụ phụ, rồi thực hiện chúng. Bài báo báo cáo thắng zero-shot chain-of-thought trên toàn bộ mười dataset được đánh giá; chúng tôi không trích dẫn con số đơn lẻ nào vì abstract của bài báo không công bố con số nào. Dùng khi lộ trình dự đoán được và việc lập lại kế hoạch sau mỗi bước sẽ lãng phí token. Sự đánh đổi là tính mong manh: nếu bước ba thất bại, một vòng lặp plan-and-execute cần một hook tái lập kế hoạch rõ ràng, trong khi ReAct tái lập kế hoạch theo chính cấu trúc của nó.

Hàng bằng chứng đo được là tín hiệu trung thực. ReAct có một bài báo năm 2022 với các con số cấp tác vụ; plan-and-execute có một cuộc quét mười dataset và không có con số tiêu đề, đó là một lý do nó được trích dẫn thường xuyên hơn là được benchmark.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

Giới hạn vòng lặp đó không phải tùy chọn. Một vòng lặp ReAct không có lối thoát đốt token cho đến khi ngân sách của bạn cạn; max_steps là rào chắn rẻ nhất trong toàn bộ bài này. Plan-and-execute cần cùng rào chắn đó ở một cấp cao hơn: giới hạn số lần tái lập kế hoạch, chứ không chỉ số bước, nếu không một kế hoạch thất bại sẽ tự sinh ra lại vô hạn.

Các mô hình chất lượng: Reflection, Evaluator-Optimizer và Human-in-the-Loop

Các mô hình chất lượng tiêu thêm token để nâng chất lượng đầu ra, và chúng chỉ đáng tiền khi chất lượng đo được. Reflection (Anthropic gọi là evaluator-optimizer) chạy một máy sinh và một máy phê bình trong một vòng lặp: một mô hình viết nháp, mô hình kia phê bình, bản nháp khá lên. Nếu bạn không thể chấm đầu ra bằng một bài test, một rubric hoặc một mô hình chấm điểm, máy phê bình chỉ là mớ token thừa đang cãi nhau với chính nó. Xây bộ chấm điểm đó mới là phần khó; hướng dẫn của chúng tôi về đánh giá agent trong production trình bày những gì một hàm điểm dùng được đòi hỏi. Khi điều kiện tiên quyết được giữ, mô hình này là bảo hiểm rẻ: Anthropic mô tả evaluator-optimizer như hai lời gọi LLM trong một vòng lặp, một sinh và một phê bình, đổi lấy mức tăng chất lượng đo được với vài giây độ trễ thêm.

Chế độ lỗi mà không ai vẽ sơ đồ là reflection mất kiểm soát: máy phê bình và máy sinh lặp mãi mãi, hoặc tệ hơn, dao động. Cách sửa là một giới hạn vòng lặp cứng cộng với một điểm dừng khi không cải thiện, viết trong code chứ không phải yêu cầu trong prompt:

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

Human-in-the-loop là một lớp kiểm soát, không phải mô hình thứ tám. Nó bọc bất kỳ mô hình nào trong số bảy: một con người phê duyệt trước khi một bước không thể đảo ngược chạy. Chỉ 2 trong 6 kết quả SERP hàng đầu có đề cập tới nó. Đặt cổng ở các hành động không thể đảo ngược, chi tiêu thật, và bất kỳ thứ gì rời hệ thống của bạn dưới dạng giao tiếp ra bên ngoài. Mọi thứ khác nên chạy không giám sát hoặc không chạy. Bản thân cái cổng nên là code đơn giản, không phải một LLM khác: một hàng đợi phê duyệt, một ngưỡng chi tiêu, một allowlist miền. Đặt một mô hình phụ trách việc quyết định xem con người có nên nhìn hay không là tự đánh bại mục đích.

Multi-agent có đáng với gấp 15 lần token? Benchmark thực sự nói gì

Orchestrator-workers là mô hình thứ bảy: một agent chỉ huy phân rã tác vụ, giao các phần cho các agent thợ, và gộp những gì chúng trả về. "Multi-agent" là mô hình này được đẩy tới cực đoan, không phải một hình dạng riêng, nên câu hỏi thực sự là khi nào orchestrator xứng đáng với chi phí đội lên của nó.

Khi nào nên dùng multi-agent thay vì một agent đơn? Chỉ khi một agent đơn chững lại dưới khoảng 85% độ chính xác trên tác vụ. Quy tắc kinh nghiệm đó lan truyền trên r/AI_Agents (2026-04-23) cùng với nghiên cứu của Google Research, và nó khớp với dữ liệu đo được: trên ngưỡng đó, thêm agent là thêm chi phí và khuếch đại lỗi mà không thêm độ chính xác.

Đây là mọi con số đã công bố mà chúng tôi xác minh được, đặt cạnh nhau:

Một lưu ý trước khi bạn bấm vào: mọi con số Google Research ở trên đến từ bài blog ngày 2026-01-28, và bài báo đằng sau nó (arXiv 2512.08296) đã được chỉnh sửa kể từ đó, nên phiên bản hiện tại báo cáo 260 cấu hình và R² = 0,373 thay vì 180 và 0,513 của blog. Chiều hướng giữ nguyên dù theo phiên bản nào; con số chính xác phụ thuộc vào phiên bản bạn đang đọc.

Hai trong số các hàng này thường xuyên bị trích dẫn sai, nên đây là số học. Con số 15× của Anthropic đo so với một tương tác chat, và con số agent đơn của họ là 4×. Nên multi-agent tốn xấp xỉ 15 / 4 = 3,75× token của một agent đơn, không phải 15×. Và khuếch đại lỗi 17,2× của Google Research cho agent độc lập so với 4,4× cho agent tập trung nghĩa là một orchestrator chứa xấp xỉ 17,2 / 4,4 = 3,9× ít khuếch đại lỗi hơn so với để agent chạy không giám sát.

Đọc bài viết của Anthropic đối chiếu với các con số của Google Research, cách đọc của chúng tôi là khả năng phân rã, không phải số lượng agent, mới là biến số quyết định. Tác vụ research của Anthropic chia sạch thành các tìm kiếm phụ song song, nên thêm agent giúp ích. Tác vụ lập kế hoạch tuần tự của Google không chia được, nên thêm agent chỉ cản đường nhau.

Điều đó khớp với những gì người làm thực tế nói khi hệ thống chạm production. Trên r/AI_Agents, một thread có tiêu đề "Multi agent systems are a total nightmare in production" (2026-04-23, 56 điểm, 68 bình luận) đến từ một OP đã ship hơn 20 hệ thống khách hàng: "Những thứ thực sự chạy được… đơn giản đến gần như đáng xấu hổ," và "mỗi lần một agent nói chuyện với một agent khác, bạn mất context. Giống hệt trò chơi Telephone." Bình luận đứng đầu cô đọng toàn bộ phần này: "hãy cố giải quyết vấn đề của bạn bằng một agent đơn. Nếu agent này có độ chính xác >85%, một hệ thống multi agent sẽ không thêm bất kỳ giá trị nào nữa."

Trước khi thêm một agent, hãy thử các sửa chữa rẻ mà Anthropic đã đo: một mô tả công cụ được cải thiện tạo ra mức giảm 40% thời gian hoàn thành tác vụ, và gọi công cụ song song cắt thời gian research tới 90%. Cả hai đều thắng một agent thứ hai về chi phí. Nếu bạn vẫn đi theo multi-agent trong một công cụ thật, subagent Claude Code là orchestrator-workers mà bạn có thể kiểm tra từng dòng.

Cùng một mô hình, năm cái tên: bảng Rosetta các framework

Cùng bốn hình dạng xuất hiện dưới những cái tên khác nhau trong tài liệu của mọi vendor, và cách gọi tên không chuyển được giữa các framework. "Magentic" và "group chat" của Microsoft chẳng có nghĩa gì trong OpenAI SDK cho đến khi bạn dịch chúng, và thứ thuế phiên dịch đó là một chi phí thật mà bảng này loại bỏ.

Năm vendor, năm bộ từ vựng, ba hoặc bốn hình dạng thật. Chi phí thực tế lộ ra khi bạn đổi framework: một đội chuyển từ Agent Framework của Microsoft sang OpenAI SDK phải ánh xạ lại "magentic" sang agents-as-tools và "group chat" sang một đồ thị handoff trước khi một dòng code duy nhất được chuyển đi. Hệ phân loại mười một cái tên của Google Cloud là dài nhất, danh sách bảy cái tên của Anthropic được trích dẫn nhiều nhất, và ba cái tên của blog Claude là những thứ bạn sẽ triển khai đầu tiên. Đọc hình dạng trước, rồi đọc SDK. Tiêu đề các cột chính là bản thân tài liệu: Anthropic, blog Claude, OpenAI Agents SDK, Vercel AI SDK, Microsoft Learn, và Google Cloud. Khi bạn đã nhìn ra các hình dạng, chọn framework là một quyết định riêng; bài tổng hợp của chúng tôi về các framework AI agent tốt nhất năm 2026 và bài so sánh LangGraph với CrewAI với OpenAI Agents SDK bao quát chuyện đó.

Khi nào bạn KHÔNG nên dùng agent workflow?

Thường là không nên. Thang quyết định được ủng hộ nhiều nhất trên r/AI_Agents (2026-03-09) nói thẳng: "Nếu câu lệnh if…then dùng được thì dùng. Rồi nếu workflow truyền thống dùng được thì dùng. Nếu không thì dùng AI agent." Hai trong ba kết quả SERP hàng đầu là tài liệu cloud mà về cấu trúc không thể bảo bạn xây ít hơn. Chúng tôi có thể. Dữ liệu trong bài này chỉ cùng một hướng: hai mức tăng đo được lớn nhất (+80,9% và +90,2%) đều đến từ các tác vụ phân rã sạch, và mức giảm đo được tệ nhất (−70%) đến từ việc ép agent lên một tác vụ không phân rã.

Các chế độ lỗi đã được gọi tên, và mỗi thứ giờ có một con số đi kèm:

• Mất context qua các lần handoff: mọi message từ agent sang agent đều rơi state (lời than phiền "Telephone" trên r/AI_Agents, 2026-04-23).
• Khuếch đại lỗi: 17,2× cho agent độc lập so với 4,4× tập trung (Google Research, 2026-01-28).
• Vòng lặp reflection mất kiểm soát: giới hạn số vòng và dừng khi không cải thiện, như trong code ở trên.
• Thoái hóa tác vụ tuần tự: tệ hơn 39-70% khi bạn song song hóa công việc không phân rã (Google Research, 2026-01-28).
• Vỡ chi phí: token chat xấp xỉ 15× cho một hệ thống multi-agent (Anthropic, 2025-06-13).

Mọi chế độ lỗi trong số đó đều có một giới hạn mà bạn viết được trong mười dòng code, và giới hạn đó luôn rẻ hơn agent mà bạn định thêm vào.

Walden Yan của Cognition đã lập luận tương tự từ phía người xây trong Don't Build Multi-Agents (2025-06-12): "Hãy chia sẻ context, và chia sẻ toàn bộ trace của agent, chứ không chỉ từng message riêng lẻ," và "Hành động mang theo các quyết định ngầm, và các quyết định xung đột mang theo kết quả tệ." So sánh trên r/AI_Agents là thứ chúng tôi quay lại mãi: "multi agent bắt đầu trông rất giống microservices. Mạnh mẽ khi các ranh giới là thật, đau đớn khi chúng được bịa ra."

Cách Techsy tiếp cận việc chọn mô hình

Thang quyết định dưới đây là cách đọc của chúng tôi về các phát hiện của Google Research và Anthropic cộng với các thread của người làm thực tế, không phải một kết quả đo được của riêng chúng tôi. Chúng tôi chạy nó từ trên xuống dưới và dừng ở hàng đầu tiên khớp:

Ba điều rút ra từ dữ liệu trong bài này. Bắt đầu tuần tự, vì Anthropic nói vậy và không gì trên SERP bác bỏ điều đó. Chỉ song song hóa những gì phân rã được, vì cùng thay đổi phối hợp đo được +80,9% cũng đo được −70%. Và coi agent thứ hai là phương án cuối, vì hóa đơn token là thật và khuếch đại lỗi đã được đo. Sợi chỉ xuyên suốt là thêm agent là một nước đi mở rộng quy mô, không phải nước đi chất lượng: benchmark chỉ thưởng ở nơi công việc chia được, và các thread thực chiến xác nhận điều đó ở mọi nơi khác. Nếu bạn muốn một ý kiến thứ hai về một kiến trúc trước khi xây nó, Nhận tư vấn miễn phí.

Câu hỏi thường gặp

7 mô hình AI agent là gì?

Bảy mô hình là sequential (chuỗi prompt), routing (handoff), song song hóa (fan-out/fan-in), orchestrator-workers, reflection (evaluator-optimizer), ReAct và plan-and-execute. Chúng lặp lại dưới những cái tên khác nhau trong mọi hệ phân loại của vendor, từ Anthropic đến Google Cloud. Human-in-the-loop được bàn cùng với chúng nhưng là một lớp kiểm soát bọc bất kỳ mô hình nào trong số bảy, không phải mô hình thứ tám.

4 giai đoạn của một AI agent workflow là gì?

Plan, act, observe, reflect. Mô hình lập kế hoạch cho bước tiếp theo, hành động bằng cách gọi công cụ, quan sát kết quả của công cụ đi vào context, rồi phản tư xem mục tiêu đã đạt chưa và lặp lại hoặc dừng. Mọi mô hình trong bài này là một cách đi dây khác nhau cho bốn giai đoạn đó.

Sự khác nhau giữa AI workflow và AI agent là gì?

Workflow đi theo các đường dẫn code định trước; agent để mô hình tự điều khiển luồng điều khiển của nó. Quy tắc của Anthropic: workflow cho khả năng dự đoán trên các tác vụ được định nghĩa rõ, agent cho sự linh hoạt khi cần các quyết định do mô hình dẫn dắt ở quy mô lớn. Hầu hết hệ thống production là các workflow với vài bước agent bên trong.

ReAct và plan-and-execute: tôi nên dùng cái nào?

Dùng ReAct khi bước tiếp theo phụ thuộc vào những gì công cụ vừa rồi trả về và lộ trình có thể đổi giữa chừng. Dùng plan-and-execute khi lộ trình dự đoán được từ đầu và việc tái lập kế hoạch sau mỗi bước sẽ lãng phí token. ReAct đo được +34% trên ALFWorld (Yao et al., 2022); plan-and-execute thắng zero-shot CoT trên mười dataset (Wang et al., 2023).

Tôi có cần một framework như LangGraph để dùng các mô hình này không?

Không. Mọi khối code trong bài này là một lời gọi SDK thuần, và các mô hình có trước những framework gọi tên chúng. Một framework xứng đáng với công sức bỏ ra ở persistence state, retry và tracing, không phải ở bản thân mô hình. Nếu bạn đang chọn, bài so sánh framework của chúng tôi bao quát các đánh đổi.

Làm sao để vòng lặp reflection không chạy mãi mãi?

Hai rào chắn, cả hai trong code: một giới hạn vòng lặp cứng (chúng tôi dùng 4 vòng) và một điểm dừng khi không cải thiện, dừng ngay khoảnh khắc bản viết lại của máy phê bình không chấm cao hơn bản nháp hiện tại. Đừng tin prompt sẽ kết thúc vòng lặp; mô hình không biết gì về chi phí.

Khi nào một agent đơn là đủ?

Khi nó đạt xấp xỉ 85% độ chính xác trên tác vụ. Heuristic đó, lan truyền trên r/AI_Agents (2026-04-23) cùng với nghiên cứu của Google Research, khớp với benchmark: trên ngưỡng đó, thêm agent là thêm chi phí và khuếch đại lỗi mà không thêm độ chính xác. Hãy đo baseline agent đơn trước khi thiết kế bất kỳ thứ gì lớn hơn.

Tôi có thể tìm ví dụ về mô hình workflow AI agent kèm code ở đâu?

Năm khối Python ở trên bao quát sequential, routing, song song hóa, ReAct và reflection, tất cả là lời gọi SDK thuần mà bạn có thể lấy dùng trực tiếp. Với ví dụ theo phong cách vendor, Vercel AI SDK ship TypeScript chạy được cho mỗi mô hình và tài liệu OpenAI Agents SDK bao quát handoff và agents-as-tools. Link tới cả hai nằm trong danh sách Nguồn dưới đây.

Nguồn

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28); bài báo: arXiv 2512.08296
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang et al., Plan-and-Solve Prompting (ACL 2023)
• Claude by Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (cập nhật 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)