ወደ ዋና ይዘት እለፍ
OpenAI

23 ጃንዋሪ 2026

ምህንድስና

የCodex ወኪል ዑደትን መፍታት

በMichael Bolin፣ የቴክኒክ ሠራተኛ አባል

በመጫን ላይ…

Codex CLI⁠(በአዲስ መስኮት ውስጥ ይክፈታል) በማሽንዎ ላይ ደኅንነቱ በተጠበቀ እና በብቃት ሲሠራ ከፍተኛ ጥራት ያላቸውን እና አስተማማኝ የሶፍትዌር ለውጦችን ለማምጣት የተነደፈ ሁለገብ የአካባቢ ሶፍትዌር ወኪላችን ነው። በኤፕሪል ወር CLI ለመጀመሪያ ጊዜ ከጀመርንበት ጊዜ ጀምሮ⁠ ዓለም አቀፍ ደረጃውን የጠበቀ የሶፍትዌር ወኪል እንዴት መገንባት እንደሚቻል ብዙ ተምረናል። እነዚህን ግንዛቤዎች ለማብራራት፣ ይህ Codex እንዴት እንደሚሠራ የተለያዩ ገጽታዎችን እና በትጋት የተገኙ ትምህርቶችን የምንዳስስበት ቀጣይ ተከታታይ ጽሑፍ ውስጥ የመጀመሪያው ነው። (የCodex CLI እንዴት እንደተገነባ የበለጠ ዝርዝር ዕይታ ለማግኘት፣ ክፍት ምንጭ ማከማቻችንን በhttps://github.com/openai/codex⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ላይ ይመልከቱ። የንድፍ ውሳኔዎቻችን ብዙዎቹ ጥቃቅን ዝርዝሮች በGitHub እትሞች እና የበለጠ ለማወቅ ከፈለጉ የመሳብ ጥያቄዎች ውስጥ ተካትተዋል።)

ለመጀመር፣ በCodex CLI ውስጥ በተጠቃሚው፣ በሞዴሉ እና ሞዴሉ ትርጉም ያለው የሶፍትዌር ሥራን ለማከናወን በሚጠቀምባቸው መሣሪያዎች መካከል ያለውን መስተጋብር ለማደራጀት ኃላፊነት ባለው በወኪል ሉፕ ላይ እናተኩራለን። ይህ ጽሑፍ ወኪላችን (ወይም «ማሠሪያ») የLLM አጠቃቀምን በተመለከተ የሚጫወተውን ሚና ጥሩ ዕይታ እንደሚሰጥዎት ተስፋ እናደርጋለን።

ወደ ውስጥ ከመግባታችን በፊት፣ ስለ ቃላት አጭር ማስታወሻ፦ በOpenAI «Codex» የCodex CLI፣ የCodex ክላውድ እና የCodex VS ኮድ ቅጥያዎችን ጨምሮ የተለያዩ የሶፍትዌር ወኪል አቅርቦቶችን ያካትታል። ይህ ጽሑፍ በCodex ማሠሪያ ላይ ያተኩራል፣ ይህም ሁሉንም የCodex ልምዶች መሰረት ያደረገ እና በCodex CLI በኩል የሚወጣውን ዋና ወኪል ዑደት እና የአፈጻጸም አመክንዮ ያቀርባል። እዚህ ጋር በቀላሉ ለመረዳት፣ «Codex» እና «Codex CLI» የሚሉትን ቃላት በተለዋጭነት እንጠቀማለን።

የወኪል ዑደት

የእያንዳንዱ የሰው ሠራሽ አስተውሎት (AI) ወኪል ልብ ውስጥ «የወኪል ዑደት» የሚባል ነገር አለ። የወኪል ዑደት ቀለል ያለ ምሳሌ እንደዚህ ይመስላል፦

“የወኪል ዑደት” የሚል ርዕስ ያለው ዲያግራም የሰው ሰራሽ አስተውሎት (AI) ስርዓት የተጠቃሚ ጥያቄን እንዴት እንደሚያስኬድ፣ መሳሪያዎችን እንዴት እንደሚጠራ፣ ውጤቶችን እንዴት እንደሚመለከት፣ ዕቅዱን እንዴት እንደሚያዘምን እና ውጤቶችን እንዴት እንደሚመልስ ያሳያል። ቀስቶች እንደ ተጠቃሚ ግቤት፣ ሞዴል ማመዛዘን፣ የመሣሪያ እርምጃዎች እና የመጨረሻ ምላሽ ያሉ ደረጃዎችን ያገናኛሉ።

ለመጀመር፣ ወኪሉ ከተጠቃሚው ግቤት ወስዶ እርምጃ በመባል ለሚታወቀው ሞዴል በሚያዘጋጀው የጽሑፍ መመሪያ ስብስብ ውስጥ እንዲካተት ያደርጋል።

ቀጣዩ እርምጃ ሞዴሉን መመሪያዎቻችንን በመላክ እና ምላሽ እንዲያመነጭ በመጠየቅ መጠየቅ ነው፣ ይህም ሂደት እንደ መደምደሚያ ይባላል። በማጠቃለያው ወቅት፣ የጽሑፍ እርምጃው መጀመሪያ ወደ ተከታታይ የግቤት token-ዎች⁠(በአዲስ መስኮት ውስጥ ይክፈታል)— ወደ ሞዴሉ የቃላት ዝርዝር ውስጥ የሚገቡ ኢንቲጀሮች ይተረጉማል። እነዚህ token-ዎች ከዚያም ሞዴሉን ለመምሰል ጥቅም ላይ ይውላሉ፣ አዲስ የውጤት token-ዎችን ቅደም ተከተል ይፈጥራሉ።

የውጤት token-ዎች ወደ ጽሑፍ ይተረጎማሉ፣ ይህም የሞዴሉ ምላሽ ይሆናል። ምክንያቱም token-ዎች በተከታታይ ስለሚመረቱ፣ ይህ ትርጉም ሞዴሉ እየሠራ ሳለ ሊከናወን ይችላል፣ ስለዚህም ብዙ በLLM ላይ የተመሰረቱ መተግበሪያዎች የሚፈስ ውጤት ያሳያሉ። በተግባር፣ መደምደሚያ ብዙውን ጊዜ በጽሑፍ ላይ የሚሠራ API ጀርባ ተሸፍኖ የtokenization ዝርዝሮችን ያስወግዳል።

እንደ ማጠቃለያ ደረጃ ውጤት፣ ሞዴሉ (1) ለተጠቃሚው የመጀመሪያ ግቤት የመጨረሻ ምላሽ ይሰጣል፣ ወይም (2) ወኪሉ እንዲያከናውን የሚጠበቅበትን የመሣሪያ ጥሪ ይጠይቃል (ለምሳሌ፣ «ls አሂድ እና ውጤቱን ሪፖርት አድርግ»)። በ(2) ሁኔታ ወኪሉ የመሣሪያውን ጥሪ ያከናውናል እና ውጤቱን ከመጀመሪያው እርምጃ ጋር ያያይዛል። ይህ ውጤት ሞዴሉን እንደገና ለመጠየቅ የሚያገለግል አዲስ ግቤት ለማመንጨት ይጠቅማል፤ ከዚያም ወኪሉ ይህንን አዲስ መረጃ ግምት ውስጥ በማስገባት እንደገና መሞከር ይችላል።

ይህ ሂደት ሞዴሉ የመሣሪያ ጥሪዎችን ማስተላለፍ እስኪያቆም ድረስ ይደገማል እና በምትኩ ለተጠቃሚው መልእክት እስኪያወጣ ድረስ (በOpenAI ሞዴሎች ውስጥ እንደ ረዳት መልእክት ተብሎ ይጠራል)። በብዙ አጋጣሚዎች፣ ይህ መልእክት የተጠቃሚውን የመጀመሪያ ጥያቄ በቀጥታ ይመልሳል፣ ነገር ግን ለተጠቃሚው የተከታይ ጥያቄ ሊሆን ይችላል።

ወኪሉ የአካባቢውን አካባቢ የሚቀይሩ የመሣሪያ ጥሪዎችን መፈጸም ስለሚችል፣ «ውጤቱ» በረዳት መልዕክቱ ብቻ የተወሰነ አይደለም። በብዙ አጋጣሚዎች፣ የሶፍትዌር ወኪል ዋና ውጤት በማሽንዎ ላይ የሚጽፈው ወይም የሚያርትዖት ኮድ ነው። ቢሆንም፣ እያንዳንዱ ዙር ሁልጊዜ በረዳት መልዕክት ይጠናቀቃል—ለምሳሌ «እርስዎ የጠየቁትን architecture.md ጨመረው»—ይህም በወኪል ሉፕ ውስጥ የመጨረሻ ሁኔታን ያመለክታል። ከወኪሉ ዕይታ አንጻር፣ ሥራው ተጠናቅቋል እና ቁጥጥር ወደ ተጠቃሚው ይመለሳል።

በሥዕላዊ መግለጫው ላይ የሚታየው የተጠቃሚ ግብዓት ወደ ወኪል ምላሽ የሚደረገው ጉዞ እንደ አንድ የውይይት ዙር (በCodex ውስጥ ያለ ክር ) ይባላል። ምንም እንኳን ይህ የውይይት ዙር በሞዴል ማጠቃለያ እና በመሣሪያ ጥሪዎች መካከል ብዙ ድግግሞሾችን ሊያካትት ቢችልም። አዲስ መልእክት ወደ ነባር ውይይት በላኩ ቁጥር፣ የውይይት ታሪክ ለአዲሱ ዙር እንደ አራማጅ አካል ሆኖ ይካተታል፣ ይህም ከቀደሙት ተራዎች የተላኩ መልዕክቶችን እና የመሣሪያ ጥሪዎችን ያካትታል፦

"ባለብዙ-ዙር ወኪል ዑደት" የሚል ዲያግራም ያለው ሲሆን የሰው ሰራሽ አስተውሎት (AI) ወኪል የተጠቃሚ ግብዓትን ደጋግሞ እንዴት እንደሚወስድ፣ እርምጃዎችን እንዴት እንደሚያመነጭ፣ መሳሪያዎችን እንዴት እንደሚያማክር፣ የዝማኔዎችን ሁኔታ እንዴት እንደሚመልስ ያሳያል። የተወካዩን የማመዛዘን ዑደት የሚያሳዩ የተሰየሙ ደረጃዎችን፣ ቀስቶችን እና የመሳሪያ ውጤቶችን ያካትታል።

ይህ ማለት ውይይቱ እየጨመረ በሄደ ቁጥር ሞዴሉን ለመቅዳት የሚያገለግለው የእርምጃው ርዝመትም ይጨምራል ማለት ነው። ይህ ርዝመት አስፈላጊ ነው ምክንያቱም እያንዳንዱ ሞዴል የአውድ መስኮት ስላለው፣ ይህም ለአንድ የማጠቃለያ ጥሪ ሊጠቀምበት የሚችለው ከፍተኛው የtoken-ዎች ብዛት ነው። ይህ መስኮት የግቤት እና የውጤት ቶከኖችን እንደሚያካትት ልብ ይበሉ። እንደምታስቡት፣ አንድ ወኪል በአንድ ጊዜ በመቶዎች የሚቆጠሩ የመሣሪያ ጥሪዎችን ለማድረግ ሊወስን ይችላል፣ ይህም የአውድ መስኮቱን ሊያደክም ይችላል። በዚህ ምክንያት፣ የአውድ መስኮት አስተዳደር ከወኪሉ በርካታ ኃላፊነቶች አንዱ ነው። አሁን፣ Codex የወኪል ዑደቱን እንዴት እንደሚያሄድ ለማየት እንሞክር።

የሞዴል ማጠቃለያ

የCodex CLI የሞዴል መደምደሚያን ለማስኬድ የHTTP ጥያቄዎችን ወደ ምላሾች API⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ይልካል። መረጃ በCodex ውስጥ እንዴት እንደሚፈስ እንመረምራለን፣ ይህም የAPI ምላሾችን በመጠቀም የወኪል ዑደትን ያንቀሳቅሳል።

የCodex CLI የሚጠቀመው የAPI ምላሾች የመጨረሻ ነጥብ ሊዋቀር የሚችል⁠(በአዲስ መስኮት ውስጥ ይክፈታል)፣ ስለሆነ የAPI ምላሾችን የሚተገብር⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ማንኛውም የመጨረሻ ነጥብ ጋር መጠቀም ይቻላል፦

Codex በውይይቱ ውስጥ ለመጀመሪያው የማጠቃለያ ጥሪ እርምጃን እንዴት እንደሚፈጥር እንመርምር።

የመጀመሪያውን የእርምጃ ቅጽ መገንባት

እንደ የመጨረሻ ተጠቃሚ፣ የAPI ምላሾችን ሲጠይቁ ሞዴሉን በቃል ለመቅዳት የሚያገለግለውን እርምጃ አይገልጹም። በምትኩ፣ የተለያዩ የግቤት ዓይነቶችን እንደ እርምጃዎ አካል ይገልጻሉ፣ እና የAPI ምላሾች አገልጋይ ይህንን መረጃ ሞዴሉ ለመጠቀም የተነደፈውን እርምጃ እንዴት ማዋቀር እንዳለበት ይወስናል። እርምጃውን እንደ «የእቃዎች ዝርዝር» አድርገው ሊያስቡበት ይችላሉ፤ ይህ ክፍል ጥያቄዎ ወደዚያ ዝርዝር እንዴት እንደሚለወጥ ያብራራል።

በመጀመሪያው እርምጃ ውስጥ፣ በዝርዝሩ ውስጥ ያለው እያንዳንዱ ንጥል ከአንድ ሚና ጋር የተያያዘ ነው። role የተያያዘው ይዘት ምን ያህል ክብደት ሊኖረው እንደሚገባ የሚያመለክት ሲሆን ከሚከተሉት እሴቶች አንዱ ነው (በቅድሚያ በሚቀነስ ቅደም ተከተል)፦ ሥርዓት፣ ገንቢ፣ ተጠቃሚ፣ ረዳት።

API ምላሾች⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ብዙ መለኪያዎች ያሉትን የJSON ጭነት ይቀበላል። በእነዚህ ሦስት ላይ እናተኩራለን፦

በCodex ውስጥ፣ መመሪያዎች መስክ ከተጠቀሰው በ~/.codex/config.tomlውስጥ ካለው የሞዴል_መመሪያ_ፋይል⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ይነበባል፤ አለበለዚያ ከሞዴል ጋር የመሠረት_መመሪያዎችጥቅም ⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ላይ ይውላሉ። የሞዴል-ተኮር መመሪያዎች በCodex ማከማቻ ውስጥ ይኖራሉ እና በCLI ውስጥ ተጠቃለዋል (ለምሳሌ፣ gpt-5.2-codex_prompt.md⁠(በአዲስ መስኮት ውስጥ ይክፈታል))።

የመሣሪያዎች መስክ በAPI ምላሾች ከተገለጸው እቅድ ማውጣት ጋር የሚጣጣሙ የመሣሪያ ፍቺዎች ዝርዝር ነው። ለCodex፣ ይህ በCodex CLI የሚቀርቡ መሣሪያዎችን፣ ለCodex መቅረብ ያለባቸው በAPI ምላሾች የሚቀርቡ መሣሪያዎችን እንዲሁም በተጠቃሚው የሚቀርቡ መሣሪያዎችን፣ አብዛኛውን ጊዜ በMCP አገልጋዮች በኩል ያካትታል፦

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
]

