API hỗ trợ OpenAI sẽ ngừng hoạt động vào ngày 26 tháng 8 năm 2026, các bước thực tế để di chuyển API phản hồi

Các điểm chính (câu trả lời trong 30 giây): API Trợ lý OpenAI sẽ ngừng hoạt động hoàn toàn vào ngày 26 tháng 8 năm 2026 và /v1/assistants, /v1/threads và /v1/runs sẽ không còn khả dụng nữa. Đích là API phản hồi + API hội thoại.

Hộp thông tin Ban biên tập

API phản hồi + API hội thoại

API hoàn thành trò chuyện tiếp tục

Xác nhận lần cuối: Ngày 1 tháng 8 năm 2026 bởi ban biên tập

Các điểm chính của bài viết này API hỗ trợ OpenAI sẽ ngừng hoạt động hoàn toàn vào ngày 26 tháng 8 năm 2026. Giải pháp thay thế là API phản hồi + API hội thoại, API này không chỉ thay đổi điểm cuối mà còn cả quản lý trạng thái, vòng lặp công cụ và mô hình chi phí. Còn 4 tháng nữa nên hãy làm nguyên mẫu trong tháng này.

Tính đến thời điểm bài viết này cập nhật (tháng 5 năm 2026), còn khoảng 3 tháng nữa là API Trợ lý sẽ ngừng hoạt động. Nhóm của tôi cũng đang trong quá trình chuyển đổi và thành thật mà nói, tôi đã ngây thơ khi nghĩ rằng đó chỉ là một bản viết lại đơn giản. Toàn bộ khái niệm về Thread biến mất và việc bỏ phiếu không đồng bộ của các đối tượng Run chuyển thành phát trực tuyến đồng bộ. Toàn bộ kiến ​​trúc đã được làm lại.

Hơn nữa, hướng dẫn di chuyển chính thức của OpenAI chỉ cung cấp cái nhìn tổng quan. Khi thực sự chạm vào mã, bạn sẽ gặp nhiều bẫy không có trong tài liệu, chẳng hạn như cách xử lý previous_response_id, sự khác biệt trong hoạt động của các công cụ tìm kiếm tệp và sự khác biệt trong ước tính chi phí. Bài viết này xác định và sắp xếp tất cả các phần còn vướng mắc trong quá trình thực hiện. Đây là nội dung mà những người đã đọc xong hướng dẫn chính thức nên đọc tiếp theo.

Chính xác thì việc ngừng sử dụng API Trợ lý là gì?

Việc ngừng sử dụng API Trợ lý đề cập đến kế hoạch ngừng sử dụng API Trợ lý mà OpenAI đã cung cấp ở giai đoạn thử nghiệm kể từ cuối năm 2023 (xem ghi chú phát hành chính thức về ngày phát hành) vào ngày 26 tháng 8 năm 2026 và hợp nhất API này vào API Phản hồi + API Cuộc trò chuyện. Thông báo về việc ngừng sử dụng sẽ được đưa ra vào nửa cuối năm 2025 (xem trang Khấu hao chính thức) và thời hạn chuyển đổi là cuối tháng 8 năm 2026.

Mục tiêu của việc ngừng sử dụng là các điểm cuối trong Trợ lý, chẳng hạn như /v1/assistants, /v1/threads và /v1/runs. API hoàn thành cuộc trò chuyện sẽ không bị ngừng sử dụng và sẽ tiếp tục. Điều này có nghĩa là chỉ những dịch vụ sử dụng đối tượng Trợ lý và Chủ đề để xây dựng agent chatbot mới bị ảnh hưởng.

Ngược lại, hệ thống được xây dựng chỉ bằng cách sử dụng chat.completions.create không liên quan gì đến việc ngừng cung cấp này. Tuy nhiên, trong tương lai, API Phản hồi sẽ trở thành xu hướng chủ đạo, do đó, việc bắt đầu viết bản phát triển mới bằng API Phản hồi là điều hợp lý.

