Tạo các tác nhân CrewAI đa mô hình với CometAPI:

Việc xây dựng hệ thống multi-agent với CrewAI trở nên thú vị hơn khi các agent có thể dùng các model khác nhau.

Một researcher có thể hưởng lợi từ model nhanh và tiết kiệm, một analyst có thể cần model suy luận mạnh, và một writer có thể cần model tối ưu cho sinh nội dung dài chất lượng cao. Truyền thống, kết nối các agent này tới những nhà cung cấp khác nhau đồng nghĩa với việc phải quản lý riêng biệt thông tin xác thực API, endpoint, SDK, hệ thống thanh toán, và cấu hình đặc thù từng nhà cung cấp.

Kiến trúc sạch hơn là để CrewAI quản lý agent và workflow trong khi CometAPI quản lý truy cập model.

CometAPI cung cấp một endpoint tương thích OpenAI tại https://api.cometapi.com/v1, vì thế ứng dụng có thể định tuyến yêu cầu tới các model từ nhiều nhà cung cấp qua một giao diện API chung. Tài liệu quick-start hiện tại của nó cũng hỗ trợ dùng OpenAI Python SDK tiêu chuẩn bằng cách thay đổi API key và base URL.

Trong hướng dẫn này, bạn sẽ xây dựng một workflow CrewAI gồm ba agent với:

• Gemini 3.7 Flash cho nghiên cứu
• Claude Opus 5 cho phân tích
• GPT-5.6 cho viết cuối cùng
• Một API key CometAPI
• Một API base URL
• Cấu hình model theo từng agent
• Fallback có giới hạn cho lỗi tạm thời
• Checkpointing của CrewAI để khôi phục production
• Theo dõi mức sử dụng token và thực thi
• Xác thực model phía server

Ranh giới kiến trúc quan trọng rất đơn giản:

CrewAI xử lý điều phối agent. CometAPI xử lý truy cập model. Model ID quyết định định tuyến.

---

CrewAI Multi-Agent Model Routing là gì?

CrewAI là framework Python để tạo agent, task, crew, và workflow multi-agent. Mỗi agent có thể có cấu hình LLM riêng, trong khi Crew điều phối cách các agent thực thi task và trao đổi ngữ cảnh.

Cấu hình LLM hiện tại của CrewAI hỗ trợ đặt rõ model, api_key, và base_url, bao gồm cả các endpoint tương thích OpenAI tùy chỉnh.

Điều đó giúp kiến trúc multi-model trở nên đơn giản:

                         CometAPI                            │              https://api.cometapi.com/v1                            │        ┌───────────────────┼───────────────────┐        │                   │                   │   Researcher            Analyst             Writer        │                   │                   │ Gemini 3.7 Flash      Claude Opus 5         GPT-5.6

Các agent vẫn tách biệt ở mức logic, nhưng quyền truy cập model được tập trung.

Điều này khác với việc nói rằng tất cả model có thể thay thế cho nhau. Một API tương thích OpenAI cung cấp giao diện yêu cầu chung; nó không đảm bảo giới hạn ngữ cảnh, hỗ trợ công cụ, điều khiển suy luận, hành vi đầu ra, độ trễ hay giá cả giống hệt nhau.

Sự khác biệt đó quan trọng khi thiết kế định tuyến production.

---

Tại sao dùng CometAPI với CrewAI?

Ưu điểm chính không phải là CrewAI bỗng nhiên trở thành framework đa nhà cung cấp. CrewAI vốn đã hỗ trợ nhiều nhà cung cấp LLM.

Ưu điểm là truy cập model có thể được hợp nhất sau một lớp API.

Nếu không có lớp API hợp nhất, một workflow ba agent có thể trông như sau:

Với CometAPI:

Tài liệu quick-start hiện tại của CometAPI mô tả endpoint của nó như một sự thay thế thả-vào (drop-in) cho OpenAI API base URL và liệt kê các model từ nhiều nhà cung cấp qua cùng một dịch vụ.

Điều này mang lại cho ứng dụng một sự tách biệt hữu ích:

CrewAI

• Định nghĩa vai trò agent
• Định nghĩa task
• Truyền ngữ cảnh
• Điều khiển thực thi
• Quản lý vòng lặp agent
• Xử lý điều phối ở cấp crew

CometAPI

• Cung cấp lớp truy cập model chung
• Tập trung xác thực API
• Cung cấp định tuyến model qua model ID
• Cho ứng dụng một API endpoint duy nhất
• Cung cấp khả năng quan sát mức sử dụng và thanh toán tập trung

---

Workflow CrewAI này sẽ xây dựng gì?

Ví dụ tạo ba agent tuần tự.

Đây là ví dụ chính sách định tuyến, không phải bảng xếp hạng benchmark.

Model phù hợp cho agent của bạn phụ thuộc vào:

• độ phức tạp nhiệm vụ
• độ dài ngữ cảnh cần thiết
• việc dùng tool
• yêu cầu đầu ra có cấu trúc
• độ trễ
• độ tin cậy
• chi phí token
• chất lượng đầu ra
• kết quả đánh giá theo ứng dụng

Một quy tắc hữu ích là:

