Open Responses là gì?

Open Responses là một đặc tả mở, được công bố dưới dạng tài liệu OpenAPI 3.1, mô tả một hình dạng yêu cầu và phản hồi duy nhất để gọi các mô hình ngôn ngữ trên nhiều nhà cung cấp. Nó dựa trên OpenAI Responses API: bạn gửi model, input và tools tùy chọn tới POST /v1/responses, và bạn nhận lại các item có kiểu và các sự kiện streaming ngữ nghĩa thay vì một định dạng riêng của nhà cung cấp. OpenAI ra mắt Open Responses vào 2026-01-15, nó được cấp phép theo Apache 2.0, và vào 2026-10-22 OpenAI đã đóng góp nó cho Agentic AI Foundation (AAIF), tổ chức thuộc Linux Foundation cũng đang vận hành MCP.

Dùng thử Apidog ngay hôm nay

Bước cuối cùng đó chính là tin tức: đặc tả giờ đây đã có một hiến chương kỹ thuật, một ủy ban chỉ đạo và một ngôi nhà trung lập. Bài viết này đề cập đến những gì nó định nghĩa, ai triển khai nó, việc chuyển sang AAIF thay đổi điều gì, và cách kiểm tra xem một endpoint mà bạn phụ thuộc có tuân thủ hay không. Nếu bạn mới làm quen với API nền tảng, hãy bắt đầu với cách sử dụng OpenAI Responses API.

Open Responses định nghĩa những gì

Đặc tả mô tả vấn đề một cách rõ ràng: các nhà cung cấp đã hội tụ về cùng những khối xây dựng (tin nhắn, lệnh gọi công cụ, streaming, đầu vào đa phương thức) nhưng mỗi bên mã hóa chúng theo cách khác nhau. Open Responses chọn một cách mã hóa và ghi nó ra.

Tài liệu OpenAPI hiện tại là phiên bản 2026-04-24 và bao phủ một bề mặt nhỏ:

Thao tác	Chức năng
POST /responses (createResponse)	Tạo một phản hồi, có hoặc không streaming
WebSocket trên /responses	Cùng mô hình phản hồi qua một socket liên tục (thêm vào 2026-04-24)
POST /responses/compact (compactResponse)	Trả về một cửa sổ đầu vào đã nén cho các cuộc hội thoại dài

Phần thân yêu cầu chấp nhận các trường mà bạn sẽ mong đợi nếu đã từng dùng API của OpenAI: model, input, instructions, tools, tool_choice, stream, store, previous_response_id, reasoning, text, truncation, temperature, top_p, max_output_tokens, prompt_cache_key và một vài trường khác. Đối tượng phản hồi (ResponseResource) mang id, status, output, usage, error và một bản sao của các thiết lập bạn đã gửi. Tài liệu định nghĩa tổng cộng 108 schema, hầu hết là các kiểu item và sự kiện streaming.

Ba ý tưởng mang thiết kế này.

Item là đơn vị ngữ cảnh

Mọi thứ mô hình đọc hoặc tạo ra đều là một item: một message, một function_call, một function_call_output, một item reasoning. Các item có tính hai chiều, vì vậy đầu ra của một lượt có thể được đưa thẳng trở lại làm đầu vào cho lượt tiếp theo. Mỗi kiểu item được phân biệt bởi trường type của nó và có schema riêng.

Các item cũng là máy trạng thái: mỗi item chuyển từ in_progress sang completed hoặc incomplete (ngân sách token đã cạn), và một item incomplete phải là item cuối cùng được phát ra, với toàn bộ phản hồi được đánh dấu là incomplete. Trạng thái không nói lên điều gì về việc máy chủ có lưu trữ item hay không; việc lưu trữ là một mối quan tâm riêng.

Streaming là các sự kiện ngữ nghĩa, không phải các delta thô

Khi bạn đặt stream: true, máy chủ phải trả lời với Content-Type: text/event-stream và một chuỗi sự kiện được định nghĩa. Một item đầu ra mở đầu bằng response.output_item.added; văn bản bên trong nó đến dưới dạng response.content_part.added, sau đó là các sự kiện response.output_text.delta lặp lại, rồi response.output_text.done và response.content_part.done; item kết thúc bằng response.output_item.done. Luồng phải kết thúc bằng một sự kiện kết thúc: response.completed, response.failed hoặc response.incomplete. Một [DONE] ở cuối là tùy chọn, và các client phải xử lý được một luồng kết thúc mà không có nó.

