OpenAI mã nguồn mở lớp thực thi Codex, Cisco đã tích hợp

Ngày 19/8, OpenAI đăng một bài trên blog dành cho nhà phát triển có tựa "Codex as a platform", đổi cách mô tả Codex từ "trợ lý lập trình chạy trong terminal" sang "một lớp thực thi mã nguồn mở mà người khác có thể xây trực tiếp lên trên".

Bài viết mở đầu bằng một điểm dễ bị bỏ qua: phần lớn người dùng biết đến Codex qua ứng dụng desktop, dòng lệnh hoặc plugin IDE, nhưng cả ba lối vào này đều dùng chung một hệ thống nền, và hệ thống đó vốn đã có sẵn trên GitHub (kho openai/codex, giấy phép Apache 2.0, hiện có 109.000 star). Bước đi lần này của OpenAI thực chất là định vị lại: từ "chi tiết triển khai nội bộ của sản phẩm chúng tôi" thành "nền móng cho sản phẩm của bạn".

Lớp bao quanh mô hình

Bản gốc tiếng Anh dùng từ harness, giới kỹ thuật thường gọi là khung thực thi hay bộ khung điều phối. Định nghĩa mà OpenAI đưa ra khá đơn giản:

"That surrounding execution system is the harness."
Hệ thống thực thi bao quanh mô hình chính là harness.

Bóc tách ra, nó chịu trách nhiệm thu thập ngữ cảnh, chia nhỏ nhiệm vụ thành các bước có thể thực thi, duy trì trạng thái phiên qua nhiều lượt, gọi công cụ, chạy trong ranh giới sandbox và quyền hạn đã cấu hình, dừng lại đúng lúc cần con người phê duyệt, và cuối cùng trả kết quả về hệ thống nghiệp vụ. Những việc này không liên quan đến trọng số mô hình, nhưng làm tốt hay dở ảnh hưởng trực tiếp đến điểm số. OpenAI dẫn lại bộ dữ liệu ARC-AGI-3 hồi cuối tháng 7: chỉ cần bật hai công tắc giữ lại suy luận và nén ngữ cảnh ở tầng harness, điểm trên tập công khai của GPT-5.6 Sol tăng từ 13,3% lên 38,3%, trong khi số token đầu ra giảm còn khoảng một phần sáu. Mô hình không đổi, thứ thay đổi là lớp bao quanh nó.

Ba cấp độ tích hợp, xếp theo mức độ can thiệp

OpenAI chia rõ cách tích hợp thành ba tầng, để nhà phát triển chọn theo tình huống thay vì luôn phải nhét vào một khung chat.

codex exec dành cho script, tác vụ CI và công việc nền một lần: chạy một luồng agent có giới hạn rõ, trả ra kết quả có cấu trúc rồi kết thúc. Codex SDK dành cho ứng dụng cần khởi động, tiếp tục và đọc luồng (stream) tác vụ Codex ngay trong code. Codex app-server là tầng can thiệp sâu nhất: ứng dụng kết nối tới tiến trình Codex chạy cục bộ, giữ phiên mở liên tục, nhận luồng sự kiện, có thể ngắt bất cứ lúc nào, cho agent dùng công cụ riêng của ứng dụng, và tự xử lý các yêu cầu phê duyệt.

Để minh họa cách dùng app-server, OpenAI làm luôn một ứng dụng mẫu tên Relay, một bàn xử lý sự cố vận chuyển hàng hóa hư cấu. Người dùng không gõ prompt, mà chọn một lô hàng rồi bấm nút kiểu "Compare recovery"; ứng dụng đưa ngữ cảnh liên quan cho Codex, Codex qua công cụ MCP do chính ứng dụng gắn vào để lấy dữ liệu mới nhất và giải thích các phương án; muốn đổi lịch thật sự thì bắt buộc phải có người phê duyệt, sau khi ghi thao tác vào cơ sở dữ liệu thì ứng dụng mới cập nhật lại giao diện nghiệp vụ của mình.

