02-347-7730  |  Saeree ERP - ระบบ ERP ครบวงจรสำหรับธุรกิจไทย ติดต่อเรา

OpenAI Agents API คืออะไร? ถอดแผนภาพ Codex Harness และ Sandbox ที่องค์กรต้องเลือกเอง 2569

  • หน้าแรก
  • บทความ
  • OpenAI Agents API คืออะไร? ถอดแผนภาพ Codex Harness และ Sandbox ที่องค์กรต้องเลือกเอง 2569
OpenAI Agents API คืออะไร? ถอดแผนภาพ Codex Harness และ Sandbox ที่องค์กรต้องเลือกเอง 2569
  • 13
  • กันยายน

OpenAI Agents API คือ API ที่ยก harness ของ Codex ขึ้นมาขายเป็นบริการ — OpenAI รับหน้าที่วนลูป AI Agent ให้ทั้งหมด ทั้งการจัดการ session การบีบอัด context และการกู้งานที่ล้มกลางทาง ส่วนแอปของคุณเหลือหน้าที่แค่สองอย่าง คือส่งงานเข้าไป กับเลือกว่า "มือ" ของ agent จะไปรันคำสั่งจริงบนเครื่องไหน เปิด public beta เมื่อ 10 กันยายน 2569

บทความนี้ถอดแผนภาพสถาปัตยกรรมทีละกล่อง ดูราคาจริงของ container ที่หลายทีมมองข้ามจนบิลบาน เทียบกับฝั่ง Anthropic ที่ทำเรื่องเดียวกันมาก่อน และสรุปสามข้อที่ฝ่าย compliance ขององค์กรไทยจะถามก่อนอนุมัติให้ใช้งานจริง

สรุปบรรทัดเดียว: Agents API คือบริการที่ให้ OpenAI รันลูป agent แทนคุณด้วย Codex harness ตัวเดียวกับที่ Codex ใช้ ส่วนคุณเลือกเองได้ว่า sandbox ที่รันคำสั่งจริงจะอยู่บนเครื่องของ OpenAI เครื่องของคุณเอง หรือของพาร์ตเนอร์ — ตัว API ไม่คิดค่าธรรมเนียมเพิ่ม แต่คิดค่าโทเคน ค่า tool และค่าเวลาที่ container เปิดค้างอยู่

แผนภาพเดียวที่อธิบายทั้งระบบ

สถาปัตยกรรมของ Agents API แบ่งความรับผิดชอบออกเป็นสามฝั่ง และเส้นประด้านล่างของแผนภาพคือจุดที่องค์กรควรมองเป็นอันดับแรก เพราะมันบอกว่า "สมอง" กับ "มือ" ของ agent ไม่จำเป็นต้องอยู่บ้านเดียวกัน

คุณ OpenAI OpenAI หรือผู้ให้บริการของคุณ แอปพลิเคชัน ส่งงานเข้าไป แสดงผลลัพธ์ให้ผู้ใช้ Agents API Codex Harness ที่ OpenAI ดูแลให้ทั้งหมด Sandbox รันคำสั่ง อ่าน–เขียนไฟล์จริง งานที่สั่ง เหตุการณ์ + ผลลัพธ์ เรียกใช้ tool ผลลัพธ์ที่รันได้ แอปของคุณเลือกได้เองว่า sandbox จะไปรันบนเครื่องไหน (self-hosted compute — โค้ดและไฟล์ไม่จำเป็นต้องออกจากเครือข่ายคุณ)

อ่านจากซ้ายไปขวา แอปของคุณส่งงานเข้าไปหนึ่งครั้ง แล้ว Agents API รับหน้าที่วนลูปคิด–เรียก tool–อ่านผล–คิดต่อ โดยส่ง event กลับมาให้แอปแสดงผลตามจริง ส่วนกล่องขวาสุดคือที่ที่คำสั่งถูกรันจริง ไฟล์ถูกเขียนจริง และ artifact ถูกสร้างขึ้นมา — ซึ่งไม่จำเป็นต้องเป็นเครื่องของ OpenAI

Harness คืออะไร ทำไมถึงเป็นงานที่หนักที่สุดของการทำ agent