በመጨረሻም፣ የJSON የክፍያ ጭነት ግብዓት መስክ የእቃዎች ዝርዝር ነው። Codex የተጠቃሚውን መልእክት ከማከልዎ በፊት የሚከተሉትን ነገሮች⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ወደ ግቤት ያስገባል፦

1. መሣሪያዎች ክፍል ውስጥ በተገለጸው የCodex-የቀረበውን shell መሣሪያ ብቻ የሚመለከት የአሸዋ ሳጥኑን የሚገልጽ ሚና የገንቢ=ሚና ያለው መልእክት። ማለትም፣ እንደ ከMCP ሰርቨሮች የቀረቡት ያሉ ሌሎች መሣሪያዎች በCodex አሸዋ ውስጥ አይገቡም እና የራሳቸውን መከላከያዎች የማስፈጸም ኃላፊነት አለባቸው።

መልዕክቱ የተገነባው ቁልፍ የይዘት ክፍሎች ከMarkdown ቁርጥራጮች ወደ Codex CLI ከተጣመሩ፣ ለምሳሌ workspace_write.md⁠(በአዲስ መስኮት ውስጥ ይክፈታል) እና on_request.md⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ካሉ፣ ከሚመጡበት አብነት ነው።

መደበኛ ጽሑፍ

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. (አማራጭ) ከተጠቃሚው config.toml ፋይል የተነበበ የገንቢ_መመሪያዎች እሴት የሆነ የገንቢ=ሚና ያለው መልእክት።

