OpenAI Agents API 2026: Codex harness, durable sessions, MCP và bài toán vận hành agent

Một agent có thể gọi model, dùng tool và chạy code. Nhưng để nó làm một công việc dài hơi, phần khó thường không nằm ở một prompt đơn lẻ. Hệ thống còn phải giữ trạng thái qua nhiều lượt, quản lý context khi lịch sử phình to, điều phối tool, phục hồi khi tác vụ bị gián đoạn, cô lập môi trường thực thi và theo dõi các agent con.

Ngày 10/09/2026, OpenAI đưa Agents API vào public beta. Theo công bố chính thức, API này mang cùng agent harness và hạ tầng đứng sau Codex tới nhà phát triển dưới dạng dịch vụ được quản lý. OpenAI xử lý session orchestration, context compaction và recovery; nhà phát triển có thể nối tool/MCP, dùng sandbox do OpenAI quản lý hoặc chọn môi trường khác.

Đây không chỉ là thêm một API cho agent. Nó cho thấy một lớp kỹ thuật từng phải tự dựng đang dần trở thành hạ tầng dùng chung.

Nhưng điều đó không có nghĩa phần khó của agent đã biến mất. Nó chỉ chuyển lên một tầng khác.

Mục lục

1. OpenAI vừa thay đổi điều gì?
2. Từ tự dựng agent loop đến managed harness
3. Durable sessions và context compaction giải quyết vấn đề gì?
4. MCP, tool và sandbox: có năng lực không đồng nghĩa có quyền
5. Phần nào doanh nghiệp vẫn phải tự thiết kế?
6. Một khung thử nghiệm thực tế cho workflow agent
7. Những rủi ro cần giữ lại trong thiết kế
8. Lợi thế chuyển từ agent loop sang hệ thống bằng chứng

1. OpenAI vừa thay đổi điều gì?

FACT — theo OpenAI: Agents API được phát hành public beta cho tất cả nhà phát triển ngày 10/09/2026. OpenAI mô tả đây là cách xây và chạy cloud agent bằng Codex harness được quản lý, thay vì mỗi đội phải tự vận hành toàn bộ vòng lặp điều phối.

Changelog chính thức nêu ba năng lực đáng chú ý: durable sessions để tiếp tục công việc qua nhiều lượt, context compaction để quản lý lịch sử dài và recovery cho quá trình thực thi. Agent có thể kết nối tool và MCP server, đồng thời chạy trong sandbox do OpenAI cung cấp hoặc môi trường phù hợp khác.

OpenAI cũng cho biết harness có nền tảng mã nguồn mở, còn phần vận hành harness có thể được OpenAI đảm nhiệm.

INTERPRETATION: Ranh giới sản phẩm đang dịch chuyển. Trước đây, một đội xây agent thường phải đầu tư đáng kể vào “agent loop”: gọi model, ghi lịch sử, chọn tool, chuyển kết quả về model, xử lý lỗi và tiếp tục tác vụ. Với managed harness, nhiều phần trong số đó có thể được coi giống hạ tầng hơn là lợi thế ứng dụng riêng.

Điều đáng hỏi vì vậy không còn chỉ là “agent có gọi được tool không?”, mà là “workflow nào đáng giao cho agent và bằng chứng nào cho phép hệ thống đi tiếp?”.

2. Từ tự dựng agent loop đến managed harness

Một agent demo có thể khá đơn giản: nhận yêu cầu → gọi model → chọn tool → trả kết quả. Nhưng workflow thực tế thường dài hơn.

Ví dụ giả định, một agent hỗ trợ phân tích hiệu quả Marketing có thể cần đọc nhiều nguồn, kiểm tra định nghĩa metric, chạy truy vấn, phát hiện dữ liệu thiếu, giao một nhánh nghiên cứu cho subagent, tổng hợp bằng chứng rồi mới đưa ra đề xuất. Nếu một bước lỗi hoặc context vượt quá giới hạn hữu ích, hệ thống phải biết cách tiếp tục mà không làm mất trạng thái quan trọng.

Khi tự xây, đội kỹ thuật phải quyết định cách lưu state, tóm gọn context, retry, checkpoint, cô lập code và quan sát chuỗi hành động. Đây là công việc cần thiết nhưng phần lớn không phải logic kinh doanh độc quyền.

Agents API đưa một phần trách nhiệm này xuống lớp harness được quản lý.

INTERPRETATION: Điều này có thể làm giảm lý do phải tự xây agent framework chỉ để có những năng lực nền tảng phổ biến. Tuy nhiên, “ít code orchestration hơn” không đồng nghĩa “ít thiết kế hệ thống hơn”. Khi lớp kỹ thuật cơ bản dễ tiếp cận, chất lượng khác biệt sẽ phụ thuộc nhiều hơn vào workflow, dữ liệu, permission, evaluation và cách xác minh trạng thái cuối.

