Stateful Continuation cho AI Agents: Tại sao lớp Transport lại trở nên quan trọng?

Stateful Continuation cho AI Agents: Tại sao lớp Transport lại trở nên quan trọng?

Các luồng công việc của AI Agent đang khiến lớp truyền tải (transport layer) trở thành mối quan tâm hàng đầu. Các vòng lặp đa bước và sử dụng nhiều công cụ (tool-heavy loops) làm tăng đáng kể chi phí mà trước đây thường bị bỏ qua trong các ứng dụng LLM đơn giản. Stateful continuation giúp cắt giảm chi phí này một cách mạnh mẽ, việc lưu trữ ngữ cảnh ở phía máy chủ có thể giảm dữ liệu gửi từ client lên tới 80% và cải thiện thời gian thực thi từ 15–29%.

Vấn đề "Trên chuyến bay"

Trong một chuyến bay gần đây, tôi đã mua dịch vụ internet trên máy bay và cố gắng sử dụng Claude Code. Agent này cần đọc một số tệp, hiểu cấu trúc codebase, thực hiện chỉnh sửa và chạy các bài kiểm thử; đây là một luồng công việc điển hình của agent liên quan đến 10-15 lời gọi công cụ. Tuy nhiên, kết nối internet quá kém nên đến lượt thứ ba hoặc thứ tư, các yêu cầu bắt đầu hết thời gian chờ (timeout).

Mỗi lượt yêu cầu đều gửi lại toàn bộ lịch sử trò chuyện — lời nhắc ban đầu, mọi tệp mà nó đã đọc, mọi chỉnh sửa mà nó đã đề xuất, và kết quả của mọi bài kiểm thử. Dữ liệu tải (payload) đã phình to đến hàng trăm kilobyte. Trên một liên kết băng thông hạn chế, payload ngày càng tăng này trở thành nút thắt cổ chai.

Trải nghiệm này làm nổi bật một vấn đề ngày càng trở nên phù hợp khi các AI coding agent trưởng thành: lớp truyền tải quan trọng hơn nhiều đối với các luồng công việc dạng agent so với các cuộc trò chuyện đơn giản.

Vòng lặp Coding của Agent

Các AI coding agent đã chuyển từ sự mới lạ trở thành quy trình làm việc hàng ngày của nhiều tổ chức, đặc biệt là kể từ tháng 12 năm 2025. Các công cụ như Claude Code, OpenAI Codex, Cursor và Cline hiện nay thường xuyên thực hiện chỉnh sửa đa tệp, chạy bộ kiểm thử và lặp lại trên các bản dựng thất bại.

Vòng lặp coding agent

Trọng tâm của các agent này là "vòng lặp agent": một chu kỳ suy luận mô hình và thực thi công cụ lặp lại cho đến khi nhiệm vụ hoàn thành. Một lượt duy nhất của vòng lặp agent thường bao gồm đọc một số tệp để hiểu codebase, chỉnh sửa một số tệp và chạy kiểm thử, liên quan đến 10-15 lời gọi công cụ. Kết quả của các lời gọi công cụ này sau đó được gửi đến máy chủ suy luận LLM. Nếu vấn đề được giải quyết, máy chủ LLM trả về phản hồi. Nếu không, máy chủ đề xuất các lời gọi công cụ bổ sung, bắt đầu lượt tiếp theo của vòng lặp.

Vấn đề chi phí của HTTP

Với các API dựa trên HTTP, mỗi lượt là một yêu cầu không trạng thái (stateless). Máy chủ không nhớ những gì đã xảy ra ở lượt trước, vì vậy client phải gửi lại mọi thứ:

• Hướng dẫn hệ thống và định nghĩa công cụ (~2 KB)
• Lời nhắc ban đầu của người dùng
• Mọi đầu ra mô hình trước đó (bao gồm các khối code đầy đủ)
• Mọi kết quả gọi công cụ (bao gồm nội dung tệp, đầu ra lệnh)

Điều này có nghĩa là payload yêu cầu tăng tuyến tính theo mỗi lượt. Đến lượt thứ 9, HTTP đang gửi gần gấp 10 lần lượng dữ liệu mỗi yêu cầu so với WebSocket. Điều này là do chế độ WebSocket của OpenAI cho Responses API duy trì kết nối liên tục với trạng thái trong bộ nhớ phía máy chủ. Sau lượt đầu tiên, mỗi lượt tiếp theo chỉ gửi:

• Một previous_response_id tham chiếu đến trạng thái được lưu trong bộ nhớ đệm (~60 byte)
• Các đầu ra gọi công cụ mới (thường là 1-3 KB nội dung tệp hoặc đầu ra lệnh)

Payload giữ nguyên khoảng bất kể bạn đang ở lượt sâu nào.

Kết quả Benchmark: Xác nhận các tuyên bố

Để xác nhận các tuyên bố này với các phép đo được kiểm soát, chúng tôi đã xây dựng một benchmark mô phỏng các luồng công việc coding thực tế chống lại Responses API của OpenAI.

Chúng tôi đã đo lường hai cấu hình: HTTP Responses API (gửi lại toàn bộ ngữ cảnh) và WebSocket Responses API (chỉ gửi previous_response_id và đầu vào tăng thêm).

Biểu đồ so sánh bytes gửi qua HTTP và WebSocket

Kết quả cho thấy hiệu suất tương đối (WebSocket so với HTTP):

• Tổng thời gian: Nhanh hơn 29% (với GPT-5.4) và 15% (với GPT-4o-mini)
• Bytes gửi: Giảm 82% (GPT-5.4) và 86% (GPT-4o-mini)
• TTFT (Thời gian đến Token đầu tiên) ở lượt đầu: Giảm 14% (GPT-5.4)

