Hướng dẫn GPT-6 Astra API: Xây dựng Agent Kiểm Tra Phát Hành với Async Tools và Steering

GPT-6 Astra API là gì?

GPT-6 Astra API là cách bạn truy cập vào mô hình chủ lực mới của OpenAI, phát hành ngày 3 tháng 9, 2026, thông qua Responses API. Với hướng dẫn này, điều quan trọng là bề mặt sử dụng: gpt-6-astra nhận đầu vào văn bản và hình ảnh thông qua Responses API của OpenAI. Phạm vi nỗ lực suy luận từ low đến max, không có tùy chọn none. 

Các ví dụ trong hướng dẫn này dùng client.responses.create thay vì client.chat.completions.create, nhưng việc chuyển đổi còn đòi hỏi thay đổi định dạng yêu cầu, đầu ra và kết quả công cụ. Hãy bỏ các thiết lập tùy chỉnh temperature, top_p và log-probabilities, vì Astra không hỗ trợ. Trước khi gọi lần đầu, hãy xem qua giá.

GPT-6 Astra có giá bao nhiêu?

Với các yêu cầu có tối đa 272.000 input token, giá tiêu chuẩn là $10 cho mỗi triệu input token thông thường và $50 cho mỗi triệu output token. Input được cache có giá $1 mỗi triệu, và ghi cache là $12,50 mỗi triệu. 

Khi một yêu cầu vượt ngưỡng đó, OpenAI áp dụng hệ số 2x cho input và cache, và 1.5x cho output. Mức giá cao áp dụng cho toàn bộ yêu cầu, không chỉ phần vượt ngưỡng. Không lần chạy nào trong hướng dẫn này chạm gần ngưỡng.

Chúng ta sẽ xây dựng gì với GPT-6 Astra API?

Ứng dụng staging là một bảng công việc nhỏ bằng Flask: một trang chủ, một form thêm task, một nút đánh dấu hoàn thành, và một endpoint /health . Toàn bộ mã, bao gồm app staging, có trong kho GitHub này.

Ba task mẫu xuất hiện trước khi thử. Ảnh: Tác giả.

Ứng dụng có một lỗi cố ý. Agent có ba kiểm tra, nhưng chỉ bộ test được thiết kế để bắt lỗi đó.

Vì sao ứng dụng chấp nhận tiêu đề task trống?

Endpoint tạo task không từ chối tiêu đề trống. Tôi giữ hành vi đó để agent có một lỗi đã biết để tìm, mà không lộ ra trong prompt.

Agent có thể chạy những kiểm tra phát hành nào?

Agent có thể gọi ba công cụ:

• run_test_suite chạy pytest, bao gồm một bài test nhập khẩu hàng loạt với khoảng 250 yêu cầu HTTP. 

• check_ui_flow dùng Playwright để thêm một task và xác nhận nó xuất hiện. 

• check_staging_health gửi yêu cầu GET tới /health. 

Cả ba đều chạy trên staging, không dùng mock. Kiểm tra trình duyệt dùng mã cố định; phần computer use do mô hình viết sẽ đến sau.

Cách thiết lập GPT-6 Astra API trong Python

Bạn cần khóa OpenAI API có quyền truy cập gpt-6-astra. Tạo khóa tại platform.openai.com/api-keys, và kiểm tra dự án của bạn đã bật gpt-6-astra. Ở các workspace Enterprise, Astra mặc định tắt khi ra mắt.

Các lệnh dưới đây dùng Windows PowerShell và cài mọi gói cần cho hướng dẫn này, bao gồm realtime của OpenAI cho bản demo steering.

python -m venv .venv
.venv\Scripts\Activate.ps1
Copy-Item .env.example .env
pip install "openai[realtime]" flask pytest playwright pydantic matplotlib python-dotenv streamlit
playwright install chromium

Trên macOS hoặc Linux, thay lệnh kích hoạt bằng source .venv/bin/activate và lệnh sao chép bằng cp .env.example .env. 

Sau đó thêm API key vào tệp .env mới: Mở tệp .env vừa sao chép và thêm OPENAI_API_KEY=sk-..., python-dotenv sẽ tải và SDK tự động nhận, nên bạn không cần truyền khóa trong mã.

Nếu phụ thuộc theo dự án hoặc tệp .env còn mới với bạn, các bài hướng dẫn về môi trường ảo và biến môi trường của chúng tôi sẽ giải thích. Hãy xác nhận khóa hoạt động rồi mới xây dựng tiếp.

Nếu API key của bạn đã hoạt động với Responses API, hãy bỏ qua mục tiếp theo và bắt đầu với vòng lặp công cụ đồng bộ. Yêu cầu đầu tiên chỉ để xác minh thiết lập.

Thực hiện cuộc gọi GPT-6 Astra API đầu tiên

Khi đã có key, cần tải nó bằng dotenv. Sau đó, bạn có thể tạo client OpenAI và gửi yêu cầu đầu tiên bằng hàm client.responses.create(). Yêu cầu nhỏ nhất có dạng như sau:

from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()

client = OpenAI()
response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "low"},
    input="In one sentence, what is a staging environment used for?",
)
print(response.output_text)

Trường usage của phản hồi liệt kê số lượng token cần cho phần tính chi phí về sau.

Xây dựng vòng lặp công cụ đồng bộ cho GPT-6 Astra

Các đoạn dưới đây là trích đoạn; phiên bản chạy được có trong kho GitHub đi kèm.

Trước khi đụng đến bất cứ thứ gì async, tôi xây dựng phiên bản thông thường: 

1. Gọi mô hình

2. Kiểm tra mục function_call

3. Chạy công cụ tương ứng

4. Gửi kết quả lại với previous_response_id

5. Lặp lại cho đến khi mô hình ngừng yêu cầu công cụ. 

Vòng lặp chặn này là chuẩn để so sánh với async.

for turn in range(max_turns):
    response = client.responses.create(
        model="gpt-6-astra",
        reasoning={"effort": "low"},
        tools=TOOLS,
        input=next_input,
        previous_response_id=previous_response_id,
    )
    calls = [item for item in response.output if item.type == "function_call"]
    if not calls:
        final_text = response.output_text
        break
    outputs = [
        {"type": "function_call_output", "call_id": call.call_id, "output": run_tool(call)}
        for call in calls
    ]
    next_input, previous_response_id = outputs, response.id

Kết quả chạy chuẩn tìm thấy gì

Trong lần chạy chuẩn, mô hình gọi từng công cụ theo thứ tự. Nó tìm thấy lỗi xác thực đã biết và trả về quyết định no-go. Qua ba lần chạy, tổng thời gian thực trung bình là 23,40 giây. Trung bình này bao trùm cả lượt, không phải thời gian từng công cụ.

GPT-6 Astra Async Tool Calling hoạt động như thế nào?

Đánh dấu một công cụ với "async": true trong schema của nó, và ứng dụng của bạn có thể hoãn kết quả đó trong khi mô hình hoặc tiếp tục làm việc hoặc chờ. Ứng dụng của bạn vẫn chạy công cụ và quản lý job nền.

Cách chạy các kiểm tra độc lập song song

Tôi đánh dấu run_test_suite và check_ui_flow là async, và thêm một công cụ wait_for_tasks do ứng dụng định nghĩa, không có đối số, vì bản demo này chỉ có một lô công việc chờ tại một thời điểm. Lệnh chờ không đối số giúp ví dụ gọn nhẹ. 

Trong runner sản xuất, hãy nhận diện job bằng tay cầm (handle) tác vụ, gắn mỗi handle với call_id gốc của nó, và chỉ chờ khi bước tiếp theo phụ thuộc vào kết quả đang chờ.

Trả về mỗi kết quả đã hoàn tất theo call_id gốc của nó, rồi trả về trạng thái chờ theo call_id của chính công cụ chờ.

TOOLS = [
    {"type": "function", "name": "run_test_suite", "async": True, ...},
    {"type": "function", "name": "check_ui_flow", "async": True, ...},
    {"type": "function", "name": "check_staging_health", ...},
    {"type": "function", "name": "wait_for_tasks", ...},
]

Trong lần chạy này, ứng dụng gửi mỗi lời gọi đã đánh dấu tới một thread pool. Trong lúc các kiểm tra nền chạy, nó thực hiện kiểm tra health đồng bộ nhanh. Sau đó nó chặn tại wait_for_tasks cho tới khi các kiểm tra đang chờ hoàn tất.

Async tool calling có giảm thời gian thực không?

Qua ba lần chạy, async giảm thời gian thực trung bình 19,1%, từ 23,40 giây xuống 18,94 giây. Mức trung bình có vẻ đơn giản cho đến khi từng lượt riêng lẻ về; biểu đồ dưới đây cho thấy mức độ biến thiên thực tế. Ba lượt chạy là đủ để cho thấy điều đã xảy ra ở đây, không phải để dự đoán độ trễ trong sản xuất.

Thời gian chạy biến thiên ở cả hai chế độ. Ảnh: Tác giả.

Vì sao các kiểm tra đồng thời gây ra race condition?

Chạy kiểm tra trình duyệt và test nhập khẩu hàng loạt cùng lúc đôi khi khiến assert của nhập khẩu hàng loạt thất bại vì cả hai kiểm tra đều sửa đổi cùng một danh sách task trong bộ nhớ. Điều đó phá vỡ giả định truy cập độc quyền của bài test. Cô lập dữ liệu ở runner hoặc trong test đều có thể tránh race này.

Computer Use của GPT-6 Astra có giới hạn cho kiểm thử UI

Với computer use, tài li liệu của GPT-6 Astra khuyến nghị thực thi mã, trong khi công cụ có cấu trúc computer vẫn được hỗ trợ như một lựa chọn thay thế. Với thực thi mã, một lời gọi có thể kết hợp nhiều hành động, vòng lặp và logic điều kiện, trong khi công cụ computer trả về từng hành động chuột hoặc bàn phím dạng cấu trúc để ứng dụng của bạn dịch và phát lại.

Cách giới hạn runner computer-use

Tôi gọi lớp là BrowserSandbox, nhưng cái tên đó phóng đại mức bảo vệ. Nó cấp cho mã do mô hình viết một đối tượng Playwright page, một hàm log(), và một trợ thủ expect_text() . Python vẫn có thể bơm built-ins vào exec(), và trang có thể điều hướng tới origin khác.

sandbox_globals = {"page": self.page, "log": log, "expect_text": expect_text}
exec(code, sandbox_globals)

Hãy coi đây là runner demo, không phải rào chắn bảo mật. Mã do mô hình viết cần một tiến trình hoặc container tách biệt với các hạn chế về hệ thống tệp, tiến trình, mạng và origin.

Điều gì đã xảy ra trong kiểm tra UI?

Tôi giới hạn vòng lặp ở tám lượt vì một kiểm tra có giới hạn cần điểm dừng cứng. Mô hình quan sát trang, tìm thấy input của form, tạo tiêu đề "UI flow check, cobalt otter 73921," gửi task, và xác nhận tiêu đề đã xuất hiện, mất 13 giây. Bài hướng dẫn computer use GPT-5.4 của chúng tôi có ví dụ chi tiết dùng tiền nhiệm của Astra.

Steering giữa lượt của GPT-6 Astra hoạt động thế nào?

Steering giữa lượt chỉ khả dụng cho gpt-6-astra qua kết nối WebSocket.

Mở kết nối và tạo một phản hồi, rồi gửi sự kiện response.steer với hướng dẫn mới trong khi phản hồi đang sinh. Sự kiện response.steer.accepted nghĩa là bản cập nhật đã được xếp hàng, chưa áp dụng. Trước khi tạo phần tiếp tục tự động, máy chủ hoàn tất mục đầu ra hiện tại và mọi công việc công cụ được host đang chạy. 

Nếu nó vẫn cần kết quả công cụ phía client hoặc phê duyệt, response.steer.pending sẽ chỉ ra đầu vào còn thiếu.

async with client.responses.connect() as connection:
    await connection.response.create(model="gpt-6-astra", input=TASK)
    async for event in connection:
        if event.type == "response.created" and initial_response_id is None:
            initial_response_id = event.response.id
            await asyncio.sleep(1.0)
            await connection.response.steer(
                previous_response_id=initial_response_id,
                input="Also add a rollback plan, but skip mobile.",
            )

Độ trễ một giây khớp với mã thí nghiệm và cho phản hồi đầu tiên thời gian để bắt đầu. Không có độ trễ này, bài thử sẽ ở một điểm khác trong vòng đời phản hồi.

Steering giữa lượt giữ nguyên điều gì?

Steering không viết lại phản hồi gốc. Nếu bản cập nhật ngắt nó, phản hồi đó kết thúc với status: "incomplete" và incomplete_details.reason: "steered". Một phản hồi kế tiếp sẽ tiếp tục với hướng dẫn mới. 

Nếu phản hồi đầu tiên hoàn tất trước khi cập nhật có hiệu lực, nó vẫn hoàn tất. Steering không đảo ngược hay hủy hành động phía client đã bắt đầu; ứng dụng của bạn vẫn chịu trách nhiệm phần đó. Steering xếp hàng chỉ tồn tại trên kết nối WebSocket hiện tại, nên hãy ghi lại cập nhật trước khi thử kết nối lại.

Đường so sánh cho phép phản hồi đầu tiên hoàn tất, rồi gửi yêu cầu mới với hướng dẫn kết hợp. Qua hai lượt, steering trung bình 26,91 giây so với 50,02 giây cho đường kết thúc-rồi-khởi động lại. So sánh này không bao gồm chính sách hủy-rồi-khởi động lại, cũng không chấm điểm độ đúng của văn bản cuối.

Trung bình hai lượt cho thời gian và chi phí. Ảnh: Tác giả.

Đường khởi động lại tạo ra hai phản hồi đầy đủ bao phủ một phần các yêu cầu trùng. Thiết lập đó giải thích một phần chênh lệch thời gian, nên tôi sẽ không coi hai lượt này là benchmark chung cho steering.

Cách thay đổi nỗ lực suy luận của GPT-6 Astra giữa cuộc hội thoại

gpt-6-astra hỗ trợ nỗ lực suy luận từ low đến max. Nỗ lực cao có thể tăng mức dùng token suy luận, nhưng không đảm bảo câu trả lời khác. Một configuration_update sẽ thay đổi các phản hồi tiếp theo cho đến khi có cập nhật khác ghi đè, trong khi thiết lập ở cấp yêu cầu vẫn giữ nguyên. 

Trong pipeline này, báo cáo kết thúc cuộc hội thoại, nên cập nhật chỉ ảnh hưởng bước cuối.

response = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=previous_id,
    reasoning={"effort": "low"},  # default remains low
    input=[
        {"type": "configuration_update", "reasoning": {"effort": "high"}},
        {"role": "user", "content": "Diagnose the root cause and recommend a fix."},
    ],
)

Tôi dùng cùng một trace lỗi ở cả hai mức nỗ lực và so sánh chẩn đoán và mức dùng token.

Một điểm tinh tế: trường reasoning.effort của phản hồi vẫn báo cáo thiết lập ở cấp yêu cầu, không phải nỗ lực được chọn bởi configuration_update. Đừng dùng trường đó để kiểm tra cập nhật đã có hiệu lực hay chưa.

Nỗ lực suy luận cao có thay đổi chẩn đoán không?

Trong lần chạy kết hợp đầy đủ, bước nâng cấp dùng 108 token suy luận. Mọi bước khác ở mức low dùng 0. Trong một thử nghiệm tách biệt trước đó với trace lỗi dài hơn, low dùng 0 token suy luận, còn high dùng 318. Cả hai phiên bản đều xác định đúng lỗi xác thực, nên thay đổi sang nỗ lực cao làm thay đổi mức dùng token nhưng không đổi chẩn đoán.

Configuration update chỉ hoạt động trong các yêu cầu chuẩn, đơn-agent. API từ chối các cập nhật liền kề, và chúng không thể kết hợp với compaction tự động hoặc cắt bớt tự động.

Cách dùng Structured Outputs của GPT-6 Astra

Bước cuối của pipeline gọi client.responses.parse để thay văn bản tự do bằng một mô hình Pydantic đã được xác thực.

class GoNoGoReport(BaseModel):
    decision: str
    summary: str
    checks_completed: list[str]
    failures: list[str]
    risks: list[str]
    follow_up_actions: list[str]
    confidence: float

response = client.responses.parse(
    model="gpt-6-astra",
    previous_response_id=previous_id,
    text_format=GoNoGoReport,
    input=[...],
)

Pydantic kiểm tra kiểu trường được khai báo ở đây. Nó không chứng minh rằng báo cáo khớp với bằng chứng, và phiên bản này không giới hạn decision vào hai giá trị hay confidence vào một khoảng.

Báo cáo go/no-go bắt được gì?

Báo cáo trả về decision: "no_go". Nó phân loại lỗi xác thực đã nêu vào failures và vấn đề đồng thời (concurrency) vào risks. Với phần sau, nó viết: "possible interference from concurrent UI checks against shared staging data." Prompt không nêu rủi ro đó.

Giữ độ trễ và chi phí ngoài schema này và tính trong mã. Mô hình điền các trường báo cáo từ bằng chứng công cụ.

Giao diện Streamlit tiêu thụ cùng generator với runner dòng lệnh. Nó hiển thị từng sự kiện công cụ khi đến, rồi cho thấy báo cáo đã parse trong tab Report và JSON.

Tiến độ agent trực tiếp bên cạnh báo cáo cuối. Video: Tác giả.

Bảng điều khiển chạy pipeline phát hành async kết hợp với kiểm tra trình duyệt cố định, cập nhật nỗ lực suy luận, báo cáo có cấu trúc, và hiển thị thời gian. Bảng chi phí của nó đọc cùng sổ cái với runner dòng lệnh. Nó không chạy các bản demo computer use do mô hình viết hoặc steering riêng.

Cách theo dõi mức dùng token và chi phí GPT-6 Astra API

Với phần token mô hình trong những lần chạy này, trường usage chứa bốn số token cần để định giá mỗi phản hồi. Ghi cache có mức giá riêng, nên đừng gộp chúng vào input thông thường. Các công cụ ở đây chạy trong ứng dụng của bạn; nếu bạn thêm công cụ được host có phí riêng, hãy cộng khoản đó nữa.

details = usage.input_tokens_details
cached_tokens = details.cached_tokens
cache_write_tokens = details.cache_write_tokens
ordinary_tokens = usage.input_tokens - cached_tokens - cache_write_tokens

cost = (
    ordinary_tokens * PRICE_INPUT
    + cached_tokens * PRICE_CACHED_INPUT
    + cache_write_tokens * PRICE_CACHE_WRITE
    + usage.output_tokens * PRICE_OUTPUT
) / 1_000_000

Tính toán này áp dụng cho một phản hồi. Sổ cái áp dụng sau mỗi phản hồi, rồi cộng tổng cho cuộc gọi.

Ghi log cache_write_tokens ngay cả khi giá trị là 0. Nếu không, một lần ghi cache sau này có thể ẩn trong số input thông thường, và đó là cách khó chịu để phát hiện lỗi tính phí.

Những lưu ý sản xuất cho GPT-6 Astra Agent

Bản demo cần các thay đổi này trước khi có thể chặn triển khai.

Quyền công cụ và cô lập

Giữ ranh giới staging và cô lập BrowserSandbox như mô tả ở trên. Đừng cấp thông tin đăng nhập DB hoặc quyền truy cập production.

Vòng đời job async

Trong demo, mọi job đang chờ đều hoàn tất, và không ai khác đụng vào. Runner triển khai phải sống sót trong các trường hợp cả hai điều đó đều không đúng. Nó cần, cho mỗi mục đang chờ:

• Hạn chót và trạng thái cuối, để không có gì chờ mãi
• Cờ giao nhận, để callback và retry không gửi trùng kết quả
• Dấu thời gian bắt đầu và kết thúc, để phân biệt timeout với hoàn tất muộn nhưng hợp lệ
• Từ chối lời gọi trùng, để cùng một task không thể khởi chạy hai lần
• Xử lý lỗi luồng nền, để ngoại lệ không biến mất trong pool
• Hủy bỏ, nghĩa là bỏ qua kết quả muộn và dừng công việc bên ngoài đang thực hiện

Steering và hành động không thể đảo ngược

Một steer có thể thay đổi hướng dẫn tương lai, nhưng không thể đảo ngược tác dụng phụ đã hoàn tất. Nếu một công cụ đã thay đổi hệ thống bên ngoài, cần một hành động công cụ riêng để bù trừ.

Giám sát misalignment

Tự động dừng áp dụng cho các yêu cầu Responses API dùng persisted reasoning, WebSockets, hoặc OpenAI compaction. Các yêu cầu khác có thể kích hoạt cảnh báo, nhưng không tự dừng. 

Trước khi streaming, misalignment monitoring có thể chặn một lượt được bao phủ với HTTP 403 và mã misalignment_policy_violation. Client streaming có thể nhận lỗi sau khi đầu ra đã bắt đầu. API không cung cấp đường tiếp tục chung cho cuộc hội thoại bị dừng.

Danh sách kiểm tra triển khai GPT-6 Astra Agent

Trước khi chuyển agent này từ demo cục bộ sang triển khai, hãy thêm các kiểm soát này. Chúng thuộc về mã ứng dụng thay vì hướng dẫn cho mô hình.

• Đặt timeout rõ ràng cho các cuộc gọi HTTP của app staging và kết nối WebSocket

• Ghi log input thông thường, input được cache, ghi cache, output, ID phản hồi, và số lượt

• Cảnh báo khi lượt chạy không hoàn tất hoặc chạm trần số lượt. Đặt cảnh báo riêng cho vượt ngân sách

• Pin phiên bản SDK openai và kiểm tra lại hành vi async, steering, và configuration_update trước khi nâng cấp

Khi nào nên dùng Async Tools hoặc Steering của GPT-6 Astra?

Chọn con đường đơn giản nhất phù hợp với công việc.

• Bắt đầu với yêu cầu đồng bộ và structured outputs khi công cụ trả về nhanh và yêu cầu không thay đổi.
• Thêm async tool calling khi mô hình hoặc công cụ khác có thể làm việc hữu ích trong lúc một lời gọi chậm, và thời gian tiết kiệm xứng đáng với chi phí quản lý job tăng thêm.
• Dùng steering giữa lượt khi yêu cầu thay đổi trong lúc chạy.

Lời kết

Kiểm tra phát hành đồng bộ trở nên hữu ích hơn khi các công cụ chậm có thể chồng lấp, dù kết quả không phải là thắng lợi hoàn toàn. Qua ba lượt, async giảm thời gian trung bình từ 23,40 giây xuống 18,94 giây, rồi phơi bày một race dùng chung trạng thái mà vòng lặp tuần tự đã che đi. 

Tôi sẽ cô lập trình duyệt và dữ liệu test, giữ các lượt thường ở mức low, và chỉ nâng nỗ lực suy luận khi bằng chứng cần soi kỹ hơn. Nếu công cụ hoàn tất nhanh và yêu cầu cố định, dừng ở vòng lặp đồng bộ với structured outputs. Dùng async khi công việc độc lập có thể chồng lấp, và dùng steering khi hướng dẫn thay đổi trong lúc phản hồi.

Với kiến thức cơ bản về API, tôi khuyến nghị học khóa Làm việc với OpenAI API. Với hệ thống agent lớn hơn, xem khóa Xây dựng Hệ thống Agentic Có Khả Năng Mở Rộng.