Từ Mô hình đến Tác tử: OpenAI trang bị Môi trường Máy tính cho Responses API

Bước chuyển mình từ Mô hình sang Tác tử

Chúng ta đang chứng kiến một sự thay đổi lớn trong ngành công nghệ AI: từ việc sử dụng các mô hình (models) vốn chỉ xuất sắc ở những tác vụ cụ thể, sang việc triển khai các tác tử (agents) có khả năng xử lý những luồng công việc phức tạp. Nếu như việc sử dụng câu lệnh (prompt) chỉ cho phép chúng ta truy cập vào trí thông minh đã được huấn luyện của mô hình, thì việc cung cấp cho mô hình một môi trường máy tính sẽ mở ra một phạm vi ứng dụng rộng lớn hơn nhiều. Các mô hình giờ đây có thể chạy dịch vụ, yêu cầu dữ liệu từ API, hay tạo ra các sản phẩm hữu ích hơn như bảng tính hoặc báo cáo.

Tuy nhiên, một vài vấn đề thực tiễn nảy sinh khi xây dựng các tác tử: lưu trữ các tệp trung gian ở đâu, làm thế nào để tránh việc dán các bảng dữ liệu khổng lồ vào câu lệnh, làm sao để cấp quyền truy cập mạng cho luồng công việc mà không gây ra rủi ro bảo mật, và cách xử lý thời gian chờ (timeouts) và thử lại (retries) mà không phải tự mình xây dựng cả một hệ thống phức tạp.

Thay vì để các nhà phát triển tự xây dựng môi trường thực thi, chúng tôi đã tạo ra các thành phần cần thiết để trang bị cho Responses API một môi trường máy tính, giúp nó có thể thực thi các tác vụ trong thế giới thực một cách đáng tin cậy.

Giải pháp toàn diện từ OpenAI

Responses API của OpenAI, kết hợp với công cụ shell và một không gian làm việc container (hosted container workspace), được thiết kế để giải quyết những vấn đề thực tiễn này. Mô hình sẽ đề xuất các bước và câu lệnh; nền tảng sẽ chạy chúng trong một môi trường cô lập với hệ thống tệp (filesystem) cho đầu vào và đầu ra, tùy chọn lưu trữ có cấu trúc (như SQLite), và quyền truy cập mạng bị hạn chế.

Trong bài viết này, chúng tôi sẽ phân tích cách chúng tôi đã xây dựng một môi trường máy tính cho các tác tử và chia sẻ những bài học ban đầu về cách sử dụng nó để có được các luồng công việc sản xuất nhanh hơn, dễ tái lặp hơn và an toàn hơn.

Vòng lặp Thực thi: Cốt lõi của một Tác tử hiệu quả

Một luồng công việc của tác tử hiệu quả bắt đầu bằng một vòng lặp thực thi chặt chẽ: mô hình đề xuất một hành động như đọc tệp hoặc lấy dữ liệu bằng API, nền tảng thực thi nó, và kết quả được đưa trở lại cho bước tiếp theo. Chúng ta sẽ bắt đầu với công cụ shell—cách đơn giản nhất để thấy vòng lặp này hoạt động—và sau đó sẽ đề cập đến không gian làm việc container, kết nối mạng, các kỹ năng tái sử dụng, và tính năng nén ngữ cảnh (context compaction).

Để hiểu về công cụ shell, trước tiên cần hiểu cách một mô hình ngôn ngữ sử dụng các công cụ nói chung: để thực hiện các việc như gọi một hàm hoặc tương tác với máy tính. Trong quá trình huấn luyện, mô hình được cho xem các ví dụ về cách sử dụng công cụ và kết quả tương ứng, từng bước một. Điều này giúp mô hình học cách quyết định khi nào và làm thế nào để sử dụng một công cụ. Khi chúng tôi nói "sử dụng một công cụ", thực chất mô hình chỉ đề xuất một lệnh gọi công cụ, chứ nó không thể tự mình thực thi lệnh gọi đó.