Thời gian nghỉ hưu và vị trí hiện tại

Dưới đây là những ngày quan trọng được OpenAI công bố. Thời điểm cập nhật bài viết này (tháng 5 năm 2026) là giai đoạn chuyển tiếp từ giai đoạn nguyên mẫu sang giai đoạn thực hiện chuyển đổi.

Tóm lại, nếu nguyên mẫu không chạy vào tháng 4 thì lịch trình khá dày đặc. Nếu thử nghiệm bắt đầu vào tháng 5, thời gian thử nghiệm sẽ chỉ kéo dài một tháng và khả năng cao là các hệ thống lớn sẽ không thể hoàn thành thử nghiệm kịp thời.

Tôi cũng muốn đọc nó

TypingMind là gì? Giá và các tùy chọn lựa chọn bắt đầu từ $39 (phiên bản 2026)

TypingMind là màn hình trò chuyện một lần, nơi bạn có thể sử dụng nhiều AI bằng khóa API của riêng mình. Chúng tôi đã sắp xếp các nội dung của Tiêu chuẩn $39, Mở rộng $79 và Cao cấp $99, phiên bản Nhóm bắt đầu từ $83 mỗi tháng, nơi lưu dữ liệu và mức độ bạn có thể sử dụng miễn phí bằng cách sử dụng thông tin chính thức kể từ tháng 8 năm 2026.

Ngày 7 tháng 8 năm 2026

14 bài toán và giải pháp triển khai AI trong các công ty xây dựng và ngành xây dựng

Phải mất nửa ngày để tạo ước tính và bạn có thể thu thập 20 báo cáo hàng ngày. Chúng tôi đã sắp xếp 14 vấn đề gặp phải khi giới thiệu AI trong ngành xây dựng dưới dạng Hỏi đáp. Hầu hết các nguyên nhân không nằm ở hiệu suất của AI mà nằm ở cách nó được phân phối. Nó bao gồm bản tóm tắt chi tiết về báo cáo hàng ngày, cách bắt đầu sau một tuần, chi phí khoảng 3.000 yên Nhật mỗi tháng và những điểm cần lưu ý về trợ cấp.

Ngày 7 tháng 8 năm 2026

Sự khác biệt giữa API phản hồi và API hội thoại

Giải pháp thay thế chính thức là sự kết hợp của hai API với vai trò được phân tách rõ ràng.

API phản hồi chịu trách nhiệm tạo phản hồi và các cuộc hội thoại có trạng thái cũng có thể được định cấu hình bằng cách liên kết với tùy chọn cửa hàng, previous_response_id và Cuộc hội thoại (xem thông số kỹ thuật chính thức để biết chi tiết). Gọi client.responses.create() để trả về đầu ra mô hình, lệnh gọi công cụ và phát trực tuyến cùng một lúc. Nó tương tự như tính năng Hoàn thành trò chuyện truyền thống nhưng có vòng lặp công cụ tích hợp sẵn, giúp giảm đáng kể số lượng văn bản.

API hội thoại chịu trách nhiệm quản lý trạng thái của các cuộc hội thoại. Nó là phiên bản kế thừa của Threads nhưng có cấu trúc đơn giản tự động duy trì lịch sử hội thoại và có mẫu đơn giản kết nối thủ công previous_response_id.

Tóm lại, API mới có mô hình đối tượng phẳng và giảm số lượng mã. Tuy nhiên, điều này làm tăng trách nhiệm quản lý "lịch sử được tích lũy trong Thread mà không được phép" của riêng bạn. Đây sẽ là bước ngoặt lớn nhất trong quá trình chuyển đổi.

5 điều luôn thay đổi khi viết lại code

Khi thực sự làm việc trong quá trình di chuyển, năm phần sau đây sẽ luôn cần được viết lại. Về mặt dòng mã, nó sẽ giảm 30-50%, nhưng không thể thay thế một cách máy móc sed vì triết lý thiết kế sẽ thay đổi.