3. (አማራጭ) ከአንድ ፋይል የተገኙ ሳይሆን በብዙ ምንጮች የተዋሃዱ የተጠቃሚ=ሚና ያለው መልዕክት ይዘቱ «የተጠቃሚ መመሪያዎች» የሆነበት ነው⁠(በአዲስ መስኮት ውስጥ ይክፈታል)። በአጠቃላይ፣ የበለጠ ዝርዝር መመሪያዎች በኋላ ላይ ይታያሉ፦

4. ወኪሉ በአሁኑ ጊዜ የሚሠራበትን የአካባቢ አካባቢ የሚገልጽ የተጠቃሚ=ሚና ያለው መልእክት። ይህ የአሁኑን የሥራ ማውጫ እና የተጠቃሚውን ሼል ይገልጻል⁠(በአዲስ መስኮት ውስጥ ይክፈታል)፦

መደበኛ ጽሑፍ

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

Codex ግቤት ለማስጀመር ከላይ የተጠቀሱትን ሁሉ ስሌት ካጠናቀቀ በኋላ፣ ውይይቱን ለመጀመር የተጠቃሚውን መልእክት ይጨምራል።

ቀደም ሲል የነበሩት ምሳሌዎች በእያንዳንዱ መልእክት ይዘት ላይ ያተኮሩ ናቸው፣ ነገር ግን እያንዳንዱ ግቤት አካል የJSON ነገር ሲሆን ዓይነት፣ ሚና⁠(በአዲስ መስኮት ውስጥ ይክፈታል) እና ይዘት እንደሚከተለው መሆኑን ልብ ይበሉ፦

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 ወደ API ምላሾች ለመላክ ሙሉውን የJSON ክፍያ ካጠናቀቀ በኋላ፣ የAPI ምላሾች የመጨረሻ ነጥብ ~/.codex/config.toml ውስጥ እንዴት እንደተዋቀረ ላይ በመመስረት የHTTP POST ጥያቄን Authorization ራስጌ ያደርገዋል (ተጨማሪ የHTTP ራስጌዎች እና የጥያቄ መለኪያዎች ከተገለጹ ይታከላሉ)።

