แกะโครงลูปเอเจนต์ของ Codex

 (openai.com)
3 คะแนน โดย GN⁺ 2026-01-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Codex CLI ถูกออกแบบให้เป็น เอเจนต์ที่ทำการเปลี่ยนแปลงซอฟต์แวร์คุณภาพสูงได้อย่างปลอดภัยและมีประสิทธิภาพ ในสภาพแวดล้อมโลคัล
  • โครงสร้างหลักอย่าง ลูปเอเจนต์ (agent loop) เชื่อมโยงอินพุตของผู้ใช้ การอนุมานของโมเดล และการเรียกใช้เครื่องมือแบบวนซ้ำ เพื่อทำงานที่มีความหมาย
  • ระหว่างกระบวนการลูป การประกอบพรอมป์ต์, การจัดการ context window, การแคชพรอมป์ต์ ทำหน้าที่เป็นองค์ประกอบสำคัญด้านประสิทธิภาพและความเสถียร
  • Codex สื่อสารกับโมเดลผ่าน Responses API โดยแต่ละคำขอประกอบด้วย JSON payload แบบสมบูรณ์ จึงคงการทำงานแบบ stateless
  • โครงสร้างนี้ทำให้สามารถรองรับความสามารถขั้นสูงอย่าง Zero Data Retention (ZDR), การแคชพรอมป์ต์, การบีบอัดอัตโนมัติ (compaction) และเป็นรากฐานของการออกแบบเอเจนต์ขนาดใหญ่

ภาพรวมของลูปเอเจนต์ Codex

  • Codex CLI ทำงานโดยมี โครงสร้างลูปที่ประสานปฏิสัมพันธ์ระหว่างผู้ใช้ โมเดล และเครื่องมือ เป็นแกนกลาง
    • รับอินพุตจากผู้ใช้แล้วประกอบเป็น พรอมป์ต์ (prompt) เพื่อส่งให้โมเดล
    • หากโมเดลสร้างคำตอบหรือร้องขอ การเรียกใช้เครื่องมือ (tool call) เอเจนต์จะดำเนินการตามนั้นและเพิ่มผลลัพธ์กลับเข้าไปในพรอมป์ต์อีกครั้ง
    • เมื่อโมเดลไม่เรียกใช้เครื่องมือเพิ่มเติมแล้วและสร้าง ข้อความ assistant หนึ่งเทิร์นก็จะสิ้นสุดลง
  • แต่ละเทิร์นเป็นส่วนหนึ่งของ บทสนทนา (conversation) โดยข้อความก่อนหน้าและประวัติการเรียกใช้เครื่องมือทั้งหมดจะถูกรวมไว้ในพรอมป์ต์ของคำขอถัดไป
  • เนื่องจากความยาวของพรอมป์ต์ได้รับผลกระทบจากข้อจำกัดของ context window ของโมเดล Codex จึงต้องจัดการส่วนนี้อย่างเหมาะสม

โครงสร้างการสื่อสารระหว่าง Responses API กับ Codex

  • Codex CLI ส่งคำขอ HTTP ไปยัง Responses API เพื่อทำ model inference
    • API endpoint จะแตกต่างกันตามการตั้งค่า และสามารถใช้ได้ทั้งในสภาพแวดล้อม OpenAI, ChatGPT, Azure และแบบโลคัล (LM Studio, Ollama เป็นต้น)
  • คำขอ API ประกอบด้วย JSON payload โดยฟิลด์หลักมีดังนี้
    • ข้อความ system/developer: ตั้งค่าบริบทพื้นฐานของโมเดล
    • instructions: รายการเครื่องมือที่โมเดลสามารถเรียกใช้ได้
    • tools: คำจำกัดความของเครื่องมือที่ Codex CLI, Responses API และผู้ใช้ (เช่น MCP server) จัดเตรียมไว้
    • input: รายการข้อความที่รวมประวัติบทสนทนาและข้อมูลสภาพแวดล้อม
  • Codex จะอ่านการตั้งค่า ~/.codex/config.toml รวมถึง AGENTS.md และไฟล์ skills ภายในโปรเจ็กต์ เพื่อ แทรกคำสั่งของผู้ใช้และข้อมูลสภาพแวดล้อมโดยอัตโนมัติ

