ข้ามไปยังเนื้อหาหลัก
OpenAI

4 กุมภาพันธ์ 2569

วิศวกรรม

ปลดล็อกพลังของ Codex และวิธีที่เราพัฒนาแอปเซิร์ฟเวอร์

โดย Celia Chen สมาชิกทีมงานด้านเทคนิค

กำลังโหลด…

เอเจนต์เขียนโค้ด Codex ของ OpenAI มีให้ใช้งานบนหลายแพลตฟอร์ม ไม่ว่าจะเป็นเว็บแอป⁠(เปิดในหน้าต่างใหม่) CLI⁠(เปิดในหน้าต่างใหม่) ส่วนขยาย IDE⁠(เปิดในหน้าต่างใหม่) และ แอป Codex สำหรับ macOS ใหม่ ภายในระบบ Codex ใช้ Harness ชุดเดียวที่รวมลูปเอเจนต์และตรรกะการทำงานที่เป็นพื้นฐานของประสบการณ์ทั้งหมดใน Codex ตัวแปรสำคัญที่เชื่อมทุกระบบเข้าหากันคืออะไร Codex App Server⁠(เปิดในหน้าต่างใหม่) ซึ่งเป็น API JSON-RPC1 แบบสองทิศทางที่ใช้งานง่าย

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

จุดกำเนิดของ App Server

ก่อนจะเจาะลึกเรื่องสถาปัตยกรรม ควรเข้าใจเรื่องราวเบื้องหลังของ App Server ก่อน แรกเริ่ม App Server ถูกสร้างขึ้นเพื่อใช้ Codex Harness ซ้ำในผลิตภัณฑ์ต่างๆ อย่างมีประสิทธิภาพ และต่อมาพัฒนากลายเป็นโปรโตคอลมาตรฐาน

Codex CLI เริ่มต้นจาก TUI (Terminal User Interface หรือ อินเทอร์เฟซผู้ใช้ผ่านเทอร์มินัล) ซึ่งหมายความว่าผู้ใช้เข้าถึง Codex ผ่านเทอร์มินัล เมื่อเราสร้างส่วนขยาย VS Code (วิธีที่เหมาะกับ IDE มากขึ้นในการโต้ตอบกับเอเจนต์ Codex) เราจำเป็นต้องใช้ Codex Harness เดิมเพื่อให้สามารถขับเคลื่อนเอเจนต์ลูปจาก UI ของ IDE ได้โดยไม่ต้องเขียนใหม่ ระบบจึงต้องรองรับรูปแบบการใช้งานที่ลึกกว่าการสั่งและตอบ เช่น การสำรวจเวิร์กสเปซ การสตรีมความคืบหน้าขณะเอเจนต์วิเคราะห์ และการส่งออก Diff เราเริ่มทดลองด้วยการเปิดให้ใช้งาน Codex ในฐานะเซิร์ฟเวอร์ MCP⁠(เปิดในหน้าต่างใหม่) แต่การทำให้ MCP ทำงานได้อย่างสมเหตุสมผลใน VS Code กลับเป็นความท้าทาย แทนที่จะทำเช่นนั้น เราได้สร้างโปรโตคอล JSON-RPC ที่สะท้อนลูป TUI ซึ่งกลายเป็น เวอร์ชันแรกแบบไม่เป็นทางการ⁠(เปิดในหน้าต่างใหม่) ของ App Server ขณะนั้นเราไม่คิดว่าผู้ใช้คนอื่นจะต้องพึ่งพา App Server จึงไม่ได้ออกแบบให้เป็น API ที่มั่นคง

ในช่วงเดือนต่อมาเมื่อ Codex เป็นที่นิยมมากขึ้น ทีมภายในและพันธมิตรภายนอกต้องการความสามารถในการฝัง Harness เดียวกันในผลิตภัณฑ์ของตน เพื่อเร่งกระบวนการพัฒนาซอฟต์แวร์ของผู้ใช้ ตัวอย่างเช่น JetBrains และ Xcode ต้องการประสบการณ์เอเจนต์ระดับ IDE ในขณะที่แอปเดสก์ท็อป Codex จำเป็นต้องประสานงานเอเจนต์ Codex หลายตัวพร้อมกัน ความต้องการเหล่านี้ผลักดันให้เราสร้างแพลตฟอร์มที่ทั้งผลิตภัณฑ์ของเราและการรวมกับพันธมิตรสามารถใช้งานได้อย่างมั่นคงและปลอดภัยตลอดเวลา ต้องสามารถผสานเข้ากับระบบอื่นได้ง่ายและเข้ากันได้กับเวอร์ชันก่อนหน้า หมายความว่าโปรโตคอลสามารถพัฒนาได้โดยไม่กระทบคลไคลเอนต์เดิม

