สร้างเอเจนต์ CrewAI แบบหลายโมเดลด้วย CometAPI:

การสร้างระบบหลายเอเจนต์ด้วย CrewAI จะน่าสนใจยิ่งขึ้นเมื่อเอเจนต์ต่างๆ สามารถใช้โมเดลที่แตกต่างกันได้

นักวิจัยอาจได้ประโยชน์จากโมเดลที่รวดเร็วและประหยัด นักวิเคราะห์อาจต้องการโมเดลที่มีความสามารถในการให้เหตุผลสูงกว่า และนักเขียนอาจต้องใช้โมเดลที่เหมาะกับการสร้างงานเขียนระยะยาวคุณภาพสูง โดยทั่วไป การเชื่อมต่อเอเจนต์เหล่านี้เข้ากับผู้ให้บริการต่างๆ หมายถึงการต้องจัดการข้อมูลรับรอง API แยกกัน ปลายทาง (endpoint) SDK ระบบเรียกเก็บเงิน และการตั้งค่าเฉพาะของผู้ให้บริการ

สถาปัตยกรรมที่สะอาดกว่าคือให้ CrewAI จัดการเอเจนต์และเวิร์กโฟลว์ ในขณะที่ CometAPI จัดการการเข้าถึงโมเดล

CometAPI มีปลายทางที่เข้ากันได้กับ OpenAI ที่ https://api.cometapi.com/v1 ทำให้แอปพลิเคชันสามารถส่งคำขอไปยังโมเดลจากหลายผู้ให้บริการผ่านอินเทอร์เฟซ API ร่วมกันได้ เอกสาร Quick Start ปัจจุบันยังรองรับการใช้ OpenAI Python SDK มาตรฐานโดยเปลี่ยน API key และ base URL ด้วย

ในบทเรียนนี้ คุณจะสร้างเวิร์กโฟลว์ CrewAI ที่มีสามเอเจนต์ด้วย:

• Gemini 3.7 Flash สำหรับการวิจัย
• Claude Opus 5 สำหรับการวิเคราะห์
• GPT-5.6 สำหรับงานเขียนสุดท้าย
• CometAPI API key เพียงหนึ่งตัว
• API base URL เพียงหนึ่งค่า
• การกำหนดค่าโมเดลรายเอเจนต์
• การ fallback แบบมีกรอบสำหรับความล้มเหลวชั่วคราว
• CrewAI checkpointing เพื่อการกู้คืนในระบบโปรดักชัน
• การติดตามการใช้โทเคนและการประมวลผล
• การตรวจสอบโมเดลฝั่งเซิร์ฟเวอร์

เส้นแบ่งทางสถาปัตยกรรมที่สำคัญนั้นเรียบง่าย:

CrewAI จัดการการทำงานของเอเจนต์ CometAPI จัดการการเข้าถึงโมเดล Model ID ควบคุมการกำหนดเส้นทาง

---

CrewAI Multi-Agent Model Routing คืออะไร?

CrewAI เป็นเฟรมเวิร์ก Python สำหรับสร้างเอเจนต์ งาน crews และเวิร์กโฟลว์แบบหลายเอเจนต์ แต่ละเอเจนต์สามารถมีการตั้งค่า LLM ของตัวเอง ในขณะที่ Crew ทำหน้าที่ประสานวิธีที่เอเจนต์เหล่านั้นดำเนินงานและแลกเปลี่ยนบริบท

การตั้งค่า LLM ใน CrewAI ปัจจุบันรองรับการกำหนด model api_key และ base_url อย่างชัดเจน รวมถึงปลายทางที่เข้ากันได้กับ OpenAI แบบกำหนดเองด้วย

นั่นทำให้ออกแบบสถาปัตยกรรมหลายโมเดลได้ตรงไปตรงมา:

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

เอเจนต์ยังคงแยกจากกันในเชิงตรรกะ แต่การเข้าถึงโมเดลจะรวมศูนย์

นี่แตกต่างจากการกล่าวว่าโมเดลทั้งหมดสามารถทดแทนกันได้ API ที่เข้ากันได้กับ OpenAI ให้ส่วนติดต่อคำขอร่วมกัน; แต่ไม่ได้รับประกันขีดจำกัดบริบท การรองรับเครื่องมือ การควบคุมการให้เหตุผล พฤติกรรมเอาต์พุต ความหน่วง หรือราคาเหมือนกัน

ความแตกต่างนี้สำคัญในการออกแบบการกำหนดเส้นทางในโปรดักชัน

---

ทำไมต้องใช้ CometAPI ร่วมกับ CrewAI?

ข้อดีหลักไม่ใช่ว่า CrewAI จะกลายเป็นเฟรมเวิร์กหลายผู้ให้บริการทันที CrewAI รองรับผู้ให้บริการ LLM ได้หลายรายอยู่แล้ว

ข้อดีคือ การเข้าถึงโมเดลสามารถรวมไว้หลังเลเยอร์ API เดียวได้

หากไม่มีเลเยอร์ API แบบรวม เวิร์กโฟลว์สามเอเจนต์อาจมีหน้าตาแบบนี้:

เมื่อใช้ CometAPI:

เอกสาร Quick Start ปัจจุบันของ CometAPI อธิบายว่าปลายทางของบริการเป็นตัวแทนแทน base URL ของ OpenAI API ได้โดยตรง และแสดงรายการโมเดลจากหลายผู้ให้บริการภายในบริการเดียวกัน

สิ่งนี้ทำให้แอปพลิเคชันแยกความรับผิดชอบได้อย่างมีประโยชน์:

CrewAI

• กำหนดบทบาทของเอเจนต์
• กำหนดงาน
• ส่งต่อบริบท
• ควบคุมการทำงาน
• จัดการการวนซ้ำของเอเจนต์
• จัดการการประสานในระดับ crew

CometAPI

• ให้เลเยอร์การเข้าถึงโมเดลแบบร่วมกัน
• รวมศูนย์การตรวจสอบสิทธิ์ API
• ให้การกำหนดเส้นทางโมเดลผ่าน Model ID
• ให้ปลายทาง API เพียงจุดเดียวแก่แอป
• ให้การมองเห็นการใช้งานและการเรียกเก็บเงินแบบรวม

---

เวิร์กโฟลว์ CrewAI นี้จะสร้างอะไร?

ตัวอย่างนี้สร้างเอเจนต์สามตัวแบบลำดับกัน

นี่เป็น ตัวอย่างนโยบายการกำหนดเส้นทาง ไม่ใช่การจัดอันดับแบบ benchmark

โมเดลที่เหมาะกับเอเจนต์ของคุณขึ้นอยู่กับ:

• ความซับซ้อนของงาน
• ความยาวบริบทที่ต้องการ
• การใช้เครื่องมือ
• ข้อกำหนดเอาต์พุตแบบมีโครงสร้าง
• ความหน่วง
• ความเชื่อถือได้
• ต้นทุนโทเคน
• คุณภาพเอาต์พุต
• ผลการประเมินเฉพาะของแอปพลิเคชัน

กฎที่มีประโยชน์คือ:

เลือกโมเดลให้เหมาะกับงานที่เอเจนต์ทำ ไม่ใช่เพียงเพราะผู้ให้บริการที่มันมาจาก

---

เอเจนต์ CrewAI แต่ละตัวควรใช้โมเดลใด?

สำหรับตัวอย่างนี้ การกำหนดโมเดลใช้กลยุทธ์สมดุลต้นทุนกับขีดความสามารถแบบง่ายๆ

Researcher: Gemini 3.7 Flash

งานวิจัยมักเกี่ยวข้องกับการประมวลข้อมูลจำนวนมากและผลิตผลลัพธ์กลางที่กะทัดรัด

ดังนั้นโมเดลที่รวดเร็วอาจมีประโยชน์สำหรับงานวิจัยปริมาณสูง

"researcher": "gemini-3.7-flash"

Analyst: Claude Opus 5

นักวิเคราะห์มีบทบาทที่แคบกว่าแต่ต้องใช้การให้เหตุผลอย่างเข้มข้น รับผลลัพธ์จากงานวิจัยและแปลงเป็นข้อเสนอแนะ

"analyst": "claude-opus-5"

Writer: GPT-5.6

เอเจนต์สุดท้ายจะแปลงงานวิจัยและการวิเคราะห์เป็นบันทึกการตัดสินใจสำหรับนักพัฒนา

"writer": "gpt-5.6"

ส่วนสำคัญไม่ใช่การกำหนดสามตัวนี้แบบตายตัว แอปของคุณควรประเมินโมเดลที่เป็นผู้สมัครกับงานที่เป็นตัวแทนก่อนที่จะกำหนดนโยบายการกำหนดเส้นทาง

---

ต้องมีอะไรบ้างก่อนเริ่ม?

คุณต้องมี:

• Python 3.10+
• CrewAI
• ความเข้ากันได้กับ OpenAI Python SDK
• python-dotenv
• CometAPI API key
• Model ID ที่คุณตั้งใจจะใช้

การเชื่อมต่อ Python กับ CometAPI ในปัจจุบันรองรับ API ที่เข้ากันได้กับ OpenAI และแพกเกจ CometAPI Python อย่างเป็นทางการระบุ COMETAPI_KEY และ COMETAPI_BASE_URL เป็นตัวเลือกการตั้งค่าจาก environment

ปลายทางมาตรฐานคือ:

https://api.cometapi.com/v1

ก่อนเปิดใช้งาน โปรดตรวจสอบว่า Model ID ที่คุณเลือกมีอยู่จริงในขณะนั้น และรองรับปลายทางและพารามิเตอร์ที่เวิร์กโหลด CrewAI ของคุณต้องใช้ แคตตาล็อกโมเดลและราคาสามารถเปลี่ยนแปลงได้

---

ติดตั้ง CrewAI และไลบรารีที่จำเป็นอย่างไร?

สร้างสภาพแวดล้อม Python ใหม่:

python -m venv .venv

เปิดใช้งาน:

source .venv/bin/activate

บน Windows:

.venv\Scripts\Activate.ps1

จากนั้นติดตั้งไลบรารีที่จำเป็น:

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

การระบุ openai โดยตรงนั้นตั้งใจ เพราะการทำ fallback ด้านล่างจะ import คลาสข้อยกเว้นของ OpenAI SDK โดยตรง

