Ana içeriğe atla
OpenAI

23 Ocak 2026

Mühendislik

Codex otonom ajan döngüsünü çözme

Michael Bolin, Teknik Personel Üyesi

Yükleniyor...

Codex CLI⁠(yeni bir pencerede açılır), makinenizde güvenli ve verimli bir şekilde çalışarak yüksek kaliteli ve güvenilir yazılım değişiklikleri üreten, platformlar arası otonom ajanımızdır. Dünya standartlarında bir otonom ajan nasıl inşa edilir konusunda, Nisan ayında CLI'yı ilk kez kullanıma sunduğumuzdan beri⁠ çok şey öğrendik. Bu analizleri daha derinlemesine ele almak için, Codex'in nasıl çalıştığının farklı yönlerini ve deneyimle kazanılmış önemli dersleri inceleyeceğimiz devam eden bir serinin ilk yazısıyla başlıyoruz. (Codex CLI'nın nasıl oluşturulduğuna dair daha ayrıntılı bilgi için https://github.com/openai/codex⁠(yeni bir pencerede açılır) adresindeki açık kaynak depomuzu inceleyin. Tasarım kararlarımızın daha ince ayrıntılarının çoğu, daha fazla bilgi edinmek isterseniz GitHub işlem öğeleri ve pull request'lerinde kayıt altına alınmıştır.)

Başlangıç olarak, kullanıcı, model ve modelin çağırdığı araçlar arasındaki etkileşimi düzenlemekten sorumlu olan Codex CLI'daki temel mantık olan otonom ajan döngüsüne odaklanacağız. Bu yazının, bir LLM'den yararlanırken otonom ajanımızın (veya donanımın) oynadığı rolü size iyi bir şekilde gösterdiğini umuyoruz.

Başlamadan önce, terminoloji hakkında kısa bir not: OpenAI'da "Codex"; Codex CLI, Codex Cloud ve Codex VS Code uzantısı gibi otonom ajan çözümlerini kapsar. Bu yazı, Codex CLI aracılığıyla sunulan ve tüm Codex deneyimlerinin temelini oluşturan ana otonom ajan döngüsü ve yürütme mantığını sağlayan Codex donanımına odaklanmaktadır. Burada kolaylık sağlamak amacıyla "Codex" ve "Codex CLI" terimlerini birbirinin yerine kullanacağız.

Otonom ajan döngüsü

Her yapay zeka otonom ajanının merkezinde "otonom ajan döngüsü" adı verilen bir yapı bulunur. Otonom ajan döngüsünün basitleştirilmiş bir gösterimi şu şekildedir:

Bir yapay zeka sisteminin bir kullanıcı talebini nasıl işlediğini, araçları nasıl çağırdığını, sonuçları nasıl gözlemlediğini, planını nasıl güncellediğini ve çıktıları nasıl döndürdüğünü gösteren "Ajan döngüsü" başlıklı diyagram. Oklar, kullanıcı girdisi, model muhakemesi, araç eylemleri ve nihai yanıt gibi adımları birbirine bağlar.

Başlamak için otonom ajan, model için hazırladığı ve komut olarak bilinen metinsel talimatlar kümesine dahil etmek üzere kullanıcıdan girdi alır.

Bir sonraki adım, modele talimatlarımızı göndererek ve ondan bir yanıt üretmesini isteyerek modeli sorgulamaktır; bu süreç çıkarım olarak bilinir. Çıkarım sırasında, metin komutu önce bir dizi girdi token'ına⁠(yeni bir pencerede açılır) (modelin kelime dağarcığını indeksleyen tamsayılar) çevrilir. Bu token'lar daha sonra modelden örnekleme yapmak için kullanılır ve yeni bir çıktı token dizisi oluşturur.

Çıktı token'ları tekrar metne çevrilir ve bu metin modelin yanıtı olur. Token'lar artımlı olarak üretildiğinden bu çeviri, model çalışırken gerçekleşebilir; bu nedenle birçok LLM tabanlı uygulama, akış halinde çıktı gösterir. Uygulamada, çıkarım genellikle metin üzerinde çalışan bir API'nin arkasında kapsüllenerek, tokenizasyon ayrıntılarını soyutlar.