ถัดไปเราจะอธิบายทีละขั้นตอนว่าเราออกแบบสถาปัตยกรรมและโปรโตคอลอย่างไร เพื่อให้ไคลเอนต์ที่แตกต่างกันสามารถใช้ Harness เดียวกันได้

กลไกด้านภายในของ Codex Harness

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

1. วงจรชีวิตของเธรดและการจัดเก็บ เธรดคือการสนทนาใน Codex ระหว่างผู้ใช้และเอเจนต์ Codex สร้างเธรดใหม่ ดึงเธรดเดิมกลับมาใช้งาน แตกเธรด และเก็บเธรดเข้าคลัง พร้อมเก็บประวัติอีเวนต์เพื่อให้ไคลเอนต์กลับมาเชื่อมต่อและแสดงไทม์ไลน์แบบต่อเนื่อง

2. การตั้งค่าและการตรวจสอบสิทธิ์ Codex โหลดการตั้งค่า จัดการค่าเริ่มต้น และดำเนินการยืนยันตัวตน เช่น “เข้าสู่ระบบด้วย ChatGPT” รวมทั้งจัดการสถานะของข้อมูลรับรอง

3. การดำเนินการของเครื่องมือและส่วนขยาย Codex ทำงานกับเครื่องมือ shell/file ในแซนด์บ็อกซ์และเชื่อมต่อเซิร์ฟเวอร์ MCP และทักษะ เพื่อให้สามารถทำงานร่วมในเอเจนต์ลูปภายใต้นโยบายเดียวกัน

ตรรกะของเอเจนต์ทั้งหมดที่เราได้กล่าวถึงที่นี่ รวมถึงลูปเอเจนต์หลัก อยู่ในส่วนหนึ่งของโค้ดเบส Codex CLI ที่เรียกว่า “Codex core⁠(เปิดในหน้าต่างใหม่)” Codex Coreป็นทั้งไลบรารีที่เก็บโค้ดเอเจนต์ทั้งหมด และเป็นและเป็นรันไทม์ที่เปิดขึ้นเพื่อรันเอเจนต์ลูปและจัดการการเก็บข้อมูลของเธรด Codex หนึ่ง (การสนทนา)

Codex Harness ต้องเปิดให้ไคลเอนต์เข้าถึงได้ เพื่อให้ระบบทำงานได้อย่างมีประสิทธิภาพ นั่นคือจุดที่ App Server เข้ามามีบทบาท

แผนภาพชื่อ “โฟลว์กระบวนการของแอปเซิร์ฟเวอร์” ไคลเอนต์ส่งข้อความ JSON-RPC ไปยังตัวอ่าน stdio ซึ่งจะส่งต่อคำขอไปยังตัวประมวลผลข้อความ Codex โปรเซสเซอร์โต้ตอบกับตัวจัดการเธรดและเธรดหลักผ่านเธรดสำหรับการค้นหา ตัวจัดการเธรด คำขอที่ส่งเข้ามา และอีเวนต์/การอัปเดต จากนั้นส่งการตอบกลับไปยังไคลเอนต์

App Server ทำหน้าที่เป็นโปรโตคอล JSON-RPC ระหว่างไคลเอนต์และเซิร์ฟเวอร์ และเป็นกระบวนการที่รันเธรด Codex core อย่างต่อเนื่อง ดังที่เห็นจากแผนภาพข้างต้น กระบวนการ App Server ประกอบด้วยสี่ส่วนหลัก ได้แก่ ตัวอ่าน stdio ตัวประมวลผลข้อความ Codex ตัวจัดการเธรด และเธรดหลัก ตัวจัดการเธรดจะสร้างเซสชันหลักหนึ่งเซสชันสำหรับแต่ละเธรด จากนั้นตัวประมวลผลข้อความ Codex จะสื่อสารโดยตรงกับแต่ละเซสชันหลักเพื่อส่งคำขอจากลูกค้าและรับการอัปเดต

คำขอจากไคลเอนต์หนึ่งครั้งสามารถก่อให้เกิดอีเวนต์อัปเดตหลายรายการ และอีเวนต์ที่ละเอียดเหล่านี้ช่วยให้เราสร้าง UI ที่สมบูรณ์บน App Server ได้ นอกจากนี้ตัวอ่าน stdio และตัวประมวลผลข้อความ Codex ยังทำหน้าที่เป็นชั้นการแปลระหว่างไคลเอนต์และเธรดหลักของ Codex ระบบแปลงคำขอ JSON-RPC ของไคลเอนต์ให้กลายเป็นการทำงานใน Codex Core รับฟังอีเวนต์ภายใน และจัดรูปอีเวนต์ระดับล่างให้เป็นการแจ้งเตือน JSON-RPC ที่เสถียรและเหมาะกับ UI