Đầu tiên là chính điểm cuối API. client.beta.assistants.create() và client.beta.threads.runs.create() đã bị bãi bỏ hoàn toàn. Mọi thứ được tóm tắt trong client.responses.create().

Thứ hai là quản lý nhanh chóng. Trong API Trợ lý, lời nhắc hệ thống được viết trong trường hướng dẫn, nhưng trong phương thức mới, chúng được đăng ký dưới dạng "Lời nhắc" trên bảng thông tin OpenAI và ID được tham chiếu từ mã. Điều này giúp loại bỏ nhu cầu triển khai khi cải thiện lời nhắc nhưng yêu cầu các quy tắc hoạt động để quản lý ID lời nhắc bằng Git.

Cái thứ ba là chủ đề → thay thế cuộc trò chuyện. Có hai tùy chọn: sử dụng API hội thoại hoặc tạo chuỗi thủ công bằng cách sử dụng previous_response_id. Cái sau là đủ cho quy mô nhỏ, nhưng cái trước được khuyến khích nếu số lượng phiên người dùng vượt quá hàng chục nghìn.

Thứ tư là vòng lặp công cụ. Phương thức cũ sử dụng một vòng lặp phức tạp để tạo một lần chạy, thăm dò trạng thái, thực thi công cụ tại require_action và trả về kết quả với submit_tool_outputs. Trong phương thức mới, các công cụ tích hợp sẵn như tìm kiếm trên web và file_search được API phản hồi xử lý, trong khi việc gọi hàm tùy chỉnh vẫn yêu cầu xử lý nhiều giai đoạn để trả về kết quả đầu ra của công cụ và yêu cầu lại (xem thông số kỹ thuật chính thức để biết chi tiết).

Thứ năm là mẫu xử lý không đồng bộ. Trợ lý được thiết kế để hoàn toàn không đồng bộ và "đợi vài giây đến vài phút trước khi nhận kết quả", nhưng API phản hồi về cơ bản là đồng bộ hóa hoặc phát trực tuyến. Giao diện người dùng thay đổi từ "màn hình chờ" sang "đầu ra tuần tự".

Tìm kiếm tập tin và lưu trữ vector thay đổi như thế nào?

Cửa hàng vectơ có thể được sử dụng nguyên trạng nhưng phương thức đính kèm sẽ thay đổi.

Trong phương thức cũ, vector_store_ids được gắn vào Trợ lý hoặc Chủ đề, nhưng trong phương thức mới, ID cửa hàng vectơ được chuyển dưới dạng công cụ file_search trong mảng công cụ của API phản hồi. Tính linh hoạt đã tăng lên vì các cửa hàng có thể được chuyển đổi theo yêu cầu.

Mặt khác, với Trợ lý, API Trợ lý tự động chọn đoạn tối ưu, trong khi với API Phản hồi, phía prompt cần lưu ý đến việc xử lý hậu kỳ kết quả tìm kiếm (xếp hạng lại, chèn ngữ cảnh). Cũng có báo cáo rằng độ chính xác của tìm kiếm đã giảm.

Nếu bạn đang thực hiện tìm kiếm tài liệu liên quan đến OCR, việc đọc hướng dẫn đầy đủ về các công cụ AI OCR sẽ giúp bạn quyết định có nên xử lý trước văn bản hay không. Khi PDF thô được vector hóa, nhiễu có xu hướng tăng lên với API mới.

Những thay đổi trong mô hình chi phí và tác động đến số tiền thanh toán

Đây có xu hướng là một điểm mù, nhưng số tiền hóa đơn sẽ tăng hoặc giảm do di chuyển.

API Trợ lý có ``Chi phí lưu giữ luồng'', ``Chi phí thực thi chạy'' và ``Chi phí lưu trữ cửa hàng Vector'' phức tạp. API phản hồi được tóm tắt đơn giản là phí mã thông báo + phí sử dụng công cụ. Nói cách khác, lịch sử lâu dài được lưu trữ trước đó trong Thread trở nên rõ ràng dưới dạng mức tiêu thụ mã thông báo cho mỗi yêu cầu.