Çıkarım adımının sonucunda, model ya (1) kullanıcının orijinal girdisine nihai bir yanıt üretir ya da (2) otonom ajanın gerçekleştirmesi beklenen bir araç çağrısı talep eder (örn. "ls komutunu çalıştır ve çıktıyı bildir"). (2) olması durumunda otonom ajan, araç çağrısını gerçekleştirir ve çıktısını orijinal komuta ekler. Bu çıktı, modeli yeniden sorgulamak için yeni bir girdi oluşturmak amacıyla kullanılır; otonom ajan bu yeni bilgiyi dikkate alarak tekrar deneyebilir.

Bu süreç, model araç çağrıları üretmeyi bırakıp bunun yerine kullanıcıya bir mesaj oluşturana kadar (OpenAI modellerinde asistan mesajı olarak adlandırılır) tekrarlanır. Çoğu durumda bu mesaj, kullanıcının ilk talebine doğrudan yanıt verir, ancak aynı zamanda bir takip sorusu da olabilir.

Otonom ajan, yerel ortamı değiştirebilen araç çağrılarını gerçekleştirebildiği için "çıktısı" sadece asistan mesajıyla sınırlı kalmaz. Çoğu durumda, bir yazılım otonom ajanının birincil çıktısı, makinenizde yazdığı veya düzenlediği koddur. Bununla birlikte, her tur, "İstediğiniz architecture.md dosyasını ekledim" gibi bir asistan mesajıyla sona erer ve bu, otonom ajan döngüsünde bir sonlandırma durumunu belirtir. Otonom ajanın bakış açısından, işi tamamlanmıştır ve kontrol kullanıcıya geri döner.