Chọn model cho công việc agent thực hiện, không chỉ vì nhà cung cấp của nó.

---

Mỗi CrewAI agent nên dùng model nào?

Trong ví dụ này, phân công model theo chiến lược đơn giản giữa chi phí và năng lực.

Researcher: Gemini 3.7 Flash

Nghiên cứu thường liên quan xử lý lượng thông tin tương đối lớn và tạo ra kết quả trung gian gọn.

Một model nhanh do đó hữu ích cho các tác vụ nghiên cứu khối lượng lớn.

"researcher": "gemini-3.7-flash"

Analyst: Claude Opus 5

Analyst có vai trò hẹp hơn nhưng nặng về suy luận. Nó nhận đầu ra nghiên cứu và chuyển thành khuyến nghị.

"analyst": "claude-opus-5"

Writer: GPT-5.6

Agent cuối cùng chuyển nghiên cứu và phân tích thành một decision memo hướng tới developer.

"writer": "gpt-5.6"

Điều quan trọng không phải là đúng ba phân công này. Ứng dụng của bạn nên đánh giá các model ứng viên trên các tác vụ đại diện trước khi cố định chính sách định tuyến.

---

Cần gì trước khi bắt đầu?

Bạn cần:

• Python 3.10+
• CrewAI
• Tương thích OpenAI Python SDK
• python-dotenv
• Một API key CometAPI
• Các model ID dự định dùng

Tích hợp Python hiện tại của CometAPI hỗ trợ API tương thích OpenAI, và gói CometAPI Python chính thức tài liệu hóa COMETAPI_KEY và COMETAPI_BASE_URL như các tùy chọn cấu hình dựa trên biến môi trường.

Endpoint tiêu chuẩn là:

https://api.cometapi.com/v1

Trước khi triển khai, hãy xác minh rằng các model ID bạn chọn hiện có sẵn và hỗ trợ endpoint và tham số mà workload CrewAI của bạn yêu cầu. Danh mục model và giá có thể thay đổi.

---

Cài đặt CrewAI và dependencies như thế nào?

Tạo môi trường Python mới:

python -m venv .venv

Kích hoạt:

source .venv/bin/activate

Trên Windows:

.venv\Scripts\Activate.ps1

Sau đó cài dependencies:

pip install "crewai[openai]" openai python-dotenv

Việc nêu rõ openai là có chủ đích vì phần fallback bên dưới import trực tiếp các lớp ngoại lệ của OpenAI SDK.

Trong production, hãy ghim các phiên bản bạn đã kiểm thử thay vì dựa mãi vào bản latest trôi nổi.

Ví dụ:

crewai==YOUR_TESTED_VERSIONopenai==YOUR_TESTED_VERSIONpython-dotenv==YOUR_TESTED_VERSION

Lớp LLM của CrewAI đang phát triển tích cực, vì thế hàm khởi tạo và cấu hình provider chính xác nên được kiểm tra theo phiên bản CrewAI mà ứng dụng của bạn dùng. Tài liệu CrewAI hiện tại hỗ trợ cấu hình một LLM với base_url tùy chỉnh và API key.

---

Cấu hình CometAPI API key như thế nào?

Tạo file .env:

COMETAPI_KEY=your_cometapi_keyCOMETAPI_BASE_URL=https://api.cometapi.com/v1

Nạp các giá trị này trong Python:

import osfrom dotenv import load_dotenvload_dotenv()COMETAPI_KEY = os.environ["COMETAPI_KEY"]COMETAPI_BASE_URL = os.getenv(    "COMETAPI_BASE_URL",    "https://api.cometapi.com/v1",)

Không bao giờ commit .env lên Git.

Thêm vào .gitignore:

.env.venv/__pycache__/

API key nên ở phía server. Hướng dẫn quick-start hiện tại của CometAPI cũng khuyến nghị lưu key trong biến môi trường thay vì mã nguồn.

---

Kết nối CrewAI với CometAPI như thế nào?

Đối tượng LLM của CrewAI có thể nhận tên model, API key và base URL tùy chỉnh.

Tạo helper:

from crewai import LLMdef cometapi_llm(model_id: str) -> LLM:    return LLM(        model=model_id,        base_url=COMETAPI_BASE_URL,        api_key=COMETAPI_KEY,        timeout=60.0,        max_retries=0,    )

Điều này tốt hơn so với nhúng cùng một cấu hình lặp lại trong mọi agent.

Mỗi agent giờ chỉ cần một model ID:

research_llm = cometapi_llm("gemini-3.7-flash")analysis_llm = cometapi_llm("claude-opus-5")writing_llm = cometapi_llm("gpt-5.6")

Tại sao đặt max_retries=0?

Lý do là để kiểm soát fallback.

Nếu client LLM bên dưới tự động retry và ứng dụng của bạn cũng triển khai fallback, một lỗi có thể trở thành nhiều yêu cầu ẩn trước khi logic fallback thực thi.

Trong hướng dẫn với định tuyến tường minh, để ứng dụng quyết định khi nào retry hoặc chuyển model sẽ sạch hơn.

---

Định nghĩa chính sách định tuyến model như thế nào?

Giữ định tuyến ở ngoài prompt:

