การผสานรวม Codex API: คู่มือติดตั้งฉบับสมบูรณ์

การเชื่อมต่อโมเดลภายนอกเข้ากับ Codex เป็นกระบวนการที่ซับซ้อน คู่มือนี้ใช้ Kimi API เป็นตัวอย่างปฏิบัติจริงเพื่อพาคุณตั้งค่า Codex API แบบครบถ้วนบน macOS และ Windows

Codex คืออะไร?

Codex คือเอเจนต์เขียนโค้ดของ OpenAI สำหรับงานในรีโพซิทอรีและเทอร์มินัล โดยสามารถ:

• เขียนโค้ด: สร้างฟังก์ชัน เทสต์ สคริปต์ และฟีเจอร์เฉพาะจุด

• ทำความเข้าใจโค้ดเบสที่ไม่คุ้นเคย: ค้นหาไฟล์ ไล่ดูการเรียกใช้งาน และอธิบายคอมโพเนนต์ต่าง ๆ

• รีวิวโค้ด: ระบุจุดที่อาจมีข้อบกพร่อง สมมติฐานที่มีความเสี่ยง เทสต์ที่ขาดหาย และประเด็นด้านความปลอดภัย

• ดีบักและแก้ไขปัญหา: จำลองข้อผิดพลาด เสนอการแก้ไข และรันการตรวจสอบ

• ทำงานประจำให้เป็นอัตโนมัติ: อัปเดตไฟล์และรันเวิร์กโฟลว์ที่มีเอกสารกำกับ โดยต้องได้รับการอนุมัติจากคุณ

ติดตั้งและลงชื่อเข้าใช้ Codex

ส่วนที่ 1: ติดตั้ง Codex CLI

1. เปิด Terminal บน macOS หรือ PowerShell บน Windows

2. รันคำสั่งตามระบบปฏิบัติการของคุณ:

macOS:

Windows:

1. รอจนการติดตั้งเสร็จสิ้น จากนั้นปิดและเปิด Terminal หรือ PowerShell ใหม่

2. รัน:

1. เลือก Sign in with ChatGPT ทำการลงชื่อเข้าใช้ผ่านเบราว์เซอร์ให้เสร็จสิ้น แล้วกลับมาที่ Terminal หรือ PowerShell

ส่วนที่ 2: ติดตั้งแอปเดสก์ท็อป Codex

1. ไปที่หน้าแอปเดสก์ท็อป Codex อย่างเป็นทางการ

2. ดาวน์โหลดแอปเดสก์ท็อป ChatGPT สำหรับ macOS หรือ Windows

3. ติดตั้งและเปิดแอป จากนั้นลงชื่อเข้าใช้ด้วยบัญชี ChatGPT ของคุณ

4. สร้างงานหรือเปิดโปรเจกต์ แล้วเลือก Codex เป็นโหมดการทำงาน

5. พิมพ์ Say hello in one sentence. แล้วส่งข้อความ

โมเดล AI ในตัวเทียบกับ LLM API ภายนอก

หลังจากติดตั้ง Codex แล้ว คุณสามารถใช้โมเดล AI ในตัว หรือเชื่อมต่อกับ LLM API ภายนอกที่รองรับได้ ตัวเลือกที่เหมาะสมที่สุดขึ้นอยู่กับว่าคุณต้องการตั้งค่ามากน้อยแค่ไหน ความยืดหยุ่นแค่ไหน และการจัดการบัญชีอย่างไร

ใช้โมเดลในตัวของ Codex

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

ข้อดี:

• ตั้งค่าได้รวดเร็ว ไม่ต้องทำขั้นตอนเพิ่มเติม

• เชื่อมต่อโดยตรงกับเครื่องมือและฟีเจอร์ของ Codex

• มีบริการและข้อมูลรับรองให้จัดการน้อยลง

ข้อจำกัด:

• เลือกได้เฉพาะโมเดลที่มีให้ใช้งานในบัญชีของคุณเท่านั้น

• มีความยืดหยุ่นน้อยกว่าหากต้องการใช้โมเดลจากผู้ให้บริการรายอื่น

• ต้องมีการสมัครสมาชิก GPT และค่าใช้จ่ายในการใช้งานค่อนข้างสูง

ใช้ LLM API ภายนอก

API ภายนอกให้ตัวเลือกโมเดลมากขึ้น และให้คุณใช้บัญชีที่มีอยู่แล้วกับผู้ให้บริการรายอื่นได้ อย่างไรก็ตาม บางโมเดลต้องมีการตั้งค่าเพิ่มเติมหรือเครื่องมือช่วยรองรับความเข้ากันได้ในเครื่องก่อนที่ Codex จะใช้งานได้