የOpenAI API ምላሾች አገልጋይ እርምጃውን ሲቀበል፣ ለሞዴሉ ጥያቄውን እንደሚከተለው ለማግኘት JSONን ይጠቀማል (እርግጠኛ ለመሆን፣ የAPI ምላሾች ብጁ ትግበራ የተለየ ምርጫ ሊያደርግ ይችላል)

በAI ወኪል ዑደት ውስጥ አንድ እርምጃን የሚያሳይ የቅጽበተ-ፎቶ ዲያግራም። የተጠቃሚ ጥያቄ ወደ ሞዴሉ ይገባል፣ ይህም ሀሳብ፣ የመሳሪያ ስም ያለው እርምጃ እና የመሳሪያ ግቤት ይፈጥራል። ዲያግራሙ መሳሪያው ከመጠራቱ በፊት ይህንን መካከለኛ የማመዛዘን ደረጃ ያጎላል።

እንደምታየው፣ በእርምጃው ውስጥ የመጀመሪያዎቹ ሦስት እቃዎች ቅደም ተከተል የሚወሰነው በአገልጋዩ እንጂ በደንበኛው አይደለም። ያም ሆኖ፣ ከሦስቱ ነገሮች ውስጥ፣ መሣሪያዎች እና መመሪያዎች የሚወሰኑት በደንበኛው ስለሆነ የሥርዓት መልዕክቱ ይዘት ብቻ በአገልጋዩ ቁጥጥር ይደረግበታል። እነዚህም ከJSON የክፍያ ጭነት ግቤት ተከትሎ እርምጃውን ያጠናቅቃሉ።