3. Durable sessions và context compaction giải quyết vấn đề gì?

Agent chạy lâu gặp hai vấn đề rất thực tế.

Thứ nhất là tính liên tục. Một nhiệm vụ có thể kéo dài qua nhiều lượt, nhiều tool call hoặc nhiều lần người dùng quay lại. Nếu mỗi lần đều bắt đầu từ đầu, hệ thống vừa tốn chi phí vừa dễ mất các quyết định đã được xác lập.

Durable sessions nhằm giữ công việc tiếp tục qua các lượt thay vì xem mỗi request như một phiên độc lập.

Thứ hai là context tăng không giới hạn. Đưa toàn bộ lịch sử vào model mãi mãi không phải chiến lược bền vững. Context dài làm tăng chi phí và có thể làm loãng thông tin quan trọng. OpenAI mô tả context compaction như một phần do harness quản lý để giữ agent hoạt động qua session dài.

Nhưng có một ranh giới quan trọng.

FACT: Harness có thể quản lý việc duy trì và thu gọn context.

INTERPRETATION: Harness không thể tự biết mọi thông tin nào trong doanh nghiệp là “sự thật chuẩn” nếu ứng dụng không định nghĩa nguồn, trạng thái và quy tắc rõ ràng.

Một quyết định đã được phê duyệt, một KPI đã đổi định nghĩa hay một giao dịch đã thực sự ghi nhận ở hệ thống đích không nên tồn tại chỉ như ký ức hội thoại. Với các trạng thái quan trọng, ứng dụng vẫn cần source of truth bên ngoài model context.

Context giúp agent làm việc. Source of truth giúp hệ thống biết điều gì thực sự đã xảy ra.

4. MCP, tool và sandbox: có năng lực không đồng nghĩa có quyền

Agents API hỗ trợ tool và MCP, đồng thời cho phép agent làm việc trong sandbox với file và code. Đây là nền tảng mạnh để biến agent từ “trả lời” thành “thực hiện”.

Nhưng càng nhiều năng lực, ranh giới quyền càng quan trọng.

Một MCP server có thể cho agent đọc dữ liệu hoặc gọi hành động. Sandbox có thể cho agent chạy code. Subagent có thể chia nhỏ công việc và chạy song song. Không năng lực nào trong số đó tự trả lời ba câu hỏi:

Agent được phép làm gì?
Bằng chứng nào đủ để agent nên làm việc đó?
Sau khi tool báo thành công, làm sao biết trạng thái đích thực sự đúng?

INTERPRETATION: Tool success và task success là hai lớp khác nhau. Một API trả về thành công chứng minh lời gọi đã được xử lý theo giao thức; nó chưa chắc chứng minh mục tiêu kinh doanh cuối cùng đã đạt đúng trạng thái mong muốn.

Vì vậy, với hành động có hậu quả — thay đổi ngân sách, cập nhật dữ liệu, gửi thông tin ra ngoài, cấp quyền hoặc triển khai production — agent cần checkpoint và verification tương xứng với rủi ro.

5. Phần nào doanh nghiệp vẫn phải tự thiết kế?

Managed harness có thể đảm nhiệm orchestration, nhưng ít nhất năm lớp vẫn thuộc trách nhiệm của ứng dụng và tổ chức.

Một là mục tiêu. Agent cần biết kết quả nào được xem là hoàn thành, không chỉ chuỗi bước cần chạy.

Hai là dữ liệu và nguồn có thẩm quyền. Khi hai nguồn mâu thuẫn, hệ thống cần quy tắc xác định nguồn chuẩn, độ mới và cách ghi nhận UNKNOWN.

Ba là quyền và mức độ tự chủ. Đọc dữ liệu, đề xuất thay đổi và thực thi thay đổi là ba cấp quyền khác nhau. Không nên gộp chúng chỉ vì agent về kỹ thuật có thể gọi cùng một tool.

Bốn là evaluation. Một agent trả lời trôi chảy chưa chứng minh workflow đáng tin cậy. Cần test case có expected outcome, tình huống thiếu dữ liệu, lỗi tool, quyền bị từ chối và trường hợp nguồn xung đột.

Năm là verification. Với hành động quan trọng, hệ thống nên đọc lại trạng thái đích sau khi thực thi. “Đã gửi request” và “đích đã đúng” không phải cùng một bằng chứng.

Đây là nơi agent engineering gặp operations: chất lượng không chỉ nằm trong model mà nằm trong toàn bộ chuỗi quyết định và kiểm chứng.