Theo nguyên tắc chung, nếu bạn tiếp tục kết nối bằng previous_response_id mà không nén lịch sử thì sau lượt thứ 10, giá có thể đắt hơn 30-50% so với API Trợ lý cũ. Có hai biện pháp đối phó:

• Chèn bản tóm tắt cuộc hội thoại định kỳ: Thay thế nhật ký quá khứ bằng bản tóm tắt cứ sau 5 lượt
• Tận dụng luồng thu gọn /responses: Sử dụng quy trình chính thức để tóm tắt, nén và điền lại lịch sử (xem tài liệu chính thức để biết chi tiết về quản lý ngữ cảnh và thanh toán)

Giám sát thanh toán là điều bắt buộc và bạn nên kiểm tra bảng điều khiển chi phí hàng ngày trong một tuần sau khi chuyển đổi.

Các dự án cần được di chuyển nhanh chóng và các dự án tốt nhất nên chờ xem

Không cần thiết mọi người phải di chuyển ngay lập tức. Tổ chức các ưu tiên của bạn.

Các dự án sử dụng API Trợ lý trong sản xuất và có chi phí hàng tháng trên 100.000 yên Nhật nên được bắt đầu ngay lập tức. Quy mô càng lớn thì thời gian chuyển tiếp càng dài. Ngoài ra, hãy cảnh giác với các dịch vụ kiểu agent sử dụng nhiều trợ lý và nhiều công cụ. Ngay cả trong các trường hợp xây dựng agent tự trị như AutoGPT, việc viết lại vòng lặp công cụ chiếm lượng thời gian công sức lớn nhất.

Mức độ ưu tiên trung bình bao gồm các chatbot để sử dụng nội bộ và các dịch vụ nhận được vài nghìn yêu cầu mỗi tháng. Nó sẽ là đủ để bắt đầu từ tháng Năm đến tháng Sáu.

Tốt nhất nên chờ xem liệu nó chỉ là nguyên mẫu trong sân chơi API Trợ lý và chưa được đưa vào sản xuất hay không. Nếu bạn muốn đưa vào sản xuất ngay từ đầu, bạn nên viết lại nó bằng API mới.

Mặt khác, nếu bạn đang bắt đầu phát triển mới, API phản hồi là lựa chọn duy nhất của bạn. API hoàn thành cuộc trò chuyện vẫn là một tùy chọn, nhưng nếu bạn đang làm việc với nhiều công cụ và đa phương thức, việc viết bằng API mới ngay từ đầu sẽ dễ dàng hơn trong tương lai.

Tùy chọn chuyển sang dịch vụ AI của công ty khác

Đây cũng là cơ hội để giảm sự phụ thuộc vào OpenAI. Nếu bạn sẵn sàng trả tiền cho nỗ lực di chuyển, bạn nên xem xét hỗ trợ từ nhiều nhà cung cấp tại cơ hội này.

Về mặt cạnh tranh, các lựa chọn bao gồm Anthropic Claude, Google Gemini và Meta Llama. Mỗi người có điểm mạnh khác nhau. Xu hướng trong các hệ thống nguồn mở được sắp xếp theo cách sử dụng và giá cả của Meta AI, đồng thời các tùy chọn đa phương thức khác ngoài OpenAI được sắp xếp theo cách tạo video của Sora AI. Đối với mục đích dịch thuật, phương pháp sử dụng DeepL mới nhất thường có lợi thế hơn về độ chính xác và chi phí.

Tuy nhiên, OpenAI đi trước một bước về tính phong phú của việc cộng tác công cụ. Thay vì di chuyển hoàn toàn, giải pháp thực sự là một hoạt động kết hợp trong đó các chức năng cốt lõi do OpenAI cung cấp và các chức năng phụ do các công ty khác cung cấp.