Bài viết nói thẳng về hướng thiết kế này: đừng lấy một khung chat vạn năng thay thế cho bảng điều phối, dòng thời gian, bản đồ hay trang xử lý công việc — những giao diện đó vốn là nơi con người hiểu hiện trường, ra quyết định và giữ cảm giác kiểm soát.

Vài cái tên đã đưa vào sản phẩm

OpenAI liệt kê ba nhóm ví dụ công khai. GitHub và JetBrains đưa Codex vào luồng làm việc IDE của riêng mình; Cisco dùng Codex SDK trong App Builder thuộc Cloud Control; Thrive Holdings và Crete đưa Codex vào quy trình khai thuế, giai đoạn thử nghiệm đã xử lý 7.000 hồ sơ thuế, thời gian chuẩn bị khai thuế giảm khoảng một phần ba.

Con số cuối cùng khá thực chất. Khai thuế là trường hợp điển hình có độ lặp cao, dung sai lỗi thấp và yêu cầu tuân thủ nghiêm ngặt; đưa ra được quy mô thử nghiệm cùng một chỉ số hiệu quả có thể so sánh, hữu ích hơn nhiều so với những phát biểu kiểu "tăng năng suất đáng kể". OpenAI cũng nhân đó nhấn mạnh mô hình này không chỉ phục vụ đội kỹ thuật: xử lý sự cố hỗ trợ khách hàng, điều phối vận hành, phân loại sự cố an ninh, thẩm định thông tin trước bán hàng — tất cả đều cùng một hình dạng: ứng dụng cung cấp ngữ cảnh, công cụ và bước phê duyệt, Codex đảm nhận vòng lặp đó.

Mã nguồn mở dừng lại ở đâu

Bài viết có một câu được gạch chân: phần mở mã nguồn là harness và bề mặt tích hợp, còn quyền truy cập mô hình và dịch vụ hosting vẫn tính phí riêng.

Đặt câu này cạnh ba cấp độ tích hợp, toan tính của OpenAI hiện rõ. Lớp thực thi được cho miễn phí, có thể kiểm toán, có thể tùy chỉnh, ai cũng lấy được về nhét vào sản phẩm của mình; nhưng mỗi lần vòng lặp agent chạy, token vẫn phải đi qua API của OpenAI. Phần mã nguồn mở càng dễ dùng, càng nhiều sản phẩm nhúng nó vào, thì lượng gọi mô hình càng lớn. Đây cùng một kiểu nước cờ như cách Anthropic biến MCP thành chuẩn thực tế cho việc tích hợp công cụ, chỉ khác là lần này OpenAI nhường ra thứ nặng hơn — cả runtime được đưa ra ngoài.

Với các đội đang làm sản phẩm agent, cái lợi trước mắt là đỡ được một khoản việc trùng lặp. Trạng thái phiên, luồng sự kiện, gọi công cụ, gián đoạn chờ phê duyệt — hầu hết các đội đều từng tự viết lại những thứ này ít nhất một lần, viết xong còn phải tự chỉnh. Giờ có thêm một bản triển khai đã được kiểm chứng ở quy mô lớn, đọc được từng dòng để đối chiếu. Tính nhẩm thì nếu chỉ riêng thay đổi ở tầng harness đã kéo token đầu ra xuống còn một phần sáu, với cùng ngân sách có thể chạy thêm năm vòng, riêng điều này đã đáng để nhiều đội đọc kỹ mã nguồn.

Cái giá cũng nằm sờ sờ đó: càng tích hợp sâu, càng gắn chặt với mô hình tính phí của OpenAI. Cấp app-server rõ nhất, nó đã vượt quá quan hệ gọi API thông thường, gần như đưa tiến trình của đối tác vào thẳng sản phẩm của mình.

Nguồn tham khảo: Blog dành cho nhà phát triển của OpenAI "Codex as a platform", CocoLoop, kho GitHub openai/codex; giấy phép, số star và ba cấp độ tích hợp được đối chiếu theo kho mã và tài liệu chính thức, điểm ARC-AGI-3 và mức giảm token theo số liệu tự công bố của OpenAI.