วิเคราะห์การทำงานภายในของ OpenAI Codex CLI: ลูปเอเจนต์และกลยุทธ์การแคชพรอมป์ต์

สรุป:

• โครงสร้างของลูปเอเจนต์ (Agent Loop): อธิบายอย่างละเอียดถึงกระบวนการแบบวนซ้ำที่ Codex CLI ใช้ประสานอินพุตจากผู้ใช้ การอนุมานของโมเดล และการทำงานของเครื่องมือ (Tool) เพื่อทำงานจริงให้สำเร็จ
• การประกอบพรอมป์ต์และ Responses API: วิเคราะห์กระบวนการและการไหลของข้อมูลที่คำสั่งระบบ นิยามเครื่องมือ และคอนเท็กซ์ของสภาพแวดล้อมภายในเครื่อง ถูกแปลงเป็น JSON payload ของ Responses API
• การปรับประสิทธิภาพและการจัดการสถานะ: กล่าวถึงกลยุทธ์เพื่อเพิ่มประสิทธิภาพ Prompt Caching ให้สูงสุด เทคนิคการบีบอัดบทสนทนา (Compaction) เพื่อรับมือกับข้อจำกัดของ context window และหลักการออกแบบแบบไร้สถานะ (Stateless) สำหรับ ZDR (Zero Data Retention)

สรุปแบบละเอียด:
ทีมวิศวกรรมของ OpenAI ได้เผยแพร่บทความเชิงเทคนิคที่วิเคราะห์เชิงลึกหลักการทำงานของ 'ลูปเอเจนต์ (Agent Loop)' ซึ่งเป็นตรรกะแกนกลางของ Codex CLI เอเจนต์ซอฟต์แวร์บนเครื่อง บทความนี้อธิบายวงจรชีวิตทั้งหมดในมุมมองเชิงเทคนิค ตั้งแต่รับคำสั่งจากผู้ใช้ โต้ตอบกับโมเดล เรียกใช้เครื่องมือ และส่งผลลัพธ์กลับคืน

1. ลูปเอเจนต์ (The Agent Loop)

ลูปเอเจนต์เป็นโครงสร้างแบบวนซ้ำที่รับอินพุตจากผู้ใช้และโต้ตอบกับโมเดลจนกว่างานจะเสร็จสมบูรณ์

• กระบวนการ: อินพุตผู้ใช้ -> สร้างพรอมป์ต์ -> การอนุมานของโมเดล (Inference) -> (คำขอเรียกใช้เครื่องมือ -> รันเครื่องมือ -> แนบผลลัพธ์ -> อนุมานใหม่) ทำซ้ำ -> คำตอบสุดท้าย
• เทิร์น (Turn): กระบวนการตั้งแต่อินพุตของผู้ใช้จนถึงตอนที่โมเดลส่งข้อความสุดท้ายถึงผู้ใช้ (Assistant Message) เรียกว่า 1 'เทิร์น' ในระหว่างนี้ เอเจนต์อาจเรียกใช้เครื่องมือได้หลายร้อยครั้ง (เช่น รัน ls, แก้ไขไฟล์ เป็นต้น)

2. การอนุมานของโมเดลและ Responses API

Codex CLI สื่อสารกับโมเดลผ่าน Responses API โดย API นี้สามารถตั้งค่าให้ชี้ไปที่ https://chatgpt.com/backend-api/codex/responses, https://api.openai.com/v1/responses หรือ localhost (เช่น Ollama) ได้

การประกอบพรอมป์ต์เริ่มต้น (Building the Initial Prompt)

พรอมป์ต์ไม่ใช่แค่ข้อความธรรมดา แต่เป็นข้อมูลแบบมีโครงสร้างที่ประกอบด้วย instructions, tools, input เป็นต้น

• Instructions: ข้อความระบบหรือข้อความจากนักพัฒนา ที่กำหนดแนวทางพฤติกรรมของโมเดล (เช่น อ้างอิงไฟล์ตั้งค่า ~/.codex/config.toml)
• Tools: รายการนิยามเครื่องมือที่โมเดลสามารถใช้ได้ รวมถึงการรัน shell, การอัปเดตแผน (update_plan), การค้นหาเว็บ และเครื่องมือจากเซิร์ฟเวอร์ MCP (Model Context Protocol) ที่ผู้ใช้กำหนดเอง
• Input: รายการข้อมูลจริงที่ส่งให้โมเดล ซึ่งรวมถึงการตั้งค่าสิทธิ์ของ sandbox, คำสั่งเฉพาะของโปรเจกต์ และ Environment Context เช่น current working directory (cwd) และชนิดของ shell ที่กำลังใช้งาน