Diyagramda gösterilen kullanıcı girdisi ile otonom ajan yanıtı arasındaki yolculuk, bir konuşmanın bir turu (Codex'te bir mesaj dizisi ) olarak adlandırılır. Bu konuşma turu; model çıkarımı ve araç çağrıları arasında birçok yineleme içerebilir. Mevcut bir sohbete yeni bir mesaj gönderdiğinizde, sohbet geçmişi yeni tur için istemlerin bir parçası olarak dahil edilir. Bu istemler, önceki turlardan gelen mesajları ve araç çağrılarını içerir:

Bir yapay zeka ajanının yinelemeli olarak kullanıcı girdisini nasıl aldığını, eylemleri nasıl oluşturduğunu, araçlara nasıl başvurduğunu, durumu nasıl güncellediğini ve sonuçları nasıl döndürdüğünü gösteren "Çok turlu ajan döngüsü" başlıklı diyagram. Otonom ajanın akıl yürütme döngüsünü gösteren etiketli adımlar, oklar ve örnek araç çıktıları içerir.

Bu, konuşma büyüdükçe modeli örneklemek için kullanılan komutun uzunluğunun da arttığı anlamına gelir. Bu uzunluk önemlidir çünkü her modelin bir bağlam penceresi vardır ve bu, tek bir çıkarım çağrısında kullanabileceği maksimum token sayısını belirler. Bu pencerenin hem girdi hem de çıktı token'larını içerdiğini unutmayın. Tahmin edebileceğiniz gibi, bir otonom ajan tek bir turda yüzlerce araç çağrısı yapmaya karar verebilir ve bu da bağlam penceresini potansiyel olarak tüketebilir. Bu nedenle bağlam penceresi yönetimi, otonom ajanın birçok sorumluluğundan biridir. Şimdi, Codex'in otonom ajan döngüsünü nasıl çalıştırdığını görmek için derinlemesine inceleyelim.

Model çıkarımı

Codex CLI, model çıkarımı gerçekleştirmek için Responses API⁠(yeni bir pencerede açılır)'ye HTTP istekleri gönderir. Bilginin Codex üzerinden nasıl aktığını inceleyeceğiz; Codex, otonom ajan döngüsünü çalıştırmak için Responses API'yi kullanır.

Codex CLI'nin kullandığı Responses API uç noktası yapılandırılabilir⁠(yeni bir pencerede açılır), bu nedenle Responses API'yi uygulayan⁠(yeni bir pencerede açılır) herhangi bir uç nokta ile kullanılabilir:

Bir konuşmada ilk çıkarım çağrısı için Codex'in komutunu nasıl oluşturduğunu inceleyelim.

İlk komutu oluşturma

Bir son kullanıcı olarak, Responses API'yi sorguladığınızda modeli örneklemek için kullanılan komutu tam olarak belirtmezsiniz. Bunun yerine, sorgunuzun bir parçası olarak çeşitli girdi türleri belirtirsiniz ve Responses API sunucusu, bu bilgileri modelin tüketmesi için tasarlanmış bir komuta nasıl yapılandıracağına karar verir. Komutu bir "öğe listesi" olarak düşünebilirsiniz; bu bölüm, komutunuzun bu listeye nasıl dönüştüğünü açıklayacaktır.

Başlangıç komutunda, listedeki her öğe bir rolle ilişkilendirilmiştir. role, ilişkili içeriğin ne kadar önemli olduğunu belirtir ve öncelik sırasına göre azalan şu değerlerden biridir: system, developer, user, assistant.

Responses API⁠(yeni bir pencerede açılır), birçok parametre içeren bir JSON yükünü alır. Biz şu üçüne odaklanacağız:

Codex'te instructions alanı, belirtilmişse ~/.codex/config.toml içindeki model_instructions_file⁠(yeni bir pencerede açılır) dosyasından okunur; aksi takdirde, model ile ilişkili base_instructions kullanılır⁠(yeni bir pencerede açılır). Modele özgü talimatlar Codex deposunda yer alır ve CLI'ya dahil edilir (örn. gpt-5.2-codex_prompt.md⁠(yeni bir pencerede açılır)).

tools alanı, Responses API tarafından tanımlanan bir şemaya uygun araç tanımlarının listesidir. Codex için, Codex CLI tarafından sağlanan araçlar, Codex'e sunulması gereken Responses API araçları ve genellikle MCP sunucuları aracılığıyla kullanıcı tarafından sağlanan araçlar dahildir:

JavaScript

1
[
2
  // Codex's default shell tool for spawning new processes locally.
3
  {
4
    "type": "function",
5
    "name": "shell",
6
    "description": "Runs a shell command and returns its output...",
7
    "strict": false,
8
    "parameters": {
9
      "type": "object",
10
      "properties": {
11
        "command": {"type": "array", "description": "The command to execute", ...},
12
        "workdir": {"description": "The working directory...", ...},
13
        "timeout_ms": {"description": "The timeout for the command...", ...},
14
        ...
15
      },
16
      "required": ["command"],
17
    }
18
  }
19

20
  // Codex's built-in plan tool.
21
  {
22
    "type": "function",
23
    "name": "update_plan",
24
    "description": "Updates the task plan...",
25
    "strict": false,
26
    "parameters": {
27
      "type": "object",
28
      "properties": {"plan":..., "explanation":...},
29
      "required": ["plan"]
30
    }
31
  },
32

33
  // Web search tool provided by the Responses API.
34
  {
35
    "type": "web_search",
36
    "external_web_access": false
37
  },
38

39
  // MCP server for getting weather as configured in the
40
  // user's ~/.codex/config.toml.
41
  {
42
    "type": "function",
43
    "name": "mcp__weather__get-forecast",
44
    "description": "Get weather alerts for a US state",
45
    "strict": false,
46
    "parameters": {
47
      "type": "object",
48
      "properties": {"latitude": {...}, "longitude": {...}},
49
      "required": ["latitude", "longitude"]
50
    }
51
  }
52
]

Son olarak, JSON yükünün input alanı, öğelerden oluşan bir listedir. Codex aşağıdaki öğeleri⁠(yeni bir pencerede açılır) input içine ekler ve ardından kullanıcı mesajını ekler:

1. role=developer içeren ve yalnızca Codex tarafından sağlanan shell aracına uygulanan sandbox ortamını, araçlar bölümünde tanımlayan bir mesaj. Yani, MCP sunucularından sağlanan diğer araçlar Codex tarafından sandbox edilmez ve kendi koruma önlemlerini uygulamaktan sorumludur.

Mesaj, temel içerik parçalarının Codex CLI ile birlikte paketlenmiş Markdown parçacıklarından alındığı bir şablondan oluşturulur; örneğin, workspace_write.md⁠(yeni bir pencerede açılır) ve on_request.md⁠(yeni bir pencerede açılır):

Düz Metin

1
<permissions instructions>
2
  - description of the sandbox explaining file permissions and network access
3
  - instructions for when to ask the user for permissions to run a shell command
4
  - list of folders writable by Codex, if any
5
</permissions instructions>

2. (İsteğe bağlı) Kullanıcının config.toml dosyasından okunan developer_instructions değerini içeren role=developer rolüne sahip bir mesaj.

3. (İsteğe bağlı) İçeriği "kullanıcı talimatları" olan role=user içeren bir mesaj; bu talimatlar tek bir dosyadan alınmaz, birden çok kaynaktan bir araya getirilir⁠(yeni bir pencerede açılır). Genel olarak, daha ayrıntılı talimatlar daha sonra görünür:

4. role=user içeren ve otonom ajanın şu anda çalıştığı yerel ortamı tanımlayan bir mesaj. Bu, geçerli çalışma dizinini ve kullanıcının kabuğunu belirtir⁠(yeni bir pencerede açılır):

Düz Metin

1
<environment_context>
2
  <cwd>/Users/mbolin/code/codex5</cwd>
3
  <shell>zsh</shell>
4
</environment_context>

Codex, input'u başlatmak için yukarıdaki tüm hesaplamaları yaptıktan sonra kullanıcı mesajını ekler ve konuşmayı başlatır.

Önceki örnekler her bir mesajın içeriğine odaklanıyordu, ancak input içindeki her bir öğenin type, role⁠(yeni bir pencerede açılır) ve content içeren bir JSON nesnesi olduğunu unutmayın:

JSON

1
{
2
  "type": "message",
3
  "role": "user",
4
  "content": [
5
    {
6
      "type": "input_text",
7
      "text": "Add an architecture diagram to the README.md"
8
    }
9
  ]
10
}

Codex, Responses API'ye göndermek üzere tam JSON yükünü oluşturduktan sonra, ~/.codex/config.toml dosyasında Responses API uç noktasının nasıl yapılandırıldığına bağlı olarak bir Yetkilendirme başlığı ile HTTP POST isteği yapar (belirtilmişse ek HTTP başlıkları ve sorgu parametreleri eklenir).

OpenAI Responses API sunucusu isteği aldığında, JSON'ı kullanarak model için komutu aşağıdaki şekilde türetir (emin olmak gerekirse, Responses API'nin özel bir uygulaması farklı bir seçim yapabilir):