Công cụ shell giúp mô hình trở nên mạnh mẽ hơn đáng kể: nó tương tác với máy tính thông qua dòng lệnh để thực hiện một loạt các tác vụ, từ tìm kiếm văn bản đến gửi yêu cầu API trên máy tính của bạn. Được xây dựng trên các công cụ Unix quen thuộc, công cụ shell của chúng tôi có thể làm mọi thứ bạn mong đợi, với các tiện ích như grep, curl, và awk có sẵn.

So với trình thông dịch mã (code interpreter) hiện có, vốn chỉ thực thi Python, công cụ shell cho phép một phạm vi ứng dụng rộng hơn nhiều, như chạy các chương trình Go hoặc Java, hoặc khởi động một máy chủ NodeJS. Sự linh hoạt này cho phép mô hình hoàn thành các tác vụ phức tạp của một tác tử.

Responses API: Bộ điều phối thông minh

Bản thân mô hình chỉ có thể đề xuất các lệnh shell, nhưng làm thế nào để các lệnh này được thực thi? Chúng ta cần một bộ điều phối (orchestrator) để nhận đầu ra của mô hình, gọi các công cụ, và chuyển phản hồi của công cụ trở lại cho mô hình trong một vòng lặp, cho đến khi tác vụ hoàn tất.

Responses API chính là cách các nhà phát triển tương tác với các mô hình của OpenAI. Khi được sử dụng với các công cụ tùy chỉnh, Responses API sẽ trả quyền kiểm soát lại cho client, và client cần có cơ chế riêng để chạy các công cụ đó. Tuy nhiên, API này cũng có thể tự động điều phối giữa mô hình và các công cụ được lưu trữ sẵn.

Khi Responses API nhận một câu lệnh, nó sẽ tập hợp ngữ cảnh cho mô hình: câu lệnh của người dùng, trạng thái cuộc trò chuyện trước đó, và hướng dẫn về công cụ. Để việc thực thi shell hoạt động, câu lệnh phải đề cập đến việc sử dụng công cụ shell và mô hình được chọn phải được huấn luyện để đề xuất các lệnh shell—các mô hình từ GPT-5.2 trở đi đã được huấn luyện cho việc này. Với tất cả ngữ cảnh này, mô hình sẽ quyết định hành động tiếp theo. Nếu nó chọn thực thi shell, nó sẽ trả về một hoặc nhiều lệnh shell cho dịch vụ Responses API. Dịch vụ API sẽ chuyển tiếp các lệnh đó đến môi trường container, truyền trực tiếp (stream) đầu ra của shell trở lại, và đưa nó vào ngữ cảnh của yêu cầu tiếp theo cho mô hình. Mô hình sau đó có thể kiểm tra kết quả, đưa ra các lệnh tiếp theo, hoặc tạo ra câu trả lời cuối cùng. Responses API lặp lại vòng lặp này cho đến khi mô hình trả về một kết quả hoàn chỉnh mà không có thêm lệnh shell nào.

Tối ưu hóa Hiệu suất và Ngữ cảnh

Thực thi đồng thời và Giới hạn đầu ra

Khi Responses API thực thi một lệnh shell, nó duy trì một kết nối streaming đến dịch vụ container. Khi đầu ra được tạo ra, API sẽ chuyển tiếp nó đến mô hình gần như trong thời gian thực để mô hình có thể quyết định xem nên chờ thêm đầu ra, chạy một lệnh khác, hay chuyển sang phản hồi cuối cùng.

Mô hình có thể đề xuất nhiều lệnh shell trong một bước, và Responses API có thể thực thi chúng đồng thời bằng cách sử dụng các phiên container riêng biệt. Mỗi phiên truyền trực tiếp đầu ra một cách độc lập, và API ghép các luồng đó lại thành các đầu ra công cụ có cấu trúc làm ngữ cảnh. Nói cách khác, vòng lặp của tác tử có thể song song hóa công việc, chẳng hạn như tìm kiếm tệp, lấy dữ liệu, và xác thực các kết quả trung gian.

