OpenAI ra mắt GPT-6 Astra ngày 3/9, với context window 1 triệu token, các mức reasoning-effort từ low đến max, và — phần thực sự quan trọng với cách chúng ta xây hệ thống — một computer-use mode có thể đọc trạng thái trên màn hình và điều khiển chuột, bàn phím mà không cần API cho ứng dụng nó đang thao tác. Nó điền form, cập nhật record trong bất kỳ internal tool nào công ty bạn đang chạy, điều hướng các luồng browser nhiều bước, và làm điều đó bằng cách nhìn pixel và accessibility tree giống hệt cách một con người làm, không phải gọi một endpoint bạn viết sẵn cho nó.

Ba năm qua mình vẫn nói với khách hàng rằng “AI không thể hành động, nó chỉ có thể gợi ý” là một ranh giới thiết kế hợp lý vì chi phí integration là bottleneck. Ranh giới đó vừa mỏng đi rất nhiều, và mình nghĩ đa số team chưa nghĩ kỹ chuyện gì xảy ra khi nó mỏng đi.

Vì sao “không cần API” mới là tin thực sự

Mọi agent framework trước thế hệ này đều có cùng một hình dạng: định nghĩa tool, wrap chúng quanh API sẵn có, để model chọn từ một menu. Đó là một pattern thiết kế tốt, nhưng nó có nghĩa là năng lực của agent bị giới hạn bởi việc bao nhiêu phần bề mặt hệ thống của bạn đã có API. Các admin panel nội bộ, phần mềm vendor cũ, bất cứ thứ gì sau một màn hình login không có API công khai — tất cả đều nằm ngoài tầm với của agent trừ khi ai đó xây một integration riêng trước.

Computer-use model xóa bỏ rào cản đó. Nếu một con người có thể làm bằng cách click qua UI, agent cũng có thể thử, vì nó đang thao tác trên cùng một giao diện mà con người thao tác. Đó là một bước nhảy năng lực thực sự, không phải một bước nhảy điểm benchmark.

Đây là hình dạng gần đúng của một vòng lặp task trên browser do Astra điều khiển, nhìn từ phía API:

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "medium"},
    tools=[{"type": "computer_use", "display_width": 1440, "display_height": 900}],
    input=[
        {
            "role": "user",
            "content": "Open the internal billing dashboard, find invoices "
                       "overdue by more than 30 days, and export the list as CSV."
        }
    ],
    truncation="auto",
)

# Model trả về một stream các action: screenshot -> click -> type -> screenshot -> ...
for action in response.output:
    if action.type == "computer_call":
        execute_action(action.action)   # executor có sandbox của bạn
        screenshot = capture_screen()
        # đưa screenshot ngược lại làm observation cho turn tiếp theo

Vòng lặp rất đơn giản. Phần khó là mọi thứ xung quanh nó: sandbox nào đang chạy cái này, nó thực sự có thể chạm tới đâu, và ai review những gì nó đã làm trước khi coi là xong.

Nó gãy ở đâu trong thực tế

Mình đã test một phiên bản scoped của pattern này (dùng một automation nội bộ, không phải Astra trực tiếp, vì API access lúc viết bài vẫn đang trickle ra) trên ba internal tool của công ty tuần trước. Hai quan sát mình nghĩ sẽ tổng quát hóa được:

Failure âm thầm một phần mới là rủi ro thật, không phải failure rõ ràng. Khi một API call fail, bạn nhận được status code. Khi một computer-use agent click sai — trúng nhầm hàng trong bảng vì bảng re-render giữa lúc chụp screenshot và click, hoặc bấm nhầm một dropdown — nó thường không biết là đã fail. Nó tiếp tục như thể click đã trúng, và trạng thái downstream giờ sai theo cách trông vẫn ổn trong transcript. Đây là một failure mode khác về bản chất so với automation dựa trên API, nơi lỗi ít nhất còn có cấu trúc.