Bir yapay zeka otonom ajan döngüsünde tek bir adımı gösteren anlık görüntü diyagramı. Bir kullanıcı isteği modele girer ve model bir düşünce, bir araç adıyla bir eylem ve bir araç girdisi üretir. Diyagram, araç çağrılmadan önce bu ara akıl yürütme adımını öne çıkarır.

Gördüğünüz gibi, komuttaki ilk üç öğenin sırası istemci tarafından değil, sunucu tarafından belirlenir. Bununla birlikte, bu üç öğeden yalnızca system message içeriği sunucu tarafından kontrol edilir; çünkü tools ve instructions istemci tarafından belirlenir. Bunları, komutu tamamlamak için JSON yükünden gelen input takip eder.

Artık komutumuza sahip olduğumuza göre, modeli çalıştırmaya hazırız.

İlk tur

Responses API'ye yapılan bu HTTP isteği, Codex'te bir konuşmanın ilk "aşamasını" başlatır. Sunucu, Sunucu Tarafından Gönderilen Olaylar (SSE⁠(yeni bir pencerede açılır)) akışı ile yanıt verir. Her etkinliğin veri alanı, "response" ile başlayan bir "type" içeren bir JSON yüküdür; bu, örneğin şöyle bir şey olabilir (etkinliklerin tam listesi API belgelerimizde⁠(yeni bir pencerede açılır) bulunabilir):

