Xây dựng AI Agents với nhiều mô hình: Hướng dẫn kiến trúc thực tế

Hầu hết các AI agent đều dựa vào một mô hình duy nhất để xử lý mọi giai đoạn thực thi. Bước lập kế hoạch, gọi công cụ, trích xuất dữ liệu, tóm tắt và khôi phục lỗi đều chạy qua cùng một LLM. Mặc dù cách tiếp cận này khá đơn giản cho các bản mẫu ban đầu, nhưng nó lại gây ra những sự kém hiệu quả đáng kể trong môi trường sản xuất.

Một bước lập kế hoạch đòi hỏi khả năng suy luận sâu không cần dùng chung mô hình với một bước trích xuất JSON cơ bản. Một tác vụ tạo mã nguồn có những yêu cầu khác với một tác vụ phân loại. Việc sử dụng một mô hình suy luận cao cấp như Claude Fable 5 hoặc Claude Opus 4.8 chỉ để định dạng một chuỗi ngày tháng là một sự lãng phí tài nguyên đắt đỏ.

Việc xây dựng AI agent với nhiều mô hình cho phép bạn điều hướng từng bước của quy trình làm việc đến mô hình phù hợp nhất cho tác vụ cụ thể đó. Hướng dẫn này khám phá cách thiết kế, triển khai và quản lý các kiến trúc đa mô hình này.

Nếu bạn đang làm việc ở lớp API thay vì lớp điều phối agent, hãy tham khảo Thiết kế API ưu tiên Agent (Agent-First API Design) và Tại sao các nhóm chuyển từ API mô hình trực tiếp sang API AI hợp nhất cùng với hướng dẫn này. Các agent đa mô hình hoạt động đáng tin cậy nhất khi bề mặt API cơ sở đủ ổn định để có thể thay đổi mô hình mà không cần viết lại mã điều phối.

:::info

Các điểm chính cần lưu ý

1. Kết hợp mô hình với độ phức tạp của tác vụ: Sử dụng các mô hình nhỏ, nhanh cho việc định tuyến, trích xuất và định dạng; dành riêng các mô hình suy luận lớn hơn cho việc lập kế hoạch và phân tích phức tạp.
2. Chuẩn hóa Schema: Triển khai xác thực đầu ra nghiêm ngặt (như Pydantic) tại mỗi bước chuyển giao để ngăn chặn sự sai lệch hợp đồng khi chuyển đổi giữa các nhà cung cấp mô hình khác nhau.
3. Thiết kế cho phương án dự phòng (Fallback): Xây dựng các đường dẫn dự phòng tự động để xử lý giới hạn tốc độ (rate limit), sự cố nhà cung cấp hoặc độ trễ tăng đột biến mà không làm gián đoạn quy trình làm việc của agent.
4. Tập trung hóa Telemetry: Theo dõi độ trễ, số lượng token đầu vào/đầu ra và chi phí cho mỗi bước để liên tục tối ưu hóa logic định tuyến của bạn. :::

---

Kiến trúc Agent đa mô hình

Kiến trúc agent đa mô hình phân bổ các tác vụ cho các mô hình chuyên biệt dựa trên yêu cầu về độ phức tạp, chi phí và độ trễ.

Yêu cầu người dùng
    │
    ▼
┌─────────────┐
│   Router     │  ← Phân loại độ phức tạp tác vụ
│ (mô hình nhanh)│
└──────┬──────┘
       │
   ┌───┴───┐
   ▼       ▼
┌──────┐ ┌──────┐
│Mô hình│ │Mô hình│
│Đơn giản│ │Phức tạp│
└──┬───┘ └──┬───┘
   │        │
   ▼        ▼
┌─────────────┐
│  Aggregator  │  ← Kết hợp kết quả
│ (mô hình nhanh)│
└─────────────┘

Kiến trúc cốt lõi bao gồm năm thành phần chính:

1. Router (Bộ định tuyến): Một mô hình nhanh, chi phí thấp giúp phân loại các tác vụ đến theo độ phức tạp và mục đích.
2. Model Pool (Nhóm mô hình): Tập hợp các mô hình phù hợp với các loại tác vụ khác nhau (như suy luận, trích xuất hoặc tạo mã).
3. Aggregator (Bộ tổng hợp): Một mô hình nhanh giúp kết hợp kết quả từ các bước song song thành một phản hồi cuối cùng.
4. Fallback Policy (Chính sách dự phòng): Các quy tắc quy định mô hình nào sẽ được sử dụng nếu lựa chọn chính bị lỗi, hết thời gian chờ hoặc gặp giới hạn tốc độ.
5. Telemetry Layer (Lớp đo lường): Hệ thống ghi nhật ký ghi lại các lựa chọn mô hình, độ trễ và chi phí token chính xác cho mỗi bước.

Nếu không có chính sách dự phòng và telemetry, một agent đa mô hình có thể trở nên khó gỡ lỗi, với độ trễ và hồ sơ chi phí khó dự đoán.

---

Triển khai với OpenAI SDK

Sử dụng một cổng API hợp nhất cho phép bạn truy cập các mô hình từ các nhà cung cấp khác nhau bằng một SDK và khóa API duy nhất. Điều này đơn giản hóa việc thay đổi và định tuyến mô hình.

Ví dụ sau đây minh họa một cách triển khai định tuyến cơ bản. Tính khả dụng và giá cả của mô hình nên được xác minh trên danh mục mô hình TokenLab.

from openai import OpenAI

client = OpenAI(
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Nhóm mô hình với các cấp độ chi phí và khả năng
MODELS = {
    "router": "deepseek-v4-flash",        # Phân loại nhanh
    "simple": "deepseek-v4-flash",        # Trích xuất, định dạng
    "reasoning": "claude-sonnet-5",       # Lập kế hoạch, phân tích
    "complex": "gpt-5.5",                 # Tạo mã, logic phức tạp
    "budget": "deepseek-v4-flash",        # Xử lý hàng loạt
}

def route_task(task: str) -> str:
    """Sử dụng mô hình chi phí thấp để phân loại độ phức tạp tác vụ."""
    response = client.chat.completions.create(
        model=MODELS["router"],
        messages=[
            {"role": "system", "content": """Phân loại tác vụ này vào đúng một danh mục:
- simple: trích xuất dữ liệu, định dạng, dịch thuật
- reasoning: phân tích, lập kế hoạch, so sánh
- complex: tạo mã, giải quyết vấn đề nhiều bước
- budget: xử lý hàng loạt, các tác vụ không quan trọng
Chỉ trả lời bằng tên danh mục viết thường."""},
            {"role": "user", "content": task}
        ],
        max_tokens=10
    )
    category = response.choices[0].message.content.strip().lower()
    return MODELS.get(category, MODELS["simple"])

def execute_task(task: str, context: str = "") -> str:
    """Định tuyến tác vụ đến mô hình đã chọn và thực thi."""
    model = route_task(task)
    messages = []
    if context:
        messages.append({"role": "system", "content": context})
    messages.append({"role": "user", "content": task})

    response = client.chat.completions.create(
        model=model,
        messages=messages
    )
    return response.choices[0].message.content

---

Agent thực tế: Quy trình đánh giá mã nguồn (Code Review)

Để thấy tác động thực tế của việc xây dựng AI agent với nhiều mô hình, hãy xem xét một quy trình được thiết kế để đánh giá các yêu cầu kéo (pull request). Quy trình này chia nhỏ việc đánh giá thành các bước chuyên biệt thay vì gửi toàn bộ mã diff đến một mô hình đắt tiền duy nhất.

def review_pr(diff: str) -> dict:
    """Quy trình đánh giá PR đa mô hình."""

    # Bước 1: Phân loại các thay đổi bằng mô hình nhanh, chi phí thấp
    classification = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Phân loại các thay đổi mã nguồn này: {diff[:2000]}\n"
                       "Các danh mục: bugfix, feature, refactor, docs, test"
        }],
        max_tokens=20
    ).choices[0].message.content

    # Bước 2: Thực hiện quét bảo mật bằng mô hình suy luận mạnh mẽ
    security = client.chat.completions.create(
        model="claude-sonnet-5",
        messages=[{
            "role": "system",
            "content": "Bạn là chuyên gia đánh giá bảo mật. Kiểm tra: "
                       "SQL injection, XSS, vượt qua xác thực, bí mật trong mã, "
                       "giải mã không an toàn. Hãy cụ thể về số dòng."
        }, {
            "role": "user",
            "content": f"Đánh giá diff này về các vấn đề bảo mật:\n{diff}"
        }]
    ).choices[0].message.content

    # Bước 3: Phân tích chất lượng mã bằng mô hình đa năng
    quality = client.chat.completions.create(
        model="gpt-5.5",
        messages=[{
            "role": "user",
            "content": f"Đánh giá chất lượng mã: đặt tên, cấu trúc, "
                       f"xử lý lỗi, độ bao phủ kiểm thử.\n{diff}"
        }]
    ).choices[0].message.content

    # Bước 4: Tạo tóm tắt bằng mô hình nhanh, chi phí thấp
    summary = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Tóm tắt đánh giá PR này trong 3 gạch đầu dòng:\n"
                       f"Loại: {classification}\n"
                       f"Bảo mật: {security[:500]}\n"
                       f"Chất lượng: {quality[:500]}"
        }]
    ).choices[0].message.content

    return {
        "classification": classification,
        "security": security,
        "quality": quality,
        "summary": summary
    }