ตัวอย่าง JSON payload:

{  
  "type": "message",  
  "role": "user",  
  "content": [  
    {  
      "type": "input_text",  
      "text": "README.md에 아키텍처 다이어그램을 추가해줘"  
    }  
  ]  
  // ... มีการส่ง environment context และการตั้งค่าสิทธิ์ที่กำหนดไว้ก่อนหน้านี้ไปด้วย  
}  
  

3. การทำงานของเครื่องมือและการไหลของข้อมูล

เมื่อโมเดลร้องขอการเรียกใช้เครื่องมือ (Function Call) เอเจนต์จะทำการรัน จากนั้นเพิ่มผลลัพธ์เข้าไปในประวัติการสนทนาและเรียกโมเดลอีกครั้ง

ตัวอย่าง JSON สำหรับการร้องขอซ้ำหลังรันเครื่องมือ:

[  
  /* ... รายการอินพุตก่อนหน้า ... */  
  {  
    "type": "reasoning", // กระบวนการให้เหตุผลของโมเดล (CoT)  
    "summary": [...],  
    "encrypted_content": "gAAAAABpaDW..." // เนื้อหาการให้เหตุผลที่เข้ารหัส  
  },  
  {  
    "type": "function_call",  
    "name": "shell",  
    "arguments": "{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}",  
    "call_id": "call_8675309..."  
  },  
  {  
    "type": "function_call_output", // ผลลัพธ์จากการรันเครื่องมือ  
    "call_id": "call_8675309...",  
    "output": "<p align=\"center\"><code>npm i -g @openai/codex</code>..."  
  }  
]  
  

การจัดให้พรอมป์ต์ก่อนหน้าเป็น prefix ที่ตรงกันอย่างสมบูรณ์ ของพรอมป์ต์ใหม่เป็นเรื่องสำคัญ เพราะสิ่งนี้มีผลโดยตรงต่อประสิทธิภาพของการแคชพรอมป์ต์ที่จะกล่าวถึงต่อไป

4. ข้อพิจารณาด้านประสิทธิภาพ: แคชและ ZDR

เมื่อบทสนทนายาวขึ้น ขนาดของพรอมป์ต์จะเพิ่มขึ้นแบบเชิงเส้น ซึ่งทำให้ต้นทุนและเวลาแฝงเพิ่มขึ้น

• Prompt Caching: โมเดลของ OpenAI สามารถนำผลการคำนวณก่อนหน้ากลับมาใช้ซ้ำเพื่อเพิ่มความเร็วได้ หากส่วนต้นของพรอมป์ต์ตรงกัน (Prefix Match)

• การป้องกัน Cache Miss: หากมีการเปลี่ยนรายการเครื่องมือ หรือเปลี่ยนการตั้งค่า sandbox ระหว่างบทสนทนา แคชอาจใช้งานไม่ได้ เพื่อป้องกันสิ่งนี้ Codex จึงจัดการการเปลี่ยนค่าด้วยวิธี เพิ่มข้อความใหม่ (Append) แทนการแก้ไขข้อความเดิม

• Stateless และ ZDR: ระบบจะไม่ใช้พารามิเตอร์อย่าง previous_response_id และจะส่งบริบททั้งหมดทุกครั้ง เพื่อให้สอดคล้องกับนโยบาย Zero Data Retention (ZDR) ที่ไม่เก็บข้อมูลไว้บนเซิร์ฟเวอร์ ด้วยวิธีที่ไคลเอนต์รับเนื้อหาการให้เหตุผลแบบเข้ารหัส (encrypted_content) แล้วส่งกลับไปยังเซิร์ฟเวอร์อีกครั้ง เซิร์ฟเวอร์จึงสามารถกู้คืนบริบทการให้เหตุผลก่อนหน้าได้โดยไม่ต้องเก็บสถานะไว้

5. การจัดการ context window (Compaction)

เพื่อไม่ให้เกินข้อจำกัดของโทเค็น Codex ใช้เอนด์พอยต์ /responses/compact เพื่อบีบอัดประวัติการสนทนา โดยไม่ได้เป็นเพียงการสรุปแบบธรรมดา แต่จะรับรายการข้อมูลที่ถูกบีบอัดซึ่งรวม encrypted_content ที่คงไว้ซึ่งความเข้าใจเชิงแฝง (Latent understanding) ของโมเดล แล้วนำมาแทนที่อินพุตเดิม

[iolothebard]

Claude Code มีอยู่ในเอกสารทางการตั้งแต่ช่วงแรกแล้วนี่…

[iolothebard]

https://code.claude.com/docs/en/how-claude-code-works