การประกอบพรอมป์ต์และการจัดการอีเวนต์

  • Codex จัดโครงสร้างแต่ละข้อความเป็นอ็อบเจ็กต์ JSON (type, role, content) แล้วส่งไปยัง Responses API
  • เซิร์ฟเวอร์จะ สร้างโมเดลพรอมป์ต์ จาก JSON นี้ และส่งคำตอบกลับมาเป็นสตรีม SSE (Server-Sent Events)
    • อีเวนต์ response.output_text.delta ใช้สำหรับเอาต์พุตแบบสตรีมมิง
    • อีเวนต์ response.output_item.added จะถูกเพิ่มเข้าไปใน input ของคำขอถัดไปเพื่อให้ลูปดำเนินต่อ
  • ระบบถูกออกแบบให้พรอมป์ต์ก่อนหน้าเป็น prefix ที่ตรงกันอย่างแม่นยำ ของพรอมป์ต์ใหม่ เพื่อให้สามารถใช้ การแคชพรอมป์ต์ (prompt caching) ได้

การเพิ่มประสิทธิภาพ: การแคชและการออกแบบแบบ stateless

  • Codex ไม่ใช้ previous_response_id จึงคงโครงสร้างคำขอแบบ stateless อย่างสมบูรณ์
    • สิ่งนี้ช่วยให้รองรับลูกค้าแบบ Zero Data Retention (ZDR) และลดการเก็บรักษาข้อมูลให้เหลือน้อยที่สุด
  • การแคชพรอมป์ต์นำ prefix เดิมกลับมาใช้ซ้ำเพื่อ ทำให้ต้นทุนการ sampling เป็นเชิงเส้น (linear)
    • การ cache hit จะเกิดขึ้นเฉพาะเมื่อ prefix ตรงกันอย่างแม่นยำ เท่านั้น
    • การเปลี่ยนรายการเครื่องมือ โมเดล การตั้งค่า sandbox หรือ working directory จะทำให้เกิด cache miss
  • การเปลี่ยนแปลงแบบไดนามิกของเครื่องมือ MCP อาจทำให้สูญเสียแคชได้ ดังนั้น Codex จึง สะท้อนการเปลี่ยนแปลงผ่านวิธีการแทรกข้อความใหม่

การจัดการ context window และการบีบอัดอัตโนมัติ (compaction)

  • เมื่อบทสนทนายาวขึ้น จะมีการทำ การบีบอัดบทสนทนา (compaction) เพื่อป้องกันไม่ให้เกิน context window
    • ในช่วงแรกใช้คำสั่ง /compact เพื่อสรุปด้วยตนเอง แต่ปัจจุบันใช้ endpoint /responses/compact ของ Responses API แบบอัตโนมัติ
    • endpoint นี้จะส่งคืน รายการ type=compaction และ encrypted_content ที่เข้ารหัสไว้ เพื่อคงความเข้าใจของโมเดล
  • เมื่อเกินค่า auto_compact_limit Codex จะทำการบีบอัดโดยอัตโนมัติเพื่อรักษาความต่อเนื่องของบทสนทนา

