ในงาน DevDay เมื่อวันที่ 29 กันยายน OpenAI ระบุว่านักพัฒนา “สามารถรัน Codex ได้ทุกที่ที่ต้องการ ไม่ว่าจะเป็นบนคอมพิวเตอร์ สั่งการระยะไกลจากโทรศัพท์ หรือบนคลาวด์จากอุปกรณ์ใดก็ได้” แต่ประโยคในสรุปงาน DevDay ที่สำคัญต่อการทำงานเป็นทีมมากที่สุดคือประโยคถัดมา นั่นคือ สภาพแวดล้อมสำหรับการพัฒนาที่นำกลับมาใช้ซ้ำได้ “ช่วยให้เริ่มงานได้อย่างรวดเร็ว และทำให้ทีมของคุณมีสภาพแวดล้อมการทำงานร่วมกันที่มีการตั้งค่าและสิทธิ์ที่ได้รับการอนุมัติเรียบร้อยแล้ว” โดย Codex cloud เปิดให้ใช้งานบนแพ็กเกจ Plus, Pro, Business, Healthcare, Education และ Enterprise
สำหรับนักพัฒนาคนเดียว เรื่องนี้คงให้คำตอบที่ชัดเจนแล้ว แต่สำหรับทีมที่รัน Claude Code บนเวิร์กสเตชัน รัน Codex บนบิลด์เซิร์ฟเวอร์ และรัน Gemini บนแล็ปท็อปของใครสักคนอยู่แล้ว นี่คือการเพิ่มพื้นที่ทำงานเข้ามาอีกแห่งหนึ่ง ตอนนี้งานสามารถเริ่มต้นได้ทั้งบนคลาวด์ของ OpenAI บนฮาร์ดแวร์ของคุณเอง และจากโทรศัพท์มือถือระหว่างอยู่บนรถไฟ ซึ่งแต่ละแห่งต่างก็มีรายการบันทึกสิ่งที่รันแยกกันของตัวเอง การจะดูว่าเอเจนต์ตัวไหนกำลังทำงานอะไรอยู่ งานไหนเสร็จแล้ว และงานไหนกำลังรอคนมารีวิว จึงมีอีกหนึ่งที่ที่ต้องคอยตามเช็ก ดังนั้น คำถามที่เป็นประโยชน์จึงไม่ใช่ “คลาวด์หรือโลคอล?” แต่เป็นงานประเภทไหนควรทำที่ไหน และบันทึกประวัติของงานนั้นควรอยู่ที่ใด
สรุปใจความสำคัญ
Codex cloud เหมาะอย่างยิ่งสำหรับงานของ Codex ที่ต้องการความรวดเร็วในการเริ่มต้น ต้องการให้ทำงานต่อไปได้แม้จะพับหน้าจอแล็ปท็อป หรือสั่งเริ่มงานได้จากโทรศัพท์ และเหมาะสำหรับทีมที่ต้องการสภาพแวดล้อมมาตรฐานเดียวที่ผ่านการอนุมัติ แทนที่จะต้องให้ทุกคนมานั่งเตรียมเครื่องโฮสต์ของตัวเอง ส่วนคอมพิวเตอร์ของคุณเอง (Your own Computers) จะตอบโจทย์ได้ดีกว่าเมื่องานนั้นจำเป็นต้องใช้ Claude Code หรือรันไทม์อื่นที่ไม่ใช่ Codex, ต้องใช้ฮาร์ดแวร์ที่เกินกว่า VM เริ่มต้นของแพ็กเกจ หรือต้องใช้ฟีเจอร์ที่เอกสารสภาพแวดล้อมคลาวด์ของ OpenAI ระบุว่ายังไม่รองรับในปัจจุบัน เช่น คลังโค้ดบน GitLab, การสั่งงานเบราว์เซอร์ (browser use) หรือบริการส่วนตัวภายในองค์กรที่ต้องเข้าถึงผ่าน SSH หรือโปรโตคอลฐานข้อมูลโดยตรง อย่างไรก็ตาม ไม่ว่าจะเลือกทางไหน สิ่งที่ระบบไม่ได้กำหนดให้คือใครเป็นผู้มอบหมายงานหรือใครเป็นผู้ตรวจรับงาน ซึ่งเรื่องนั้นยังคงเป็นหน้าที่ของทีมผ่านระบบ Task
สิ่งที่คุณจะได้รับจากสภาพแวดล้อม Codex cloud
สภาพแวดล้อมบนคลาวด์ ตามเอกสารของ OpenAI คือ “สภาพแวดล้อมการทำงานที่นำกลับมาใช้ซ้ำได้สำหรับงานต่างๆ ซึ่งประกอบด้วยคลังโค้ด, แพ็กเกจที่ต้องพึ่งพา (dependencies), เครื่องมือ และการตั้งค่าสิทธิ์การเข้าถึง” คุณเพียงเลือกคลังโค้ด GitHub จากนั้น Codex จะตรวจสอบโค้ด ติดตั้ง dependencies และเครื่องมือ ทดสอบเวิร์กโฟลว์ และจะสอบถามข้อมูลเพิ่มเติมหากไม่สามารถอนุมานเองได้ เมื่อคุณตรวจสอบรายงานการตั้งค่าและเผยแพร่แล้ว ทุกงานใหม่จะเริ่มต้นจากระบบไฟล์ที่เผยแพร่นั้นในพื้นที่ทำงานที่แยกเป็นอิสระของตัวเอง และงานต่างๆ “สามารถทำงานต่อไปได้แม้คอมพิวเตอร์ของคุณจะอยู่ในโหมดสลีป”
โมเดลด้านความปลอดภัยและการเข้าถึงได้รับการออกแบบมาอย่างรอบคอบกว่าการเขียนสคริปต์ตั้งค่าแล้วแปะโทเคนลงไป ค่าตัวแปรสภาพแวดล้อม (Environment variables) จะถูกส่งตรงไปยังโปรแกรม ส่วนข้อมูลลับด้านเครือข่าย (Network secrets) จะไม่ถูกส่งไปถึงโพรเซสเลย โดยโปรแกรมจะได้รับเพียงค่าตัวแทน (placeholder) และจะมีพร็อกซีคอยสลับเป็นข้อมูลรับรองตัวจริงให้เฉพาะปลายทาง HTTPS ที่ได้รับอนุญาตเท่านั้น การเข้าถึงอินเทอร์เน็ตเป็นค่าที่คุณสามารถเปิดใช้งานแล้วจำกัดขอบเขตได้ ไม่ว่าจะใช้ค่าพรีเซ็ตสำหรับตัวจัดการแพ็กเกจหรือกำหนดรายการโดเมนเอง บริการส่วนตัวสามารถเข้าถึงได้ผ่าน VPN โดยปัจจุบันรองรับ Tailscale และพื้นที่ทำงานระดับ Enterprise สามารถขอใช้การเชื่อมต่อ OIDC สำหรับข้อมูลรับรองคลาวด์แบบมีอายุสั้นได้
การเริ่มต้นทำงานมีความยืดหยุ่นไม่แพ้กัน ภาพรวมของ Codex Cloud ระบุว่ารองรับทั้งบนเว็บ, แอปเดสก์ท็อป, มือถือ และ Codex CLI นอกจากนี้ พื้นที่ทำงานระดับ Enterprise ที่เปิดใช้งาน Cloud delegation ยังสามารถเริ่มงานได้ผ่าน @ChatGPT ใน Slack หรือ Microsoft Teams สภาพแวดล้อมระดับ Enterprise ยังสามารถแชร์ให้กับทั้งพื้นที่ทำงานได้ เพื่อให้เพื่อนร่วมทีมใหม่เริ่มต้นจากค่าที่ได้รับอนุมัติทันทีโดยไม่ต้องตั้งค่าใหม่ตั้งแต่ต้น สำหรับงานของ Codex แล้ว สิ่งนี้ช่วยขจัดปัญหาความคลาดเคลื่อนของการตั้งค่าระบบ (setup drift) ได้อย่างแท้จริง
กลุ่มผลิตภัณฑ์ของ OpenAI เองก็มองว่าการเลือกพื้นที่รันงานขึ้นอยู่กับลักษณะของแต่ละเวิร์กโหลด ไม่ใช่การเลือกคำตอบเดียวสำหรับทุกอย่าง Dots แต่ละตัวจะได้คอมพิวเตอร์บนคลาวด์ของตัวเอง และ Agents API ก็รองรับทั้งสภาพแวดล้อมที่โฮสต์โดย OpenAI หรือโฮสต์ด้วยตัวเอง ดังที่เราเคยกล่าวถึงในบทความใครเป็นผู้รันเอเจนต์ และในตอนนี้ Codex ก็สามารถรันได้จากทั้งสองที่เช่นเดียวกัน
สิ่งที่คุณจะได้รับจาก Sharkly Computer
Computer คืออุปกรณ์ เซิร์ฟเวอร์ หรือคอนเทนเนอร์ที่เชื่อมต่ออยู่ ซึ่งเอเจนต์สามารถเข้าไปรันงานได้ ตามคำนิยามในเอกสาร Sharkly Computers ระบบนี้ “ทำหน้าที่จัดเตรียมระบบปฏิบัติการ, ไฟล์, ข้อมูลรับรอง, การเข้าถึงเครือข่าย และเครื่องมือต่างๆ ที่เอเจนต์จำเป็นต้องใช้” โดยมีเซอร์วิสขนาดเล็กในเครื่องทำหน้าที่ลงทะเบียน ตรวจหารันไทม์ที่ติดตั้งอยู่ในเครื่อง รับคิวงาน และสตรีมความคืบหน้ากลับมา เซอร์วิสนี้จะเปิดการเชื่อมต่อไปยังภายนอก ดังนั้นการตั้งค่าทั่วไปจึงไม่จำเป็นต้องเปิดพอร์ตขาเข้า (inbound port)
มีคุณสมบัติสามประการที่สำคัญสำหรับการเปรียบเทียบนี้ ประการแรก Computer เครื่องเดียวสามารถรองรับได้หลายรันไทม์ โดย Sharkly รองรับทั้ง Claude Code, Codex, Gemini, OpenCode, OpenClaw และ Hermes อีกทั้งยังมี ACP Runtime แบบกำหนดเองสำหรับเครื่องมือที่เซอร์วิสในเครื่องตรวจไม่พบ ทำให้ Computer เพียงเครื่องเดียวสามารถให้บริการเอเจนต์ได้หลายตัวพร้อมกัน ประการที่สอง มีการแยกสภาพแวดล้อมเป็นราย Task โดยในโหมด Temporary แต่ละ Task จะได้ไดเรกทอรีที่แยกเป็นสัดส่วน และงานที่ผูกกับคลังโค้ดสามารถใช้ worktree ใหม่ได้ ซึ่งเป็นวิธีที่เอเจนต์แบบขนานใช้หลีกเลี่ยงปัญหา merge conflict ส่วนในโหมด Specified การรันงานจะนำไดเรกทอรีในเครื่องที่กำหนดค่าไว้กลับมาใช้ซ้ำ พร้อมด้วย dependencies, แคช และบริการในเครื่องที่พร้อมใช้งานอยู่แล้ว โดยจะรันทีละงาน ประการที่สาม ข้อมูลรับรองเป็นของคุณอย่างสมบูรณ์ เอเจนต์จะเก็บตัวแปรสภาพแวดล้อมทั้งแบบธรรมดาและแบบความลับ โดยการรันแต่ละครั้งจะได้รับเฉพาะสภาพแวดล้อมและข้อมูลรับรองที่ได้รับอนุญาตเท่านั้น และ Computer ที่ตั้งค่าการมองเห็นเป็นแบบ Personal จะเปิดให้เฉพาะเจ้าของเข้าใช้งานได้เท่านั้น
ข้อแลกเปลี่ยนตามตรงคือคุณต้องดูแลเครื่องโฮสต์เอง หาก Computer ออฟไลน์ไป งานใหม่ที่เข้ามาจะต้องรอจนกว่าเครื่องจะเชื่อมต่อใหม่อีกครั้ง แอปเดสก์ท็อปสามารถป้องกันไม่ให้เครื่องเข้าสู่โหมดสลีปได้ และบน macOS ก็สามารถทำงานต่อเนื่องขณะพับหน้าจอได้หากระบบอนุญาต แต่งานที่ต้องรันต่อเนื่องเป็นเวลานานโดยไม่มีคนเฝ้าควรอยู่บนเซิร์ฟเวอร์ที่คุณควบคุมเอง ดังที่เราเคยนำเสนอไปในบทความการรันเอเจนต์เขียนโค้ดจากระยะไกล ส่วนเรื่องค่าใช้จ่ายก็ยังคงแยกส่วนชัดเจนเช่นเดิม Computer และรันไทม์ต่างๆ จะไม่นับเป็นที่นั่ง (seats) ในแพ็กเกจของ Sharkly อีกทั้ง Sharkly ไม่ได้ขายโทเค็น และ Codex Agent จะใช้แพ็กเกจ ChatGPT หรือ API key ตามที่ Codex CLI ของเครื่องนั้นเข้าสู่ระบบไว้
Codex cloud หรือ Computer ของคุณเอง: ตารางช่วยตัดสินใจ
ข้อมูลของ Codex cloud ในตารางด้านล่างนี้อ้างอิงจากเอกสารสภาพแวดล้อมคลาวด์ของ OpenAI ณ วันที่ 30 กันยายน ส่วนข้อมูลของ Computer มาจากเอกสารของ Sharkly
| ความต้องการของงาน | ตัวเลือกที่เหมาะสมกว่า | เหตุผล |
|---|---|---|
| การแก้ไขงานด่วนที่เริ่มจากโทรศัพท์ โดยพับหน้าจอแล็ปท็อปไว้ | Codex cloud | สามารถเริ่มงานได้จากมือถือ และระบบยังคงทำงานต่อได้แม้คอมพิวเตอร์ของคุณจะเข้าสู่โหมดสลีป |
| สภาพแวดล้อมมาตรฐานเดียวกันที่ผ่านการอนุมัติสำหรับทุกคนในทีม | Codex cloud (แชร์ในพื้นที่ทำงาน Enterprise) | ใช้สภาพแวดล้อมที่เผยแพร่เพียงชุดเดียว แต่แต่ละงานยังคงได้พื้นที่ทำงานแยกเป็นสัดส่วนของตัวเอง |
| ไม่อยากดูแลเครื่องโฮสต์เอง | Codex cloud | Codex จะเป็นผู้เตรียม ทดสอบ และรันสภาพแวดล้อมให้ทั้งหมด |
| ต้องการใช้ Claude Code, Gemini, OpenCode หรือรันไทม์อื่นที่ไม่ใช่ของ OpenAI | Computer ของคุณเอง | Computer สามารถโฮสต์หลายรันไทม์ควบคู่กันได้ |
| ต้องมีการใช้งานคอมพิวเตอร์หรือเบราว์เซอร์ (computer หรือ browser use) ภายในงาน | Computer ของคุณเอง | เอกสารระบุว่าสภาพแวดล้อมบนคลาวด์ยังไม่รองรับการใช้งานคอมพิวเตอร์และเบราว์เซอร์ |
| คลังโค้ดอยู่บน GitLab หรือ GitHub Enterprise Server | Computer ของคุณเอง | ระบุไว้ว่าเป็นข้อจำกัดของระบบคลาวด์ในปัจจุบันเช่นกัน |
| ต้องใช้ SSH, โปรโตคอลฐานข้อมูลโดยตรง หรือ private DNS | Computer ที่อยู่ภายในเครือข่ายนั้น | VPN ของคลาวด์รองรับเฉพาะ HTTP และ HTTPS ผ่าน IPv4 โดยไม่รองรับ private DNS, SSH หรือโปรโตคอลฐานข้อมูลโดยตรง |
| ต้องการฮาร์ดแวร์เฉพาะ หรือสเปกที่สูงกว่า VM เริ่มต้น | Computer ของคุณเอง หรือยื่นคำขอระดับ Enterprise | ค่าเริ่มต้นคือ 2 vCPU, แรม 8 GiB, ดิสก์ 8 GiB สำหรับแพ็กเกจ Plus และ 4 vCPU, 16 GiB, 32 GiB สำหรับ Pro, Business และ Enterprise หากต้องการสเปกที่สูงกว่าหรือปรับแต่งเองต้องติดต่อทีมดูแลลูกค้าของ OpenAI |
| คลังโค้ดขนาดใหญ่มากที่มีสถานะไฟล์ในเครื่อง (local state) ซึ่งใช้เวลาเตรียมนาน | Computer ในเครื่อง โหมด Specified | นำไดเรกทอรีเดิมที่มีอยู่แล้วกลับมาใช้ซ้ำได้ทันที โดยไม่ต้องเสียเวลาเตรียมสำเนาใหม่ |
| สกิลที่มีอยู่เฉพาะบนแล็ปท็อปของคุณ | Computer ของคุณเอง | สกิลส่วนตัวในเครื่องจะไม่ถูกซิงค์ไปยังสภาพแวดล้อมบนคลาวด์ แต่จะซิงค์เฉพาะสกิลในระดับคลังโค้ดเท่านั้น |
ให้มองตารางนี้เป็นคู่เกณฑ์ในการตัดสินใจ: เลือกใช้ Codex cloud เมื่องานนั้นเป็นงานสำหรับ Codex, dependencies ทั้งหมดเป็นแบบสาธารณะหรือเข้าถึงได้ผ่าน HTTPS ที่ได้รับอนุญาต และผู้สั่งเริ่มงานอาจไม่ได้อยู่ที่โต๊ะทำงาน และเลือกใช้ Computer ของคุณเอง เมื่องานนั้นจำเป็นต้องใช้รันไทม์ ฮาร์ดแวร์ หรือเครือข่ายที่คุณได้เจาะจงเลือกไว้ด้วยเหตุผลเฉพาะ
มีอยู่หนึ่งแถวที่เราตั้งใจละเว้นไว้ นั่นคือ “ข้อมูลที่ต้องไม่รั่วไหลออกนอกเครือข่ายของเรา” การรันบน Computer ของคุณเองจะช่วยรักษาคลังโค้ด แคช และข้อมูลลับให้อยู่บนฮาร์ดแวร์ที่คุณควบคุม แต่ไม่ได้ป้องกันไม่ให้พรอมต์ถูกส่งไปยังผู้ให้บริการโมเดล เพราะข้อมูลใดก็ตามที่รันไทม์ส่งไปยังตัวโมเดลก็ยังคงต้องส่งออกไปภายนอกอยู่ดี ซึ่ง OpenAI เองก็ระบุขอบเขตสำหรับผลิตภัณฑ์ของตนไว้เช่นเดียวกัน โดยเอกสาร Agents API ระบุว่า “การเลือกแซนด์บ็อกซ์แบบ self-hosted ไม่ได้ทำให้ Agents API เข้าเกณฑ์ ZDR (Zero Data Retention)” การเลือกพื้นที่รันงานเป็นตัวกำหนดว่าโค้ดและข้อมูลรับรองจะอยู่ที่ใด ส่วนนโยบายการเก็บรักษาข้อมูล (Retention) นั้นเป็นสัญญาข้อตกลงคนละส่วนกับผู้ให้บริการโมเดลของคุณ
การใช้งานแบบผสมผสานคือจุดที่บอร์ดบริหารงานแสดงคุณค่าที่แท้จริง
ทีมส่วนใหญ่จะเลือกใช้งานทั้งสองรูปแบบร่วมกัน งานแก้ไขด่วนของ Codex จะเริ่มจากโทรศัพท์เข้าสู่สภาพแวดล้อมบนคลาวด์ ส่วนงานไมเกรชันที่ต้องเข้าถึงฐานข้อมูล staging จะรันผ่านเอเจนต์บน Computer ภายในเครือข่าย ซึ่งเป็นการแบ่งงานที่สมเหตุสมผล แต่มันก็จะทำให้เกิดรายการบันทึกงานแยกกันเป็นสองแห่ง
Codex cloud ได้รับการออกแบบมาให้แยกงานออกจากกันอย่างชัดเจน โดยเอกสารระบุว่า การเข้าถึงสภาพแวดล้อมที่แชร์ร่วมกัน “ไม่ได้ให้สิทธิ์ในการเข้าถึงงานของผู้อื่น” ซึ่งถือเป็นค่าเริ่มต้นที่ถูกต้องในแง่ของความเป็นส่วนตัว แต่นั่นก็หมายความว่า มีเพียงสภาพแวดล้อมเท่านั้นที่แชร์กัน ส่วนตัวงานไม่ได้แชร์ด้วย ดังนั้น คำถามที่ว่า “ตอนนี้เอเจนต์ทั้งหมดของทีมกำลังทำอะไรอยู่?” ไม่ว่าจะบนคลาวด์หรือบน Computer จึงจำเป็นต้องหาคำตอบจากที่อื่น ให้เริ่มต้นด้วยการกำหนดกฎเกณฑ์การส่งต่องาน (routing rules) เอาไว้ก่อนดังนี้:
Where does this Task run?
1. Needs a non-Codex Runtime -> Agent on a Computer
2. Needs SSH, a database protocol, or private DNS -> Computer inside that network
3. Needs GitLab, GitHub Enterprise Server, or browser use -> Computer
4. Codex work, allowlisted HTTPS, started away from a desk -> Codex cloud
5. Someone must accept the result -> a Task with an Assignee and a reviewer, wherever it ran
กฎข้อที่ห้าคือหัวใจสำคัญที่ทำให้การจัดการงานแบบผสมผสานนี้ไม่หลุดการควบคุม ใน Sharkly ตัว Task คือศูนย์กลางของการบันทึกข้อมูล ทั้งความคืบหน้า บันทึกการทำงาน (log) อุปสรรคที่พบ และผลลัพธ์สุดท้ายจะถูกส่งกลับมาที่นี่ และงานที่กำลังรอการรีวิวจากมนุษย์จะถูกส่งตรงไปยัง Inbox ของผู้รับผิดชอบ ทั้ง Codex Agent และ Claude Code Agent ที่อยู่บน Computer เครื่องเดียวกันจะรายงานผลเข้ามายังบอร์ดเดียวกัน โดยแต่ละตัวจะทำตามโมเดลที่รันไทม์ของมันถูกกำหนดค่าไว้ สำหรับงานที่รันบน Codex cloud จุดเชื่อมโยงก็คือ pull request เพียงใส่ Task ID ไว้ในชื่อบรันช์หรือชื่อ PR แล้วระบบเชื่อมต่อ GitHub ของ Sharkly จะพยายามเชื่อมโยง PR นั้นกลับมายัง Task โดยอัตโนมัติ ทำให้ขั้นตอนการตรวจรับงานยังคงเกิดขึ้นในที่เดียวเสมอ นอกจากนี้ บทความของเราเรื่องเอเจนต์ที่รันงานนานเกินกว่าชั่วโมงทำงานของคุณ ก็ได้อธิบายถึงแง่มุมการรีวิวผลงานสำหรับการรันงานระยะยาวโดยไม่ต้องเฝ้าจอไว้แล้วเช่นกัน
เอเจนต์มีหน้าที่ค้นคว้า ดำเนินการ ทดสอบ และรายงานผล แต่มนุษย์คือผู้กำหนดทิศทาง มอบหมายอำนาจ และตรวจรับผลงาน ข้อตกลงนี้ไม่เคยเปลี่ยนไป ไม่ว่างานนั้นจะถูกรันขึ้นที่ใดก็ตาม
บทสรุปสำหรับการตั้งค่าของคุณ
Codex cloud คือคำตอบที่ดีสำหรับคำถามที่ว่า “ควรจะรัน Codex ไว้ที่ไหน?” แต่มันไม่ได้ถูกสร้างมาเพื่อตอบคำถามว่า “ตอนนี้เอเจนต์แต่ละตัวของเราในทุกรันไทม์กำลังทำอะไรอยู่ และใครเป็นผู้อนุมัติงานแล้วบ้าง?” จงเก็บ Computer ไว้สำหรับงานที่จำเป็นต้องใช้รันไทม์ ฮาร์ดแวร์ หรือเครือข่ายของคุณ ปล่อยให้ Codex cloud รับหน้าที่จัดการงานที่สั่งจากมือถือหรืองานที่ต้องรันขณะพับหน้าจอแล็ปท็อป และใช้ศูนย์กลางเดียวในการบันทึกและติดตามงานทั้งสองส่วน
หากคุณต้องการใช้งานเอเจนต์เขียนโค้ดหลายๆ ตัวต่อไป แทนที่จะต้องผูกมัดอยู่กับระบบนิเวศเพียงเจ้าเดียว นั่นคือปัญหาที่ Sharkly ได้รับการออกแบบมาเพื่อแก้ไขโดยเฉพาะ



