用 Jev 做 coding agent 的决策层:路由、工具判断与结果校验
土耳其开发者提出把 Jev 嵌进 agent harness,用小决策模型替代大 LLM 处理任务分类、模型路由、工具调用判断和完成度验证。
Jev’le alakalı çok fazla use case gördüm ancak en değerli alanlardan birinin agent harness’ları olacağını düşünüyorum. Bunun için LangChain ailesi uyumamış olsa gerek :D Çünkü artık agent’ın yaptığı her küçük judgement görevi için büyük bir LLM’e gitmek zorunda değiliz. Özellikle coding agent’larda bunun çok ciddi bir karşılığı var. Örneğin bir coding harness içerisinde Jev; → Görevin zorluğunu değerlendirip doğru modele routing yapabilir. Basit bir değişikliği küçük modele, ciddi bir refactor veya architecture değişikliğini frontier modele gönderebilir. → Agent bir tool kullanmadan önce yapılacak işlemi değerlendirebilir. “Bu command gerçekten gerekli mi?”, “Riskli bir işlem mi?”, “Agent kendisine verilen scope’un dışına çıkıyor mu?” gibi kararları verebilir. → Agent’ın yaptığı işi sürekli kontrol edebilir. “Bu değişiklik gerçekten problemi çözdü mü?”, “Test sonucu yapılan değişikliği destekliyor mu?”, “Tekrar denemek gerekiyor mu?” gibi judgement görevlerini üstlenebilir. → Agent “task completed” dediğinde gerçekten tamamlanıp tamamlanmadığını ayrıca değerlendirebilir. Yani yapı kabaca: task ↓ Jev → task classification / model routing ↓ LLM → reasoning + coding ↓ Jev → action / tool judgement ↓ tools ↓ Jev → result verification ↓ retry / continue / finish haline gelebilir. Burada bence önemli olan Jev’in başka bir LLM’in yerini alması değil. LLM’i reasoning ve generation gereken yerde kullanıp agent loop içerisindeki çok sayıdaki küçük judgement görevini hızlı ve ucuz bir decision modeline bırakabilmek. Bu tip bir ilerlemede özellikle kodlama görevlerinin ciddi anlamda ucuzlayacağını ve hızlanacağını düşünüyorum. Ki bu sadece harness tarafındaki use case. Sabahtan beri basit bir RAG sistemini de Jev ile modifiye ediyorum ve şu an için aldığım sonuçlar inanılmaz iyi. Mesela klasik: query → retrieval → context → LLM akışı yerine; query ↓ Jev → query classification / retrieval gerekli mi? ↓ retrieval ↓ Jev → gelen chunk gerçekten soruyla alakalı mı? ↓ Jev → yeterli evidence var mı, tekrar retrieval gerekli mi? ↓ LLM → answer generation ↓ Jev → cevap gerçekten retrieved context tarafından destekleniyor mu? gibi bir yapı kurulabiliyor. Bunun sonucunda LLM’e gereksiz context göndermeyi azaltabilir, irrelevant chunk’ları daha generation aşamasına gelmeden eleyebilir, gerektiğinde retrieval’ı tekrarlayabilir ve final cevabın eldeki evidence tarafından desteklenip desteklenmediğini ayrıca kontrol edebiliriz. Yani potansiyel olarak daha az token, daha düşük latency ve maliyet ile daha temiz context ve daha güvenilir cevaplar elde edebilecek bir RAG pipeline ortaya çıkıyor. Ve bunların hepsini yapmak için her judgement noktasında tekrar büyük bir reasoning modeline gitmek zorunda değiliz. Jev’in use case’leri gerçekten çok fazla ve birbirinden tamamen farklı önemli problemlere dokunuyor. Uzun süredir yaşamadığımız o “DeepSeek moment”i tekrar yaşıyor olabiliriz.
这条是引用着另一条写的:「Jev 分类模型介绍与接入 harness 的教程预告」