Open Responses คืออะไร

Open Responses เป็นข้อกำหนดแบบเปิดที่เผยแพร่ในรูปแบบเอกสาร OpenAPI 3.1 ซึ่งอธิบายรูปแบบคำขอและการตอบกลับชุดเดียวสำหรับการเรียกใช้โมเดลภาษาผ่านผู้ให้บริการต่างๆ โดยอ้างอิงจาก OpenAI Responses API: คุณส่ง model, input และ tools (ซึ่งเป็นทางเลือก) ไปยัง POST /v1/responses แล้วคุณจะได้ไอเท็มที่มีการระบุชนิด (typed items) และเหตุการณ์สตรีมมิ่งเชิงความหมาย (semantic streaming events) กลับมา แทนที่จะเป็นรูปแบบเฉพาะของผู้ให้บริการรายนั้น OpenAI เปิดตัว Open Responses เมื่อ 2026-01-15 อยู่ภายใต้สัญญาอนุญาต Apache 2.0 และเมื่อ 2026-10-22 OpenAI ได้มอบข้อกำหนดนี้ให้แก่ Agentic AI Foundation (AAIF) ซึ่งเป็นองค์กรภายใต้ Linux Foundation ที่ดูแล MCP เช่นกัน

ขั้นตอนสุดท้ายนั่นคือข่าว: ตอนนี้ข้อกำหนดนี้มีกฎบัตรทางเทคนิค มีคณะกรรมการกำกับดูแล และมีบ้านที่เป็นกลาง บทความนี้ครอบคลุมว่าข้อกำหนดนิยามอะไรบ้าง ใครนำไปใช้งาน การย้ายไป AAIF เปลี่ยนอะไร และจะตรวจสอบได้อย่างไรว่า endpoint ที่คุณพึ่งพานั้นสอดคล้องกับข้อกำหนดหรือไม่ หากคุณเพิ่งเริ่มรู้จัก API ที่เป็นพื้นฐาน ควรเริ่มจาก วิธีใช้ OpenAI Responses API

Open Responses นิยามอะไรบ้าง

ข้อกำหนดนี้อธิบายปัญหาอย่างตรงไปตรงมา: ผู้ให้บริการต่างๆ ต่างก็ converged มาที่องค์ประกอบพื้นฐานเดียวกัน (ข้อความ การเรียกใช้เครื่องมือ การสตรีมมิ่ง อินพุตแบบหลายรูปแบบ) แต่แต่ละรายเข้ารหัสองค์ประกอบเหล่านั้นต่างกัน Open Responses จึงเลือกการเข้ารหัสแบบเดียวและเขียนมันลงไปให้ชัดเจน

เอกสาร OpenAPI ปัจจุบันเป็นเวอร์ชัน 2026-04-24 และครอบคลุมพื้นที่เพียงเล็กน้อย:

การดำเนินการ	สิ่งที่ทำ
`POST /responses` (`createResponse`)	สร้างการตอบกลับ จะสตรีมมิ่งหรือไม่ก็ได้
WebSocket บน `/responses`	โมเดลการตอบกลับเดียวกันผ่านซ็อกเก็ตที่คงอยู่ต่อเนื่อง (เพิ่มเมื่อ 2026-04-24)
`POST /responses/compact` (`compactResponse`)	คืนหน้าต่างอินพุตแบบย่อสำหรับบทสนทนายาวๆ

บอดี้ของคำขอรองรับฟิลด์ที่คุณคาดว่าจะมีหากเคยใช้ API ของ OpenAI: model, input, instructions, tools, tool_choice, stream, store, previous_response_id, reasoning, text, truncation, temperature, top_p, max_output_tokens, prompt_cache_key และอีกเล็กน้อย ออบเจ็กต์การตอบกลับ (ResponseResource) มี id, status, output, usage, error และการสะท้อนค่าตั้งค่าที่คุณส่งไป เอกสารนี้กำหนดสคีมาไว้ทั้งหมด 108 รายการ โดยส่วนใหญ่เป็นชนิดของไอเท็มและเหตุการณ์สตรีมมิ่ง