ข้อดี:

• เข้าถึงโมเดลจากผู้ให้บริการรายอื่นได้

• มีความยืดหยุ่นมากขึ้นสำหรับงานเขียนโค้ดที่หลากหลาย

• ควบคุมบัญชี API ภายนอกและการใช้งานได้แยกต่างหาก

• ไม่ต้องสมัครสมาชิก GPT เหมาะสำหรับกรณีที่คำนึงถึงต้นทุน

ข้อจำกัด:

• ต้องมี API key และการตั้งค่าเพิ่มเติม

• อาจต้องใช้ตัวจัดเส้นทาง (router) ในเครื่องที่ต้องรันค้างไว้ตลอด

• เรื่องการเรียกเก็บเงิน ความเข้ากันได้ ความเป็นส่วนตัว และการแก้ไขปัญหา ขึ้นอยู่กับผู้ให้บริการภายนอก

หากต้องการตั้งค่าให้เร็วที่สุด ให้เริ่มด้วยโมเดลในตัว แต่ถ้าคุณมีบัญชี API ภายนอกอยู่แล้ว หรือต้องการตัวเลือกโมเดลที่มากขึ้น ให้ทำตามขั้นตอนต่อไปนี้ ซึ่งใช้ Kimi API เป็นตัวอย่างในการเชื่อมต่อโมเดลภายนอกเข้ากับ Codex

วิธีเชื่อมต่อ External LLM API เข้ากับ Codex: ตัวอย่างการใช้ Kimi

การตั้งค่าบน macOS

ขั้นตอนที่ 1: เปิด Terminal A และตรวจสอบ Node.js กับ npm

ตำแหน่ง: กด Command+Space พิมพ์ Terminal แล้วกด Enter ให้ถือว่าหน้าต่างแรกนี้คือ Terminal A

รันคำสั่ง:

ผลลัพธ์ที่คาดหวัง: แต่ละคำสั่งจะแสดงหมายเลขเวอร์ชัน ตัวอย่างผลลัพธ์เช่น v22.x.x สำหรับ Node.js และ 10.x.x สำหรับ npm เป็นเพียงตัวอย่าง ไม่ใช่ข้อกำหนดขั้นต่ำ

หากไม่พบคำสั่งดังกล่าว: เปิดเบราว์เซอร์ ไปที่ https://nodejs.org/en/download ดาวน์โหลดไฟล์ .pkg เวอร์ชัน LTS สำหรับ macOS เปิดโฟลเดอร์ Downloads ใน Finder ดับเบิลคลิกไฟล์ติดตั้ง แล้วยอมรับค่าเริ่มต้นของตัวติดตั้ง ปิด Terminal ด้วย Command+Q เปิด Terminal A ใหม่ แล้วรันคำสั่งตรวจสอบเวอร์ชันทั้งสองอีกครั้ง อย่าดำเนินการต่อจนกว่าทั้งสองคำสั่งจะแสดงเวอร์ชันออกมา

ขั้นตอนที่ 2: สร้าง Kimi API key

เปิด Kimi API platform สร้าง API key จากคอนโซล แล้วเก็บไว้ใน password manager หรือ secret manager หากคอนโซลของคุณแสดงคีย์แบบเต็มให้เห็นเพียงครั้งเดียว ให้คัดลอกไว้ก่อนออกจากหน้านั้น

ขั้นตอนที่ 3: ตั้งค่า MOONSHOT_API_KEY ใน Terminal A

ตำแหน่ง: กลับไปที่ Terminal A

รันคำสั่ง:

แทนที่เฉพาะ YOUR_KIMI_API_KEY ด้วยคีย์ Kimi จริงของคุณ คงเครื่องหมายคำพูดและชื่อตัวแปร MOONSHOT_API_KEY ไว้ตามเดิม

ผลลัพธ์ที่คาดหวัง: คำสั่ง export จะไม่แสดงผลลัพธ์ใด ๆ ให้ตรวจสอบว่ามีค่าอยู่จริงโดยไม่ต้องแสดงค่านั้น:

Terminal ควรแสดงข้อความ Kimi key is set

ขั้นตอนที่ 4: ทดสอบ Kimi โดยตรงจาก Terminal A

ตำแหน่ง: ใช้ Terminal A ต่อไป ซึ่งตั้งค่า MOONSHOT_API_KEY ไว้แล้ว

รันคำสั่ง:

ผลลัพธ์ที่คาดหวัง: จะปรากฏการตอบกลับแบบ JSON ที่มีข้อความที่สร้างขึ้นอยู่ใน choices[0].message.content

