CometAI ile çoklu ajanlı bir sistem kurmak, farklı ajanların farklı modeller kullanabilmesiyle daha ilgi çekici hale gelir.
Bir araştırmacı hızlı ve ekonomik bir modelden fayda sağlayabilir, bir analist daha güçlü bir akıl yürütme modeline ihtiyaç duyabilir ve bir yazar yüksek kaliteli uzun biçimli üretim için optimize edilmiş bir model gerektirebilir. Geleneksel olarak, bu ajanları farklı sağlayıcılara bağlamak, ayrı API kimlik bilgilerini, uç noktaları, SDK’ları, faturalandırma sistemlerini ve sağlayıcıya özgü yapılandırmayı yönetmek anlamına gelir.
Daha temiz bir mimari yaklaşım, ajanları ve iş akışını CrewAI’nin yönetmesine, model erişimini ise CometAPI’nin yönetmesine izin vermektir.
CometAPI, https://api.cometapi.com/v1 adresinde OpenAI uyumlu bir uç nokta sağlar; böylece uygulamalar birden fazla sağlayıcıdaki modellere istekleri ortak bir API arayüzü üzerinden yönlendirebilir. Mevcut hızlı başlangıç dokümantasyonu ayrıca API anahtarını ve temel URL’yi değiştirerek standart OpenAI Python SDK’sının kullanımını desteklemektedir.
Bu eğitimde, üç ajanlı bir CrewAI iş akışı oluşturacaksınız:
- Araştırma için: Gemini 3.7 Flash
- Analiz için: Claude Opus 5
- Nihai yazım için: GPT-5.6
- Tek bir CometAPI API anahtarı
- Tek bir API temel URL’si
- Ajan başına model yapılandırması
- Geçici hatalar için sınırlı geri dönüş (fallback)
- Üretim kurtarma için CrewAI kontrol noktaları (checkpointing)
- Token ve yürütme kullanım takibi
- Sunucu tarafında model doğrulaması
Önemli mimari sınır basittir:
CrewAI ajan orkestrasyonunu üstlenir. CometAPI model erişimini yönetir. Model kimlikleri yönlendirmeyi belirler.
CrewAI Çoklu Ajan Model Yönlendirme Nedir?
CrewAI; ajanlar, görevler, ekipler ve çoklu ajanlı iş akışları oluşturmak için bir Python çerçevesidir. Her ajanın kendi LLM yapılandırması olabilirken, Crew bu ajanların görevleri nasıl yürüttüğünü ve bağlamı nasıl paylaştığını koordine eder.
CrewAI’nin mevcut LLM yapılandırması, özel OpenAI uyumlu uç noktalar da dahil olmak üzere, model, api_key ve base_url ayarlarını açıkça destekler.
Bu, çok modelli bir mimariyi yalın hale getirir:
CometAPI │ https://api.cometapi.com/v1 │ ┌───────────────────┼───────────────────┐ │ │ │ Researcher Analyst Writer │ │ │ Gemini 3.7 Flash Claude Opus 5 GPT-5.6
Ajanlar mantıksal olarak ayrı kalır, ancak model erişimleri merkezileştirilir.
Bu, tüm modellerin birbirinin yerine geçebilir olduğu anlamına gelmez. OpenAI uyumlu bir API, ortak bir istek arayüzü sağlar; ancak aynı bağlam sınırlarını, araç desteğini, akıl yürütme denetimlerini, çıktı davranışını, gecikmeyi veya fiyatlandırmayı garanti etmez.
Bu ayrım, üretim yönlendirmesi tasarlanırken önemlidir.
Neden CrewAI ile CometAPI Kullanılmalı?
Asıl avantaj, CrewAI’nin birdenbire çok sağlayıcılı bir çerçeveye dönüşmesi değildir. CrewAI zaten birden fazla LLM sağlayıcısını destekler.
Avantaj, model erişiminin tek bir API katmanının arkasında konsolide edilebilmesidir.
Birleşik bir API katmanı olmadan, üç ajanlı bir iş akışı şöyle görünebilir:
| Ajan | Sağlayıcı | Kimlik Bilgisi | Entegrasyon |
|---|---|---|---|
| Araştırmacı | Google API anahtarı | Sağlayıcıya özgü | |
| Analist | Anthropic | Anthropic API anahtarı | Sağlayıcıya özgü |
| Yazar | OpenAI | OpenAI API anahtarı | Sağlayıcıya özgü |
CometAPI ile:
| Ajan | Model | Kimlik Bilgisi | Uç Nokta |
|---|---|---|---|
| Araştırmacı | Gemini 3.7 Flash | CometAPI anahtarı | CometAPI |
| Analist | Claude Opus 5 | CometAPI anahtarı | CometAPI |
| Yazar | GPT-5.6 | CometAPI anahtarı | CometAPI |
CometAPI’nin mevcut hızlı başlangıç dokümantasyonu, uç noktasını OpenAI API temel URL’sine bire bir ikame olarak tanımlar ve aynı hizmet üzerinden birden çok sağlayıcıdan modeller listeler.
Bu, uygulamaya faydalı bir ayrım sağlar:
CrewAI
- Ajan rollerini tanımlar
- Görevleri tanımlar
- Bağlamı iletir
- Yürütmeyi kontrol eder
- Ajan yinelemelerini yönetir
- Ekip düzeyinde orkestrasyonu üstlenir
CometAPI
- Ortak bir model erişim katmanı sağlar
- API kimlik doğrulamayı merkezileştirir
- Model kimlikleri üzerinden yönlendirme sağlar
- Uygulamaya tek bir API uç noktası verir
- Merkezileştirilmiş kullanım ve faturalandırma görünürlüğü sağlar
Bu CrewAI İş Akışı Ne Üretecek?
Örnek, üç ardışık ajandan oluşur.
| CrewAI Ajanı | Birincil Model | Geri Dönüş | Rol |
|---|---|---|---|
| Pazar Araştırmacısı | gemini-3.7-flash | gpt-5.6 | Gerçekleri ve araştırmayı toplar |
| Ürün Analisti | claude-opus-5 | gpt-5.6 | Kanıtları ve ödünleri sentezler |
| Teknik Yazar | gpt-5.6 | gemini-3.7-flash | Nihai karar notunu üretir |
Bu, bir kıyaslama sıralaması değil, örnek bir yönlendirme politikasıdır.
Ajanınız için doğru model şunlara bağlıdır:
- görev karmaşıklığı
- gerekli bağlam uzunluğu
- araç kullanımı
- yapılandırılmış çıktı gereksinimleri
- gecikme
- güvenilirlik
- token maliyeti
- çıktı kalitesi
- uygulamaya özgü değerlendirme sonuçları
Faydalı bir kural şudur:
Ajanın yaptığı işe uygun bir model seçin; yalnızca geldiği sağlayıcıya göre değil.
Her CrewAI Ajanı Hangi Modeli Kullanmalı?
Bu örnek için model ataması, basit bir maliyet–yetkinlik stratejisini izler.
Araştırmacı: Gemini 3.7 Flash
Araştırma genellikle nispeten büyük miktarda bilgiyi işlemeyi ve kompakt bir ara sonuç üretmeyi içerir.
Bu nedenle, yüksek hacimli araştırma görevleri için hızlı bir model faydalı olabilir.
"researcher": "gemini-3.7-flash"
Analist: Claude Opus 5
Analistin rolü daha dardır ancak daha yoğun muhakeme gerektirir. Araştırma çıktısını alır ve bunu bir öneriye dönüştürür.
"analyst": "claude-opus-5"
Yazar: GPT-5.6
Son ajan, araştırma ve analizi geliştirici odaklı bir karar notuna dönüştürür.
"writer": "gpt-5.6"
Önemli olan, tam olarak bu üç atama değildir. Uygulamanız yönlendirme politikasını sabitlemeden önce aday modelleri temsilci görevlerle değerlendirmelidir.
Başlamadan Önce Ne Gerekiyor?
Şunlara ihtiyacınız var:
- Python 3.10+
- CrewAI
- OpenAI Python SDK uyumluluğu
python-dotenv- Bir CometAPI API anahtarı
- Kullanmayı planladığınız model kimlikleri
CometAPI’nin mevcut Python entegrasyonu OpenAI uyumlu API’yi destekler ve resmi CometAPI Python paketi, COMETAPI_KEY ve COMETAPI_BASE_URL değerlerini ortama dayalı yapılandırma seçenekleri olarak belgelendirir.
Standart uç nokta:
https://api.cometapi.com/v1
Dağıtımdan önce, seçtiğiniz model kimliklerinin şu anda mevcut olduğunu ve CrewAI iş yükünüzün gerektirdiği uç noktayı ve parametreleri desteklediğini doğrulayın. Model katalogları ve fiyatlandırmalar değişebilir.
CrewAI ve Bağımlılıklar Nasıl Kurulur?
Yeni bir Python ortamı oluşturun:
python -m venv .venv
Etkinleştirin:
source .venv/bin/activate
Windows’ta:
.venv\Scripts\Activate.ps1
Ardından bağımlılıkları yükleyin:
pip install "crewai[openai]" openai python-dotenv
Aşağıdaki geri dönüş (fallback) uygulaması OpenAI SDK istisna sınıflarını doğrudan içe aktardığı için openai paketini açıkça eklemek kasıtlıdır.
Üretimde, test ettiğiniz sürümleri sabitleyin; süresiz olarak en güncel sürümlere güvenmeyin.
Örneğin:
crewai==YOUR_TESTED_VERSIONopenai==YOUR_TESTED_VERSIONpython-dotenv==YOUR_TESTED_VERSION
CrewAI’nin LLM katmanı aktif olarak gelişmektedir; bu nedenle, tam kurucu ve sağlayıcı yapılandırmasını uygulamanızda kullanılan CrewAI sürümüne karşı kontrol etmelisiniz. Mevcut CrewAI dokümantasyonu, özel bir base_url ve API anahtarı ile bir LLM yapılandırmayı desteklemektedir.
CometAPI API Anahtarı Nasıl Yapılandırılır?
Bir .env dosyası oluşturun:
COMETAPI_KEY=your_cometapi_keyCOMETAPI_BASE_URL=https://api.cometapi.com/v1
Bu değerleri Python’da yükleyin:
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",)
.env dosyasını asla Git’e yüklemeyin.
.gitignore dosyasına ekleyin:
.env.venv/__pycache__/
API anahtarı sunucu tarafı kimlik bilgisi olarak kalmalıdır. CometAPI’nin mevcut hızlı başlangıç önerisi de anahtarın kaynak kod yerine ortam değişkenlerinde saklanmasını tavsiye eder.
CrewAI CometAPI’ye Nasıl Bağlanır?
CrewAI’nin LLM nesnesi bir model adı, API anahtarı ve özel temel URL alabilir.
Bir yardımcı işlev oluşturun:
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, )
Bu, aynı yapılandırmayı her ajanın içinde ayrı ayrı gömmekten daha uygundur.
Artık her ajanın yalnızca bir model kimliğine ihtiyacı var:
research_llm = cometapi_llm("gemini-3.7-flash")analysis_llm = cometapi_llm("claude-opus-5")writing_llm = cometapi_llm("gpt-5.6")
Neden max_retries=0 Ayarlanır?
Sebep, geri dönüş kontrolüdür.
Temeldeki LLM istemcisi otomatik olarak yeniden denemeler yaparsa ve uygulamanız da geri dönüş uygularsa, tek bir başarısızlık, geri dönüş mantığınız çalışmadan önce birkaç gizli isteğe dönüşebilir.
Açık yönlendirmeli bir eğitim için, yeniden denemeye veya modeli değiştirmeye ne zaman karar verileceğine uygulamanın karar vermesi daha temizdir.
Model Yönlendirme Politikası Nasıl Tanımlanır?
Yönlendirmeyi istemlerinizin dışında tutun:
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",}
Bu, net bir yapılandırma sınırı oluşturur.
Daha sonra aynı eşlemeyi aşağıdakilere taşıyabilirsiniz:
- ortam yapılandırması
- YAML
- JSON
- bir veritabanı
- özellik bayrakları
- dahili bir model yönlendirme hizmeti
ve bunu yaparken ajan istemlerini yeniden yazmanız gerekmez.
Üç CrewAI Ajanı Nasıl Kurulur?
Ajan başına bir LLM nesnesi oluşturun.
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
Model ataması artık ajanın rol tanımından tamamen bağımsızdır.
Model yönlendirmeyi pratik kılan budur.
Ajanlar Sıralı Görevlerle Nasıl Bağlanır?
Üç görev oluşturun:
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
Bağımlılık zinciri şöyledir:
Topic ↓Research ↓Analysis ↓Final memo
Analist, araştırma görevinin çıktısını alır; yazar ise hem araştırma hem analiz bağlamını alır.
Ekip (Crew) Nasıl Kurulur?
Ajanları ve görevleri birleştirin:
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, )
Artık model yönlendirme tamamen yapılandırma odaklıdır.
Şunu değiştirmek:
"researcher": "gemini-3.7-flash"
desteklenen başka bir modele geçmek anlamına gelir; araştırma istemini veya görev tanımını değiştirmeniz gerekmez.
CrewAI Model Geri Dönüşü (Fallback) Nasıl Olmalı?
Burası, üretim odaklı bir uygulamada daha fazla özen gerektiren kısımdır.
Yaygın bir hata şudur:
Herhangi bir hata ↓Model değiştir
Bu fazla agresiftir.
Örneğin, şu hatalar genel olarak model geri dönüşünü tetiklememelidir:
400 Bad Request401 Unauthorized403 Forbidden404 Not Found422 Validation Error
Modelleri değiştirmek, geçersiz bir API anahtarını veya hatalı bir isteği düzeltmez.
Geri dönüş, şu geçici hatalar için daha uygundur:
408 Request Timeout429 Rate Limit500 Internal Server Error502 Bad Gateway503 Service Unavailable504 Gateway TimeoutConnection errorTimeout
Bu nedenle geri dönüş politikası şu olmalıdır:
Yalnızca sınırlı, geçici hatalarda ve yalnızca geri dönüş modelinin aynı istek sözleşmesini desteklediği durumlarda yeniden deneyin veya model değiştirin.
Yeniden Denenebilir Hatalar Nasıl Tespit Edilir?
OpenAI SDK’nın hata sınıflarını kullanabilirsiniz:
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
Bu, özellikle 408 ve 429 dışındaki 400 düzeyi yapılandırma hatalarını hariç tutar.
Tüm Ekip Mi Yeniden Denenmeli, Yoksa Sadece Başarısız Ajan Mı?
İki farklı geri dönüş stratejisi vardır.
Ekip düzeyinde geri dönüş
En basit uygulama:
Ekip başlat ↓başarısızlık ↓yönlendirmeyi değiştir ↓ekibi tekrar çalıştır
Bu anlaşılması kolaydır, ancak tamamlanan görevleri tekrar ettirebilir.
Örneğin:
Araştırma → tamamlandıAnaliz → tamamlandıYazar → başarısız
Tam bir kickoff() yeniden denemesi şunları çalıştırabilir:
Araştırma → tekrarAnaliz → tekrarYazar → geri dönüş
Bu durum artırır:
- token kullanımını
- gecikmeyi
- API maliyetini
- potansiyel yan etkileri
Görev düzeyinde kurtarma
Üretim iş akışı bunun yerine tamamlanan çalışmaları kontrol noktalarına kaydetmelidir:
Araştırma ↓kontrol noktası ↓Analiz ↓kontrol noktası ↓Yazar başarısız ↓geri dönüş ile yazarı yeniden dene
CrewAI, yürütme durumunu kaydeden ve bir başarısızlıktan sonra bir koşuyu sürdürmenize izin veren kontrol noktası özelliği sağlar. Belgelendirilmiş kontrol noktası davranışı, tamamlanan görevleri atlar ve ekibi kaydedilen durumdan itibaren devam ettirir.
Bu, pahalı veya yan etki üreten iş akışları için daha iyi mimaridir.
CrewAI Kontrol Noktaları Nasıl Eklenir?
Üretim iş akışları için ekipte kontrol noktalarını etkinleştirin:
crew = Crew( agents=[researcher, analyst, writer], tasks=[ research_task, analysis_task, writing_task, ], process=Process.sequential, checkpoint=True, verbose=True,)
CrewAI’nin kontrol noktası sistemi, görev tamamlandıktan sonra yürütme durumunu kalıcı hale getirebilir ve ekibi bir kontrol noktasından geri yükleyebilir.
Örneğin, geri yüklenen bir koşu şunu kullanabilir:
from crewai import CheckpointConfigresult = crew.kickoff( from_checkpoint=CheckpointConfig( restore_from="./.checkpoints/checkpoint.json", ))
Tam kontrol noktası yapılandırması, projenizde kullanılan CrewAI sürümüne göre düzenlenmelidir.
Önemli mimari nokta şudur:
Önce kontrol noktası, sonra geri dönüş.
Bu, geçici bir model hatasının, pahalı tamamlanmış işleri tekrar çalıştırmaya zorlamasını engeller.
Basit ve Sınırlı Bir Geri Dönüş Nasıl Uygulanır?
Bir eğitim için, yine basit bir ekip düzeyinde geri dönüş gösterebilirsiniz.
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
Önemli ayrımı fark edin:
Bu, başarısız olan ajanın tanımlandığını iddia etmez.
Bu, sınırlı bir ekip düzeyinde geri dönüş stratejisidir.
Küçük ve durumsuz iş akışları için kabul edilebilir olabilir. Araştırması pahalı, araç kullanan veya yan etkileri olan üretim iş akışlarında, kontrol noktası tabanlı kurtarma kullanın.
CrewAI Token Kullanımı Nasıl Takip Edilir?
Kullanım takibi, yönlendirme katmanının bir parçası olmalıdır; sonradan düşünülmemelidir.
Çalışmanın sonunda, CrewAI sonucunu inceleyin:
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)
Mevcut kullanım alanları, CrewAI sürümüne ve yürütme yoluna bağlı olarak değişebilir; bu nedenle, dağıttığınız sürüm için döndürülen sonuç nesnesini tek doğru kaynak olarak kabul edin.
Üretim kullanım kaydı ideal olarak şunları içermelidir:
job_idagentmodelinput_tokensoutput_tokenstotal_tokenslatency_msfallback_usedfallback_reasonstatuscreated_at
Şu soruları yanıtlamanızı sağlar:
Hangi ajan bütçenin çoğunu tüketiyor?
Analist ne sıklıkla geri dönüş yapıyor?
Hangi modelin gecikmesi en yüksek?
Her iş akışı ne kadara mal oluyor?
Maliyeti Ajan Düzeyinde Nasıl Kontrol Edersiniz?
Çok modelli yönlendirme, gerçek iş yükü farklılıklarını yansıttığında en kullanışlıdır.
Örneğin:
Araştırmacı→ yüksek hacim→ daha düşük maliyetli modelAnalist→ düşük hacim→ daha güçlü akıl yürütme modeliYazar→ orta hacim→ genel amaçlı üretim modeli
Ayrıca ajanın yapılandırmasıyla maliyeti sınırlayabilirsiniz.
Örneğin:
max_iter=3
ajanın yineleme döngüsünü sınırlandırır. Bu, tam olarak üç API çağrısı veya üç token bütçesi gibi katı bir limit olarak yorumlanmamalıdır.
Ek kontroller şunları içerir:
- görev bağlamını sınırlama
- ara çıktıları özetleme
- tekrarlanabilir araştırmaları önbelleğe alma
- maksimum girdi boyutunu sınırlama
- desteklendiğinde maksimum çıktı token’larını sınırlama
- araç çağrılarını kısıtlama
- kullanıcı başına bütçeler belirleme
- iş akışı başına bütçeler belirleme
- geri dönüş sıklığını takip etme
Modelleri Dağıtımdan Önce Nasıl Doğrularsınız?
Model kimliklerini sonsuza dek sabitlemeyin.
Bir model şu hale gelebilir:
- kullanılamaz
- yeniden adlandırılmış
- kullanım dışı bırakılmış
- kısıtlanmış
- yetenekleri değişmiş
- fiyatlandırması değişmiş
- uygulamanızın kullandığı bir parametreyle uyumsuz
CometAPI, programatik olarak sorgulanabilen bir model katalog uç noktası sağlar; halka açık model dizini ise insan odaklı model keşfi için kullanılabilir.
Bir dağıtım kontrolü şu şekilde olabilir:
curl -s \ https://api.cometapi.com/api/models \ -H "Authorization: Bearer $COMETAPI_KEY"
Daha sonra, yapılandırdığınız model kimliklerinin dağıtımdan önce mevcut olduğunu doğrulayın.
Örneğin, CI süreciniz şunları doğrulayabilir:
gemini-3.7-flash → availableclaude-opus-5 → availablegpt-5.6 → available
Kullanılabilirlik kontrollerini uygulama testlerinin yerine koymayın. Bir modelin katalogda bulunması, CrewAI ajanınızın kullandığı her parametre, araç veya çıktı biçimini desteklediği anlamına gelmez.
Tam CrewAI Örneği Nasıl Görünür?
Konsolide bir uygulama aşağıdadır:
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()
Orijinal sürüme kıyasla önemli iyileştirme, kodun bir istisnanın tam olarak başarısız olan ajanı belirttiğini iddia etmemesidir.
Bu, açıkça sınırlı bir ekip düzeyinde geri dönüş uygulamasıdır.
Üretimde, aynı yönlendirme politikasını CrewAI kontrol noktalarıyla birleştirin.
CrewAI İş Akışı Nasıl Çalıştırılır?
Dosyayı şu adla kaydedin:
crewai_multi_model.py
Ardından çalıştırın:
python crewai_multi_model.py \ "Should a small SaaS add AI-generated meeting summaries?"
Başarılı bir yanıt aşağıdakine benzer bilgiler içerecektir:
{ "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>"}
Kesin yanıt ve kullanım değerleri, girdiye, model davranışına, CrewAI sürümüne ve yürütme yoluna bağlıdır.
Yeniden denenebilir bir hata geri dönüş rotasını etkinleştirirse, selected_models nesnesi o ekip yürütmesi için kullanılan rotayı gösterir.
Üretim Model Yönlendirmesi Nasıl Tasarlanmalı?
Bir üretim yönlendirme politikası, model kalitesinden daha fazlasını dikkate almalıdır.
Faydalı bir karar fonksiyonu:
Model Score =Quality+ Reliability+ Context Fit+ Tool Compatibility- Cost- Latency
Bunu birkaç düzeyde uygulayabilirsiniz.
Maliyete dayalı yönlendirme
Basit görev → ekonomik modelKarmaşık görev → premium model
Gecikmeye dayalı yönlendirme
Etkileşimli istek → hızlı modelArka plan iş akışı → daha yüksek kaliteli model
Güvenilirliğe dayalı yönlendirme
Birincil model ↓geçici hata ↓geri dönüş modeli
Göreve dayalı yönlendirme
Araştırma → Model AAnaliz → Model BYazım → Model CKod → Model D
Son yaklaşım, CrewAI için özellikle doğaldır; çünkü çerçeve zaten her ajana farklı bir rol verir.
Geri Dönüş Nasıl Güvenli Hale Getirilir?
Sağlam bir geri dönüş sistemi dört kuralı zorlamalıdır.
Kimlik doğrulama hatalarında geri dönüş yapmayın
API anahtarı geçersizse:
401
modelleri değiştirmek sorunu çözmez.
Hatalı isteklerde geri dönüş yapmayın
İstek geçersizse:
400422
modeli değiştirmek yerine isteği düzeltin.
Sonsuz geri dönüş yapmayın
Sabit bir sınır belirleyin:
MAX_FALLBACK_ATTEMPTS = 2
Sınırı olmayan bir geri dönüş sistemi, pahalı bir yeniden deneme döngüsüne dönüşebilir.
Geri dönüş modellerini istek uyumlu hale getirin
Geri dönüş modeli, ajanınızın gerektirdiği özellikleri desteklemelidir.
Örneğin, birincil ajan belirli bir aracı veya yapılandırılmış çıktı davranışını gerektiriyorsa, geri dönüş modeli de aynı sözleşmeyi desteklemelidir.
OpenAI uyumluluğu, özellik uyumluluğu anlamına gelmez.
En Yaygın CrewAI + CometAPI Hataları Nelerdir?
| Belirti | Muhtemel Neden | Çözüm |
|---|---|---|
| 401 Unauthorized | Geçersiz veya eksik API anahtarı | COMETAPI_KEY’i kontrol edin; geri dönüş yapmayın |
| 400 Bad Request | Geçersiz istek parametreleri | İsteği düzeltin |
| 404 Model Not Found | Eski model kimliği | Güncel model kataloğunu kontrol edin |
| 408 Timeout | Geçici istek zaman aşımı | Sınırlı politikayla yeniden deneyin |
| 429 Rate Limited | Çok fazla istek | Geri çekilin ve yeniden deneyin |
| 500–504 | Geçici sunucu/geçit hatası | Sınırlı geri dönüş kullanın |
| Ajan sürekli yeniden deniyor | Gizli SDK yeniden denemeleri | max_retries’i kontrol edin |
| Tamamlanan görevler yeniden çalışıyor | Tüm ekibin yeniden denemesi | Kontrol noktası tabanlı kurtarma kullanın |
| Farklı model farklı davranıyor | Model yetenekleri farklı | Her modeli bağımsız test edin |
| Beklenmeyen CrewAI kurucu hatası | Sürüm uyumsuzluğu | CrewAI sürümünü sabitleyin ve doğrulayın |
CrewAI Hatalarını Model Hatalarından Nasıl Ayırırsınız?
Bu ayrım hata ayıklarken önemlidir.
Yapılandırma hataları
Eksik API anahtarıGeçersiz model kimliğiGeçersiz temel URLDesteklenmeyen parametre
Bunlar hızlıca başarısız olmalıdır.
Sağlayıcı/API hataları
401403404429500503
Duruma bağlı olarak farklı işlemler gerektirir.
Uygulama hataları
Ajan çıktısı geçersizAraç hatalı veri döndürdüGörev bağlamı eksikYan etki başarısız oldu
Bunlar modelleri değiştirerek mutlaka çözülmez.
Olgun bir ajan sistemi şu alanlar için ayrı işleme sahip olmalıdır:
yapılandırma ↓API taşımacılığı ↓model yürütmesi ↓ajan mantığı ↓araç yürütmesi ↓uygulama yan etkileri
Bu, genel bir:
except Exception: use_fallback()
yaklaşımından çok daha güvenlidir.
Harici Yan Etkileri Nasıl Korursunuz?
Ajanlar metin üretmenin ötesinde işler yaptığında geri dönüş önemli ölçüde karmaşıklaşır.
Örneğin, bir ajanın:
- bir veritabanı kaydı oluşturduğunu
- bir e-posta gönderdiğini
- harici bir API çağırdığını
- bir CRM’i güncellediğini
varsayın. Model, harici işlem başarılı olduktan sonra zaman aşımına uğrarsa, tüm ekibi yeniden çalıştırmak işlemi çoğaltabilir.
Şunları kullanın:
- idempotency anahtarları
- görev kontrol noktaları
- işlem sınırları
- yürütme kimlikleri
- kalıcı görev durumu
- açık yan etki onayı
Örneğin:
job_id = crew_run_123task_id = writer_456
Bu tanımlayıcıları harici işlemlerle birlikte saklayın; böylece bir yeniden deneme, işlemin zaten gerçekleşip gerçekleşmediğini belirleyebilir.
Çok Modelli CrewAI İş Akışları Nasıl İzlenir?
En azından şunları günlükleyin:
workflow_idagentmodeltaskstart_timeend_timelatencystatusfallback_usedfallback_reasoninput_tokensoutput_tokenstotal_tokens
Şunları günlüklemeyin:
API anahtarlarıözel kimlik bilgileriözel hassas istemlerözel kullanıcı verileridüzenlenmemiş model çıktısı
Her model için şu alanları izleyin:
Güvenilirlik
başarı oranızaman aşımı oranı5xx oranıgeri dönüş oranı
Performans
p50 gecikmep95 gecikmep99 gecikme
Maliyet
girdi token’larıçıktı token’larıgörev başına maliyettamamlanan iş akışı başına maliyet
Kalite
görev başarı oranıinsan değerlendirmesiyapılandırılmış çıktı geçerliliğiaraç çağrısı başarısı
Bu, model yönlendirmeyi sabit kodlanmış bir tercihten gözlemlenebilir bir mühendislik sistemine dönüştürür.
Doğrudan Sağlayıcı API’leri ile CometAPI Arasında Nasıl Seçim Yaparsınız?
Seçim mimarinize bağlıdır.
| Mimari | Kimlik Bilgileri | Model Değiştirme | Sağlayıcı Entegrasyonu | Merkezileştirilmiş Yönlendirme |
|---|---|---|---|---|
| Doğrudan sağlayıcı API’leri | Birden fazla | Özel | Yüksek | Hayır |
| Tek sağlayıcı | Bir | Sınırlı | Düşük | Sınırlı |
| CrewAI + CometAPI | Tek CometAPI kimliği | Model kimliği tabanlı | Daha düşük | Evet |
Uygulamanız sadece bir sağlayıcıya ve onun yerel yeteneklerine ihtiyaç duyuyorsa, doğrudan entegrasyon gayet mantıklı olabilir.
CrewAI uygulamanız birden fazla sağlayıcıdan modellere ihtiyaç duyuyor ve tek bir erişim katmanı istiyorsanız, CometAPI daha cazip hale gelir.
Önemli nokta, CometAPI’nin CrewAI’nin yerine geçmediğidir.
Bunun yerine:
CrewAIAjan orkestrasyonu ↓CometAPIModel erişimi ↓Birden çok model
Her katmanın farklı bir sorumluluğu vardır.
Bu Mimari Nasıl Ölçeklenir?
Yönlendirme politikası ajan tanımlarından ayrıldıktan sonra, başka bir model eklemek tüm uygulamayı yeniden oluşturmayı gerektirmez.
Örneğin:
PRIMARY_MODELS = { "researcher": "gemini-3.7-flash", "analyst": "claude-opus-5", "writer": "gpt-5.6", "coder": "YOUR_CODE_MODEL",}
Aynı mimari şu ajanları destekleyebilir:
Araştırma ajanıAnaliz ajanıKodlama ajanıGözden geçirme ajanıYazım ajanıGerçek kontrol ajanı
Her ajan farklı bir modele sahip olabilirken aynı CometAPI erişim katmanını paylaşabilir.
Bir sonraki adım yönlendirmeyi dinamik hale getirmektir.
Şunun yerine:
"analyst": "claude-opus-5"
şunu kullanabilirsiniz:
select_model( task="analysis", budget=budget, latency_target=latency_target,)
Yönlendirme sistemi daha sonra uygulama gereksinimlerine göre onaylı modeller arasından seçim yapabilir.
CrewAI + CometAPI için En İyi Üretim Mimarisi Nedir?
Küçük bir iş akışı için:
Kullanıcı Girdisi ↓CrewAI ↓CometAPI ↓Modeller
Üretim için:
┌───────────────┐ │ Model Catalog │ └───────┬───────┘ │ ▼User → CrewAI → Routing Policy → CometAPI │ │ │ │ │ ├── Gemini │ │ ├── Claude │ │ └── GPT │ │ │ ▼ │ Cost / Quality / │ Latency / Policy │ ▼ Checkpoints │ ▼ Usage Tracking
Temel üretim bileşenleri şunlardır:
- Model izin listesi (allowlist)
- Ajan başına yönlendirme
- Sınırlı yeniden denemeler
- Görev kontrol noktaları
- Kullanım takibi
- Maliyet kontrolleri
- Model uyumluluk testleri
- Gözlemlenebilirlik
- İdempotent yan etkiler
Bu mimari, yalnızca crew.kickoff() etrafına bir try/except eklemekten çok daha sağlamdır.
Tek Bir CometAPI Anahtarı, Farklı Modeller, Daha Net Ajan Rolleri
CrewAI ve CometAPI’yi birlikte düşünmenin en faydalı yolu, iki tamamlayıcı katman olarak görmektir.
CrewAI, ajanların ne yaptığını tanımlar.
CometAPI, bu ajanların modellere nasıl eriştiğini tanımlar.
Bu ayrım, yüksek hacimli bir araştırma ajanına hızlı bir model, analiz ajanına daha güçlü bir akıl yürütme modeli ve nihai yazara genel amaçlı bir model atamayı, iş akışı içinde ayrı sağlayıcı entegrasyonları sürdürmeden mümkün kılar.
En basit uygulama, tek bir CometAPI anahtarını ve tek bir OpenAI uyumlu temel URL’yi kullanır:
https://api.cometapi.com/v1
Üretim için mimariyi bir adım daha ileri taşıyın: model yönlendirmeyi yapılandırmada tutun, model kullanılabilirliğini dağıtımdan önce doğrulayın, yalnızca geçici hatalar için sınırlı geri dönüş kullanın, tamamlanan görevleri kontrol noktasıyla koruyun ve her çalıştırma için model ve kullanım meta verilerini kaydedin.
Bu, CrewAI’yi tek bir LLM’ye bağlamaktan çok daha dayanıklı bir desen sağlar:
CrewAI ajanları orkestre eder. CometAPI model erişimini merkezileştirir. Model kimlikleri yönlendirmeyi kontrol eder. Kontrol noktaları tamamlanan işleri korur. Kullanım takibi maliyeti yönetir.
Sıkça Sorulan Sorular
CrewAI aynı ekipte birden fazla AI modeli kullanabilir mi?
Evet. Her CrewAI ajanına farklı bir LLM yapılandırması atayın. Her yapılandırma, aynı CometAPI API anahtarını ve temel URL’yi kullanırken kendi modelini belirtebilir.
CrewAI OpenAI uyumlu bir API’ye bağlanabilir mi?
Evet. CrewAI’nin LLM yapılandırması OpenAI uyumlu uç noktalar için özel bir base_url ve API anahtarını destekler.
CometAPI ile temel URL:
https://api.cometapi.com/v1
GPT, Claude ve Gemini için ayrı API anahtarlarına ihtiyacım var mı?
Bu modellere CometAPI üzerinden erişirken, uygulama her CrewAI ajanında ayrı sağlayıcı kimlik bilgileri uygulamak yerine CometAPI kimliğini ve uç noktasını kullanabilir.
Tek bir API anahtarı, modellerin aynı yeteneklere sahip olduğu anlamına gelir mi?
Hayır. API arayüzü birleştirilebilir, ancak model yetenekleri farklı kalır. Bağlam pencereleri, araç desteği, parametreler, çıktı davranışı, gecikme ve fiyatlandırma modele göre değişebilir.
Bir model başarısız olduğunda tüm CrewAI iş akışını yeniden denemeli miyim?
Yalnızca basit ve durumsuz iş akışları için. Tüm ekibin yeniden denemesi, tamamlanan görevleri tekrar ettirebilir ve maliyeti artırabilir. Üretim iş akışlarında, tamamlanan görevleri kontrol noktalarına alın ve mümkün olduğunda başarısız kısımdan devam edin.
CrewAI’nin mevcut kontrol noktası işlevi, yürütme durumunu korumak ve hatalardan sonra devam etmek için tasarlanmıştır.
Her CrewAI istisnası model geri dönüşünü tetiklemeli mi?
Hayır. Kimlik doğrulama, hatalı istekler, geçersiz model kimlikleri ve desteklenmeyen parametreler genellikle farklı bir modele geçmek yerine yapılandırma değişikliği gerektirir.
Geri dönüş, zaman aşımı, hız sınırı ve geçici 5xx yanıtları gibi sınırlı geçici hatalar için daha uygundur.
Her CrewAI ajanının maliyetini nasıl takip ederim?
Her görev için ajan adını, model kimliğini, token kullanımını, gecikmeyi, yürütme durumunu ve geri dönüş bilgilerini kaydedin. Bu verileri kullanarak ajan ve iş akışı başına maliyeti hesaplayın.
Bir ajana atanan modeli dinamik olarak değiştirebilir miyim?
Evet. Model kimliklerini ajan tanımlarına gömmek yerine bir yönlendirme yapılandırmasında saklayın. Uygulamanız daha sonra maliyet, gecikme, görev türü veya kullanılabilirliğe göre modelleri seçebilir.
CometAPI, CrewAI’nin yerine geçer mi?
Hayır. Farklı katmanlarda çalışırlar. CrewAI ajanları ve görevleri orkestre ederken, CometAPI birleşik bir model erişim katmanı sağlar.
Mevcut CometAPI modellerini nerede bulabilirim?
İnsan odaklı model keşfi için CometAPI model dizinini ve programatik doğrulama için model API’sini kullanın. CometAPI’nin mevcut hızlı başlangıç sayfası, metin, görsel, video ve ses kategorilerinde 500+ modeli listeler.
