Keneet Mühendisliği Nedir? Uygulamalı Bir Giriş.

Buna güçlü bir görüşle başlayayım.

Bir yazılım mühendisi ya da veri bilimci iseniz, kariyeriniz için bugün öğrenebileceğiniz hiçbir şey, ajan kancalarını (harness) tasarlamanın sağlayacağı kadar fayda sağlamaz.

Bu gerçeği kavramak biraz zaman aldı, ancak üst düzey firmalardaki araştırmacıların son 8 aydır kod yazmadığını öğrendiğimde içimden bir şey geçti.

Bundan sonra artık kod yazmayacağız.

AI bağlamında “kanca”nın ne olduğunu açıkça tanımlayalım

Güncel durumda çok fazla kafa karışıklığı, moda kavram ve kavramsal muğlâzlık var. Bu yüzden, bir kancanın gerçekte ne olduğuna dair kolektif bir kavram birliğine ihtiyacımız var.

Bu denklemi daha önce görmüş olabilirsiniz:

Ajan

=

LLM

+

Hatırlama

+

Araçlar

+

Planlama

+

Eylem

\text{Agent} = \text{LLM} + \text{Memory} + \text{Tools} + \text{Planning} + \text{Action}

Ajan

=

LLM

+

Hatırlama

+

Araçlar

+

Planlama

+

Eylem

LLM taban. Durumsuz, değişmez, belki değiştirilebilir.

Kalanı “kanca”dır. Hatırlama, Araçlar, Planlama ve Eylemi sıralıyorum, ancak bir ajanın davranışını koordine eden “ek”lerin evreni çok daha büyük olabilir.

Ajan

=

LLM

+

Hatırlama

+

Araçlar

+

Planlama

+

Eylem

⏟

Kanca

\text{Agent} = \text{LLM} +
\underbrace{\text{Memory} + \text{Tools} + \text{Planning} + \text{Action}}_{\text{Harness}}

Ajan

=

LLM

+

Kanca

Hatırlama

+

Araçlar

+

Planlama

+

Eylem

​

​

Bu nedenle, ajanların dünyası basitçe şudur:

Ajan

=

LLM

+

Kanca

\text{Agent} = \text{LLM} + \text{Harness}

Ajan

=

LLM

+

Kanca

Anlaşılması gereken önemli şey, kancanın, model yeteneklerini operasyonel bir ajana dönüştürmek için o modelin etrafında inşa ettiğimiz her şey olmasıdır.

Codex, Claude Code ve diğerlerinin yalnızca harness (sistem) olduğunu anlamak önemlidir

Bu bağlamda, bu araçları çalıştıran LLM ikinci sınıf bir vatandaş konumundadır. Codex ve Claude Code, dil modellerinin etrafında inşa edilen ajan tabanlı kodlama ajanlarıdır. Bu ajanlar, model çıkarımını dosya düzenleme, repls, git vb. otonom yazılım geliştirmeyi mümkün kılan bir dizi mekanizma ile birleştirir.

Güç, harness’in zekâsında yatar.

Bu ayrım, mühendislik çabamızın nerede yoğunlaşması gerektiğini değiştirir.

Diyelim ki bir ajana büyük bir kod tabanını yeniden düzenlemesini istiyorsunuz. Python üretmede biraz daha iyi olan bir modeli ince ayarlaarak haftalarca uğraşabilirsiniz.

Alternatif olarak, harness’i şu şekilde iyileştirebilirsiniz: ajan, depo haritasını çıkarabilsin, bağımlılıkları belirleyebilsin, bir test planı oluşturabilsin, kademeli değişiklikler yapabilsin, hedefli testleri çalıştırabilsin, hataları teşhis edebilsin ve alakasız davranışların değişmeden kaldığını doğrulayabilsin.

İkinci yaklaşım, altta yatan LLM’yi yükseltmeye gerek kalmadan, genel sistemde çok daha büyük bir iyileşme genellikle sağlar.

Elbette model yeteneği hâlâ önem taşır. Bir harness, zayıf bir modele eksik olduğu akıl yürütme yeteneğini veremez. Ancak ajanın performansı yalnızca model yeteneğiyle belirlenmez. Bu, yeteneğin göreve ne kadar etkili şekilde uygulandığına bağlıdır.