สำหรับโปรดักชัน ให้ตรึงเวอร์ชันที่คุณทดสอบแทนการพึ่งพาเวอร์ชันล่าสุดตลอดไป

เช่น:

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

เลเยอร์ LLM ของ CrewAI กำลังพัฒนาอย่างต่อเนื่อง ดังนั้นควรตรวจสอบคอนสตรักเตอร์และการตั้งค่าผู้ให้บริการกับเวอร์ชัน CrewAI ที่แอปของคุณใช้ เอกสารปัจจุบันของ CrewAI รองรับการกำหนด LLM ด้วย base_url แบบกำหนดเองและ API key

---

ตั้งค่า CometAPI API Key อย่างไร?

สร้างไฟล์ .env:

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

โหลดค่าเหล่านี้ใน 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",)

อย่า commit .env ลง Git

เพิ่มใน .gitignore:

.env.venv/__pycache__/

API key ควรคงเป็นข้อมูลรับรองฝั่งเซิร์ฟเวอร์ เอกสาร Quick Start ปัจจุบันของ CometAPI ก็แนะนำให้เก็บ key ไว้ในตัวแปร environment แทนการวางไว้ในซอร์สโค้ดเช่นกัน

---

เชื่อมต่อ CrewAI เข้ากับ CometAPI อย่างไร?

อ็อบเจ็กต์ LLM ของ CrewAI สามารถรับชื่อโมเดล API key และ base_url แบบกำหนดเองได้

สร้างตัวช่วย:

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,    )

วิธีนี้ดีกว่าการฝังการตั้งค่าเดียวกันซ้ำๆ ในทุกเอเจนต์

ตอนนี้แต่ละเอเจนต์ต้องการเพียง Model ID:

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

ทำไมต้องตั้งค่า max_retries=0?

เหตุผลคือการควบคุม fallback

หากไคลเอนต์ LLM ชั้นล่าง retry โดยอัตโนมัติ และแอปของคุณก็มีการทำ fallback ด้วยเช่นกัน ความล้มเหลวหนึ่งครั้งอาจกลายเป็นคำขอที่ซ่อนอยู่หลายครั้งก่อนที่ตรรกะ fallback จะทำงาน

สำหรับบทเรียนที่ต้องการการกำหนดเส้นทางอย่างชัดเจน การปล่อยให้แอปตัดสินใจว่าจะ retry หรือสลับโมเดลเมื่อใดจะชัดเจนกว่า

---

กำหนดนโยบายการกำหนดเส้นทางโมเดลอย่างไร?

เก็บการกำหนดเส้นทางไว้ภายนอกพรอมต์:

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",}

สิ่งนี้สร้างขอบเขตการกำหนดค่าอย่างชัดเจน

ในภายหลัง คุณสามารถย้าย mapping เดียวกันไปไว้ใน:

• การตั้งค่า environment
• YAML
• JSON
• ฐานข้อมูล
• feature flags
• บริการภายในสำหรับการกำหนดเส้นทางโมเดล

โดยไม่ต้องเขียนพรอมต์ของเอเจนต์ใหม่

---

สร้างเอเจนต์ CrewAI ทั้งสามอย่างไร?

สร้างอ็อบเจ็กต์ LLM หนึ่งตัวต่อเอเจนต์

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

ตอนนี้การกำหนดโมเดลแยกออกจากคำจำกัดความบทบาทของเอเจนต์โดยสมบูรณ์

นี่คือสิ่งที่ทำให้การกำหนดเส้นทางโมเดลใช้งานได้จริง

---

เชื่อมเอเจนต์ด้วยงานแบบลำดับอย่างไร?

สร้างงานสามงาน:

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

สายโซ่การพึ่งพาคือ:

Topic  ↓Research  ↓Analysis  ↓Final memo

นักวิเคราะห์จะได้รับเอาต์พุตของงานวิจัย ในขณะที่นักเขียนจะได้รับทั้งบริบทของงานวิจัยและการวิเคราะห์

---

สร้าง Crew อย่างไร?

รวมเอเจนต์และงานเข้าด้วยกัน:

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,    )

ตอนนี้การกำหนดเส้นทางโมเดลขึ้นอยู่กับการกำหนดค่าโดยสิ้นเชิง

การเปลี่ยน:

"researcher": "gemini-3.7-flash"

ไปเป็นโมเดลที่รองรับอื่น ไม่จำเป็นต้องเปลี่ยนพรอมต์หรือคำจำกัดความของงานวิจัย

---

ควรให้ CrewAI ทำ fallback ของโมเดลอย่างไร?

นี่เป็นจุดที่การใช้งานแบบมุ่งสู่โปรดักชันต้องระมัดระวังมากขึ้น

ความผิดพลาดที่พบได้บ่อยคือ:

Any error   ↓Switch model

นั่นเข้มเกินไป

ตัวอย่างเช่น ความผิดพลาดเหล่านี้โดยทั่วไป ไม่ควรกระตุ้นให้ทำ fallback ของโมเดล:

400 Bad Request401 Unauthorized403 Forbidden404 Not Found422 Validation Error

การสลับโมเดลจะไม่แก้ไข API key ที่ไม่ถูกต้องหรือคำขอที่รูปแบบไม่ถูกต้อง