6. Một khung thử nghiệm thực tế cho workflow agent

Thay vì bắt đầu bằng câu hỏi “dùng Agents API làm gì?”, có thể bắt đầu từ một workflow lặp lại đang tốn thời gian nhưng có ranh giới rõ.

Ví dụ giả định: agent chuẩn bị bản phân tích tuần từ một bộ nguồn đã cho phép.

Bước 1 — Định nghĩa đầu ra trước. Ghi rõ cấu trúc kết quả, dữ kiện bắt buộc, điều kiện nào phải trả về UNKNOWN và hành động nào agent tuyệt đối không được thực hiện.

Bước 2 — Tách quyền đọc và quyền ghi. Giai đoạn đầu chỉ cấp read-only nếu mục tiêu là nghiên cứu/phân tích. Đừng cấp quyền thay đổi hệ thống chỉ để demo trông “agentic” hơn.

Bước 3 — Xây bộ test nhỏ nhưng khó. Không chỉ dùng case đẹp. Thêm dữ liệu thiếu, hai nguồn lệch nhau, tool timeout, context dài và một yêu cầu vượt quyền.

Bước 4 — Gắn checkpoint với rủi ro. Việc tổng hợp nội dung có thể tự động hơn; việc gửi ra ngoài hoặc thay đổi production cần phê duyệt rõ ràng.

Bước 5 — Xác minh trạng thái cuối. Sau tool call quan trọng, đọc lại hệ thống đích hoặc nguồn chuẩn. Không dùng chính lời agent vừa tạo làm bằng chứng rằng hành động đã thành công.

Bước 6 — Đo chất lượng workflow. Theo dõi tỷ lệ hoàn thành đúng, lỗi cần người sửa, chi phí, thời gian và loại lỗi. Chỉ mở rộng quyền khi bằng chứng cho thấy hệ thống ổn định.

Đây là khung triển khai đề xuất, không phải benchmark của OpenAI hay kết quả từ một hệ thống nội bộ của Làm Cùng Long.

7. Những rủi ro cần giữ lại trong thiết kế

Public beta không phải GA. OpenAI nói rõ Agents API đang ở public beta và sẽ tiếp tục thay đổi dựa trên phản hồi. Thiết kế production cần chấp nhận khả năng API và hành vi vận hành còn tiến hóa.

Managed không có nghĩa là zero-ops. OpenAI có thể quản lý harness, nhưng ứng dụng vẫn phải quan sát chất lượng, chi phí, tool failure, permission và dữ liệu.

Context compaction không thay thế memory architecture. Những dữ kiện cần tính bền vững, audit hoặc xác nhận pháp lý/vận hành nên nằm ở hệ thống lưu trữ thích hợp, không phụ thuộc duy nhất vào context đã được nén.

Subagent không tự tạo ra tính đúng. Chia một bài toán thành nhiều agent có thể tăng throughput, nhưng cũng làm tăng số nhánh cần quan sát và hợp nhất. Nếu nguồn hoặc tiêu chí sai, chạy song song chỉ làm sai nhanh hơn.

MCP mở rộng bề mặt hành động. Mỗi tool mới là thêm năng lực và thêm rủi ro. Principle of least privilege vẫn cần được áp dụng ở lớp kết nối.

8. Lợi thế chuyển từ agent loop sang hệ thống bằng chứng

Khi cloud, database hay payment infrastructure trưởng thành, nhiều phần kỹ thuật nền tảng dần trở thành dịch vụ. Agent infrastructure có vẻ đang đi theo hướng tương tự.

Agents API là một tín hiệu rõ: orchestration, session, compaction, recovery và sandbox đang được đóng gói thành một lớp có thể dùng lại.

Nếu xu hướng này tiếp tục, việc “tự build một agent loop” sẽ ngày càng ít tạo khác biệt. Phần đáng đầu tư hơn là những thứ gắn với thực tế của tổ chức: dữ liệu chuẩn, workflow đúng, quyền rõ, evaluation tốt và bằng chứng đủ mạnh trước khi agent được phép hành động.

Một agent tốt không chỉ cần khả năng làm được việc.

Nó cần một hệ thống biết khi nào nên làm, được phép làm đến đâu, dựa trên bằng chứng nào và làm sao kiểm tra rằng việc đã thực sự hoàn tất.

Nguồn và phạm vi xác minh

Thông tin sản phẩm được đối chiếu đến 29/09/2026 từ thông báo Agents API của OpenAI, OpenAI API Changelog và Agents Cookbook. Các phần về governance, checkpoint, source of truth và verification là phân tích/khung triển khai, không phải tuyên bố rằng OpenAI tự động cung cấp các lớp kiểm soát kinh doanh đó.