มีแนวคิดสามข้อที่เป็นแกนของการออกแบบนี้

ไอเท็มคือหน่วยของบริบท

ทุกสิ่งที่โมเดลอ่านหรือสร้างขึ้นล้วนเป็นไอเท็ม: message, function_call, function_call_output, ไอเท็ม reasoning ไอเท็มมีทิศทางสองทาง (bidirectional) ดังนั้นเอาต์พุตของเทิร์นหนึ่งสามารถป้อนกลับเป็นอินพุตของเทิร์นถัดไปได้เลย ไอเท็มแต่ละชนิดแยกแยะด้วยฟิลด์ type ของตัวเองและมีสคีมาเป็นของตัวเอง

ไอเท็มยังเป็นสเตตแมชชีนด้วย: แต่ละไอเท็มจะเปลี่ยนจาก in_progress ไปเป็น completed หรือ incomplete (เมื่องบโทเค็นหมด) และไอเท็มที่เป็น incomplete ต้องเป็นไอเท็มสุดท้ายที่ถูกส่งออก โดยทั้งการตอบกลับจะถูกทำเครื่องหมายว่า incomplete สถานะไม่ได้บอกอะไรว่าฝั่งเซิร์ฟเวอร์ได้จัดเก็บไอเท็มนั้นไว้หรือไม่ การจัดเก็บถาวรเป็นเรื่องแยกต่างหาก

การสตรีมมิ่งคือเหตุการณ์เชิงความหมาย ไม่ใช่ delta ดิบ

เมื่อคุณตั้งค่า stream: true เซิร์ฟเวอร์ต้องตอบกลับด้วย Content-Type: text/event-stream และลำดับเหตุการณ์ที่กำหนดไว้ ไอเท็มเอาต์พุตจะเปิดด้วย response.output_item.added ข้อความภายในจะมาในรูปของ response.content_part.added ตามด้วยเหตุการณ์ response.output_text.delta ที่เกิดซ้ำหลายครั้ง จากนั้น response.output_text.done และ response.content_part.done ไอเท็มจะปิดด้วย response.output_item.done สตรีมต้องจบด้วยเหตุการณ์สิ้นสุด: response.completed, response.failed หรือ response.incomplete การมี [DONE] ต่อท้ายเป็นทางเลือก และไคลเอนต์ต้องรองรับสตรีมที่จบโดยไม่มี它也ได้

Diagram of the Open Responses streaming event order: output_item.added, content_part.added, output_text.delta repeated, output_text.done, content_part.done, output_item.done, then a terminal completed, failed or incomplete event

เรื่องนี้สำคัญที่สุดสำหรับโค้ดฝั่งไคลเอนต์: หากผู้ให้บริการสองรายส่งเหตุการณ์เดียวกันในลำดับเดียวกัน ตัวแยกวิเคราะห์ SSE ตัวเดียวก็ใช้ได้กับทั้งสองราย คู่มือการทดสอบ SSE ของเราแสดงวิธีตรวจสอบสตรีมเหล่านี้ทีละเหตุการณ์

แกนหลักที่เสถียรพร้อมส่วนขยายที่แยกเนมสเปซ

ผู้ให้บริการสามารถเพิ่มชนิดไอเท็ม เครื่องมือ และเหตุการณ์สตรีมมิ่งของตัวเองได้ แต่ต้องใส่คำนำหน้าเป็น slug ของผู้ให้บริการนั้น ตัวอย่างในข้อกำหนดเองคือ openai:web_search_call ไคลเอนต์ที่ไม่รู้จักชนิดที่มีคำนำหน้าสามารถข้ามมันไปได้โดยไม่เกิดข้อผิดพลาด นี่คือวิธีที่ทำให้ข้อกำหนดนี้ยังคงพกพาได้ ในขณะที่เครื่องมือที่โฮสต์ไว้ เช่น web search หรือ file search ยังคงเป็นฟีเจอร์เฉพาะของผู้ให้บริการ

ส่วนที่เหลือของสัญญา

มีกฎอีกสองสามข้อที่ควรรู้ก่อนสร้างงานบนข้อกำหนดนี้:

เครื่องมือสองประเภท เครื่องมือที่โฮสต์ภายนอก (ฟังก์ชัน, เซิร์ฟเวอร์ MCP) ทำงานนอกผู้ให้บริการ สำหรับฟังก์ชัน โมเดลจะส่ง function_call ออกมา คุณเป็นคนรันมัน แล้วส่ง function_call_output กลับไปพร้อม call_id ที่ตรงกัน ส่วนเครื่องมือที่โฮสต์ภายใน (เช่น file search ของ OpenAI) ทำงานภายในผู้ให้บริการโดยไม่คืนการควบคุมกลับมา
tool_choice และ allowed_tools tool_choice รับค่า auto (ค่าเริ่มต้น), required, none หรือออบเจ็กต์ที่ระบุชื่อฟังก์ชันหนึ่งรายการ allowed_tools จำกัดว่าโมเดลเรียกใช้เครื่องมือใดได้บ้างในขณะที่ยังแสดงเครื่องมือทั้งหมดอยู่ เพื่อไม่ให้แคชพรอมป์ตกลายเป็นโมฆะจากการแก้ไขอาร์เรย์ tools เซิร์ฟเวอร์ต้องบังคับใช้มันเป็นขีดจำกัดแบบเด็ดขาด
previous_response_id เซิร์ฟเวอร์ต้องถือว่าคำขอใหม่คือ previous_response.input + previous_response.output + input ตามลำดับนั้น เพื่อให้คุณไม่ต้องส่งบทสนทนาทั้งหมดซ้ำ
ไอเท็ม reasoning อาจมี content ดิบ, บล็อบ encrypted_content ที่อ่านไม่ได้, summary ที่ปลอดภัยสำหรับผู้ใช้ หรือผสมกันแบบใดก็ได้
ข้อผิดพลาด มี type (server_error, invalid_request, not_found, model_error, too_many_requests) พร้อมด้วย code, param และ message ระหว่างสตรีม ข้อผิดพลาดจะตามมาด้วย response.failed

การแก้ไขปรับปรุงเมื่อ 2026-04-24 (changelog) ได้เพิ่มการรับส่งผ่าน WebSocket: แต่ละเทิร์นเริ่มด้วยข้อความ response.create หนึ่งการเชื่อมต่อประมวลผลการตอบกลับได้ครั้งละหนึ่งรายการ การเชื่อมต่อถูกจำกัดไว้ที่ 60 นาที (รหัสข้อผิดพลาด websocket_connection_limit_reached) และการต่อเนื่องที่ใช้ store: false จะอยู่ในหน่วยความจำเฉพาะการเชื่อมต่อนั้น ซึ่งจะล้มเหลวด้วย previous_response_not_found เมื่อสถานะนั้นหายไปแล้ว การแก้ไขปรับปรุงครั้งเดียวกันยังได้เพิ่ม /responses/compact ฟิลด์ phase แบบทางเลือกบนข้อความของผู้ช่วย (commentary หรือ final_answer) และทำให้ logprobs เป็นทางเลือก

Open Responses กับ Chat Completions

Chat Completions ยังคงเป็นอินเทอร์เฟซ LLM ที่ถูกนำไปลอกเลียนแบบมากที่สุด ความต่างอยู่ที่รูปร่าง: Chat Completions คืนค่า choices ที่ภายในบรรจุข้อความ โดยมีการเรียกใช้เครื่องมือซ่อนอยู่ภายในนั้น ขณะที่โมเดล Responses คืนค่ารายการแบนของไอเท็มที่มีการระบุชนิด ขั้นตอนการคิด (reasoning) การเรียกใช้เครื่องมือสามครั้ง และข้อความสุดท้ายจะกลายเป็นออบเจ็กต์แยกกันที่เรียงลำดับและมีสถานะของตัวเอง ซึ่งเข้ากับลูปของเอเจนต์ได้ดีกว่า

Side-by-side diagram: Chat Completions nests content and three tool_calls inside choices[0].message, while Open Responses returns a flat output list of reasoning, three function_call items and a message, each with a status