การ fallback เหมาะสมกว่าสำหรับความล้มเหลวชั่วคราว เช่น:

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

ดังนั้นนโยบาย fallback ควรเป็น:

Retry หรือสลับโมเดลเฉพาะสำหรับความล้มเหลวชั่วคราวที่อยู่ในกรอบ และเฉพาะเมื่อโมเดล fallback รองรับสัญญาคำขอเดียวกัน

---

ตรวจจับข้อผิดพลาดที่ retry ได้อย่างไร?

คุณสามารถใช้คลาสข้อผิดพลาดของ 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

สิ่งนี้ตั้งใจเว้นข้อผิดพลาดระดับ 400 ที่เกี่ยวกับการตั้งค่าการกำหนดค่า ยกเว้น 408 และ 429

---

ควร retry ทั้ง crew หรือเฉพาะเอเจนต์ที่ล้มเหลว?

มีสองกลยุทธ์ fallback ที่แตกต่างกัน

Fallback ระดับ crew

การใช้งานที่ง่ายที่สุดคือ:

Start crew   ↓failure   ↓change routing   ↓run crew again

เข้าใจง่าย แต่สามารถทำให้งานที่เสร็จแล้วถูกรันซ้ำได้

ตัวอย่างเช่น:

Research → completedAnalysis → completedWriter → failed

การ retry kickoff() ทั้งหมดอาจทำให้เกิด:

Research → againAnalysis → againWriter → fallback

ซึ่งเพิ่ม:

• การใช้โทเคน
• ความหน่วง
• ค่าใช้จ่าย API
• ผลข้างเคียงที่อาจเกิดขึ้น

กู้คืนระดับงาน

เวิร์กโฟลว์สำหรับโปรดักชันควร checkpoint งานที่เสร็จแล้วแทน:

Research   ↓checkpoint   ↓Analysis   ↓checkpoint   ↓Writer fails   ↓retry writer with fallback

CrewAI ปัจจุบันมี checkpointing ที่บันทึกสถานะการทำงานและอนุญาตให้รันต่อหลังจากความล้มเหลว ตามที่เอกสารระบุ ระบบ checkpoint จะข้ามงานที่เสร็จแล้วและดำเนินงานต่อจากสถานะที่บันทึกไว้

นี่เป็นสถาปัตยกรรมที่ดีกว่าสำหรับเวิร์กโฟลว์ที่มีค่าใช้จ่ายสูงหรือมีผลข้างเคียง

---

เพิ่ม CrewAI Checkpointing อย่างไร?

สำหรับเวิร์กโฟลว์โปรดักชัน เปิดใช้ checkpointing บน crew:

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

ระบบ checkpointing ของ CrewAI สามารถคงสถานะการทำงานหลังจากงานเสร็จ และกู้คืน crew จาก checkpoint ได้

ตัวอย่างเช่น รันที่กู้คืนสามารถใช้:

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

การตั้งค่า checkpoint ที่แน่นอนควรตรงกับเวอร์ชัน CrewAI ที่ใช้ในโปรเจ็กต์ของคุณ

ประเด็นสถาปัตยกรรมที่สำคัญคือ:

Checkpoint ก่อน แล้วค่อย fallback

สิ่งนี้ป้องกันไม่ให้ความล้มเหลวของโมเดลชั่วคราวบังคับให้รันงานที่เสร็จแล้วอีกครั้งซึ่งมีค่าใช้จ่ายสูง

---

ติดตั้ง fallback แบบมีกรอบอย่างง่ายอย่างไร?

สำหรับบทเรียน คุณยังสามารถสาธิต fallback ระดับ crew แบบง่ายได้

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

โปรดสังเกตความแตกต่างที่สำคัญ:

นี่ไม่ได้อ้างว่าได้ระบุเอเจนต์ที่ล้มเหลวอย่างแม่นยำ

นี่เป็น กลยุทธ์ fallback ระดับ crew แบบมีกรอบ

สำหรับเวิร์กโฟลว์ขนาดเล็กที่ไม่เก็บสถานะ อาจยอมรับได้ สำหรับเวิร์กโฟลว์โปรดักชันที่มีงานวิจัย เครื่องมือ หรือผลข้างเคียงที่แพง ให้ใช้การกู้คืนแบบ checkpoint

---

ติดตามการใช้โทเคนใน CrewAI อย่างไร?

การติดตามการใช้งานควรเป็นส่วนหนึ่งของเลเยอร์กำหนดเส้นทาง ไม่ใช่เรื่องภายหลัง

เมื่อจบรัน ให้ตรวจสอบผลลัพธ์ 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)

ฟิลด์การใช้งานที่มีอยู่จริงอาจแตกต่างกันตามเวอร์ชัน CrewAI และเส้นทางการทำงาน ดังนั้นให้ถืออ็อบเจ็กต์ผลลัพธ์ที่คืนมาเป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับเวอร์ชันที่คุณใช้งาน

บันทึกการใช้งานสำหรับโปรดักชันควรมีข้อมูลอย่างน้อยดังนี้:

job_idagentmodelinput_tokensoutput_tokenstotal_tokenslatency_msfallback_usedfallback_reasonstatuscreated_at