Bu da beni merkez teze götürüyor: eğer bir yazılım mühendisi veya veri bilimcisiseniz, harness mühendisliğini anlamak artık isteğe bağlı değil. İlgili kalmaya devam etmek için zorunludur.

Rolünüz kod yazmaktan kod yazan ajanlar üretmeye dönüştükçe, harness tasarımı en üst düzey beceri haline gelir. Kendiliğinden, (olası) birçok karmaşık alanı kapsayan problemler üzerinde çalışabil ajanlar yaratmanız gerekir. Başka bir deisle, doğrudan rapor veren kimse olmasanız bile artık bireysel katkı sağlayıcı değilsiniz. Bir yöneticisiniz; ajanların yöneticisi.

Tüm problemlerinizi çözmek için Claude Code veya Codex’e güvenemezsiniz

Bunlar iyi genel amaçlı harness’lerdir. Çok faydalıdırlar, ancak çok karmaşık bir probleme veya genel amaçlı alanın dışında bir probleme yaklaştığınız anda görkemlice çökerler. Bu yaklaşıma güvenirseniz, yalnızca sürüklenme ve çöp temizlemeye zaman harcamakla kalmazsınız, ayrıca kendinizi daha az gerekli hale getirirsiniz.

Üzücü ama gerçek bir olgu: Sadece Claude Code veya Codex kullanarak sistem kurabilen mühendisler tekleşiyor. Pazarda rekabetçi kalamazsınız, tek yeteneğiniz “Claude Code’u nasıl kullanacağımı biliyorum” ise. Açıkçası, AI çağında SWE için stratejiniz buysa, işten çıkarmaların hedefisiniz.

Değeriniz, LLM’leri işe yarayan sistemlere dönüştüren harness’leri tasarlamanızda yatıyor.

O halde bir mühendis nasıl harness mühendisi olur?

Bu, “50 satırda bir ajan kur” yazısı değil. Muhtemelen o eğitim setini gördünüz.

Modele çağrı yapın, bir araç isteyip istemediğini kontrol edin, aracı çalıştırın, sonucu ekleyin, bittiğini söyleyene kadar döngüye girin. Mekanizmayı anlamak için harika bir yol ve demoda çalışır. Bu ajan 101, bir LLM’yi ajan yapan en basit döngü.

python

while

True

response

=

model(messages)

if

response.is_final:

break

result

=

run_tool(response.tool_call)

messages.append(response.tool_call)

messages.append(result)

Ancak bu döngü karmaşık problemleri çözmez. Karmaşık problemler bellek, araçlar ve bağlam yönetimi teknikleri gerektirir. Tam harness.

Bu, kendi harness’lerinizi tasarlamanız için aslında işe yarayan harness’lerin altında yatan ilkel unsurları anlamanızla ilgilidir.

Terfi ettiniz. Artık kıdemli yazılım mühendisi değilsiniz. Sistemin kalbindeki mimarsınız.

Bu, yapmanız gereken temel düşünce değişimidir.

Eğer daha önce yazılımı geleneksel yöntemle yazmaktan rahat hissediyorsanız: bir spec yazmak, fonksiyonları ve birim testlerini tasarlayıp uygulamak, bu artık mevcut değil. Bu artık AI ajanlarının alanı.

Bu iyi bir haber. Otomatik olarak bir sistem mimarına terfi ettirildiniz.

Rolünüz artık, ajanların günlük operasyonlarda başarılı olmalarını sağlayan akıllı çerçeveleri tasarlamak. Çözülecek sorunu çözen mantığı yazmıyorsunuz; yapmanız gereken, yapay zekânın sorunları çözmesini sağlayacak sistemleri tasarlamak.

Bunlar temelden farklı faaliyetler. Takımınızdeki ajanlara yeni yazılım mühendisleri gibi düşünmelisiniz. Engelleri nerede bekliyorsunuz? Hangi araçlara ihtiyaçları var? Geri bildiriminiz ve tasarım vizyonunuz, tüm ayrıntıları tek tek yönetmenize gerek kalmadan doğru ve güvenilir biçimde nasıl hayata geçirilir?

👉 Bu girişi “ilkel birimlere” böldüm: Güvenilir bir ajan çerçevesi üretmek için birleşen mühendislik kavramları. Bu ilkel birimler, yapım blokları gibi düşünülmelidir. Her çerçeve onları farklı oranlarda içermelidir.

İlkel Birim #1. İş Akışları