Tối ưu hóa chi phí và hiệu quả

Bảng dưới đây phác thảo việc phân bổ mô hình cho quy trình này. Giá chính xác thay đổi tùy theo nhà cung cấp và khối lượng; hãy xác minh giá hiện tại trên danh mục mô hình TokenLab.

Bước	Mô hình	Input Tokens	Vai trò / Chuyên môn
1. Phân loại	DeepSeek V4 Flash	~2,100	Phân loại nhanh, định tuyến chi phí thấp
2. Bảo mật	Claude Sonnet 5	~2,500	Suy luận sâu, phân tích bảo mật
3. Chất lượng	GPT-5.5	~2,500	Đánh giá cấu trúc và chất lượng mã nâng cao
4. Tóm tắt	DeepSeek V4 Flash	~1,200	Tổng hợp văn bản nhanh, chi phí thấp

Việc chạy cả bốn bước qua một mô hình suy luận hàng đầu như Claude Sonnet 5 hoặc GPT-5.5 sẽ làm tăng chi phí đáng kể. Bằng cách định tuyến các tác vụ đơn giản hơn đến các mô hình chi phí thấp hơn như DeepSeek V4 Flash, quy trình đa mô hình giúp giảm tổng chi tiêu token trong khi vẫn giữ được khả năng suy luận sâu cho bước phân tích bảo mật quan trọng.

---

Định tuyến theo khả năng, không chỉ theo giá

Mặc dù giảm chi phí là mục tiêu phổ biến, các quyết định định tuyến cũng nên tính đến các khả năng cụ thể của mô hình. Một chính sách định tuyến mạnh mẽ đánh giá các mô hình dựa trên bốn khía cạnh chính:

• Độ sâu suy luận: Logic phức tạp, lập kế hoạch và suy luận nhiều bước.
• Cửa sổ ngữ cảnh (Context Window): Khối lượng thông tin nền hoặc mã cần thiết cho tác vụ.
• Độ tin cậy khi sử dụng công cụ: Độ chính xác của việc gọi hàm và tạo đầu ra có cấu trúc.
• Độ nhạy về độ trễ: Các yêu cầu về tốc độ của ứng dụng hướng người dùng.

Những khía cạnh này giúp thiết lập các quy tắc định tuyến rõ ràng:

• Các tác vụ phân rã và lập kế hoạch được định tuyến đến các mô hình nặng về suy luận.
• Các tác vụ trích xuất và định dạng dữ liệu được định tuyến đến các mô hình nhanh, chi phí thấp.
• Các tác vụ tạo mã và phân tích cú pháp được định tuyến đến các mô hình được tối ưu hóa cho tác vụ lập trình.
• Các tác vụ phân tích toàn bộ kho lưu trữ được định tuyến đến các mô hình có cửa sổ ngữ cảnh lớn.

Để căn chỉnh bộ định tuyến của bạn với các yêu cầu này, hãy tham khảo so sánh mô hình lập trình và so sánh giá để khớp các bước quy trình làm việc của bạn với các tiêu chuẩn mô hình hiện tại.

---

Tích hợp LangChain

Bạn cũng có thể triển khai định tuyến đa mô hình trong các khung điều phối như LangChain. Ví dụ sau cấu hình các mô hình khác nhau bằng cách sử dụng URL cơ sở API hợp nhất:

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

# Khởi tạo các mô hình với cấu hình riêng biệt
fast_model = ChatOpenAI(
    model="deepseek-v4-flash",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

reasoning_model = ChatOpenAI(
    model="claude-sonnet-5",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Xác định các chuỗi chuyên biệt
classify_chain = ChatPromptTemplate.from_template(
    "Phân loại mục đích của yêu cầu này: {input}"
) | fast_model

analyze_chain = ChatPromptTemplate.from_template(
    "Thực hiện phân tích chi tiết về vấn đề này: {input}"
) | reasoning_model

---

Khi nào nên sử dụng AI Agent đa mô hình

Việc giới thiệu nhiều mô hình làm tăng độ phức tạp về kiến trúc. Cách tiếp cận này thường mang lại lợi ích nhất khi:

• Yêu cầu tác vụ đa dạng: Agent xử lý hỗn hợp các tác vụ đơn giản (như phân loại hoặc định dạng) và các tác vụ phức tạp (như lập kế hoạch chiến lược hoặc tạo mã).
• Khối lượng và chi phí cao: Chi tiêu API hàng tháng đủ cao để việc tối ưu hóa mang lại khoản tiết kiệm đáng kể.
• Thế mạnh mô hình chuyên biệt: Quy trình làm việc được hưởng lợi từ thế mạnh cụ thể của nhà cung cấp, chẳng hạn như cửa sổ ngữ cảnh của Gemini, khả năng lập trình của Claude hoặc tốc độ sử dụng công cụ của GPT.
• Nhu cầu độ trễ bất đối xứng: Một số phần của quy trình phải trả về kết quả ngay lập tức, trong khi các bước nền khác có thể mất nhiều thời gian hơn.

Đối với các agent đơn mục đích hoặc giao diện trò chuyện đơn giản, một mô hình duy nhất thường dễ bảo trì hơn. Chi phí vận hành của việc định tuyến có thể không được biện minh nếu mọi yêu cầu đều đòi hỏi cùng một mức độ khả năng.

---

Các chế độ lỗi phổ biến

Kiến trúc đa mô hình giới thiệu các chế độ lỗi cụ thể cần được giảm thiểu:

1. Bộ định tuyến quá phức tạp

Nếu prompt của bộ định tuyến trở nên quá phức tạp, bản thân bước phân loại có thể trở nên chậm và đắt đỏ. Hãy giữ các prompt định tuyến ngắn gọn và các danh mục phân loại ở mức rộng.

2. Sai lệch hợp đồng đầu ra (Output Contract Drift)

Các mô hình khác nhau có thể định dạng đầu ra khác nhau, ngay cả khi được hướng dẫn trả về JSON. Một mô hình có thể trả về JSON thô, trong khi mô hình khác lại bao bọc nó trong các khối markdown. Để ngăn chặn lỗi phân tích cú pháp ở hạ nguồn, hãy thực thi các schema nghiêm ngặt bằng cách sử dụng các thư viện xác thực như Pydantic tại mỗi bước chuyển giao.

3. Suy giảm chất lượng âm thầm

Nếu chính sách dự phòng định tuyến một yêu cầu đến mô hình cấp thấp hơn trong thời gian nhà cung cấp chính gặp sự cố, agent có thể trả về các câu trả lời chất lượng thấp hơn mà không đưa ra lỗi. Việc triển khai chiến lược giới hạn tốc độ và hệ thống cảnh báo rõ ràng giúp theo dõi khi nào các phương án dự phòng đang hoạt động.

4. Telemetry bị phân mảnh

Khi việc sử dụng mô hình bị chia nhỏ qua nhiều API nhà cung cấp trực tiếp, việc tổng hợp các số liệu chi phí và hiệu suất trở nên khó khăn. Tập trung hóa các yêu cầu thông qua một cổng duy nhất giúp đơn giản hóa việc ghi nhật ký và theo dõi chi phí.

---

Vòng lặp đánh giá tối thiểu

Để duy trì một agent đa mô hình, hãy thiết lập một vòng lặp đánh giá cơ bản để theo dõi hiệu suất. Bạn có thể ghi lại các số liệu sau cho mỗi lần chạy vào bảng cơ sở dữ liệu:

• Danh mục tác vụ: Phân loại được gán bởi bộ định tuyến.
• Mô hình được chọn: Mô hình được chọn cho mỗi bước.
• Độ trễ bước: Thời gian hoàn thành mỗi bước.
• Sử dụng Token: Số lượng token đầu vào và đầu ra chính xác.
• Trạng thái dự phòng: Liệu mô hình dự phòng có được kích hoạt hay không.
• Phản hồi của người dùng: Chỉ báo nhị phân về việc đầu ra cuối cùng có thành công hay không.

Việc phân tích dữ liệu này giúp xác định xem bộ định tuyến có đang chọn đúng mô hình hay không, bước nào đang chiếm phần lớn chi phí của bạn và liệu các mô hình dự phòng có đang duy trì chất lượng chấp nhận được hay không.

---

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

Làm thế nào để xử lý các định dạng prompt khác nhau giữa các mô hình?

Các mô hình khác nhau phản hồi tốt nhất với các cấu trúc prompt khác nhau. Ví dụ, một số mô hình hoạt động tốt hơn với system prompt, trong khi những mô hình khác thích các hướng dẫn được nhúng trong user prompt. Để xử lý việc này, hãy trừu tượng hóa các prompt của bạn thành các mẫu (templates) thích ứng dựa trên mô hình mục tiêu, thay vì gửi các chuỗi thô giống hệt nhau đến mọi mô hình trong nhóm của bạn.

Việc định tuyến có làm tăng quá nhiều độ trễ cho các ứng dụng hướng người dùng không?

Việc định tuyến có gây ra một lượng độ trễ nhỏ cho bước phân loại. Bạn có thể giảm thiểu điều này bằng cách sử dụng các mô hình có độ trễ thấp, được tối ưu hóa cao cho bộ định tuyến, giữ giới hạn token tối đa ở mức thấp (dưới 10 token) hoặc song song hóa các bước khi việc phân loại có thể được suy ra từ trạng thái ứng dụng hoặc điểm truy cập của người dùng.

Làm thế nào để ngăn chặn lỗi phân tích cú pháp JSON khi chuyển đổi giữa các mô hình?

Để ngăn chặn lỗi phân tích cú pháp, hãy sử dụng các tính năng đầu ra có cấu trúc (như chế độ JSON hoặc gọi công cụ) được hỗ trợ bởi các nhà cung cấp mô hình. Ngoài ra, hãy bao bọc tất cả đầu ra của mô hình trong một lớp xác thực sử dụng Pydantic hoặc các thư viện tương tự để phân tích, xác thực và sửa chữa payload trước khi chuyển nó đến bước tiếp theo trong quy trình của bạn.

---

Truy cập mọi mô hình thông qua một API: Bắt đầu với TokenLab để truy cập hơn 300 mô hình với một khóa API duy nhất. Xây dựng các agent đa mô hình mà không cần quản lý nhiều tài khoản nhà cung cấp hoặc viết lại logic định tuyến cho các API khác nhau.