7 Mayıs 2026'da LangChain, Deep Agents için harness profilleri yayınladı: bir agent'ın sistem promptunu, araçlarını ve middleware'ini her model için ayrı ayrı ezmenin bildirimsel bir yolu. OpenAI, Anthropic ve Google modelleri için profiller kutudan çıktığı gibi geliyor. Mobil, otomasyon ve agent orkestrasyonunu birden fazla model üzerinde yürüten ekipler için bu, "GPT üzerinde çalışıyor" ile "router bugün hangisini seçtiyse onun üzerinde çalışıyor" arasındaki eksik parça. Bu rehber harness profillerinin ne olduğunu, model bazında yapılandırmanın neden önemli olduğunu ve n8n, Hermes Workspace ile Sakana Conductor'un yanına nasıl oturduğunu adım adım anlatıyor.
Geçtiğimiz yılın büyük bölümünde Deep Agents harness'ı, tüm desteklenen modellerle iyi çalışmayı hedefleyen tek bir prompt seti, tek bir araç listesi ve tek bir middleware yığınıyla geliyordu. Tek modelli bir proje için bu makul bir varsayılan. Sakana Conductor gibi bir yönlendirme katmanı aynı koşuda bir görevi Claude'a, sonrakini GPT-5'e ve üçüncüsünü Gemini'ye gönderdiği anda sessizce çöküyor. Her model farklı bir prompt stilini ödüllendiriyor, farklı bir araç yüzeyini kaldırıyor ve farklı çıktı doğrulamasına ihtiyaç duyuyor. Harness profilleri LangChain'in cevabı: belirli bir sağlayıcı veya model seçildiğinde agent'ın otomatik olarak aldığı, modele özgü bir yapılandırma paketi.
30 Saniyelik Özet
Harness profilleri pratikte ne sunuyor
Bir harness profili, model kurulduktan sonra agent'ı yeniden yazmadan uygulanan, YAML veya JSON destekli bir yapılandırma paketidir. LangChain bunları Deep Agents'ta birinci sınıf bir katman olarak veriyor; üretim agent orkestrasyonu için önemli beş düğme var:
- Sistem promptu ön eki ve son eki — temel promptu çevreleyen, modele duyarlı kısa bloklar. Akıl yürüten bir model, hızlı ucuz bir modelden farklı bir ön ek alır.
- Araç dahil etme ve yeniden adlandırma — araçları model bazında açıp kapatmak ve aynı temel aracı her modelin tercih ettiği kongreye uyacak şekilde yeniden adlandırmak.
- Middleware seçimi — modele uygun doğrulayıcıları, yeniden denemeleri, şema göçlerini ve zaman aşımı politikalarını seçmek. JSON halüsinasyonu gören bir model, bunu yapmayan bir modelden daha sıkı bir doğrulayıcı alır.
- Alt-ajan yapılandırması — üst agent'ın hangi alt-ajanlara ulaşabileceğini ve bunların prompt'ta nasıl tanımlanacağını seçmek; böylece küçük bir model 12 alt-ajanlı bir menüyle boğulmuyor.
- Yetenekler — adlandırılmış yetenekleri (arama, kod yürütme, retrieval) profile bağlamak ve her modelin yalnızca iyi yaptığı yetenekleri görmesini sağlamak.
Profiller, "openai" gibi bir sağlayıcı adı altında veya "openai:gpt-5.4" gibi bir sağlayıcı-model anahtarı altında kayıt olur. Sağlayıcı düzeyi ve model düzeyindeki profiller çözümleme anında birleşir; böylece bir ekip OpenAI geneli için varsayılanları bir kez koyup yalnızca yeni bir model çıktığında GPT-5.4 satırını ezebilir.
Modele göre yapılandırma neden önemli
Tek modelli bir projede modele özgü her seçim temel prompta ve temel araç listesine pişiyor; agent yayına çıkıyor. Çok modelli bir projede aynı yaklaşım temel promptu hiçbir modele tam uymayan bir uzlaşıya çeviriyor. Üç somut kayma, profil yaklaşımını eklemenin değerini gözle görülür kılıyor.
Farklı modeller farklı promptları ödüllendirir
Akıl yürütme ağırlıklı modeller açık plan adımları olan uzun, yapılandırılmış promptları okur. Hızlı sohbet modelleri daha kısa, daha vurucu talimatlarla daha iyi sonuç verir. İki farklı modele yönlendirilen aynı agent koşusu iki farklı ön ek ister. Profiller, agent kodu içinde dallanan if model == "gpt" karmaşası olmadan her ikisini de gönderir.
Araç yüzeyleri taşınabilir değildir
Bir modelin temiz çağırdığı bir aracı bir başka model yanlış kullanır. Çözüm her zaman aracı yeniden yazmak değil. Çoğu zaman zayıf modelden o aracı saklamak ya da docstring'in modelin eğitim dağılımına denk gelecek şekilde yeniden adlandırmak yeterli. Profil bazında araç dahil etme ve yeniden adlandırma, asıl uygulamayı tek kaynakta tutar.
Middleware ihtiyacı modele bağlıdır
Çıktı doğrulayıcıları, şema göçleri, yeniden denemeler ve düğüm-düzeyi zaman aşımları modelin nasıl davrandığına bağlıdır. Uzun koşulardan sonra JSON şemasından kayan bir model, agresif bir doğrulayıcı ve şema göç adımı ister; şemaya saygı gösteren bir model ikisini de istemez. Middleware'i profil bazında bağlamak, sıkı yolun yalnızca gerçekten ihtiyaç duyan modellere yük olması anlamına gelir; her koşuyu vergilendirmez.
Üretim agent kalitesinin çoğunun yaşadığı yüzey ağırlıklar değil, harness'tır. Harness profilleri, bunu açıkça kabul edip her modelin biçimine saygı gösteren bir yapılandırmayı yayına almanın en temiz yolu.
Bir harness profilinin anatomisi
Profil küçük bir nesne. Agent kodunuzu değiştirmiyor; modelin etrafında harness'ı yönlendiriyor. Tipik bir Deep Agents profili, makul boş varsayılanlarla aynı beş alanı kapsar:
| Alan | Ne kontrol eder | Örnek |
|---|---|---|
| prompt.prefix | Sistem promptunun başına eklenen kısa blok | Adım adım düşün. Önce plan aracını kullan. |
| prompt.suffix | Sistem promptunun sonuna eklenen kısa blok | Emin değilsen, tahmin etmek yerine kullanıcıya tek hedefli bir soru sor. |
| tools.include | Bu modelde aktif olan araçlar | plan, search, run_code |
| tools.rename | Araç bazında ad değiştirme | run_code → execute_python |
| middleware | Doğrulayıcılar, retry, zaman aşımları | json_schema_v2, retry_3x, timeout_60s |
| subagents.allowed | Üst agent'ın başlatabileceği alt-ajanlar | researcher, writer |
| skills.bind | Bu modele açık olan yetenekler | web_search, repo_read |
Mesele bu form. Bir profil bir yapılandırma belgesidir, kod dalı değil. Model kayıt defterinin yanında durur, bir pull request'te gözden geçirilebilir ve bir model güncellemesi davranışı değiştirdiğinde her diğer yapılandırma kalıbı gibi geri alınabilir.
Harness profilleri yığınınızda nereye oturuyor
Harness profilleri ne iş akışı aracınızın, ne yönlendirme katmanınızın, ne de kalıcı çalıştırma katmanınızın yerine geçer. Agent katmanının içinde, model bazında yapılandırma yüzeyi olarak otururlar. Yan yana:
| Katman | Araç | Sahip olduğu |
|---|---|---|
| Görsel iş akışı | n8n | Tetikleyiciler, entegrasyonlar, okunabilir akış adımları |
| Mobil orkestrasyon | Hermes Workspace | Telefon tarafı onaylar ve agent kontrol düzlemi |
| Yönlendirme | Sakana Conductor | Hangi modelin hangi alt görevi alacağını seçer |
| Kalıcı çalıştırma | Cloudflare Project Think | Çökmeye dayanıklı yürütme, alt-ajanlar, kalıcı oturumlar |
| Uzun vadeli sürü | Kimi K2.6 | 300 paralel alt-ajan, 4.000 koordineli araç çağrısı |
| Model bazında harness yapılandırması | LangChain Deep Agents profilleri | Model başına prompt, araç, middleware, alt-ajan ve yetenek |
Sınırlar gerçek. Sakana modeli seçer. Project Think koşuyu hayatta tutar. Hermes telefon tarafı onay döngüsünü çevirir. LangChain Deep Agents profilleri ise Sakana'nın seçtiği modelin sonra o modelin istediği gibi prompted, araçlandırılmış ve doğrulanmış olmasını sağlar.
Halmob tarzı yığınlar için beş pratik kullanım
Çok modelli n8n akışları
Bir n8n akışı bugün yalnızca bir modelde çalışan bir Deep Agent adımını çağırıyor. Anthropic ve Google profillerini ekleyin, yönlendirmeyi maliyet ve gecikme politikasına yöneltin ve aynı akışın altındaki model değişirken çalışmaya devam etmesini izleyin. Akış görselleştirmesi sade kalır; modele özgü farklar profillerde yaşar, akışta değil.
Sağlayıcılar arası, telefonla onaylanan agent koşuları
Bir Hermes Workspace kullanıcısı telefondan derin bir araştırma koşusu başlatır. İlk bacak sorgu genişletmesi için hızlı bir modeli, ikinci bacak sentez için bir akıl yürütme modelini kullanır. Profiller bacaklar arasında promptu ve araç setini kullanıcı fark etmeden değiştirir; böylece kullanıcının onayladığı sonuç tutarlı olur.
Çevrimdışı dostu yedekleri olan mobil asistanlar
Mobil otomasyonlar genelde birincil model rate-limited ya da ulaşılmaz olduğunda çalışmaya devam etmek zorunda. Yedek model için bir profil daha dar bir araç listesi ve daha sıkı bir doğrulayıcı taşır; böylece düşürme sessiz bir kalite düşüşüne dönüşmez.
Uyumluluk düzeyinde JSON çıktısı
Düzenlenmiş bir iş akışı her seferinde şemaya uygun JSON ister. Kayan modelin profili bir şema göç middleware'i ve 3x retry taşır; kaymayan modelin profili ikisini de taşımaz. Agent kodu tek bir yol olarak kalır; sıkılık profile taşınır.
Üst modele göre boyutlandırılmış alt-ajan menüleri
12 alt-ajanlı bir menüden kafası karışan küçük bir üst model 3 alt-ajanlı bir profille koşabilir; aynı üst rol daha büyük bir modelde tüm menüyü açabilir. Agent hâlâ tek bir agent; gördüğü menü profile bağlı.
Bu mobil otomasyon için neden önemli
Nasıl başlanır
- 1LangChain Deep Agents harness referansını ve harness profillerinin lansman yazısını okuyun. Sağlayıcı düzeyi ve model düzeyindeki profillerin çözümleme anında nasıl birleştiğine dikkat edin.
- 2Bugün üretimde en az iki modelde — gayri resmi olarak da olsa — koşan bir Deep Agent seçin. Model bazında profilin değerini hissetmek için en ucuz nokta burası.
- 3Modele özgü kısımları temel prompttan bir profile taşıyın. Ön ek, son ek ve araç include listesiyle başlayın; baseline oturduktan sonra middleware ekleyin.
- 4Profilleri yönlendirme katmanınıza bağlayın. Sakana Conductor ya da benzeri bir router kullanıyorsanız profil anahtarı router'ın ürettiği model kimliğini takip etsin; böylece bir yönlendirme değişikliği aynı zamanda bir profil değişikliği olur.
- 5Profil çözümlemesini izleyin. Hangi koşuda hangi profilin kazandığını loglayın; böylece bir model güncellemesinden sonra gelen bir regresyon değişen yapılandırmaya kolayca eşlenir.
Agent katmanını henüz haritalayanlar için OpenClaw 101 rehberi yapı taşlarını (araçlar, yetenekler, izinler, bellek) anlatıyor; Hermes Workspace mobil orkestrasyonu yazısı ise agent'ın önünde duran telefon onay yüzeyini ele alıyor.
Sonuç
Harness profilleri, LangChain'in tek bir prompt, araç ve middleware setinin her modele iyi hizmet edemeyeceğini ve cevabın kod değil, yapılandırma olduğunu kabul ettiği yerdir. Prompt ön eki, araç dahil etme, middleware, alt-ajanlar ve yetenekler — hepsi çözümleme anında birleşen, model bazında ezimlere dönüşür. Halihazırda n8n, mobil orkestrasyon, bir yönlendirme katmanı ve kalıcı bir çalıştırma katmanı işleten bir ekip için bu, altındaki model değiştikçe aynı agent'ı keskin tutan katmandır.
Bir sonraki sprint için soru basit: Hangi agent'ınız yarın, prompt, araç listesi ve doğrulayıcılar router'ın gerçekten seçtiği modeli takip ettiğinde — agent'ın başta tunelendiği tek model yerine — daha iyi davranır?