เราได้เปรียบเทียบสามรูปแบบที่โดดเด่นแบบเคียงข้างกัน พร้อมคำขอจริง ในบทความ Chat Completions กับ Anthropic Messages กับ Responses API หากคุณกำลังเลือกระหว่างพื้นผิว API ของ OpenAI เอง บทวิเคราะห์ Agents API กับ Responses API กับ Agents SDK ครอบคลุมว่า Responses อยู่ตรงไหน

ใครนำไปใช้งาน

รายชื่อผู้สนับสนุนประกอบด้วย AWS Bedrock, Databricks, Hugging Face, LM Studio, Nvidia, Ollama, OpenRouter, Red Hat, Vercel และ vLLM ควบคู่กับ OpenAI ส่วน Anthropic และ Google ไม่ได้อยู่ในรายชื่อผู้สนับสนุนที่ระบุชื่อไว้ ทั้งสองรายยังคงส่งมอบรูปแบบเนทีฟของตัวเอง

คำว่า "สนับสนุน" ครอบคลุมความหมายได้กว้างมาก ดังนั้นควรตรวจสอบรายละเอียดของรันไทม์ที่คุณใช้:

Ollama เพิ่ม POST /v1/responses ใน v0.13.3 เอกสารความเข้ากันได้ของมันระบุว่า "รองรับเฉพาะแบบไม่เก็บสถานะ (non-stateful)" เท่านั้น: การสตรีมมิ่ง เครื่องมือฟังก์ชัน และสรุป reasoning ใช้ได้ แต่ previous_response_id, conversation และ truncation ใช้ไม่ได้ คุณต้องส่งประวัติซ้ำเอง
LM Studio ทำให้ endpoint http://localhost:1234/v1/responses ของตนเข้ากันได้ในเวอร์ชัน 0.3.39 รวมถึง previous_response_id, URL รูปภาพระยะไกลสำหรับโมเดลที่มองเห็นภาพ และ logprobs ดู คู่มือ LM Studio ของเราเพื่อการตั้งค่า

เพื่อให้เห็นขนาดของเรื่องนี้ API Evangelist ได้ทำการวัดค่าพื้นฐานเมื่อวันที่ 13 กันยายน: จากผู้ให้บริการ 120 รายที่อ้างว่าสามารถใช้แทน OpenAI ได้และเผยแพร่เอกสาร OpenAPI ที่อ่านได้ มี 26 รายที่ประกาศ POST /responses เทียบกับ 105 รายที่ประกาศ POST /chat/completions จุดประสงค์ของการวัดค่าพื้นฐานนี้คือเพื่อวัดว่าการกำกับดูแลแบบเป็นกลางจะทำให้ตัวเลขนั้นเปลี่ยนไปหรือไม่

การย้ายไป Agentic AI Foundation เปลี่ยนอะไร

AAIF ประกาศเรื่อง Open Responses เมื่อ 2026-10-22 ที่งาน AGNTCon + MCPCon North America ในซานโฮเซ พร้อมกับอีกสามโปรเจ็กต์ใหม่ ได้แก่ Agent Skills (จาก Anthropic), OpenEnv (จาก Hugging Face) และ OpenSandbox (จาก Alibaba) นั่นทำให้ AAIF มีโปรเจ็กต์ที่โฮสต์ไว้ทั้งหมด 10 โปรเจ็กต์ในปีแรก เคียงคู่กับ MCP, โปรโตคอล Agent2Agent, AGENTS.md, goose, agentgateway และ Agent Router หากคุณกำลังพยายามทำความเข้าใจว่าสิ่งเหล่านี้เชื่อมโยงกันอย่างไร บทอธิบาย MCP กับ A2A ของเราเป็นจุดเริ่มต้นที่ดี

สิ่งที่เปลี่ยนไป:

การกำกับดูแล ตอนนี้โปรเจ็กต์นี้มีชื่อว่า "Open Responses a Series of LF Projects, LLC" พร้อมกฎบัตรทางเทคนิคที่รับรองเมื่อ 2026-10-21 คณะกรรมการกำกับดูแลทางเทคนิค (Technical Steering Committee) ซึ่งเริ่มต้นจากผู้ดูแลโปรเจ็กต์ เป็นผู้ตัดสินใจเรื่องเทคนิค และการมีส่วนร่วมเปิดกว้างสำหรับทุกคนที่ปฏิบัติตามกฎบัตร
ความน่าเชื่อถือสำหรับผู้จำหน่ายรายอื่น ข้อกำหนดที่เป็นของบริษัทใดบริษัทหนึ่งก็คือผลิตภัณฑ์ แต่ข้อกำหนดที่อยู่ภายใต้มูลนิธิย่อมทำให้คู่แข่งนำไปใช้ได้ง่ายกว่าโดยไม่ดูเหมือนกำลังทำตามคู่แข่ง

สิ่งที่ยังไม่เปลี่ยน:

API ของ OpenAI เอง Responses API บน api.openai.com ยังคงมีฟีเจอร์และตารางการออกรุ่นของตัวเอง Open Responses อธิบายแกนหลักที่พกพาได้ ส่วนเครื่องมือเฉพาะของ OpenAI ยังคงอยู่หลังคำนำหน้า openai:
รูปแบบการรับส่งข้อมูล (wire format) ไม่มีเวอร์ชันข้อกำหนดใหม่มาพร้อมกับการย้ายครั้งนี้ รุ่นล่าสุดยังคงเป็น 2026-04-24 และรุ่นที่มีการลงวันที่จะไม่ถูกแก้ไข
ความสอดคล้อง การอยู่ในรายชื่อผู้สนับสนุนไม่ได้หมายความว่า endpoint จะผ่านการทดสอบ ยังไม่มีใครเผยแพร่ดัชนีผ่าน/ไม่ผ่าน ดังนั้นคุณต้องตรวจสอบ endpoint ที่คุณพึ่งพาด้วยตัวเอง

ตรวจสอบ endpoint ด้วยชุดทดสอบการยอมรับ

โปรเจ็กต์นี้มีชุดทดสอบการยอมรับ (acceptance tests) ของตัวเอง หน้าความสอดคล้องรันการทดสอบ 10 รายการในเบราว์เซอร์กับ base URL, โมเดล และคีย์ใดก็ได้: การตอบกลับข้อความพื้นฐาน, การสตรีมมิ่ง, system prompt, การเรียกใช้เครื่องมือ, อินพุตรูปภาพ, ประวัติแบบหลายเทิร์น, ป้ายกำกับ phase ของผู้ช่วย, endpoint การย่อข้อมูล และการทดสอบเชิงลบสำหรับคำขอย่อที่ขาด model นอกจากนี้ยังมีการทดสอบ WebSocket อีกเจ็ดรายการ (เทิร์นต่อเนื่อง, การต่อเนื่องที่ใช้ store: false, การกู้คืนหลังการเชื่อมต่อใหม่, การล้างแคชหลังการต่อเนื่องที่ล้มเหลว) ซึ่งรันได้เฉพาะจาก CLI เท่านั้น:

git clone https://github.com/openresponses/openresponses
cd openresponses && bun install
bun run test:compliance --base-url http://localhost:11434/v1 --api-key ollama

คำขอ HTTP แต่ละครั้งและเทิร์น WebSocket แต่ละเทิร์นมีกำหนดเวลา 30 วินาที และการหมดเวลาจะทำให้เฉพาะการทดสอบนั้นล้มเหลว ให้คาดว่ารันไทม์แบบไม่เก็บสถานะอย่าง Ollama จะล้มเหลวในการทดสอบการต่อเนื่องตามการออกแบบ

ให้เอเจนต์เขียนโค้ดของคุณทดสอบด้วย Apidog CLI

ชุดทดสอบการยอมรับบอกคุณว่าเซิร์ฟเวอร์ปฏิบัติตามข้อกำหนดในปัจจุบันหรือไม่ แต่ไม่ได้เฝ้าดู endpoint ที่แอปของคุณเรียกทุกครั้งที่คุณดีพลอย อัปเกรด Ollama หรือสลับผู้ให้บริการ สำหรับเรื่องนั้น ให้ import ข้อกำหนดนี้เข้าโปรเจ็กต์ Apidog แล้วให้เอเจนต์เขียนโค้ดของคุณเขียนและรันการทดสอบรีเกรสชันกับมันด้วย Apidog CLI