บทสรุปและทิศทางต่อไป

  • ลูปเอเจนต์ของ Codex คือโครงสร้างแกนกลางที่ผสาน model inference, การเรียกใช้เครื่องมือ, การแคช, การจัดการบริบท เข้าด้วยกัน
  • โครงสร้างนี้ทำให้สามารถออกแบบเอเจนต์ที่ ประสิทธิภาพสูง เป็นแบบ stateless และเน้นความปลอดภัย ได้
  • ในโพสต์ถัดไปจะกล่าวถึงโครงสร้างภายในของ Codex เพิ่มเติม เช่น สถาปัตยกรรม CLI, การอิมพลีเมนต์การใช้เครื่องมือ, โมเดล sandboxing

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-24
ความคิดเห็นจาก Hacker News

  • สิ่งที่ดีที่สุดของโพสต์บล็อกนี้คือมันไม่น่าแปลกใจเลยแม้แต่น้อย เพราะ Codex CLI เป็นโอเพนซอร์ส จึงสามารถดูภายในได้โดยไม่ต้องทำรีเวิร์สเอนจิเนียริง
    การสื่อสารของ Eric Traut (นักพัฒนาที่มีชื่อเสียงจาก Pyright) ก็ดีเยี่ยมมาก เขามีส่วนร่วมกับ issues และ PR อย่างแข็งขัน
    GitHub repository

    • ตอนที่ Codex CLI ถูกเปิดเป็นโอเพนซอร์สเมื่อปีที่แล้ว ฉันประหลาดใจมาก มันยังรวม codex-rs ที่พอร์ตจาก TypeScript มาเป็น Rust ด้วย จึงมีประโยชน์มากสำหรับคนที่อยากเรียนรู้ว่า coding agent ทำงานอย่างไร
      ฉันเองก็มีส่วนช่วยปรับปรุง CLI ไปบางอย่าง และคอยตามดูรีลีสกับ PR อย่างต่อเนื่องเพื่อขยายความรู้
    • ดูเหมือนหลายคนจะไม่รู้ว่า Claude Code เป็น ซอฟต์แวร์แบบปิด
    • พูดตามตรง ฉันคิดว่าเหตุผลที่ Claude Code ไม่เป็นโอเพนซอร์สก็เพราะคุณภาพโค้ดมันแย่มากจนน่าอาย ฉันใช้แพ็กเกจสมัครสมาชิกเดือนละ 200 ดอลลาร์อยู่ แต่ CLI ทั้งช้าและพังบ่อย เลยตั้งใจจะยกเลิกเร็ว ๆ นี้
    • ฉันสงสัยว่า Codex CLI เป็นแค่ ฟรอนต์เอนด์ ที่เรียกใช้ลอจิกระยะไกลหรือไม่ หรือมันสามารถทำงานได้สมบูรณ์แบบแบบออฟไลน์ด้วย และก็อยากรู้ว่ามีการให้ weights ภายใต้ FLOW license หรือไม่ รวมถึงมีการทำเอกสารกระบวนการ build ไว้หรือเปล่า

  • ประเด็นที่น่าสนใจคือส่วนที่การบีบอัด (compaction) ถูกทำเป็น “ข้อความเข้ารหัสที่เก็บความเข้าใจโดยนัยของโมเดลเอาไว้”
    เมื่อ Codex เกิน auto_compact_limit มันจะใช้เอนด์พอยต์นี้โดยอัตโนมัติเพื่อลดบริบทการสนทนาอย่างมีประสิทธิภาพ

    • เอนด์พอยต์ compaction ของ Codex อยู่ในระดับดีที่สุดของวงการ ของ Claude นั้นเรียกได้ว่า แย่สุด ๆ
    • ฉันสงสัยว่าสามารถใช้เอนด์พอยต์ compactor แยกเดี่ยวได้หรือไม่ เรามี agent loop เฉพาะโดเมนของเราเองอยู่ และดูเหมือนของ Codex จะให้ประสิทธิภาพดีกว่าระบบบีบอัดที่เราสร้างเอง
    • อยากรู้ว่าฟีเจอร์นี้ทำงานได้กับโมเดลอื่นที่ไม่ใช่ OpenAI ด้วยหรือไม่

  • สิ่งที่ทำให้ฉันแปลกใจตอนดูภายในของ Codex คือ reasoning token จะถูกเก็บไว้ใน agent tool-calling loop แต่จะถูกลบทิ้งทุกครั้งที่เปลี่ยนเป็น user turn ใหม่
    เพราะงั้นมันจึงรักษาบริบทต่อเนื่องข้ามหลาย turn ได้ แต่ก็อาจทำให้บริบทบางส่วนหายไปในระหว่างคำขอของผู้ใช้ที่เกี่ยวข้องกัน
    ฉันเลยให้โมเดลบันทึกความคืบหน้า แผน หรือรายละเอียดการดีบักลงในไฟล์ Markdown เพื่อให้ทำหน้าที่เหมือน snapshot ระหว่างหลาย context window

    • มันต่างกันตามเส้นทาง API สำหรับ chat completions จะเป็นแบบที่คุณพูด แต่ใน responses v1 API จะตรงกันข้าม reasoning token จะยังคงอยู่ตอนส่งข้อความถัดไปด้วย เพียงแต่ โหมด xhigh จะกินคอนเท็กซ์เร็วกว่าเยอะ
    • การไม่เก็บ reasoning token ไว้อาจเป็นการตัดสินใจที่ดีก็ได้ ไม่อย่างนั้นบริบทที่ผู้ใช้มองไม่เห็นจะสะสมต่อไปเรื่อย ๆ และเสี่ยงให้ความเข้าใจของโมเดลกับผู้ใช้ ไม่ตรงกัน
    • ฉันสร้าง Codex Reflect Skill เพื่อสะท้อนบทสนทนาในอดีตและสร้างคอนเท็กซ์ด้วยเซสชันแบบขนาน
      GitHub repository
    • การเก็บบันทึกร่วมกับโค้ดนั้นสะดวก แต่จะสร้างปัญหาในสภาพแวดล้อมทีม หรือเวลาทำหลาย branch พร้อมกัน การทดลองถัดไปของฉันคือแยกข้อมูลนี้ออกไปไว้ใน daemon ที่มี external storage แล้วเข้าถึงผ่าน CLI client
    • ฉันใช้ agent-shell ของ emacs บ่อย มันเก็บประวัติการสนทนาทั้งหมดไว้ ทำให้พูดว่า “ช่วยอ้างอิงบทสนทนาก่อนหน้านี้ให้หน่อย” ได้ง่าย เพราะคนที่ทำ logging คือ emacs ไม่ใช่ agent จึงไม่ต้องกังวลว่าจะตกหล่น

  • สิ่งที่ฉันอยากได้จาก Codex มากที่สุดคือฟีเจอร์ checkpoint แบบสไตล์ Copilot มี issue ที่เกี่ยวข้องอยู่หลายอันบน GitHub (#2788, #3585) แต่ดูเหมือนจะยังไม่ใช่ลำดับความสำคัญของทีม

    • Gemini CLI มีฟีเจอร์นี้อยู่แล้ว
    • ทีม Codex บอกว่าพวกเขาจัดลำดับความสำคัญจาก จำนวนอีโมจิอัปโหวต บน GitHub ถ้ามีฟีเจอร์ที่อยากได้ก็ควรไปอัปโหวตไว้

  • ฉันสงสัยว่าเวลารวบรวมคำสั่งของผู้ใช้ใน agent loop พวกเขาจัดการ การรักษาคอนเท็กซ์ ในบทสนทนาหลาย turn อย่างไร และเคยลองใช้เทคนิคที่ปรับแบบไดนามิกเมื่อความต้องการของผู้ใช้เปลี่ยนไปหรือไม่

  • ฉันชอบ Codex แต่รู้สึกว่ามัน ช้ากว่า เว็บอินเทอร์เฟซ ChatGPT เวลาโยนไอเดียโต้ตอบกันเร็ว ๆ ฉันยังรู้สึกว่าการคัดลอกวางบนเว็บมีประสิทธิภาพกว่า
    Codex มักเริ่มไปแก้โค้ดผิดจุด ทำให้ feedback loop ช้าและน่าหงุดหงิด แต่ตอนที่มันทำงานดี มันก็ดีมาก หวังว่าสักวันจะเร็วได้เหมือนเว็บและยังทำงานโลคัลได้ด้วย

    • ในเว็บอินเทอร์เฟซ ChatGPT Plus ไม่มีโหมด xhigh reasoning effort ของโมเดล 5.2

  • ไม่ได้ใหม่เป็นพิเศษ แต่ก็ยังเป็นบทความที่มีคุณค่า อยากให้ใน coding CLI แบบ agentic สามารถ สะท้อน (reflect) วนลูปหรือประวัติย้อนหลังได้ง่ายกว่านี้ ฉันเคยลองใช้วิธี query ประวัติแชตผ่าน MCP แต่ต้องระบุชัดเจนถึงจะใช้ได้ เลยไม่ค่อยสะดวก การเรียนรู้อย่างต่อเนื่องน่าจะช่วยแก้ปัญหานี้ได้

  • พฤติกรรมแบบนี้สังเกตได้ผ่าน OTEL telemetry เช่นกัน ฉันใช้ headless codex exec บ่อย แต่การรองรับ telemetry ในตัวมีน้อย เลยดีบักได้ยาก
    เพราะงั้นฉันจึงทำ codex-plus ขึ้นมาใช้เอง มันสะท้อนอินเทอร์เฟซ codex exec ตรง ๆ และสร้างอยู่บน TypeScript SDK จากนั้นหลังรันเสร็จก็ส่ง session log ไปยัง remote OpenTelemetry collector เพื่อให้วิเคราะห์ผ่าน codex-plus-log-viewer ได้

  • ส่วนที่อธิบายเรื่อง skill ให้ความรู้สึกแปลก ๆ
    ลิงก์ไปยังโค้ดที่เกี่ยวข้อง
    ฉันสงสัยว่าทำไมไม่เปิดเผยไฟล์โดยตรงไปเลย แต่กลับให้โมเดลร้องขอเหมือนไฟล์ทั่วไป

    • นั่นแหละคือหัวใจของ skill โครงสร้างนี้ทำให้ เปิดเฉพาะไฟล์ที่เกี่ยวข้อง เพื่อลดการใช้ context window

  • ฉันเคยสงสัยว่ามีใครใช้ Codex CLI แบบจริงจังบ้างไหม ฉันเคยใช้ VSCode Codex extension, Gemini CLI และ Claude Code CLI ซึ่งทั้งหมด ประสิทธิภาพแย่มาก
    แต่ Codex CLI ตัวใหม่ที่ทำด้วย Rust นั้นแรงมาก UX ก็ยอดเยี่ยม และรายละเอียดเล็ก ๆ อย่างคีย์ลัดก็ทำมาดี Theo บอกว่า “ควรโฟกัสที่การปรับปรุงโมเดลมากกว่าการ optimize CLI” แต่พอได้ใช้แล้วฉันไม่เห็นด้วยเลย

    • ฉันรู้สึกว่า Codex CLI ดีกว่า Claude Code มาก มันทำตามคำสั่งได้แม่นยำ และไม่ทำพฤติกรรมที่ไม่ต้องการ ด้วยแพ็กเกจสมัครสมาชิกเดือนละ 20 ดอลลาร์ก็ใช้ โมเดล 5.2 codex high ได้อย่างเหลือเฟือ ฉันทำงานกับโมเดลชีวอะคูสติก SSL
    • OpenCode ก็เร็วและเสถียรกว่า CLI ตัวอื่นเหมือนกัน ช่วงหลังฉันใช้ Codex มากขึ้น และกำลังจะยกเลิก Claude Pro จุดที่น่าสนใจคือ OpenAI รองรับ OpenCode อย่างเป็นทางการ ตอนนี้มีหลายตัวเลือกแข่งกันถือว่าเป็นเรื่องดี
    • Codex ให้ผลลัพธ์สม่ำเสมอเกิน 95% ในงานเขียนโค้ดส่วนใหญ่ แต่ในงานที่ ไม่มีโครงสร้างชัดเจน (เช่น บทสนทนาหรือการเขียนเรื่อง) มันก็อาจให้ผลลัพธ์เพี้ยน ๆ ได้ ฉันเคยเจอมันติดลูประหว่าง git rebase ด้วย ฉันเคยลอง Aider แล้ว แต่แทบไม่มีประโยชน์
    • ประสิทธิภาพด้านหน่วยความจำและ CPU ของ Codex CLI ดีมาก แถมยังเป็นโอเพนซอร์ส จึงตรวจสอบการทำงานภายในได้ด้วย ฉันยังคงไม่พอใจกับคำพูดของ Theo
    • ปัญหาของ Codex ตอนนี้คือยัง ไม่มีการรองรับ hook ฉันทำเครื่องมือที่ใช้ hook เพื่อลดการใช้ agent token ลงได้ 30% ผ่าน hook เราสามารถแก้พฤติกรรมที่ไม่มีประสิทธิภาพของ agent แบบเรียลไทม์ได้
      บทความที่เกี่ยวข้อง: Scribe Swebench Benchmark