Herhangi bir gerçek mühendislik işleminden önce, bir iş akışı tasarlamanız gerekir. Buna aynı zamanda “Döngü Mühendisliği” da denir.

Bir ajan için bir iş akışı, bir insan için olanla neredeyse aynıdır. İş akışı, bir ajanın bir görevi çözmek için izlediği aşamaların, karar noktalarının ve geri bildirim döngülerinin sırasındır. Bu iş akışlarını tasarlamak, alan uzmanlığınızın devreye girdiği yerdir.

Örneğin, öznelikselleştirilemez veri bilimi iş akışı, bir insan tarafından yürütüldüğü şekliyle. Bir paydaş sizden bir tahmin modeli oluşturmanızı ister.

1. Sorunu tanımlayın: Ne tiên ediliyoruz ve başarı olarak ne sayılır?

2. Veriyi keşfedin: Veriyi anlayın, sorunları belirleyin ve faydalı özellikleri bulun.

3. Modeli kurun: Özellikler mühendisliği yapın ve ilk modeli eğitin.

4. Değerlendirin: İlgili metrikleri kullanarak görülmemiş veri üzerinde performansı test edin.

5. Tekrarlayın: Hataları analiz edin, özellikleri iyileştirin, farklı modelleri deneyin ve tatmin edici bir sonuç elde edilene kadar tekrarlayın.

6. Teslim edin: Sonuçları belgeleyin ve modeli yaygınlaştırın.

Bu, başarılı mühendisliğin ardındaki aynı ilkedir.

Karmaşık işi, geri bildirimle iyileştirilebilen doğrulanabilir çıktılar içeren aşamalara bölün.

Şimdi, her görevi bir insanın yerine, döngü içinde tamamlanabilecek iş akışları tasarlıyoruz.

Bazı başarılı iş akışı tasarım kalıpları:

1. ReAct

2. Plan-then-Execute

3. Reflexion

4. Sub-agents

ReAct

ReAct: Synergizing Reasoning and Acting in Language Models (ICLR 2023), Yao ve ark. ReAct (Reasoning + Acting) kavramını tanıttı; bu, modelin iç muhakemesini ortamda somut eylemle birleştiren kavramsal olarak basit bir kalıptır.

Yapı üç öğe arasında sırayla değişir:

• Düşünce : model mevcut duruma, ne bildiğine ve sıradaki adımın ne olması gerektiğine dair muhakeme yürütür

• Eylem: model bir araç çağırır veya ortamda bir adım atar

• Gözlem: bu eylemin sonucu modele geri beslenir

Mühendisler için ReAct temelidir. Neredeyse tüm üretim ajanı çerçeveleri bu döngünün bir sürümünü uygular. ReAct döngüsü, yukarıda bahsedilen döngüdür. Basitçe zarif bir yapısı vardır.

Ancak, doğrusal yapısı nedeniyle sınırlıdır. Ajan tek bir muhakeme ipliğini izler. Yanlış bir yöne döndüğünde, genellikle geri dönüp geri gelmek yerine yanlış yolda devam eder. Hiçbir belleği yoktur ve bağlamı hızla bozulur; yalnızca ReAct kullanmak karmaşık problelerde başarıya yol açmayabilir.

Plan-then-Execute

Plan-and-Solve Prompting (ACL 2023), Wang ve ark. modelleri bir eyleme geçmeden önce bir plan formüle etmeye yönlendirmeyi inceledi. Bu, pratikte her başarılı kodlama ajanının yaptığı şeydir ve yazılım mühendisliği dışında birden fazla bağlamda kullanılabilir.

Kalıp:

• Planlama aşaması: Bilgi topla, kod tabanını keşfet, belgeleri oku, değişikliğin gerekli olduğu tüm konumları belirle ve yapılandırılmış bir plan üret

• Gözden geçirme noktası: Plan doğrulanır (bir insan tarafından, bir doğrulama adımıyla veya kendi kendini gözden geçirmeyle)

• Uygulama aşaması: Plana adım adım uy, kenevi mevcut adım hakkında bağlam sağlar ve ilerlemeyi izler

Her yazılım mühendisi kodun içine atlamak ile önce bir tasarım belgesi yazmak arasındaki farkı bilir. Planla-Uygula, bu içgüdünün kenev olarak biçimlendirilmiş halidir.

ReAct basit iş akışları için temel ise, Planla-Uygula karmaşık iş akışları için temeldir.

Reflexion