คนมักคิดว่าการสร้าง AI Agent คือการเลือกโมเดลเก่ง ๆ แต่ในทางปฏิบัติ โมเดลเป็นแค่ชิ้นเดียว ส่วนที่กินเวลาทีมพัฒนาจริง ๆ คือ harness — โค้ดที่ห่อรอบโมเดลไว้เพื่อให้มันทำงานยาว ๆ ได้โดยไม่พัง สิ่งที่ Agents API ขายจึงไม่ใช่โมเดล แต่คือ harness ตัวเดียวกับที่ Codex ใช้อยู่

งานของ harnessถ้าเขียนเองAgents API จัดการให้
จำบทสนทนาข้ามหลายเทิร์นเก็บ history เอง แล้วส่งกลับไปทั้งก้อนทุกครั้งsession เก็บ state ไว้ฝั่ง OpenAI สั่งงานต่อได้โดยไม่ต้องประกอบ context ใหม่
context ใกล้เต็มเขียน logic สรุป/ตัดทิ้งเอง เสี่ยงตัดของสำคัญหายcompaction อัตโนมัติ และทำแยกกันระหว่าง agent หลักกับ subagent แต่ละตัว
งานใหญ่ที่ควรแตกเป็นงานย่อยเขียน orchestrator + รวมผลเองมอบให้ subagent ทำขนานกัน กำหนดจำนวนด้วย max_concurrent_subagents
เรียก tool หลายตัวพร้อมกันจัดคิว จัด error จัด retry เองเรียกขนาน ร้อยผลต่อกัน และกรองผลลัพธ์ก่อนส่งเข้าโมเดล
นิยาม tool เยอะจนเปลืองโทเคนยัดทุก tool เข้าไปใน prompt ทุกครั้งtool search โหลดเฉพาะนิยามที่ต้องใช้ รักษา cache ไม่ให้แตก
งานล้มกลางทางเขียนกลไกกู้คืนเองเปิด session เดิมขึ้นมาทำต่อได้ รองรับงานที่กินเวลาเป็นวัน

จุดที่ต่างจากเดิมชัดที่สุด: ใน Responses API ลูป agent อยู่ในโค้ดของคุณ — คุณเป็นคนตัดสินใจว่าจะเรียก tool ไหนต่อ เก็บ history อย่างไร ส่วนใน Agents API ลูปนั้นย้ายไปอยู่ฝั่ง OpenAI ทั้งหมด คุณเหลือแค่ "บอกว่ามี tool อะไรให้ใช้" กับ "บอกว่าจะให้รันที่ไหน"

เส้นทางกว่าจะมาถึง Agents API

ถ้าดูเฉพาะข่าวเปิดตัวจะเห็นแค่ของใหม่ แต่ถ้าเรียงไทม์ไลน์จะเห็นทิศทางชัดว่า OpenAI ค่อย ๆ ย้ายภาระจากฝั่งนักพัฒนามาไว้ฝั่งตัวเอง

APIสถานะลูป agent อยู่ที่ใคร
Assistants API (beta)ประกาศเลิกใช้ ปิดบริการ 26 สิงหาคม 2569OpenAI (แต่ยืดหยุ่นน้อย บังคับรูปแบบ state)
Responses APIทางเดินหลักที่ OpenAI แนะนำให้ย้ายมาแอปของคุณ — คุมได้ละเอียด แต่ต้องเขียนเอง
Agents APIเปิด public beta 10 กันยายน 2569OpenAI (Codex harness) พร้อม sandbox ที่คุณเลือกที่ตั้งได้

หมายเหตุสำหรับทีมที่มีของเก่า: ถ้ายังมีโค้ดค้างอยู่บน Assistants API วันปิดบริการผ่านมาแล้วตั้งแต่ปลายเดือนสิงหาคม การย้ายไป Responses API คืองานที่ต้องทำก่อน ส่วน Agents API ค่อยพิจารณาทีหลังว่าคุ้มกับการยกลูปไปฝากไว้ฝั่ง OpenAI หรือไม่

Sandbox สามแบบ — จุดชี้ขาดว่าใช้ได้หรือไม่ในองค์กรคุณ

นี่คือส่วนที่แผนภาพอธิบายไว้ด้วยเส้นประ และเป็นเหตุผลที่บทความนี้เกี่ยวกับองค์กรมากกว่าที่คิด เพราะที่ตั้งของ sandbox คือที่ตั้งของ "ข้อมูลที่ agent จับต้องจริง"

