Ajan Altyapısı Nedir? Araştırmalar, Açık Kaynak Projeler ve Sektör Uygulamaları

İki ajan, tamamen aynı modeli kullanıp aynı kıyaslamada çok farklı skorlar alabilir. OpenAI bunu doğrudan ölçtü: SWE-bench Lite'ta GPT-4, bir altyapıyla %2,7, diğeriyle %28,3 skor aldı; aradaki 10 katlık farkın tamamı altyapıdan kaynaklandı. Sektör, "hangi model daha akıllı" sorusundan "hangi ajan işi gerçekten tamamlıyor" sorusuna yöneldikçe, ajan altyapısı güvenilirliğin kazanıldığı veya kaybedildiği katman hâline geldi. Ajan altyapısının ne olduğunu, en yeni makaleler ile kıyaslamaların altyapı tasarımı hakkında neler söylediğini, hangi açık kaynak altyapıların zamanınıza değdiğini ve büyük yapay zekâ laboratuvarlarının kendi altyapılarını nasıl geliştirdiğini — Moonshot AI'ın kendi altyapılarıyla eşleştirdiği açık ağırlıklı model Kimi K3.1 Pro dâhil — öğrenmek için okumaya devam edin.

Ajan altyapısı, büyük bir dil modelinin gerçek bir ortamda ajan olarak çalışmasını sağlayan çevresindeki altyapıdır. Model token üretirken diğer her şeyi altyapı üstlenir: her adımda prompt'u oluşturur, hangi araçların bulunduğunu ve nasıl çağrıldığını tanımlar, eylemleri bir sandbox'ta veya terminalde yürütür, gözlemleri modele geri iletir, adım ve maliyet sınırlarını uygular, değerlendirme ya da hata ayıklama için tüm süreci günlüğe kaydeder.

Terim değerlendirme dünyasından gelir: "test harness", bir sistemi kontrollü koşullarda çalıştıran test düzeneğidir. Ajan odaklı yapay zekâda aynı fikir üretime de genişletildi: altyapı hem bir ajanı ölçmek için kullanılan düzenektir (SWE-bench veya Terminal-Bench'te olduğu gibi) hem de bir ajanı çalıştırmak için kullanılan altyapıdır (SWE-agent, OpenHands veya Claude Code'da olduğu gibi).

Anthropic'in kendi SWE-bench araştırması bunu açıkça ifade eder: kıyaslama, "yalnızca yapay zekâ modelini yalıtılmış olarak değil, bütün bir 'ajan' sistemini" değerlendirir; burada ajan, "bir yapay zekâ modeli ile onu çevreleyen yazılım iskelesinin birleşimidir." Geliştirilmiş Claude 3.5 Sonnet, SWE-bench Verified'da karmaşık bir framework ile değil, tek prompt ve iki genel amaçlı araçtan (bir Bash aracı ve bir Edit aracı) oluşan minimal bir altyapıyla %49'a ulaştı.

Yıllar boyunca liderlik tablosundaki ilerlemeler model ölçeğine bağlandı. Son araştırmalar bu varsayımı iki yönden sarstı.

İlki, "az çoktur" sonucu: SWE-bench ekibi Temmuz 2025'te, bash dışında aracı olmayan, tamamen doğrusal bir mesaj geçmişine sahip ve her eylemi bağımsız bir subprocess.run çağrısı olarak çalıştıran, yaklaşık 100 satırlık Python'dan oluşan mini-SWE-agent altyapısını yayımladı. Çok daha karmaşık framework'lerle rekabet edebilecek kıyaslama skorlarına ulaştı (aşağıdaki araştırma bölümünde ele alınmıştır). Çıkarım çarpıcıydı: Model yeterince güçlüyse son derece basit ve öngörülebilir bir altyapı, ağır bir altyapıyı geride bırakabilir. Meta, NVIDIA, IBM, Princeton ve Stanford bunu hâlihazırda temel referans olarak kullanıyor.

İkincisi, "çok azdır" sonucu: Gürültülü araç çıktıları, sınırsız döngüler ve kötü hata kurtarma gibi sorunları olan zayıf bir altyapı, öncü bir modelin vasat görünmesine neden olabilir. OpenAI, SWE-bench'in hatalı görevlerini temizlemenin (aşağıdaki OpenAI bölümünde ayrıntılandırılmıştır) ölçülen model performansını iki kattan fazla artırdığını buldu.

Bu nedenle altyapı mühendisliği başlı başına bir disiplin hâline geldi. Altyapı şunları belirler:

• Modelin ne gördüğünü: prompt yapısı, araç şemaları, ortam durumunun ve geçmişin ne kadarının bağlam penceresine dâhil edildiği.

• Modelin ne yapabildiğini: hangi araçların kullanılabildiği (kabuk, dosya düzenleyici, tarayıcı, arama) ve eylemlerin yürütülmeden önce nasıl ayrıştırılıp doğrulandığı.

• Hataların nasıl ele alındığını: yeniden denemeler, zaman aşımları, pencere dolduğunda bağlam sıkıştırma ve kontrollü sonlandırma.

• Çalışmanın nasıl ölçüldüğünü: süreç günlüğü, derecelendirme ve maliyet muhasebesi — bunlar olmadan ne değerlendirme ne de iyileştirme döngüsü vardır.

İster araştırma amaçlı bir kıyaslama düzeneği ister üretimdeki bir kodlama asistanı olsun, neredeyse her ajan altyapısı aynı temel döngüyü uygular:

1. Görev alımı: sorunu, talimatı veya hedefi okuyun ve yalıtılmış bir ortam başlatın (genellikle bir Docker container'ı veya VM anlık görüntüsü).

2. Prompt oluşturma: sistem prompt'unu, araç tanımlarını, görev açıklamasını ve eylem ve gözlemlerden oluşan devam eden geçmişi birleştirin.

3. Eylem ayrıştırma: modelin çıktısını somut bir araç çağrısına — bir bash komutu, dosya düzenlemesi veya API isteğine — dönüştürmek ve hatalı biçimlendirilmiş eylemleri reddetmek.

4. Yürütme ve gözlem: eylemi ortamda çalıştırmak, stdout/stderr ya da UI durumunu yakalamak ve bağlam bütçesine sığacak şekilde kısaltmak.

5. Kontrol akışı: adım sınırlarını, maliyet sınırlarını ve durdurma koşullarını uygulamak; ne zaman bir insana danışılacağına veya bölümün sonlandırılacağına karar vermek.

6. Kaydetme ve değerlendirme: tam yörüngeyi kaydetmek ve nihai durumu değerlendirmek — örneğin, SWE-bench'te deponun test paketini çalıştırarak.

Her adımdaki tasarım tercihleri birbirini etkiler. Yalnızca kısaltma stratejisi bile uzun vadeli görevlerde puanları belirgin biçimde değiştirebilir; bu nedenle ciddi ekipler harness'ı yapıştırıcı kod değil, sürüm kontrollü ve test edilebilir bir yazılım olarak ele alır.

Ajan harness'larına ilişkin akademik literatür, emekle edinilmiş az sayıda sonuca yakınsamıştır. Bu bölüm, her karşılaştırma ölçütünü sıralamak yerine alanı harness'ı ciddiye almaya zorlayan araştırma sorularını izliyor.

Makalelere geçmeden önce kısa bir giriş. Benchmark, farklı sistemlerin aynı koşullarda karşılaştırılabilmesi için tasarlanmış, sabit bir görev kümesi ve puanlama kuralıdır. Ajan değerlendirmesinde bir benchmark'ın üç hareketli parçası vardır: bir görev kümesi (gerçek GitHub sorunları, terminal komutları, web görevleri), bir yürütme ortamı (bir Docker konteyneri, tarayıcı, terminal) ve bir değerlendirici (bir test paketi, durum kontrolü, insan incelemesi). Harness, model ile bunların üçü arasında yer alır — modelin yeteneğinin puana yansıyıp yansımayacağını belirleyen değişkendir.

Puanların gerçekte nasıl ölçüldüğü, manşetteki sayıdan daha önemlidir. SWE-bench'te bir ajan kod yaması üretir; benchmark ardından iki test paketini çalıştırır: FAIL_TO_PASS (düzeltmeden önce başarısız olan ve artık geçmesi gereken testler) ve PASS_TO_PASS (düzeltmeden önce çalışan ve bozulmaması gereken testler). Görev ancak ikisi de geçerse çözülmüş sayılır. Bu nedenle test yürütme ve diff oluşturma gibi harness özellikleri isteğe bağlı ekstralar değildir — puanlar burada kazanılır veya kaybedilir.

Her benchmark puanını okurken geçerli üç kural:

1. Puanın neyi gizlediğini sorun. Herkese açık GitHub verileriyle eğitilmiş bir model, test edildiği sorunların ta kendisini görmüş olabilir — veri kontaminasyonu, gerçek bir yetenek artışı olmadan puanları şişirebilir. Tekrarlanabilir ortamlar ve ayrılmış görev kümeleri bunun panzehiridir.

2. Goodhart yasasına dikkat edin: bir ölçüt hedef hâline geldiğinde, iyi bir ölçüt olmaktan çıkar. Bir benchmark'ta üstün sonuç almak üzere ayarlanmış bir harness, genel yetenek yerine benchmark'a özgü numaralar öğreniyor olabilir — bu yüzden ciddi ekipler değerlendirmeyi birden fazla benchmark'ta yapar.

3. Yalnızca modeli değil, harness'ı da inceleyin. Bu bölümün devamında görüleceği gibi, aynı model altyapıya bağlı olarak %2,7 veya %28,3 puan alabilir. Adı belirtilmeyen bir harness ile verilen puan, ölçüm değil anekdottur.

Özgün SWE-bench makalesi ("Can Language Models Resolve Real-World GitHub Issues?"), artık standartlaşmış değerlendirmeyi tanıttı: bir modele gerçek bir GitHub sorunu ve deponun tamamını verin, ardından yamasının başarısız testleri geçirip geçirmediğini değerlendirin. En çok atıf alan sonucu sıkça yanlış yorumlanır: o dönemin en iyi modeli Claude 2, görevlerin yalnızca %1,96'sını çözebildi. Yazarların kendi çerçevesine göre benchmark, "geleneksel kod üretiminin çok ötesine geçen karmaşık akıl yürütmeyi" test ediyordu — ancak sonraki çalışmalar, farkın büyük bölümünün akıl yürütme yeteneğinden değil, bir depoda gezinebilen, test çalıştırabilen ve yineleme yapabilen bir harness'ın yokluğundan kaynaklandığını ortaya koydu. Başka bir deyişle, SWE-bench yalnızca modelleri ölçmedi; onları çevreleyen harness'ın eksik parça olduğunu gösterdi.

SWE-agent makalesi ("Agent-Computer Interfaces Enable Automated Software Engineering"), alanın harness tasarımı için kurucu belgesidir. Temel savı, arayüz tasarımının birinci dereceden bir değişken olduğudur: yazarlar Agent-Computer Interface (ACI) terimini ortaya attı ve amaca yönelik oluşturulmuş bir arayüzün — linter korumalı dosya düzenleyici, özlü shell geri bildirimi, hatalı biçimlendirilmiş komutlara karşı koruyucular — SWE-bench'teki pass@1 oranını düşük tek haneli yüzdelerden, o dönemin en ileri seviyesi olan %12,5'e çıkardığını gösterdi. Makalenin kalıcı katkısı, "LM ajanlarının yeni bir son kullanıcı kategorisini temsil ettiği" ve insanların IDE'lere ihtiyaç duyması gibi onların da kendileri için geliştirilmiş yazılıma ihtiyaç duyduğu savıdır. Sonraki tüm harness makaleleri bu sonuca atıf yapar.

2024 tarihli iki makale, harness araştırmasını kod depolarından tam bilgisayara taşıdı. OSWorld, Ubuntu, Windows ve macOS genelinde, web ve masaüstü uygulamalarını kapsayan 369 görevle ilk ölçeklenebilir gerçek bilgisayar ortamını oluşturdu. Manşet sayısı — insanlar görevlerin %72,36'sını, en iyi model ise %12,24'ünü tamamlıyor — baskın başarısızlık biçiminin bilgi sorunu değil, bir harness sorunu olan GUI grounding (model çıktısını doğru tıklama ve tuş vuruşlarına dönüştürme) olduğunu gösterdi. WebArena farklı bir yaklaşım benimsedi: GPT-4'ün, insanların %78,24'üne karşılık uçtan uca yalnızca %14,41 başarıya ulaştığı, kendi kendine barındırılan ve tamamen tekrarlanabilir bir web ortamı (e-ticaret, forumlar, GitLab, CMS). Her iki makale de harness değerlendirmesinin model çıktılarında örüntü eşleştirmeye değil, yürütme tabanlı olmaya — ortamın nihai durumunu kontrol etmeye — dayanması gerektiğini ortaya koydu.

Sierra'nın τ-bench'i ("A Benchmark for Tool-Agent-User Interaction in Real-World Domains") daha incelikli bir noktaya işaret etti: üretimde harness yalnızca modeli ve ortamı sarmalamaz — kullanıcıya da aracılık eder. Benchmark, dil modeli kullanan bir kullanıcı ile alan API'lerine ve politika yönergelerine sahip bir ajan arasındaki dinamik konuşmaları simüle eder, ardından nihai veritabanı durumunu değerlendirir. Temel metriği olan pass^k (k bağımsız denemedeki başarı), ajanların ne kadar tutarsız olduğunu ortaya çıkardı: GPT-4o görevlerin bir kerede %50'sinden azını çözebildi ve perakendede pass^8 %25'in altına düştü. Harness geliştirenler için çıkarım şudur: güvenilirlik tek bir çalıştırmanın değil, dağılımsal bir özelliktir — bir kez çalışan harness, gerçekten çalışan bir harness değildir.

METR'nin "Measuring AI Ability to Complete Long Software Tasks" makalesi, %50 görev tamamlama zaman ufkunu tanıttı: bir modelin %50 güvenilirlikle bitirdiği görevin uzunluğu (insanın tamamlama süresiyle ölçülür). Sınırdaki modeller 2019 ile 2025 arasında dakikalardan yaklaşık bir saate çıktı; yaklaşık her yedi ayda bir iki katına ulaştı. Harness mühendisliği açısından bu, on yılın en önemli bulgusudur: 2024 modelini kısıtlayan harness, 2026 modeli için gereksiz yüktür. Anthropic'in çerçevesine göre bir harness'taki her bileşen, modelin ne yapamayacağına dair bir varsayım barındırır — ve modeller geliştikçe bu varsayımlar güncelliğini yitirir.

Özgün benchmark, bu dersleri uygulamaya döken bir ekosisteme dönüştü:

• SWE-bench Verified (OpenAI ile, 2024): yetersiz tanımlanmış veya haksız değerlendirilen görevleri çıkaran, 500 örnekten oluşan insan filtreli bir alt küme — özgün havuzun %68,3'ü elendi; bu da ölçülen puanları iki katından fazla artırdı ve varsayılan liderlik tablosu hâline geldi.

• SWE-smith (2025): modellerin yalnızca üzerinde değerlendirilmesi değil, ajan odaklı harness'lar için eğitilmesi amacıyla sentetik eğitim görevleri üreten bir işlem hattı.

• mini-SWE-agent (2025): artık SWE-bench Verified'da %74'ü aşan yaklaşık 100 satırlık harness; model yeterince güçlendiğinde doğrusal geçmişe sahip minimal, yalnızca bash kullanan bir döngünün yeterli olduğunu gösteriyor ve topluluğun varsayılan temel çizgisi hâline geliyor.

• Terminal-Bench (Stanford × Laude, 2025): Harbor çatısı üzerine kurulu terminal görevi değerlendirmesi; harness'ları kod düzenlemenin ötesine, sistem yönetimine taşıyor.

• CodeClash (2025) ve ProgramBench (2026): amaç odaklı ve sıfırdan yazılım oluşturma; harness'ları tek sorun düzeltmelerinden açık uçlu geliştirmeye genişletiyor.

Tüm bu çalışmaların ortak çizgisi tutarlıdır: harness tesisat değildir, incelemenin nesnesidir. Puanla birlikte harness'ı da raporlayın, ortamı tekrarlanabilir tutun ve harness'ı incelenemeyen her sonuçtan şüphe edin.

Açık kaynak harness'lar, çoğu ekibin başlangıç noktasıdır. Aşağıdaki projeler, büyük GitHub topluluklarını (önde gelenlerde on binlerce yıldız) etkin bakımla bir araya getiriyor:

Bunlar arasından seçim yaparken topluluğun yaklaşımı şudur: görevinizi ifade edebilen en az kapsamlı altyapıyı kullanın (mini-SWE-agent felsefesi) ve karmaşıklığı yalnızca ölçülmüş bir başarısızlık gerektirdiğinde ekleyin. DeepSeek Harness, yelpazenin karşı ucunda yer alır — her katmanı değiştirilebilir kılmak isteyen ekipler için tamamen eklenti odaklı bir platformdur — ancak ikisi de ortak bir disipline sahiptir: modelin gördükleri için tek doğruluk kaynağı olarak dayanıklı, yalnızca ekleme yapılabilen bir oturum günlüğü.

Öncü laboratuvarlar altyapı mühendisliğini temel fikrî mülkiyet olarak görüyor ve bunların birçoğu yaklaşımlarını alışılmadık ölçüde ayrıntılı biçimde yayımladı.

Anthropic, altyapı mühendisliğine ilişkin en kapsamlı kamuya açık kaydı yayımladı ve Building Effective Agents (2024), SWE-bench altyapısı yazısı (2024) ve Managed Agents (2026) boyunca ayrıntılandırdığı mimarisi, iç içe üç katman olarak okunabilir.

Yürütme katmanı kasıtlı olarak asgari düzeydedir: komutları çalıştırmak için bir Bash aracı ve dosyaları görüntüleyip değiştirmek için bir Edit aracı. Tasarım çabası, bu araçları hataya dayanıklı kılmaya odaklandı — mutlak yolların zorunlu tutulması, uzun çıktının kesilmesi ve düzenlemelerin yalnızca benzersiz bir dize eşleşmesinde uygulanması gibi — böylece modelin önlenebilir araç hatalarından kurtulması nadiren gerekir.

Oturum katmanı, modelin bağlam penceresinin dışında bulunan, dayanıklı ve yalnızca ekleme yapılabilen bir olay günlüğüdür. Her eylem ve gözlem buraya kaydedilir; modelin bağlamı günlüğün kendisi değil, bu günlüğün bir yansımasıdır. Bu ayrım, başarısız olan bir altyapı sürecinin yeniden başlatılıp görev ortasında sürdürülmesini sağlar ve altyapıyı bir evcil hayvandan ziyade gözden çıkarılabilir "sığır" haline getirir.

Orkestrasyon katmanı — Anthropic'in "meta-harness" adını verdiği katman — açık arayüzler aracılığıyla "beyni" (modeli ve döngüsünü), "ellerden" (korumalı alanlar ve araçlar) ayırır. Beyin artık yürütme kapsayıcısının içinde yer almadığından, korumalı alanlar gerektiğinde sağlanabilir ve kimlik bilgileri, korumalı alanın hiç erişmediği bir kasada tutulabilir. Bildirdikleri kazanç kozmetik değil, yapısaldır: oturumlar hiç kullanmayabilecekleri kapsayıcıları artık beklemediği için p50 ilk token süresi yaklaşık %60, p95 ise %90'ın üzerinde düştü.

Bu evrimin izini üç belge sürer: Building Effective Agents (2024), SWE-bench altyapısı yazısı (2024) ve Managed Agents (2026).

OpenAI, altyapıların temiz görevlere ihtiyaç duyması nedeniyle insan doğrulamalı Verified bölümünü oluşturmak üzere SWE-bench ekibiyle ortaklık kurdu: açıklama kampanyaları (93 geliştirici, 1.699 örnek), özgün kıyaslamadaki görevlerin %68,3'ünün sorunlu olduğunu ortaya koydu ve bunların çıkarılması ölçülen performansı iki kattan fazla artırdı. Aynı yazıda, yalnızca altyapı seçiminin GPT-4'ü SWE-bench Lite'ta %2,7'den %28,3'e taşıdığı belirtiliyor; bu farkı, değerlendirmelerin topluluk tarafından geliştirilen altyapılardaki ilerlemeyi hesaba katması gerektiğini savunmak için kullanıyorlar.

Açık kaynak tarafında Codex CLI, eksiksiz bir referans altyapısı olarak sunuluyor. Mimarisi, bu bölümdeki diğer sistemleri yansıtan katmanlı bir yapıya sahiptir: bir temel ajan döngüsü planlama ve araç çağrılarını yönetir; bir korumalı alan katmanı, görev başına yapılandırılabilir politikalarla yürütmeyi izole eder; bir oturum katmanı, konuşmaları devam ettirilebilmeleri, dallandırılabilmeleri veya sıkıştırılabilmeleri için kalıcı olarak saklar; bir araç katmanı ise hem yerel kabuk erişimini hem de MCP tabanlı harici araçları sunar. Tek bir arayüzü sabitlemek yerine, aynı motor üç farklı yüzey üzerinden sunulur — etkileşimli çalışma için terminal arayüzü, VS Code gibi zengin istemciler için JSON-RPC uygulama sunucusu ve bulut korumalı alanları için uzaktan kod yürütme hizmeti — böylece altyapı yerelde çalışabilir veya programatik olarak yönetilebilir. Tasarım, araştırma literatürünün önerdiği aynı tercihleri yapar: asgari döngü, güçlü korumalı alan, açık bağlam yönetimi ve model ile dış dünya arasında net bir sınır.

Agent Development Kit (ADK) ve Nisan 2025'te Atlassian, Salesforce, SAP ve ServiceNow dahil 50'den fazla teknoloji ortağıyla kullanıma sunulan Agent2Agent (A2A) protokolü ile Google, koşum katmanını ürünleştiriyor. A2A; koşumların özel yapıştırıcılar yerine birlikte çalışabilir altyapılar hâline gelmesi için ajanların yeteneklerini nasıl duyurduğunu (JSON "Ajan Kartları" aracılığıyla), uzun süren görevleri nasıl yönettiğini, yapıtları nasıl paylaştığını ve kullanıcı arayüzü biçimlerini nasıl müzakere ettiğini standartlaştırır. Koşumun araç tarafını standartlaştıran Anthropic'in Model Context Protocol (MCP) protokolünü tamamlamak üzere açıkça tasarlanmıştır.

Microsoft'un AutoGen ve Magentic-One ürünleri, bir orkestratör ajanın olguların ve ilerlemenin kaydını yönettiği koşumlar sunar; bu, naif koşumları etkileyen sınırsız döngüleri önlemek için yayımlanmış bir tasarımdır. Meta ve Hugging Face'in GAIA'sı, web'de gezinme ve dosya işlemleri gerektiren gerçek dünya sorularını değerlendiren bir koşumla genel asistanlar için bir kıyaslama oluşturdu; Hugging Face'in Open Agent Leaderboard'u karşılaştırılabilir, koşum farkındalığına sahip sıralamalar için çalışmayı sürdürüyor.

DeepSeek Harness (dsh), meta koşum fikrini alıp birleştirilebilir hâle getirir. Mimarisi Cordis çerçevesi üzerine kuruludur ve temel savı şudur: Koşumun her parçası değiştirilebilir bir eklentidir — model bağdaştırıcısı, araç kayıt defteri, oturum günlüğü ve ajan döngüsünün kendisi dâhil.

Tasarım üç temel öğeye dayanır. İlki, modelin gördükleri için tek doğruluk kaynağı olan kalıcı oturum günlüğüdür; modele ulaşan her şey günlükten yeniden oluşturulabilir olmalıdır ve bu, çalışma zamanı değişmezi olarak zorunlu kılınır. İkincisi, yetenek bağlantı noktalarıdır: ajan ile dış dünya arasında değiştirilebilir bir sağlayıcı arayüzü. Böylece dosya sistemi ve alt süreç sağlayıcıları uzak bir korumalı alana yönlendirildiğinde, koşumu çatallamadan Bash, terminal ve dil sunucusu erişimi de onlarla birlikte taşınır. Üçüncüsü ise eklentilerin çekirdek kodu değiştirmeden döngüyü kesmesine veya yeniden yazmasına olanak veren, adlandırılmış genişletme olaylarına (agent/pre-step, tools/execute, agent/turn-stopping) sahip açık bir tur/adım yaşam döngüsüdür.

Sonuç, Anthropic'in meta koşumunun açık kaynaklı en yakın karşılığıdır: yapının sabit bir çerçeve değil, yapılandırma üzerinden değiştirilebilen eklentilerin bileşimi olduğu bir koşum. İlk aylarında GitHub'da 170 binden fazla yıldız alması, ajan koşumunun başlı başına bir ürün kategorisine dönüştüğünü gösteriyor.

Hepsindeki ortak örüntü şudur: döngüyü basit tutun, her şeyi korumalı alana alın, her adımı günlüğe kaydedin ve onu üreten koşum olmadan hiçbir puana güvenmeyin.

Bu bölümde şimdiye kadar ele alınan her şey — minimal döngüler, kalıcı oturum günlükleri, korumalı alanda yürütme, eklenti mimarileri — aynı varsayımı paylaşır: ajanın ortamı bir bilgisayardır. Bir terminal, tarayıcı, dosya sistemi, depo. Koşum, ajanın bu makineyi güvenilir şekilde kullanabilmesi için vardır.

Ancak yukarıda izlenen araştırma çizgisi başka bir yönü gösteriyor. τ-bench, kullanıcıyı koşumun içine yerleştirdi. METR, ajanların dakikalar değil günler süren işleri üstlendiğini gösterdi. OSWorld ve WebArena, ortamı temiz bir depodan dağınık gerçek dünyaya taşıdı. Yön tutarlı: ajanlar kodlama araçlarından gerçek iş asistanlarına dönüştükçe, gezinmeleri gereken ortam artık yalnızca silikon değil, insanlardır. Beklentileri olan kullanıcılar, geçmişi olan ekipler, izinleri ve kurumsal bilgisi olan kuruluşlar.

Bu değişim, diğer tüm koşum alt sistemlerinden çok bağlam yönetimini etkiler. Bir terminal oturumunda tek bir operatör ve sınırlı bir geçmiş vardır; uzun süreli bir çalışmada ise on paydaş, aylarca alınmış kararlar ve sürekli büyüyen bir depo bulunur. Dosya sistemi pasiftir; çalışma ilişkisi ise zımni taahhütler, yarım kalmış düşünceler ve gelişigüzel verilen kararlar akışıdır. Bunların tümü modele ulaşmadan önce özetlenmeli, sıkıştırılmalı veya atılmalıdır; bu kararların her biri, ajanın görevin ihtiyaç duyduğu bir şeyi kaybettiği yerdir.

Koşum sıkıştırabilir, ancak bunu sınırsız biçimde yapamaz. Bu nedenle bağlam penceresinin boyutu bir model belirtimi olmaktan çıkıp koşum tasarım parametresine dönüştü.

Moonshot AI'ın koşum portföyü, bu makalede daha önce tanımlanan anatomiyi yönetilen tek bir yığına uygular. Ajan × Bilgisayar problemi için koşumları standart döngüyü genişletir: Kimi Browser Extension, steril bir korumalı alan yerine Chrome DevTools Protocol üzerinden gerçek bir tarayıcı oturumunu yönetir; Eylemden önce sor bağlantı noktası dosya sistemi düzeyinde onayı zorunlu kılar ve bir Agent Swarm, uzun ufuklu görevlerde orkestrasyonu 300 alt ajana kadar ölçeklendirir.

Bu döngüyü çalıştıran Kimi K3.1 Pro — K3.1 serisinin ilk modeli ve Moonshot AI'ın bugüne kadarki en yetenekli 3T sınıfı açık ağırlıklı modeli — 1.048.576 tokenlık bağlam penceresine sahiptir. Özelliklerinden üçü doğrudan koşum tasarımıyla ilgilidir:

• Sıkıştırmayı ertelemeye yetecek büyüklükte bir pencere. Bir milyon token, çalışan bir depoyu, devam eden süreci ve referans belgelerini aynı anda barındırır. Koşum yine de kırpma yapar — her zaman yapmak zorundadır — ancak özetlemenin bilgiyi yok etmeye başladığı eşik yeterince ileriye taşınır; böylece uzun ufuklu görevler yolun yarısında sessizce bozulmayı bırakır.

• Koşum ayarı olarak muhakeme çabası. K3.1 Pro her zaman düşünür ve reasoning_effort, varsayılanı max olmak üzere low, high veya max değerlerini kabul eder. Böylece modelin muhakeme maliyeti, sabit bir giriş ücreti olmaktan çıkıp koşumun görev başına belirlediği bir bütçeye dönüşür.

• Bölüm ortasında gelen araçlar. Dinamik araç yükleme, koşumun bir sistem mesajı içine eksiksiz bir araç tanımı eklemesine olanak verir; böylece araç o mesajdan itibaren kullanılabilir hâle gelir — yeniden başlatma gerekmez ve onu hiç kullanmayan bir konuşmanın her turunda şeması için ödeme yapılmaz.

Moonshot, koşumu modelle birlikte raporlar; makalenin geri kalanında savunulan disiplin de budur. Sıkı göreve özgü testler altında, gerçekçi ve kaynak kısıtlı terminal görevlerinde kodlama ajanlarını puanlayan Terminal-Bench 4.0'da K3.1 Pro, GPT-6 Astra'nın (%58,2) önünde ve Claude Opus 5.5'in (%66,4) hemen gerisinde %65,7'ye ulaşır. Çok adımlı yürütme, araç kullanımı ve uçtan uca problem çözme için kurum içi bir kıyaslama olan Kimi Code Bench 3.0 Long-horizon'da, K3'ün %55,95'ine karşı %61,2 puan alır. Dokümantasyon, ters yöndeki bağımlılığı da aynı açıklıkla belirtir: temperature ve top_p gibi örnekleme parametreleri sabittir ve isteklerden çıkarılmalıdır; ayrıca tam asistan mesajı turlar arasında değiştirilmeden döndürülmelidir. Mesajı yeniden yazan bir koşum, bir sonraki araç çağrısının bağlı olduğu muhakemeyi kaybeder.

Aynı model tüm yüzeyi çalıştırır. Yönetilen web sürümünü Kimi Agent ile deneyebilir, tam yerel koşumu Kimi Work ile çalıştırabilir, terminalde Kimi Code ile çalışabilir veya kimi-k3.1-pro modelini doğrudan Kimi API üzerinden çağırabilirsiniz. kimi-k3.1-pro-highspeed varyantı, yaklaşık iki kat token fiyatı karşılığında iki ila üç kat daha yüksek çıktı hızı sunar.

Modelleri değerlendiriyor ya da bir ürün geliştiriyor olun, aynı kontrol listesi geçerlidir:

1. Çerçeveden değil, görevden başlayın. Ajanlarınız kod düzenliyorsa SWE-agent'ın ACI'sı gibi bash artı düzenleyici koşumu kendini kanıtlamıştır. GUI'leri veya canlı web'i kullanıyorlarsa gerçek oturum gözlemlerine ve tıklama düzeyinde eylemlere ihtiyacınız vardır.

2. Ortamları yeniden üretilebilir kılın. Docker imajları, sabitlenmiş bağımlılıklar ve tohumlanmış veriler, bir kıyaslamayı anekdottan ayırır.

3. Bağlam penceresini bilinçli biçimde bütçeleyin. Gözlem kırpma, geçmiş özetleme ve sıkıştırma; puanları ve maliyetleri doğrudan etkileyen koşum özellikleridir. Uzun bağlamlı modellerin, koşumun atmak zorunda olduğu veri miktarını azaltmasının nedeni de budur.

4. Kesin sınırlar uygulayın. Bölüm başına adım sınırları, gerçek zamanlı zaman aşımları ve dolar bütçeleri ajanları güvenli tutar ve değerlendirmeleri karşılaştırılabilir kılar.

5. İlk günden itibaren tam süreç kayıtlarını tutun. İnsan incelemesi, başarısızlık kümeleme ve ince ayar gibi her ciddi iyileştirme döngüsü süreç verilerini kullanır. Anthropic'in Managed Agents'ı ve DeepSeek Harness daha da ileri gider: oturum günlüğünü koşum döngüsünün dışında, yalnızca eklemeli bir olay akışı olarak tutar. Böylece koşumun kendisi değiştirilebilir olur ve modelin bağlamı her zaman yeniden oluşturulabilir.

6. Birden fazla koşumda değerlendirin. Ajanınız yalnızca tek bir koşumda çalışıyorsa, yetenek değil koşuma özgü davranış geliştirmişsinizdir.

7. Kimlik bilgilerini korumalı alanın dışında tutun — hatta tamamen bulutun dışında bırakın. Ajanın yürütme ortamını güvenilmez kabul edin; tokenları bir kasada saklayıp proxy üzerinden ekleyin ya da kimlik bilgilerinin ve sayfa içeriğinin cihazdan hiç çıkmaması için tüm oturumu yerelde çalıştırın — Kimi'nin yerel koşumlarında benimsediği yaklaşım budur.

Ajan koşumu, fark edilmeden ajan temelli yığının en önemli katmanı hâline geldi. SWE-bench, mini-SWE-agent, Terminal-Bench ve METR araştırmaları, koşum tasarımının etkisinin model yükseltmeleriyle yarışabileceğini gösteriyor; DeepSeek Harness, OpenHands, SWE-agent ve Aider gibi açık kaynak projeleri üretim sınıfı koşumları herkesin erişimine sunuyor; Anthropic, OpenAI, Google, Microsoft ve Moonshot AI ise artık koşum mühendisliğini birinci sınıf iş olarak görüyor.

Ancak daha derin değişim kavramsaldır. İlk nesil koşumlar Ajan × Bilgisayar problemini çözdü: bir modele terminal, tarayıcı ve dosya sistemi için güvenilir eller verdi. Sonraki nesil, bu ortamların yarattığı bağlam sorununu çözüyor: günlere, paydaşlara ve hiçbir özetleyicinin kayıpsız sıkıştıramayacağı depolara yayılan çalışma. Koşum, iskeleden bir işletim ortamına evriliyor; koşumun yönetmesi gerekenlerle modelin doğrudan belleğinde tutabilecekleri arasındaki çizgi de sürekli değişiyor. Kimi K3.1 Pro'nun bir milyon tokenlık penceresi bunun güncel en açık örneğidir: koşumun önceden yapmak zorunda olduğu işi ortadan kaldıran bir model değişikliği.

Kendi koşumunuzu geliştirseniz, açık kaynaklı bir çerçeveyi benimseseniz ya da üretim koşumu çalıştırsanız da koşumu tasarlanmış, sürümlenmiş ve ölçülebilir yazılım olarak gören ekipler, ajanlarının işi gerçekten tamamlamasını sağlayan ekiplerdir.