አሁን የእኛን እርምጃ ስላቀረብን ሞዴሉን ለመፈተሽ ዝግጁ ነን።

የመጀመሪያው ተራ

ይህ የHTTP ጥያቄ ለAPI ምላሾች በCodex ውስጥ የመጀመሪያውን የውይይት «ዙር» ይጀምራል። አገልጋዩ በሰርቨር-የተላኩ ክስተቶች (SSE⁠(በአዲስ መስኮት ውስጥ ይክፈታል)) ዥረት ምላሽ ይሰጣል። የእያንዳንዱ ክስተት ውሂብ «በምላሽ» የሚጀምር «ዓይነት» ያለው የJSON የክፍያ ጭነት ሲሆን እንደዚህ አይነት ነገር ሊሆን ይችላል (ሙሉ የክስተቶች ዝርዝር በAPI ሰነዶቻችን⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ውስጥ ይገኛል)፦

መደበኛ ጽሑፍ

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 የክስተቶችን ፍሰት ይጠቀማል⁠(በአዲስ መስኮት ውስጥ ይክፈታል) እና እንደ ውስጣዊ የክስተት ዕቃዎች እንደገና ያትማል፣ ይህም በደንበኛ ጥቅም ላይ ሊውል ይችላል። እንደ response.output_text.delta ያሉ ክስተቶች በUI ውስጥ ዥረትን ለመደገፍ ያገለግላሉ፣ እንደ response.output_item.added ያሉ ሌሎች ክስተቶች ደግሞ ለቀጣይ API ምላሾች ጥሪዎች ወደ ግቤት የሚጨመሩ ነገሮች ይለወጣሉ።

የመጀመሪያው የAPI ምላሽ ጥያቄ ሁለት response.output_item.done ክስተቶችን ያካተተ እንደሆነ እናስብ፦ አንደኛው ዓይነት=ከማመዛዘን ጋር ሲሆን ሌላኛው ደግሞ ዓይነት=ከተግባር_ጥሪ ጋር ነው። እነዚህ ክስተቶች በJSON ግቤት መስክ ውስጥ መወከል አለባቸው ሞዴሉን እንደገና ስንጠይቅ ለመሣሪያ ጥሪው ምላሽ ስንሰጥ፦ 

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
]

ሞዴሉን እንደ ቀጣዩ መጠይቅ አካል አድርጎ ለመፈተሽ የሚያገለግለው የእርምጃ ቅጽ እንደሚከተለው ይሆናል፦

