Responses API so với Chat Completions cho Agents: Lựa chọn hợp đồng

Đối với các tác vụ của agent, Responses API là lựa chọn mặc định tốt hơn: nó cung cấp trạng thái hội thoại phía máy chủ thông qua previous_response_id, các mục đầu ra được định kiểu (typed output items) thay vì một khối tin nhắn đơn lẻ, và các sự kiện streaming ngữ nghĩa. Những tính năng này giúp giảm bớt khối lượng công việc quản lý dữ liệu mà lớp điều phối (orchestration layer) của bạn phải đảm nhận. Chat Completions vẫn là một lựa chọn hợp lệ khi bạn muốn kiểm soát hoàn toàn lịch sử tin nhắn hoặc đang tích hợp với các công cụ được xây dựng dựa trên định dạng tin nhắn chat của OpenAI, nhưng đối với các agent thực hiện gọi công cụ (tool-calling) nhiều lượt, Responses là lựa chọn phù hợp trực tiếp hơn.

Cả hai endpoint đều được ghi lại trong các trang tham chiếu mô hình hiện tại cho GPT-5.6 và GPT-5.5, và hợp đồng yêu cầu/phản hồi chung cho Responses được quy định trong tài liệu tham chiếu tạo Responses.

Những điểm chính cần lưu ý

• Chat Completions do người gọi quản lý: bạn gửi toàn bộ mảng messages trong mỗi yêu cầu và tự tái tạo lịch sử.
• Responses được máy chủ hỗ trợ: bạn gửi input cùng với instructions tùy chọn, và có thể nối tiếp các lượt hội thoại bằng previous_response_id thay vì phải gửi lại lịch sử.
• Việc gọi công cụ khác biệt về cấu trúc: Chat Completions lồng các lệnh gọi trong choices[0].message.tool_calls; Responses phát ra chúng dưới dạng các mục được định kiểu trong một mảng output phẳng.
• Kết quả công cụ được khớp theo tool_call_id (Chat) so với call_id trên một mục function_call_output (Responses).
• Streaming là các delta dựa trên chunk trong Chat Completions so với các sự kiện ngữ nghĩa được đặt tên trong Responses.
• Hỗ trợ công cụ được lưu trữ (tìm kiếm web, trình thông dịch mã, tìm kiếm tệp, v.v.) phụ thuộc vào mô hình ở cả hai API; hãy kiểm tra trang của mô hình trước khi giả định tính khả dụng.

So sánh cấp trường

Mối quan tâm	Chat Completions	Responses
Endpoint	POST /v1/chat/completions	POST /v1/responses
Đầu vào chính	messages: [] (toàn bộ mảng mỗi lần gọi)	input (chuỗi hoặc mảng các mục)
Hướng dẫn kiểu hệ thống	messages[0].role = "system"	Trường instructions cấp cao nhất
Tiếp nối đa lượt	Người gọi gửi lại toàn bộ lịch sử messages	previous_response_id tham chiếu lượt trước phía máy chủ
Hình dạng đầu ra	choices[0].message (đối tượng tin nhắn đơn)	output: [], một mảng các mục được định kiểu (tin nhắn, function_call, v.v.)
Vị trí gọi công cụ	choices[0].message.tool_calls[]	Các mục trong output với type: "function_call"
Gửi kết quả công cụ	Tin nhắn mới với role: "tool", tool_call_id	Mục với type: "function_call_output", call_id
Streaming	Các mảnh chunk.choices[0].delta	Các sự kiện được đặt tên (response.output_text.delta, response.completed, v.v.)

previous_response_id: Nó thực sự làm gì

Trong Chat Completions, bộ nhớ hội thoại hoàn toàn là trách nhiệm của bạn. Mọi yêu cầu phải bao gồm toàn bộ lịch sử tin nhắn và máy chủ không có khái niệm về lượt trước đó. Thay vào đó, Responses API trả về một id trên mỗi đối tượng phản hồi. Nếu ứng dụng của bạn lưu trữ id đó và truyền lại dưới dạng previous_response_id trong lần gọi tiếp theo, máy chủ sẽ tái tạo trạng thái hội thoại trước đó ở phía nó. Bạn chỉ cần gửi input mới cho lượt hiện tại cộng với instructions mới (tùy chọn). Điều này chuyển việc quản lý trạng thái từ lớp ứng dụng của bạn sang cơ sở hạ tầng của OpenAI, điều này rất quan trọng đối với các agent thực hiện nhiều lượt gọi công cụ tuần tự vì bạn tránh được việc phải tuần tự hóa lại và truyền lại lịch sử ngày càng dài trong mỗi bước.