Shinn ve arkadaşlarının Reflexion’u (Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023), başarısızlık üzerine düşünerek yinelemeli kendini iyileştirme kalıbıdır. Ajan bir görevi dener, sonucunu değerlendirir, neyin yanlış gittiği sözel geri bildirim üretir, bu geri bildirimi hafızaya kaydeder ve bu düşüncenin katkısıyla tekrar dener.

Bu, kodlayan her ajanda testler başarısız olduğunda doğrudan yaşanan şeydir. Ajan kod yazar, testleri çalıştırır, başarısızlıkları görür, neyin yanlış gittiği üzerine düşünür ve gözden geçirir. Reflexion bunu biçimlendirmiş ve modelde hiçbir değişiklik olmadan HumanEval’de 11 puanlık bir iyileşme (80% → 91%) göstermiştir.

Model, kendi başarısızlığını anlamak için bir metabilişsel strateji kullanır, ardından son sonucu iyileştirmek için bunu bağlam olarak kullanır.

Alt ajanlar

Fikir basittir: büyük bir görevi daha küçük alt görevlere ayırın ve her alt görevi kendi araçları ve bağlam penceresiyle donatılmış uzmanlaşmış bir ajana devredin. Bir yönetici devretmeyi yönetir, sonuçları toplar ve bunları son çıktıda sentezler.

Bu kalıbın güzel yanı, her alt ajanın yukarıda betimlenen zarif bir iş akışını kullanabilmesidir. Buradaki temel sınırlamalar, devreden ajanın gücü ve iş akışınızın dayanıklılığıdır.

Alt ajanlarla çalışırkenki temel tasarım kararları şunlardır:

• Kapsam sınırları: Her alt ajan hangi konuyu yönetiyor? Net sorumluluk tanımları, ajanların birbirinin işini ihlal etmesini önler.

• Arayüz sözleşmeleri: Koordinatör her alt ajana hangi bilgiyi aktarıyor ve geriye ne bekliyor? Bu sözleşmeler ne kadar yapılandırılmışsa, sistem o kadar güvenilir olur.

• Başarısızlığın izole edilmesi: Bir alt ajan başarısız olursa veya saçma sonuçlar üretirse, koordinatör bunu tespit etmeli ve diğer alt ajanların işini kirletmeden yeniden deneyerek, görevi başka bir ajana devrederek veya üst seviyeye taşıyarak müdahale etmelidir.

• Bağımsız bağlam: Her alt ajan, yalnızca kendisine verilen bilgilerle çalışabilmelidir. Bir alt ajan işini yapabilmek için 200 dosyalık bir depoyu baştan sona okumak zorundaysa, kapsamı yanlış tanımlamışsınız demektir.

Bu iş akışı kalıpları, harness’leri yazılım mühendisliği, veri bilimi veya başka bir alan için kuruyor olmanızdan bağımsız olarak her zaman kritiktir.

Ayrıca şunu da belirtmek önemlidir: Bunlar yalnızca temel örneklerdir ve kesinlikle zorunlu değildir. Örneğin, hibrit bir tasarım yapabilirsiniz: Her alt ajanın reflexion + insanın döngüde olduğu bir adım kullandığı bir alt ajan devir sistemi. Bu kalıplar, yapı taşları gibi kullanılabilecek kadar yerleşiktir.

⚠️ Tekerleği yeniden icat etmeyin. Bu temelleri kendi görüşünüze göre geliştirin veya değiştirin.

İlkel #2: Mimari

Bir harness’i autoresearch gibi basit bir şeyden Codex gibi daha karmaşık bir şeye eviltmek öngörü ve planlama gerektirir. Ajanın temizce çalışabilmesi ve gerekirse kendi harness’ini bile değiştirebilmesi için, insanın temizlemesi gereken devasa miktarlarda teknik borç yaratmayan net mimari ve yapısal sınırlar olmalıdır.

Eğer bir ekipte üretim yazılımı geliştirdiyseniz, burada zaten içgüdüleriniz mevcuttur.

Öncelikle harness’inizin iskeletini tasarlayın. Bu, araçları, belleği, istemleri vb. düzenli ve okunabilir bir yapı içinde düzenler.

text

your-harness/

├── config/

│ ├── models.yaml # Sağlayıcı yapılandırmaları, API anahtarları, hız sınırları

├── model/

│ ├── interface.py # Birleşik model çağırma API’si