Düz Metin

1
data: {"type":"response.reasoning_summary_text.delta","delta":"ah ", ...}
2
data: {"type":"response.reasoning_summary_text.delta","delta":"ha!", ...}
3
data: {"type":"response.reasoning_summary_text.done", "item_id":...}
4
data: {"type":"response.output_item.added", "item":{...}}
5
data: {"type":"response.output_text.delta", "delta":"forty-", ...}
6
data: {"type":"response.output_text.delta", "delta":"two!", ...}
7
data: {"type":"response.completed","response":{...}}

Codex olay akışını işler⁠(yeni bir pencerede açılır) ve bunları bir istemci tarafından kullanılabilecek dahili olay nesneleri olarak yeniden yayımlar. response.output_text.delta gibi olaylar, kullanıcı arayüzünde akışı desteklemek için kullanılırken, response.output_item.added gibi diğer olaylar, sonraki Responses API çağrıları için input'a eklenmek üzere nesnelere dönüştürülür.

Responses API'ye yapılan ilk isteğin iki response.output_item.done olayı içerdiğini varsayalım: biri type=reasoning ve diğeri type=function_call. Bu olaylar, araç çağrısına verilen yanıtla modeli yeniden sorguladığımızda JSON'ın input alanında yer almalıdır: 

JavaScript

1
[
2
  /* ... original 5 items from the input array ... */
3
  {
4
    "type": "reasoning",
5
    "summary": [
6
      "type": "summary_text",
7
      "text": "**Adding an architecture diagram for README.md**\n\nI need to..."
8
    ],
9
    "encrypted_content": "gAAAAABpaDWNMxMeLw..."
10
  },
11
  {
12
    "type": "function_call",
13
    "name": "shell",
14
    "arguments": "{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}",
15
    "call_id": "call_8675309..."
16
  },
17
  {
18
    "type": "function_call_output",
19
    "call_id": "call_8675309...",
20
    "output": "<p align=\"center\"><code>npm i -g @openai/codex</code>..."
21
  }
22
]

Sonraki sorgunun bir parçası olarak modeli örneklemek için kullanılan komut şu şekilde olurdu:

"Snapshot 2" etiketli diyagram, bir araç çağrısından sonra bir otonom ajanı göstermektedir. Model bir araç gözlemi alır ve yeni bir düşünce ve eylem üretir. Oklar, ajanın muhakeme döngüsünü nasıl yinelediğini göstermek için girdileri, gözlemleri ve çıktıları birbirine bağlar.

Özellikle, eski komutun yeni komutun tam bir ön eki olduğuna dikkat edin. Bu kasıtlıdır; çünkü bu, komut önbelleğe alma özelliğinden yararlanmamızı sağladığı için sonraki istekleri çok daha verimli hale getirir (bunu performansla ilgili bir sonraki bölümde ele alacağız).

Otonom ajanın döngüsünün ilk diyagramına dönüp baktığımızda, çıkarım ile araç çağırma arasında birçok yineleme olabileceğini görüyoruz. Komut, sonunda bir asistan mesajı alana kadar büyümeye devam edebilir; bu da turun sonunu belirtir:

Düz Metin

1
data: {"type":"response.output_text.done","text": "I added a diagram to explain...", ...}
2
data: {"type":"response.completed","response":{...}}

Codex CLI'da, kullanıcıya yardımcı mesajını sunar ve kullanıcıya konuşmaya devam etme "sırasının" kendisinde olduğunu belirtmek için yazıcıya odaklanırız. Kullanıcı yanıt verirse, hem önceki turdaki asistan mesajı hem de kullanıcının yeni mesajı, yeni turu başlatmak için Responses API isteğindeki input alanına eklenmelidir:

JavaScript

1
[
2
  /* ... all items from the last Responses API request ... */
3
  {
4
    "type": "message",
5
    "role": "assistant",
6
    "content": [
7
      {
8
        "type": "output_text",
9
        "text": "I added a diagram to explain the client/server architecture."
10
      }
11
    ]
12
  },
13
  {
14
    "type": "message",
15
    "role": "user",
16
    "content": [
17
      {
18
        "type": "input_text",
19
        "text": "That's not bad, but the diagram is missing the bike shed."
20
      }
21
    ]
22
  }
23
]

