Bỏ qua nội dung chính
OpenAI

11 tháng 3, 2026

Kỹ thuật

Từ mô hình đến tác nhân: Trang bị cho API Phản hồi một môi trường máy tính

Bởi Bo Xu, Danny Zhang và Rohit Arunachalam

Đang tải…

Hiện tại, chúng tôi đang chuyển từ việc sử dụng các mô hình, vốn xuất sắc trong các tác vụ cụ thể, sang việc sử dụng các tác nhân có khả năng xử lý các quy trình công việc phức tạp. Bằng cách đưa ra lời nhắc cho các mô hình, bạn chỉ có thể truy cập trí tuệ đã được huấn luyện. Tuy nhiên, việc cung cấp cho mô hình một môi trường máy tính có thể đáp ứng phạm vi trường hợp sử dụng rộng hơn nhiều, như chạy các dịch vụ, yêu cầu dữ liệu từ các API, hoặc tạo ra các tạo phẩm hữu ích hơn như bảng tính hoặc báo cáo.

Một vài vấn đề thực tế nảy sinh khi bạn cố gắng xây dựng các tác nhân: đặt các tệp trung gian ở đâu, làm thế nào để tránh dán các bảng lớn vào một câu lệnh, làm thế nào để cung cấp cho quy trình làm việc quyền truy cập mạng mà không tạo ra cơn đau đầu về bảo mật, và làm thế nào để xử lý thời gian chờ và thử lại mà không phải tự xây dựng một hệ thống quy trình làm việc.

Thay vì để các nhà phát triển tự xây dựng môi trường thực thi của riêng họ, chúng tôi đã xây dựng các thành phần cần thiết để trang bị cho Responses API(mở trong cửa sổ mới) một môi trường máy tính nhằm thực thi các tác vụ thực tế một cách đáng tin cậy.