│ ├── context.py # Bağlam penceresi yönetimi, özetleme

│ └── providers/

│ ├── openai.py

│ └── anthropic.py

├── tools/

│ ├── registry.py # Araç kaydı, arama, şema doğrulaması

│ ├── builtin/ # Kendi araçlarınız (her dosya = bir araç + şeması)

│ └── custom/ # Araç tarafından üretilen araçlar buraya yerleşir

├── state/

│ ├── memory.py # Çalışma belleği, noktaya kaydetme, geri alma

│ └── plan.py # Plan takibi, adım tamamlanma durumu

├── orchestration/

│ ├── loop.py # Çekirdek ajan döngüsü

│ ├── router.py # Sonraki adım kararları: araç, alt-ajan, yetki verme

│ └── subagents.py # Alt-ajan oluşturma ve koordinasyonu

├── evaluation/

│ ├── linters.py # Özel doğrulamalar

│ └── validators.py # Çıktı doğrulaması (şema, testler, inceleme)

├── observability/

│ ├── tracer.py # Yapılandırılmış iz loglama

│ └── metrics.py # Maliyet, gecikme, başarı oranı takibi

├── prompts/

│ ├── system.md.jinja # Temel sistem promptu şablonu

│ └── stages/ # İş akışı aşaması başına bir şablon

├── evals/ # Regresyon testleri için benchmark görevleri

├── main.py

└── README.md

Her proje farklıdır, ancak ajanın nasıl yapılandırıldığına dair net bir zihinsel modelle başlamak gerekir. Unutmayın, büyük ihtimalle evrilecek; bu yüzden, harness’i değiştirmeye çalışan ajanları kafa karıştırabilecek örtüşmeler olmadan şeyleri mümkün olduğunca net tutun.

Bu modeli, muhtemelen önemli ölçüde AI kaymasına uğramış bir Hermes ajanıyla karşılaştırın. Kök AGENTS.md dosyasında 14 farklı alt AGENTS.md var. Ajanların mantığının çoğunu içeren /agents dizinde 395 ayrı dosya ve 145k satır kod bulunuyor. Bu, henüz becerileri veya promptları dahil etmiyor. Hermes’in bu kadar karmaşıklığa ihtiyaç duymasının gereksiz olduğunu söylemiyorum, ancak burada belli bir AI kaynaklı kayma olmuş olabileceğini söylemek büyük ihtimalle güvenli.

Harness’in kendisinde net bir sınır koymamak ve ajana kendi harness’ine katkıda bulunmasına izin vermek, teknik borç için mükemmel bir reçete. Projenin karmaşıklığı ve örtüşen modüller, AI kaymasının açık kanıtı olmasa da, yine de benim en iyi tahminim bu.

İyi şekilde iskeletlendirilmiş bir harness, en azından aşağıdaki konuları birbirinden ayırır:

• Model arayüzü katmanı: Harness’iniz ile LLM arasındaki sınır. İstem yapımı, belirteç sayımı, yanıt ayrıştırma, yeniden deneme mantığı ve modele özgü özelliklerle ilgilenir. Claude’dan GPT-4’e, oradan Gemini’ye geçtiğinizde değişmesi gereken tek katman budur.

• Araç/beceri katmanı: Araç tanımları, girdi doğrulama, yürütme. Her araç, açık bir şema ve belgeye sahip, kendi kendine yeten bir birim olmalıdır.

• Durum katmanı: Ajanın çalışma belleği, görev ilerlemesi, biriktirdiği bağlam, plan durumu ve ürettiği herhangi bir çıktı.

• Yönetim katmanı: İş akışı mantığının yaşadığı yerdir. Sıradaki adımın ne olacağını belirler: ajanın hangi aşamada olduğu, alt ajan çağırıp çağırmayacağı, checkpoint alıp almayacağı, bir insana yönlendirilip yönlendirilmeyeceği.

• Değerlendirme katmanı: Ajanın çıktılarının kalite eşiklerini karşılayıp karşılamadığını değerlendiren mekanizmalar. Bu, birim testlerini çalıştırmaktan ikinci bir modelle çıktıyı gözden geçirmeye, sonuca yönelik yapısal kısıtlamaları denetlemeye kadar her şey olabilir. Bu katman, iş akışı aşamaları arasındaki geçişleri kontrol altına alır.