WebSocket nhất quán giảm dữ liệu gửi từ client lên 80-86%. Đây là phát hiện đáng tin cậy nhất, độc lập với mô hình, biến thể API hoặc độ phức tạp của nhiệm vụ. HTTP gửi 153-176 KB cho mỗi nhiệm vụ; trong khi WebSocket chỉ gửi 21-32 KB.

Tại sao nó nhanh hơn: Kiến trúc

Sự khác biệt về hiệu suất là hệ quả trực tiếp của việc loại bỏ việc truyền dữ liệu dư thừa.

HTTP: Không trạng thái theo thiết kế Mỗi yêu cầu là độc lập. Máy chủ xử lý nó, trả về phản hồi và quên mọi thứ. Client phải tái tạo ngữ cảnh đầy đủ từ đầu.

WebSocket: Stateful Continuation Máy chủ giữ phản hồi gần nhất trong bộ nhớ cục bộ của kết nối. Các phần tiếp theo tham chiếu trạng thái được lưu trong bộ nhớ đệm đó, vì vậy client chỉ gửi những gì mới.

Bài học kiến trúc

1. Tương thích API so với Hiệu năng

API HTTP tương thích OpenAI là tiêu chuẩn thực tế. Mọi công cụ LLM, SDK và khung điều phối đều nói ngôn ngữ này. Nhưng sự tương thích này đi kèm một cái giá: API vốn dĩ không trạng thái, yêu cầu ngữ cảnh đầy đủ được truyền lại trên mỗi yêu cầu. Chế độ WebSocket phá vỡ sự tương thích này, gây ra sự phân mảnh.

Hiện tại, WebSocket là lợi thế chỉ dành cho OpenAI. Nếu agent của bạn cần chuyển đổi giữa các nhà cung cấp, bạn sẽ mất lợi ích hiệu suất của WebSocket trên mọi cuộc gọi không phải của OpenAI.

2. Chi phí giao thức ở quy mô lớn

Đối với một cuộc trò chuyện duy nhất, chi phí gửi lại ngữ cảnh là không đáng kể. Nhưng từ góc độ máy chủ, quy mô của coding agent vào năm 2026 làm cho điều này trở nên đáng kể.

Ước tính với 1 triệu phiên coding đồng thời tại thời điểm cao điểm:

• HTTP: 1.000.000 phiên x 176 KB = 176 GB dữ liệu client-to-server cho mỗi nhiệm vụ 40 giây.
• WebSocket: 1.000.000 phiên x 32 KB = 32 GB dữ liệu client-to-server cho mỗi nhiệm vụ 40 giây.

Đó là mức giảm 144 GB lưu lượng truy cập, tức là giảm 29 Gbps. Đối với một nhà cung cấp xử lý hàng triệu yêu cầu, điều này giảm tải cho các cổng API, bộ token hóa và cơ sở hạ tầng mạng.

3. Trạng thái phía máy chủ: Sự đổi mới thực sự

Manh mối chính là WebSocket không nhanh hơn vì của giao thức — tốc độ đến từ quản lý trạng thái phía máy chủ: máy chủ WebSocket lưu trữ phản hồi gần nhất trong bộ nhớ dễ bay hơi, cho phép tiếp tục gần như tức thì mà không cần token hóa lại toàn bộ cuộc trò chuyện.

Điều này có ý nghĩa kiến trúc:

• Trạng thái là nhất thời: Nó chỉ sống trong bộ nhớ trên máy chủ cụ thể xử lý kết nối của bạn. Nếu kết nối bị ngắt, trạng thái sẽ bị mất.
• Không có đa kênh (multiplexing): Mỗi kết nối WebSocket xử lý một phản hồi tại một thời điểm.

Khi nào HTTP vẫn là lựa chọn đúng

Chế độ WebSocket không phải lúc nào cũng tốt hơn. Sử dụng HTTP cho:

• Tương tác đơn giản, ít lượt: Đối với tương tác 1-2 lượt, chi phí truyền lại ngữ cảnh là không đáng kể.
• Hỗ trợ đa nhà cung cấp: Nếu bạn cần chuyển đổi giữa OpenAI, Anthropic, Google và các mô hình cục bộ, API HTTP tiêu chuẩn là mẫu số chung.
• Cơ sở hạ tầng không trạng thái: Nếu backend của bạn chạy trên các hàm không máy chủ (Lambda, Cloud Functions) không thể duy trì kết nối liên tục, HTTP là lựa chọn duy nhất.

Kết luận

Đối với các luồng công việc coding dạng agent, việc chuyển từ kết nối HTTP không trạng thái sang kết nối WebSocket có trạng thái mang lại cải thiện hiệu suất có ý nghĩa thực sự: thực thi nhanh hơn 29%, giảm 82% dữ liệu gửi từ client và giảm 11% TTFT với GPT-5.4.

Nhưng lợi thế của WebSocket đi kèm một sự đánh đổi: hiện tại nó chỉ dành riêng cho OpenAI, tạo ra sự phụ thuộc vào nhà cung cấp trong một hệ sinh thái mà các nhà phát triển ngày càng muốn chuyển đổi giữa các mô hình.

Bài học rút ra cho các kiến trúc sư xây dựng hệ thống agent không phải là áp dụng WebSocket một cách mù quáng. Đó là nhận ra rằng khi các luồng công việc AI chuyển từ đơn lượt sang đa lượt, các quyết định về lớp truyền tải trước đây không quan trọng đối với chatbot giờ đây trở nên vật chất đối với agent. Bất kỳ hệ thống nào tránh được việc truyền lại ngữ cảnh trò chuyện đang phát triển — dù thông qua WebSocket, lưu trữ phiên phía máy chủ hay giao thức có trạng thái tùy chỉnh — sẽ thấy những lợi ích tương tự.