Bağlam mühendisliği: istemden önceki çalışma

spinny:~/writing $ vim context-engineering-agents.md

1~
2Yapay zeka ajanlarının küçük dünyasında şu anın sözcüğü bağlam mühendisliğidir.
3~
4Zaten yaptığımız bir şeyi satmak için başka bir etiket icat edilmiş gibi görünüyor. Kısmen öyle. Ancak çoğu zaman olduğu gibi bu etiket dikkat çekiyor çünkü gerçek bir acıya isim veriyor.
5~
6Sorun şu: Modeller sırf "düşünmüyorlar" diye başarısız olmuyorlar. Çoğu zaman başarısız oluyorlar çünkü onları çalışmaya yanlış odaya gönderiyoruz.
7~
8Onlara eski talimatları veriyoruz. Önemli dosyaları ondan saklıyoruz. Onlara çok uzun ve neyin önemli olduğunu söylemeyen belgeler veriyoruz. Onlara öncelik olmadan günlükleri gösteririz. Ne zaman kullanacaklarını açıklamadan onlara on araç veriyoruz. Sonra ajanın bilinmeyen bir dairede uyanmış biri gibi hareket etmesi bizi şaşırtıyor.
9~
10İstem, ona söylediğiniz ifadedir. Bağlam, onun etrafında hazırladığınız dünyadır.
11~
12## Hızlı mühendislikten bağlam mühendisliğine
13~
14Hızlı mühendislik genellikle yazı yazmak olarak düşünülürdü. Doğru kelimeleri seçin, doğru şekilde sorun, örnekler ekleyin, formatı belirtin.
15~
16Bağlam mühendisliği mimariye daha yakındır.
17~
18Sadece "talebi nasıl formüle edebilirim?" diye sormazsınız. Şunu sorar:
19~
20- Gerçekten hangi bilgilere ihtiyaç var?
21- gürültü nedir?
22- anında neyin kurtarılması gerekiyor?
23- ne hatırlanmalı?
24- hangi araçlar açığa çıkarılmalıdır?
25- hangi talimatlar kararlıdır ve hangileri göreve bağlıdır?
26- Temsilcinin neyin yetkili olduğunu anlamasını nasıl sağlayabilirim?
27~
28Bu ince ama çok büyük bir değişiklik. Çünkü aracılarla çalıştığınızda bağlam statik bir blok değildir. Her adımda değişiyor.
29~
30Aracı bir dosyayı açar, bir şeyler öğrenir, bir test yapar, bir hata alır, planı günceller, bir aracı çağırır, bir bağımlılığı keşfeder. Her turda yanına neleri alıp neyi dışarıda bırakacağına karar vermesi gerekiyor.
31~
32Bu mühendisliktir.
33~
34## Bağlam çöp sahası değil
35~
36Büyük bağlam pencerelerine sahip şablonlar bizi baştan çıkardı: hadi her şeyi içine koyalım.
37~
38Bu anlaşılabilir bir durum. Bir milyon jetonum varsa neden seçeyim?
39~
40Çünkü her şeyi koyabilseniz bile, bu her şeyin işe yaradığı anlamına gelmez. Aslında gürültünün bir bedeli vardır. Belirteçlere mal olur, dikkat gerektirir, gecikmeye mal olur, kaliteye mal olur. Bir model, tıpkı bizim gibi yirmi sekme açtığımızda nedenini hatırlamadığımızda alakasız ayrıntılar içinde kaybolabiliyor.
41~
42İyi bağlamın bir hiyerarşisi vardır:
43~
441. sistem talimatları ve politikaları;
452. özel amaç;
463. mevcut durum;
474. ilgili veriler;
485. kısıtlamalar;
496. mevcut araçlar;
507. Halihazırda alınmış kararları takip edin.
51~
52Her şeyi aynı seviyede ele almaya gerek yok. Bir kullanıcı komutu eski bir nottan daha değerlidir. Başarısız bir test artık üç ay önceki estetik tercihten daha değerli. Bir güvenlik politikası üretim kısayolundan daha değerlidir.
53~
54Bağlam mühendisliği aynı zamanda yalnızca verilere değil, ağırlıklara da yer verilmesi anlamına gelir.
55~
56## Bellek: daha az hatırla, daha iyi hatırla
57~
58Ajanlarda hafıza en kaygan konulardan biridir.
59~
60Bir kullanıcı olarak temsilcinin sizi tanımasını istersiniz. Onun üslubunu, planını, geleneklerini, önceden kararlaştırılmış şeyleri hatırlamasını istiyorsun. Bir mühendis olarak, her kalıcı hafızanın aynı zamanda bir risk olduğunu da biliyorsunuz: Yanlış, eski, fazla kişisel, fazla genel ve doğrulanamaz olabilir.
61~
62Yararlı bir hafızanın en az üç özelliğe sahip olması gerekir:
63~
64- kaynak: bu bilgi nereden geliyor?
65- tarih: ne zaman doğruydu?
66- amaç: ne tür bir görev için kullanılmalı?
67~
68Bu üç şey olmadan hafıza batıl inanç haline gelir.
69~
70Fail hafızasını büyülü bir zihin olarak değil, bir çalışma kitabı olarak düşünmeyi seviyorum. Geçici notlar, onaylanmış kararlar, stil tercihleri, teknik kısıtlamalar, kaynaklara bağlantılar var. Bazı şeylerin süresi doluyor. Bazılarının yeniden yazılması gerekiyor. Temsilci onları yanlış anladığı için bazılarının elenmesi gerekiyor.
71~
72İyi bir sistemin bu bakımı normal hale getirmesi gerekir. Kahramanca değil.
73~
74## Erişim ve araçlar aynı şey değildir
75~
76Bağlam hakkında konuştuğumuzda çoğu zaman kendimizi hemen RAG'da buluruz. Gömme, vektör veritabanı, parçalama, yeniden sıralama.
77~
78Hepsi faydalı. Ancak geri alma, bilgiyi modele getirmenin yalnızca bir yoludur. O tek kişi değil.
79~
80Bir aracı, dosyaları okuyarak, bir API'yi sorgulayarak, bir MCP sunucusunu arayarak, bir tarayıcı açarak, testler çalıştırarak, Slack'te arama yaparak, kontrol paneline bakarak, insana sorarak bağlam elde edebilir.
81~
82İlginç olan, hangi rotanın ne zaman kullanılacağına karar vermektir.
83~
84Temsilcinin tarihsel bir soruyu yanıtlaması gerekiyorsa, belki de yalnızca geri almak yeterlidir. Bir hatayı düzeltmek zorundaysa gerçek kodu okumak zorundadır. Bir dağıtımın neden başarısız olduğunu anlaması gerekiyorsa yeni günlüklere bakması gerekir. Bir müşteriye yazmanız gerekiyorsa biletin tonunu, geçmişini ve durumunu almanız gerekir. Eğer üretimle ilgili bir faaliyette bulunacaksa izin istemelidir.
85~
86Bağlam bir veritabanı değildir. Bu bir iş akışıdır.
87~
88## İyi bir temsilci nasıl görmezden gelineceğini de bilir
89~
90Temsilcilerde olgunluğun bir işareti şunu söyleyebilmektir: Bu bilgiye ihtiyacım yok.
91~
92Önemsiz gibi görünüyor ama çok zor. Pek çok etmenli sistem birikir. Her araç çağrısı metin ekler. Her hata arabellekte kalır. Okunan her dosya yığına eklenir. Sonuçta modelin çok uzun bir geçmişi var ve haritası yok.
93~
94Sıkıştırma gereklidir. Ara senteze ihtiyaç vardır. Yapılandırılması gerekiyor.
95~
96"Olan bu kadar" değil ama:
97~
98- amaç hâlâ geçerli;
99- mevcut hipotez;
100- dosyalar zaten kontrol edildi;
101- alınan kararlar;
102- açık riskler;
103- sonraki eylem.
104~
105Bu, temsilciyi daha az teatral ve daha yararlı kılar. Daha akıllı göründüğü için değil, düzenli bir masayla çalıştığı için.
106~
107## Hızlı sanatçılar için değil, ekipler için bağlam mühendisliği
108~
109Bu konunun ilgimi çekmesinin nedeni sorumluluğun bireyden sisteme kaydırılmasıdır.
110~
111Hızlı mühendislikte, modelle en iyi şekilde konuşabilen kişi çoğunlukla kazanır. Bağlam mühendisliğinde işini en iyi organize eden ekip kazanır: dokümantasyon, kurallar, sorunlar, günlükler, testler, sahiplik, adlandırma, kaynaklar.
112~
113Temiz bir depo daha iyi bir bağlam haline gelir. İyi yazılmış bir konu daha iyi bir yakıt haline gelir. Güncelleştirilmiş bir runbook, belirteçlerden ve endişelerden tasarruf sağlar. Açık bir değişiklik günlüğü halüsinasyonları azaltır.
114~
115Bu iyi ve biraz da rahatsız edici bir haber. Güzel çünkü iyi uygulamaları ödüllendiriyor. Uygunsuz çünkü her şeyi akıllı bir istemle çözemezsiniz.
116~
117Ajanlar buldukları sistemin hijyenini artırır.
118~
119## Yarın bunu nasıl uygulardım
120~
121Bağlam mühendisliğini gerçek bir projeye dahil edecek olsaydım küçük şeylerden başlardım:
122~
123- kısa ve bakımı yapılmış bir proje talimat dosyası;
124- beklenen çıktıya ilişkin iyi örnekler;
125- mevcut araçların ve bunların kullanılacağı durumların bir listesi;
126- Alıntı yapılabilir bir şekilde yazılmış mimari kararlar;
127- asgari zorunlu bağlamla ilgili sorun;
128- günlükleri ve testleri almak kolaydır;
129- İnsanlar tarafından değiştirilebilen kalıcı hafıza.
130~
131Daha sonra basit bir şeyi ölçerdim: Temsilcinin kaç kez açıklama istemesi gerekiyor veya yanlış yöne gidiyor?
132~
133Sık sık oluyorsa hemen daha büyük bir model eklemezdim. Bağlama bakardım.
134~
135## Okumalarım
136~
137Bağlam mühendisliği biraz şişirilmiş bir kelime, evet. Ama konsept sağlam.
138~
139Bize bir ajanın zekasının sadece modelde olmadığını hatırlatır. Önemli olan onun için hazırladığımız ortamda yatıyor: Ne gördüğü, ne hatırladığı, ne yapabileceği, ne yapmasının yasak olduğu, hangi kaynakları doğru kabul ettiği.
140~
141İnsani tarafı şudur: Ortamı iyi hazırlamak bir bakım şeklidir. Bu menajere ve aynı zamanda ekibe şunu söylemektir: "Tahmin etmenizi istemiyorum, ihtiyacınız olan şeye sahip olmanızı istiyorum."
142~
143Daha az büyü. Temiz oda. Bizim kadar acentelerin de buna ihtiyacı var.
144~
145## Kaynaklar
146~
147- [LangChain Blogu: Bağlam mühendisliğinin yükselişi](https://blog.langchain.com/the-rise-of-context-engineering/)
148- [Simon Willison: Bağlam mühendisliği](https://simonwillison.net/2025/Jun/27/context-engineering/)
149- [Model Bağlamı Protokolü: Giriş](https://modelcontextprotocol.io/introduction)
150- [Antropik: Etkili aracılar oluşturmak](https://www.anthropic.com/engineering/building-active-agents)
151- [OpenAI: İnşaat acenteleri için yeni araçlar](https://openai.com/index/new-tools-for-building-agents/)
152~

NORMAL · context-engineering-agents.md [readonly]152 lines · :q to close

2Yapay zeka ajanlarının küçük dünyasında şu anın sözcüğü bağlam mühendisliğidir.

4Zaten yaptığımız bir şeyi satmak için başka bir etiket icat edilmiş gibi görünüyor. Kısmen öyle. Ancak çoğu zaman olduğu gibi bu etiket dikkat çekiyor çünkü gerçek bir acıya isim veriyor.

6Sorun şu: Modeller sırf "düşünmüyorlar" diye başarısız olmuyorlar. Çoğu zaman başarısız oluyorlar çünkü onları çalışmaya yanlış odaya gönderiyoruz.

8Onlara eski talimatları veriyoruz. Önemli dosyaları ondan saklıyoruz. Onlara çok uzun ve neyin önemli olduğunu söylemeyen belgeler veriyoruz. Onlara öncelik olmadan günlükleri gösteririz. Ne zaman kullanacaklarını açıklamadan onlara on araç veriyoruz. Sonra ajanın bilinmeyen bir dairede uyanmış biri gibi hareket etmesi bizi şaşırtıyor.

10İstem, ona söylediğiniz ifadedir. Bağlam, onun etrafında hazırladığınız dünyadır.

11~

12## Hızlı mühendislikten bağlam mühendisliğine

13~

14Hızlı mühendislik genellikle yazı yazmak olarak düşünülürdü. Doğru kelimeleri seçin, doğru şekilde sorun, örnekler ekleyin, formatı belirtin.

15~

16Bağlam mühendisliği mimariye daha yakındır.

17~

18Sadece "talebi nasıl formüle edebilirim?" diye sormazsınız. Şunu sorar:

19~

20- Gerçekten hangi bilgilere ihtiyaç var?

21- gürültü nedir?

22- anında neyin kurtarılması gerekiyor?

23- ne hatırlanmalı?

24- hangi araçlar açığa çıkarılmalıdır?

25- hangi talimatlar kararlıdır ve hangileri göreve bağlıdır?

26- Temsilcinin neyin yetkili olduğunu anlamasını nasıl sağlayabilirim?

27~

28Bu ince ama çok büyük bir değişiklik. Çünkü aracılarla çalıştığınızda bağlam statik bir blok değildir. Her adımda değişiyor.

29~

30Aracı bir dosyayı açar, bir şeyler öğrenir, bir test yapar, bir hata alır, planı günceller, bir aracı çağırır, bir bağımlılığı keşfeder. Her turda yanına neleri alıp neyi dışarıda bırakacağına karar vermesi gerekiyor.

31~

32Bu mühendisliktir.

33~

34## Bağlam çöp sahası değil

35~

36Büyük bağlam pencerelerine sahip şablonlar bizi baştan çıkardı: hadi her şeyi içine koyalım.

37~

38Bu anlaşılabilir bir durum. Bir milyon jetonum varsa neden seçeyim?

39~

40Çünkü her şeyi koyabilseniz bile, bu her şeyin işe yaradığı anlamına gelmez. Aslında gürültünün bir bedeli vardır. Belirteçlere mal olur, dikkat gerektirir, gecikmeye mal olur, kaliteye mal olur. Bir model, tıpkı bizim gibi yirmi sekme açtığımızda nedenini hatırlamadığımızda alakasız ayrıntılar içinde kaybolabiliyor.

41~

42İyi bağlamın bir hiyerarşisi vardır:

43~

441. sistem talimatları ve politikaları;

452. özel amaç;

463. mevcut durum;

474. ilgili veriler;

485. kısıtlamalar;

496. mevcut araçlar;

507. Halihazırda alınmış kararları takip edin.

51~

52Her şeyi aynı seviyede ele almaya gerek yok. Bir kullanıcı komutu eski bir nottan daha değerlidir. Başarısız bir test artık üç ay önceki estetik tercihten daha değerli. Bir güvenlik politikası üretim kısayolundan daha değerlidir.

53~

54Bağlam mühendisliği aynı zamanda yalnızca verilere değil, ağırlıklara da yer verilmesi anlamına gelir.

55~

56## Bellek: daha az hatırla, daha iyi hatırla

57~

58Ajanlarda hafıza en kaygan konulardan biridir.

59~

60Bir kullanıcı olarak temsilcinin sizi tanımasını istersiniz. Onun üslubunu, planını, geleneklerini, önceden kararlaştırılmış şeyleri hatırlamasını istiyorsun. Bir mühendis olarak, her kalıcı hafızanın aynı zamanda bir risk olduğunu da biliyorsunuz: Yanlış, eski, fazla kişisel, fazla genel ve doğrulanamaz olabilir.

61~

62Yararlı bir hafızanın en az üç özelliğe sahip olması gerekir:

63~

64- kaynak: bu bilgi nereden geliyor?

65- tarih: ne zaman doğruydu?

66- amaç: ne tür bir görev için kullanılmalı?

67~

68Bu üç şey olmadan hafıza batıl inanç haline gelir.

69~

70Fail hafızasını büyülü bir zihin olarak değil, bir çalışma kitabı olarak düşünmeyi seviyorum. Geçici notlar, onaylanmış kararlar, stil tercihleri, teknik kısıtlamalar, kaynaklara bağlantılar var. Bazı şeylerin süresi doluyor. Bazılarının yeniden yazılması gerekiyor. Temsilci onları yanlış anladığı için bazılarının elenmesi gerekiyor.

71~

72İyi bir sistemin bu bakımı normal hale getirmesi gerekir. Kahramanca değil.

73~

74## Erişim ve araçlar aynı şey değildir

75~

76Bağlam hakkında konuştuğumuzda çoğu zaman kendimizi hemen RAG'da buluruz. Gömme, vektör veritabanı, parçalama, yeniden sıralama.

77~

78Hepsi faydalı. Ancak geri alma, bilgiyi modele getirmenin yalnızca bir yoludur. O tek kişi değil.

79~

80Bir aracı, dosyaları okuyarak, bir API'yi sorgulayarak, bir MCP sunucusunu arayarak, bir tarayıcı açarak, testler çalıştırarak, Slack'te arama yaparak, kontrol paneline bakarak, insana sorarak bağlam elde edebilir.

81~

82İlginç olan, hangi rotanın ne zaman kullanılacağına karar vermektir.

83~

84Temsilcinin tarihsel bir soruyu yanıtlaması gerekiyorsa, belki de yalnızca geri almak yeterlidir. Bir hatayı düzeltmek zorundaysa gerçek kodu okumak zorundadır. Bir dağıtımın neden başarısız olduğunu anlaması gerekiyorsa yeni günlüklere bakması gerekir. Bir müşteriye yazmanız gerekiyorsa biletin tonunu, geçmişini ve durumunu almanız gerekir. Eğer üretimle ilgili bir faaliyette bulunacaksa izin istemelidir.

85~

86Bağlam bir veritabanı değildir. Bu bir iş akışıdır.

87~

88## İyi bir temsilci nasıl görmezden gelineceğini de bilir

89~

90Temsilcilerde olgunluğun bir işareti şunu söyleyebilmektir: Bu bilgiye ihtiyacım yok.

91~

92Önemsiz gibi görünüyor ama çok zor. Pek çok etmenli sistem birikir. Her araç çağrısı metin ekler. Her hata arabellekte kalır. Okunan her dosya yığına eklenir. Sonuçta modelin çok uzun bir geçmişi var ve haritası yok.

93~

94Sıkıştırma gereklidir. Ara senteze ihtiyaç vardır. Yapılandırılması gerekiyor.

95~

96"Olan bu kadar" değil ama:

97~

98- amaç hâlâ geçerli;

99- mevcut hipotez;

100- dosyalar zaten kontrol edildi;

101- alınan kararlar;

102- açık riskler;

103- sonraki eylem.

104~

105Bu, temsilciyi daha az teatral ve daha yararlı kılar. Daha akıllı göründüğü için değil, düzenli bir masayla çalıştığı için.

106~

107## Hızlı sanatçılar için değil, ekipler için bağlam mühendisliği

108~

109Bu konunun ilgimi çekmesinin nedeni sorumluluğun bireyden sisteme kaydırılmasıdır.

110~

111Hızlı mühendislikte, modelle en iyi şekilde konuşabilen kişi çoğunlukla kazanır. Bağlam mühendisliğinde işini en iyi organize eden ekip kazanır: dokümantasyon, kurallar, sorunlar, günlükler, testler, sahiplik, adlandırma, kaynaklar.

112~

113Temiz bir depo daha iyi bir bağlam haline gelir. İyi yazılmış bir konu daha iyi bir yakıt haline gelir. Güncelleştirilmiş bir runbook, belirteçlerden ve endişelerden tasarruf sağlar. Açık bir değişiklik günlüğü halüsinasyonları azaltır.

114~

115Bu iyi ve biraz da rahatsız edici bir haber. Güzel çünkü iyi uygulamaları ödüllendiriyor. Uygunsuz çünkü her şeyi akıllı bir istemle çözemezsiniz.

116~

117Ajanlar buldukları sistemin hijyenini artırır.

118~

119## Yarın bunu nasıl uygulardım

120~

121Bağlam mühendisliğini gerçek bir projeye dahil edecek olsaydım küçük şeylerden başlardım:

122~

123- kısa ve bakımı yapılmış bir proje talimat dosyası;

124- beklenen çıktıya ilişkin iyi örnekler;

125- mevcut araçların ve bunların kullanılacağı durumların bir listesi;

126- Alıntı yapılabilir bir şekilde yazılmış mimari kararlar;

127- asgari zorunlu bağlamla ilgili sorun;

128- günlükleri ve testleri almak kolaydır;

129- İnsanlar tarafından değiştirilebilen kalıcı hafıza.

130~

131Daha sonra basit bir şeyi ölçerdim: Temsilcinin kaç kez açıklama istemesi gerekiyor veya yanlış yöne gidiyor?

132~

133Sık sık oluyorsa hemen daha büyük bir model eklemezdim. Bağlama bakardım.

134~

135## Okumalarım

136~

137Bağlam mühendisliği biraz şişirilmiş bir kelime, evet. Ama konsept sağlam.

138~

139Bize bir ajanın zekasının sadece modelde olmadığını hatırlatır. Önemli olan onun için hazırladığımız ortamda yatıyor: Ne gördüğü, ne hatırladığı, ne yapabileceği, ne yapmasının yasak olduğu, hangi kaynakları doğru kabul ettiği.

140~

141İnsani tarafı şudur: Ortamı iyi hazırlamak bir bakım şeklidir. Bu menajere ve aynı zamanda ekibe şunu söylemektir: "Tahmin etmenizi istemiyorum, ihtiyacınız olan şeye sahip olmanızı istiyorum."

142~

143Daha az büyü. Temiz oda. Bizim kadar acentelerin de buna ihtiyacı var.

144~

145## Kaynaklar

146~

147- [LangChain Blogu: Bağlam mühendisliğinin yükselişi](https://blog.langchain.com/the-rise-of-context-engineering/)

148- [Simon Willison: Bağlam mühendisliği](https://simonwillison.net/2025/Jun/27/context-engineering/)

149- [Model Bağlamı Protokolü: Giriş](https://modelcontextprotocol.io/introduction)

150- [Antropik: Etkili aracılar oluşturmak](https://www.anthropic.com/engineering/building-active-agents)

151- [OpenAI: İnşaat acenteleri için yeni araçlar](https://openai.com/index/new-tools-for-building-agents/)

152~