Assistants API đã tắt: chuyển dự án của khách sang Responses API không chỉ là đổi endpoint

Hướng dẫn chuyển đổi của OpenAI giờ mở đầu bằng một câu ở thì quá khứ: Assistants API đã chính thức ngừng vào ngày 26/8/2026 và không còn dùng được nữa. Đây không còn là cảnh báo. Ứng dụng nào vẫn gọi API này thì đang hỏng, chỉ là có thể chưa ai để ý.

Thời gian chuẩn bị thì không thiếu. Ngày 26/8/2025, OpenAI thông báo trên diễn đàn developer rằng họ đang dừng bản beta của Assistants và sẽ tắt hẳn đúng một năm sau. Dù vậy, với một dự án đang ở trạng thái “chạy ổn, chưa cần sửa”, một năm rất dễ trôi qua mà không ai đụng tới.

Nếu bạn muốn làm FDE, hãy thử hình dung một ticket kiểu này: khách có một chatbot hay một agent nội bộ do ai đó viết từ năm trước, nay nó trả lỗi, và người viết đã nghỉ. Nhìn qua thì tưởng chỉ cần đổi endpoint. Thực tế thì phần khó nằm ở dữ liệu và ở những hệ thống đọc output phía sau.

Vì sao OpenAI bỏ Assistants?

OpenAI gọi Assistants là cách họ thử xây agent từ sớm, khi chưa có reasoning model. Responses API được giới thiệu là con đường tích hợp được khuyến nghị cho hiện tại và về lâu dài. Theo hướng dẫn chuyển đổi, khách chuyển sang sẽ có hiệu năng tốt hơn và thêm các tool có sẵn như web search, MCP và computer use.

Nhưng đổi sang Responses không chỉ mang về tính năng mới. Theo cách OpenAI ghép khái niệm, vòng gọi tool giờ nằm trong code của khách, còn lịch sử cũ muốn dùng tiếp thì khách phải tự lưu. Responses trả phần kiểm soát về cho bạn, nên bạn cũng phải tự lo những việc mà trước đây không cần nghĩ tới.

Ba khái niệm đổi tên, ba trách nhiệm đổi chỗ

Hướng dẫn của OpenAI ghép các khái niệm theo từng cặp. Assistant trở thành Prompt, tức một bản cấu hình gồm model, tools và instructions, dễ quản lý phiên bản và cập nhật hơn. Thread trở thành Conversation, lưu một chuỗi item thay vì chỉ lưu tin nhắn; Run trở thành Response, và vòng gọi tool giờ do code của khách tự điều khiển.

Đọc riêng từng dòng thì không thấy gì đáng lo. Rủi ro chỉ lộ ra khi đặt mỗi cặp cạnh câu hỏi “ai phải làm gì khác đi tại chỗ khách”. Bảng dưới đây đi theo hướng đó:

Assistants	Responses	Việc FDE phải kiểm tra tại chỗ khách
Assistant	Prompt (model, tools, instructions, có phiên bản)	Cấu hình đang nằm cứng trong code hay trên dashboard? Ai được sửa, sửa xong rollback thế nào?
Thread	Conversation (chuỗi item, không chỉ tin nhắn)	Lịch sử cũ có được khách lưu riêng không? Khi chuyển sang thì giữ bao nhiêu?
Run	Response, vòng gọi tool do code của khách điều khiển	Code của khách có xử lý được function call, retry và giới hạn số vòng không?
Output chỉ có tin nhắn	Output có thêm activity item (file search, function call)	Parser, log, dashboard, CRM phía sau có hiểu các loại item mới không?

Dòng thứ hai và dòng cuối là hai dòng dễ làm khách mất dữ liệu hoặc mất niềm tin nhất. Hai phần tiếp theo sẽ nói kỹ về từng dòng.

Lịch sử hội thoại: thứ không lấy lại được

Hướng dẫn của OpenAI nói rõ: lệnh Assistants dùng để lấy tin nhắn của thread không còn hoạt động, hãy dùng tin nhắn bạn đã tự lưu. Hiểu đơn giản, nếu khách luôn coi thread của OpenAI là database thì sau ngày 26/8/2026, phần lịch sử chỉ nằm trên thread đã không còn truy xuất được.

Thử hình dung một công ty logistics dùng Assistants làm bot chăm sóc khách hàng. Mỗi đơn khiếu nại là một thread, và nhân viên mở lại thread để đọc toàn bộ trao đổi trước khi gọi điện.

Nếu backend chỉ lưu thread_id mà không lưu nội dung, màn hình đó giờ trống, và lúc này vấn đề không còn nằm ở API mà ở chính quy trình nghiệp vụ của họ.

Ngay cả nhà cung cấp làm cẩn thận cũng không mang sang được toàn bộ. Zoho SalesIQ đã tự chuyển phần tích hợp của mình, nên Assistant ID, conversation ID và file ID cũ của khách vẫn dùng được trong tích hợp do SalesIQ quản lý. Nhưng khi chuyển một hội thoại, SalesIQ chỉ mang theo 100 tin nhắn gần nhất.

Thử hình dung một hội thoại hỗ trợ kéo dài nhiều tuần với 340 tin nhắn: sang hệ thống mới nó còn 100 tin, và 240 tin cũ nhất nằm ngoài ngữ cảnh model nhìn thấy. Nếu thông tin quan trọng như số hợp đồng hay cam kết hoàn tiền nằm ở mấy tin đầu, bot mới sẽ trả lời như thể chưa từng nghe đến chuyện đó.

Vì vậy, việc đầu tiên tại chỗ khách không phải viết code. Hãy kiểm kê: hội thoại nào khách còn bản lưu riêng, hội thoại nào chỉ còn ID, và nghiệp vụ nào cần lịch sử đầy đủ chứ không chỉ một phần cuối.

Sau đó thống nhất bằng văn bản với khách xem giữ bao nhiêu là đủ, thay vì để một con số mặc định quyết định thay họ.

Vòng gọi tool giờ là code của bạn

Hướng dẫn của OpenAI nói rõ rằng với Responses, vòng gọi tool do code của khách tự điều khiển. Chính code đó phải gửi request, nhận function call, chạy hàm, gửi kết quả về và quyết định khi nào dừng.

Hệ quả là những thứ trước đây bạn không phải nghĩ đến giờ trở thành trách nhiệm của bạn. Model gọi tool liên tục không dừng thì cắt sau bao nhiêu vòng?

Một function của hệ thống khách bị timeout thì báo lại cho model thế nào, và hai tool gọi song song mà một cái lỗi thì xử lý ra sao, đó là những câu hỏi về độ tin cậy của hệ thống chứ không chỉ về cú pháp API.

Điểm tích cực là sau khi tự viết vòng này, khách có chỗ để gắn logging, đo độ trễ từng bước và chặn những hành động nguy hiểm trước khi chúng chạy. Một FDE giỏi sẽ trình bày việc này cho khách như một lợi ích họ nhận được, không như gánh nặng bị ép làm.

Output đổi hình dạng, hệ thống phía sau đọc sai

Rủi ro thứ ba khó thấy nhất, vì nó không làm gì báo lỗi. Zoho lưu ý khách rằng một response giờ có thể chứa cả các activity item sinh ra trong lúc xử lý, chẳng hạn file search và function call, chứ không chỉ có câu trả lời cuối.

Thử hình dung một đoạn code cũ lấy phần tử đầu tiên của output rồi ghi vào CRM như câu trả lời của bot. Trên hệ thống mới, phần tử đầu tiên có thể là một bản ghi file search. CRM vẫn nhận dữ liệu, không có exception nào, và nhân viên bắt đầu thấy những đoạn text lạ trong lịch sử khách hàng.

Cách phòng là lần theo output từ API đến mọi nơi dùng nó: parser, log, dashboard, hệ thống báo cáo. Ở mỗi chỗ, kiểm tra xem code lọc theo loại item hay đang giả định output chỉ có tin nhắn. Danh sách này nên có trước khi đổi bất kỳ dòng code nào.

Developer Việt Nam nên làm gì với đợt chuyển đổi này?

Nếu công ty bạn từng làm chatbot hay agent trên Assistants cho khách, rất có thể sớm muộn sẽ có một ticket chuyển đổi rơi vào tay ai đó trong team. Đừng né nó. Đây là dịp tốt để luyện đúng loại kỹ năng của một FDE: vào một hệ thống lạ, tìm chỗ dữ liệu có thể mất, và thống nhất với khách trước khi sửa.

Khi đọc JD, nên để ý xem mô tả công việc có nhắc đến migration, tích hợp hệ thống cũ hay tool calling không; nếu có, trải nghiệm với đợt chuyển đổi này là thứ đáng đem ra kể khi phỏng vấn. Trên CV, đừng viết “migrated to Responses API”.

Hãy viết cụ thể bạn đã kiểm kê bao nhiêu hội thoại, giữ lại bao nhiêu lịch sử và đã ngăn được lỗi nào ở hệ thống phía sau, vì cách viết đó cho thấy bạn nghĩ đến hậu quả với khách chứ không chỉ đến endpoint.

OpenAI đã báo trước đúng 12 tháng, và dự án nào hôm nay còn gọi Assistants thì đã hết thời gian chờ. Người được gọi vào lúc đó sẽ cần biết dữ liệu của khách đang nằm ở đâu, và đó là việc phải làm trước khi động vào code.