Điều này quan trọng nhất đối với mã client: nếu hai nhà cung cấp phát ra cùng các sự kiện theo cùng thứ tự, một bộ phân tích SSE sẽ hoạt động cho cả hai. Hướng dẫn kiểm thử SSE của chúng tôi chỉ cách kiểm tra các luồng này theo từng sự kiện.

Một lõi ổn định với các phần mở rộng có không gian tên

Các nhà cung cấp có thể thêm các kiểu item, công cụ và sự kiện streaming của riêng họ, nhưng họ phải thêm tiền tố là một slug của nhà cung cấp. Ví dụ của chính đặc tả là openai:web_search_call. Một client không nhận ra một kiểu có tiền tố có thể bỏ qua nó mà không bị lỗi. Đây là cách đặc tả giữ được tính di động trong khi các công cụ được lưu trữ như tìm kiếm web hay tìm kiếm tệp vẫn là các tính năng của nhà cung cấp.

Phần còn lại của hợp đồng

Một vài quy tắc nữa đáng để biết trước khi bạn xây dựng dựa trên đặc tả:

• Hai loại công cụ. Các công cụ được lưu trữ bên ngoài (hàm, máy chủ MCP) chạy bên ngoài nhà cung cấp; đối với hàm, mô hình phát ra một function_call, bạn chạy nó, và bạn gửi lại một function_call_output với call_id khớp. Các công cụ được lưu trữ bên trong (ví dụ tìm kiếm tệp của OpenAI) chạy bên trong nhà cung cấp mà không trao lại quyền điều khiển.
• tool_choice và allowed_tools. tool_choice nhận auto (mặc định), required, none, hoặc một đối tượng nêu tên một hàm. allowed_tools giới hạn những công cụ mà mô hình có thể gọi trong khi vẫn hiển thị tất cả chúng, để bạn không làm mất hiệu lực một prompt đã được lưu trong bộ nhớ đệm bằng cách sửa mảng tools. Máy chủ phải thực thi nó như một giới hạn cứng.
• previous_response_id. Máy chủ phải xử lý yêu cầu mới như previous_response.input + previous_response.output + input, theo thứ tự đó, để bạn không phải gửi lại bản ghi hội thoại.
• Các item reasoning có thể mang content thô, một blob encrypted_content không rõ ràng, một summary an toàn cho người dùng, hoặc bất kỳ sự kết hợp nào.
• Lỗi mang một type (server_error, invalid_request, not_found, model_error, too_many_requests), cùng với code, param và message; giữa luồng, một lỗi được theo sau bởi response.failed.

Bản sửa đổi 2026-04-24 (changelog) đã thêm giao thức truyền tải WebSocket: mỗi lượt bắt đầu bằng một thông điệp response.create, một kết nối xử lý một phản hồi tại một thời điểm, các kết nối bị giới hạn ở 60 phút (mã lỗi websocket_connection_limit_reached), và các phần tiếp nối store: false sống trong bộ nhớ cục bộ của kết nối, thất bại với previous_response_not_found một khi trạng thái đó không còn. Cùng bản sửa đổi đã thêm /responses/compact, một trường phase tùy chọn trên các tin nhắn assistant (commentary hoặc final_answer), và làm cho logprobs trở thành tùy chọn.

Open Responses so với Chat Completions

Chat Completions vẫn là giao diện LLM được sao chép rộng rãi nhất. Sự khác biệt nằm ở hình dạng: Chat Completions trả về các choice chứa một message, với các lệnh gọi công cụ được nhét bên trong nó, trong khi mô hình Responses trả về một danh sách phẳng các item có kiểu. Một bước reasoning, ba lệnh gọi công cụ và một tin nhắn cuối trở thành các đối tượng riêng biệt, có thứ tự với trạng thái riêng của chúng, điều này phù hợp hơn với các vòng lặp agent.

Chúng tôi đã so sánh ba định dạng thống trị cạnh nhau, với các yêu cầu thực tế, trong Chat Completions vs Anthropic Messages vs Responses API. Nếu bạn đang chọn giữa các bề mặt của chính OpenAI, bài phân tích Agents API vs Responses API vs Agents SDK đề cập đến vị trí của Responses.