ติดตั้ง CLI และสกิลของเอเจนต์เพียงครั้งเดียว:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

จากนั้นมอบพรอมป์หนึ่งข้อให้ Claude Code, Codex หรือ Cursor:

Download https://www.openresponses.org/openapi/openapi.json and import it into
Apidog project <id>. Create an environment "local-ollama" with base URL
http://localhost:11434/v1. Add test cases for POST /responses: one that expects 200,
status "completed" and an output item of type "message"; one with stream: true that
expects text/event-stream ending in response.completed; one without "model" that
expects a 4xx error with an error.type field. Run them and summarize any failures.

เอเจนต์จะอ่านสคีมา ตรวจสอบความถูกต้องของเพย์โหลดก่อนเขียนอะไรลงไป แล้วรันเคสต่างๆ:

curl -sLO https://www.openresponses.org/openapi/openapi.json
apidog import --project <id> --format openapi --file ./openapi.json
apidog environment create local-ollama --project <id> --base-url http://localhost:11434/v1
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> -r cli,json

รายการ servers ในข้อกำหนดชี้ไปที่ https://api.openai.com/v1 ดังนั้นให้เพิ่มหนึ่ง environment ต่อผู้ให้บริการหนึ่งราย แล้วรันเคสเดียวกันกับแต่ละราย นั่นคือข้ออ้างเรื่องการพกพาที่ถูกนำมาทดสอบจริง ใส่บรรทัด apidog run ... -r junit ลงในไปป์ไลน์ของคุณ เพื่อให้การอัปเกรดรันไทม์ที่ทำให้ฟิลด์หนึ่งหายไปทำให้บิลด์ล้มเหลว (คู่มือ CI/CD) ส่วน Apidog CLI ใน Claude Code ครอบคลุมการตั้งค่าเอเจนต์อย่างละเอียด

คำถามที่พบบ่อย

Open Responses เหมือนกับ OpenAI Responses API หรือไม่? ไม่ Open Responses เป็นข้อกำหนดที่พัฒนามาจากมัน Responses API ของ OpenAI เป็นการนำไปใช้งานหนึ่งรูปแบบที่มีฟีเจอร์พิเศษเฉพาะ OpenAI ส่วน Ollama, LM Studio และ vLLM เป็นอีกรูปแบบหนึ่ง

ตอนนี้ใครเป็นเจ้าของ Open Responses? ตั้งแต่ 2026-10-22 มันเป็นโปรเจ็กต์ของ Agentic AI Foundation ภายใต้ Linux Foundation ดำเนินงานในรูปแบบชุดโปรเจ็กต์ LF พร้อมคณะกรรมการกำกับดูแลทางเทคนิค อยู่ภายใต้สัญญาอนุญาต Apache 2.0

Anthropic สนับสนุน Open Responses หรือไม่? Anthropic ไม่ได้อยู่ในรายชื่อผู้สนับสนุนที่ระบุไว้ วันเดียวกันนั้นทาง Anthropic ได้มอบ Agent Skills ให้แก่ AAIF แต่อินเทอร์เฟซเนทีฟของ Claude ยังคงเป็น Messages API

ไฟล์ข้อกำหนดอยู่ที่ไหน? อยู่ที่ https://www.openresponses.org/openapi/openapi.json โดยมีรุ่นที่ลงวันที่อยู่ในที่เก็บ GitHub

ขั้นตอนถัดไป

เลือก endpoint เดียวที่ผลิตภัณฑ์ของคุณเรียกบ่อยที่สุด รันชุดทดสอบการยอมรับในเบราว์เซอร์กับมัน แล้ว import ข้อกำหนดเข้า Apidog เพื่อให้เอเจนต์ของคุณคอยรันการตรวจสอบเหล่านั้นในทุกการดีพลอย ดาวน์โหลด Apidog เพื่อเริ่มต้น