Điểm đánh đổi là ứng dụng của bạn vẫn cần lưu trữ id ở một nơi bền vững (kho lưu trữ phiên, hàng cơ sở dữ liệu) giữa các lượt; API không cung cấp cho bạn khả năng lưu giữ vô hạn hoặc tìm kiếm qua các phản hồi cũ, nó chỉ cho phép bạn tham chiếu đến phản hồi ngay trước đó như một điểm tiếp nối.

Ví dụ yêu cầu hiện tại (gpt-5.6)

Chat Completions: bạn sở hữu toàn bộ lịch sử:

{
  "model": "gpt-5.6",
  "messages": [
    { "role": "system", "content": "You are a support agent." },
    { "role": "user", "content": "Check order #4471 status." }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_order_status",
        "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
      }
    }
  ]
}

Responses: lượt đầu tiên với instructions và input:

{
  "model": "gpt-5.6",
  "instructions": "You are a support agent.",
  "input": "Check order #4471 status.",
  "tools": [
    {
      "type": "function",
      "name": "get_order_status",
      "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
    }
  ]
}

Responses: lượt tiếp theo, không gửi lại lịch sử:

{
  "model": "gpt-5.6",
  "previous_response_id": "resp_abc123",
  "input": "What about order #4472?"
}

Vòng đời gọi hàm (Function-Call)

Chat Completions:

1. Mô hình trả về choices[0].message.tool_calls, mỗi cái có một id và tên/đối số hàm.
2. Bạn thực thi hàm cục bộ.
3. Bạn thêm tin nhắn trợ lý (với tool_calls) vào mảng messages của bạn, sau đó thêm một tin nhắn mới: { "role": "tool", "tool_call_id": "<id>", "content": "<result>" }.
4. Bạn gửi lại toàn bộ mảng messages đã cập nhật để tiếp tục.

Responses:

1. Mảng output chứa một mục với type: "function_call", bao gồm call_id, name và arguments.
2. Bạn thực thi hàm cục bộ.
3. Bạn gửi một yêu cầu mới với previous_response_id được đặt thành id của phản hồi trước đó, và input chứa một mục với type: "function_call_output", khớp với call_id và kết quả.
4. Máy chủ đã lưu giữ ngữ cảnh gọi hàm, vì vậy bạn không cần gửi lại các lượt trước đó.

Sự khác biệt về cấu trúc giữa các mục đầu ra được định kiểu phẳng và một tin nhắn đơn lẻ với mảng lồng nhau có xu hướng đơn giản hóa logic phân tích cú pháp trong Responses, vì bạn có thể lặp qua output và chuyển đổi dựa trên type thay vì đào sâu vào các trường tùy chọn của tin nhắn.

Danh sách kiểm tra quyết định

• Đang xây dựng agent đa lượt với các lệnh gọi công cụ? Mặc định chọn Responses; previous_response_id loại bỏ việc quản lý lịch sử.
• Cần kiểm soát chính xác những gì có trong lịch sử (biên tập, tóm tắt tùy chỉnh, chèn tin nhắn không chuẩn)? Chat Completions cho bạn quyền kiểm soát đó một cách rõ ràng, vì bạn tự lắp ráp messages.
• Đang di chuyển một tích hợp Chat Completions hiện có? Cân nhắc chi phí tái cấu trúc so với việc tiết kiệm quản lý trạng thái; đối với các cuộc gọi ngắn, đơn lượt, lợi ích sẽ nhỏ hơn.
• Phụ thuộc vào các công cụ được lưu trữ (tìm kiếm, trình thông dịch mã, công cụ tệp)? Xác minh hỗ trợ trên trang của mô hình cụ thể trước khi cam kết, vì tính khả dụng thay đổi theo mô hình và endpoint.
• Cần streaming với ngữ nghĩa sự kiện chi tiết (ví dụ: phân biệt delta văn bản với delta gọi công cụ mà không cần kiểm tra hình dạng delta)? Các sự kiện được đặt tên của Responses rõ ràng hơn các khối delta chung của Chat Completions.
• Làm việc trong một framework hoặc SDK hiện có được xây dựng xung quanh tin nhắn chat? Xác nhận mức độ trưởng thành hỗ trợ Responses của nó trước khi chuyển đổi hợp đồng giữa dự án.

Agent đa nhà cung cấp và chuyển đổi hợp đồng

Các agent hiếm khi ở lại với một nhà cung cấp duy nhất trong thời gian dài. Một agent lập trình có thể định tuyến đến Claude Sonnet 5 hoặc Kimi K2.7 Code cho công việc triển khai, quay lại DeepSeek V4 Flash hoặc Gemini 3.5 Flash cho các bản nháp giá rẻ, và thỉnh thoảng gọi GLM-5.2 hoặc Qwen3.7 Plus để kiểm soát chi phí cho các mô hình mã nguồn mở. Không phải nhà cung cấp nào trong số này cũng nhất thiết phải hiển thị hợp đồng Chat Completions hoặc Responses của OpenAI một cách tự nhiên.