แบบใครดูแลเครื่องเหมาะกับกรณี
OpenAI-hostedOpenAI จัดเครื่องให้ คุณแค่ส่งไฟล์ ติดตั้งแพ็กเกจ เพิ่ม skillเริ่มเร็ว ไม่อยากดูแล infra งานที่ข้อมูลไม่อ่อนไหว
Self-hostedเครื่องของคุณเอง ใน VPC ของคุณ เลือก CPU / GPU / หน่วยความจำได้ข้อมูลห้ามออกนอกเครือข่าย ต้องต่อระบบภายในที่ไม่เปิดออกอินเทอร์เน็ต
Partner sandboxผู้ให้บริการที่ OpenAI เชื่อมไว้แล้ว 9 ราย ได้แก่ Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop และ Vercelอยากได้ตรงกลาง — ไม่ต้องดูแลเครื่องเอง แต่เลือกภูมิภาคและผู้ให้บริการได้

หน้าตาการเรียกใช้จริง

โครงคำขอนั้นตรงไปตรงมา — ปลายทางเดียว หนึ่ง session ต่อหนึ่งงาน แล้วรับ event กลับมา

POST https://api.openai.com/v1/agents/sessions

{
  "model": "gpt-6-astra",
  "sandbox": { "type": "hosted" },          // หรือชี้ไปเครื่องของคุณเอง
  "tools": [
    { "type": "mcp", "server_url": "https://mcp.example.co.th/erp" },
    { "type": "web_search" }
  ],
  "multi_agent": { "enabled": true, "max_concurrent_subagents": 4 }
}

ตัว tool รองรับทั้ง MCP (Model Context Protocol) ผ่าน HTTP, ฟังก์ชันที่คุณเขียนเอง และ built-in tool อย่าง web search — แปลว่าถ้าองค์กรมี MCP server อยู่แล้ว การต่อเข้ากับ agent ตัวนี้ไม่ต้องเขียน adapter ใหม่ทั้งชุด ประเด็นเรื่องการยืนยันตัวตนของ MCP ฝั่งองค์กร เราแยกเขียนไว้ใน สเปก MCP กับการทำ auth ระดับองค์กร

ราคา: ตัว API ไม่คิดเงิน แต่ "เวลา" ของ container คิด

OpenAI ระบุว่าไม่มีค่าธรรมเนียมเพิ่มสำหรับการใช้ Agents API — คุณจ่ายตามโทเคน ตาม tool และตามเวลาที่ container เปิดอยู่ ซึ่งข้อสุดท้ายนี่แหละที่ทำให้บิลบานได้ถ้าไม่ระวัง

รายการอัตราตามหน้าราคา OpenAIสิ่งที่ต้องระวัง
ค่าใช้ Agents APIไม่มีค่าธรรมเนียมเพิ่มต้นทุนจริงซ่อนอยู่ใน 3 บรรทัดถัดไป
Container (hosted shell / code interpreter)1 GB $0.03 · 4 GB $0.12 · 16 GB $0.48 · 64 GB $1.92 ต่อ session-container 20 นาทีคิดเป็นรายนาที ขั้นต่ำ 5 นาทีต่อ session — agent ที่เปิดค้างข้ามวันคือค่าใช้จ่ายที่เดินตลอด
โมเดล gpt-6-astrainput $10 / output $50 ต่อ 1M โทเคน (context สั้น) · context ยาวขึ้นเป็น $20 / $75งาน agent มักอ่านมากกว่าเขียน โทเคน input คือตัวที่โตเร็วที่สุด
Web search$10 ต่อ 1,000 ครั้ง บวกโทเคนของเนื้อหาที่ค้นมาตามอัตราของโมเดลsubagent หลายตัวค้นพร้อมกัน = คูณจำนวนครั้งทันที

คำแนะนำก่อนเปิดใช้จริง: ตั้ง usage limit ที่ระดับโปรเจกต์ก่อนรัน agent ตัวแรกเสมอ และอย่าเพิ่งเปิด subagent หลายตัวในรอบทดสอบ — คำนวณค่า container ต่อ session ให้จบก่อน แล้วค่อยขยาย นี่เป็นคำเตือนที่โผล่ในกระทู้ประกาศเปิดตัวของ OpenAI เองตั้งแต่วันแรก