Başarı ölçütü, bir insan veya ajanın her birini bağımsız olarak değerlendirebilmesi, her birini bağımsız olarak test edebilmesi ve her birini, zincirleme yan etkilerden endişe etmeden değiştirebilmesidir.

Bu iskelet çift amaç hizmet eder. Sistemi sizin için sürdürülebilir kılar. Aynı zamanda sistemi içinde çalışan ajana okunabilir kılar. Kendi araç tanımlarını okuyabilen, kendi durum şemasını anlayabilen ve kendi iş akışının yapısını görebilen bir ajan, daha fazla otonomiyle güvenilen bir ajandır.

Kendini Değiştiren Harness’ler

En güçlü harness mimarileri, ajanın kendi yeteneklerini genişletmesine olanak tanır. Pratik, mühendislik açısından: ajan tekrarlayan bir problemle karşılaşır, bunu çözmek için yeni bir araç yazar, bu aracı kendi araç katmanına kaydeder ve bundan sonra onu kullanır.

Bu zaten yaşanıyor. Kodlama ajanları, ardından gelen adımları kolaylaştırmak için görev ortasında yardımcı betikler yazıyor, yardımcı işlevler oluşturuyor ve küçük araçlar inşa ediyor. Sorun, mimarinizin bunu bir kazaya mı yoksa birinci sınıf bir yeteneğe mi baktığıdır.

Güvenli kendini değiştirme desteği için şunlara ihtiyacınız var:

• Modüler bir araç kaydı: Araçlar, orkestrasyon mantığına gömülmüş değil de yapılandırma (şemalar, açıklamalar, giriş noktaları) olarak tanımlanırsa, ajan yeni araçları yalnızca yeni bir yapılandırma girdisi ve buna karşılık gelen uygulamayı yazarak ekleyebilir. Çekirdek harness’e dokunmasına gerek yoktur.

• Kumbara içinde yürütme: Ajanın oluşturduğu her araç bir kumbara içinde çalışmalıdır. Çekirdek harness’in iç yapısına, kimlik bilgilerinize ya da belirlenen kapsamın dışındaki hiçbir şeye erişimi olmamalıdır. Harness, yerleşik araçlarına siz yazdığınız için güvenir. Ajan tarafından yazılan araçlar böyle bir güvenceyi varsayılan olarak kazanmaz.

• Kayıt öncesi doğrulama: Yeni bir araç kullanılabilir hale gelmeden önce temel kontrollerden geçmelidir. Şema ayrıştırılabiliyor mu? Bir duman testi başarılı oluyor mu? Var olan araçlarla çelişiyor mu? Otomatik düzenleyicileri kullanın.

📌 İskelet işi güvenli kılan odur. Bu olmadan, kendini değiştirme, sistemleri durduran türden zincirleme ve anlaşılmaz teknik borçlanma tarifidir.

İlkel #3. Görünürlük

Sistem ajanları, gelenekli yazılım sistemlerinin (genellikle) varsayılan olarak sunduğu deterministik korumaların hiçbirisini size vermez. Model bir kutu kapalıdır. “Mantık yürütme”si bir belirtey akışıdır. Kararları olasılıksaldır: model ile harness arasındaki etkileşim, sonradan akıl yürütülmesi son derece zor olabilecek belirsiz davranışlar üretir.

Görünürlük, sistem ajanlarını güvenilir kıldığınız yoldur. İyi bir görünürlük yığınıyla arızaları teşhis edebilir ve yinelemeli olarak geliştirebilirsiniz.

Her Şeyi İzleyin

En asgari gereklilik: Her model çağrısını ve her araç kullanımını tam girdiler ve çıktılarla loglayın. Tek tek hepsi. Bu, sizin izlenebilir trace (izleme) kaynağınıza karşılık gelir.

Bir tek görev için onlarca model çağrısı ve araç kullanımı söz konusu olabilir. Bir şeyler ters gittiğinde (ve gidecek), ne olduğunu tam olarak yeniden inşa edebiliyor olmanız gerekir:

• Her adımda prompt’ta, muhakemede ve yanıta ne vardı?

• Hangi araç hangi argümanlarla çağrıldı ve ne döndürdü?

• Harness bu sonucu nasıl yorumladı?

• İş akışı orkestrasyonunuz bir sonraki kararı ne verdi ve neden?

Bunu en başından itibaren inşa edin. Her model çağrısı bir loglama sarmalından geçmeli. Her araç kullanımı kaydedilmeli. Her durum geçişi açıklamalı olmalı.