Bir kez daha, bir konuşmayı sürdürdüğümüz için Responses API'ye gönderdiğimiz input uzunluğu artmaya devam ediyor:

Bir otonom ajan döngüsünün son aşamasını gösteren, "Snapshot 3" etiketli diyagram. Araç sonuçlarını aldıktan sonra model, bir sonuç düşüncesi oluşturur ve kullanıcıya nihai bir yanıt sunar. Oklar, araç çıktısından tamamlanmış bir yanıta geçişi gösterir.

Bu sürekli büyüyen komutun performans açısından ne anlama geldiğini inceleyelim.

Performans değerlendirmeleri

Kendinize şu soruyu soruyor olabilirsiniz: "Bir dakika, ajan döngüsü, konuşma süresince Responses API'ye gönderilen JSON miktarı açısından ikinci dereceden değil mi?" Ve haklı olurdunuz. Responses API, bu sorunu hafifletmek için isteğe bağlı bir previous_response_id⁠(yeni bir pencerede açılır) parametresini desteklese de Codex bunu bugün kullanmıyor; bunun başlıca nedeni, istekleri tamamen durumsuz tutmak ve Sıfır Veri Saklama (ZDR) yapılandırmalarını desteklemektir.

previous_response_id kullanmaktan kaçınmak, Responses API sağlayıcısı için işleri basitleştirir çünkü her isteğin durumsuz olmasını garanti eder. Bu durum, Sıfır Veri Saklama (ZDR)⁠(yeni bir pencerede açılır) seçeneğini tercih eden müşterileri desteklemeyi kolaylaştırır; çünkü previous_response_id desteği için gereken verilerin saklanması ZDR ile çelişir. ZDR müşterilerinin, sunucuda çözülebilen ilgili encrypted_content sayesinde, önceki turlardan gelen tescilli akıl yürütme mesajlarından faydalanma yeteneklerinden vazgeçmediklerini unutmayın. (OpenAI, bir ZDR müşterisinin şifre çözme anahtarını saklar, ancak verilerini saklamaz.) ZDR'yi desteklemek için Codex'teki ilgili değişiklikleri görmek amacıyla #642⁠(yeni bir pencerede açılır) ve #1641⁠(yeni bir pencerede açılır) numaralı PR'lere (pull request'lere) bakın.

Genel olarak, modelin örnekleme maliyeti ağ trafiği maliyetine baskın gelir ve bu da örneklemeyi verimlilik çabalarımızın ana hedefi yapar. Bu nedenle komut önbelleğe alma çok önemlidir; çünkü önceki bir çıkarım çağrısından yapılan hesaplamayı yeniden kullanmamıza olanak tanır. Önbellek isabetleri aldığımızda, modeli örneklemek doğrusal olur, ikinci dereceden değil. Komut önbelleğe alma ⁠(yeni bir pencerede açılır)belgelerimizde bu daha ayrıntılı olarak açıklanmaktadır:

Önbellek isabetleri yalnızca bir komut içinde tam önek eşleşmeleriyle mümkündür. Önbelleğe alma avantajlarından yararlanmak için talimatlar ve örnekler gibi statik içeriği komutun başına yerleştirin ve kullanıcıya özgü bilgiler gibi değişken içeriği sona koyun. Bu durum, istekler arasında aynı olması gereken görseller ve araçlar için de geçerlidir.

Bunu akılda tutarak, Codex'te hangi tür işlemlerin bir "önbellek kaçırma"ya yol açabileceğini düşünelim:

  • Konuşmanın ortasında modele sunulan tools seçeneklerini değiştirmek.
  • Responses API isteğinin hedefi olan model'i değiştirmek (pratikte bu, orijinal komuttaki üçüncü öğeyi değiştirir; çünkü model'e özgü talimatlar içerir).
  • Sandbox yapılandırmasını, onay modunu veya geçerli çalışma dizinini değiştirmek.