ከመሳሪያ ጥሪ በኋላ የሰው ሰራሽ አስተውሎት (AI) ወኪልን የሚያሳይ “ቅጽበታዊ ገጽ እይታ 2” የሚል ዲያግራም። ሞዴሉ የመሳሪያ ምልከታን ይቀበላል እና አዲስ ሀሳብና እርምጃ ያመነጫል። ቀስቶች ግብዓቶችን፣ ምልከታዎችን እና ውጤቶችን ያገናኛሉ፣ ይህም ወኪሉ የማመዛዘን ዑደቱን እንዴት እንደሚደግም ያሳያል።

በተለይም፣ አሮጌው እርምጃ የአዲሱ እርምጃ ትክክለኛ ቅድመ ቅጥያ እንዴት እንደሆነ ልብ ይበሉ። ይህ ሆን ተብሎ የተደረገ ነው፣ ምክንያቱም ይህ ቀጣይ እርምጃዎችን የበለጠ ቀልጣፋ ስለሚያደርገው ፈጣን መሸጎጫ (በሚቀጥለው ክፍል ስለ አፈጻጸም እንወያያለን) እንድንጠቀም ስለሚያስችለን ነው።

የወኪል ዑደት የመጀመሪያ ዲያግራምን መለስ ብለን ስንመለከት፣ በማጠቃለያ እና በመሣሪያ ጥሪ መካከል ብዙ ድግግሞሽ ሊኖር እንደሚችል እናያለን። የረዳት መልእክት እስክንቀበል ድረስ እርምጃው ማደጉን ሊቀጥል ይችላል፣ ይህም የመዞሪያውን መጨረሻ የሚያመለክት ነው፦

መደበኛ ጽሑፍ

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

በCodex CLI ውስጥ፣ የረዳት መልዕክቱን ለተጠቃሚው እናቀርባለን እና አቀናባሪው ውይይቱን ለመቀጠል «ተራው» መሆኑን ለተጠቃሚው ለማሳየት ትኩረት እናደርጋለን። ተጠቃሚው ምላሽ ከሰጠ፣ ከቀዳሚው ዙር የመጣው የረዳት መልእክትም ሆነ የተጠቃሚው አዲስ መልእክት አዲሱን ዙር ለመጀመር በAPI ምላሾች ጥያቄ ውስጥ ባለው ግቤት ውስጥ መያያዝ አለባቸው፦

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
]

በድጋሚ፣ ውይይቱን ስለቀጠልን፣ ወደ API ምላሾች የምንልከው ግቤት ርዝመት እየጨመረ ነው

የAI ወኪል ዑደት የመጨረሻ ደረጃን የሚያሳይ “ቅጽበታዊ ገጽ እይታ 3” የሚል ስያሜ የተሰጠው ዲያግራም። የመሳሪያ ውጤቶችን ከተቀበለ በኋላ፣ ሞዴሉ መደምደሚያ ሀሳብ ያመነጫል እና የመጨረሻውን መልስ ለተጠቃሚው ይመልሳል። ቀስቶች ከመሳሪያ ውጤት ወደ ተጠናቀቀ ምላሽ የሚደረገውን ሽግግር ያሳያሉ።

ይህ በየጊዜው እያደገ የመጣው እርምጃ ለአፈጻጸም ምን ማለት እንደሆነ እስቲ እንመልከት።

የአፈጻጸም ግምት ውስጥ የሚገቡ ነገሮች

«ቆይ፣ በውይይቱ ወቅት ወደ API ምላሾች የተላከው የJSON መጠን አንፃር የወኪል ዑደት ኳድራቲክ አይደለምን?» ብለህ ራስህን እየጠየቅክ ሊሆን ይችላል። እና ትክክል ትሆናለህ። የAPI ምላሽ ይህንን ችግር ለማቃለል አማራጭ የሆነ previous_response_id⁠(በአዲስ መስኮት ውስጥ ይክፈታል) መለኪያን የሚደግፍ ቢሆንም፣ Codex ዛሬ አይጠቀምበትም፣ በዋናነት ጥያቄዎችን ሙሉ በሙሉ ግዛት አልባ ለማድረግ እና የዜሮ ዳታ ማቆያ (ZDR) ውቅሮችን ለመደገፍ ነው።

