เครื่องมือใหม่สำหรับสร้างเอเจนต์
(openai.com)- OpenAI เปิดตัว Responses API, เครื่องมือในตัว, Agents SDK และเครื่องมือสังเกตการณ์ เพื่อให้การพัฒนา เอเจนต์สำหรับใช้งานจริงในโปรดักชัน ง่ายขึ้น
- Responses API ผสานความเรียบง่ายของ Chat Completions API เข้ากับความสามารถในการใช้เครื่องมือของ Assistants API ทำให้จัดการการค้นหาเว็บ การค้นหาไฟล์ และการใช้คอมพิวเตอร์ได้ในโฟลว์เดียว
- สำหรับการผสานรวมใหม่ แนะนำให้ใช้ Responses API ส่วน Assistants API จะเข้าสู่กระบวนการเลิกใช้งานหลังจากมีฟีเจอร์เทียบเท่ากันครบถ้วน โดยตั้งเป้ายุติใน กลางปี 2026
- เครื่องมือในตัวรองรับข้อมูลเว็บล่าสุด การค้นหาเอกสารขนาดใหญ่ และการทำงานอัตโนมัติบนคอมพิวเตอร์ด้วยเมาส์และคีย์บอร์ด แต่สำหรับ computer use โดยเฉพาะในสภาพแวดล้อมที่ไม่ใช่เบราว์เซอร์ แนะนำให้มีการกำกับดูแลจากมนุษย์
- นักพัฒนาสามารถผสาน API, เครื่องมือ, SDK และฟีเจอร์ติดตาม-ประเมินผลบนแพลตฟอร์มเดียว เพื่อสร้าง ปรับใช้ และเพิ่มประสิทธิภาพเอเจนต์ได้
องค์ประกอบใหม่สำหรับการพัฒนาเอเจนต์
- OpenAI มองเอเจนต์เป็น ระบบ ที่ทำงานแทนผู้ใช้ได้อย่างอิสระ
- ในช่วง 1 ปีที่ผ่านมา การให้เหตุผลขั้นสูง การโต้ตอบแบบมัลติโมดัล และเทคนิคความปลอดภัยใหม่ ๆ ได้ถูกนำมาใช้ ทำให้มีพื้นฐานสำหรับจัดการงานซับซ้อนหลายขั้นตอน
- ลูกค้าประสบความยากลำบากในการเปลี่ยนความสามารถเหล่านี้ให้เป็น เอเจนต์ที่พร้อมใช้งานจริงในโปรดักชัน
- ต้องวนปรับพรอมป์จำนวนมาก
- ต้องสร้างลอจิก orchestration แบบกำหนดเองเอง
- ขาดการมองเห็นที่เพียงพอและการสนับสนุนในตัว
- องค์ประกอบที่เปิดตัวครั้งนี้มีดังนี้
- Responses API: ผสานความเรียบง่ายของ Chat Completions API กับความสามารถในการใช้เครื่องมือของ Assistants API
- เครื่องมือในตัว: web search, file search, computer use
- Agents SDK: ทำ orchestration ให้กับเวิร์กโฟลว์เอเจนต์เดี่ยวและมัลติเอเจนต์
- เครื่องมือสังเกตการณ์: ติดตามและตรวจสอบการรันเวิร์กโฟลว์ของเอเจนต์
Responses API
- Responses API คือหน่วยพื้นฐานใหม่ของ API สำหรับสร้างเอเจนต์โดยใช้เครื่องมือในตัวของ OpenAI
- ผสานความเรียบง่ายของ Chat Completions กับความสามารถในการใช้เครื่องมือของ Assistants API
- ในการเรียก Responses API เพียงครั้งเดียว สามารถใช้หลายเครื่องมือและหลายเทิร์นของโมเดลเพื่อจัดการงานที่ซับซ้อนขึ้นได้
- เครื่องมือที่รองรับในระยะแรกมีดังนี้
- การค้นหาเว็บ
- การค้นหาไฟล์
- การใช้คอมพิวเตอร์
- รวมถึงการปรับปรุงด้านการใช้งาน
- การออกแบบแบบ item ที่เป็นหนึ่งเดียว
- polymorphism ที่เรียบง่ายขึ้น
- อีเวนต์สตรีมมิงที่เข้าใจง่าย
- helper ของ SDK เช่น
response.output_text
- ออกแบบมาสำหรับนักพัฒนาที่ต้องการผสานโมเดล OpenAI และเครื่องมือในตัวเข้ากับแอป โดยไม่ต้องรวม API หลายตัวหรือผู้ให้บริการภายนอกแยกกัน
- หากจัดเก็บข้อมูลไว้กับ OpenAI ฟีเจอร์ติดตามและประเมินผลจะทำให้ การประเมินประสิทธิภาพของเอเจนต์ ง่ายขึ้น
- โดยค่าเริ่มต้น OpenAI จะไม่ใช้ข้อมูลธุรกิจในการฝึกโมเดล และเป็นเช่นเดียวกันแม้ข้อมูลจะถูกจัดเก็บไว้กับ OpenAI
- นักพัฒนาทุกคนใช้งานได้ตั้งแต่วันนี้ ไม่มีค่าบริการแยกต่างหาก โดยโทเคนและเครื่องมือจะคิดค่าบริการตามอัตรามาตรฐานในหน้าราคา
- เอกสารเริ่มต้นมีให้ที่ Responses API quickstart guide
ความสัมพันธ์กับ API เดิม
- Chat Completions API จะยังได้รับการสนับสนุนต่อไปในฐานะ API ที่มีการนำไปใช้แพร่หลายที่สุดของ OpenAI
- นักพัฒนาที่ไม่ต้องการเครื่องมือในตัวสามารถใช้งานต่อได้
- โมเดลใหม่สำหรับฟีเจอร์ที่ไม่พึ่งพาเครื่องมือในตัวหรือการเรียกโมเดลหลายครั้ง จะยังเปิดตัวบน Chat Completions ต่อไป
- Responses API เป็น superset ของ Chat Completions และให้ประสิทธิภาพเท่ากัน จึงแนะนำให้ใช้ Responses API สำหรับการผสานรวมใหม่
- ฟีดแบ็กจากเบต้าของ Assistants API ถูกนำมาสะท้อนใน Responses API ทำให้ยืดหยุ่นกว่า เร็วกว่า และใช้งานง่ายกว่า
- กำลังดำเนินการให้ Assistants API และ Responses API มีฟีเจอร์เทียบเท่ากันครบถ้วน รวมถึงอ็อบเจ็กต์แบบ Assistant-like, อ็อบเจ็กต์แบบ Thread-like และเครื่องมือ Code Interpreter
- เมื่อฟีเจอร์เทียบเท่ากันครบถ้วนแล้ว มีแผนประกาศการเลิกใช้ Assistants API อย่างเป็นทางการ
- เป้าหมายเวลายุติคือ กลางปี 2026
- เมื่อประกาศเลิกใช้งาน จะมีคู่มือ migration ที่ช่วยให้รักษาข้อมูลและย้ายแอปพลิเคชันได้
- จนกว่าจะมีประกาศเลิกใช้อย่างเป็นทางการ จะยังให้โมเดลใหม่กับ Assistants API ต่อไป
- OpenAI วางให้ Responses API เป็น ทิศทางในอนาคต สำหรับการสร้างเอเจนต์บน OpenAI
เครื่องมือในตัวของ Responses API
-
การค้นหาเว็บ
- นักพัฒนาสามารถรับคำตอบที่รวดเร็วและเป็นปัจจุบันจากเว็บ พร้อม การอ้างอิงแหล่งที่มาอย่างชัดเจน
- ใน Responses API การค้นหาเว็บมีให้เป็นเครื่องมือเมื่อใช้
gpt-4oและgpt-4o-miniและสามารถใช้ร่วมกับเครื่องมืออื่นหรือการเรียกฟังก์ชันได้ - กรณีใช้งานในการทดสอบเบื้องต้นพบว่าเป็นแอปที่ต้องการข้อมูลเว็บล่าสุด เช่น ผู้ช่วยช้อปปิง เอเจนต์วิจัย และเอเจนต์จองการเดินทาง
- Hebbia ใช้เครื่องมือค้นหาเว็บเพื่อช่วยให้ผู้จัดการสินทรัพย์ บริษัทไพรเวตอิควิตีและเครดิต รวมถึงผู้ปฏิบัติงานด้านกฎหมาย ดึงอินไซต์ที่นำไปปฏิบัติได้จากชุดข้อมูลสาธารณะและส่วนตัวขนาดใหญ่ได้อย่างรวดเร็ว
- การค้นหาเว็บใน API ใช้โมเดลพื้นฐานเดียวกับที่ใช้ใน ChatGPT search
- ใน SimpleQA GPT‑4o search preview ทำความแม่นยำได้ 90% และ GPT‑4o mini search preview ทำได้ 88%
- คำตอบจากการค้นหาเว็บใน API มีลิงก์แหล่งที่มา เช่น บทความข่าวและบล็อกโพสต์
- เว็บไซต์หรือผู้เผยแพร่สามารถเลือกให้ปรากฏในการค้นหาเว็บของ API ได้
- เครื่องมือค้นหาเว็บมีให้เป็นพรีวิวสำหรับนักพัฒนาทุกคนใน Responses API
- ใน Chat Completions API สามารถเข้าถึงโมเดลค้นหาโดยตรงผ่าน
gpt-4o-search-preview,gpt-4o-mini-search-preview - ราคาเริ่มต้นที่ 30 ดอลลาร์ต่อ 1,000 query สำหรับ GPT‑4o search และ 25 ดอลลาร์ต่อ 1,000 query สำหรับ 4o-mini search
-
การค้นหาไฟล์
- เครื่องมือ file search ที่ปรับปรุงแล้วช่วยให้ค้นหาข้อมูลที่เกี่ยวข้องจากเอกสารขนาดใหญ่ได้ง่าย
- รองรับหลายรูปแบบไฟล์ การเพิ่มประสิทธิภาพ query การกรอง metadata และการ rerank แบบกำหนดเอง
- ใน Responses API สามารถผสานรวมได้ด้วยโค้ดเพียงไม่กี่บรรทัด
- กรณีใช้งานมีดังนี้
- เอเจนต์ซัพพอร์ตลูกค้าเข้าถึง FAQ
- ผู้ช่วยด้านกฎหมายอ้างอิงคดีในอดีตได้อย่างรวดเร็วสำหรับผู้เชี่ยวชาญที่มีคุณสมบัติเหมาะสม
- เอเจนต์เขียนโค้ดค้นดูเอกสารทางเทคนิค
- Navan ใช้ file search ในเอเจนต์เดินทางที่ขับเคลื่อนด้วย AI เพื่อให้คำตอบที่ถูกต้องจากเอกสารฐานความรู้ เช่น นโยบายการเดินทางของบริษัท ได้อย่างรวดเร็ว
- ด้วยการเพิ่มประสิทธิภาพ query และการ rerank ในตัว จึงสามารถสร้าง RAG pipeline ได้โดยไม่ต้องจูนหรือกำหนดค่าเพิ่มเติม
- หากมี vector store เฉพาะสำหรับแต่ละกลุ่มผู้ใช้ ก็สามารถให้คำตอบที่สอดคล้องกับการตั้งค่าบัญชีและบทบาทผู้ใช้ได้
- file search พร้อมใช้งานสำหรับนักพัฒนาทุกคนใน Responses API
- ราคาตามการใช้งานอยู่ที่ 2.50 ดอลลาร์ต่อ 1,000 query ส่วนพื้นที่เก็บไฟล์คิด 0.10 ดอลลาร์ต่อ GB ต่อวัน และ 1GB แรกฟรี
- ยังให้บริการใน Assistants API ต่อไป
- มีการเพิ่ม endpoint ค้นหาใหม่ให้กับอ็อบเจ็กต์ Vector Store API เพื่อให้ค้นข้อมูลที่จะใช้ในแอปพลิเคชันและ API อื่นได้โดยตรง
-
การใช้คอมพิวเตอร์
- เครื่องมือ computer use เป็นความสามารถใน Responses API สำหรับสร้างเอเจนต์ที่ทำงานบนคอมพิวเตอร์
- เครื่องมือนี้ขับเคลื่อนด้วยโมเดล Computer-Using Agent(CUA) ที่ทำให้ Operator เป็นไปได้
- โมเดล research preview ทำผลลัพธ์ benchmark ได้ดังนี้
- OSWorld: 38.1% ในงานใช้คอมพิวเตอร์โดยรวม
- WebArena: 58.1%
- WebVoyager: 87% ในการโต้ตอบบนเว็บ
- เครื่องมือ computer use ในตัวจะจับการกระทำเมาส์และคีย์บอร์ดที่โมเดลสร้างขึ้น
- นักพัฒนาสามารถแปลงการกระทำนี้เป็นคำสั่งที่รันได้ในสภาพแวดล้อมของตน เพื่อทำงานใช้คอมพิวเตอร์แบบอัตโนมัติ
- กรณีใช้งานคือการทำเวิร์กโฟลว์บนเบราว์เซอร์ให้เป็นอัตโนมัติ เช่น การประกันคุณภาพเว็บแอป และการป้อนข้อมูลระหว่างระบบ legacy
- Unify ใช้เครื่องมือ computer use ในระบบเพื่อการเติบโตของรายได้ ที่เอเจนต์ทำความเข้าใจเจตนา สำรวจบัญชี และติดต่อผู้ซื้อ
- เอเจนต์ยังสามารถใช้ข้อมูลที่ไม่เคยเข้าถึงผ่าน API ได้
- ตัวอย่างเช่น บริษัทบริหารอสังหาริมทรัพย์สามารถตรวจสอบผ่านแผนที่ออนไลน์ว่ากิจการหนึ่ง ๆ กำลังขยายขนาดพื้นที่อสังหาริมทรัพย์หรือไม่
- Luminai ผสานเครื่องมือ computer use เพื่อทำเวิร์กโฟลว์ปฏิบัติการที่ซับซ้อนให้เป็นอัตโนมัติสำหรับองค์กรขนาดใหญ่ที่มีระบบ legacy ซึ่งไม่มี API และข้อมูลมาตรฐาน
- ในไพลอตขององค์กรบริการชุมชนขนาดใหญ่แห่งหนึ่ง สามารถทำให้ขั้นตอนการประมวลผลใบสมัครและการลงทะเบียนผู้ใช้เป็นอัตโนมัติได้ภายในไม่กี่วัน
- RPA แบบดั้งเดิมทำงานเดียวกันได้ยากแม้พยายามเป็นเวลาหลายเดือน
- ก่อนเปิดตัว CUA ใน Operator ได้ทำการทดสอบความปลอดภัยและ red team อย่างกว้างขวางใน 3 ด้าน ได้แก่ การใช้ในทางที่ผิด ข้อผิดพลาดของโมเดล และความเสี่ยง frontier
- ยังมีการประเมินความปลอดภัยและ red team เพิ่มเติมเพื่อรับมือความเสี่ยงที่ความสามารถของ Operator ถูกขยายไปยังระบบปฏิบัติการท้องถิ่นผ่าน CUA ใน API
- มีการเพิ่มมาตรการลดความเสี่ยงสำหรับนักพัฒนาด้วย
- การตรวจสอบความปลอดภัยเพื่อป้องกัน prompt injection
- พรอมป์ยืนยันสำหรับงานที่มีความอ่อนไหว
- เครื่องมือช่วยแยกสภาพแวดล้อม
- การตรวจจับที่ดีขึ้นสำหรับการละเมิดนโยบายที่อาจเกิดขึ้น
- แม้มาตรการลดความเสี่ยงจะช่วยลดความเสี่ยงได้ แต่โมเดลยังอาจทำผิดพลาดโดยไม่ตั้งใจ โดยเฉพาะในสภาพแวดล้อมที่ไม่ใช่เบราว์เซอร์
- ประสิทธิภาพ OSWorld ที่ 38.1% แสดงให้เห็นว่ายังไม่มีความน่าเชื่อถือสูงสำหรับการทำงานระบบปฏิบัติการแบบอัตโนมัติ และในกรณีนี้แนะนำให้มี การกำกับดูแลจากมนุษย์
- รายละเอียดงานด้านความปลอดภัยเฉพาะ API ดูได้ใน system card ที่อัปเดตแล้ว
Agents SDK และ workflow orchestration
- เอเจนต์ต้องการไม่เพียงลอจิกหลักและการเข้าถึงเครื่องมือเท่านั้น แต่ยังต้องมี workflow orchestration ด้วย
- Agents SDK แบบโอเพนซอร์สใหม่ช่วยให้ orchestration ของเวิร์กโฟลว์มัลติเอเจนต์เรียบง่ายขึ้น
- ปรับปรุงจาก SDK เชิงทดลอง Swarm ที่เปิดตัวเมื่อปีที่แล้ว
- ฟีเจอร์หลักมีดังนี้
- Agents: LLM ที่ตั้งค่าได้ง่าย พร้อมคำสั่งที่ชัดเจนและเครื่องมือในตัว
- Handoffs: โอนการควบคุมระหว่างเอเจนต์อย่างชาญฉลาด
- Guardrails: การตรวจสอบความปลอดภัยที่กำหนดค่าได้สำหรับตรวจสอบ input และ output
- Tracing & Observability: แสดงภาพการติดตามการรันของเอเจนต์ เพื่อช่วย debug และเพิ่มประสิทธิภาพ
- กรณีใช้งานจริงที่นำไปใช้ได้ ได้แก่ การทำซัพพอร์ตลูกค้าอัตโนมัติ การวิจัยหลายขั้นตอน การสร้างคอนเทนต์ การรีวิวโค้ด และการหาลูกค้าเป้าหมายฝ่ายขาย
- Coinbase ใช้ Agents SDK เพื่อสร้างต้นแบบและปรับใช้ AgentKit อย่างรวดเร็ว ทำให้เอเจนต์ AI สามารถโต้ตอบกับกระเป๋าเงินคริปโตและกิจกรรมบนเชนได้
- ผสาน custom action ของ Developer Platform SDK เข้ากับเอเจนต์ที่ทำงานได้สมบูรณ์ภายในไม่กี่ชั่วโมง
- สถาปัตยกรรมที่เรียบง่ายของ AgentKit ทำให้การเพิ่ม action ใหม่ของเอเจนต์ง่ายขึ้น
- Box สร้างเอเจนต์ที่ใช้การค้นหาเว็บและ Agents SDK ได้ภายในไม่กี่วัน ทำให้ค้นหา สอบถาม และดึงอินไซต์จากข้อมูลไม่มีโครงสร้างภายใน Box และแหล่งข้อมูลอินเทอร์เน็ตสาธารณะได้
- ลูกค้าองค์กรสามารถค้นหาข้อมูลกรรมสิทธิ์ภายในได้ในลักษณะที่เป็นไปตามสิทธิ์ภายในและนโยบายความปลอดภัย พร้อมกับข้อมูลล่าสุด
- ตัวอย่างเช่น บริษัทบริการทางการเงินสามารถสร้างเอเจนต์แบบกำหนดเองที่ผสานการวิเคราะห์ตลาดภายในที่เก็บใน Box เข้ากับข่าวและข้อมูลเศรษฐกิจแบบเรียลไทม์บนเว็บ
- Agents SDK ทำงานได้กับ Responses API และ Chat Completions API
- หากมี endpoint API สไตล์ Chat Completions ก็สามารถใช้ร่วมกับโมเดลจากผู้ให้บริการอื่นได้ด้วย
- สามารถผสานเข้ากับ codebase Python ได้ทันที และจะรองรับ Node.js ในเร็ว ๆ นี้
- ในการออกแบบ Agents SDK OpenAI ได้รับแรงบันดาลใจจากผลงานของ Pydantic, Griffe และ MkDocs
- มีแผนจะสร้าง Agents SDK ต่อไปในฐานะเฟรมเวิร์กโอเพนซอร์ส เพื่อให้ชุมชนสามารถขยายแนวทางนี้ได้
ทิศทางการขยายแพลตฟอร์มเอเจนต์
- OpenAI มองว่าเอเจนต์จะกลายเป็นองค์ประกอบสำคัญของแรงงานในเร็ว ๆ นี้ และจะเพิ่ม ผลิตภาพ ทั่วทั้งอุตสาหกรรมอย่างมาก
- เมื่อความต้องการขององค์กรในการใช้ AI กับงานซับซ้อนเพิ่มขึ้น จึงมุ่งเน้นการให้องค์ประกอบที่ช่วยให้นักพัฒนาและองค์กรสร้างระบบอัตโนมัติที่สร้างผลกระทบจริงได้
- การเปิดตัวครั้งนี้เป็นองค์ประกอบชุดแรกที่จะทำให้การสร้าง ปรับใช้ และขยายเอเจนต์ AI ที่น่าเชื่อถือและมีประสิทธิภาพสูงทำได้ง่ายขึ้น
- เมื่อความสามารถของโมเดลพัฒนาไปในลักษณะเป็นเอเจนต์มากขึ้น OpenAI จะยังลงทุนต่อไปในการผสานรวมที่ลึกขึ้นทั่วทั้ง API และเครื่องมือใหม่ที่ช่วยปรับใช้ ประเมิน และเพิ่มประสิทธิภาพเอเจนต์ในโปรดักชัน
- เป้าหมายคือการมอบ ประสบการณ์แพลตฟอร์มที่ไร้รอยต่อ สำหรับสร้างเอเจนต์ที่ช่วยงานหลากหลายรูปแบบในทุกอุตสาหกรรมได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ไม่แน่ใจว่า การเปลี่ยนแปลง API แบบนี้จะช่วยนักพัฒนาที่พยายามเอา OpenAI ไปผูกกับผลิตภัณฑ์จริงได้มากแค่ไหน
สเตตแมชชีนที่ผู้ให้บริการจัดการให้ ซึ่งดูแลเรื่องบทสนทนา ข้อความ การส่งพรอมป์ต์ ฯลฯ สำหรับการใช้งานของผมสุดท้ายแล้วมักจะไม่พอ ตั้งสมมติฐานมากเกินไป หรือกลายเป็นสิ่งกีดขวาง
สุดท้ายผมก็ใช้ Chat Completions API โดยเปิดแค่ structured output และแม้ในนั้นก็ยังทำ tool use, recursive conversation, RAG ฯลฯ ได้เพียงพอ
ผมไม่เห็นคุณค่าว่าควรฝากการจัดการสถานะของ “เอเจนต์” ของผมไว้กับบุคคลที่สาม และเรื่องแบบนี้เก็บไว้ในเครื่องเองจะมีอิสระกว่ามาก
แก่นสำคัญมีแค่ว่าเอา string literal บางอย่างใส่เข้าไปในกล่องดำ แล้วได้สตริงใหม่กลับมา ถ้าเป็นไปได้ก็ในรูปแบบที่ร้องขออย่าง JSON
ถ้าโฟกัสที่มุมมองว่าทุกครั้งคือการประกอบสตริงที่เหมาะสม ส่วนที่เหลือก็หายไป และมันจะเหมือนกับการสร้างสตริงที่มีโครงสร้างสูงจากสถานะทางธุรกิจในฐานข้อมูล
โดยพื้นฐานแล้วมันเหมือนกับการเรนเดอร์หน้าเว็บฝั่งเซิร์ฟเวอร์ด้วย PHP และความต่างจริง ๆ มีแค่รูปแบบการส่งมอบเท่านั้น
ผมยังหาเฟรมเวิร์กเอเจนต์ที่เติมสิ่งที่ผมต้องการบน การเรียกสร้างแบบมีโครงสร้าง ง่าย ๆ ไม่ได้
คำขอไปยัง LLM ส่วนใหญ่ควรเป็น “อินพุตพรอมป์ต์, เอาต์พุตมีโครงสร้าง” และสิ่งนี้ก็สอดคล้องกับปรัชญา Unix ที่ให้ทำสิ่งเดียวให้ดี
เฟรมเวิร์กเอเจนต์ยังเร็วเกินไป และเป็นเพียงชั้นที่ทำ abstraction ให้กับชุด design pattern ที่ยังไม่แพร่หลาย
ควรสร้าง abstraction ก็ต่อเมื่อชัดเจนว่าทุกคนกำลังประดิษฐ์ล้อซ้ำ แต่สำหรับเอเจนต์ไม่มีล้อให้ประดิษฐ์ ทุกอย่างเป็นแค่การเรียกโมเดลภาษาแบบง่าย ๆ
ผมมักพูดว่า “โมเดลภาษาควรเป็นส่วนที่น่าเบื่อที่สุดในโค้ด”
เวลาส่วนใหญ่ควรใช้ไปกับการสร้างซอฟต์แวร์และเครื่องมือจริง ๆ และ LLM ควรเป็นองค์ประกอบเล็ก ๆ ของซอฟต์แวร์
สำหรับรสนิยมของผม เฟรมเวิร์กเอเจนต์ทำให้การมีอยู่ของโมเดลภาษาในโค้ดเบสใหญ่เกินไป
แม้แต่ abstraction อย่าง function calling ของ OpenAI ก็ยัง hallucinate พารามิเตอร์และสคีมา และ JSON Schema เองก็ยืดยาวเกินไป พอซับซ้อนกว่าการเรียกฟังก์ชันง่าย ๆ 5 ตัวเพียงเล็กน้อยก็พังหมด
มันดูเหมือนการสร้างซ้อนขึ้นไปบน abstraction แบบกล่องดำที่เสียอยู่แล้ว และไม่ค่อยมีประโยชน์กับแอปพลิเคชันจริง
อาจช่วยให้ทำแอป proof of concept ขนาดเล็กได้เร็วขึ้น
ถ้าจะสร้างบริษัทบน API แบบนี้ต้องไร้เดียงสาพอสมควร
LLM จะกลายเป็นสินค้าโภคภัณฑ์ และ OpenAI ก็ไม่มีทางเลือกนอกจากต้องต่อสู้กับชะตานั้น เพื่อให้มูลค่าบริษัทและขนาดการลงทุนที่ยังต้องใช้ต่อไปดูสมเหตุสมผล
ถ้าคุณสร้างบน Assistant API ก็รับสัญญาณนี้ไว้ แล้วอย่าแค่เขียนใหม่เป็น Responses API แต่ควรเป็นเจ้าของผลิตภัณฑ์ของตัวเอง
LLM ในวันนี้ควรถูกห่อไว้เป็นกล่องดำจะดีกว่า
เพราะมีส่วนที่บอกว่า “เมื่อใช้ Chat Completions โมเดลจะดึงข้อมูลจากเว็บก่อนตอบเสมอ หากต้องการให้โมเดลอย่าง gpt-4o และ gpt-4o-mini เรียก web_search_preview เป็นเครื่องมือเฉพาะเมื่อจำเป็น ให้ย้ายไปใช้ Responses API”
การพอร์ตไปยัง Responses API ใหม่ไม่ใช่เรื่องง่าย และเราก็มี history, RAG และสิ่งที่จำเป็นสำหรับ assistant อยู่แล้ว
ผมพัฒนา เอเจนต์ หลายตัวด้วยแค่ function calling และ structured output และรันใน production มานานกว่าหนึ่งปีแล้ว
เมื่อก่อนเราไม่เรียกมันว่าเอเจนต์ด้วยซ้ำ
รอบนี้ดูเหมือนตั้งเป้าไปที่คนที่ใช้เฟรมเวิร์กเอเจนต์ร่วมกับ OpenAI API อยู่แล้ว
มีเธรด Twitter ที่ดีซึ่งผู้ออกแบบ API ใหม่อธิบายที่มาของการตัดสินใจด้านการออกแบบหลายอย่าง: https://twitter.com/athyuttamre/status/1899541471532867821
มีลิงก์สำรองสำหรับคนที่ไม่ได้ล็อกอิน Twitter ด้วย: https://nitter.net/athyuttamre/status/1899541471532867821
ความพยายามเรื่อง AI agent แบบนี้ดูเหมือนพลาดตั้งแต่แก่น
เพราะมันพยายามแทนที่คนในระบบเดิม แทนที่จะสร้างวิธีใหม่
เศรษฐกิจ ชีวิต และทุกสิ่งสุดท้ายแล้วล้วนเกี่ยวกับ ปฏิสัมพันธ์ระหว่างคนกับคน จึงเป็นมุมมองที่สายตาสั้นโดยพื้นฐาน
แนวทาง AI agent ในตอนนี้ดูเหมือนการแปลงมุกที่ว่า “AI ตัวหนึ่งขยายประโยคเดียวให้เป็นอีเมลยาว ๆ ที่ดูน่าเชื่อถือ แล้ว AI ฝั่งผู้รับก็สรุปอีเมลยาวนั้นกลับมาเป็นประโยคเดียว”
ผมเข้าใจประโยชน์ของการทำงานในระบบเดิมให้เป็นอัตโนมัติ แต่โอกาสที่แท้จริงอยู่ที่การกำจัดระบบเดิมส่วนใหญ่ออกไป
มนุษย์ก็ไม่ได้แย่ขนาดนั้น
ผมสงสัยว่าการใช้ AI สร้าง UI สำหรับมนุษย์ แล้วให้ AI กลับมาควบคุม UI นั้นอีกที เป็นทางเดินไปข้างหน้าจริงหรือไม่
แล้วตะกร้าที่สานจากกิ่งไม้ที่หักด้วยมือใช้มากแค่ไหน?
ประวัติศาสตร์แสดงให้เห็นว่าสิ่งใดที่ทำให้เป็นอัตโนมัติได้ก็จะถูกทำให้เป็นอัตโนมัติ และสิ่งใดที่ทำให้ถูกลงหรือเร็วขึ้นได้ก็จะเป็นเช่นนั้น
เช่น ในระบบนิเวศ B2B SaaS ใช้เป็นประสบการณ์ผู้ช่วยสำหรับผู้ใช้ระดับสูงในองค์กร เพื่อให้ทำมาโครสำหรับงานตั้งค่าลูกค้าและจัดการโปรเจกต์ได้
หากจำกัด abstraction, บริบท และกลุ่มผู้ใช้ไว้อย่างดี การใช้เครื่องมือก็อาจเสถียรได้พอสมควร
สิ่งที่ขาดไปอย่างเห็นได้ชัด: Model Context Protocol
https://www.anthropic.com/news/model-context-protocol
เอเจนต์จำเป็นต้องมี โปรโตคอลการสื่อสาร ในรูปแบบใดรูปแบบหนึ่งเสมอ และโลกของเฟรมเวิร์กแบบเอเจนต์ก็เต็มไปด้วยโลโก้มากมาย ถ้าไม่มีมาตรฐานเปิดก็จะลำบาก
ตอนนี้อยู่ที่ Comet เคยลงมือทำการ implement MCP เอง และยังมีส่วนร่วมกับ Agent SDK ในรูปแบบการผสานรวมแบบเนทีฟและการปรับปรุงชุดทดสอบด้วย
https://github.com/comet-ml/opik-mcp
https://github.com/openai/openai-agents-python/pull/91
การผสานรวมล่าสุดปล่อยตั้งแต่วันแรกทันที
https://www.comet.com/docs/opik/tracing/integrations/openai_...
มองว่าแก่นสำคัญที่ OpenAI กำลังมุ่งไปคือการมอบความเรียบง่ายให้กับนักพัฒนาผ่านคอมโพเนนต์ที่ใช้งานง่าย
ไม่ขอพูดถึงกลยุทธ์หรือราคา แต่จากมุมมองนักพัฒนา เมื่อเห็นครั้งแรก แนวทางแบบโมดูลาร์ที่เรียบง่ายของ SDK และความไม่รกนั้นให้ความรู้สึกสดใหม่
อันนี้ไม่ใช่แบบเอนกประสงค์ แต่มีไว้ใช้การเรียกเครื่องมือของ mcp.run กับโมเดล OpenAI
ถึงอย่างนั้น การไม่รองรับ MCP โดยตรงก็แทบจะเป็นการเคลื่อนไหวที่ไม่เป็นมิตรกับนักพัฒนามากที่สุดอย่างหนึ่ง และถ้าเป็น OpenAI ก็ไม่น่าแปลกใจ
ถ้าเพิ่มเข้ามาได้ก็คงดีมาก
ต่อคำถามว่า “Agents SDK รองรับการเชื่อมต่อ MCP ไหม? สามารถมอบเครื่องมือให้เอเจนต์เฉพาะตัวได้ง่าย ๆ ผ่านการเชื่อมต่อ MCP client-server หรือไม่?” คำตอบคือ “สามารถกำหนดเครื่องมือที่ต้องการได้ ดังนั้นจึง implement เครื่องมือ MCP ด้วย function calling ได้”
สรุปคือ ต้องทำ งานเดินท่อ เองอยู่บ้าง
issue ที่เกี่ยวข้อง: https://github.com/openai/openai-agents-python/issues/23
swyx เอง
มีโอกาสได้ดู API ใหม่โดยรวมล่วงหน้ากับทีม API/DX และถามคำถามที่พบบ่อย
https://latent.space/p/openai-agents-platform
ประเด็นหลักที่น่าสนุกคือ ตอนนี้ response ถูกจัดเก็บฟรีเป็นค่าเริ่มต้นแล้ว เราจะ ใช้ Responses API ผิดวัตถุประสงค์เหมือนเป็นฐานข้อมูล ได้หรือไม่
ยังมีคำถามที่ชาว HN น่าจะชอบด้วย
ไฮเปอร์พารามิเตอร์ของการค้นหาเว็บ คือวิธีปรับความลึกและความกว้างของการค้นหาเมื่อทำ DIY Deep Research
ตอนนี้ OAI มี RAG และการจัดอันดับใหม่ให้มาเป็นค่าเริ่มต้นในส่วนหนึ่งของ Responses API แล้ว เมื่อใดจึงควรสร้าง RAG เอง
ส่วนตัวคิดว่าน่าจะมีใครสักคน benchmark ประสิทธิภาพ RAG ของ Files API ดู ความประทับใจของคอมมูนิตี้ดูเหมือนยังไม่ได้อัปเดตไปมากนักจากตอนที่ Assistants API เปิดตัวครั้งแรก
ความแตกต่างระหว่าง Agents SDK กับ OAI Swarm โดยคร่าว ๆ คือ type, tracing และ LLM ที่สลับเปลี่ยนได้
ก็สงสัยด้วยว่า fine-tuning ของ
search-previewกับcomputer-use-previewจะถูกรวมเข้าไปใน GPT5 หรือไม่0 - https://ai.pydantic.dev/
หนึ่งในเหตุผลหลักที่สร้างเครื่องมือค้นหา AI แบบนี้เอง คือเพื่อควบคุมความลึกและความกว้างได้อย่างเต็มที่ และยังปรับแต่ง loader ให้เข้ากับข้อมูลหรือไซต์ที่ต้องการได้ด้วย
ตอนนี้การค้นหาเว็บยังไม่โปร่งใสว่าไซต์ไหนไม่มีข้อความเต็ม และไซต์ไหนใช้แค่ snippet
การมีทั้งการใช้คอมพิวเตอร์และการค้นหาเว็บร่วมกันนั้นทรงพลังแน่นอน โดยเนื้อแท้แล้วก็เหมือน Deep Research ของ OpenAI
ในงานประกาศไม่ได้เปิดเผยราคา
เป็นไปได้มากว่าเพราะรู้อยู่แล้วว่ามันจะแพงมาก
การค้นหาเว็บ [0]: GPT‑4o search และ 4o-mini search ราคา $30, $25 ต่อ 1,000 คิวรีตามลำดับ
การค้นหาไฟล์ [1]: $2.50 ต่อ 1,000 คิวรี, การจัดเก็บไฟล์ $0.10/GB/วัน, 1GB แรกฟรี
เครื่องมือใช้คอมพิวเตอร์(โมเดล computer-use-preview) [2]: $3 ต่อโทเค็นอินพุต 1 ล้าน, $12 ต่อโทเค็นเอาต์พุต 1 ล้าน
[0] https://platform.openai.com/docs/pricing#web-search
[1] https://platform.openai.com/docs/pricing#built-in-tools
[2] https://platform.openai.com/docs/pricing#latest-models
ไม่ค่อยแน่ใจว่า API นี้ดีกว่า https://www.anthropic.com/news/model-context-protocol อย่างไร
ดูเหมือนแรงจูงใจจะเป็น “จะหาเงินเพิ่มได้อย่างไร” มากกว่า “จะทำให้มีประโยชน์ต่อผู้ใช้มากขึ้นได้อย่างไร”
ชอบนะ เป็นการเดินเกมที่กล้า
พอคนช้าของ Google ตามทันในที่สุด มันอาจสายเกินไปสำหรับ Google แล้วก็ได้
ผมเขียนสคริปต์ที่ค้นหาเว็บและทำงานได้ค่อนข้างดีไว้ด้วย ใช้ vercel ai sdk [1]
[0] - https://brave.com/search/api/
[1] - https://gist.github.com/bramses/41e90b27d156590154bcefd4119f...
ผมสร้างเวอร์ชันที่เรียบง่ายและทรงพลังกว่า Responses API มากขึ้นมาเอง และทำงานได้กับผู้ให้บริการ LLM ทุกเจ้า
https://github.com/Anilturaga/aiide
ดูดี และน่าสนใจมากจริง ๆ
มีข้อความว่า “มีแผนจะประกาศยุติการรองรับ Assistant API อย่างเป็นทางการ โดยตั้งเป้าสิ้นสุดในช่วงกลางปี 2026”
Responses API ใหม่ถือเป็นก้าวไปในทิศทางที่ถูกต้อง รวมถึงมีฟีเจอร์ “handoff” ในตัวด้วย
แต่สำหรับ use case แบบเอเจนต์ ยังรู้สึกว่าจำกัดอยู่บ้าง และยังขาด guardrails·ตรรกะ state machine อย่างเป็นทางการ
เขาบอกว่า “เป้าหมายคือมอบประสบการณ์แพลตฟอร์มที่ลื่นไหลให้นักพัฒนาสามารถสร้างเอเจนต์ได้” ซึ่งน่าสนใจว่าจะย้ายไปสู่แพลตฟอร์มนี้อย่างไร
คิดว่าอีกไม่กี่เดือนคงได้เห็น control flow แบบกราฟ
ตอนนี้ก็มีโซลูชันโอเพนซอร์สมากมาย แต่ส่วนใหญ่ยังไม่พอ หรือเพิ่มความทึบและความซับซ้อนที่ไม่จำเป็น
ที่ผ่านมาเราสร้าง flow แบบเอเจนต์ได้ด้วยการผสม tool calling กับ JSON response แต่ยังขาดองค์ประกอบระดับสูงที่ยังไม่มีใครแก้ได้ดีจริง ๆ
พัฒนาการของ Computer Use ที่กล่าวถึงตรงนี้น่าประทับใจ เลยสงสัยว่ามันโตพอจะเอาไปใช้กับ usability testing ได้แล้วหรือยัง
โดยทั่วไป ถ้า UI ที่ AI นำทางได้ยาก ก็มีความเป็นไปได้สูงว่ามนุษย์ก็จะใช้ยากเช่นกัน และควรมองว่าเป็นสัญญาณว่าต้องทำให้เรียบง่ายขึ้นหรือปรับปรุงในทางใดทางหนึ่งได้ไหม?
รูปแบบที่ LLM โต้ตอบกับ UI กับวิธีที่มนุษย์ใช้ UI นั้นต่างกันมาก
Agents SDK ที่ลิงก์ไว้ขึ้น 404
เผื่อเป็นข้อมูลอ้างอิง MindRoot มีบางอย่างที่คล้ายกับ Responses และบางส่วนของ File Search โดยใช้ task API: https://github.com/runvnc/mindroot/blob/main/api.md
สิ่งนี้สามารถใช้ร่วมกับเครื่องมือ query_kb ของปลั๊กอิน mr_kb ได้ และอนุญาตให้ค้นหา KB หลายตัว ดังนั้นจริง ๆ แล้วอาจดีกว่า File Search ก็ได้
ใครอยากช่วยโปรแกรมของผม สร้างปลั๊กอิน หรือส่ง PR ติดต่อมาได้สบาย ๆ ทาง GitHub, อีเมล, Discord/Telegram(runvnc)
อาจเป็นเพราะล็อกอินอยู่ก็ได้