สิ่งนี้ช่วยให้คุณตอบคำถาม เช่น:

เอเจนต์ใดใช้ทรัพยากรไปมากที่สุด?

นักวิเคราะห์เกิด fallback บ่อยแค่ไหน?

โมเดลใดมีความหน่วงสูงที่สุด?

เวิร์กโฟลว์แต่ละชุดมีค่าใช้จ่ายเท่าใด?

---

ควบคุมต้นทุนในระดับเอเจนต์อย่างไร?

การกำหนดเส้นทางหลายโมเดลจะมีประโยชน์ที่สุดเมื่อสะท้อนความแตกต่างของเวิร์กโหลดจริง

ตัวอย่าง:

Researcher→ high volume→ lower-cost modelAnalyst→ low volume→ stronger reasoning modelWriter→ medium volume→ general-purpose production model

คุณยังสามารถจำกัดต้นทุนผ่านการตั้งค่าของเอเจนต์

เช่น:

max_iter=3

จะจำกัดวงรอบการวนซ้ำของเอเจนต์ ไม่ควรถูกตีความว่าเป็นขีดจำกัดแข็งว่ามีเพียงสามคำขอ API หรือสามงบประมาณโทเคน

การควบคุมเพิ่มเติม ได้แก่:

• จำกัดบริบทของงาน
• สรุปผลลัพธ์กลาง
• แคชงานวิจัยที่ทำซ้ำได้
• จำกัดขนาดอินพุตสูงสุด
• จำกัดจำนวนโทเคนเอาต์พุตสูงสุด (เมื่อรองรับ)
• จำกัดการเรียกเครื่องมือ
• ตั้งงบประมาณรายผู้ใช้
• ตั้งงบประมาณรายเวิร์กโฟลว์
• ติดตามความถี่การ fallback

---

ตรวจสอบโมเดลก่อนเปิดใช้งานอย่างไร?

อย่าฝัง Model ID แบบตายตัวตลอดไป

โมเดลสามารถ:

• ไม่พร้อมใช้งาน
• เปลี่ยนชื่อ
• ถูกเลิกใช้
• ถูกจำกัด
• เปลี่ยนขีดความสามารถ
• เปลี่ยนราคา
• ไม่เข้ากันกับพารามิเตอร์ที่แอปของคุณใช้

CometAPI มีปลายทางแคตตาล็อกโมเดลที่สามารถ query ได้แบบโปรแกรม ในขณะที่ไดเรกทอรีโมเดลสาธารณะใช้ค้นหาด้วยมนุษย์ได้

การตรวจสอบก่อนเปิดใช้งานสามารถทำได้แบบนี้:

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

จากนั้นตรวจสอบว่า Model ID ที่คุณกำหนดมีอยู่จริงก่อนเปิดใช้งาน

เช่น ในกระบวนการ CI ของคุณ ตรวจสอบว่า:

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

อย่าใช้การตรวจสอบความพร้อมใช้งานแทนการทดสอบแอป การที่โมเดลอยู่ในแคตตาล็อกไม่ได้หมายความว่าทุกพารามิเตอร์ เครื่องมือ หรือรูปแบบเอาต์พุตที่เอเจนต์ CrewAI ของคุณใช้จะได้รับการรองรับ

---

ตัวอย่าง CrewAI แบบครบถ้วนมีหน้าตาอย่างไร?

นี่คือการใช้งานแบบรวม:

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()

การปรับปรุงสำคัญเหนือเวอร์ชันเดิมคือ โค้ดไม่ได้บ่งชี้อย่างผิดๆ อีกต่อไปว่าข้อยกเว้นระบุเอเจนต์ที่ล้มเหลวอย่างแม่นยำ

นี่ระบุอย่างชัดเจนว่าเป็น การทำ fallback ระดับ crew แบบมีกรอบ

สำหรับโปรดักชัน ให้ผสานนโยบายการกำหนดเส้นทางแบบเดียวกันกับ CrewAI checkpointing

---

รันเวิร์กโฟลว์ CrewAI อย่างไร?

บันทึกไฟล์เป็น:

crewai_multi_model.py

จากนั้นรัน:

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

การตอบกลับที่สำเร็จจะมีข้อมูลคล้ายกับ:

{  "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>"}

การตอบกลับและค่าการใช้งานที่แน่นอนขึ้นอยู่กับอินพุต พฤติกรรมโมเดล เวอร์ชัน CrewAI และเส้นทางการทำงาน

หากความผิดพลาดที่ retry ได้กระตุ้นเส้นทาง fallback วัตถุ selected_models จะแสดงเส้นทางที่ใช้สำหรับการทำงานของ crew นั้น

---

ออกแบบการกำหนดเส้นทางโมเดลสำหรับโปรดักชันอย่างไร?

นโยบายการกำหนดเส้นทางในโปรดักชันควรพิจารณามากกว่าคุณภาพของโมเดล

ฟังก์ชันการตัดสินใจที่มีประโยชน์คือ:

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

คุณสามารถทำสิ่งนี้ได้หลายระดับ

การกำหนดเส้นทางตามต้นทุน

Simple task → economical modelComplex task → premium model

การกำหนดเส้นทางตามความหน่วง

Interactive request → fast modelBackground workflow → higher-quality model