ขั้นตอนที่ 5: เปิด Terminal B แล้วเริ่มรัน router ใน Terminal A

ตำแหน่ง: ให้ Terminal A ยังทำงานอยู่ กด Command+N เพื่อเปิดหน้าต่างที่สอง เรียกหน้าต่างใหม่นี้ว่า Terminal B จากนั้นกลับไปที่ Terminal A ก่อนรันคำสั่ง router

รันใน Terminal A:

อย่าเปลี่ยน base URL หรือโมเดล และ $MOONSHOT_API_KEY ต้องคงเป็นการอ้างอิงตัวแปร ไม่ใช่การวางคีย์ซ้ำอีกชุดหนึ่ง

ข้อความแจ้งเตือนที่อาจปรากฏในการรันครั้งแรก: npx อาจแสดงข้อความ Need to install ... Ok to proceed? (y) ให้ตรวจสอบชื่อแพ็กเกจและแหล่งที่มาของบุคคลที่สามที่เชื่อมโยงไว้ก่อน พิมพ์ y แล้วกด Enter เฉพาะเมื่อคุณยอมรับแพ็กเกจนั้น ไม่มีการยืนยันว่าเวอร์ชันแพ็กเกจใดที่ใช้ทดสอบในที่นี้

ผลลัพธ์ที่คาดหวัง: โปรเซสจะยังคงทำงานอยู่และรายงานว่ากำลังรอรับการเชื่อมต่อที่ 127.0.0.1:8787 ให้เปิด Terminal A ทิ้งไว้

หากไม่สำเร็จ: หาก npm ไม่สามารถดาวน์โหลดแพ็กเกจได้ ให้ตรวจสอบการเชื่อมต่ออินเทอร์เน็ต แล้วรัน node --version และ npm --version อีกครั้ง หากพอร์ต 8787 ถูกใช้งานอยู่แล้ว ให้หยุดโปรเซสในเครื่องอื่นที่ใช้พอร์ตนั้น หรือกลับไปที่ terminal ของโปรเซสนั้นแล้วกด Ctrl+C จากนั้นรันคำสั่ง router อีกครั้ง

ขั้นตอนที่ 6: ทดสอบ localhost จาก Terminal B

ตำแหน่ง: คลิกที่ Terminal B

รันคำสั่ง:

ผลลัพธ์ที่คาดไว้: Terminal B จะแสดงอีเวนต์สตรีมมิงหรือเอาต์พุตแบบ Responses ที่มีคำทักทายสั้น ๆ หนึ่งประโยค ลำดับอีเวนต์ที่แน่นอนอาจแตกต่างกันไปตามรุ่นของ router

หากคุณเห็น Connection refused: ให้ดูที่ Terminal A หาก router หยุดทำงาน ให้รันคำสั่งของขั้นตอนที่ 5 ใหม่และปล่อยหน้าต่างนั้นเปิดไว้ หาก Terminal A แสดง 401 จากฝั่ง upstream ให้รีเซ็ต MOONSHOT_API_KEY ที่นั่นแล้วรีสตาร์ท router

ขั้นตอนที่ 7: สร้างและแก้ไขไฟล์คอนฟิก Codex บน macOS

ตำแหน่งที่ทำงาน: ใช้ Terminal B ต่อไป

รัน:

คำสั่งเหล่านี้จะสร้างไฟล์คอนฟิกระดับผู้ใช้ขึ้นมาหากยังไม่มี สำรองไฟล์เดิมที่มีอยู่ และเปิดไฟล์ ~/.codex/config.toml ใน TextEdit

หากไฟล์ว่างเปล่า

ให้วางคอนฟิกฉบับสมบูรณ์ต่อไปนี้

หากไฟล์มีการตั้งค่าอยู่แล้ว

อย่าวางคอนฟิกฉบับสมบูรณ์ทับไฟล์เดิมทั้งหมด ให้เก็บการตั้งค่าอื่นที่ไม่เกี่ยวข้องไว้ และอัปเดตบรรทัดที่จำเป็นทีละบรรทัด

1. หาบรรทัดที่ขึ้นต้นด้วย model = แล้วแทนที่ทั้งบรรทัดด้วย:

1. หาบรรทัดที่ขึ้นต้นด้วย model_provider = แล้วแทนที่ทั้งบรรทัดด้วย:

1. หาบรรทัดที่ขึ้นต้นด้วย model_context_window = แล้วแทนที่ทั้งบรรทัดด้วย:

1. หาบรรทัดที่ขึ้นต้นด้วย model_supports_reasoning_summaries = แล้วแทนที่ทั้งบรรทัดด้วย:

หากการตั้งค่าทั้งสี่ข้อนี้ข้อใดยังไม่มีอยู่ ให้เพิ่มบรรทัดที่ขาดไว้ใกล้ส่วนบนของไฟล์

1. หาและลบทั้งบรรทัดที่ขึ้นต้นด้วย:

และหาและลบทั้งบรรทัดที่ขึ้นต้นด้วย:

1. เพิ่มส่วนด้านล่างนี้:

อย่าลบส่วนของผู้ให้บริการ (provider) อื่น เช่น [model_providers.openai]

เก็บการตั้งค่าเดิมที่ไม่เกี่ยวข้องไว้ รวมถึง notify การอนุมัติ (approval) แซนด์บ็อกซ์ โปรเจกต์ และการตั้งค่าอินเทอร์เฟซ อย่าคัดลอกบรรทัด notify ของผู้ใช้คนอื่นมาใช้ เพราะอาจมี absolute path ที่เจาะจงกับเครื่องคอมพิวเตอร์นั้น

กด Command+S เพื่อบันทึกไฟล์ จากนั้นปิด TextEdit

ขั้นตอนที่ 8: รีสตาร์ท Codex และรันการทดสอบฉบับสมบูรณ์บน macOS

ตำแหน่งที่ทำงาน: ปล่อยให้ router ทำงานต่อไปใน Terminal A ส่วนใน Terminal B ให้ปิดเซสชัน Codex ที่มีอยู่ด้วย Ctrl+C จากนั้นเตรียมโฟลเดอร์ที่ใช้แล้วทิ้งได้

รันใน Terminal B:

ทดสอบ: พิมพ์ hello. แล้วกด Enter การตอบกลับหนึ่งประโยคจะยืนยันว่าเส้นทางคำขอพื้นฐานทำงานได้

การตั้งค่าบน Windows

ใช้หน้าต่าง PowerShell สองหน้าต่างแยกจากกัน PowerShell A จะเก็บคีย์ Kimi ของเซสชันปัจจุบันและรัน router PowerShell B จะใช้ทดสอบ localhost แก้ไขคอนฟิก และเริ่ม Codex ตัวแปรระดับผู้ใช้ (User variable) แบบถาวรรองรับการใช้งานในหน้าต่างอื่นในอนาคต ส่วนการกำหนดค่าระดับเซสชันปัจจุบันจะทำให้คีย์พร้อมใช้งานได้ทันทีใน PowerShell A

ขั้นตอนที่ 1: เปิด PowerShell A แล้วตรวจสอบ Node.js และ npm

ตำแหน่ง: กดปุ่ม Windows พิมพ์ PowerShell แล้วเปิด Windows PowerShell เรียกหน้าต่างนี้ว่า PowerShell A

รัน:

ผลลัพธ์ที่ควรได้: ทั้งสองคำสั่งจะแสดงเวอร์ชัน ค่าอย่าง v22.x.x และ 10.x.x เป็นเพียงตัวอย่าง ไม่ใช่ข้อกำหนดขั้นต่ำ

หากคำสั่งไม่ถูกจดจำ: เปิดเบราว์เซอร์แล้วไปที่ https://nodejs.org/en/download ดาวน์โหลดไฟล์ .msi สำหรับ Windows รุ่น LTS เปิด Downloads ใน File Explorer ดับเบิลคลิกตัวติดตั้ง ยอมรับค่าเริ่มต้น และตรวจสอบว่าตัวติดตั้งยังคงเลือกตัวเลือกที่เพิ่ม Node.js ลงใน PATH ไว้ ปิดหน้าต่าง PowerShell ทั้งหมด เปิด PowerShell A ใหม่ แล้วรันทั้งสองคำสั่งอีกครั้ง

ขั้นตอนที่ 2: สร้างคีย์ Kimi API

เปิด แพลตฟอร์ม Kimi API สร้างคีย์ API จากคอนโซล จากนั้นเก็บไว้ในโปรแกรมจัดการรหัสผ่านหรือตัวจัดการข้อมูลลับ หากคอนโซลของคุณแสดงคีย์แบบเต็มเพียงครั้งเดียว ให้คัดลอกไว้ก่อนออกจากหน้านี้

ขั้นตอนที่ 3: ตั้งค่าตัวแปรแบบถาวรและตัวแปรสำหรับเซสชันปัจจุบันใน PowerShell A

ตำแหน่ง: กลับไปที่ PowerShell A

รัน:

