Ngày 10/9, OpenAI đưa Agents API từ giai đoạn private preview ra bản beta công khai, không cần waitlist. Ý tưởng rất đơn giản: toàn bộ harness đứng sau Codex — quản lý session, nén context, chạy code trong sandbox, phục hồi khi lỗi, phân tán việc cho subagent — giờ là một dịch vụ được quản lý (managed service) mà bạn gọi thay vì một hệ thống bạn phải tự xây.

Nếu bạn đã dành cả năm qua để tự viết tay vòng lặp agent, đây là thứ đáng bỏ ra hai mươi phút để đọc kỹ, vì nó thay đổi bài toán “mua hay tự xây” cho một mảng hạ tầng mà rất nhiều team đang âm thầm làm đi làm lại.

Bên trong hộp có gì

API được xây quanh bốn đối tượng:

  • Agent — model, instructions, tools, và các MCP server được gắn vào. Đây là config, không phải trạng thái runtime.
  • Environment — sandbox tùy chọn (một container thật) nơi agent có thể chạy code, sửa file, dùng filesystem.
  • Session — cuộc hội thoại có trạng thái, bền vững. OpenAI giữ nó sống qua nhiều lượt, nén context khi đầy, và khôi phục lại sau khi crash hoặc timeout.
  • Events — luồng sự kiện mà session phát ra: tool call, output từng phần, subagent được sinh ra, lỗi.

Đó chính là kiến trúc mà Codex đã dùng nội bộ từ lâu. Điều mới là giờ nó có thể được gọi từ bên ngoài sản phẩm của OpenAI.

from openai import OpenAI

client = OpenAI()

agent = client.agents.create(
    model="gpt-6-astra",
    instructions="Bạn là release engineer. Điều tra các CI run bị fail, "
                 "đề xuất fix, và mở PR. Không bao giờ merge thẳng vào main.",
    tools=["web_search", "code_interpreter"],
    mcp_servers=["github", "internal-ci-status"],
)

session = client.agents.sessions.create(
    agent=agent.id,
    environment={"type": "sandbox", "image": "ci-debug-base"},
)

run = client.agents.sessions.run(
    session_id=session.id,
    input="CI run #48213 fail trên pipeline payments-service. Điều tra giúp.",
)

for event in run.stream():
    if event.type == "tool_call":
        print(f"[{event.tool}] {event.arguments}")
    elif event.type == "subagent_spawned":
        print(f"subagent mới: {event.role}")

So với những gì hầu hết các team đang tự duy trì: một queue cho session bền vững, một bước tóm tắt khi context tràn, một lớp orchestration container cho việc chạy code, và logic retry viết tay cho lúc model call bị timeout giữa chừng khi đang gọi tool. Đó là bốn hệ thống con được gộp lại thành một bề mặt API duy nhất.

Chi tiết đáng chú ý nhất với dân kiến trúc: subagent có giới hạn concurrency

Điều tôi muốn nhấn mạnh với bất kỳ Tech Lead nào đang đánh giá công cụ này là: session có thể phân tán việc cho các subagent với một trần concurrency có thể cấu hình được. Đây chính là phần mà hầu hết các framework agent tự xây trong công ty làm sai — hoặc mọi thứ chạy tuần tự (chậm, phí mất ý nghĩa của việc có nhiều tool), hoặc mọi thứ chạy song song không giới hạn (chi phí tăng vọt, bị rate-limit dồn dập, race condition trên state dùng chung).

Có một trần concurrency được quản lý ở cấp session nghĩa là bạn set giới hạn một lần — ví dụ bốn subagent chạy đồng thời — và harness sẽ tự áp dụng backpressure thay vì code ứng dụng của bạn phải tự làm việc đó. Nếu bạn từng debug một lỗi fan-out mà mười hai subagent cùng lúc cố ghi vào một file, bạn sẽ hiểu tại sao đây không phải tính năng nhỏ.

Cái gì bị thay thế, cái gì thì không

Bị thay thế:

  • Lưu trữ session tự viết (state hội thoại backed bởi Redis/Postgres)
  • Quản lý cửa sổ context thủ công (logic tóm tắt-khi-đầy)
  • Cấp phát sandbox để chạy code (trước đây có thể bạn đang tự chạy container Firecracker hoặc gVisor)
  • Logic retry/phục hồi cho các lượt chạy agent kéo dài

Không bị thay thế:

  • Tool và MCP server thực tế — bạn vẫn phải tự viết và sở hữu chúng
  • Evals của bạn — một harness được quản lý giúp bạn deploy một agent lỗi nhanh hơn, không phải khó hơn
  • Quyết định về data residency và compliance — sandbox chạy trên hạ tầng của OpenAI, điều này không chấp nhận được với một số workload có quy định chặt (đây cũng là lý do chúng tôi vẫn tự host eval harness cho các team không thể gửi code cho bên thứ ba thực thi)
  • Xử lý sự cố (incident response) — khi một subagent đi lệch hướng trong production, bạn vẫn là người bị page

Tôi sẽ triển khai cái này ở đâu

Với một công cụ nội bộ — ví dụ agent triage CI, agent phân loại ticket hỗ trợ, bot review PR — cái này gộp nhiều tuần công việc hạ tầng thành một buổi chiều. Mô hình giá (tính theo usage, không phí platform) khiến việc thử nghiệm ít rủi ro: bạn có thể chạy song song với vòng lặp agent tự viết hiện có và so sánh trực tiếp chi phí lẫn độ trễ.

Với bất cứ thứ gì hướng tới khách hàng và có yêu cầu compliance, tôi sẽ đối xử với nó giống cách chúng tôi đối xử với mọi “managed agent runtime” từ trước tới giờ: hữu ích cho 80% là hạ tầng không khác biệt, chưa đủ cho 20% còn lại là logic cạnh tranh thực sự và bề mặt rủi ro thực sự của bạn. Sai lầm tôi từng thấy các team mắc phải với các thế hệ harness trước (LangGraph Platform, Bedrock Agents, và giờ là cái này) là cố để lớp được quản lý quyết định những thứ nó không có đủ ngữ cảnh để quyết định — cổng phê duyệt, giới hạn chi tiêu, chính sách escalation. Giữ những thứ đó ở lớp ứng dụng của bạn, trước khi gọi API, không phải bên trong nó.

Tín hiệu lớn hơn

Điều thú vị không nằm ở bản thân API — mà ở việc nó nói lên điều gì về việc ngành này nghĩ “moat” (lợi thế cạnh tranh) đang nằm ở đâu. OpenAI sẵn sàng thương mại hóa cái harness của agent (xử lý session, sandbox, nén context) vì giá trị thực sự đã dịch chuyển lên một lớp cao hơn — vào khả năng phán đoán của model và vào những tool, dữ liệu độc quyền mà agent của bạn có quyền truy cập. Điều này khớp với xu hướng chúng ta thấy suốt cả năm nay: phần hạ tầng đang rẻ đi và chuẩn hóa hơn, còn sự khác biệt đang dịch chuyển sang context engineering và thiết kế tool. Nếu bạn là Tech Lead đang quyết định dành quý tới của team cho việc gì trong hạ tầng agent, đó chính là tín hiệu để hành động — ngừng tự xây session manager, bắt đầu xây tool tốt hơn và eval tốt hơn.

Nguồn: OpenAI — Introducing the Agents API, MarkTechPost — OpenAI Launches the Agents API in Public Beta

Xuất nội dung

Bình luận