Sorgulayabileceğiniz, filtreleyebileceğiniz ve görselleştirebileceğiniz yapılandırılmış formatlar kullanın (JSON, ebeveyn-çocuk ilişkileri içeren spans). Şu soruları yanıtlayabiliyor olmanız gerekir: “Geçen haftada bir aracı 3’ten fazla kez yeniden çağıran tüm görevleri bana göster” ya da “Görevlerin başarısız olmaya başladığı noktada ortalama bağlam penceresi kullanımı neydi?”

Bir örnek şema:

json

{

“schema_version”

“1.0”

“event_id”

“evt_000042”

“trace_id”

“trace_00121”

“task_id”

“task_001”

“session_id”

“session_007”

“parent_event_id”

“evt_000041”

“sequence”

“timestamp”

“2026-10-23T16:00:01.234Z”

“event_type”

“model.call”

“component”

“agent_runtime”

“status”

“success”

“duration_ms”

“input”

: {},

“output”

: {},

“metadata”

: {

“retry”

“worker_id”

“worker_01”

“tags”

: [

“demo”

]

},

“error”

null

}

İnsan Geri Bildirim Döngüleri

Son olarak gözlemlenebilirlik, insanların ajan davranışlarını inceleme ve müdahale etme yeteneğini de içerir. Bu, insan-in-the-loop (sürece insan dahil edilen) bir iş akışı adımıyla aynı şey değildir (her ikisi de değerlidir). Asıl olan, bir mühendisin şunları yapabilmesidir:

• Ajanın gerçek zamanlı çalışmasını izlemek; akıl yürütme ve eylemlerini oldubittiği gibi görmek

• Bir ajanı görev ortasında durdurup durum ve bağlamı inceleme

• Tamamlanmış bir görevi adım adım yeniden oynayarak davranışı anlama

• İnceleme ve etiketleme için belirli ajan davranışlarını işaretleme

Bu yetenekler, bir harness’i gerçekten güvenle iyileştirebileceğiniz bir sisteme dönüştüren unsurlardır. Ajanın nerede başarısız olduğunu nokta atışı belirleyin ve doğru davranışı tasarlayın.

Sonuç

İzlenen yol nettir. Modeller giderek daha yetenekli olmaya devam edecek. Ancak ham model yeteneği ile gerçek sorunları güvenilir şekilde çözen bir sistem arasındaki açık sürüp gidecektir. Bu açık, harness’tir. Bu açık artık sizin işinizdir.

Son on yılda başarılı olacak mühendisler, en fazla kodu yazanlar ya da en zekice prompt yazanlar olmayacak. Bunlar, model zekâsını güvenilir sonuçlara dönüştüren sistemleri tasarlayan, kuran ve işletenler olacak. İş akışı tasarımı. Mimari. Gözlemlenebilirlik. Bunlar temel ögelerdir. Bunları ustalaşın, herkesin güvendiği altyapıyı kuruyor olun.

Okuduğunuz için teşekkürler!

[1] Lopopolo, R. (2026, 11 Şubat). Harness engineering: Leveraging Codex in an agent-first world. OpenAI. https://openai.com/index/harness-engineering/

[2] Shinn, N., Cassano, F., Berman, E., Gopinath, A., Narasimhan, K., & Yao, S. (2023). Reflexion: Language agents with verbal reinforcement learning. Advances in Neural Information Processing Systems, , 8634–8652. https://doi.org/10.48550/arxiv.2303.11366

[3] Wang, L., Xu, W., Lan, Y., Hu, Z., Lan, Y., Lee, R. K.-W., & Lim, E.-P. (2023). Plan-and-solve prompting: Large dil modellerinde sıfır-örüntü düşünce zinciri muhakemesini iyileştirmek. Computational Linguistics Association 61. Yıllık Toplantı Bildirileri (Cilt 1: Uzun Makaleler), 2609–2634. https://doi.org/10.18653/v1/2023.acl-long.147

[4] Weng, L. (2026, 4 Temmuz). Kendini iyileştirme için harness mühendisliği. Lil’Log. https://lilianweng.github.io/posts/2026-07-04-harness/

[5] Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Dil modellerinde muhakeme ve eylemi birleştirmek. Learning Representations Uluslararası Konferansı (ICLR). https://doi.org/10.48550/arxiv.2210.03629