Claude là một chatbot AI được phát triển bởi Anthropic, hỗ trợ hiểu, tạo, tóm tắt và phân tích văn bản theo cách trò chuyện tự nhiên. Nó có thế mạnh trong việc đọc các văn bản dài và sắp xếp các vấn đề, đồng thời có thể tóm tắt nội dung giấy tờ, hợp đồng, báo cáo, biên bản, v.v. và rút ra những điểm và rủi ro quan trọng. Chúng tôi cũng có thể trợ giúp soạn thảo email, đề xuất và tài liệu kinh doanh, diễn giải văn bản và tư vấn về quy tắc. Nó phù hợp cho các cá nhân và người dùng doanh nghiệp muốn hợp lý hóa việc nghiên cứu, viết và tạo tài liệu kinh doanh đồng thời nhấn mạnh tính chính xác và giải thích chi tiết.

Các mẫu lỗi thường gặp và cách giải quyết

Ba sai lầm phổ biến mắc phải trong các dự án di chuyển.

Đầu tiên là quên đi "Quản lý lịch sử ngầm của Thread". Trong API cũ, Thread tự ghi nhớ cuộc hội thoại, nhưng với API mới, trừ khi bạn tự kết nối previous_response_id, các bạn sẽ phải gặp nhau lần đầu tiên. Đây là một ví dụ điển hình về việc bot làm việc trong thử nghiệm nhưng đột nhiên quên mất bối cảnh trong quá trình sản xuất.

Thứ hai là không nhận thấy những thay đổi trong lược đồ JSON trong lệnh gọi công cụ. Ký hiệu của function_calling đã thay đổi một chút và nếu bạn sao chép và dán mã cũ, bạn sẽ gặp lỗi 400. Định nghĩa lược đồ phải được viết lại hoàn toàn.

Thứ ba là khả năng tương thích phiên cho người dùng hiện tại. ID chủ đề cũ không tương thích với API hội thoại mới. Lịch sử hội thoại của người dùng sẽ được đặt lại vào ngày phát hành. Để tránh điều này, cần có chiến lược ghi kép để chạy song song cả hai API trong giai đoạn chuyển đổi và chuyển các phiên mới sang API mới.

Lộ trình đề xuất cho các dự án di chuyển (còn 4 tháng)

Lộ trình thực tế cho đến ngày 26 tháng 8, tính đến tháng 5 năm 2026.

Cho đến cuối tháng 4 (còn 1 tuần): Hoàn thành nguyên mẫu chạy một chức năng chính bằng API phản hồi. Ngay cả khi nó không phải là một sản phẩm hoạt động đầy đủ thì cũng không sao miễn là bạn có thể nhấn vàoresponse.create() và nhận được kết quả đầu ra.

Tháng 5: Viết mã sản xuất cho vòng lặp công cụ, tìm kiếm tệp và quản lý nhanh chóng. Quy tắc hoạt động của bảng điều khiển cho chức năng Lời nhắc cũng sẽ được quyết định vào lúc này.

Tháng 6: Thời gian hoạt động song song của API cũ và mới. Chuyển 10-30% tổng lưu lượng truy cập sang API mới và so sánh tỷ lệ lỗi, độ trễ và chi phí. Nếu có vấn đề thì rollback ngay.

Tháng 7: Tăng tỷ lệ API mới lên 100%. Loại bỏ hoàn toàn sự phụ thuộc vào API Trợ lý cũ. Đồng thời dọn dẹp Vector Store và các tập tin.

Đầu tháng 8: Thời kỳ tăng cường giám sát. Không có thay đổi lớn nào được thực hiện và trò chơi đã bị đóng băng trong một tuần trước khi bị bãi bỏ.

Ngày 26 tháng 8: API Trợ lý bắt đầu trả về lỗi 404. Nếu thậm chí một lệnh gọi API cũ vẫn còn ở thời điểm này, dịch vụ sẽ dừng.

Những điểm dễ bị kẹt trong quá trình di chuyển