previous_response_id ማስወገድ የምላሾች API አቅራቢ ነገሮችን ቀላል ያደርገዋል ምክንያቱም እያንዳንዱ ጥያቄ ግዛት የሌለው መሆኑን ያረጋግጣል። ይህ ደግሞ previous_response_id ለመደገፍ የሚያስፈልገውን መረጃ ማከማቸት ከZDR ጋር ስለሚጋጭ፣ ዜሮ የውሂብ ማቆየት (ZDR) የሚለውን⁠(በአዲስ መስኮት ውስጥ ይክፈታል) መርጠው የገቡ ደንበኞችን መደገፍ ቀላል ያደርገዋል። የZDR ደንበኞች ከቀደምት ተራዎች የተገኙ የባለቤትነት ማረጋገጫ መልዕክቶችን የመጠቀም ችሎታቸውን እንደማይሰጡ ልብ ይበሉ፣ ምክንያቱም ተያያዥ encrypted_content በአገልጋዩ ላይ ዲክሪፕት ሊደረግ ይችላል። (OpenAI የZDR ደንበኛን ዲክሪፕት ቁልፍ ይቀጥላል፣ ነገር ግን ውሂባቸው አይደለም።) ZDRን ለመደገፍ በCodex ላይ የተደረጉ ተዛማጅ ለውጦችን ለማግኘት የPRዎች #642⁠(በአዲስ መስኮት ውስጥ ይክፈታል) እና #1641ን⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ይመልከቱ።

በአጠቃላይ፣ የሞዴሉን ናሙና የመውሰድ ወጪ የኔትወርክ ትራፊክ ወጪን የሚቆጣጠር ሲሆን፣ ናሙናን የውጤታማነት ጥረታችን ዋና ኢላማ ያደርገዋል። ለዚህ ነው እርምጃ ማሰባሰቢያ በጣም አስፈላጊ የሆነው፣ ምክንያቱም ከቀድሞ የማመዛዘን ጥሪ የተደረገውን ስሌት እንደገና እንድንጠቀም ያስችለናል። የመሸጎጫ ውጤቶችን ስናገኝ፣ የሞዴሉን ናሙና መውሰድ ኳድራቲክ ሳይሆን መስመራዊ ነው። የእኛ እርምጃ ማሰባሰቢያ ⁠(በአዲስ መስኮት ውስጥ ይክፈታል)ሰነዶች ይህን በተጨማሪ ዝርዝር ያብራራሉ፡፡

የመሸጎጫ ምቶች የሚቻሉት በእርምጃ ውስጥ ላሉ ትክክለኛ የቅድመ-ቅጥያ ግጥሚያዎች ብቻ ነው። የመሸጎጫ ጥቅሞችን ለማግኘት፣ እንደ መመሪያዎች እና ምሳሌዎች ያሉ የማይንቀሳቀሱ ይዘቶችን በእርምጃዎ መጀመሪያ ላይ ያስቀምጡ እና እንደ ተጠቃሚ-ተኮር መረጃ ያሉ ተለዋዋጭ ይዘቶችን በመጨረሻው ላይ ያስቀምጡ። ይህ ለምስሎች እና ለመሣሪያዎችም ይሠራል፣ እነዚህም በጥያቄዎች መካከል ተመሳሳይ መሆን አለባቸው።

ይህንን በአእምሯችን ይዘን፣ በCodex ውስጥ «የመሸጎጫ መጥፋት» ሊያስከትሉ የሚችሉ ምን አይነት ሥራዎችን እንመልከት፦

  • በውይይቱ መካከል ለሞዴሉ የሚገኙ መሣሪያዎችን መቀየር።
  • የAPI ምላሾች ጥያቄ ኢላማ የሆነውን ሞደል መቀየር (በተግባር፣ ይህ በዋናው እርምጃ ውስጥ ያለውን ሦስተኛውን ንጥል ይለውጠዋል፣ ምክንያቱም ሞዴል-ተኮር መመሪያዎችን ይዟል)።
  • የሳንድቦክስ ውቅርን፣ የማጽደቂያ ሁነታን ወይም የአሁኑን የሥራ ማውጫ መቀየር።

የCodex ቡድን በCodex CLI ውስጥ እርምጃን ሊያበላሽ የሚችል አዲስ ባህሪያትን ሲያስገባ በጥንቃቄ መሆን አለበት። ለምሳሌ፣ ለMCP መሣሪያዎች የመጀመሪያ ድጋፋችን መሣሪያዎቹን በተከታታይ ቅደም ተከተል መዘርዘር ባለመቻላችን⁠(በአዲስ መስኮት ውስጥ ይክፈታል) የመሸጎጫ ስህተቶችን አስከትሏል። የMCP መሣሪያዎች በተለይ አስቸጋሪ ሊሆኑ እንደሚችሉ ልብ ይበሉ ምክንያቱም የMCP አገልጋዮች notifications/tools/list_changed⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ማሳወቂያዎች አማካኝነት የሚያቀርቧቸውን የመሣሪያዎች ዝርዝር በፍጥነት ሊቀይሩ ይችላሉ። ይህንን ማሳወቂያ በረጅም ውይይት መሃል ማክበር ውድ የሆነ የመሸጎጫ መጥፋት ሊያስከትል ይችላል።