Responses API của OpenAI, cùng với công cụ shell và một không gian làm việc container được lưu trữ, được thiết kế để giải quyết những vấn đề thực tế này. Mô hình đề xuất các bước và lệnh; nền tảng chạy chúng trong một môi trường tách biệt với một hệ thống tệp cho đầu vào và đầu ra, lưu trữ có cấu trúc tùy chọn (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 xây dựng một môi trường máy tính cho các tác nhân và chia sẻ một số bài học ban đầu về cách sử dụng nó để có quy trình làm việc nhanh hơn, dễ lặp lại hơn và an toàn hơn trong môi trường sản xuất.

Công cụ shell

Một quy trình làm việc tác nhân tốt bắt đầu với 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 tìm nạp dữ liệu bằng API, nền tảng chạy hành động đó và kết quả được đưa vào 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 để xem vòng lặp này hoạt động—và sau đó đề cập đến không gian làm việc của container, mạng, các kỹ năng có thể tái sử dụng và việc nén ngữ cảnh.

Để hiểu công cụ shell, trước tiên sẽ hữu ích nếu hiểu cách một mô hình ngôn ngữ sử dụng các công cụ nói chung: để làm những 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ột mô hình được cho xem các ví dụ về cách các công cụ được sử dụng và các tác động tạo ra, 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 nên sử dụng một công cụ và cách sử dụng nó. Khi chúng tôi nói “sử dụng một công cụ”, ý chúng tôi là mô hình thực ra chỉ đề xuất một lệnh gọi công cụ. Nó không thể tự thực hiện lệnh gọi.

Công cụ shell "chỉ là một công cụ khác" kèm theo sơ đồ

Công cụ shell giúp mô hình 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 nhiều loại tác vụ, từ tìm kiếm văn bản đến gửi các 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, curlawk được tích hợp sẵn.

So với trình thông dịch mã hiện có của chúng tôi, vốn chỉ thực thi Python, công cụ shell cho phép phạm vi trường hợp sử 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. Tính linh hoạt này cho phép mô hình hoàn thành các tác vụ tự chủ phức tạp.

Điều phối vòng lặp tác nhân

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

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

Khi Responses API nhận được một câu lệnh, nó sẽ tập hợp ngữ cảnh 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à các hướng dẫn 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 and 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 GPT‑5.2 trở lên được huấn luyện cho việc này. Với tất cả ngữ cảnh này, mô hình sau đó 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 chuyển tiếp các lệnh đó đến runtime container, truyền trực tuyến đầu ra shell trở lại và đưa nó vào mô hình trong ngữ cảnh của yêu cầu tiếp theo. Sau đó, mô hình có thể kiểm tra kết quả, đưa ra các lệnh theo dõi hoặc tạo ra một 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ề trạng thái hoàn thành mà không có thêm lệnh shell.

Sơ đồ vòng lặp tác nhân: Responses API điều phối việc thực thi mô hình và shell trong container

Khi Responses API thực thi một lệnh shell, nó duy trì một kết nối truyền trực tuyến tới dịch vụ của container. Khi đầu ra được tạo ra, API chuyển tiếp nó đến mô hình gần như theo thời gian thực để mô hình có thể quyết định liệu có 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.

Đầu ra thực thi lệnh shell truyền trực tuyến

Responses API truyền phát đầu ra lệnh shell

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 phát trực tuyến đầu ra một cách độc lập, và API ghép kênh các luồng đó trở lại thành Dữ liệu đầu ra công cụ có cấu trúc dưới dạng ngữ cảnh. Nói cách khác, vòng lặp tác nhân có thể song song hóa công việc, chẳng hạn như tìm kiếm tệp, tìm nạp dữ liệu và xác thực các kết quả trung gian.

API Phản hồi ghép kênh các phiên thực thi lệnh

Khi lệnh liên quan đến các thao tác tệp hoặc xử lý dữ liệu, đầu ra 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 cho mỗi lệnh. Responses API áp dụng giới hạn đó và trả về một kết quả bị 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ị lược bỏ. Ví dụ, bạn có thể giới hạn đầu ra ở 1000 ký tự, với phần đầu và phần cuối được giữ nguyên:

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

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

Khi cửa sổ ngữ cảnh đầy: nén

Một vấn đề tiềm ẩn với các vòng lặp tác nhân là các nhiệm vụ có thể chạy dài hạn. Các tác vụ chạy lâu lấp đầy cửa sổ ngữ cảnh, điều này quan trọng để cung cấp ngữ cảnh xuyên suốt các lượt và giữa các tác nhân. Hãy hình dung một tác nhân gọi một kỹ năng, nhận phản hồi, thêm các lần gọi công cụ và các bản tóm tắt suy luận—cửa sổ ngữ cảnh giới hạn nhanh chóng bị lấp đầy. Để tránh làm mất ngữ cảnh quan trọng khi tác nhân tiếp tục chạy, chúng ta cần một cách để giữ lại các chi tiết then chốt và loại bỏ mọi thứ 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 gốc trong 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 giúp bảo toàn trạng thái quan trọng trước đó trong một biểu diễn được 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 quy trình làm 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 mở rộng nhiều bước và do công cụ điều khiển. Codex dựa vào cơ chế này để duy trì các nhiệm vụ lập trình chạy dài hạn và việc thực thi công cụ lặp lại mà không làm suy giảm chất lượng.

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 điểm cuối `/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 tự động xử lý thời điểm nén, loại bỏ nhu cầu về logic phức tạp phía máy khách. Nó cho phép một cửa sổ ngữ cảnh đầu vào hiệu quả lớn hơn một chút để chịu được các phần vượt quá nhỏ ngay trước khi nén, vì vậy các yêu cầu gần giới hạn vẫn có thể được xử lý và nén thay vì bị từ chối. 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 phát triển theo cho mọi lần phát hành mô hình OpenAI.

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

Ngữ cảnh của container

Bây giờ, hãy cùng tìm hiểu về trạng thái và tài nguyên. Container không chỉ là nơi để chạy lệnh mà còn là ngữ cảnh làm việc cho mô hình. Bên trong container, mô hình có thể đọc tệp, truy vấn cơ sở dữ liệu và truy cập các hệ thống bên ngoài theo các biện pháp kiểm soát chính sách mạng.

Một sơ đồ hiển thị bên trong runtime container: Tệp, cơ sở dữ liệu, kỹ năng và một mạng được kiểm soát bởi chính sách

Hệ thống tệp

Phần đầu tiên của bối cảnh container là hệ thống tệp để tải lên, sắp xếp và quản lý tài nguyên. Chúng tôi đã xây dựng các API container và tệp(mở trong cửa sổ mới) để cung cấp cho mô hình một bản đồ về dữ liệu sẵn có và giúp mô hình chọn các thao tác tệp có mục tiêu thay vì thực hiện các lượt quét rộng, gây nhiễu.

Một mẫu chống phổ biến là nhồi nhét toàn bộ đầu vào trực tiếp vào ngữ cảnh câu lệnh. Khi các đầu vào tăng lên, việc nhồi nhét quá nhiều vào câu lệnh trở nên tốn kém và khó để mô hình điều hướng. Một mẫu hình tốt hơn là dàn dựng các tài nguyên trong hệ thống tệp của container và để mô hình quyết định những gì cần mở, phân tích hoặc chuyển đổi bằng các lệnh shell. Cũng giống như con người, các mô hình hoạt động tốt hơn với thông tin được tổ chức.

Cơ sở dữ liệu

Phần thứ hai của ngữ cảnh container là cơ sở dữ liệu. Trong nhiều trường hợp, chúng tôi đề xuất các nhà phát triển lưu trữ dữ liệu có cấu trúc trong cơ sở dữ liệu dưới dạng SQLite và truy vấn chúng. Thay vì sao chép toàn bộ một bảng tính vào câu lệnh, chẳng hạn, bạn có thể cung cấp cho mô hình một mô tả về các bảng—có những cột nào và chúng có ý nghĩa gì—và để nó trích xuất các hàng mà nó cần.

Ví dụ: nếu bạn hỏi, “Sản phẩm nào có doanh số giảm trong quý này?” thì mô hình có thể truy vấn chỉ các hàng liên quan thay vì quét toàn bộ bảng tính. Điều này nhanh hơn, rẻ hơn, có khả năng mở rộng hơn cho các tập dữ liệu lớn hơn.

Quyền truy cập mạng 

Phần thứ ba của ngữ cảnh container là quyền truy cập mạng, một phần thiết yếu trong khối lượng công việc của tác nhân. Quy trình làm việc của tác nhân có thể cần lấy dữ liệu trực tiếp, gọi các API bên ngoài hoặc cài đặt các gói. Đồng thời, việc cấp cho các container quyền truy cập internet không bị hạn chế có thể tiềm ẩn rủi ro: nó có thể làm lộ thông tin ra các trang web bên ngoài, vô tình chạm tới các hệ thống nội bộ nhạy cảm hoặc hệ thống của bên thứ ba, hoặc khiến việc phòng vệ trước rò rỉ thông tin xác thực và đánh cắp dữ liệu trở nên khó khăn hơn.

Để xử lý những vấn đề này mà vẫn giữ nguyên tính hữu ích của các tác nhân, chúng tôi triển khai các container chạy kèm một proxy egress theo mô hình sidecar Tất cả các yêu cầu mạng đi ra đều đi qua một lớp chính sách tập trung, lớp này thực thi danh sách được phép và kiểm soát truy cập, đồng thời vẫn đảm bảo lưu lượng có thể quan sát được. Đối với thông tin xác thực, chúng tôi sử dụng cơ chế chèn bí mật theo phạm vi miền tại điểm egress. Mô hình và container chỉ thấy các trình giữ chỗ, trong khi các giá trị bí mật thô vẫn nằm ngoài ngữ cảnh mà mô hình có thể thấy và chỉ được áp dụng cho các đích đến đã được phê duyệt. Điều này giúp giảm nguy cơ rò rỉ trong khi vẫn cho phép các lệnh gọi bên ngoài đã được xác thực.

Sơ đồ truy cập mạng được kiểm soát thông qua proxy egress: thiết lập container

Kỹ năng của tác nhân

Các lệnh shell rất mạnh mẽ, nhưng nhiều tác vụ lặp lại cùng một mẫu bao gồm nhiều bước. Các tác nhân phải khám phá lại luồng công việc mỗi lần chạy—lập kế hoạch lại, phát hành lại lệnh và học lại các quy ước—dẫn đến kết quả không nhất quán và lãng phí thời gian thực thi. Kỹ năng tác nhân(mở trong cửa sổ mới) đóng gói các mẫu đó thành các khối nền tảng có thể tái sử dụng, có thể kết hợp. Cụ thể, một kỹ năng là một gói thư mục bao gồm ‘SKILL.md(mở trong cửa sổ mới)’ (chứa siêu dữ liệu và hướng dẫn) cộng với mọi tài nguyên hỗ trợ, chẳng hạn như đặc tả API và tài nguyên UI.

Cấu trúc này ánh xạ tự nhiên tới kiến trúc thời gian chạy mà chúng tôi đã mô tả trước đó. Container cung cấp các tệp liên tục và ngữ cảnh thực thi, còn công cụ shell cung cấp giao diện thực thi. Khi cả hai đã sẵn sàng, mô hình có thể khám phá các tệp kỹ năng bằng các lệnh shell (`ls`, `cat`, etc.) khi cần, diễn giải hướng dẫn và chạy các tập lệnh kỹ năng, tất cả trong cùng một vòng lặp tác nhân.

Chúng tôi cung cấp API(mở trong cửa sổ mới) để quản lý các kỹ năng trên nền tảng OpenAI. Nhà phát triển tải lên và lưu trữ các thư mục kỹ năng dưới dạng các gói được phiên bản hóa, sau đó có thể truy xuất bằng ID kỹ năng. Trước khi gửi câu lệnh đến mô hình, API Phản hồi tải kỹ năng và đưa kỹ năng đó vào ngữ cảnh mô hình. Trình tự này mang tính xác định:

  1. Tìm siêu dữ liệu kỹ năng, bao gồm tên và mô tả.
  2. Tìm gói kỹ năng, sao chép gói đó vào container và giải nén gói đó.
  3. Cập nhật ngữ cảnh mô hình với siêu dữ liệu kỹ năng và đường dẫn của container.

Khi quyết định xem một kỹ năng có liên quan hay không, mô hình dần dần khám phá các hướng dẫn của nó và thực thi các tập lệnh của nó thông qua các lệnh shell trong container.

Sơ đồ quy trình tải kỹ năng: sổ đăng ký, gói, thời gian chạy

Cách tạo ra tác nhân

Để ghép tất cả các mảnh lại với nhau: Responses API cung cấp điều phối, công cụ shell cung cấp các hành động có thể thực thi, container được lưu trữ cung cấp ngữ cảnh thời gian chạy bền vững, kỹ năng xếp lớp logic quy trình làm việc có thể tái sử dụng, và nén cho phép một tác nhân chạy trong thời gian dài với ngữ cảnh mà nó cần.

Với các nguyên thủy này, một câu lệnh duy nhất có thể mở rộng thành một quy trình làm việc từ đầu đến cuối: khám phá kỹ năng phù hợp, tìm nạp dữ liệu, chuyển đổi dữ liệu thành trạng thái có cấu trúc cục bộ, truy vấn dữ liệu đó một cách hiệu quả và tạo ra các tạo phẩm bền vững. 

Sơ đồ dưới đây cho thấy cách hệ thống này hoạt động để tạo bảng tính từ dữ liệu trực tiếp.

Sơ đồ vòng đời yêu cầu: từ một câu lệnh đến các tạo phẩm bền vững, khám phá kỹ năng

Responses API điều phối tác vụ của tác nhân

Tạo tác nhân của riêng bạn

Để xem một ví dụ chuyên sâu về cách kết hợp công cụ shell và môi trường máy tính cho các quy trình làm việc từ đầu đến cuối, hãy xem bài đăng trên blog dành cho nhà phát triển(mở trong cửa sổ mới)cẩm nang cookbook(mở trong cửa sổ mới) của chúng tôi, hướng dẫn cách đóng gói một kỹ năng và thực thi nó thông qua Responses API.

Chúng tôi rất mong chờ xem các nhà phát triển sẽ xây dựng được những gì với bộ thành phần cơ bản này. Các mô hình ngôn ngữ được thiết kế để làm nhiều hơn là tạo ra văn bản, hình ảnh và âm thanh–chúng tôi sẽ tiếp tục phát triển nền tảng của mình để trở nên có năng lực hơn trong việc xử lý các tác vụ phức tạp trong thế giới thực ở quy mô lớn.

Tác giả

Bo Xu, Danny Zhang, Rohit Arunachalam