Nếu bạn đánh giá quá trình di chuyển là "chỉ thay đổi điểm cuối" thì bạn đã nhầm. So sánh sự khác biệt với hướng dẫn di chuyển đã xuất bản, có thể thấy rõ vấn đề nằm ở đâu.

Điều hiệu quả nhất là đơn giản hóa vòng lặp công cụ. Vì vòng bỏ phiếu của while run.status != "completed" có thể bị loại bỏ hoàn toàn nên khả năng đọc được cải thiện rất nhiều.

Mặt khác, việc quản lý lịch sử hội thoại nặng hơn dự kiến. Logic nén lịch sử và logic tìm kiếm được viết trên tiền đề của Thread sẽ được viết lại hoàn toàn. Một cách tiếp cận nhẹ nhàng chỉ kết nối bằng previous_response_id sẽ gây ra sự bùng nổ về mức tiêu thụ mã thông báo và việc sử dụng API hội thoại sẽ không khớp với lược đồ DB hiện có. Chúng ta sẽ phải tìm một sự thỏa hiệp ở đây.

Chi phí có xu hướng tăng lên nếu bạn chỉ chuyển chúng. Bằng cách kết hợp tự động chèn các bản tóm tắt cuộc hội thoại, nó có thể được nén lại và về lâu dài, thiết kế có thể được thiết kế giống như phiên bản cũ hoặc giảm bớt một chút.

Nhìn chung, tốt nhất bạn nên xem toàn bộ quá trình di chuyển như một cơ hội để tái cấu trúc. Một sự thay thế đơn giản sẽ thất bại, nhưng sẽ thu được rất nhiều lợi ích nếu thiết kế được xem xét lại. Nếu chúng ta tiến hành một cách có hệ thống cho đến khi bãi bỏ, chúng ta có thể thực hiện kịp thời.

Biên bản xác minh của ban biên tập

Có nhiều hướng dẫn di chuyển nhưng chúng khác nhau về độ sâu nội dung. Ban biên tập đã so sánh các hướng dẫn thực tế đã xuất bản dựa trên ba tiêu chí: `` Nó có mô tả cụ thể những gì sẽ bị hỏng sau khi ngừng sử dụng không?'' `` Nó có giải thích sự khác biệt về thiết kế với Responses API về mặt cấu trúc không?'' `` Nó có ước tính thực tế chi phí di chuyển và khung thời gian không?''

Khi thông tin đại chúng được tổ chức, các vấn đề có thể được tóm tắt thành ba điểm. Đầu tiên, cái gì không hiệu quả? Sự sắp xếp mà /v1/assistants, /v1/threads và /v1/run gặp sự cố trong khi Hoàn thành trò chuyện vẫn tiếp tục là điều phổ biến đối với tất cả các hướng dẫn. Thứ hai, có sự khác biệt trong triết lý thiết kế. Bước ngoặt là liệu có duy trì trạng thái Thread bằng cách sử dụng previous_response_id hay API Conversations hay không. Thứ ba, trục thời gian. Chúng ta sẽ cần một lịch trình làm việc được tính ngược dựa trên giả định rằng tất cả các điểm cuối sẽ dừng vào ngày 26 tháng 8.

Dưới đây là các quyết định dựa trên mức sử dụng: Đối với các công cụ nội bộ quy mô nhỏ, phương thức previous_response_id cho phép bạn tự quản lý trạng thái một cách nhanh chóng. Nếu bạn đang sử dụng SaaS cho khách hàng lưu giữ lịch sử hội thoại trong một thời gian dài thì việc duy trì lịch sử đó sau này sẽ dễ dàng hơn bằng cách gửi trạng thái đến phía máy chủ bằng API hội thoại. Đối với các sản phẩm phụ thuộc nhiều vào framework, tốt nhất nên ưu tiên hàng đầu việc tính toán chi phí di chuyển. Tất cả các số liệu có thể thay đổi, vì vậy vui lòng tham khảo thông tin mới nhất trên trang web chính thức để biết giá và thông số kỹ thuật cuối cùng.