แทนที่เฉพาะ YOUR_KIMI_API_KEY ในทั้งสองบรรทัดด้วยคีย์ Kimi ตัวเดียวกัน ให้คง MOONSHOT_API_KEY, User, เครื่องหมายคำพูด และเครื่องหมายวรรคตอนไว้เหมือนเดิม บรรทัดแรกเก็บค่าไว้สำหรับกระบวนการในอนาคต ส่วนบรรทัดที่สองทำให้ค่านั้นใช้งานได้ทันทีใน PowerShell A

ผลลัพธ์ที่ควรได้: ทั้งสองคำสั่งไม่แสดงผลลัพธ์ใด ๆ ให้ตรวจสอบว่ามีค่าอยู่จริงโดยไม่แสดงคีย์ออกมา:

PowerShell ควรแสดงผลเป็น True

หากแสดงผลเป็น False: ให้รันคำสั่งกำหนดค่าสำหรับเซสชันปัจจุบันใหม่โดยใช้เครื่องหมายคำพูดตรง หากการเขียนค่าระดับ User ถูกบล็อกโดยนโยบาย ให้ใช้ค่าของเซสชันปัจจุบันสำหรับการฝึกปฏิบัตินี้ต่อไป และสอบถามผู้ดูแลระบบว่าควรจัดเก็บตัวแปรสภาพแวดล้อมระดับผู้ใช้อย่างไร เพิกถอนคีย์ใด ๆ ที่ถูกเปิดเผยในบันทึกหรือข้อความที่แชร์

ขั้นตอนที่ 4: ทดสอบ Kimi โดยตรงจาก PowerShell A

เอกสารอ้างอิง API อาจแสดง POST URL แต่ห้ามพิมพ์ POST https://... เพียงอย่างเดียวลงใน PowerShell ให้ใช้ Invoke-RestMethod -Method Post ตามที่แสดงไว้ที่นี่

ตำแหน่ง: อยู่ที่ PowerShell A ต่อไป ซึ่ง $env:MOONSHOT_API_KEY ถูกตั้งค่าไว้แล้ว

รัน:

อย่าแทนที่ endpoint, model หรือชื่อตัวแปร PowerShell จะอ่านคีย์จาก $env:MOONSHOT_API_KEY

ผลลัพธ์ที่ควรได้: บรรทัดสุดท้ายจะแสดงคำทักทายหนึ่งประโยคจาก choices[0].message.content

หากได้รับ 401: ตรวจสอบว่าคีย์มาจากคอนโซลส่วนกลาง .ai เพิกถอนและสร้างใหม่หากจำเป็น รันคำสั่งกำหนดค่าทั้งสองรายการในขั้นตอนที่ 3 ใหม่แล้วลองอีกครั้ง หากโมเดลถูกปฏิเสธ ตรวจสอบว่า ID ตรงกับ kimi-k2.7-code ทุกตัวอักษร และตรวจสอบสิทธิ์การเข้าถึงโมเดลในคอนโซล Kimi

ขั้นตอนที่ 5: เปิด PowerShell B และเริ่มตัว router ใน PowerShell A

ตำแหน่ง: กดปุ่ม Windows อีกครั้ง พิมพ์ PowerShell แล้วเปิดหน้าต่าง Windows PowerShell อีกบานหนึ่ง เรียกหน้าต่างนี้ว่า PowerShell B จากนั้นกลับไปที่ PowerShell A เพื่อรันคำสั่ง router

รันใน PowerShell A:

ให้คง $env:MOONSHOT_API_KEY ไว้เหมือนเดิม อย่าวางคีย์ลงในคำสั่งโดยตรง

ข้อความแจ้งเตือนที่อาจเกิดขึ้นในการรันครั้งแรก: npx อาจแสดงข้อความ Need to install ... Ok to proceed? (y) ตรวจสอบแพ็กเกจและแหล่งที่มาจากบุคคลที่สาม พิมพ์ y แล้วกด Enter เฉพาะเมื่อคุณยอมรับเท่านั้น ทั้งนี้ไม่มีการรับรองว่าได้ทดสอบกับเวอร์ชันแพ็กเกจที่เจาะจงใด ๆ

ผลลัพธ์ที่ควรได้: โปรเซสจะยังคงเปิดอยู่และรายงานว่ากำลังรับฟังที่ 127.0.0.1:8787 ให้เปิด PowerShell A ค้างไว้

หากไม่สำเร็จ: รันคำสั่ง node --version และ npm --version ใน PowerShell A หากคำสั่งใดคำสั่งหนึ่งล้มเหลว ให้ทำขั้นตอนที่ 1 ซ้ำ หากพอร์ต 8787 ถูกใช้งานอยู่ ให้หยุด router อีกตัวด้วย Ctrl+C ในหน้าต่างของมัน แล้วรันคำสั่งนี้ใหม่

