- เป็นมาตรฐานโอเพนซอร์สและระบบนิเวศที่มุ่งเป้าไปที่ การทำงานร่วมกันระหว่างผู้ให้บริการ LLM หลายราย โดยกำหนดอินเทอร์เฟซกลางบนพื้นฐานของ OpenAI Responses API
- อธิบายคำขอและการตอบกลับด้วย สคีมาที่ใช้ร่วมกัน ทำให้สามารถรันในรูปแบบเดียวกันกับผู้ให้บริการโมเดลหลายรายได้ด้วยงานแปลงข้อมูลเพียงเล็กน้อย
- จัดองค์ประกอบร่วมอย่างข้อความ การเรียกใช้ทูล สตรีมมิง อินพุตแบบมัลติโหมด ฯลฯ ให้อยู่ในโครงสร้างที่สอดคล้องกัน จึงเหมาะกับการสร้างเวิร์กโฟลว์แบบเอเจนต์
- เป็นโครงสร้างที่อนุญาตให้มีส่วนขยายเฉพาะผู้ให้บริการบนแกนกลางที่เสถียร โดยมุ่งทั้ง ความขยายได้และการไม่แตกแยก ไปพร้อมกัน
- ดำเนินงานบนพื้นฐานของคอมมูนิตี้ที่มี ผู้สร้างจำนวนมากเข้าร่วม เช่น OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI, vLLM เป็นต้น
ภาพรวม
- Open Responses คือมาตรฐานโอเพนซอร์สและระบบนิเวศเครื่องมือที่ อิงกับ OpenAI Responses API
- ออกแบบมาเพื่อให้สามารถทำงานอย่าง ไม่ผูกกับผู้ให้บริการ ได้ ทั้งการเรียกใช้ language model การจัดการผลลัพธ์แบบสตรีมมิง และงานประกอบเอเจนต์
- มอบประสบการณ์แบบอินเทอร์เฟซเดียวผ่านสคีมากลางและชั้นเครื่องมือร่วม
ทำไมต้อง Open Responses
- แม้ API ของ LLM จะมีองค์ประกอบคล้ายกัน เช่น ข้อความ การเรียกใช้ทูล สตรีมมิง และอินพุตแบบมัลติโหมด แต่ก็ยังใช้ วิธีเข้ารหัสที่ต่างกัน
- Open Responses จึงมอบ มาตรฐานกลางแบบเปิดเผยสู่สาธารณะ เพื่อรวมสิ่งเหล่านี้เข้าด้วยกันและลดภาระจากการทำซ้ำในการพัฒนา
- โครงสร้างคำขอและผลลัพธ์ที่นิยามไว้ครั้งเดียวสามารถนำกลับไปใช้ซ้ำกับผู้ให้บริการหลายรายได้
หลักการออกแบบ
- ใช้ การออกแบบที่รองรับหลายผู้ให้บริการเป็นพื้นฐาน ทำให้สคีมาเดียวสามารถแมปกับผู้ให้บริการโมเดลที่หลากหลายได้
- ใช้แนวคิด items เป็นหน่วยย่อยสุดของอีเวนต์สตรีมมิง รูปแบบการเรียกใช้ทูล และผลลัพธ์จากโมเดล เพื่อให้โครงสร้างเป็นมิตรกับเวิร์กโฟลว์แบบเอเจนต์
- ฟีเจอร์ที่ยังไม่สามารถทำให้เป็นแบบทั่วไปจะอนุญาตให้ขยายแบบเฉพาะผู้ให้บริการได้ แต่ให้ความสำคัญกับ การคงเสถียรภาพของแกนหลัก เป็นอันดับแรก
คอมมูนิตี้และระบบนิเวศ
- ดำเนินงานในฐานะ โครงการคอมมูนิตี้แบบเปิด ที่ตั้งอยู่บนสมมติฐานของสภาพแวดล้อมแบบหลายเวนเดอร์
- มีหลายองค์กรเข้าร่วมแสดงตัวผ่านโลโก้ เช่น OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI, vLLM
- ก่อให้เกิดคอมมูนิตี้ที่ขับเคลื่อนโดยนักพัฒนา ซึ่งให้ความสำคัญกับการพกพาได้ การทำงานร่วมกัน และรากฐานร่วม
คุณลักษณะของสเปก
- ใช้ สคีมากลางที่ยึด items เป็นศูนย์กลาง เพื่อแสดงข้อความ/การเรียกใช้ทูล/สถานะการอนุมานในหน่วยเดียวกัน โดยมีโครงสร้างที่ทั้งอินพุตและเอาต์พุตเคลื่อนที่ในรูปของ item
- กำหนด response และ item เป็น state machine เพื่อจัดการวงจรชีวิตอย่างชัดเจน เช่น
in_progress→completed/failed/incomplete
- ทำให้สตรีมมิงเป็นมาตรฐานในรูปของ semantic events แทนชิ้นข้อความ โดยยึดแพตเทิร์นคงที่ที่เริ่มด้วย
response.output_item.added แล้วปิดด้วย delta→done
- แยกทูลเป็น การรันภายนอก (นักพัฒนา/บุคคลที่สาม) และ การรันภายใน (โฮสต์โดยผู้ให้บริการ) พร้อมมีชั้นควบคุมที่บังคับขอบเขตการเรียกใช้ได้ด้วย
tool_choice/allowed_tools
- ใช้
previous_response_id ให้เซิร์ฟเวอร์สร้างอินพุต+เอาต์พุตก่อนหน้ากลับมาเป็นคอนเท็กซ์ เพื่อรองรับ การสนทนาต่อเนื่อง/ลดการส่งซ้ำให้น้อยที่สุด และเลือกได้ผ่าน truncation ว่า “อนุญาตให้ตัด” หรือ “ล้มเหลวเมื่อเกินขนาด”
- ส่วนขยายที่อยู่นอกมาตรฐานจะแยกด้วยคำนำหน้า
provider_slug: และ hosted tool แบบกำหนดเองจะต้องมี ชนิด item ที่สอดคล้องกัน เพื่อทิ้ง “หลักฐาน” ที่สามารถบันทึกล็อกและทำ round-trip ได้
- ข้อผิดพลาดจะถูกส่งกลับเป็น error object แบบมีโครงสร้าง และข้อผิดพลาดระหว่างสตรีมมิงจะจบด้วยอีเวนต์
response.failed
1 ความคิดเห็น
โอ้... ผมก็มีอะไรที่กำลังทำอยู่เหมือนกัน แบบนี้คงต้องเอาสิ่งนี้มาเป็นกรอบแล้วล่ะ