Latency cộng dồn theo cách khác. Một API call cộng một lượt model là một round trip. Một task điều khiển qua UI có thể mất 15-40 chu kỳ screenshot/action cho việc mà một integration viết sẵn chỉ cần một request. Điều đó không chỉ chậm hơn — nó tạo ra nhiều bề mặt hơn để môi trường trôi dạt (drift) giữa chừng lúc agent đang làm task (một modal bật lên, một session hết hạn, một banner làm layout dịch đi 40px).

Cả hai điều trên đều chỉ về cùng một yêu cầu thiết kế: bạn cần một bước verify độc lập với lời tường thuật của chính agent. Đừng tin “tôi đã export CSV thành công” — hãy kiểm tra xem một file CSV với đúng số dòng và cột dự kiến có thực sự nằm ở đúng chỗ hay không. Đây là bài học y hệt chúng ta đã học từ các thế hệ coding agent trước (verify với ground truth, không phải với lời tự báo cáo của agent), chỉ là áp dụng lên một bề mặt mới.

Một review gate pattern mình sẽ thực sự triển khai

Nếu bạn đang pilot computer-use agent trên các internal tool thật, đây là pattern mình sẽ bắt đầu:

def run_computer_task(task_description, target_system, risk_tier):
    plan = astra.plan(task_description, target_system)

    if risk_tier == "read_only":
        return astra.execute(plan, sandbox=readonly_sandbox)

    if risk_tier == "write_reversible":
        result = astra.execute(plan, sandbox=staging_sandbox)
        return require_human_approval(result, diff=compute_diff(target_system))

    if risk_tier == "write_irreversible":
        # billing, xóa user data, gửi communication ra bên ngoài — chưa có đường tự động
        raise RequiresManualExecution(plan)

Các nhóm này quan trọng hơn tooling. Đa số team mình nói chuyện muốn nhảy thẳng lên “để nó chạy hết cả workflow,” nhưng điểm khởi đầu trung thực là: các task read-only (thu thập dữ liệu, báo cáo, kiểm tra QA) có thể chạy tự động ngay hôm nay với spot-check nhẹ; các write có thể đảo ngược cần một bước diff-và-approve; các write không thể đảo ngược (bất cứ thứ gì liên quan đến tiền, xóa record, gửi giao tiếp ra ngoài) chưa nên tự động dù benchmark có đẹp đến đâu. System card của OpenAI cho Astra báo cáo rằng nó “ít khả năng hơn đáng kể” thực hiện hành động không được ủy quyền hoặc phá hoại so với thế hệ trước — đó là tiến bộ, nhưng “ít khả năng hơn” không thay thế được một ranh giới cứng về việc nó được phép chạm vào gì mà không có giám sát.

Mình đang thực sự dùng nó thế nào

Với công việc khách hàng, use case ngắn hạn không phải “thay thế người vận hành click qua CRM cũ.” Đó là regression testing và QA cho internal tooling — các task read-only hoặc hoàn toàn có thể đảo ngược theo thiết kế, nơi một click sai chỉ có nghĩa là chạy lại test. Đó là một fit thực sự tốt hôm nay: computer-use agent có thể chạy các luồng UI trên cả browser lẫn desktop app mà không ai phải viết script Selenium, và một lần chạy hỏng không tốn gì ngoài compute.

Thay đổi lớn hơn nằm ở kiến trúc, không phải chiến thuật: vài năm qua, “hệ thống này có API hay không” quyết định việc nó có tự động hóa được hay không. Điều đó không còn đúng tuyệt đối nữa, và nó thay đổi cuộc trò chuyện với các vendor phần mềm cũ — bạn không cần họ ra API trước rồi mới xây được trên tool của họ nữa. Đáng để nội tâm hóa điều này trước chu kỳ planning tiếp theo, kể cả khi bạn chưa deploy computer-use agent lên hệ thống production.

Nguồn: OpenAI GPT-6 Astra announcement, GPT-6 Astra System Card, GPT-6 Astra API docs