Codex ekibi, komut önbelleğe almayı tehlikeye atabilecek yeni özellikleri Codex CLI'ye eklerken dikkatli olmalıdır. Örneğin, MCP araçlarına yönelik ilk desteğimiz, araçları tutarlı bir sırayla listeleyemediğimiz bir hataya⁠(yeni bir pencerede açılır) yol açtı ve bu da önbellek kaçırmalarına neden oldu. MCP araçlarının özellikle zorlayıcı olabileceğini unutmayın; çünkü MCP sunucuları, notifications/tools/list_changed⁠(yeni bir pencerede açılır) bildirimi aracılığıyla sağladıkları araçların listesini anında değiştirebilir. Uzun bir konuşmanın ortasında bu bildirimi dikkate almak, maliyetli bir önbellek hatasına yol açabilir.

Mümkün olduğunda, konuşma sırasında meydana gelen yapılandırma değişikliklerini, önceki bir mesajı değiştirmek yerine, değişikliği yansıtmak için input'a yeni bir mesaj ekleyerek ele alırız:

Performansı artırmak için önbellek isabetlerini sağlamak adına büyük çaba gösteriyoruz. Yönetmemiz gereken başka bir önemli kaynak daha var: bağlam penceresi.

Bağlam penceresinin dolmasını önlemek için genel stratejimiz, token sayısı belirli bir eşiği aştığında konuşmayı daraltmaktır. Özellikle, girdi öğesini, konuşmayı temsil eden yeni ve daha küçük bir öğe listesiyle değiştiririz; bu, otonom ajanın şimdiye kadar olanları anlayarak devam etmesini sağlar. Sıkıştırmanın erken bir uygulaması⁠(yeni bir pencerede açılır), kullanıcının /compact komutunu manuel olarak çalıştırmasını gerektiriyordu; bu komut, mevcut konuşmayı ve özetleme⁠(yeni bir pencerede açılır) için özel talimatları kullanarak Responses API'sini sorgulardı. Codex, özet içeren ortaya çıkan asistan mesajını sonraki konuşma turları için yeni girdi⁠(yeni bir pencerede açılır) olarak kullandı.

O zamandan beri Responses API, sıkıştırmayı daha verimli gerçekleştiren özel bir /responses/compact uç noktasını⁠(yeni bir pencerede açılır) destekleyecek şekilde gelişti. Önceki girdi yerine kullanılabilecek öğelerin bir listesini⁠(yeni bir pencerede açılır) döndürür ve bu sayede bağlam penceresinde yer açılırken konuşmanın devam etmesine olanak tanır. Bu liste, modelin orijinal konuşmayı örtük bir şekilde anlamasını koruyan opak bir encrypted_content öğesi içeren özel bir type=compaction öğesini içerir. Artık Codex, auto_compact_limit⁠(yeni bir pencerede açılır) aşıldığında konuşmayı sıkıştırmak amacıyla bu uç noktayı otomatik olarak kullanır.

Yakında

Codex otonom ajan döngüsünü tanıttık ve bir modeli sorgularken Codex'in bağlamını nasıl oluşturup yönettiğini adım adım açıkladık. Bu süreçte, Responses API'nin üzerine bir otonom ajan döngüsü kuran herkes için geçerli olan pratik hususları ve en iyi uygulamaları vurguladık.

Otonom ajan döngüsü Codex için bir temel sağlasa da, bu sadece bir başlangıçtır. Gelecek yazılarda CLI'nin mimarisini derinlemesine inceleyecek, araç kullanımının nasıl uygulandığını keşfedecek ve Codex'in sandboxing modeline daha yakından bakacağız.

Yazar

Michael Bolin

Teşekkürler

Codex CLI'yi geliştiren tüm ekibe özel teşekkürler.

Okumaya devam et

Tümünü görüntüle
Tax Agent > Art Card
Codex ile kendini iyileştiren vergi ajanları oluşturma

Mühendislik

codex windows > art card
Windows’ta Codex’i etkinleştirmek için güvenli ve etkili bir sandbox oluşturulması

Mühendislik

MRC 1_1
Goblinler nereden çıktı

Mühendislik