ขั้นตอนที่ 6: ทดสอบ localhost จาก PowerShell B

ตำแหน่ง: คลิก PowerShell B อย่าหยุด router ใน PowerShell A

รัน:

อย่าเปลี่ยน localhost URL เพราะมันชี้ไปยัง router ใน PowerShell A

ผลลัพธ์ที่คาดหวัง: PowerShell จะแสดงอ็อบเจ็กต์ที่คล้ายกับ Responses หรือเอาต์พุตที่มีข้อความทักทายอยู่ ฟิลด์ที่แน่ชัดอาจแตกต่างกันไปตามรุ่นของ router

หากการเชื่อมต่อถูกปฏิเสธ: ให้ดูที่ PowerShell A และรันคำสั่งใน Step 5 ใหม่หาก router หยุดทำงาน หาก PowerShell A แสดงข้อผิดพลาดการยืนยันตัวตนต้นทาง (upstream authentication error) ให้กด Ctrl+C รีเซ็ต $env:MOONSHOT_API_KEY แล้วเริ่ม router ใหม่ อย่าเพิ่ม local authorization header สำหรับการเริ่มต้นแบบด่วนของ @codeproxy/cli ตามค่าเริ่มต้น

Step 7: สร้างและแก้ไขไฟล์คอนฟิก Codex บน Windows

ตำแหน่ง: ใช้ PowerShell B ต่อไป การตั้งค่า provider ต้องอยู่ที่ $HOME\.codex\config.toml ไม่ใช่ในโฟลเดอร์โปรเจกต์

รัน:

คำสั่งเหล่านี้จะสร้างไดเรกทอรีผู้ใช้ สำรองไฟล์คอนฟิกเดิมที่มีอยู่ สร้างไฟล์ใหม่ในกรณีที่ยังไม่มี และเปิดไฟล์นั้นด้วย Notepad

ใน Notepad: วางคอนฟิกเริ่มต้นแบบเต็มนี้ โดยลบคีย์ model หรือ provider ที่ซ้ำกันออกหากไฟล์มีอยู่แล้ว:

อย่าเปลี่ยน kimi-proxy, localhost URL หรือ responses กด Ctrl+S แล้วปิด Notepad

ยืนยันชื่อไฟล์: รัน:

ผลลัพธ์ที่คาดหวัง: Name จะต้องเป็น config.toml เท่านั้น ไม่ใช่ config.toml.txt และ Length ต้องมากกว่าศูนย์

หาก Notepad เพิ่ม .txt ต่อท้าย: ใน Notepad ให้เลือก File → Save As ตั้งค่า Save as type เป็น All Files ใส่ชื่อ config.toml แล้วบันทึกไว้ที่ $HOME\.codex จากนั้นรัน Get-Item อีกครั้ง หาก Codex ไม่รับค่า provider ให้ตรวจสอบว่าคุณแก้ไขไฟล์ที่ระดับผู้ใช้จริง และลบคีย์ TOML ที่ซ้ำกันออก

Step 8: รีสตาร์ท Codex และรันการทดสอบฉบับเต็มบน Windows

ตำแหน่ง: ปล่อยให้ PowerShell A และ router ทำงานต่อไป ปิดแอปหรือเซสชัน Codex ทั้งหมดให้สนิท ปิด PowerShell B แล้วเปิดใหม่ด้วยการกดปุ่ม Windows → พิมพ์ PowerShell → เปิด Windows PowerShell และสร้างโฟลเดอร์ชั่วคราวขึ้นมา

รันใน PowerShell B ที่เปิดใหม่:

ทดสอบ: พิมพ์ hello. แล้วกด Enter คำตอบหนึ่งประโยคจะยืนยันว่าเส้นทางคำขอพื้นฐานทำงานได้

การใช้ Kimi ในแอป Codex เดสก์ท็อป

ก่อนดำเนินการต่อ ให้ทำ Step 1–7 ของการตั้งค่าบน macOS หรือ Windows สำหรับ local router และ config.toml ให้เสร็จก่อน คุณไม่จำเป็นต้องทำการทดสอบ CLI ให้เสร็จก่อน แต่ router ต้องทำงานอยู่ตลอดเวลาที่คุณใช้ Kimi ในแอปเดสก์ท็อป

Step 1: ปล่อยให้ local router ทำงานต่อไป