PRIMARY_MODELS = {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6",}FALLBACK_MODELS = {    "researcher": "gpt-5.6",    "analyst": "gpt-5.6",    "writer": "gemini-3.7-flash",}

Điều này tạo ranh giới cấu hình rõ ràng.

Bạn có thể chuyển cùng ánh xạ này vào:

• cấu hình môi trường
• YAML
• JSON
• cơ sở dữ liệu
• feature flag
• dịch vụ định tuyến model nội bộ

mà không cần viết lại prompt của agent.

---

Xây dựng ba CrewAI agent như thế nào?

Tạo một đối tượng LLM cho mỗi agent.

from crewai import Agentdef build_agents(model_map: dict[str, str]):    researcher = Agent(        role="Market Researcher",        goal="Collect the facts needed to answer the topic",        backstory=(            "You create concise, source-aware research briefs "            "and clearly separate facts from assumptions."        ),        llm=cometapi_llm(model_map["researcher"]),        max_iter=3,        allow_delegation=False,    )    analyst = Agent(        role="Product Analyst",        goal="Turn research into a defensible recommendation",        backstory=(            "You identify evidence, assumptions, risks, "            "and trade-offs before making recommendations."        ),        llm=cometapi_llm(model_map["analyst"]),        max_iter=3,        allow_delegation=False,    )    writer = Agent(        role="Technical Writer",        goal="Produce a concise technical decision memo",        backstory=(            "You write clear technical explanations "            "without unnecessary marketing language."        ),        llm=cometapi_llm(model_map["writer"]),        max_iter=3,        allow_delegation=False,    )    return researcher, analyst, writer

Việc gán model giờ hoàn toàn độc lập với định nghĩa vai trò agent.

Đó là điều khiến định tuyến model trở nên thực tiễn.

---

Kết nối các agent với task tuần tự như thế nào?

Tạo ba task:

from crewai import Taskdef build_tasks(researcher, analyst, writer):    research_task = Task(        description=(            "Research this topic: {topic}. "            "Return the key facts, uncertainties, "            "and relevant sources that the analyst should consider."        ),        expected_output=(            "A compact research brief containing facts, "            "uncertainties, and source references."        ),        agent=researcher,    )    analysis_task = Task(        description=(            "Using the research brief, analyze {topic}. "            "Identify the strongest conclusion and explain "            "the major trade-offs."        ),        expected_output=(            "A decision outline with evidence, "            "assumptions, risks, and trade-offs."        ),        agent=analyst,        context=[research_task],    )    writing_task = Task(        description=(            "Write a concise technical decision memo about {topic}. "            "State the recommendation early and preserve "            "important caveats."        ),        expected_output="A polished technical decision memo in Markdown.",        agent=writer,        context=[research_task, analysis_task],    )    return research_task, analysis_task, writing_task

Chuỗi phụ thuộc:

Chủ đề  ↓Nghiên cứu  ↓Phân tích  ↓Bản memo cuối

Analyst nhận đầu ra của task nghiên cứu, trong khi writer nhận cả ngữ cảnh của nghiên cứu và phân tích.

---

Xây dựng Crew như thế nào?

Kết hợp agent và task:

from crewai import Crew, Processdef build_crew(model_map: dict[str, str]) -> Crew:    researcher, analyst, writer = build_agents(model_map)    research_task, analysis_task, writing_task = build_tasks(        researcher,        analyst,        writer,    )    return Crew(        agents=[researcher, analyst, writer],        tasks=[            research_task,            analysis_task,            writing_task,        ],        process=Process.sequential,        verbose=True,    )

Giờ việc định tuyến model hoàn toàn được điều khiển bởi cấu hình.

Thay đổi:

"researcher": "gemini-3.7-flash"

sang model được hỗ trợ khác không yêu cầu thay đổi prompt nghiên cứu hay định nghĩa task.

---

Fallback model của CrewAI nên hoạt động ra sao?

Đây là nơi triển khai hướng production cần cẩn trọng hơn.

Sai lầm thường gặp là:

Bất kỳ lỗi nào   ↓Chuyển model

Điều đó quá mạnh tay.

Ví dụ, các lỗi này thường không nên kích hoạt fallback model:

400 Bad Request401 Unauthorized403 Forbidden404 Not Found422 Validation Error

Chuyển model sẽ không sửa API key không hợp lệ hoặc yêu cầu sai định dạng.

Fallback phù hợp hơn cho các lỗi tạm thời như:

408 Request Timeout429 Rate Limit500 Internal Server Error502 Bad Gateway503 Service Unavailable504 Gateway TimeoutConnection errorTimeout

Vì vậy, chính sách fallback nên là:

Chỉ retry hoặc chuyển model cho lỗi tạm thời có giới hạn và chỉ khi model fallback hỗ trợ cùng hợp đồng yêu cầu.

---

Phát hiện lỗi có thể retry như thế nào?

Bạn có thể dùng các lớp lỗi của OpenAI SDK:

from collections.abc import Iteratorfrom openai import (    APIConnectionError,    APIStatusError,    APITimeoutError,)def exception_chain(error: BaseException) -> Iterator[BaseException]:    current: BaseException | None = error    seen: set[int] = set()    while current is not None and id(current) not in seen:        seen.add(id(current))        yield current        current = (            current.__cause__            or current.__context__        )def should_fallback(error: BaseException) -> bool:    for current in exception_chain(error):        if isinstance(            current,            (APIConnectionError, APITimeoutError),        ):            return True        if isinstance(current, APIStatusError):            return (                current.status_code in {408, 429}                or current.status_code >= 500            )    return False

Điều này cố ý loại trừ các lỗi 400-level về cấu hình ngoại trừ 408 và 429.

---

Bạn nên retry toàn bộ Crew hay chỉ agent bị lỗi?

Có hai chiến lược fallback khác nhau.

Fallback cấp crew

Triển khai đơn giản nhất là:

Bắt đầu crew   ↓thất bại   ↓đổi định tuyến   ↓chạy lại crew

Dễ hiểu, nhưng có thể lặp lại các task đã hoàn thành.

Ví dụ:

Research → hoàn thànhAnalysis → hoàn thànhWriter → thất bại

Một lần retry kickoff() đầy đủ có thể thực thi:

Research → lạiAnalysis → lạiWriter → fallback

Điều đó làm tăng:

• mức dùng token
• độ trễ
• chi phí API
• tác dụng phụ tiềm ẩn

Phục hồi cấp task

Workflow production nên checkpoint công việc đã hoàn thành:

Research   ↓checkpoint   ↓Analysis   ↓checkpoint   ↓Writer thất bại   ↓retry writer với fallback

CrewAI hiện cung cấp checkpointing để lưu trạng thái thực thi và cho phép tiếp tục sau lỗi. Hành vi checkpoint được tài liệu hóa là bỏ qua các task đã hoàn thành và tiếp tục công việc hạ lưu từ trạng thái đã lưu.

Đây là kiến trúc tốt hơn cho workflow tốn kém hoặc có tác dụng phụ.

---

Thêm CrewAI checkpointing như thế nào?

Với workflow production, bật checkpointing trên crew:

crew = Crew(    agents=[researcher, analyst, writer],    tasks=[        research_task,        analysis_task,        writing_task,    ],    process=Process.sequential,    checkpoint=True,    verbose=True,)

Hệ thống checkpointing của CrewAI có thể lưu trạng thái thực thi sau khi hoàn thành task và khôi phục crew từ checkpoint.

Ví dụ, một lượt khôi phục có thể dùng:

from crewai import CheckpointConfigresult = crew.kickoff(    from_checkpoint=CheckpointConfig(        restore_from="./.checkpoints/checkpoint.json",    ))

Cấu hình checkpoint chính xác nên theo phiên bản CrewAI mà dự án của bạn dùng.

Điểm kiến trúc quan trọng là:

Checkpoint trước, fallback sau.

Điều này ngăn lỗi model tạm thời buộc phải chạy lại công việc đã hoàn thành tốn kém.

---

Triển khai fallback đơn giản có giới hạn như thế nào?

Cho mục đích hướng dẫn, bạn vẫn có thể minh họa fallback cấp crew đơn giản.

def run_with_fallback(topic: str):    routes = [        PRIMARY_MODELS,        {            **PRIMARY_MODELS,            "writer": FALLBACK_MODELS["writer"],        },        {            **PRIMARY_MODELS,            "analyst": FALLBACK_MODELS["analyst"],            "writer": FALLBACK_MODELS["writer"],        },    ]    last_error = None    for attempt, model_map in enumerate(routes, start=1):        try:            crew = build_crew(model_map)            result = crew.kickoff(                inputs={"topic": topic}            )            return result, model_map        except Exception as error:            last_error = error            if not should_fallback(error):                raise            if attempt == len(routes):                raise            print(                f"Transient failure on attempt {attempt}. "                f"Trying bounded fallback route.",                flush=True,            )    raise RuntimeError(        "Crew execution failed after all fallback routes."    ) from last_error

Lưu ý sự khác biệt quan trọng:

Điều này không khẳng định rằng agent bị lỗi đã được xác định.

Đây là chiến lược fallback cấp crew có giới hạn.

Với workflow nhỏ không trạng thái, điều này có thể chấp nhận được. Với workflow production có nghiên cứu tốn kém, tool, hoặc tác dụng phụ, hãy dùng khôi phục dựa trên checkpoint.

---

Theo dõi mức sử dụng token của CrewAI như thế nào?

Theo dõi mức sử dụng nên là một phần của lớp định tuyến, không phải suy nghĩ sau cùng.

Kết thúc lượt chạy, kiểm tra kết quả CrewAI:

result, selected_models = run_with_fallback(topic)print("Selected models:")print(selected_models)print("Final result:")print(result.raw)print("Usage:")print(result.token_usage)

Các trường usage chính xác có thể phụ thuộc vào phiên bản CrewAI và đường thực thi, vì vậy hãy coi đối tượng kết quả trả về là nguồn chân lý cho phiên bản bạn triển khai.

Một bản ghi usage production lý tưởng nên chứa:

job_idagentmodelinput_tokensoutput_tokenstotal_tokenslatency_msfallback_usedfallback_reasonstatuscreated_at

Điều này cho phép bạn trả lời các câu hỏi như:

Agent nào tiêu tốn nhiều ngân sách nhất?

Analyst fallback thường xuyên đến mức nào?

Model nào có độ trễ cao nhất?

Mỗi workflow tốn bao nhiêu?

---

Kiểm soát chi phí ở cấp agent như thế nào?

Định tuyến multi-model hữu ích nhất khi phản ánh khác biệt workload thực tế.

Ví dụ:

Researcher→ khối lượng cao→ model chi phí thấpAnalyst→ khối lượng thấp→ model suy luận mạnhWriter→ khối lượng trung bình→ model sản xuất đa dụng

Bạn cũng có thể ràng buộc chi phí qua cấu hình agent.

Ví dụ:

max_iter=3

giới hạn vòng lặp lặp lại của agent. Nó không nên được hiểu là giới hạn cứng đúng ba lần gọi API hoặc ba ngân sách token.

Các kiểm soát bổ sung gồm:

• giới hạn ngữ cảnh task
• tóm tắt đầu ra trung gian
• cache nghiên cứu có thể lặp lại
• giới hạn kích thước input tối đa
• giới hạn số token output tối đa nếu được hỗ trợ
• hạn chế gọi tool
• đặt ngân sách theo người dùng
• đặt ngân sách theo workflow
• theo dõi tần suất fallback

---

Xác thực model trước khi triển khai như thế nào?

Đừng hardcode model ID mãi mãi.

Một model có thể:

• không còn khả dụng
• đổi tên
• bị ngừng hỗ trợ
• bị hạn chế
• thay đổi năng lực
• thay đổi giá
• không tương thích với tham số mà ứng dụng của bạn dùng

CometAPI cung cấp endpoint danh mục model có thể truy vấn bằng lập trình, trong khi thư mục model công khai của nó phục vụ khám phá model cho con người.

Một kiểm tra triển khai có thể như:

curl -s \  https://api.cometapi.com/api/models \  -H "Authorization: Bearer $COMETAPI_KEY"

Sau đó xác nhận rằng các model ID bạn cấu hình tồn tại trước khi triển khai.

Ví dụ, quy trình CI của bạn có thể xác minh:

gemini-3.7-flash → availableclaude-opus-5    → availablegpt-5.6          → available

Đừng xem kiểm tra khả dụng là thay thế cho kiểm thử ứng dụng. Một model có trong danh mục không có nghĩa là mọi tham số, tool, hay định dạng đầu ra mà agent CrewAI của bạn dùng đều được hỗ trợ.

---

Ví dụ CrewAI đầy đủ trông như thế nào?

Dưới đây là triển khai tổng hợp:

import jsonimport osimport sysfrom collections.abc import Iteratorfrom dotenv import load_dotenvfrom openai import (    APIConnectionError,    APIStatusError,    APITimeoutError,)from crewai import Agent, Crew, LLM, Process, Taskload_dotenv()COMETAPI_KEY = os.environ["COMETAPI_KEY"]COMETAPI_BASE_URL = os.getenv(    "COMETAPI_BASE_URL",    "https://api.cometapi.com/v1",)PRIMARY_MODELS = {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6",}FALLBACK_MODELS = {    "researcher": "gpt-5.6",    "analyst": "gpt-5.6",    "writer": "gemini-3.7-flash",}def cometapi_llm(model_id: str) -> LLM:    return LLM(        model=model_id,        base_url=COMETAPI_BASE_URL,        api_key=COMETAPI_KEY,        timeout=60.0,        max_retries=0,    )def build_crew(model_map: dict[str, str]) -> Crew:    researcher = Agent(        role="Market Researcher",        goal="Collect the facts needed to answer the topic",        backstory=(            "You create concise, source-aware research briefs "            "and distinguish facts from assumptions."        ),        llm=cometapi_llm(model_map["researcher"]),        max_iter=3,        allow_delegation=False,    )    analyst = Agent(        role="Product Analyst",        goal="Turn research into a defensible recommendation",        backstory=(            "You evaluate evidence, assumptions, risks, "            "and trade-offs."        ),        llm=cometapi_llm(model_map["analyst"]),        max_iter=3,        allow_delegation=False,    )    writer = Agent(        role="Technical Writer",        goal="Produce a concise technical decision memo",        backstory=(            "You write clear technical explanations "            "without unnecessary hype."        ),        llm=cometapi_llm(model_map["writer"]),        max_iter=3,        allow_delegation=False,    )    research_task = Task(        description=(            "Research this topic: {topic}. "            "Return the key facts, uncertainties, "            "and relevant sources."        ),        expected_output=(            "A concise research brief with facts "            "and open questions."        ),        agent=researcher,    )    analysis_task = Task(        description=(            "Using the research brief, analyze {topic}. "            "Identify the strongest conclusion and "            "explain the major trade-offs."        ),        expected_output=(            "A decision outline with evidence, "            "assumptions, risks, and trade-offs."        ),        agent=analyst,        context=[research_task],    )    writing_task = Task(        description=(            "Write a concise technical decision memo "            "about {topic}. State the recommendation early "            "and preserve important caveats."        ),        expected_output=(            "A polished technical decision memo in Markdown."        ),        agent=writer,        context=[            research_task,            analysis_task,        ],    )    return Crew(        agents=[            researcher,            analyst,            writer,        ],        tasks=[            research_task,            analysis_task,            writing_task,        ],        process=Process.sequential,        verbose=True,    )def exception_chain(    error: BaseException,) -> Iterator[BaseException]:    current = error    seen: set[int] = set()    while current is not None and id(current) not in seen:        seen.add(id(current))        yield current        current = (            current.__cause__            or current.__context__        )def should_fallback(error: BaseException) -> bool:    for current in exception_chain(error):        if isinstance(            current,            (                APIConnectionError,                APITimeoutError,            ),        ):            return True        if isinstance(current, APIStatusError):            return (                current.status_code in {408, 429}                or current.status_code >= 500            )    return Falsedef run_with_fallback(topic: str):    routes = [        PRIMARY_MODELS,        {            **PRIMARY_MODELS,            "writer": FALLBACK_MODELS["writer"],        },        {            **PRIMARY_MODELS,            "analyst": FALLBACK_MODELS["analyst"],            "writer": FALLBACK_MODELS["writer"],        },    ]    last_error = None    for attempt, model_map in enumerate(        routes,        start=1,    ):        try:            crew = build_crew(model_map)            result = crew.kickoff(                inputs={                    "topic": topic,                }            )            return result, model_map        except Exception as error:            last_error = error            if not should_fallback(error):                raise            if attempt == len(routes):                raise            print(                f"Transient failure on attempt "                f"{attempt}; trying fallback.",                file=sys.stderr,            )    raise RuntimeError(        "No model route completed the crew."    ) from last_errordef main():    topic = (        sys.argv[1]        if len(sys.argv) > 1        else (            "Should a small SaaS add "            "AI-generated meeting summaries?"        )    )    result, selected_models = (        run_with_fallback(topic)    )    output = {        "selected_models": selected_models,        "raw": result.raw,        "tasks_output": [            task.raw            for task in result.tasks_output        ],        "token_usage": str(            result.token_usage        ),    }    print(        json.dumps(            output,            indent=2,            default=str,        )    )if __name__ == "__main__":    main()

Cải tiến quan trọng so với phiên bản gốc là mã không còn ngụ ý sai rằng một ngoại lệ xác định chính xác agent bị lỗi.

Nó tường minh là một triển khai fallback cấp crew có giới hạn.

Trong production, hãy kết hợp cùng chính sách định tuyến với checkpointing của CrewAI.

---

Chạy workflow CrewAI như thế nào?

Lưu file thành:

crewai_multi_model.py

Sau đó chạy:

python crewai_multi_model.py \  "Should a small SaaS add AI-generated meeting summaries?"

Phản hồi thành công sẽ chứa thông tin tương tự:

{  "selected_models": {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6"  },  "raw": "<final decision memo>",  "tasks_output": [    "<research output>",    "<analysis output>",    "<writing output>"  ],  "token_usage": "<usage information>"}

Phản hồi và giá trị usage chính xác phụ thuộc vào đầu vào, hành vi model, phiên bản CrewAI, và đường thực thi.

Nếu lỗi có thể retry kích hoạt tuyến fallback, đối tượng selected_models hiển thị tuyến được dùng cho lượt thực thi crew đó.

---

Thiết kế định tuyến model production như thế nào?

Chính sách định tuyến production nên cân nhắc nhiều hơn chất lượng model.

Một hàm quyết định hữu ích là:

Model Score =Quality+ Reliability+ Context Fit+ Tool Compatibility- Cost- Latency

Bạn có thể triển khai ở nhiều cấp độ.

Định tuyến dựa trên chi phí

Tác vụ đơn giản → model tiết kiệmTác vụ phức tạp → model cao cấp

Định tuyến dựa trên độ trễ

Yêu cầu tương tác → model nhanhWorkflow nền → model chất lượng cao hơn

Định tuyến dựa trên độ tin cậy

Model chính     ↓lỗi tạm thời     ↓model fallback

Định tuyến dựa trên task

Research → Model AAnalysis → Model BWriting → Model CCode → Model D

Cách cuối đặc biệt tự nhiên với CrewAI vì framework vốn cho mỗi agent một vai trò riêng.

---

Làm sao để fallback an toàn?

Một hệ thống fallback vững chắc nên tuân bốn quy tắc.

Không fallback khi lỗi xác thực

Nếu API key không hợp lệ:

401

đổi model sẽ không sửa được.

Không fallback khi yêu cầu sai

Nếu yêu cầu không hợp lệ:

400422

hãy sửa yêu cầu.

Không fallback vô hạn

Đặt giới hạn cứng:

MAX_FALLBACK_ATTEMPTS = 2

Hệ thống fallback không giới hạn có thể trở thành vòng lặp retry tốn kém.

Model fallback phải tương thích yêu cầu

Model fallback phải hỗ trợ các tính năng agent của bạn yêu cầu.

Ví dụ, nếu agent chính cần một tool cụ thể hoặc hành vi đầu ra có cấu trúc, fallback phải hỗ trợ cùng hợp đồng đó.

Tương thích OpenAI không đồng nghĩa tương thích tính năng.

---

Lỗi thường gặp CrewAI + CometAPI là gì?

---

Phân biệt lỗi CrewAI với lỗi model như thế nào?

Phân biệt này quan trọng khi debug.

Lỗi cấu hình

Thiếu API keyModel ID không hợp lệBase URL không hợp lệTham số không được hỗ trợ

Các lỗi này nên fail nhanh.

Lỗi nhà cung cấp/API

401403404429500503

Cần xử lý khác nhau tùy trạng thái.

Lỗi ứng dụng

Đầu ra agent không hợp lệTool trả dữ liệu sai định dạngThiếu ngữ cảnh taskTác dụng phụ thất bại

Những lỗi này không nhất thiết được giải quyết bằng cách đổi model.

Một hệ thống agent trưởng thành do đó nên có xử lý riêng cho:

cấu hình      ↓truyền tải API      ↓thực thi model      ↓logic agent      ↓thực thi tool      ↓tác dụng phụ ứng dụng

An toàn hơn nhiều so với một khối:

except Exception:    use_fallback()

---

Bảo vệ tác dụng phụ bên ngoài như thế nào?

Fallback phức tạp hơn đáng kể khi agent làm nhiều hơn là sinh văn bản.

Ví dụ, tưởng tượng một agent:

1. tạo bản ghi cơ sở dữ liệu
2. gửi email
3. gọi API bên ngoài
4. cập nhật CRM

Nếu model timeout sau khi tác vụ bên ngoài đã thành công, chạy lại toàn bộ crew có thể nhân đôi thao tác.

Hãy dùng:

• idempotency key
• checkpoint task
• ranh giới giao dịch
• execution ID
• trạng thái task bền vững
• xác nhận tác dụng phụ tường minh

Ví dụ:

job_id = crew_run_123task_id = writer_456

Lưu các định danh này cùng các thao tác bên ngoài để retry có thể xác định liệu thao tác đã xảy ra hay chưa.

---

Giám sát workflow CrewAI multi-model như thế nào?

Tối thiểu, log:

workflow_idagentmodeltaskstart_timeend_timelatencystatusfallback_usedfallback_reasoninput_tokensoutput_tokenstotal_tokens

Đừng log:

API keythông tin xác thực riêngđầy đủ prompt nhạy cảmdữ liệu riêng tư người dùngđầu ra model chưa được che giấu

Với mỗi model, theo dõi:

Độ tin cậy

tỷ lệ thành côngtỷ lệ timeouttỷ lệ 5xxtỷ lệ fallback

Hiệu năng

độ trễ p50độ trễ p95độ trễ p99

Chi phí

input tokensoutput tokenschi phí mỗi taskchi phí mỗi workflow hoàn thành

Chất lượng

tỷ lệ thành công taskđánh giá con ngườihợp lệ đầu ra có cấu trúcthành công gọi tool

Điều này biến định tuyến model từ ưu tiên hardcode thành một hệ thống kỹ thuật có thể quan sát.

---

Chọn giữa API trực tiếp của nhà cung cấp và CometAPI như thế nào?

Lựa chọn phụ thuộc vào kiến trúc của bạn.

Nếu ứng dụng của bạn chỉ cần một nhà cung cấp và các khả năng gốc của họ, tích hợp trực tiếp có thể hoàn toàn hợp lý.

Nếu ứng dụng CrewAI của bạn cần model từ nhiều nhà cung cấp và bạn muốn một lớp truy cập, CometAPI trở nên hấp dẫn hơn.

Điểm quan trọng là CometAPI không thay thế CrewAI.

Thay vào đó:

CrewAIĐiều phối agent       ↓CometAPITruy cập model       ↓Nhiều model

Mỗi lớp có trách nhiệm khác nhau.

---

Kiến trúc này mở rộng như thế nào?

Khi chính sách định tuyến được tách khỏi định nghĩa agent, thêm một model không đòi hỏi xây lại toàn bộ ứng dụng.

Ví dụ:

PRIMARY_MODELS = {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6",    "coder": "YOUR_CODE_MODEL",}

Cùng kiến trúc có thể hỗ trợ:

Agent nghiên cứuAgent phân tíchAgent viết codeAgent reviewAgent viếtAgent kiểm chứng

Mỗi agent có thể có model khác nhau trong khi chia sẻ cùng lớp truy cập CometAPI.

Bước tiếp theo là làm định tuyến động.

Thay vì:

"analyst": "claude-opus-5"

bạn có thể dùng:

select_model(    task="analysis",    budget=budget,    latency_target=latency_target,)

Hệ thống định tuyến khi đó có thể chọn từ các model đã được phê duyệt dựa trên yêu cầu ứng dụng.

---

Kiến trúc production tốt nhất cho CrewAI + CometAPI là gì?

Với workflow nhỏ:

User Input   ↓CrewAI   ↓CometAPI   ↓Models

Với production:

                     ┌───────────────┐                     │ Model Catalog │                     └───────┬───────┘                             │                             ▼User → CrewAI → Routing Policy → CometAPI           │          │             │           │          │             ├── Gemini           │          │             ├── Claude           │          │             └── GPT           │          │           │          ▼           │     Cost / Quality /           │     Latency / Policy           │           ▼      Checkpoints           │           ▼      Usage Tracking

Các thành phần production chính là:

1. Danh sách cho phép model
2. Định tuyến theo agent
3. Retry có giới hạn
4. Checkpoint task
5. Theo dõi usage
6. Kiểm soát chi phí
7. Kiểm thử tương thích model
8. Khả năng quan sát
9. Tác dụng phụ idempotent

Kiến trúc đó vững chắc hơn nhiều so với chỉ thêm try/except quanh crew.kickoff().

---

Một CometAPI Key, Model khác nhau, Vai trò agent rõ ràng hơn

Cách hữu ích nhất để nghĩ về CrewAI và CometAPI cùng nhau là như hai lớp bổ trợ.

CrewAI định nghĩa agent làm gì.

CometAPI định nghĩa các agent đó truy cập model ra sao.

Sự tách biệt đó giúp có thể gán model nhanh cho agent nghiên cứu khối lượng lớn, model suy luận mạnh cho agent phân tích, và model đa dụng cho writer cuối cùng mà không phải duy trì tích hợp riêng từng nhà cung cấp trong workflow.

Triển khai đơn giản nhất dùng một CometAPI key và một OpenAI-compatible base URL:

https://api.cometapi.com/v1

Với production, tiến thêm một bước: giữ định tuyến model trong cấu hình, xác thực khả dụng model trước khi triển khai, dùng fallback có giới hạn chỉ cho lỗi tạm thời, checkpoint các task đã hoàn thành, và ghi lại metadata model và usage cho mọi lần chạy.

Điều đó cho bạn mẫu bền vững hơn nhiều so với chỉ kết nối CrewAI tới một LLM:

CrewAI điều phối agent. CometAPI tập trung truy cập model. Model ID điều khiển định tuyến. Checkpoint bảo vệ công việc đã hoàn thành. Theo dõi usage kiểm soát chi phí.

---

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

CrewAI có thể dùng nhiều AI model trong cùng một crew không?

Có. Gán cấu hình LLM khác nhau cho từng CrewAI agent. Mỗi cấu hình có thể chỉ định model riêng trong khi dùng cùng CometAPI API key và base URL.

CrewAI có thể kết nối tới API tương thích OpenAI không?

Có. Cấu hình LLM của CrewAI hỗ trợ base_url tùy chỉnh và API key cho các endpoint tương thích OpenAI.

Với CometAPI, base URL là:

https://api.cometapi.com/v1

Tôi có cần API key riêng cho GPT, Claude, và Gemini không?

Khi truy cập các model này qua CometAPI, ứng dụng có thể dùng credential và endpoint của CometAPI thay vì triển khai thông tin xác thực riêng lẻ cho từng agent CrewAI.

Một API key có nghĩa là các model có khả năng giống hệt nhau?

Không. Giao diện API có thể hợp nhất trong khi khả năng model vẫn khác nhau. Cửa sổ ngữ cảnh, hỗ trợ tool, tham số, hành vi đầu ra, độ trễ và giá có thể khác theo model.

Tôi có nên retry toàn bộ workflow CrewAI khi một model thất bại?

Chỉ với workflow đơn giản, không trạng thái. Retry toàn bộ crew có thể lặp lại các task đã hoàn thành và tăng chi phí. Với workflow production, hãy checkpoint các task đã hoàn thành và tiếp tục từ phần thất bại khi khả thi.

Chức năng checkpointing hiện tại của CrewAI được thiết kế để bảo toàn trạng thái thực thi và tiếp tục sau lỗi.

Mọi ngoại lệ CrewAI có nên kích hoạt fallback model?

Không. Lỗi xác thực, yêu cầu sai định dạng, model ID không hợp lệ, và tham số không được hỗ trợ thường cần thay đổi cấu hình thay vì đổi model.

Fallback nên dành cho các lỗi tạm thời có giới hạn như timeout, rate limit, và phản hồi 5xx tạm thời.

Theo dõi chi phí của từng CrewAI agent như thế nào?

Ghi lại tên agent, model ID, mức dùng token, độ trễ, trạng thái thực thi, và thông tin fallback cho từng task. Dùng dữ liệu đó để tính chi phí theo agent và workflow.

Tôi có thể thay đổi động model gán cho một agent không?

Có. Giữ model ID trong cấu hình định tuyến thay vì nhúng trực tiếp vào định nghĩa agent. Ứng dụng của bạn khi đó có thể chọn model dựa trên chi phí, độ trễ, loại task, hoặc khả dụng.

CometAPI có phải là thay thế cho CrewAI?

Không. Chúng hoạt động ở các lớp khác nhau. CrewAI điều phối agent và task, trong khi CometAPI cung cấp lớp truy cập model thống nhất.

Tôi có thể tìm các model CometAPI hiện tại ở đâu?

Dùng CometAPI model directory cho khám phá thủ công và model API cho xác thực bằng lập trình. Trang quick-start hiện tại của CometAPI liệt kê 500+ model thuộc các nhóm văn bản, ảnh, video, và âm thanh.

---

Nguồn

• CometAPI Quick Start
• CometAPI Model Directory
• CometAPI API Documentation
• CometAPI Python SDK
• CrewAI Documentation
• CrewAI LLM Configuration
• CrewAI Checkpointing