የሚቻል ከሆነ፣ በውይይቱ መካከል የሚከሰቱ የውቅር ለውጦችን የምናስተናግደው ቀደም ሲል የነበረን መልእክት ከማሻሻል ይልቅ ለውጡን ለማንፀባረቅ አዲስ መልእክት ወደ ግቤት በማከል ነው፦

ለአፈፃፀም የካሽ ሂቶች መካሄዳቸውን ለማረጋገጥ ከፍተኛ ጥረት እናደርጋለን። ማስተዳደር ያለብን ሌላ ቁልፍ የሆነ ሀብት አለ፦ የአውድ መስኮት።

የአውድ መስኮት እንዳያልቅብን ለመከላከል የምንጠቀምበት አጠቃላይ ስትራቴጂ የቶከኖች ቁጥር ከተወሰነ ገደብ በላይ ሲያልፍ ውይይቱን ማጥበብ ነው። በተለይም፣ ግቤቱን የምንተካው የውይይቱን ወካይ በሆነ አዲስ፣ አነስተኛ የቁሶች ዝርዝር ነው፣ ይህም ወኪሉ እስካሁን ምን እንደተፈጠረ መረዳቱን እንዲቀጥል ያስችለዋል። ቀደም ብሎ የተተገበረው የኮምፓክሽን ትግበራ⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ተጠቃሚው /compact ትዕዛዝን እንዲጠራ ያስገድደዋል፣ ይህም አሁን ያለውን ውይይት እና ብጁ ለማጠቃለያ⁠(በአዲስ መስኮት ውስጥ ይክፈታል) የሚሆኑ መመሪያዎችን በመጠቀም የResponses APIን ይጠይቃል። Codex ማጠቃለያ የያዘውን የረዳት መልዕክት ለቀጣዮቹ የውይይት ዙሮች እንደ አዲሱ ግቤት⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ተጠቅሟል።

ከዚያን ጊዜ ጀምሮ፣ የRespons API ኮምፓክሽን በብቃት የሚያከናውን ልዩ /responses/compactን የመጨረሻ ነጥብ⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ለመደገፍ ተሻሽሏል። የአውድ መስኮቱን እያስፈታ ውይይቱን ለመቀጠል የእቃዎች ዝርዝር⁠(በአዲስ መስኮት ውስጥ ይክፈታል) የሚመልስ ሲሆን ይህም ውይይቱን ለመቀጠል ከቀዳሚው ግቤት ይልቅ ጥቅም ላይ ሊውል ይችላል። ይህ ዝርዝር የሞዴሉ የመጀመሪያውን ውይይት ድብቅ ግንዛቤ የሚጠብቅ ግልጽ ያልሆነ type=compaction እቃ ያለው ልዩ type=compaction ንጥል ያካትታል። አሁን፣ auto_compact_limit⁠(በአዲስ መስኮት ውስጥ ይክፈታል) ሲያልፍ Codex ይህንን የመጨረሻ ነጥብ በራስ-ሰር ይጠቀማል።

በቀጣይ የሚመጣው

የCodex ወኪል ዑደትን አስተዋውቀናል፣ እንዲሁም Codex ሞዴልን ሲጠይቅ አውዱን እንዴት እንደሚቀርጽ እና እንደሚያስተዳድር ተመልክተናል። በመንገዱ ላይ፣ በResponses API ላይ የተመሠረተ የወኪል ዑደት ለሚገነባ ማንኛውም ሰው የሚተገበሩ ተግባራዊ ጉዳዮችን እና ምርጥ ልምዶችን አሳይተናል።

የወኪል ዑደት ለCodex መሠረቱን ቢሰጥም፣ ይህ ጅማሬው ብቻ ነው። በሚቀጥሉት ጽሁፎች፣ የCLIን አርክቴክቸር በጥልቀት እንመረምራለን፣ የመሳሪያ አጠቃቀም እንዴት እንደሚተገበር እንመረምራለን፣ እና የCodexን ሳንድቦክሲንግ ሞዴል በጥልቀት እንመረምራለን።

ደራሲ

Michael Bolin

ምስጋናዎች

Codex CLIን ለገነባው ቡድን በሙሉ ልዩ ምስጋና እናቀርባለን።

ማንበብዎን ይቀጥሉ

ሁሉንም ይመልከቱ
Tax Agent > Art Card
በCodex ራስን የሚያሻሽሉ የታክስ ወኪሎችን መገንባት

ምህንድስና

codex windows > art card
በWindows ላይ Codexን ለማስቻል ደህንነቱ የተጠበቀና ውጤታማ sandbox መገንባት

ምህንድስና

MRC 1_1
Supercomputer networking to accelerate large scale AI training

ምህንድስና