Các câu hỏi thường gặp (FAQ)

Câu hỏi: Chính xác thì khi nào thì API Trợ lý sẽ ngừng hoạt động?

Ngày tạm ngưng chính thức là ngày 26 tháng 8 năm 2026. Sau đó, các điểm cuối như /v1/assistants và /v1/threads sẽ trả về lỗi. Thời gian chuyển tiếp sẽ kéo dài khoảng 8 tháng kể từ thông báo vào tháng 1 năm 2026.

Câu hỏi: API hoàn thành trò chuyện có bị ngừng sử dụng không?

Không, API hoàn thành trò chuyện sẽ không bị ngừng sử dụng. sẽ tiếp tục được cung cấp. Chỉ API Trợ lý (các đối tượng Trợ lý, Chuỗi, Chạy) sẽ không được dùng nữa và các hệ thống được xây dựng chỉ bằng chat.completions.create sẽ không bị ảnh hưởng.

H. Tôi có thể tiếp tục sử dụng Cửa hàng Vector hiện tại của mình không?

Có, Vector Store sẽ tiếp tục có sẵn. Tuy nhiên, phương thức đính kèm đã thay đổi và hiện được chỉ định làm công cụ file_search trong mảng công cụ của API phản hồi. Không cần di chuyển dữ liệu nhưng mã cuộc gọi tìm kiếm phải được viết lại.

Câu hỏi: Có cần cả API phản hồi và API hội thoại không?

API phản hồi là bắt buộc. Chỉ sử dụng API hội thoại khi bạn muốn tự động quản lý lịch sử hội thoại. Đối với quy mô nhỏ, mẫu kết nối thủ công previous_response_id đơn giản là đủ và đối với quy mô vượt quá hàng chục nghìn phiên, API hội thoại được khuyên dùng.

H. Điều gì sẽ xảy ra nếu tôi không di chuyển?

Sau ngày 26 tháng 8 năm 2026, tất cả các lệnh gọi API sẽ dẫn đến lỗi. Các hệ thống sản xuất dựa trên API Trợ lý phải được di chuyển trước thời hạn do ngừng dịch vụ. Việc chuyển đổi ngay trước thời hạn có nguy cơ thất bại cao, vì vậy chúng tôi khuyên bạn nên hoàn tất việc chuyển đổi vào tháng 7.

Bài viết liên quan

• Việc sử dụng và định giá API ChatGPT được giải thích sau 5 phút | GPT-5 là 1,25 USD/1 triệu
• API COTOHA không còn khả dụng | Quy trình so sánh và di chuyển API thay thế NLP của Nhật Bản (phiên bản 2026)
• Hướng dẫn đầy đủ về LiteLLM | Cách gọi hơn 100 LLM với API, phí và mức sử dụng thống nhất (phiên bản 2026)
• DuyệtComp là gì? Bài kiểm tra khả năng khám phá AI gồm 1.266 câu hỏi và cách đọc điểm (ấn bản 2026)
• Gọi hàm là gì? Hướng dẫn đầy đủ về cơ chế, cách triển khai và mức phí để AI thao tác với các API bên ngoài

ChatGPT là chatbot AI hỗ trợ trả lời câu hỏi, tạo văn bản, sắp xếp thông tin và tạo ý tưởng thông qua đối thoại tự nhiên. Bạn có thể thực hiện các tác vụ dựa trên văn bản như tóm tắt văn bản dài, soạn thảo email và đề xuất, dịch, diễn giải và sắp xếp chúng dưới dạng bảng trong khi trò chuyện. Chúng tôi còn cung cấp dịch vụ tạo mã lập trình, xác nhận nguyên nhân lỗi, giải thích nội dung học tập và tư vấn bằng hình ảnh. Nó phù hợp cho những người dùng muốn sử dụng nó cho nhiều mục đích khác nhau, từ nghiên cứu cá nhân đến hỗ trợ tạo và phát triển tài liệu kinh doanh.