การกำหนดเส้นทางตามความเชื่อถือได้

Primary model     ↓transient failure     ↓fallback model

การกำหนดเส้นทางตามงาน

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

แนวทางสุดท้ายนี้เป็นธรรมชาติสำหรับ CrewAI เพราะเฟรมเวิร์กให้แต่ละเอเจนต์มีบทบาทที่แตกต่างกันอยู่แล้ว

---

ทำให้ fallback ปลอดภัยอย่างไร?

ระบบ fallback ที่แข็งแรงควรมีสี่กฎ

อย่า fallback เมื่อเกิดข้อผิดพลาดด้านการตรวจสอบสิทธิ์

หาก API key ไม่ถูกต้อง:

401

การเปลี่ยนโมเดลจะไม่แก้ปัญหา

อย่า fallback เมื่อคำขอผิดรูปแบบ

หากคำขอไม่ถูกต้อง:

400422

ให้แก้ไขคำขอแทน

อย่า fallback อย่างไม่มีกำหนด

ตั้งขีดจำกัดแข็ง:

MAX_FALLBACK_ATTEMPTS = 2

ระบบ fallback ที่ไม่มีขีดจำกัดอาจกลายเป็นลูป retry ที่มีค่าใช้จ่ายสูง

ทำให้โมเดล fallback เข้ากันได้กับคำขอ

โมเดล fallback ต้องรองรับคุณสมบัติที่เอเจนต์ของคุณต้องการ

เช่น หากเอเจนต์หลักต้องใช้เครื่องมือเฉพาะหรือพฤติกรรมเอาต์พุตแบบมีโครงสร้าง โมเดล fallback ต้องรองรับสัญญาเดียวกันนั้น

คำว่าเข้ากันได้กับ OpenAI ไม่ได้หมายความว่าเข้ากันได้กับคุณสมบัติ

---

ข้อผิดพลาดที่พบบ่อยที่สุดระหว่าง CrewAI + CometAPI คืออะไร?

---

แยกแยะข้อผิดพลาดจาก CrewAI กับข้อผิดพลาดจากโมเดลอย่างไร?

ความแตกต่างนี้สำคัญเมื่อดีบัก

ข้อผิดพลาดด้านการตั้งค่า

Missing API keyInvalid model IDInvalid base URLUnsupported parameter

ควรล้มเหลวอย่างรวดเร็ว

ข้อผิดพลาดจากผู้ให้บริการ/API

401403404429500503

ต้องจัดการต่างกันขึ้นอยู่กับสถานะ

ข้อผิดพลาดของแอปพลิเคชัน

Agent output invalidTool returned malformed dataTask context missingSide effect failed

ไม่จำเป็นต้องแก้ด้วยการเปลี่ยนโมเดลเสมอไป

ระบบเอเจนต์ที่เติบโตเต็มที่ควรมีการจัดการแยกสำหรับ:

configuration      ↓API transport      ↓model execution      ↓agent logic      ↓tool execution      ↓application side effects

ซึ่งปลอดภัยกว่ามากเมื่อเทียบกับการทำแบบทั่วไปว่า:

except Exception:    use_fallback()

---

ปกป้องผลข้างเคียงภายนอกอย่างไร?

fallback จะซับซ้อนขึ้นมากเมื่อเอเจนต์ทำมากกว่าแค่สร้างข้อความ

ตัวอย่างเช่น ลองนึกภาพเอเจนต์ที่:

1. สร้างเรคคอร์ดในฐานข้อมูล
2. ส่งอีเมล
3. เรียก API ภายนอก
4. อัปเดต CRM

หากโมเดลหมดเวลาหลังจากปฏิบัติการภายนอกสำเร็จ การรันทั้ง crew อีกครั้งอาจทำให้ปฏิบัติการเกิดซ้ำ

ใช้:

• idempotency keys
• task checkpoints
• ขอบเขตธุรกรรม
• execution ID
• สถานะงานที่ทนทาน
• การยืนยันผลข้างเคียงอย่างชัดเจน

ตัวอย่าง:

job_id = crew_run_123task_id = writer_456

เก็บตัวระบุเหล่านี้พร้อมกับการดำเนินการภายนอกเพื่อให้การ retry สามารถตรวจสอบได้ว่าปฏิบัติการเกิดขึ้นแล้วหรือไม่

---

เฝ้าติดตามเวิร์กโฟลว์ CrewAI แบบหลายโมเดลอย่างไร?

อย่างน้อยให้บันทึก:

workflow_idagentmodeltaskstart_timeend_timelatencystatusfallback_usedfallback_reasoninput_tokensoutput_tokenstotal_tokens

อย่าบันทึก:

API keysprivate credentialsfull sensitive promptsprivate user dataunredacted model output

สำหรับแต่ละโมเดล ให้เฝ้าติดตาม:

ความเชื่อถือได้

success ratetimeout rate5xx ratefallback rate

ประสิทธิภาพ

p50 latencyp95 latencyp99 latency

ต้นทุน

input tokensoutput tokenscost per taskcost per completed workflow

คุณภาพ

task success ratehuman evaluationstructured-output validitytool-call success