โปรโตคอล JSON-RPC ระหว่างไคลเอนต์กับ App Server ทำงานแบบสองทางอย่างสมบูรณ์ เธรดทั่วไปมีคำขอจากไคลเอนต์และการแจ้งเตือนจากเซิร์ฟเวอร์หลายรายการ นอกจากนี้ ซิร์ฟเวอร์สามารถเริ่มคำขอได้เมื่อเอเจนต์ต้องการข้อมูล เช่น การอนุมัติ จากนั้นหยุดการทำงานไว้จนกว่าไคลเอนต์จะตอบกลับ

องค์ประกอบพื้นฐานของบทสนทนา

ถัดไปเราจะอธิบายเกี่ยวกับองค์ประกอบพื้นฐานของการสนทนา ซึ่งเป็นส่วนประกอบสำคัญของโปรโตคอล App Server การออกแบบ API สำหรับลูปเอเจนต์เป็นเรื่องที่ท้าทาย เพราะการโต้ตอบระหว่างผู้ใช้กับเอเจนต์ไม่ได้เป็นคำขอหรือการตอบกลับแบบง่ายๆ คำขอจากผู้ใช้หนึ่งครั้งอาจแตกออกเป็นชุดขั้นตอนที่มีรูปแบบชัดเจน ซึ่งไคลเอนต์ต้องแสดงให้ครบถ้วน ทั้งอินพุตของผู้ใช้ ความคืบหน้าแบบค่อยเป็นค่อยไปของเอเจนต์ และอาร์ติแฟกต์ที่เกิดขึ้นระหว่างทาง (เช่น Diffs) เพื่อให้การสตรีมการโต้ตอบนั้นง่ายต่อการรวมเข้ากับระบบอื่นและทนต่อการทำงานข้าม UI เราจึงเลือกใช้หลักการพื้นฐานสามประการที่มีขอบเขตและวงจรชีวิตที่ชัดเจนดังนี้