เปิด Terminal A หรือ PowerShell A ค้างไว้โดยให้ @codeproxy/cli ทำงานอยู่ที่:

Step 2: ยืนยันการตั้งค่า provider

เปิดไฟล์คอนฟิก Codex ระดับผู้ใช้

บน macOS ให้รัน:

บน Windows ให้รัน:

ยืนยันว่าไฟล์มีการตั้งค่าระดับบนสุดเหล่านี้อยู่:

Step 3: รีสตาร์ทแอปเดสก์ท็อปให้สนิท

บน macOS ให้กด Command+Q เพื่อปิดแอปเดสก์ท็อปให้สนิท การปิดแค่หน้าต่างไม่เพียงพอ

บน Windows ให้ปิดหน้าต่างแอปเดสก์ท็อปทั้งหมด และตรวจสอบว่าแอปไม่ได้ทำงานอยู่ใน system tray แล้ว

เปิดแอปเดสก์ท็อปอีกครั้งแล้วเปิดโฟลเดอร์โปรเจกต์

ขั้นตอนที่ 4: คงค่าโมเดล Custom ไว้

ตัวเลือกโมเดลในแอปเดสก์ท็อปอาจแสดง Custom แทนที่จะเป็น Kimi K2.7 Code ซึ่งเป็นเรื่องปกติ

ผู้ให้บริการที่กำหนดเองซึ่งกำหนดไว้ใน config.toml มักไม่แสดงชื่อในรายการโมเดลของแอปเดสก์ท็อปเสมอไป อย่าเลือกโมเดล OpenAI เช่น GPT-5.6 Sol เมื่อต้องการใช้ผู้ให้บริการ Kimi ให้คงเลือก Custom ไว้

คุณอาจเห็นคำเตือนนี้ด้วย:

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

ขั้นตอนที่ 5: ตรวจสอบเส้นทางคำขอของเดสก์ท็อป

ส่งพรอมป์นี้ในแอปเดสก์ท็อป:

จับตาดู Terminal A หรือ PowerShell A ขณะที่แอปเดสก์ท็อปตอบกลับ หากหน้าต่าง Terminal A ได้รับคำขอใหม่ และแอปเดสก์ท็อปส่งคำตอบกลับมา แสดงว่าแอปเดสก์ท็อปกำลังใช้เส้นทาง Kimi ในเครื่อง

การแก้ปัญหาข้อผิดพลาดในการเชื่อมต่อที่พบบ่อย

zsh: command not found: POST

POST URL เป็นสัญลักษณ์ในเอกสาร API ไม่ใช่คำสั่งจริง บน macOS ให้คัดลอกตัวอย่าง curl ทั้งหมด บน Windows ให้คัดลอกตัวอย่าง Invoke-RestMethod -Method Post ทั้งหมด

การเชื่อมต่อถูกปฏิเสธที่พอร์ต 8787

กลับไปที่ Terminal A หรือ PowerShell A หากไม่มีโพรเซสเราเตอร์ทำงานอยู่ ให้ตั้งค่าตัวแปร Kimi สำหรับเซสชันปัจจุบันแล้วรันคำสั่ง npx @codeproxy/cli ... ตามเอกสารอีกครั้ง คงหน้าต่างนั้นเปิดไว้ แล้วทำการทดสอบ localhost ซ้ำในหน้าต่าง B

การตอบกลับด้วยรหัส 401

อ่านหน้าต่างเราเตอร์เพื่อระบุจุดที่ล้มเหลว หาก 401 มาจากฝั่งต้นทาง Kimi มักหมายความว่า MOONSHOT_API_KEY ไม่ถูกต้อง ถูกเพิกถอนไปแล้ว หรือมาจากบัญชีในภูมิภาคที่ผิด ให้เพิกถอนคีย์ในคอนโซล .ai ส่วนกลาง สร้างคีย์ใหม่ ตั้งค่าตัวแปรของเซสชันปัจจุบันใหม่ แล้วรีสตาร์ทเราเตอร์ เส้นทางเราเตอร์เริ่มต้นไม่มีการตรวจสอบ bearer token ขาเข้า หาก 401 เกิดขึ้นในเครื่องกับอะแดปเตอร์อื่น อาจหมายความว่า CODEX_KIMI_PROXY_KEY ซึ่งเป็นตัวเลือกเสริมนั้นขาดหายหรือไม่ถูกต้อง

ข้อผิดพลาดเกี่ยวกับพารามิเตอร์หรือเครื่องมือที่ไม่รองรับ