สิ่งนี้เปลี่ยนการกำหนดเส้นทางโมเดลจากความชอบที่ฝังไว้ให้กลายเป็นระบบวิศวกรรมที่สังเกตได้

---

เลือกระหว่าง API ของผู้ให้บริการโดยตรงกับ CometAPI อย่างไร?

การเลือกขึ้นอยู่กับสถาปัตยกรรมของคุณ

หากแอปของคุณต้องการเพียงผู้ให้บริการเดียวและความสามารถดั้งเดิมของมัน การเชื่อมต่อโดยตรงสามารถสมเหตุสมผลได้อย่างยิ่ง

หากแอป CrewAI ของคุณต้องใช้โมเดลจากหลายผู้ให้บริการและต้องการเลเยอร์การเข้าถึงเดียว CometAPI จะน่าสนใจมากขึ้น

ประเด็นสำคัญคือ CometAPI ไม่ได้แทนที่ CrewAI

แต่แทนที่จะเป็น:

CrewAIAgent orchestration       ↓CometAPIModel access       ↓Multiple models

แต่ละเลเยอร์มีความรับผิดชอบต่างกัน

---

สถาปัตยกรรมนี้ขยายตัวได้อย่างไร?

เมื่อแยกนโยบายการกำหนดเส้นทางออกจากคำจำกัดความของเอเจนต์แล้ว การเพิ่มโมเดลใหม่ไม่จำเป็นต้องสร้างแอปทั้งตัวใหม่

เช่น:

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

สถาปัตยกรรมเดียวกันสามารถรองรับ:

Research agentAnalysis agentCoding agentReview agentWriting agentFact-checking agent

แต่ละเอเจนต์สามารถมีโมเดลที่แตกต่างกัน พร้อมแชร์เลเยอร์การเข้าถึง CometAPI เดียวกัน

ขั้นตอนต่อไปคือทำให้การกำหนดเส้นทางเป็นแบบไดนามิก

แทนที่จะเป็น:

"analyst": "claude-opus-5"

ในที่สุดคุณอาจใช้:

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

ระบบกำหนดเส้นทางสามารถเลือกจากโมเดลที่อนุมัติตามข้อกำหนดของแอปพลิเคชัน

---

สถาปัตยกรรมโปรดักชันที่ดีที่สุดสำหรับ CrewAI + CometAPI คืออะไร?

สำหรับเวิร์กโฟลว์ขนาดเล็ก:

User Input   ↓CrewAI   ↓CometAPI   ↓Models

สำหรับโปรดักชัน:

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

องค์ประกอบโปรดักชันที่สำคัญคือ:

1. รายการโมเดลที่อนุญาต (allowlist)
2. การกำหนดเส้นทางรายเอเจนต์
3. การ retry แบบมีกรอบ
4. การทำ checkpoint ของงาน
5. การติดตามการใช้งาน
6. การควบคุมต้นทุน
7. การทดสอบความเข้ากันได้ของโมเดล
8. ความสามารถในการสังเกต (observability)
9. ผลข้างเคียงที่ idempotent

สถาปัตยกรรมนี้มีความทนทานมากกว่าอย่างมีนัยสำคัญเมื่อเทียบกับการใส่ try/except รอบ crew.kickoff() เฉยๆ

---

CometAPI Key เดียว โมเดลต่างกัน บทบาทเอเจนต์ชัดเจนขึ้น

วิธีคิดที่มีประโยชน์ที่สุดเกี่ยวกับการใช้ CrewAI และ CometAPI ร่วมกันคือการมองว่าเป็นสองเลเยอร์ที่เกื้อกูลกัน

CrewAI กำหนดสิ่งที่เอเจนต์ทำ

CometAPI กำหนดวิธีที่เอเจนต์เหล่านั้นเข้าถึงโมเดล

การแยกนี้ทำให้สามารถกำหนดโมเดลที่เร็วให้กับเอเจนต์วิจัยปริมาณสูง กำหนดโมเดลที่มีเหตุผลแข็งแรงให้กับเอเจนต์วิเคราะห์ และกำหนดโมเดลอเนกประสงค์ให้กับนักเขียนสุดท้ายได้ โดยไม่ต้องรักษาการเชื่อมต่อกับผู้ให้บริการแยกกันภายในเวิร์กโฟลว์

การใช้งานที่ง่ายที่สุดใช้ CometAPI key เดียวและ OpenAI-compatible base URL เดียว:

https://api.cometapi.com/v1

สำหรับโปรดักชัน ยกระดับสถาปัตยกรรมอีกขั้น: เก็บการกำหนดเส้นทางโมเดลไว้ในคอนฟิก ตรวจสอบความพร้อมใช้งานของโมเดลก่อนเปิดใช้งาน ทำ fallback แบบมีกรอบเฉพาะสำหรับความล้มเหลวชั่วคราว ทำ checkpoint งานที่เสร็จแล้ว และบันทึกข้อมูลโมเดลและการใช้งานสำหรับทุกรัน

สิ่งนี้จะให้รูปแบบที่ทนทานกว่ามากเมื่อเทียบกับการเชื่อม CrewAI เข้ากับ LLM เพียงตัวเดียว:

CrewAI จัดการการทำงานของเอเจนต์ CometAPI รวมศูนย์การเข้าถึงโมเดล Model ID ควบคุมการกำหนดเส้นทาง Checkpoint ปกป้องงานที่เสร็จแล้ว การติดตามการใช้งานควบคุมต้นทุน

---

คำถามที่พบบ่อย

CrewAI สามารถใช้หลายโมเดล AI ใน crew เดียวกันได้หรือไม่?

ได้ กำหนด LLM ที่แตกต่างกันให้กับเอเจนต์ CrewAI แต่ละตัว โดยแต่ละการตั้งค่าสามารถระบุโมเดลของตัวเอง ในขณะที่ใช้ CometAPI API key และ base URL เดียวกัน

CrewAI เชื่อมต่อกับ API ที่เข้ากันได้กับ OpenAI ได้หรือไม่?

ได้ การตั้งค่า LLM ของ CrewAI รองรับ base_url แบบกำหนดเองและ API key สำหรับปลายทางที่เข้ากันได้กับ OpenAI

สำหรับ CometAPI base URL คือ:

https://api.cometapi.com/v1

ต้องใช้ API key แยกสำหรับ GPT, Claude และ Gemini หรือไม่?

เมื่อเข้าถึงโมเดลเหล่านี้ผ่าน CometAPI แอปพลิเคชันสามารถใช้ข้อมูลรับรองและปลายทางของ CometAPI แทนการทำข้อมูลรับรองของผู้ให้บริการแยกในแต่ละเอเจนต์ CrewAI

API key เดียวหมายความว่าโมเดลมีความสามารถเหมือนกันหรือไม่?

ไม่ อินเทอร์เฟซ API อาจเป็นหนึ่งเดียว ในขณะที่ความสามารถของโมเดลยังแตกต่างกันได้ ขนาดบริบท การรองรับเครื่องมือ พารามิเตอร์ พฤติกรรมเอาต์พุต ความหน่วง และราคาสามารถแตกต่างกันไปตามโมเดล

ควร retry เวิร์กโฟลว์ CrewAI ทั้งชุดเมื่อโมเดลตัวหนึ่งล้มเหลวหรือไม่?

เฉพาะสำหรับเวิร์กโฟลว์ง่ายๆ ที่ไม่เก็บสถานะ การ retry ทั้งชุดอาจทำให้งานที่เสร็จแล้วถูกรันซ้ำและเพิ่มต้นทุน สำหรับเวิร์กโฟลว์โปรดักชัน ให้ทำ checkpoint งานที่เสร็จแล้วและทำต่อจากส่วนที่ล้มเหลวเมื่อสามารถทำได้

ฟังก์ชัน checkpointing ของ CrewAI ในปัจจุบันถูกออกแบบมาเพื่อคงสถานะการทำงานและทำงานต่อหลังความล้มเหลว

ข้อยกเว้นของ CrewAI ทุกกรณีควรกระตุ้นให้ fallback โมเดลหรือไม่?

ไม่ การตรวจสอบสิทธิ์ที่ผิดพลาด คำขอที่ผิดรูปแบบ Model ID ที่ไม่ถูกต้อง และพารามิเตอร์ที่ไม่รองรับ โดยทั่วไปต้องแก้ไขการตั้งค่า ไม่ใช่เปลี่ยนโมเดล

fallback เหมาะกับความล้มเหลวชั่วคราวที่อยู่ในกรอบเท่านั้น เช่น การหมดเวลา (timeout) การถูกจำกัดอัตรา (rate limit) และการตอบกลับ 5xx ชั่วคราว

ติดตามต้นทุนของเอเจนต์ CrewAI แต่ละตัวอย่างไร?

บันทึกชื่อเอเจนต์ Model ID การใช้โทเคน ความหน่วง สถานะการทำงาน และข้อมูล fallback สำหรับแต่ละงาน ใช้ข้อมูลที่ได้ในการคำนวณต้นทุนต่อเอเจนต์และต่อเวิร์กโฟลว์

สามารถเปลี่ยนโมเดลที่กำหนดให้เอเจนต์แบบไดนามิกได้หรือไม่?

ได้ เก็บ Model ID ไว้ในคอนฟิกสำหรับการกำหนดเส้นทาง แทนการฝังโดยตรงในคำจำกัดความเอเจนต์ จากนั้นแอปพลิเคชันสามารถเลือกโมเดลตามต้นทุน ความหน่วง ประเภทงาน หรือความพร้อมใช้งาน

CometAPI เป็นตัวแทนของ CrewAI หรือไม่?

ไม่ ทั้งสองทำงานที่เลเยอร์ต่างกัน CrewAI จัดการการประสานงานของเอเจนต์และงาน ในขณะที่ CometAPI ให้เลเยอร์การเข้าถึงโมเดลแบบรวม

จะหาโมเดลของ CometAPI เวอร์ชันปัจจุบันได้จากที่ไหน?

ใช้ CometAPI Model Directory เพื่อการค้นหาด้วยมนุษย์ และใช้ API โมเดลเพื่อการตรวจสอบแบบโปรแกรม เอกสาร Quick Start ปัจจุบันของ CometAPI แสดงโมเดลกว่า 500+ ตัวครอบคลุมหมวดข้อความ ภาพ วิดีโอ และเสียง

---

แหล่งข้อมูล

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