Vào ngày 10 tháng 9, OpenAI đã chính thức đưa Agents API vào giai đoạn thử nghiệm công khai (public beta), “mang lại cho các nhà phát triển chính khung điều phối (harness) và hạ tầng từng vận hành Codex thông qua một API đơn giản, linh hoạt.” Tại DevDay ngày 29 tháng 9, API này đã có thêm tính năng computer use, một phiên bản tích hợp gốc trên AWS, cùng một người anh em khác: các agent thường trực mới (dots) của ChatGPT cũng chạy trên cùng khung điều phối Codex này.
Nếu nhìn từ góc độ của một nhà phát triển đang xây dựng sản phẩm agent, đây là một tin mừng: bộ khung harness mà bạn từng định tự viết một cách chắp vá giờ đã có người khác lo thay. Nhưng nếu nhìn từ góc độ của một kỹ sư mà đội ngũ đã chạy Claude Code và Codex trên một codebase thực tế, câu hỏi sẽ thay đổi hoàn toàn. API này trả lời cho câu hỏi: “Làm thế nào để duy trì một agent chạy liên tục trong nhiều giờ?” Chứ nó không trả lời câu hỏi: “Làm sao đội ngũ của tôi biết sáu agent đó đã làm những gì, và ai là người phê duyệt trang web mà một trong số chúng vừa đăng nhập vào?” Sharkly ra đời để giải quyết câu hỏi thứ hai này.
Tóm tắt nhanh
Agents API đảm nhận việc vận hành khung điều phối Codex: các phiên bền vững (durable sessions), nén ngữ cảnh (compaction), tìm kiếm công cụ (tool search), các agent con (subagents), và môi trường sandbox do OpenAI, hạ tầng của bạn hoặc chín đối tác cung cấp, hoàn toàn không thu thêm phí nào ngoài chi phí token, công cụ và thời gian chạy container. Sự kiện DevDay đã bổ sung tính năng computer use — nơi ứng dụng của bạn phê duyệt từng domain trang web mới cùng mọi lượt đăng nhập (việc phê duyệt domain không đồng nghĩa với việc xác nhận từng hành động riêng lẻ) — và Bedrock Managed Agents, giúp chạy các khả năng cốt lõi này ngay bên trong AWS. Tuy nhiên, toàn bộ các giải pháp này đều không quản lý tầng làm việc nhóm (team layer): ai giao việc, agent nào đang nhận việc, việc gì đã hoàn thành, việc gì thất bại và ai là người nghiệm thu kết quả.
Agents API là gì và OpenAI thực sự vận hành những gì
Tài liệu tổng quan của OpenAI cô đọng API này thành bốn khái niệm cốt lõi. Một Agent là “mô hình, chỉ dẫn, công cụ và các MCP server khả dụng cho agent đó.” Một Environment là “một sandbox hoặc máy tính tùy chọn, nơi agent truy cập tệp tin, nạp kỹ năng và chạy lệnh.” Một Session là “một phiên thực thi bền bỉ của agent để thực hiện tác vụ và phản hồi dữ liệu đầu vào.” Events and items là dữ liệu đầu vào bạn gửi đi cùng kết quả đầu ra nhận về.
Bạn tạo một phiên với cấu hình agent tương ứng, giao việc cho nó khi môi trường đã sẵn sàng, theo dõi tiến trình qua luồng dữ liệu (streaming) hoặc webhook, sau đó tiếp tục gửi thêm tác vụ hoặc điều hướng ngay trong cùng phiên làm việc đó. Ví dụ rút gọn từ tài liệu chính thức:
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
Hai dòng code mang nhiều ý nghĩa nhất ở đây: multi_agent cho phép phân nhánh các agent con với giới hạn đồng thời, và environment.type quyết định nơi thực thi mã lệnh: openai_hosted, self_hosted, hoặc một trong các sandbox từ đối tác (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel).
Tài liệu đã tóm gọn sự phân chia trách nhiệm này trong một câu: “OpenAI quản lý các phiên làm việc, việc điều phối, nén ngữ cảnh và phục hồi lỗi, trong khi ứng dụng của bạn cung cấp các công cụ và lựa chọn môi trường thực thi.”
| OpenAI đảm nhiệm | Bạn vẫn phải tự chuẩn bị |
|---|---|
| Vòng lặp agent: gọi mô hình, sử dụng công cụ, thử lại khi lỗi | Tác vụ cần làm và tiêu chuẩn hoàn thành (definition of done) |
| Nén ngữ cảnh khi phiên làm việc chạm ngưỡng giới hạn | Công cụ: MCP server, hàm (functions), công cụ tích hợp sẵn |
| Tìm kiếm và nạp công cụ | Thông tin xác thực (credentials), thông qua vault ID |
| Chia nhỏ tác vụ và điều phối agent con | Lựa chọn môi trường thực thi và thiết lập môi trường đó |
| Khôi phục phiên làm việc và điều hướng thực thi | Tất cả những gì diễn ra sau khi phiên làm việc kết thúc |
Chi phí sử dụng mô hình được tính theo biểu giá API của mô hình đó, công cụ tính theo giá chuẩn, và sandbox do OpenAI lưu trữ tính theo giá container; bài viết ra mắt khẳng định “không có thêm phụ phí nào khi sử dụng Agents API.” Có hai ranh giới được nêu rõ ràng trong tài liệu: API này “hiện chỉ hỗ trợ lưu trữ dữ liệu tại Hoa Kỳ và không hỗ trợ chính sách không lưu giữ dữ liệu (Zero Data Retention - ZDR)”, và việc chọn sandbox tự lưu trữ (self-hosted) cũng không giúp bạn đủ điều kiện áp dụng ZDR. Nếu một trong hai yếu tố này ảnh hưởng đến chính sách tuân thủ của doanh nghiệp, thì việc tự vận hành sandbox tại nội bộ cũng không thay đổi được thực tế đó.
Những điểm mới được bổ sung tại DevDay
Computer use. Thêm công cụ computer_use, bật giao diện máy tính trên môi trường do OpenAI lưu trữ, và agent có thể điều khiển một trình duyệt chuyên dụng. Hướng dẫn computer use xây dựng luồng hoạt động xoay quanh các sự kiện phê duyệt (approval events). Trình duyệt sẽ yêu cầu người dùng phê duyệt trước mỗi domain trang web mới, bao gồm cả các trang công khai. Các yêu cầu đăng nhập được gửi về dưới dạng yêu cầu riêng biệt để ứng dụng của bạn hiển thị trường nhập email, mật khẩu và mã xác minh; API không hỗ trợ passkey hay đăng nhập qua mã QR, và chỉ có agent chính mới có quyền yêu cầu thông tin xác thực, agent con thì không. Câu nói bạn cần đọc kỹ hai lần: “Việc phê duyệt domain không áp dụng xác nhận cho từng hành động riêng lẻ.” Đối với các tác vụ mua sắm hoặc thao tác có tính hủy hoại, tài liệu khuyên bạn nên giới hạn trình duyệt lưu trữ không truy cập được vào các tài nguyên đó, hoặc sử dụng một môi trường trình duyệt do chính bạn kiểm soát. Bản tóm tắt DevDay liệt kê computer use “thông qua API cũng như trong Codex và ChatGPT Work trên các gói Pro 500 và Enterprise.”
Bedrock Managed Agents, vận hành bởi OpenAI. OpenAI và Amazon đã kết hợp “các khả năng cốt lõi của Agents API” và tùy biến để hoạt động nguyên bản trong hệ sinh thái AWS. Trang sản phẩm của AWS hiện gắn nhãn bản dùng thử (preview) và cho biết môi trường thực thi agent cũng như suy luận mô hình hoàn toàn nằm trong AWS, với mỗi agent sở hữu định danh và quyền hạn AWS riêng biệt.
Các dot chạy trên cùng một khung điều phối. Decrypt đưa tin rằng khung harness của Codex “hiện đang vận hành các dot và đã được mở mã nguồn.” Dot là các agent hoạt động liên tục của ChatGPT, mỗi dot sở hữu một máy tính đám mây riêng, và bài giải thích chi tiết về dot của chúng tôi đã phân tích cụ thể những điểm mạnh của tính năng này.
Như vậy, giờ đây một vòng lặp duy nhất có thể vận hành một coding agent, một phiên API, một AWS agent và một trợ lý luôn trực tuyến. Khung điều phối đang dần quy về một mối. Nhưng các sự kiện phê duyệt mới chính là phần đổ dồn áp lực lên đội ngũ phát triển: mỗi sự kiện là một câu hỏi trong một phiên làm việc, được trả lời bởi bất kỳ ai đang giữ kết nối stream đó. Khi có năm phiên cùng đặt câu hỏi, ai đó sẽ phải quyết định ai được phép duyệt domain nào, và quyết định đó được lưu lại ở đâu. Đó chính là bài toán về cổng phê duyệt (approval gates), và chúng tôi đã phân tích phiên bản xử lý trên Computer trong bài viết hàng rào bảo vệ cho tính năng computer use của GPT-6 Astra.
Phần bị bỏ ngỏ: Tầng làm việc nhóm
Một phiên làm việc chỉ biết đến chính nó. Nó không thể biết ba phiên khác đang cùng tác động vào một repository, hay kết quả của phiên thứ tư đã nằm chờ mốc meo từ hôm thứ Ba. Đó là những bài toán quản lý, và chúng xuất hiện ngay khoảnh khắc có nhiều hơn một người kích hoạt nhiều hơn một agent.
Có năm câu hỏi mà API này chủ động để ngỏ:
- Ai là người giao tác vụ này, và nó gắn với ticket nào? Một phiên làm việc chỉ có một ID và bất kỳ metadata nào do code của bạn ghi vào. Người phụ trách, Sprint hay đường dẫn liên kết đến issue gốc sẽ không tồn tại trừ khi bạn tự gắn vào đó.
- Nó đã thay đổi repository và branch nào? Phần thay đổi code (diff) cần phải được đưa đến một nơi mà reviewer có thể đọc được.
- Cái gì đã xong, cái gì thất bại, cái gì đang phải chờ? Các sự kiện chỉ được phát trực tiếp khi bạn lắng nghe, hoặc gửi qua webhook. Không có cơ chế nào gom chúng thành một hàng đợi kết quả để chờ con người xử lý.
- Ai là người nghiệm thu kết quả? Một sự kiện phê duyệt chỉ bao gồm việc truy cập trang web hoặc đăng nhập, chứ không bao gồm chất lượng công việc. “Phiên làm việc đã kết thúc” và “một ai đó đã đọc bằng chứng và bấm duyệt” sẽ chỉ là cùng một sự kiện, trừ khi bạn tự xây dựng bước thứ hai này.
- Thế còn những agent không thuộc OpenAI thì sao? Việc dùng Claude Code cho một loại công việc và Codex cho một loại khác đồng nghĩa với việc bạn có hai mô hình phiên làm việc và hai nơi riêng biệt để theo dõi.
Bạn có thể tự xây dựng cả năm yếu tố này dựa trên các sự kiện: một bảng theo dõi, một webhook, một trường trạng thái, một cột review. Nhưng rồi ai đó sẽ hỏi: “Chúng ta đã bao giờ triển khai bản sửa lỗi export chưa?”, và câu trả lời lại nằm chôn vùi trong lịch sử cuộn màn hình mà chẳng ai lưu lại. Bài viết về quản lý tác vụ cho AI agent của chúng tôi đã phân tích kỹ phương án tự xây dựng này.
Agent con trong một phiên, hay Task riêng trên bảng công việc?
Tùy chọn max_concurrent_subagents là lời giải của API cho bài toán xử lý song song, và nó rất hiệu quả cho đúng dạng công việc phù hợp. Đó cũng chính là sự đánh đổi mà chúng tôi đã từng đề cập khi Codex nâng giới hạn agent con lên 64: các agent con cùng chia sẻ một tiến trình cha, báo cáo kết quả về một phản hồi tổng hợp duy nhất, và được đánh giá như một kết quả thống nhất.
Hãy dùng các agent con bên trong một phiên làm việc khi công việc thiên về đọc dữ liệu, mang tính độc lập và bạn chỉ cần câu trả lời tổng hợp cuối cùng: tìm hiểu bốn API khác nhau, quét toàn bộ codebase để tìm một mẫu pattern, hoặc thu thập bằng chứng cho một sự cố.
Hãy dùng các Task riêng biệt khi từng phần việc phải viết code và cần có người review độc lập: một tác vụ migration, một tính năng trên một module cụ thể, hay một bản sửa lỗi tác động vào tệp tin dùng chung. Trong Sharkly, mỗi lượt chạy sẽ nhận được một git worktree tách biệt trên một Computer thuộc sở hữu của bạn, và mỗi kết quả sẽ trả về đúng Task của nó cùng bản diff, log thực thi và reviewer tương ứng. Việc gộp bốn thay đổi lớn về code vào trong một bản tóm tắt của agent con chẳng khác nào giấu bốn quyết định quan trọng bên trong một chỗ.
Các câu hỏi thường gặp
Tính năng computer use chạy trên mô hình nào? Các ví dụ trong tài liệu sử dụng gpt-6-astra. Hãy kiểm tra lại tài liệu hướng dẫn trước khi mặc định rằng các mô hình khác cũng tương thích với công cụ computer_use.
Sharkly có chạy các phiên Agents API không? Sharkly chạy các CLI coding agent được cài đặt trực tiếp trên Computer của bạn (chẳng hạn như Codex và Claude Code) dưới dạng các Runtime. Các phiên Agents API là một dịch vụ lưu trữ đám mây (hosted service) chứ không phải là một Runtime được cài đặt, vì vậy hãy coi chúng là một luồng thực thi hoàn toàn riêng biệt.
Việc con người review diễn ra ở đâu? Với Agents API, nó diễn ra ở bất cứ nơi nào bạn tự xây dựng: các sự kiện phê duyệt chỉ bao gồm quyền truy cập trang web và đăng nhập, chứ không bao gồm việc nghiệm thu kết quả công việc. Trong Sharkly, một Agent có thể chuyển Task của mình về trạng thái chờ người review, yêu cầu đó sẽ xuất hiện ngay trong Hộp thư đến (Inbox) của người chịu trách nhiệm, và người đó sẽ cập nhật trạng thái sau khi đã xem xét câu trả lời, log thực thi và bản diff.
Vị trí phù hợp cho từng tầng công nghệ
Một phiên làm việc bền vững trên hạ tầng của OpenAI là đối tượng tiện lợi nhất trong đợt ra mắt này, nhưng cũng là thứ mang tính ràng buộc (lock-in) cao nhất. Đối với một đội ngũ kỹ thuật, điều này rất đáng lưu tâm, bởi coding agent mạnh nhất luôn thay đổi theo thời gian. Một đội ngũ mà trạng thái review và quy tắc phân chia công việc phụ thuộc hoàn toàn vào kho lưu trữ phiên của một nhà cung cấp sẽ phải đập đi xây lại toàn bộ quy trình làm việc mỗi khi có một công cụ khác vươn lên dẫn đầu.
Nếu bạn đang xây dựng một sản phẩm ứng dụng agent hoặc một dịch vụ backend, Agents API chính là tầng phù hợp, và Bedrock Managed Agents cũng là một lựa chọn tương tự cho các đội ngũ cần vận hành bên trong AWS. Bạn có được bộ khung điều phối mà không cần tốn công bảo trì, có được sandbox mà không cần nhọc công cấp phát. Thậm chí bạn có thể chẳng cần đến một bảng quản lý tác vụ nào; chính ứng dụng của bạn đã là bảng việc đó rồi.
Nhưng nếu các agent đóng vai trò như những thành viên trong nhóm làm việc trên chính codebase của bạn — do con người vận hành, con người review, triển khai qua các repository và hệ thống theo dõi hiện có — thì bài toán lúc này đã hoàn toàn khác. Codex và Claude Code sẽ đảm nhận việc thực thi. Sharkly quản lý việc phân chia nhiệm vụ ở cấp độ nhóm, các Computer kết nối, ngữ cảnh tác vụ, tiến độ, các điểm nghẽn, kết quả và quy trình review của con người trên tất cả các công cụ đó. Nó không nhằm thay thế cho bất kỳ Runtime nào, cũng không thay thế cho Agents API. Câu hỏi tương tự về vị trí triển khai này cũng đang áp dụng cho chính Codex, điều mà chúng tôi đã phân tích trong bài viết Codex đám mây so với máy tính tự quản lý.
Hãy thuê khung điều phối nếu bạn đang xây dựng một agent. Nhưng hãy giữ quyền kiểm soát tầng quản lý cho riêng mình — và hoàn toàn độc lập với các nhà cung cấp — nếu bạn đang quản lý các agent đó.
Nếu bạn đã và đang vận hành nhiều agent, Sharkly mang đến cho bạn một nơi duy nhất để quản lý toàn bộ tác vụ và kết quả của chúng. Sharkly không bán token: chi phí sử dụng mô hình vẫn được tính qua gói thuê bao hoặc API key được cấu hình trực tiếp trong các công cụ mà bạn kết nối.