เราเตอร์อาจกำลังส่งฟิลด์ที่ Kimi ไม่รองรับ ฟิลด์เกี่ยวกับ sampling ควรปล่อยว่างไว้ หากมีการส่งค่าออกมา ต้องใช้ค่าคงที่ที่รองรับเท่านั้น ตรวจสอบว่า tool_choice เป็น auto หรือ none และอะแดปเตอร์คงค่า reasoning_content ไว้ หากการทดสอบแบบหลายขั้นตอนยังล้มเหลวอยู่ ให้หยุดใช้เวอร์ชันเราเตอร์นั้นแล้วเลือกหรืออัปเดตเป็นเวอร์ชันที่รองรับ Kimi อย่างชัดเจน

Codex ไม่นำผู้ให้บริการไปใช้

เปิดไฟล์ผู้ใช้โดยตรง: รันคำสั่ง open -e "$HOME/.codex/config.toml" บน macOS หรือ notepad "$HOME\.codex\config.toml" บน Windows ตรวจสอบว่ามี model_provider = "kimi-proxy" ระดับบนสุดเพียงหนึ่งเดียว มีตารางผู้ให้บริการหนึ่งชุด มี base URL แบบ localhost และมี wire_api = "responses" บันทึกไฟล์ ปิด Codex ให้หมด แล้วเปิดใหม่อีกครั้ง อย่ากำหนดค่าเลือกผู้ให้บริการไว้เฉพาะใน .codex/config.toml ระดับโปรเจกต์เท่านั้น

npx ไม่สามารถเริ่มเราเตอร์ได้

รันคำสั่ง node --version และ npm --version ในหน้าต่างเราเตอร์ A หากคำสั่งใดคำสั่งหนึ่งล้มเหลว ให้ติดตั้งแพ็กเกจ Node.js LTS จาก nodejs.org/download ปิดแล้วเปิดเทอร์มินัลใหม่ แล้วลองอีกครั้ง หาก npx ขออนุญาตดาวน์โหลดแพ็กเกจ ให้ตรวจสอบแพ็กเกจและแหล่งที่มาก่อนกด y

ประโยชน์ของการใช้ Kimi API

การใช้ Kimi ในเวิร์กโฟลว์ API ของ Cursor สามารถช่วยพัฒนางานเขียนโค้ด การดีบัก และการพัฒนาต่าง ๆ ได้ ความสามารถขั้นสูงของมันช่วยให้สร้างคำตอบที่แม่นยำ รับมือกับคำสั่งที่ซับซ้อน และช่วยแก้ปัญหาได้เร็วขึ้น ต่อไปนี้คือประโยชน์หลักของการใช้ Kimi ในเวิร์กโฟลว์ Cursor เพื่อเพิ่มประสิทธิภาพการทำงาน

• ความเข้าใจโค้ดในบริบทยาว

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

• การวิเคราะห์เอกสารและรีโพซิทอรีที่ดีขึ้น

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

• การพัฒนา AI ที่คุ้มค่า

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

• ค้นหาข้อมูลได้เร็วขึ้น

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

• ระบบอัตโนมัติในเวิร์กโฟลว์ที่ดีขึ้น

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

Codex ช่วยปรับปรุงเวิร์กโฟลว์การพัฒนาอย่างไร

เวิร์กโฟลว์ Codex CLI API ที่ตั้งค่าไว้จะเชื่อมโยงการตรวจสอบ repository การแก้ไข คำสั่ง และการรีวิวไว้ในบริบทเดียวกัน Codex สามารถสร้างโครงไฟล์ อธิบายโมดูลที่ไม่คุ้นเคย จำลองข้อผิดพลาดที่เกิดขึ้นซ้ำ เสนอชุดทดสอบ และรันการตรวจสอบที่ได้รับอนุมัติ การรองรับผู้ให้บริการภายนอกช่วยเพิ่มตัวเลือกโมเดล แต่ไม่ได้ลดความรับผิดชอบในการรีวิว

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

สรุป

การใช้งาน Codex API อย่างน่าเชื่อถือมาจากการทดสอบแต่ละชั้นตามลำดับ ได้แก่ ยืนยันตัวตน Codex เรียกใช้ Kimi โดยตรง เริ่มและทดสอบ localhost บันทึกการตั้งค่าผู้ให้บริการระดับผู้ใช้ รัน prompt แบบอ่านอย่างเดียว และทำงานที่เกี่ยวข้องกับไฟล์และเครื่องมือให้เสร็จสมบูรณ์ เก็บคีย์ Kimi จริงไว้กับ router อย่าให้ข้อมูลลับหลุดเข้าไปในไฟล์ที่ใช้ร่วมกัน และหยุด router เมื่อทำงานเสร็จแล้ว