Đây là nơi một lớp định tuyến phát huy giá trị. Tài liệu của TokenLab tại docs.tokenlab.sh mô tả một bề mặt API và khóa duy nhất được sử dụng để tiếp cận nhiều nhà cung cấp mô hình, giúp loại bỏ nhu cầu viết thủ công một tích hợp client riêng cho mỗi hợp đồng nhà cung cấp. Bài viết liên quan của chúng tôi về bí danh tiêu đề cho khả năng tương thích hợp đồng đề cập đến cách các tiêu đề yêu cầu có thể được ánh xạ để mã được viết dựa trên một hình dạng hợp đồng có thể tiếp cận các mô hình không hỗ trợ nó một cách tự nhiên. Nếu bạn đang xây dựng một chatbot hoặc agent cần gọi nhiều hơn một dòng mô hình, hướng dẫn của chúng tôi về xây dựng chatbot AI với một khóa API sẽ hướng dẫn thiết lập bằng các thuật ngữ cụ thể hơn.

Để biết danh sách đầy đủ các mô hình hiện có thể tiếp cận thông qua TokenLab, bao gồm các tùy chọn định tuyến tiên phong, lập trình và chi phí thấp được tham chiếu ở trên, hãy xem trang mô hình của chúng tôi. Xác nhận tính khả dụng hiện tại và bất kỳ ghi chú cụ thể nào về hợp đồng ở đó trước khi hoàn thiện kiến trúc của bạn, vì dòng sản phẩm mô hình thay đổi thường xuyên hơn các hợp đồng API.

Hạn chế

Bài viết này không trình bày lại tham chiếu API cấp trường chính xác của OpenAI cho bất kỳ hợp đồng nào, vì các chi tiết đó được đánh phiên bản và có thể thay đổi. Đừng coi ví dụ về hình dạng yêu cầu ở trên là mã sẵn sàng cho sản xuất. Chúng tôi cũng chưa đề cập sâu đến hợp đồng gốc của mọi nhà cung cấp; Claude, Gemini, DeepSeek và GLM mỗi bên đều xuất bản các tham chiếu API riêng của họ, và không ai trong số họ có nghĩa vụ phải khớp với các hình dạng Chat Completions hoặc Responses của OpenAI. Nếu agent của bạn cần đảm bảo về thứ tự gọi công cụ, định dạng sự kiện streaming hoặc hành vi xử lý hàng loạt, hãy xác minh các chi tiết cụ thể đó dựa trên tài liệu hiện tại của nhà cung cấp được nêu tên, không phải dựa trên bài viết này.

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

Responses API có phải là sự thay thế cho Chat Completions không? Tài liệu quickstart của OpenAI định vị Responses API là con đường hiện tại cho sự phát triển mới, bao gồm các trường hợp sử dụng agentic, trong khi Chat Completions vẫn là một phần của bề mặt API được ghi lại của họ. Việc Chat Completions có bị phản đối, ngừng hỗ trợ hay đơn giản là cũ tại bất kỳ thời điểm nào là điều bạn nên xác nhận trực tiếp trong tài liệu hiện tại của OpenAI, vì trạng thái hỗ trợ có thể thay đổi.

Các nhà cung cấp khác như Claude, Gemini hoặc DeepSeek có sử dụng cùng các hợp đồng này không? Không phải tự nhiên. Mỗi nhà cung cấp xác định hình dạng yêu cầu và phản hồi riêng của mình. Nếu bạn cần chạy một agent trên các mô hình OpenAI và các nhà cung cấp như Claude Sonnet 5 hoặc DeepSeek V4 Pro, hãy lên kế hoạch cho một lớp chuyển đổi thay vì giả định một hợp đồng chung.

Việc chuyển đổi hợp đồng có làm thay đổi chất lượng đầu ra của mô hình không? Không. Hợp đồng là phương thức vận chuyển và cấu trúc của yêu cầu và phản hồi, không phải bản thân mô hình. Chất lượng đầu ra được quyết định bởi mô hình bạn gọi (ví dụ: GPT-5.5 so với Claude Sonnet 5), không phải bởi việc bạn đã sử dụng Chat Completions hay Responses API để gọi nó.

Nếu bạn đang đánh giá hợp đồng nào và mô hình nào phù hợp với agent của mình, hãy bắt đầu với một bản dựng thử nghiệm nhỏ dựa trên các endpoint được ghi lại của TokenLab và so sánh trực tiếp chi phí điều phối. Bắt đầu tại docs.tokenlab.sh để chạy so sánh đó với khối lượng công việc của riêng bạn.