- 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 ไม่จำเป็นต้องอยู่บ้านเดียวกัน
อ่านจากซ้ายไปขวา แอปของคุณส่งงานเข้าไปหนึ่งครั้ง แล้ว 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 สิงหาคม 2569 | OpenAI (แต่ยืดหยุ่นน้อย บังคับรูปแบบ state) |
| Responses API | ทางเดินหลักที่ OpenAI แนะนำให้ย้ายมา | แอปของคุณ — คุมได้ละเอียด แต่ต้องเขียนเอง |
| Agents API | เปิด public beta 10 กันยายน 2569 | OpenAI (Codex harness) พร้อม sandbox ที่คุณเลือกที่ตั้งได้ |
หมายเหตุสำหรับทีมที่มีของเก่า: ถ้ายังมีโค้ดค้างอยู่บน Assistants API วันปิดบริการผ่านมาแล้วตั้งแต่ปลายเดือนสิงหาคม การย้ายไป Responses API คืองานที่ต้องทำก่อน ส่วน Agents API ค่อยพิจารณาทีหลังว่าคุ้มกับการยกลูปไปฝากไว้ฝั่ง OpenAI หรือไม่
Sandbox สามแบบ — จุดชี้ขาดว่าใช้ได้หรือไม่ในองค์กรคุณ
นี่คือส่วนที่แผนภาพอธิบายไว้ด้วยเส้นประ และเป็นเหตุผลที่บทความนี้เกี่ยวกับองค์กรมากกว่าที่คิด เพราะที่ตั้งของ sandbox คือที่ตั้งของ "ข้อมูลที่ agent จับต้องจริง"
| แบบ | ใครดูแลเครื่อง | เหมาะกับกรณี |
|---|---|---|
| OpenAI-hosted | OpenAI จัดเครื่องให้ คุณแค่ส่งไฟล์ ติดตั้งแพ็กเกจ เพิ่ม 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-astra | input $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 API | Claude Managed Agents |
|---|---|---|
| สถานะ | public beta 10 ก.ย. 2569 | beta เปิดก่อนหน้า |
| harness | Codex harness ที่ OpenAI ดูแลให้ | Anthropic รันลูปให้ agent ผูกกับ config ที่เก็บเป็นเวอร์ชัน |
| ที่ตั้ง sandbox | hosted / 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, บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด
แหล่งอ้างอิง
- OpenAI — Agents API overview (เอกสารทางการ: endpoint, sandbox, subagents, ข้อจำกัด data residency / ZDR)
- OpenAI Developer Community — Introducing the Agents API and hosted sandboxes (ประกาศเปิดตัว 10 ก.ย. 2569 + รายชื่อพาร์ตเนอร์ sandbox)
- OpenAI — API Pricing (อัตราค่า container ต่อ session 20 นาที, ราคาโมเดล, web search)
- OpenAI — Deprecations (กำหนดปิดบริการ Assistants API 26 ส.ค. 2569)
- Anthropic — Claude Managed Agents overview
- Anthropic — Session budgets (เพดานค่าใช้จ่ายต่อ session)
- Anthropic — Self-hosted sandboxes
อยากต่อ AI Agent เข้ากับระบบหลังบ้านอย่างปลอดภัย?
ปรึกษาทีม Grand Linux Solution เรื่องการเปิด MCP ให้ระบบ ERP แบบมีขอบเขตสิทธิ์ตาม role และ audit trail ครบทุกการเรียกใช้ ฟรี ไม่มีค่าใช้จ่าย
ขอ Demo ฟรีโทร 02-347-7730 | sale@grandlinux.com