Khi lệnh liên quan đến các hoạt động tệp hoặc xử lý dữ liệu, đầu ra của shell có thể trở nên rất lớn và tiêu tốn ngân sách ngữ cảnh mà không thêm tín hiệu hữu ích. Để kiểm soát điều này, mô hình chỉ định một giới hạn đầu ra (output cap) cho mỗi lệnh. Responses API thực thi giới hạn đó và trả về một kết quả có giới hạn, bảo toàn cả phần đầu và phần cuối của đầu ra, đồng thời đánh dấu nội dung bị bỏ qua. Ví dụ, bạn có thể giới hạn đầu ra ở 1.000 ký tự, với phần đầu và cuối được giữ lại:

văn bản ở đầu ... 1000 ký tự đã bị cắt ... văn bản ở cuối

Cùng với nhau, việc thực thi đồng thời và giới hạn đầu ra làm cho vòng lặp của tác tử vừa nhanh vừa hiệu quả về mặt ngữ cảnh, để mô hình có thể tiếp tục suy luận trên các kết quả liên quan thay vì bị quá tải bởi các bản ghi terminal thô.

Giải quyết bài toán giới hạn: Nén Ngữ cảnh

Một vấn đề tiềm ẩn với các vòng lặp của tác tử là các tác vụ có thể chạy trong một thời gian dài. Các tác vụ dài hạn sẽ lấp đầy cửa sổ ngữ cảnh (context window), vốn rất quan trọng để cung cấp bối cảnh qua các lượt trò chuyện và giữa các tác tử. Để tránh mất đi ngữ cảnh quan trọng khi tác tử tiếp tục chạy, chúng ta cần một cách để giữ lại các chi tiết chính và loại bỏ những gì không cần thiết. Thay vì yêu cầu các nhà phát triển thiết kế và duy trì các hệ thống tóm tắt hoặc mang trạng thái tùy chỉnh, chúng tôi đã thêm tính năng nén ngữ cảnh gốc (native compaction) vào Responses API, được thiết kế để phù hợp với cách mô hình hoạt động và cách nó được huấn luyện.

Các mô hình mới nhất của chúng tôi được huấn luyện để phân tích trạng thái cuộc trò chuyện trước đó và tạo ra một mục nén (compaction item) bảo toàn trạng thái quan trọng trước đó trong một biểu diễn mã hóa hiệu quả về token. Sau khi nén, cửa sổ ngữ cảnh tiếp theo bao gồm mục nén này và các phần có giá trị cao của cửa sổ trước đó. Điều này cho phép các luồng công việc tiếp tục một cách mạch lạc qua các ranh giới cửa sổ, ngay cả trong các phiên đa bước và sử dụng công cụ kéo dài.

Tính năng nén có sẵn dưới dạng tích hợp sẵn trên máy chủ hoặc thông qua một endpoint /compact độc lập. Việc nén phía máy chủ cho phép bạn cấu hình một ngưỡng, và hệ thống sẽ tự động xử lý thời điểm nén, loại bỏ sự cần thiết của logic phức tạp phía client. Khi quá trình huấn luyện mô hình phát triển, giải pháp nén gốc cũng sẽ phát triển theo với mỗi bản phát hành mô hình của OpenAI.

Một ví dụ thú vị là Codex đã giúp chúng tôi xây dựng hệ thống nén trong khi chính nó là một trong những người dùng đầu tiên. Khi một phiên bản Codex gặp lỗi nén, chúng tôi sẽ khởi động một phiên bản thứ hai để điều tra. Kết quả là Codex đã có được một hệ thống nén gốc, hiệu quả chỉ bằng cách làm việc trên chính vấn đề đó. Khả năng tự kiểm tra và tinh chỉnh của Codex đã trở thành một phần đặc biệt thú vị khi làm việc tại OpenAI.