สามข้อที่องค์กรไทยต้องตรวจก่อนตัดสินใจ

ข้อจำกัดที่ระบุไว้ในเอกสารทางการ (ตรวจสอบ 13 กันยายน 2569):

Agents API รองรับ data residency เฉพาะสหรัฐอเมริกา และ ไม่รองรับ Zero Data Retention (ZDR) — ข้อหลังนี้เป็นจริงแม้คุณจะเลือก sandbox แบบ self-hosted ก็ตาม เพราะการรัน sandbox เองช่วยเรื่องที่ตั้งของ "การประมวลผลและไฟล์" แต่ไม่ได้เปลี่ยนเงื่อนไขการเก็บข้อมูลฝั่ง API

สำหรับหน่วยงานรัฐหรือองค์กรที่ผูกกับ PDPA และข้อกำหนดเรื่องที่ตั้งข้อมูล สองบรรทัดนั้นคือคำตอบตั้งต้นที่ฝ่าย compliance จะถามก่อนเรื่องอื่นทั้งหมด และควรตอบให้ได้ก่อนเริ่ม PoC ไม่ใช่หลังจากนั้น

ข้อที่สองคือ ขอบเขตของ tool — agent ที่ต่อเข้าระบบธุรกิจได้จริง คือ agent ที่มีสิทธิ์ทำอะไรบางอย่างได้จริง ความเสี่ยงจึงย้ายจาก "โมเดลตอบผิด" ไปเป็น "โมเดลถูกหลอกให้สั่งงาน" ซึ่งเป็นคนละเรื่องกันโดยสิ้นเชิง เราเขียนแยกไว้แล้วใน Prompt Injection: ช่องโหว่อันดับ 1 ของ AI Agent ก่อนต่อเข้าระบบธุรกิจ

ข้อที่สามคือ ร่องรอยการทำงาน — ถ้า agent แก้ข้อมูลในระบบหลังบ้านได้ ต้องตอบให้ได้ว่าใครสั่ง สั่งเมื่อไร ผ่าน tool ตัวไหน และย้อนกลับได้หรือไม่ ส่วนเรื่องเกณฑ์ความเสี่ยงของโมเดลรุ่นล่าสุดที่ใช้ในบริการนี้ ดูเพิ่มได้ที่บทความ OpenAI Astra กับเกณฑ์ Critical ด้านไซเบอร์

ฝั่ง Anthropic ทำแบบเดียวกันไหม

ทำ และมาก่อนด้วย โครงคิดแทบจะเป็นภาพเดียวกัน คือแยก "สมอง" (harness ที่ผู้ให้บริการดูแล) ออกจาก "มือ" (sandbox ที่ลูกค้าเลือกที่ตั้งได้) ความต่างอยู่ที่รายละเอียดการควบคุม

หัวข้อOpenAI Agents APIClaude Managed Agents
สถานะpublic beta 10 ก.ย. 2569beta เปิดก่อนหน้า
harnessCodex harness ที่ OpenAI ดูแลให้Anthropic รันลูปให้ agent ผูกกับ config ที่เก็บเป็นเวอร์ชัน
ที่ตั้ง sandboxhosted / self-hosted / partner 9 รายcloud environment หรือ self-hosted sandbox พร้อม MCP tunnel เข้าเครือข่ายตัวเอง
เพดานค่าใช้จ่ายยังไม่พบกลไกเพดานระดับ session ในเอกสารเปิดตัว (ตรวจ 13 ก.ย. 2569) — คุมด้วย usage limit ขององค์กรแทนsession budget เป็นเพดานเงินแบบบังคับต่อหนึ่ง session หยุดยิงคำขอเมื่อถึงวงเงิน
ตั้งเวลาทำงานเองยังไม่พบในเอกสารเปิดตัว (ตรวจ 13 ก.ย. 2569)scheduled deployment ยิง session ตามรอบเวลาแบบ cron
MCPรองรับผ่าน HTTP transportรองรับ พร้อม tunnel เข้า MCP server ที่ไม่เปิดออกอินเทอร์เน็ต

