Membangun sistem multi-agen dengan CrewAI menjadi lebih menarik ketika agen yang berbeda dapat menggunakan model yang berbeda.
Seorang peneliti mungkin diuntungkan oleh model yang cepat dan ekonomis, seorang analis mungkin membutuhkan model penalaran yang lebih kuat, dan seorang penulis mungkin memerlukan model yang dioptimalkan untuk pembuatan konten panjang berkualitas tinggi. Secara tradisional, menghubungkan agen-agen ini ke penyedia yang berbeda berarti mengelola kredensial API terpisah, endpoint, SDK, sistem penagihan, dan konfigurasi spesifik penyedia.
Arsitektur yang lebih bersih adalah membiarkan CrewAI mengelola agen dan alur kerja sementara CometAPI mengelola akses model.
CometAPI menyediakan endpoint yang kompatibel dengan OpenAI di https://api.cometapi.com/v1, sehingga aplikasi dapat mengarahkan permintaan ke model dari berbagai penyedia melalui antarmuka API yang umum. Dokumentasi mulai cepat saat ini juga mendukung penggunaan SDK Python OpenAI standar dengan mengubah kunci API dan URL dasar.
Dalam tutorial ini, Anda akan membangun alur kerja CrewAI dengan tiga agen:
- Gemini 3.7 Flash untuk riset
- Claude Opus 5 untuk analisis
- GPT-5.6 untuk penulisan akhir
- Satu kunci API CometAPI
- Satu URL dasar API
- Konfigurasi model per agen
- Fallback terbatas untuk kegagalan sementara
- Checkpointing CrewAI untuk pemulihan produksi
- Pelacakan penggunaan token dan eksekusi
- Validasi model di sisi server
Batas arsitektural yang penting sederhana:
CrewAI menangani orkestrasi agen. CometAPI menangani akses model. ID model menentukan routing.
Apa Itu Perutean Model Multi-Agen CrewAI?
CrewAI adalah kerangka kerja Python untuk membuat agen, tugas, kru, dan alur kerja multi-agen. Setiap agen dapat memiliki konfigurasi LLM sendiri, sementara Crew mengoordinasikan bagaimana agen-agen tersebut menjalankan tugas dan bertukar konteks.
Konfigurasi LLM CrewAI saat ini mendukung pengaturan eksplisit model, api_key, dan base_url, termasuk endpoint yang kompatibel dengan OpenAI.
Itu membuat arsitektur multi-model menjadi sederhana:
CometAPI │ https://api.cometapi.com/v1 │ ┌───────────────────┼───────────────────┐ │ │ │ Researcher Analyst Writer │ │ │ Gemini 3.7 Flash Claude Opus 5 GPT-5.6
Agen tetap terpisah dari perspektif logis, tetapi akses model mereka dipusatkan.
Ini berbeda dari mengatakan bahwa semua model dapat dipertukarkan. API yang kompatibel dengan OpenAI menyediakan antarmuka permintaan yang umum; itu tidak menjamin batas konteks, dukungan alat, kontrol penalaran, perilaku output, latensi, atau harga yang identik.
Perbedaan itu penting saat merancang perutean produksi.
Mengapa Menggunakan CometAPI dengan CrewAI?
Keunggulan utama bukan karena CrewAI tiba-tiba menjadi kerangka kerja multi-penyedia. CrewAI sudah mendukung beberapa penyedia LLM.
Keunggulannya adalah akses model dapat dikonsolidasikan di belakang satu lapisan API.
Tanpa lapisan API terpadu, alur kerja tiga agen mungkin terlihat seperti ini:
| Agen | Penyedia | Kredensial | Integrasi |
|---|---|---|---|
| Researcher | Kunci API Google | Spesifik penyedia | |
| Analyst | Anthropic | Kunci API Anthropic | Spesifik penyedia |
| Writer | OpenAI | Kunci API OpenAI | Spesifik penyedia |
Dengan CometAPI:
| Agen | Model | Kredensial | Endpoint |
|---|---|---|---|
| Researcher | Gemini 3.7 Flash | Kunci CometAPI | CometAPI |
| Analyst | Claude Opus 5 | Kunci CometAPI | CometAPI |
| Writer | GPT-5.6 | Kunci CometAPI | CometAPI |
Dokumentasi mulai cepat CometAPI saat ini menjelaskan endpointnya sebagai pengganti langsung untuk URL dasar API OpenAI dan mencantumkan model dari beberapa penyedia melalui layanan yang sama.
Ini memberi aplikasi pemisahan yang berguna:
CrewAI
- Mendefinisikan peran agen
- Mendefinisikan tugas
- Meneruskan konteks
- Mengontrol eksekusi
- Mengelola iterasi agen
- Menangani orkestrasi tingkat kru
CometAPI
- Menyediakan lapisan akses model yang umum
- Memusatkan autentikasi API
- Menyediakan perutean model melalui ID model
- Memberi aplikasi satu endpoint API
- Menyediakan visibilitas penggunaan dan penagihan yang terpusat
Apa yang Akan Dibangun Alur Kerja CrewAI Ini?
Contoh ini membuat tiga agen berurutan.
| Agen CrewAI | Model Utama | Fallback | Peran |
|---|---|---|---|
| Market Researcher | gemini-3.7-flash | gpt-5.6 | Mengumpulkan fakta dan riset |
| Product Analyst | claude-opus-5 | gpt-5.6 | Mensintesis bukti dan trade-off |
| Technical Writer | gpt-5.6 | gemini-3.7-flash | Membuat memo keputusan akhir |
Ini adalah kebijakan perutean contoh, bukan peringkat benchmark.
Model yang tepat untuk agen Anda bergantung pada:
- kompleksitas tugas
- panjang konteks yang diperlukan
- penggunaan alat
- kebutuhan output terstruktur
- latensi
- keandalan
- biaya token
- kualitas output
- hasil evaluasi spesifik aplikasi
Aturan yang berguna adalah:
Pilih model untuk pekerjaan yang dilakukan agen, bukan semata-mata untuk penyedia asalnya.
Model Mana yang Harus Digunakan Setiap Agen CrewAI?
Untuk contoh ini, penetapan model mengikuti strategi sederhana biaya versus kapabilitas.
Researcher: Gemini 3.7 Flash
Riset sering melibatkan pemrosesan informasi dalam jumlah relatif besar dan menghasilkan hasil perantara yang ringkas.
Model yang cepat karenanya berguna untuk tugas riset dengan volume tinggi.
"researcher": "gemini-3.7-flash"
Analyst: Claude Opus 5
Analis memiliki peran yang lebih sempit namun lebih intensif penalaran. Ia menerima output riset dan mengubahnya menjadi rekomendasi.
"analyst": "claude-opus-5"
Writer: GPT-5.6
Agen terakhir mengubah riset dan analisis menjadi memo keputusan yang ditujukan untuk pengembang.
"writer": "gpt-5.6"
Bagian pentingnya bukan tiga penetapan ini. Aplikasi Anda sebaiknya mengevaluasi model kandidat terhadap tugas representatif sebelum menetapkan kebijakan perutean.
Apa yang Anda Butuhkan Sebelum Memulai?
Anda membutuhkan:
- Python 3.10+
- CrewAI
- Kompatibilitas SDK Python OpenAI
python-dotenv- Kunci API CometAPI
- ID model yang ingin Anda gunakan
Integrasi Python CometAPI saat ini mendukung API yang kompatibel dengan OpenAI, dan paket Python resmi CometAPI mendokumentasikan COMETAPI_KEY dan COMETAPI_BASE_URL sebagai opsi konfigurasi berbasis lingkungan.
Endpoint standar adalah:
https://api.cometapi.com/v1
Sebelum menerapkan, verifikasi bahwa ID model yang Anda pilih saat ini tersedia dan mendukung endpoint serta parameter yang diperlukan oleh beban kerja CrewAI Anda. Katalog model dan harga dapat berubah.
Bagaimana Cara Menginstal CrewAI dan Dependensi?
Buat lingkungan Python baru:
python -m venv .venv
Aktifkan:
source .venv/bin/activate
Di Windows:
.venv\Scripts\Activate.ps1
Lalu instal dependensi:
pip install "crewai[openai]" openai python-dotenv
Menggunakan openai secara eksplisit disengaja karena implementasi fallback di bawah ini mengimpor kelas pengecualian SDK OpenAI secara langsung.
Untuk produksi, kunci versi yang Anda uji alih-alih mengandalkan versi terbaru mengambang tanpa batas.
Sebagai contoh:
crewai==YOUR_TESTED_VERSIONopenai==YOUR_TESTED_VERSIONpython-dotenv==YOUR_TESTED_VERSION
Lapisan LLM CrewAI terus berkembang, jadi konstruktor dan konfigurasi penyedia yang tepat harus diperiksa terhadap versi CrewAI yang digunakan oleh aplikasi Anda. Dokumentasi CrewAI saat ini mendukung pengonfigurasian LLM dengan base_url khusus dan kunci API.
Bagaimana Cara Mengonfigurasi Kunci API CometAPI?
Buat file .env:
COMETAPI_KEY=your_cometapi_keyCOMETAPI_BASE_URL=https://api.cometapi.com/v1
Muat nilai-nilai ini di 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",)
Jangan pernah commit .env ke Git.
Tambahkan ke .gitignore:
.env.venv/__pycache__/
Kunci API harus tetap sebagai kredensial sisi server. Panduan mulai cepat CometAPI saat ini juga merekomendasikan menyimpan kunci dalam variabel lingkungan, bukan di kode sumber.
Bagaimana Cara Menghubungkan CrewAI ke CometAPI?
Objek LLM CrewAI dapat menerima nama model, kunci API, dan URL dasar khusus.
Buat 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, )
Ini lebih disukai daripada menanamkan konfigurasi yang sama secara terpisah di setiap agen.
Setiap agen sekarang hanya membutuhkan ID model:
research_llm = cometapi_llm("gemini-3.7-flash")analysis_llm = cometapi_llm("claude-opus-5")writing_llm = cometapi_llm("gpt-5.6")
Mengapa Mengatur max_retries=0?
Alasannya adalah kontrol fallback.
Jika klien LLM yang mendasari secara otomatis melakukan retry dan aplikasi Anda juga menerapkan fallback, satu kegagalan bisa menjadi beberapa permintaan tersembunyi sebelum logika fallback dieksekusi.
Untuk tutorial dengan perutean eksplisit, lebih bersih membiarkan aplikasi memutuskan kapan retry atau beralih model.
Bagaimana Cara Mendefinisikan Kebijakan Perutean Model?
Simpan perutean di luar prompt Anda:
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",}
Ini menciptakan batas konfigurasi yang jelas.
Anda nantinya dapat memindahkan pemetaan yang sama ke:
- konfigurasi lingkungan
- YAML
- JSON
- basis data
- feature flag
- layanan perutean model internal
tanpa menulis ulang prompt agen.
Bagaimana Cara Membangun Tiga Agen CrewAI?
Buat satu objek LLM per agen.
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
Penetapan model sekarang sepenuhnya independen dari definisi peran agen.
Itulah yang membuat perutean model menjadi praktis.
Bagaimana Cara Menghubungkan Agen dengan Tugas Berurutan?
Buat tiga tugas:
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
Rantai ketergantungannya adalah:
Topic ↓Research ↓Analysis ↓Final memo
Analis menerima output tugas riset, sementara penulis menerima konteks riset dan analisis.
Bagaimana Cara Membangun Kru?
Gabungkan agen dan tugas:
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, )
Sekarang perutean model sepenuhnya didorong oleh konfigurasi.
Mengubah:
"researcher": "gemini-3.7-flash"
ke model lain yang didukung tidak memerlukan perubahan pada prompt riset atau definisi tugas.
Bagaimana Seharusnya Fallback Model CrewAI Bekerja?
Di sinilah implementasi berorientasi produksi membutuhkan perhatian lebih.
Kesalahan umum adalah:
Any error ↓Switch model
Itu terlalu agresif.
Sebagai contoh, kesalahan-kesalahan ini umumnya tidak boleh memicu fallback model:
400 Bad Request401 Unauthorized403 Forbidden404 Not Found422 Validation Error
Beralih model tidak akan memperbaiki kunci API yang tidak valid atau permintaan yang salah format.
Fallback lebih tepat untuk kegagalan sementara seperti:
408 Request Timeout429 Rate Limit500 Internal Server Error502 Bad Gateway503 Service Unavailable504 Gateway TimeoutConnection errorTimeout
Kebijakan fallback karena itu seharusnya:
Retry atau beralih model hanya untuk kegagalan sementara yang terbatas dan hanya ketika model fallback mendukung kontrak permintaan yang sama.
Bagaimana Cara Mendeteksi Error yang Dapat Di-retry?
Anda dapat menggunakan kelas error SDK OpenAI:
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
Ini sengaja mengecualikan kesalahan konfigurasi level 400 selain 408 dan 429.
Haruskah Anda Me-retry Seluruh Kru atau Hanya Agen yang Gagal?
Ada dua strategi fallback yang berbeda.
Fallback tingkat kru
Implementasi paling sederhana adalah:
Start crew ↓failure ↓change routing ↓run crew again
Ini mudah dipahami, tetapi dapat mengulang tugas yang telah selesai.
Sebagai contoh:
Research → completedAnalysis → completedWriter → failed
Retry kickoff() penuh dapat mengeksekusi:
Research → againAnalysis → againWriter → fallback
Itu meningkatkan:
- penggunaan token
- latensi
- biaya API
- potensi efek samping
Pemulihan tingkat tugas
Alur kerja produksi sebaiknya melakukan checkpoint pekerjaan yang selesai:
Research ↓checkpoint ↓Analysis ↓checkpoint ↓Writer fails ↓retry writer with fallback
CrewAI saat ini menyediakan checkpointing yang menyimpan status eksekusi dan memungkinkan suatu run untuk dilanjutkan setelah kegagalan. Perilaku checkpoint yang didokumentasikan melewati tugas yang selesai dan melanjutkan pekerjaan hilir dari status yang disimpan.
Ini adalah arsitektur yang lebih baik untuk alur kerja yang mahal atau menghasilkan efek samping.
Bagaimana Cara Menambahkan Checkpointing CrewAI?
Untuk alur kerja produksi, aktifkan checkpointing pada kru:
crew = Crew( agents=[researcher, analyst, writer], tasks=[ research_task, analysis_task, writing_task, ], process=Process.sequential, checkpoint=True, verbose=True,)
Sistem checkpointing CrewAI dapat menyimpan status eksekusi setelah tugas selesai dan memulihkan kru dari checkpoint.
Sebagai contoh, run yang dipulihkan dapat menggunakan:
from crewai import CheckpointConfigresult = crew.kickoff( from_checkpoint=CheckpointConfig( restore_from="./.checkpoints/checkpoint.json", ))
Konfigurasi checkpoint yang tepat harus mengikuti versi CrewAI yang digunakan oleh proyek Anda.
Poin arsitektural penting adalah:
Checkpoint dulu, fallback kemudian.
Ini mencegah kegagalan model sementara memaksa pekerjaan yang sudah selesai untuk berjalan lagi.
Bagaimana Cara Mengimplementasikan Fallback Terbatas yang Sederhana?
Untuk tutorial, Anda masih dapat mendemonstrasikan fallback tingkat kru yang sederhana.
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
Perhatikan perbedaan penting:
Ini tidak mengklaim bahwa agen yang gagal telah diidentifikasi.
Ini adalah strategi fallback tingkat kru yang terbatas.
Untuk alur kerja kecil yang tanpa status, ini mungkin dapat diterima. Untuk alur kerja produksi dengan riset mahal, alat, atau efek samping, gunakan pemulihan berbasis checkpoint.
Bagaimana Cara Melacak Penggunaan Token CrewAI?
Pelacakan penggunaan harus menjadi bagian dari lapisan perutean, bukan pemikiran belakangan.
Di akhir run, periksa hasil 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)
Bidang penggunaan yang tersedia dapat bergantung pada versi CrewAI dan jalur eksekusi, jadi perlakukan objek hasil yang dikembalikan sebagai sumber kebenaran untuk versi yang Anda terapkan.
Catatan penggunaan produksi idealnya harus berisi:
job_idagentmodelinput_tokensoutput_tokenstotal_tokenslatency_msfallback_usedfallback_reasonstatuscreated_at
Ini memungkinkan Anda menjawab pertanyaan seperti:
Agen mana yang mengonsumsi sebagian besar anggaran?
Seberapa sering analis melakukan fallback?
Model mana yang memiliki latensi tertinggi?
Berapa biaya setiap alur kerja?
Bagaimana Cara Mengendalikan Biaya di Tingkat Agen?
Perutean multi-model paling berguna saat mencerminkan perbedaan beban kerja aktual.
Sebagai contoh:
Researcher→ high volume→ lower-cost modelAnalyst→ low volume→ stronger reasoning modelWriter→ medium volume→ general-purpose production model
Anda juga dapat membatasi biaya melalui konfigurasi agen.
Sebagai contoh:
max_iter=3
membatasi loop iterasi agen. Ini tidak boleh ditafsirkan sebagai batas keras tepat tiga panggilan API atau tiga anggaran token.
Kontrol tambahan termasuk:
- membatasi konteks tugas
- meringkas output perantara
- cache riset yang dapat diulang
- membatasi ukuran input maksimum
- membatasi token output maksimum jika didukung
- membatasi panggilan alat
- menetapkan anggaran per pengguna
- menetapkan anggaran per alur kerja
- melacak frekuensi fallback
Bagaimana Cara Memvalidasi Model Sebelum Deployment?
Jangan hardcode ID model selamanya.
Model dapat menjadi:
- tidak tersedia
- berganti nama
- ditinggalkan
- dibatasi
- berubah kapabilitas
- berubah harga
- tidak kompatibel dengan parameter yang digunakan aplikasi Anda
CometAPI menyediakan endpoint katalog model yang dapat di-query secara programatik, sementara direktori model publiknya dapat digunakan untuk penemuan model oleh manusia.
Pemeriksaan deployment dapat terlihat seperti:
curl -s \ https://api.cometapi.com/api/models \ -H "Authorization: Bearer $COMETAPI_KEY"
Lalu validasi bahwa ID model yang Anda konfigurasi ada sebelum deployment.
Sebagai contoh, proses CI Anda dapat memverifikasi:
gemini-3.7-flash → availableclaude-opus-5 → availablegpt-5.6 → available
Jangan jadikan pemeriksaan ketersediaan sebagai pengganti pengujian aplikasi. Model yang hadir dalam katalog tidak berarti setiap parameter, alat, atau format output yang digunakan oleh agen CrewAI Anda didukung.
Seperti Apa Contoh Lengkap CrewAI?
Berikut implementasi yang dikonsolidasikan:
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()
Peningkatan penting dibanding versi asli adalah bahwa kode tidak lagi secara keliru menyiratkan bahwa pengecualian mengidentifikasi agen yang tepat yang gagal.
Ini secara eksplisit merupakan implementasi fallback tingkat kru yang terbatas.
Untuk produksi, gabungkan kebijakan perutean yang sama dengan checkpointing CrewAI.
Bagaimana Cara Menjalankan Alur Kerja CrewAI?
Simpan file sebagai:
crewai_multi_model.py
Lalu jalankan:
python crewai_multi_model.py \ "Should a small SaaS add AI-generated meeting summaries?"
Respons yang berhasil akan berisi informasi serupa dengan:
{ "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>"}
Respons dan nilai penggunaan yang tepat bergantung pada input, perilaku model, versi CrewAI, dan jalur eksekusi.
Jika kesalahan yang dapat di-retry mengaktifkan rute fallback, objek selected_models menampilkan rute yang digunakan untuk eksekusi kru tersebut.
Bagaimana Sebaiknya Anda Merancang Perutean Model Produksi?
Kebijakan perutean produksi harus mempertimbangkan lebih dari sekadar kualitas model.
Fungsi keputusan yang berguna adalah:
Model Score =Quality+ Reliability+ Context Fit+ Tool Compatibility- Cost- Latency
Anda dapat mengimplementasikannya di beberapa tingkat.
Perutean berbasis biaya
Simple task → economical modelComplex task → premium model
Perutean berbasis latensi
Permintaan interaktif → model cepatAlur kerja latar belakang → model berkualitas lebih tinggi
Perutean berbasis keandalan
Model utama ↓kegagalan sementara ↓model fallback
Perutean berbasis tugas
Research → Model AAnalysis → Model BWriting → Model CCode → Model D
Pendekatan terakhir terutama natural untuk CrewAI karena kerangka kerja ini sudah memberi setiap agen peran yang berbeda.
Bagaimana Cara Membuat Fallback Aman?
Sistem fallback yang tangguh harus menegakkan empat aturan.
Jangan fallback pada kesalahan autentikasi
Jika kunci API tidak valid:
401
berubah model tidak akan memperbaiki masalah.
Jangan fallback pada permintaan yang salah format
Jika permintaan tidak valid:
400422
perbaiki permintaannya.
Jangan fallback tanpa batas
Tetapkan batas keras:
MAX_FALLBACK_ATTEMPTS = 2
Sistem fallback tanpa batas dapat menjadi loop retry yang mahal.
Jadikan model fallback kompatibel dengan permintaan
Model fallback harus mendukung fitur yang diperlukan oleh agen Anda.
Sebagai contoh, jika agen utama membutuhkan alat tertentu atau perilaku output terstruktur, fallback harus mendukung kontrak yang sama.
Kompatibel OpenAI tidak berarti kompatibel fitur.
Apa Kesalahan Paling Umum pada CrewAI + CometAPI?
| Gejala | Penyebab Kemungkinan | Perbaikan |
|---|---|---|
| 401 Unauthorized | Kunci API tidak valid atau hilang | Periksa COMETAPI_KEY; jangan fallback |
| 400 Bad Request | Parameter permintaan tidak valid | Koreksi permintaan |
| 404 Model Not Found | ID model usang | Periksa katalog model terbaru |
| 408 Timeout | Timeout permintaan sementara | Retry dengan kebijakan terbatas |
| 429 Rate Limited | Terlalu banyak permintaan | Backoff dan retry |
| 500–504 | Kegagalan server/gateway sementara | Gunakan fallback terbatas |
| Agen berulang kali retry | Retry tersembunyi dari SDK | Kendalikan max_retries |
| Tugas selesai berjalan lagi | Retry kru penuh | Gunakan pemulihan berbasis checkpoint |
| Model berbeda berperilaku berbeda | Kapabilitas model berbeda | Uji setiap model secara independen |
| Error konstruktor CrewAI tak terduga | Ketidakcocokan versi | Pin dan verifikasi versi CrewAI |
Bagaimana Cara Memisahkan Error CrewAI dari Error Model?
Perbedaan ini penting saat debugging.
Error konfigurasi
Missing API keyInvalid model IDInvalid base URLUnsupported parameter
Ini sebaiknya gagal cepat.
Error penyedia/API
401403404429500503
Ini membutuhkan penanganan berbeda tergantung status.
Error aplikasi
Agent output invalidTool returned malformed dataTask context missingSide effect failed
Ini tidak selalu diselesaikan dengan mengubah model.
Sistem agen yang matang karenanya harus memiliki penanganan terpisah untuk:
configuration ↓API transport ↓model execution ↓agent logic ↓tool execution ↓application side effects
Ini jauh lebih aman daripada:
except Exception: use_fallback()
Bagaimana Cara Melindungi Efek Samping Eksternal?
Fallback menjadi jauh lebih rumit ketika agen melakukan lebih dari sekadar menghasilkan teks.
Sebagai contoh, bayangkan agen yang:
- membuat catatan basis data
- mengirim email
- memanggil API eksternal
- memperbarui CRM
Jika model timeout setelah tindakan eksternal berhasil, menjalankan ulang seluruh kru dapat menduplikasi tindakan.
Gunakan:
- kunci idempoten
- checkpoint tugas
- batas transaksi
- ID eksekusi
- status tugas yang tahan lama
- konfirmasi efek samping eksplisit
Sebagai contoh:
job_id = crew_run_123task_id = writer_456
Simpan pengenal ini dengan operasi eksternal sehingga retry dapat menentukan apakah operasi sudah terjadi.
Bagaimana Cara Memantau Alur Kerja Multi-Model CrewAI?
Minimal, log:
workflow_idagentmodeltaskstart_timeend_timelatencystatusfallback_usedfallback_reasoninput_tokensoutput_tokenstotal_tokens
Jangan log:
API keysprivate credentialsfull sensitive promptsprivate user dataunredacted model output
Untuk setiap model, pantau:
Keandalan
success ratetimeout rate5xx ratefallback rate
Performa
p50 latencyp95 latencyp99 latency
Biaya
input tokensoutput tokenscost per taskcost per completed workflow
Kualitas
task success ratehuman evaluationstructured-output validitytool-call success
Ini mengubah perutean model dari preferensi hardcoded menjadi sistem rekayasa yang dapat diamati.
Bagaimana Cara Memilih Antara API Penyedia Langsung dan CometAPI?
Pilihan tergantung arsitektur Anda.
| Arsitektur | Kredensial | Pergantian Model | Integrasi Penyedia | Perutean Terpusat |
|---|---|---|---|---|
| API penyedia langsung | Banyak | Kustom | Tinggi | Tidak |
| Satu penyedia | Satu | Terbatas | Rendah | Terbatas |
| CrewAI + CometAPI | Satu kredensial CometAPI | Berbasis ID model | Lebih rendah | Ya |
Jika aplikasi Anda hanya membutuhkan satu penyedia dan kapabilitas native-nya, integrasi langsung dapat sepenuhnya masuk akal.
Jika aplikasi CrewAI Anda membutuhkan model dari beberapa penyedia dan Anda menginginkan satu lapisan akses, CometAPI menjadi lebih menarik.
Poin pentingnya adalah CometAPI tidak menggantikan CrewAI.
Sebaliknya:
CrewAIAgent orchestration ↓CometAPIModel access ↓Multiple models
Setiap lapisan memiliki tanggung jawab yang berbeda.
Bagaimana Arsitektur Ini Menskala?
Setelah kebijakan perutean dipisahkan dari definisi agen, menambahkan model lain tidak memerlukan pembangunan ulang seluruh aplikasi.
Sebagai contoh:
PRIMARY_MODELS = { "researcher": "gemini-3.7-flash", "analyst": "claude-opus-5", "writer": "gpt-5.6", "coder": "YOUR_CODE_MODEL",}
Arsitektur yang sama kemudian dapat mendukung:
Agen risetAgen analisisAgen codingAgen reviewAgen penulisanAgen pemeriksa fakta
Setiap agen dapat memiliki model yang berbeda sementara berbagi lapisan akses CometAPI yang sama.
Langkah berikutnya adalah membuat perutean dinamis.
Alih-alih:
"analyst": "claude-opus-5"
Anda pada akhirnya dapat menggunakan:
select_model( task="analysis", budget=budget, latency_target=latency_target,)
Sistem perutean kemudian dapat memilih dari model yang disetujui berdasarkan kebutuhan aplikasi.
Apa Arsitektur Produksi Terbaik untuk CrewAI + CometAPI?
Untuk alur kerja kecil:
User Input ↓CrewAI ↓CometAPI ↓Models
Untuk produksi:
┌───────────────┐ │ Model Catalog │ └───────┬───────┘ │ ▼User → CrewAI → Routing Policy → CometAPI │ │ │ │ │ ├── Gemini │ │ ├── Claude │ │ └── GPT │ │ │ ▼ │ Cost / Quality / │ Latency / Policy │ ▼ Checkpoints │ ▼ Usage Tracking
Komponen produksi kunci adalah:
- Daftar model yang diizinkan (allowlist)
- Perutean per agen
- Retry terbatas
- Checkpointing tugas
- Pelacakan penggunaan
- Kontrol biaya
- Pengujian kompatibilitas model
- Observabilitas
- Efek samping yang idempoten
Arsitektur itu secara substansial lebih tangguh daripada sekadar menambahkan try/except di sekitar crew.kickoff().
Satu Kunci CometAPI, Model Berbeda, Peran Agen yang Lebih Jelas
Cara paling berguna untuk memikirkan CrewAI dan CometAPI bersama adalah sebagai dua lapisan yang saling melengkapi.
CrewAI mendefinisikan apa yang dilakukan agen.
CometAPI mendefinisikan bagaimana agen-agen tersebut mengakses model.
Pemisahan itu memungkinkan penetapan model cepat ke agen riset dengan volume tinggi, model penalaran yang lebih kuat ke agen analisis, dan model serbaguna ke penulis akhir tanpa mempertahankan integrasi penyedia terpisah di dalam alur kerja.
Implementasi paling sederhana menggunakan satu kunci CometAPI dan satu URL dasar yang kompatibel dengan OpenAI:
https://api.cometapi.com/v1
Untuk produksi, bawa arsitektur satu langkah lebih jauh: simpan perutean model dalam konfigurasi, validasi ketersediaan model sebelum deployment, gunakan fallback terbatas hanya untuk kegagalan sementara, checkpoint tugas yang selesai, dan catat metadata model serta penggunaan untuk setiap run.
Itu memberi Anda pola yang jauh lebih tahan lama daripada sekadar menghubungkan CrewAI ke satu LLM:
CrewAI mengorkestrasi agen. CometAPI memusatkan akses model. ID model mengontrol perutean. Checkpoint melindungi pekerjaan yang selesai. Pelacakan penggunaan mengendalikan biaya.
Pertanyaan yang Sering Diajukan
Bisakah CrewAI menggunakan beberapa model AI dalam kru yang sama?
Ya. Tetapkan konfigurasi LLM yang berbeda untuk setiap agen CrewAI. Setiap konfigurasi dapat menentukan modelnya sendiri sambil menggunakan kunci API dan URL dasar CometAPI yang sama.
Bisakah CrewAI terhubung ke API yang kompatibel dengan OpenAI?
Ya. Konfigurasi LLM CrewAI mendukung base_url khusus dan kunci API untuk endpoint yang kompatibel dengan OpenAI.
Dengan CometAPI, URL dasarnya adalah:
https://api.cometapi.com/v1
Apakah saya memerlukan kunci API terpisah untuk GPT, Claude, dan Gemini?
Saat mengakses model-model ini melalui CometAPI, aplikasi dapat menggunakan kredensial dan endpoint CometAPI alih-alih menerapkan kredensial penyedia terpisah di setiap agen CrewAI.
Apakah satu kunci API berarti model memiliki kapabilitas yang identik?
Tidak. Antarmuka API dapat disatukan sementara kapabilitas model tetap berbeda. Jendela konteks, dukungan alat, parameter, perilaku output, latensi, dan harga dapat bervariasi menurut model.
Haruskah saya me-retry seluruh alur kerja CrewAI ketika satu model gagal?
Hanya untuk alur kerja sederhana tanpa status. Retry kru penuh dapat mengulang tugas yang selesai dan meningkatkan biaya. Untuk alur kerja produksi, checkpoint tugas yang selesai dan lanjutkan dari bagian yang gagal jika memungkinkan.
Fungsionalitas checkpointing CrewAI saat ini dirancang untuk mempertahankan status eksekusi dan melanjutkan setelah kegagalan.
Haruskah setiap pengecualian CrewAI memicu fallback model?
Tidak. Autentikasi, permintaan yang salah format, ID model tidak valid, dan parameter yang tidak didukung umumnya memerlukan perubahan konfigurasi daripada model yang berbeda.
Fallback lebih baik dicadangkan untuk kegagalan sementara yang terbatas seperti timeout, batas laju, dan respons 5xx sementara.
Bagaimana cara saya melacak biaya setiap agen CrewAI?
Catat nama agen, ID model, penggunaan token, latensi, status eksekusi, dan informasi fallback untuk setiap tugas. Gunakan data yang dihasilkan untuk menghitung biaya per agen dan alur kerja.
Bisakah saya mengubah model yang ditetapkan ke agen secara dinamis?
Ya. Simpan ID model dalam konfigurasi perutean daripada menanamkannya langsung dalam definisi agen. Aplikasi Anda kemudian dapat memilih model berdasarkan biaya, latensi, jenis tugas, atau ketersediaan.
Apakah CometAPI merupakan pengganti CrewAI?
Tidak. Mereka beroperasi di lapisan yang berbeda. CrewAI mengorkestrasi agen dan tugas, sementara CometAPI menyediakan lapisan akses model yang terpadu.
Di mana saya dapat menemukan model CometAPI saat ini?
Gunakan Direktori Model CometAPI untuk penemuan model oleh manusia dan API model untuk validasi secara programatik. Halaman mulai cepat CometAPI saat ini mencantumkan 500+ model di kategori teks, gambar, video, dan audio.