1. รายการ: รายการคือหน่วยพื้นฐานของการป้อนข้อมูล/ผลลัพธ์ใน Codex รายการต่างๆ ถูกจัดประเภท (เช่น ข้อความของผู้ใช้ ข้อความของเอเจนต์ การเรียกใช้เครื่องมือ คำขออนุมัติ Diff) และแต่ละรายการมีวงจรชีวิตที่ชัดเจน

  • item/started เมื่อเริ่มต้นรายการ
  • อีเวนต์ item/*/delta ที่ไม่บังคับเป็นสตรีมเนื้อหา (สำหรับประเภทไอเท็มที่สตรีมได้)
  • item/completed เมื่อรายการเสร็จสิ้นพร้อมกับเพย์โหลดสุดท้าย

วงจรการทำงานนี้ช่วยให้ไคลเอนต์เริ่มแสดงผลได้ตั้งแต่ Started รับอัปเดตทีละส่วนผ่าน Delta และปิดขั้นตอนทั้งหมดเมื่อถึงขั้นตอน completed

2. เทิร์น: หนึ่งเทิร์นคือหนึ่งหน่วยของการทำงานของเอเจนต์ที่เริ่มต้นจากอินพุตของผู้ใช้ กระบวนการเริ่มขึ้นเมื่อไคลเอนต์ส่งอินพุตเข้ามา (เช่น “สั่งรันทดสอบและสรุปข้อผิดพลาด”) และจบลงเมื่อเอเจนต์สร้างผลลัพธ์สำหรับอินพุตนั้นเสร็จ ในเทิร์นหนึ่งจะมีลำดับไอเท็มที่แสดงขั้นตอนและผลลัพธ์ระหว่างทาง

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

ตอนนี้เราจะดูตัวอย่างการสนทนาที่เรียบง่ายระหว่างคลไคลเอนต์กับเอเจนต์ โดยใช้หลักการพื้นฐานเป็นตัวกำหนดรูปแบบของบทสนทนา

แผนภาพชื่อ “โฟลว์ข้อความของโปรโตคอลไคลเอนต์-เซิร์ฟเวอร์: ขั้นตอนการเริ่มต้นการเชื่อมต่อ” ไคลเอนต์ส่งคำสั่งเริ่มต้นงานพร้อมข้อมูลไคลเอนต์ไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์ตอบด้วยอีเวนต์ผลลัพธ์ซึ่งระบุ userAgent ว่า “my_client/1.0”

ตอนเริ่มต้นของบทสนทนา ไคลเอนต์และเซิร์ฟเวอร์ต้องตั้งค่า Handshake แบบ Initialize ให้เรียบร้อย ไคลเอนต์ต้องส่งคำขอ Initialize เพียงครั้งเดียวก่อนใช้วิธีอื่นใด และเซิร์ฟเวอร์จะยืนยันด้วยการตอบกลับ ขั้นตอนนี้ให้เซิร์ฟเวอร์แสดงความสามารถของตัวเอง และให้ทั้งสองฝ่ายตกลงเรื่องเวอร์ชันของโปรโตคอล ฟีเจอร์ฟลัก และค่าเริ่มต้น ก่อนเริ่มงานจริง ต่อไปนี้คือตัวอย่างเพย์โหลดจากส่วนขยาย VS Code ของ OpenAI:

JSON

1
{
2
  "method": "initialize",
3
  "id": 0,
4
  "params": {
5
    "clientInfo": {
6
      "name": "codex_vscode",
7
      "title": "Codex VS Code Extension",
8
      "version": "0.1.0"
9
    }
10
  }
11
}

นี่คือสิ่งที่เซิร์ฟเวอร์ส่งกลับมา:

JSON

1
{
2
  "id": 0,
3
  "result": {
4
    "userAgent": "codex_vscode/0.94.0-alpha.7 (Mac OS 26.2.0; arm64) vscode/2.4.22 (codex_vscode; 0.1.0)"
5
  }
6
}
แผนภาพชื่อ “โฟลว์ข้อความของโปรโตคอลไคลเอนต์-เซิร์ฟเวอร์: วงจรชีวิตของเธรดและเทิร์น” ไคลเอนต์ส่งคำขอ thread/start และ turn/start ไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์ส่งอีเวนต์ thread/started, turn/started, item/started และ item/completed เพื่อแสดงเทิร์นที่ผู้ใช้สั่งว่า “รันทดสอบทั้งหมดแล้วสรุปข้อผิดพลาด”

เมื่อไคลเอนต์ส่งคำขอใหม่ มันจะเริ่มด้วยการสร้างเธรด และตามด้วยเทิร์น เซิร์ฟเวอร์จะส่งการแจ้งเตือนกลับมาเกี่ยวกับความคืบหน้า (thread/started และ turn/started) นอกจากนี้ระบบจะส่งกลับข้อมูลที่ลงทะเบียนเป็นรายการ เช่น ข้อความของผู้ใช้ที่นี่ด้วย

แผนภาพชื่อ “โฟลว์ข้อความโปรโตคอลไคลเอนต์-เซิร์ฟเวอร์: การดำเนินการเครื่องมือพร้อมการอนุมัติที่เลือกได้” ระหว่างการเรียกใช้เครื่องมือ เซิร์ฟเวอร์จะส่ง item/started จากนั้นส่ง item/commandExecution/requestApproval พร้อมเหตุผล (“run tests”) ไคลเอนต์ส่งคืนเหตุการณ์การอนุมัติ (อนุญาต/ปฏิเสธ) จากนั้นเซิร์ฟเวอร์จะส่ง item/completed เพื่อแสดงการดำเนินการคำสั่ง ("pnpm test")

การเรียกใช้เครื่องมือจะถูกส่งกลับไปยังไคลเอนต์ในรูปแบบรายการ นอกจากนี้เซิร์ฟเวอร์อาจขอการอนุมัติจากไคลเอนต์ก่อนที่จะดำเนินการได้ โดยการส่งคำขอจากเซิร์ฟเวอร์ การอนุมัติจะหยุดการดำเนินการไว้ชั่วคราวจนกว่าลูกค้าจะตอบกลับด้วย (“อนุญาต” หรือ “ปฎิเสธ” นี่คือหน้าตาของกระบวนการอนุมัติในส่วนขยาย VS Code:

หน้าต่างขออนุญาตในอินเทอร์เฟซโทนสีเข้มถามว่า “คุณต้องการอนุญาตให้ฉันรัน pnpm test สำหรับเวิร์กสเปซนี้หรือไม่” มีตัวเลือกดังนี้: 1) Yes, 2) Yes และไม่ต้องถามอีกสำหรับคำสั่งที่เริ่มต้นด้วย pnpm test, และ 3) No โดยมีปุ่ม Submit อยู่ด้านล่าง
แผนภาพชื่อ “โฟลว์ข้อความโปรโตคอลไคลเอนต์-เซิร์ฟเวอร์:โฟลว์งข้อควาของมเอเจนต์สตรีมมิง” เซิร์ฟเวอร์สตรีมข้อความผู้ช่วยเป็นส่วน ๆ: item/started, เหตุการณ์ agentMessage/delta สองครั้ง (“รันการทดสอบ 3 ครั้ง” “ผ่านทั้งหมด” จากนั้นแสดงรายการเสร็จสมบูรณ์ เทิร์นสิ้นสุดแสดง turn/completed

ท้ายที่สุดเซิร์ฟเวอร์จะส่งข้อความของเอเจนต์และจบเทิร์นด้วย turn/completed เหตุการณ์ Delta ของข้อความจากเอเจนต์จะสตรีมชิ้นส่วนของข้อความกลับมาเรื่อยๆ จนกว่าข้อความจะเสร็จสมบูรณ์ด้วย item/completed

ข้อความในแผนภาพสร้างขึ้นให้อ่านง่าย หากคุณต้องการตรวจสอบไฟล์ JSON ของการทำงานทั้งเทิร์น คุณสามารถเรียกใช้งาน Test Client ได้จาก Repository ของ Codex CLI

Bash

1
codex debug app-server send-message-v2 "run tests and summarize failures"

การทำงานร่วมกับไคลเอนต์

ตอนนี้มาดูกันว่าไคลเอนต์แต่ละอินเทอร์เฟซฝัง Codex ผ่าน App Server อย่างไร เราจะอธิบายครอบคลุมสามรูปแบบ ได้แก่ แอปและ IDE ในเครื่อง รันไทม์ Codex บนเว็บ และ TUI

แผนภาพชื่อ “ไคลเอนต์ Codex ที่ผสานรวมกับ Codex Harness ผ่านแอปเซิร์ฟเวอร์” ไคลเอนต์จากผู้พัฒนาหลัก (Codex Desktop App, TUI/CLI, Web Runtime) และการรวมระบบจากผู้พัฒนาภายนอก (JetBrains IDEs, VS Code, Xcode) สื่อสารกับ Codex harness ผ่านการเรียก JSON-RPC

ทั้งสามรายการใช้การขนส่งข้อมูลเป็น JSON-RPC ผ่าน stdio (JSONL) JSON-RPC ทำให้การสร้าง Client Bindings ในภาษาที่คุณเลือกเป็นเรื่องง่าย ทีม Codex และพันธมิตรได้พัฒนา App Server client ในหลายภาษา เช่น Go, Python, TypeScript, Swift และ Kotlin สำหรับ TypeScript คุณสามารถสร้างนิยามได้โดยตรงจากโปรโตคอล Rust

Bash

1
codex app-server generate-ts

สำหรับภาษาอื่นๆ คุณสามารถสร้างชุดโครงร่าง JSON และส่งไปยังเครื่องมือสร้างโค้ดที่คุณต้องการได้ด้วยการรันคำสั่ง

Bash

1
codex app-server generate-json-schema
แอปพลิเคชันในเครื่อง & IDE ในเครื่อง
ภาพหน้าจอของ VS Code ที่กำลังรันส่วนขยาย Codex ไฟล์ทดสอบ Rust เปิดอยู่ พร้อมกับแผง Codex ด้านล่างที่ระบุการรัน fmt และ cargo test -p codex-app-server และรายงานว่าการฟอร์แมตและทดสอบกำลังทำงานอยู่ขณะรอผลสุดท้าย

โดยทั่วไปแล้วไคลเอนต์ภายในเครื่องจะบันเดิลหรือดึงไบนารีของ App Server ที่เฉพาะเจาะจงสำหรับแพลตฟอร์ม จากนั้นเปิดใช้งานเป็นกระบวนการลูกที่ทำงานต่อเนื่องระยะยาว และคงช่องทาง stdio แบบสองทิศทางไว้สำหรับ JSON-RPC ตัวอย่างเช่น ใน VS Code Extension และ Desktop App ของเรา อาร์ติแฟกต์ที่จัดส่งจะรวมไบนารี Codex ที่เฉพาะแพลตฟอร์ม และถูกตรึงไว้กับเวอร์ชันที่ผ่านการทดสอบแล้ว เพื่อให้ไคลเอนต์รันบิตเดียวกันกับที่เราได้ตรวจสอบความถูกต้องไว้เสมอ

ไม่ใช่ทุกการเชื่อมต่อที่จะอัปเดตไคลเอนต์ได้บ่อยครั้ง บางพันธมิตร เช่น Xcode แยกการออกเวอร์ชันโดยเก็บไคลเอนต์ให้คงที่ และให้สามารถเชื่อมกับ App Server เวอร์ชันใหม่เมื่อจำเป็น ด้วยวิธีนี้ พวกเขาสามารถนำการปรับปรุงฝั่งเซิร์ฟเวอร์มาใช้ (เช่น การบีบอัดอัตโนมัติที่ดีขึ้นใน Codex Core หรือการรองรับคีย์การตั้งค่าใหม่) และปล่อยการแก้บั๊กโดยไม่ต้องรออัปเดตคลไคลเอนต์ App Server มีส่วนติดต่อ JSON-RPC ที่ออกแบบให้เข้ากันได้ย้อนหลัง ทำให้ไคลเอนต์รุ่นเก่าสามารถใช้งานกับเซิร์ฟเวอร์รุ่นใหม่ได้โดยไม่เกิดปัญหา

Codex Web
ภาพหน้าจอของอินเทอร์เฟซเว็บ Codex ที่แสดงการอัปเดตชื่อ “อัปเดตข้อความสำเร็จในการเข้าสู่ระบบ” แผงหน้าต่างด้านซ้ายสรุปการเปลี่ยนแปลง การทดสอบ และไฟล์ที่แก้ไข ขณะที่แผงด้านขวาแสดงความแตกต่างของโค้ดสำหรับ login.rs พร้อมการปรับถ้อยคำของข้อความแสดงความสำเร็จในการเข้าสู่ระบบให้เป็นเวอร์ชันอัปเดต

Codex Web ใช้ Codex Harness เช่นกัน แต่รันในสภาพแวดล้อมแบบคอนเทนเนอร์ เวิร์กเกอร์จะจัดเตรียมคอนเทนเนอร์พร้อมเวิร์กสเปซที่ถูกเช็คเอาต์ รันไฟล์โปรแกรม App Server ภายใน และรักษาช่องทาง JSON-RPC ผ่าน stdio2 ที่ทำงานยาวนาน เว็บแอป (ที่ทำงานในแท็บเบราว์เซอร์ของผู้ใช้) ติดต่อกับแบ็กเอนด์ Codex ผ่าน HTTP และ SSE ซึ่งสตรีมเหตุการณ์งานที่สร้างโดยเวิร์กเกอร์ วิธีนี้ช่วยให้ UI ฝั่งเบราว์เซอร์มีน้ำหนักเบา ขณะเดียวกันก็ยังคงให้รันไทม์ที่สม่ำเสมอทั้งบนเดสก์ท็อปและเว็บ

เนื่องจากเซสชันเว็บมีลักษณะชั่วคราว (เช่น แท็บปิดหรือเครือข่ายหลุด) เว็บแอปจึงไม่สามารถเป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับงานที่ต้องดำเนินการต่อเนื่องเป็นเวลานาน การเก็บสถานะและความคืบหน้าไว้บนเซิร์ฟเวอร์หมายความว่างานจะดำเนินต่อไปได้แม้ว่าแท็บจะหายไป โปรโตคอลการสตรีมและเซสชันเธรดที่บันทึกไว้ช่วยให้เซสชันใหม่เชื่อมต่อกลับมาได้ง่าย สานต่อจากที่ค้างไว้ และตามทันได้โดยไม่ต้องสร้างสถานะใหม่ในไคลเอนต์

TUI/Codex CLI
ภาพหน้าจอของเทอร์มินัลที่กำลังรัน Codex CLI แสดงแบนเนอร์ OpenAI Codex พร้อมโมเดล GPT-5.2-Codex ระดับกลาง คำสั่งของผู้ใช้ “อธิบาย app server ให้ฟังหน่อย” และสถานะ “กำลังดำเนินการ” ด้านล่างนี้มีคำแนะนำปรากฏขึ้น: “เขียนชุดทดสอบสำหรับ @filename” พร้อมตัวเลือกทางลัด

ในอดีต TUI เป็นไคลเอนต์ “เนทีฟ” ที่ทำงานในกระบวนการเดียวกันกับลูปของเอเจนต์ และสื่อสารโดยตรงกับชนิดข้อมูลหลักของ Rust แทนที่จะใช้โปรโตคอลของแอปเซิร์ฟเวอร์ สิ่งนั้นทำให้การทำซ้ำในระยะแรกเป็นไปอย่างรวดเร็ว แต่ก็ทำให้ TUI กลายเป็นส่วนติดต่อกรณีพิเศษ

ตอนนี้เมื่อมี App Server แล้ว เราวางแผนที่จะ ปรับโครงสร้าง TUI⁠(เปิดในหน้าต่างใหม่) เพื่อให้ทำงานเหมือนกับไคลเอนต์อื่นๆ ที่สามารถเปิดใช้งานกระบวนการย่อยของ App Server สื่อสารด้วย JSON-RPC ผ่าน stdio และแสดงผลสตรีมของเหตุการณ์และการอนุมัติแบบเดียวกัน สิ่งนี้จะปลดล็อกเวิร์กโฟลว์ที่ TUI สามารถเชื่อมต่อกับเซิร์ฟเวอร์ Codex ที่ทำงานอยู่บนเครื่องระยะไกลได้ โดยทำให้เอเจนต์อยู่ใกล้กับการประมวลผลและทำงานต่อได้แม้แล็ปท็อปจะเข้าสู่โหมดสลีปหรือตัดการเชื่อมต่อ ขณะเดียวกันก็ยังส่งมอบการอัปเดตแบบสดและการควบคุมในเครื่องได้

การเลือกโปรโตคอลที่ถูกต้อง

Codex App Server จะเป็นวิธีการรวมระบบสำคัญที่เราจะสนับสนุนต่อไป แต่ก็ยังมีวิธีอื่นที่ฟังก์ชันน้อยกว่า โดยค่าเริ่มต้นเราแนะนำให้ไคลเอนต์ใช้ Codex App Server ในการรวมเข้ากับ Codex แต่ก็ควรดูวิธีการรวมระบบแบบต่างๆ และเข้าใจข้อดีข้อเสียของแต่ละวิธี วิธีที่พบบ่อยที่สุดในการใช้งาน Codex พร้อมคำแนะนำว่าแต่ละวิธีเหมาะกับเมื่อใด

โปรโตคอล JSON-RPC

Codex ในฐานะเซิร์ฟเวอร์ MCP

เรียกใช้ codex mcp-server⁠(เปิดในหน้าต่างใหม่) และเชื่อมต่อจากไคลเอนต์ MCP ใดก็ได้ที่รองรับเซิร์ฟเวอร์ stdio (เช่น OpenAI Agents SDK⁠(เปิดในหน้าต่างใหม่)) นี่เป็นตัวเลือกที่ดีหากคุณมีเวิร์กโฟลว์ที่ใช้ MCP อยู่แล้ว และต้องการเรียกใช้ Codex เป็นเครื่องมือที่สามารถเรียกใช้งานได้ ข้อเสียคือคุณได้รับเฉพาะสิ่งที่ MCP รองรับเท่านั้น ดังนั้นการโต้ตอบเฉพาะของ Codex ที่อาศัยความหมายเชิงเซสชันที่สมบูรณ์ยิ่งขึ้น (เช่น การอัปเดต diff) อาจไม่สามารถแมปผ่าน MCP เอนด์พอยต์ได้อย่างราบรื่น

โปรโตคอลการจัดการเอเจนต์ข้ามผู้ให้บริการ

ระบบนิเวศบางระบบมีอินเทอร์เฟซแบบพกพาที่สามารถกำหนดเป้าหมายไปยังผู้ให้บริการโมเดลและรันไทม์หลายรายได้ วิธีนี้อาจเหมาะสมหากคุณต้องการตัวแทนเดียวที่ควบคุมเอเจนต์หลายตัว ข้อเสียคือโปรโตคอลเหล่านี้มักมุ่งไปที่ชุดความสามารถพื้นฐาน ทำให้การโต้ตอบที่ซับซ้อนกว่าอาจไม่สามารถแสดงได้ชัดเจน โดยเฉพาะเมื่อความหมายของเครื่องมือและเซสชันที่เฉพาะเจาะจงกับผู้ให้บริการมีความสำคัญ ขอบเขตนี้กำลังเติบโตอย่างรวดเร็ว และเราคาดว่าจะมีมาตรฐานร่วมกันเกิดขึ้นมากขึ้น เมื่อเราค้นหาพื้นฐานที่ดีที่สุดเพื่อแทนเวิร์กโฟลว์ของเอเจนต์ในโลกแห่งความเป็นจริง (ทักษะ⁠(เปิดในหน้าต่างใหม่) เป็นตัวอย่างที่ดีของเรื่องนี้)

เซิร์ฟเวอร์แอป Codex

เลือก App Server เมื่อคุณต้องการให้ชุดเครื่องมือ Codex แบบเต็มถูกเปิดเผยเป็นสตรีมเหตุการณ์ที่เสถียรและใช้งานง่ายกับ UI คุณจะได้รับทั้งฟังก์ชันการทำงานเต็มรูปแบบของลูปเอเจนต์ และฟีเจอร์สนับสนุนอื่นๆ เช่น การลงชื่อเข้าใช้ด้วย ChatGPT การค้นหาโมเดล และการจัดการการกำหนดค่า ค่าใช้จ่ายหลักอยู่ที่การทำงานรวมระบบ เนื่องจากต้องสร้าง JSON-RPC binding ฝั่งคลไคลเอนต์ในภาษาที่คุณใช้ ในทางปฏิบัติ Codex สามารถทำงานหนักได้หากคุณป้อน JSON Schema และเอกสารประกอบให้กับมัน ทีมหลายทีมที่เราร่วมงานด้วยสามารถสร้างการรวมระบบที่ทำงานได้อย่างรวดเร็วด้วย Codex

วิธีอื่นๆ ในการฝัง Codex

Codex Exec⁠(เปิดในหน้าต่างใหม่)

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

Codex SDK⁠(เปิดในหน้าต่างใหม่)

ไลบรารี TypeScript สำหรับการควบคุมเอเจนต์ Codex ภายในเครื่องด้วยโปรแกรมจากแอปพลิเคชันของคุณเอง เหมาะที่สุดเมื่อคุณต้องการอินเทอร์เฟซไลบรารีแบบเนทีฟสำหรับเครื่องมือและเวิร์กโฟลว์ฝั่งเซิร์ฟเวอร์ โดยไม่ต้องสร้างไคลเอนต์ JSON-RPC แยกต่างหาก เนื่องจากมีการจัดส่งก่อน App Server จึงรองรับภาษาน้อยกว่าและมีขอบเขตการใช้งานที่จำกัดในขณะนี้ ถ้ามีนักพัฒนาสนใจ เราอาจเพิ่ม SDK ที่ครอบโปรโตคอล App Server ทำให้ทีมใช้ส่วนต่างๆ ของ Harness ได้มากขึ้นโดยไม่ต้องสร้าง JSON-RPC Binding

การนำไปต่อยอด

ในโพสต์นี้เราได้แบ่งปันวิธีการออกแบบมาตรฐานใหม่สำหรับการโต้ตอบกับเอเจนต์ และวิธีการเปลี่ยน Codex Harness ให้เป็นโปรโตคอลที่เสถียรและเป็นมิตรกับไคลเอนต์ เราได้กล่าวถึงวิธีที่ App Server เปิดเผย Codex core ช่วยให้ไคลเอนต์ขับเคลื่อนลูปเอเจนต์ได้อย่างเต็มที่ และสนับสนุนการใช้งานที่หลากหลาย เช่น TUI การผสานรวมกับ IDE ในเครื่อง และเว็บรันไทม์

หากสิ่งนี้จุดประกายไอเดียในการผสาน Codex เข้ากับเวิร์กโฟลว์ของคุณเอง คุณควรลองใช้ App Server ซอร์สโค้ดทั้งหมดอยู่ใน Codex CLI โอเพนซอร์ส รีโป⁠(เปิดในหน้าต่างใหม่) สามารถส่งข้อเสนอแนะและคำขอฟีเจอร์มาได้ตามสะดวก เรายินดีที่จะได้รับฟังคุณ และจะทำให้เอเจนต์เข้าถึงได้ง่ายขึ้นสำหรับทุกคนต่อไป

ผู้เขียน

Celia Chen

การรับทราบ

ขอขอบคุณ Michael Bolin, Owen Lin, Eric Traut และ Rasmus Rygaard เป็นอย่างสูงที่มีส่วนร่วมในโพสต์นี้ และขอขอบคุณทีม Codex ทั้งหมดที่ทำงานเกี่ยวกับ App Server

เชิงอรรถ

  1. 1

    เราใช้รูปแบบ “JSON‑RPC lite” โดยยังคงโครงสร้างคำขอ/คำตอบ/การแจ้งเตือนเหมือนเดิม แต่ละเว้น "jsonrpc": "2.0" ส่วนหัวถูกจัดกรอบเป็น JSONL ผ่าน stdio แทนที่จะเป็น JSON‑RPC 2.0 แบบเคร่งครัด.

  2. 2

     “stdio” หมายถึง stdin/stdout ของ app-server ภายในคอนเทนเนอร์ ในสภาพแวดล้อมแบบโฮสต์ สตรีมเหล่านี้มักถูกส่งผ่านการเชื่อมต่อเครือข่ายแบบยาว (เช่น คล้าย WebSocket) ไปยังรันไทม์ของคอนเทนเนอร์ ทำให้ทำงานเหมือน stdio แม้ไม่ใช่ Pipe ในเครื่องจริง

อ่านต่อ

ดูทั้งหมด
Tax Agent > Art Card
การสร้างเอเจนต์ด้านภาษีที่พัฒนาตนเองได้ด้วย Codex

วิศวกรรม

codex windows > art card
การสร้างแซนด์บ็อกซ์ที่มีความปลอดภัยและมีประสิทธิภาพเพื่อใช้งาน Codex บน Windows

วิศวกรรม

MRC 1_1
ย้อนรอยที่มาของเหล่าก๊อบลิน

วิศวกรรม