รายละเอียดฝั่ง Anthropic เราเขียนไว้ครบแล้วใน Claude Managed Agents คืออะไร ส่วนใครที่สนใจฝั่งเครื่องมือเขียนโค้ดโดยเฉพาะ ดูที่ Codex สำหรับองค์กร: ไลเซนส์ ความปลอดภัย และการกำกับดูแล

แล้วเรื่องนี้เกี่ยวอะไรกับระบบ ERP

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

ในฝั่ง Saeree ERP เราวางเส้นแบ่งไว้ชัด — ERP คือแหล่งข้อมูลจริง ส่วน AI เป็นผู้ช่วย ไม่ใช่ผู้มีอำนาจอนุมัติ การเชื่อมต่อทำผ่าน MCP server ที่เปิดเฉพาะสิ่งที่ตั้งใจจะเปิด กำหนดสิทธิ์ตาม role เดียวกับที่ผู้ใช้คนนั้นมีอยู่ในระบบ และทุกการเรียกใช้ถูกบันทึกเป็น audit trail เหมือนธุรกรรมปกติ

และเพื่อความตรงไปตรงมา ข้อจำกัดเรื่อง data residency ข้างต้นใช้กับบริการของ OpenAI — ตัวระบบ ERP เองยังติดตั้งแบบ on-premise ในศูนย์ข้อมูลของลูกค้าได้ตามเดิม ทางเลือกที่เราเห็นว่าใช้งานได้จริงที่สุดสำหรับหน่วยงานที่มีข้อกำหนดเข้ม คือให้ agent ทำงานกับ "ผลลัพธ์ที่สรุปแล้ว" ผ่าน tool ที่จำกัดขอบเขตไว้ แทนที่จะเปิดฐานข้อมูลทั้งก้อนให้โมเดลอ่าน

สรุป: เหมาะกับใคร ยังไม่เหมาะกับใคร

เหมาะ ถ้า...ยังไม่เหมาะ ถ้า...
อยากได้ agent ที่ทำงานยาวข้ามวันโดยไม่ต้องเขียนกลไก compaction และ recovery เองข้อกำหนดขององค์กรบังคับว่าข้อมูลต้องอยู่ในประเทศ หรือบังคับ Zero Data Retention
มี MCP server หรือ tool ภายในพร้อมอยู่แล้ว เหลือแค่หาสมองมาสั่งงานยังไม่มีขอบเขตสิทธิ์และ audit trail ที่ชัดในระบบหลังบ้าน
งานเป็นลักษณะแตกเป็นชิ้นย่อยแล้วทำขนานกันได้ เช่น ตรวจเอกสารทีละกองงบยังไม่มีเพดาน และยังไม่ได้ตั้ง usage limit — ค่า container เดินตามเวลาที่เปิดค้าง
ต้องการเก็บการรันไว้ในเครือข่ายตัวเอง โดยไม่อยากดูแล orchestration ทั้งหมดต้องการแค่ถาม–ตอบครั้งเดียวจบ — Responses API เบากว่าและถูกกว่ามาก

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

harness กลายเป็นของที่ซื้อได้แล้ว สิ่งที่ยังซื้อไม่ได้คือขอบเขตสิทธิ์และร่องรอยตรวจสอบในระบบหลังบ้านของคุณเอง — และนั่นคือส่วนที่ตัดสินว่า agent จะเป็นผู้ช่วย หรือเป็นความเสี่ยง

- ทีม Saeree ERP, บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด

แหล่งอ้างอิง

อยากต่อ AI Agent เข้ากับระบบหลังบ้านอย่างปลอดภัย?

ปรึกษาทีม Grand Linux Solution เรื่องการเปิด MCP ให้ระบบ ERP แบบมีขอบเขตสิทธิ์ตาม role และ audit trail ครบทุกการเรียกใช้ ฟรี ไม่มีค่าใช้จ่าย

ขอ Demo ฟรี

โทร 02-347-7730 | sale@grandlinux.com

Saeree ERP Author

เกี่ยวกับผู้เขียน

ไพฑูรย์ บุตรี

ผู้เชี่ยวชาญด้านระบบเน็ตเวิร์คและระบบความปลอดภัยเซิร์ฟเวอร์ บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด