Neon Functions hiện đã hỗ trợ các kết nối streaming thời lượng không giới hạn, cho phép các agent AI duy trì một kênh trực tiếp trong vài giây, vài phút hoặc lâu hơn mà không gặp phải các giới hạn timeout thường làm ngắt các tác vụ serverless. Thay đổi này có ý nghĩa quan trọng đối với bất kỳ ai đang xây dựng các trợ lý kiểu chat hoặc bot sử dụng công cụ, vì một luồng dữ liệu bị ngắt sẽ làm gián đoạn cuộc hội thoại và làm hỏng trải nghiệm người dùng.

Tại sao serverless và các agent AI lại mâu thuẫn với nhau

Hầu hết các nền tảng serverless được xây dựng cho các tác vụ nhanh, kiểu "gửi và quên" (fire-and-forget). Chúng áp dụng các giới hạn thực thi nghiêm ngặt—thường là 10 giây đối với các gói miễn phí và 60 giây đối với các gói trả phí—để giữ cho tài nguyên có thể dự đoán được. Tuy nhiên, một agent AI lại dành thời gian để suy nghĩ, gọi các công cụ bên ngoài và phát ra các token ngay khi chúng được tạo ra. Giai đoạn "suy nghĩ" đó thường kéo dài hàng chục giây, và luồng token có thể tiếp tục chừng nào mô hình còn tạo ra đầu ra. Khi bộ đếm thời gian của nền tảng hết hạn, nó sẽ đóng kết nối và phía client sẽ thấy một luồng dữ liệu bị ngắt.

Câu trả lời của Neon: streaming duy trì lâu dài theo mặc định

Neon Functions thay đổi hoàn toàn cuộc chơi. Một lệnh gọi hàm có thể được duy trì mở vô thời hạn, truyền dữ liệu qua WebSockets hoặc Server-Sent Events (SSE) mà không cần bất kỳ cấu hình đặc biệt nào. Nền tảng coi một luồng dữ liệu dài là một yêu cầu bình thường, vì vậy các nhà phát triển chỉ cần viết logic tạo ra luồng dữ liệu và để Neon xử lý phần còn lại.

Trong một thử nghiệm gần đây, hai endpoint đã chứng minh hành vi này:

  • Endpoint Heartbeat – hàm phát ra một tiếng "tick" mỗi giây trong vòng 90 giây. Các gói serverless thông thường sẽ chấm dứt yêu cầu sau 10 hoặc 60 giây; Neon đã giữ kết nối sống cho đến khi hàm tự kết thúc.
  • Endpoint Token-relay – hàm truyền các token từ một mô hình AI đến client ngay khi mỗi token được tạo ra. Người dùng thấy câu trả lời xuất hiện từng từ một thay vì phải chờ đợi toàn bộ khối văn bản.

Cả hai ví dụ đều chỉ yêu cầu một yêu cầu duy nhất từ client; không cần các mẹo polling hay keep-alive.

Ai được hưởng lợi, và ai cần thận trọng

Các đội ngũ xây dựng trợ lý hội thoại, các agent sử dụng công cụ, hoặc bất kỳ dịch vụ nào cần đẩy kết quả tăng dần sẽ nhận được một lợi thế tức thì: giới hạn timeout không còn nữa. Kết quả là mã nguồn đơn giản hơn, độ trễ thấp hơn và trải nghiệm người dùng mượt mà hơn.

Các đánh đổi cần lưu ý:

  • Mô hình chỉ dựa trên yêu cầu (Request-only model) – Neon Functions xử lý các luồng dữ liệu luôn gắn liền với một yêu cầu đang hoạt động. Các tác vụ chạy ngầm (background jobs) cần tồn tại lâu hơn yêu cầu vẫn cần một bộ lập lịch riêng biệt như Inngest hoặc một công cụ workflow tương tự.
  • Cold starts – Các hàm ở trạng thái nghỉ có thể scale về 0, vì vậy yêu cầu tiếp theo có thể gặp phải sự chậm trễ do cold-start. Một luồng dữ liệu đang hoạt động sẽ ngăn việc scale down, nhưng yêu cầu đầu tiên sau một thời gian không hoạt động vẫn phải chịu chi phí khởi động.

Điều cần theo dõi tiếp theo

Điểm mấu chốt: Neon Functions loại bỏ ngưỡng giới hạn timeout vốn từ lâu đã buộc các nhà phát triển AI phải sử dụng các giải pháp lách luật. Bằng cách cho phép một yêu cầu duy trì mở lâu nhất có thể để agent suy nghĩ và trò chuyện, Neon giúp việc triển khai các agent AI streaming trở nên đơn giản như bất kỳ hàm serverless nào khác.