Ai triển khai nó

Danh sách người ủng hộ bao gồm AWS Bedrock, Databricks, Hugging Face, LM Studio, Nvidia, Ollama, OpenRouter, Red Hat, Vercel và vLLM, cùng với OpenAI. Anthropic và Google không nằm trong số những người ủng hộ được nêu tên; cả hai vẫn phát hành các định dạng gốc của riêng họ.

“Hỗ trợ” bao hàm một phạm vi rộng, vì vậy hãy kiểm tra chi tiết cho runtime bạn sử dụng:

• Ollama đã thêm POST /v1/responses trong v0.13.3. Tài liệu tương thích của nó nói rằng “chỉ phiên bản không trạng thái được hỗ trợ”: streaming, công cụ hàm và tóm tắt reasoning hoạt động, nhưng previous_response_id, conversation và truncation thì không. Bạn tự gửi lại lịch sử.
• LM Studio đã làm cho endpoint http://localhost:1234/v1/responses của nó tương thích trong phiên bản 0.3.39, bao gồm previous_response_id, URL hình ảnh từ xa cho các mô hình thị giác và logprobs. Xem hướng dẫn LM Studio của chúng tôi để biết cách thiết lập.

Để có một cảm nhận về quy mô, API Evangelist đã lấy một đường cơ sở vào ngày 13 tháng 9: trong số 120 nhà cung cấp tuyên bố tương thích OpenAI mà công bố một tài liệu OpenAPI có thể đọc được, 26 nhà cung cấp khai báo POST /responses, so với 105 nhà cung cấp khai báo POST /chat/completions. Mục đích của đường cơ sở là đo xem liệu quản trị trung lập có làm thay đổi con số đó hay không.

Việc chuyển sang Agentic AI Foundation thay đổi điều gì

AAIF đã công bố Open Responses vào 2026-10-22 tại AGNTCon + MCPCon North America ở San Jose, cùng với ba dự án mới khác: Agent Skills (từ Anthropic), OpenEnv (từ Hugging Face) và OpenSandbox (từ Alibaba). Điều đó đưa AAIF lên 10 dự án được lưu trữ trong năm đầu tiên, bên cạnh MCP, giao thức Agent2Agent, AGENTS.md, goose, agentgateway và Agent Router. Nếu bạn đang tìm hiểu cách những thứ đó khớp với nhau, bài giải thích MCP vs A2A của chúng tôi là một khởi đầu tốt.

Những gì thay đổi:

• Quản trị. Dự án hiện là “Open Responses a Series of LF Projects, LLC,” với một hiến chương kỹ thuật được thông qua vào 2026-10-21. Một Ủy ban Chỉ đạo Kỹ thuật, ban đầu là những người duy trì dự án, sở hữu các quyết định kỹ thuật, và việc tham gia mở cho bất kỳ ai tuân theo hiến chương.
• Uy tín cho các nhà cung cấp khác. Một đặc tả do một công ty sở hữu là một sản phẩm. Một đặc tả dưới một quỹ dễ dàng hơn để một đối thủ áp dụng mà không trông giống như đang đi theo một đối thủ.

Những gì không thay đổi:

• API của chính OpenAI. Responses API trên api.openai.com giữ các tính năng và lịch phát hành riêng của nó. Open Responses mô tả lõi di động; các công cụ dành riêng cho OpenAI vẫn nằm sau tiền tố openai:.
• Định dạng truyền tải. Không có phiên bản đặc tả mới nào đi kèm với việc chuyển đổi. Bản phát hành mới nhất vẫn là 2026-04-24, và các bản phát hành có ngày tháng là bất biến.
• Tuân thủ. Nằm trong danh sách người ủng hộ không có nghĩa là một endpoint vượt qua các bài kiểm tra. Chưa ai công bố một chỉ mục đạt/không đạt, vì vậy bạn tự kiểm tra các endpoint mà bạn phụ thuộc.

Kiểm tra một endpoint bằng các bài kiểm tra chấp nhận

Dự án cung cấp các bài kiểm tra chấp nhận của riêng nó. Trang tuân thủ chạy 10 bài kiểm tra trong trình duyệt đối với bất kỳ base URL, model và key nào: phản hồi văn bản cơ bản, streaming, system prompt, gọi công cụ, đầu vào hình ảnh, lịch sử nhiều lượt, nhãn phase của assistant, endpoint nén và một bài kiểm tra phủ định cho một yêu cầu nén thiếu model. Bảy bài kiểm tra WebSocket nữa (các lượt tuần tự, tiếp nối store: false, phục hồi khi kết nối lại, xóa bộ nhớ đệm sau một lần tiếp nối thất bại) chỉ chạy từ 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

Mỗi yêu cầu HTTP và mỗi lượt WebSocket có thời hạn 30 giây, và một lần hết thời gian chỉ làm thất bại bài kiểm tra đó. Hãy mong đợi một runtime không trạng thái như Ollama sẽ thất bại các bài kiểm tra tiếp nối theo thiết kế.

Để agent lập trình của bạn kiểm tra nó với Apidog CLI

Các bài kiểm tra chấp nhận cho bạn biết liệu một máy chủ có tuân theo đặc tả ngay hôm nay hay không. Chúng không theo dõi endpoint mà ứng dụng của bạn gọi mỗi khi bạn triển khai, nâng cấp Ollama hoặc chuyển nhà cung cấp. Để làm điều đó, hãy nhập đặc tả vào một dự án Apidog và để agent lập trình của bạn viết và chạy các bài kiểm tra hồi quy đối với nó bằng Apidog CLI.

Cài đặt CLI và skill cho agent một lần:

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

Sau đó đưa cho Claude Code, Codex hoặc Cursor một [REDACTED PROMPT]
Download https://www.openresponses.org/openapi/openapi.json and import it into
Apidog project . 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.

Agent đọc các schema, xác thực payload của nó trước khi viết bất cứ thứ gì, và chạy các case:

bash
curl -sLO https://www.openresponses.org/openapi/openapi.json
apidog import --project --format openapi --file ./openapi.json
apidog environment create local-ollama --project --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 --file case.json
apidog run --test-case --project -e -r cli,json

Mục `servers` của đặc tả trỏ tới `https://api.openai.com/v1`, vì vậy hãy thêm một môi trường cho mỗi nhà cung cấp và chạy cùng các case đối với từng môi trường: đó chính là tuyên bố về tính di động, được kiểm chứng. Đặt dòng `apidog run ... -r junit` vào pipeline của bạn để một bản nâng cấp runtime làm mất một trường sẽ làm hỏng bản build ([hướng dẫn CI/CD](https://apidog.com/vi/blog/apidog-cli-ci-cd-pipeline?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation)); [Apidog CLI trong Claude Code](https://apidog.com/vi/blog/apidog-cli-in-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) đề cập chi tiết việc thiết lập agent.

## Câu hỏi thường gặp

**Open Responses có giống với OpenAI Responses API không?** Không. Open Responses là một đặc tả được dẫn xuất từ nó. Responses API của OpenAI là một triển khai với các tính năng bổ sung chỉ dành cho OpenAI; Ollama, LM Studio và vLLM là những triển khai khác.

**Ai sở hữu Open Responses hiện nay?** Kể từ 2026-10-22, nó là một dự án của Agentic AI Foundation thuộc Linux Foundation, được vận hành như một chuỗi LF Projects với một Ủy ban Chỉ đạo Kỹ thuật. Nó được cấp phép theo Apache 2.0.

**Anthropic có hỗ trợ Open Responses không?** Anthropic không nằm trong số những người ủng hộ được nêu tên. Nó đã đóng góp Agent Skills cho AAIF cùng ngày, nhưng giao diện gốc của Claude vẫn là Messages API.

**Tệp đặc tả ở đâu?** Tại `https://www.openresponses.org/openapi/openapi.json`, với các bản phát hành có ngày tháng trong [kho lưu trữ GitHub](https://github.com/openresponses/openresponses).

## Bước tiếp theo

Chọn endpoint mà sản phẩm của bạn gọi nhiều nhất, chạy các bài kiểm tra chấp nhận trên trình duyệt đối với nó, và nhập đặc tả vào Apidog để agent của bạn có thể tiếp tục chạy các kiểm tra đó trên mỗi lần triển khai. [Tải Apidog](https://apidog.com/download/?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) để bắt đầu.