บทช่วยสอน GPT-6 Astra API: สร้างเอเจนต์ตรวจเช็กก่อนปล่อยระบบด้วย Async Tools และ Steering

GPT-6 Astra API คืออะไร?

GPT-6 Astra API คือวิธีเข้าถึงโมเดลเรือธงตัวใหม่ของ OpenAI ที่เปิดตัวเมื่อ 3 กันยายน 2026 ผ่าน Responses API สำหรับบทช่วยสอนนี้ สิ่งที่สำคัญคือผิวสัมผัสของ API: gpt-6-astra รับอินพุตเป็นข้อความและภาพ ผ่าน Responses API ของ OpenAI โดยมีระดับความพยายามด้านการให้เหตุผลตั้งแต่ low ถึง max และไม่มีตัวเลือก none 

ตัวอย่างในบทช่วยสอนนี้ใช้ client.responses.create แทน client.chat.completions.create แต่การย้ายยังต้องเปลี่ยนรูปแบบคำขอ เอาต์พุต และผลลัพธ์จากเครื่องมือ นอกจากนี้ควรถอดการตั้งค่า temperature, top_p และ log-probability ออกด้วย เพราะ Astra ไม่รองรับ ก่อนเรียกครั้งแรก มาดูเรื่องราคากัน

GPT-6 Astra มีค่าใช้จ่ายเท่าไร?

สำหรับคำขอที่มีโทเค็นอินพุตไม่เกิน 272,000 โทเค็น ราคาแบบมาตรฐาน อยู่ที่ $10 ต่อหนึ่งล้านโทเค็นอินพุตทั่วไป และ $50 ต่อหนึ่งล้านโทเค็นเอาต์พุต อินพุตที่แคชไว้คิด $1 ต่อหนึ่งล้าน และการเขียนเข้าคาเช่คิด $12.50 ต่อหนึ่งล้าน 

เมื่อคำขอเกินเพดานดังกล่าว OpenAI จะคูณราคาส่วนอินพุตและแคชด้วย 2 เท่า และคูณราคาส่วนเอาต์พุตด้วย 1.5 เท่า อัตราที่สูงขึ้นใช้กับคำขอทั้งรายการ ไม่ใช่เฉพาะโทเค็นที่เกินเพดาน งานรันในบทช่วยสอนนี้ไม่มีครั้งใดเข้าใกล้เพดานดังกล่าว

เราจะสร้างอะไรด้วย GPT-6 Astra API?

แอป staging เป็นกระดานงานเล็ก ๆ บน Flask: หน้าแรก แบบฟอร์มเพิ่มงาน ปุ่มทำเครื่องหมายว่างานเสร็จ และเอ็นด์พอยต์ /health โค้ดทั้งหมดรวมถึงแอป staging อยู่ใน ที่เก็บ GitHub นี้.

มีงานที่ seed ไว้สามงานก่อนการทดสอบ ภาพโดยผู้เขียน

แอปมีข้อบกพร่องโดยตั้งใจหนึ่งจุด เอเจนต์มีการตรวจเช็กสามแบบ แต่มีเพียงชุดทดสอบที่ออกแบบมาให้เจอปัญหาเหล่านั้น

ทำไมแอปรับชื่อเรื่องงานที่เว้นว่างได้?

เอ็นด์พอยต์สร้างงานไม่ปฏิเสธชื่อที่ว่างไว้ ตั้งใจคงพฤติกรรมนี้เพื่อให้เอเจนต์มีความล้มเหลวที่ทราบล่วงหน้าให้ค้นหา โดยไม่เปิดเผยในพรอมป์ต

เอเจนต์รันการตรวจเช็กก่อนปล่อยระบบอะไรได้บ้าง?

เอเจนต์สามารถเรียกใช้เครื่องมือสามตัว:

• run_test_suite รัน pytest รวมถึงการทดสอบนำเข้าจำนวนมากที่มีคำขอ HTTP ราว 250 รายการ 

• check_ui_flow ใช้ Playwright เพื่อเพิ่มงานและยืนยันว่ามันปรากฏ 

• check_staging_health ส่งคำขอ GET ไปยัง /health 

ทั้งสามอย่างรันกับสภาพแวดล้อม staging โดยไม่ใช้ mock การตรวจเช็กผ่านเบราว์เซอร์ใช้โค้ดตายตัว; เดโมการใช้คอมพิวเตอร์ที่โมเดลเขียนโค้ดเองจะมาทีหลัง

ตั้งค่า GPT-6 Astra API ใน Python อย่างไร

ต้องมีคีย์ OpenAI API ที่เข้าถึง gpt-6-astra ได้ สร้างคีย์ที่ platform.openai.com/api-keys และตรวจสอบว่าโปรเจกต์เปิดใช้ gpt-6-astra แล้ว พื้นที่ทำงานแบบองค์กรถูกปิด Astra ไว้โดยค่าเริ่มต้นเมื่อเปิดตัว

คำสั่งด้านล่างใช้ Windows PowerShell และติดตั้งแพ็กเกจทั้งหมดที่ต้องใช้ในบทช่วยสอนนี้ รวมถึง realtime ของ OpenAI สำหรับเดโมการสั่งบังคับทิศทาง

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

บน macOS หรือ Linux ให้แทนคำสั่ง activate ด้วย source .venv/bin/activate และแทนคำสั่งคัดลอกด้วย cp .env.example .env. 

จากนั้นเพิ่มคีย์ API ลงในไฟล์ .env ใหม่: เปิดไฟล์ .env ที่เพิ่งคัดลอกมาและเพิ่ม OPENAI_API_KEY=sk-... แล้ว python-dotenv จะโหลดให้และ SDK จะรับไปใช้โดยอัตโนมัติ จึงไม่ต้องส่งคีย์ในโค้ด

หากยังไม่คุ้นกับการพึ่งพาเฉพาะโปรเจกต์หรือไฟล์ .env ดูคู่มือ virtual environment และ environment variables ของเราเพื่อทำความเข้าใจ ยืนยันว่าキーใช้งานได้ก่อนจะสร้างต่อยอด

ถ้าคีย์ API ใช้งานกับ Responses API ได้อยู่แล้ว ให้ข้ามหัวข้อถัดไปและเริ่มที่ลูปเครื่องมือแบบ synchronous คำขอแรกมีไว้แค่ตรวจสอบการตั้งค่า

เรียก GPT-6 Astra API ครั้งแรก

เมื่อเพิ่มคีย์แล้ว ต้องโหลดด้วย dotenv จากนั้นสามารถสร้าง OpenAI client และส่งคำขอแรกด้วยฟังก์ชัน client.responses.create() คำขอที่เล็กที่สุดเป็นแบบนี้:

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)

ฟิลด์ usage ของการตอบกลับจะแสดงจำนวนโทเค็นที่ต้องใช้สำหรับการคำนวณต้นทุนในภายหลัง

สร้างลูปเครื่องมือแบบ Synchronous สำหรับ GPT-6 Astra

โค้ดตัวอย่างด้านล่างเป็นเพียงบางส่วน; เวอร์ชันที่รันได้อยู่ใน ที่เก็บ GitHub ที่แนบมา

ก่อนแตะอะไรที่เป็น async สร้างเวอร์ชันปกติก่อน: 

1. เรียกโมเดล

2. ตรวจหาชิ้นส่วน function_call

3. รันเครื่องมือที่ตรงกัน

4. ส่งผลลัพธ์กลับพร้อม previous_response_id

5. ทำซ้ำจนกว่าโมเดลจะหยุดขอเครื่องมือ 

ลูปแบบบล็อกนี้คือเส้นฐานสำหรับการเทียบกับ 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

สิ่งที่เส้นฐานพบ

ในการรันเส้นฐาน โมเดลเรียกใช้เครื่องมือแต่ละตัวตามลำดับ พบการตรวจสอบความถูกต้องที่ล้มเหลวตามที่ทราบไว้ และส่งคืนการตัดสินใจว่าไม่ผ่าน โดยเฉลี่ยสามครั้ง เวลาแบบผนังถึงผนังอยู่ที่ 23.40 วินาที ค่าเฉลี่ยนี้ครอบคลุมทั้งการรัน ไม่ใช่เวลาของเครื่องมือรายตัว

Async Tool Calling ของ GPT-6 Astra ทำงานอย่างไร?

ทำเครื่องหมายเครื่องมือด้วย "async": true ในสคีมา แล้วแอปของคุณสามารถเลื่อนการส่งคืนผลลัพธ์นั้นไว้ได้ ในขณะที่โมเดลทำงานต่อหรือรอ แอปพลิเคชันของคุณยังคงเป็นผู้รันเครื่องมือและจัดการงานเบื้องหลัง

รันการตรวจเช็กที่เป็นอิสระพร้อมกันอย่างไร

ทำเครื่องหมาย run_test_suite และ check_ui_flow เป็น async และเพิ่มเครื่องมือ wait_for_tasks ที่แอประบุเองซึ่งไม่มีอาร์กิวเมนต์ เพราะเดโมนี้มีงานค้างเพียงชุดเดียวในแต่ละครั้ง การรอแบบไม่มีอาร์กิวเมนต์ช่วยให้ตัวอย่างเล็กลง 

ในการรันจริง ควรกำหนดหมายเลขงานด้วยตัวจัดการงาน (task handle) ผูกแต่ละตัวจัดการเข้ากับ call_id ดั้งเดิม และรอเฉพาะเมื่อขั้นตอนถัดไปขึ้นกับผลลัพธ์ที่ค้างอยู่

ส่งคืนผลลัพธ์ที่เสร็จแล้วแต่ละรายการบน call_id ดั้งเดิม จากนั้นส่งคืนสถานะการรอบน call_id ของเครื่องมือ wait

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", ...},
]

สำหรับการรันนี้ แอปส่งแต่ละคำเรียกที่ทำเครื่องหมายไว้ไปยัง thread pool ระหว่างที่การตรวจเช็กเบื้องหลังรันอยู่ ก็ทำการตรวจ health ที่เร็วและ synchronous ไปด้วย จากนั้นบล็อกที่ wait_for_tasks จนกว่าการตรวจเช็กที่ค้างจะเสร็จ

async tool calling ลดเวลาแบบผนังถึงผนังได้หรือไม่?

จากสามครั้ง Async ลดค่าเฉลี่ยเวลาแบบผนังถึงผนังลง 19.1% จาก 23.40 วินาที เหลือ 18.94 วินาที ค่าเฉลี่ยดูเรียบง่ายจนกระทั่งเห็นผลการรันรายครั้ง กราฟด้านล่างแสดงความแปรปรวนที่เกิดขึ้นจริง สามครั้งพอจะบอกว่าเกิดอะไรขึ้นที่นี่ แต่ยังไม่พอจะทำนาย latency ในโปรดักชัน

เวลาในการรันแปรปรวนทั้งสองโหมด ภาพโดยผู้เขียน

ทำไมการตรวจเช็กร่วมกันจึงทำให้เกิด race condition?

การรันการตรวจเช็กผ่านเบราว์เซอร์และการทดสอบนำเข้าจำนวนมากพร้อมกัน บางครั้งทำให้ assertion ของการนำเข้าจำนวนมากล้มเหลว เพราะทั้งสองแก้ไขลิสต์งานในหน่วยความจำเดียวกัน ซึ่งทำให้ข้อสมมติฐานเรื่องการเข้าถึงแบบเฉพาะของการทดสอบพังลง การแยกข้อมูลทั้งในตัวรันหรือในชุดทดสอบจะช่วยหลีกเลี่ยง race ดังกล่าว

การใช้คอมพิวเตอร์แบบมีขอบเขตของ GPT-6 Astra สำหรับการทดสอบ UI

สำหรับ การใช้คอมพิวเตอร์ เอกสารของ GPT-6 Astra แนะนำการรันโค้ด ขณะที่เครื่องมือ computer แบบมีโครงสร้างยังคงรองรับเป็นทางเลือก เมื่อรันโค้ด การเรียกเดียวสามารถรวมหลายการกระทำ ลูป และเงื่อนไขได้ ขณะที่เครื่องมือ computer จะส่งคืนการกระทำของเมาส์หรือคีย์บอร์ดที่มีโครงสร้างทีละรายการให้แอปของคุณแปลและเล่นซ้ำ

จำกัดตัวรันการใช้คอมพิวเตอร์อย่างไร

ตั้งชื่อคลาสว่า BrowserSandbox แต่ชื่อนี้อาจดูเกินจริงเรื่องการป้องกัน มันให้โค้ดที่โมเดลเขียนเข้าถึง Playwright page, ฟังก์ชัน log() และตัวช่วย expect_text() Python ยังสามารถฉีด built-ins เข้าสู่ exec() ได้ และเพจก็สามารถนำทางไปยัง origin อื่นได้

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

ถือว่านี่เป็นตัวรันเพื่อเดโม ไม่ใช่ขอบเขตความปลอดภัย โค้ดที่โมเดลเขียนต้องรันในโพรเซสหรือคอนเทนเนอร์แยก ที่จำกัดไฟล์ระบบ โพรเซส เครือข่าย และ origin

เกิดอะไรขึ้นในตรวจเช็ก UI?

จำกัดลูปไว้ที่แปดเทิร์น เพราะการตรวจเช็กแบบมีขอบเขตต้องมีจุดหยุดที่ตายตัว โมเดลตรวจสอบหน้า พบอินพุตของฟอร์ม สร้างชื่อเรื่องว่า "UI flow check, cobalt otter 73921" ส่งงาน และยืนยันว่าชื่อปรากฏ ใช้เวลา 13 วินาที บทช่วยสอน การใช้คอมพิวเตอร์ของ GPT-5.4 ของเราครอบคลุมตัวอย่างละเอียดโดยใช้โมเดลรุ่นก่อนของ Astra

การสั่งบังคับทิศทางระหว่างเทิร์นของ GPT-6 Astra ทำงานอย่างไร?

การสั่งบังคับทิศทางระหว่างเทิร์น ใช้ได้เฉพาะกับ gpt-6-astra ผ่านการเชื่อมต่อ WebSocket

เปิดการเชื่อมต่อและสร้าง response แล้วส่งอีเวนต์ response.steer พร้อมคำสั่งใหม่ระหว่างที่ response กำลังสร้าง อีเวนต์ response.steer.accepted หมายความว่าการอัปเดตถูกเข้าคิวแล้ว ยังไม่ได้ถูกนำไปใช้ ก่อนสร้างการดำเนินการต่ออัตโนมัติ เซิร์ฟเวอร์จะจบเอาต์พุตชิ้นปัจจุบันและงานเครื่องมือที่โฮสต์ซึ่งกำลังรันอยู่ให้เสร็จ 

ถ้ายังต้องการผลลัพธ์จากเครื่องมือฝั่งไคลเอนต์หรือการอนุมัติ response.steer.pending จะระบุอินพุตที่ขาด

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.",
            )

ดีเลย์หนึ่งวินาทีนี้สอดคล้องกับโค้ดการทดลอง และให้เวลาการตอบแรกเริ่มต้น หากไม่มีดีเลย์ จะเป็นการทดสอบคนละจุดในวัฏจักรของ response

การสั่งบังคับทิศทางระหว่างเทิร์นไม่เปลี่ยนแปลงอะไรบ้าง?

Steering จะไม่เขียน response ดั้งเดิมใหม่ หากอัปเดตเข้าแทรก การตอบนั้นจะจบด้วย status: "incomplete" และ incomplete_details.reason: "steered" จากนั้น response ผู้สืบทอดจะดำเนินต่อด้วยคำสั่งใหม่ 

หาก response แรกเสร็จก่อนที่การอัปเดตจะมีผล มันยังคงเสร็จสมบูรณ์อยู่ Steering จะไม่ย้อนกลับหรือยกเลิกการกระทำฝั่งไคลเอนต์ที่เริ่มไปแล้ว; แอปพลิเคชันของคุณยังคงรับผิดชอบพฤติกรรมนั้น การสั่งบังคับทิศทางที่เข้าคิวมีผลเฉพาะบนการเชื่อมต่อ WebSocket ปัจจุบัน จึงควรบันทึกการอัปเดตก่อนพยายามเชื่อมต่อใหม่

เส้นทางเปรียบเทียบจะปล่อยให้ response แรกเสร็จ แล้วส่งคำขอใหม่ที่รวมคำสั่ง ทั้งสองครั้ง ค่าเฉลี่ยของ steering อยู่ที่ 26.91 วินาที เทียบกับ 50.02 วินาทีสำหรับเส้นทางจบ-แล้วเริ่มใหม่ การเปรียบเทียบนี้ไม่ครอบคลุมนโยบายยกเลิก-แล้วเริ่มใหม่ หรือให้คะแนนความถูกต้องของข้อความสุดท้าย

ค่าเฉลี่ยสองครั้งสำหรับเวลาและต้นทุน ภาพโดยผู้เขียน

เส้นทางเริ่มใหม่สร้าง response เต็มสองรายการที่ครอบคลุมคำขอซ้ำบางส่วน การตั้งค่านี้อธิบายส่วนหนึ่งของช่องว่างด้านเวลา จึงไม่ควรถือสองครั้งนี้เป็นเกณฑ์ทั่วไปสำหรับ steering

เปลี่ยนระดับความพยายามด้านการให้เหตุผลของ GPT-6 Astra ระหว่างบทสนทนาอย่างไร

gpt-6-astra รองรับระดับความพยายามด้านเหตุผลตั้งแต่ low ไปจนถึง max ความพยายามที่สูงขึ้นอาจเพิ่มการใช้โทเค็นเหตุผล แต่ไม่รับประกันคำตอบที่ต่างออกไป การใช้ configuration_update จะเปลี่ยน response ถัดไปและถัด ๆ ไป จนกว่าจะมีการอัปเดตใหม่มาทับ ขณะที่การตั้งค่าระดับคำขอยังเหมือนเดิม 

ในไปป์ไลน์นี้ รายงานเป็นตัวจบการสนทนา ดังนั้นการอัปเดตจึงมีผลเฉพาะขั้นสุดท้ายเท่านั้น

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."},
    ],
)

ใช้ร่องรอยความล้มเหลวเดียวกันทั้งสองระดับความพยายาม แล้วเปรียบเทียบการวินิจฉัยและการใช้โทเค็น

ประเด็นหนึ่งที่ละเอียด: ฟิลด์ reasoning.effort ของ responseยังคงรายงานการตั้งค่าระดับคำขอ ไม่ใช่ความพยายามที่ configuration_update เลือกใช้ อย่าใช้ฟิลด์นั้นเพื่อตรวจว่าการอัปเดตมีผลหรือไม่

ความพยายามด้านเหตุผลสูงขึ้นเปลี่ยนการวินิจฉัยหรือไม่?

ในการรันรวมเต็มขั้นตอน ขั้นที่ยกระดับใช้โทเค็นเหตุผล 108 โทเค็น ทุกขั้นอื่นที่ low ใช้ศูนย์ ในการทดสอบแยกก่อนหน้าโดยมีร่องรอยความล้มเหลวยาวกว่า ระดับ low ใช้โทเค็นเหตุผลศูนย์ และระดับ high ใช้ 318 ทั้งสองเวอร์ชันระบุบั๊กด้านการตรวจสอบความถูกต้องได้เหมือนกัน ดังนั้นการเพิ่มความพยายามเปลี่ยนการใช้โทเค็น แต่ไม่เปลี่ยนคำวินิจฉัย

การอัปเดตการกำหนดค่าทำงานได้เฉพาะในคำขอมาตรฐานแบบเอเจนต์เดียว API จะปฏิเสธการอัปเดตที่วางติดกัน และไม่สามารถใช้ร่วมกับการ compact อัตโนมัติหรือการตัดทอนอัตโนมัติได้

ใช้เอาต์พุตแบบมีโครงสร้างของ GPT-6 Astra อย่างไร

ขั้นตอนสุดท้ายของไปป์ไลน์เรียก client.responses.parse เพื่อแทนที่ข้อความเปล่าด้วยโมเดล Pydantic ที่ผ่านการตรวจสอบ

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 ตรวจชนิดฟิลด์ตามที่ประกาศไว้ ไม่ได้พิสูจน์ว่ารายงานสอดคล้องกับหลักฐาน และเวอร์ชันนี้ไม่จำกัดค่า decision ให้มีสองค่า หรือจำกัด confidence ให้อยู่ในช่วง

รายงาน go/no-go จับอะไรได้บ้าง?

รายงานส่งคืน decision: "no_go" จัดหมวดหมู่ความล้มเหลวด้านการตรวจสอบความถูกต้องที่กล่าวถึงก่อนหน้าไว้ใน failures และประเด็นด้านพร้อมกัน (concurrency) ไว้ใน risks สำหรับรายการหลัง เขียนว่า "possible interference from concurrent UI checks against shared staging data." พรอมป์ตไม่ได้ระบุความเสี่ยงนั้นไว้

เก็บ latency และต้นทุนไว้นอกสคีมานี้ และคำนวณในโค้ด โมเดลจะกรอกฟิลด์ของรายงานจากหลักฐานที่ได้จากเครื่องมือ

อินเทอร์เฟซ Streamlit ใช้เจเนอเรเตอร์เดียวกับตัวรันผ่านบรรทัดคำสั่ง เรนเดอร์อีเวนต์ของเครื่องมือแต่ละรายการเมื่อมาถึง แล้วแสดงรายงานที่แปลงแล้วในแท็บ Report และ JSON

ความคืบหน้าของเอเจนต์แบบสดข้างรายงานสุดท้าย วิดีโอโดยผู้เขียน

แดชบอร์ดรันไปป์ไลน์ตรวจเช็กก่อนปล่อยแบบ async ที่รวมทุกส่วนเข้าด้วยกัน พร้อมการตรวจเช็กเบราว์เซอร์ตายตัว การอัปเดตเหตุผล รายงานแบบมีโครงสร้าง และการแสดงเวลา พาเนลต้นทุนอ่านเลเจอร์เดียวกับตัวรันผ่านบรรทัดคำสั่ง ไม่ได้รันเดโมแยกสำหรับการใช้คอมพิวเตอร์ที่โมเดลเขียนโค้ดเองหรือการสั่งบังคับทิศทาง

ติดตามการใช้โทเค็นและต้นทุนของ GPT-6 Astra API อย่างไร

สำหรับส่วนโทเค็นของโมเดลในงานรันเหล่านี้ ฟิลด์ usage จะมีจำนวนโทเค็นสี่ค่าเพื่อใช้คิดราคาของแต่ละ response การเขียนแคชมีอัตราของตัวเอง อย่ารวมกับอินพุตทั่วไป เครื่องมือในที่นี้รันในแอปของคุณเอง หากเพิ่มเครื่องมือที่โฮสต์และมีค่าธรรมเนียมแยกต่างหาก ให้รวมค่าใช้จ่ายนั้นด้วย

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

การคำนวณนี้ครอบคลุมหนึ่ง response เลเจอร์จะใช้หลังจากทุก response แล้วรวมเป็นยอดรวมของแต่ละคำขอ

บันทึก cache_write_tokens แม้ค่าเป็นศูนย์ มิฉะนั้น การเขียนแคชในอนาคตอาจแอบอยู่ในจำนวนนับอินพุตทั่วไป ซึ่งเป็นวิธีที่น่ารำคาญในการเจอข้อผิดพลาดการเรียกเก็บเงิน

ข้อควรคำนึงสำหรับการผลิตของเอเจนต์ GPT-6 Astra

เดโมนี้ต้องปรับเปลี่ยนต่อไปนี้ก่อนจะใช้กั้นการดีพลอย

การอนุญาตและการแยกเครื่องมือ

คงขอบเขต staging และแยก BrowserSandbox ตามที่อธิบายไว้ด้านบน อย่าให้ข้อมูลเข้าสู่ฐานข้อมูลหรือเข้าถึงโปรดักชัน

วงจรชีวิตงาน async

ในเดโม งานค้างทุกงานจะเสร็จ และไม่มีสิ่งอื่นแตะต้องมัน ตัวรันที่ดีพลอยแล้วต้องเอาตัวรอดจากกรณีที่ไม่เป็นเช่นนั้น ต้องมีสิ่งต่อไปนี้สำหรับทุกรายการค้าง:

• กำหนดเส้นตายและสถานะสุดท้าย เพื่อไม่ให้อะไรค้างตลอดไป
• ธงสถานะการส่งมอบ เพื่อไม่ให้ callback และการลองใหม่ส่งผลลัพธ์เดียวกันซ้ำสองครั้ง
• เวลาเริ่มและสิ้นสุด เพื่อแยกแยะ timeout ออกจากการเสร็จช้าแต่ถูกต้อง
• การปฏิเสธคำเรียกที่ซ้ำ เพื่อไม่ให้เรียกงานเดียวกันสองครั้ง
• การจัดการข้อผิดพลาดในเธรดเบื้องหลัง เพื่อให้ exception ที่ถูกโยนโผล่ขึ้นมาแทนที่จะหายไปในพูล
• การยกเลิก ซึ่งหมายถึงการเพิกเฉยผลลัพธ์ที่มาช้ากับการหยุดงานภายนอกที่กำลังทำอยู่

การสั่งบังคับทิศทางและการกระทำที่ย้อนคืนไม่ได้

การสั่งบังคับทิศทางสามารถเปลี่ยนคำสั่งในอนาคต แต่ไม่สามารถย้อนผลข้างเคียงที่เสร็จสิ้นแล้วได้ หากเครื่องมือได้เปลี่ยนระบบภายนอกไปแล้ว ต้องมีการกระทำของเครื่องมือแยกต่างหากเพื่อชดเชย

การมอนิเตอร์ความไม่สอดคล้อง (misalignment)

การหยุดโดยอัตโนมัติใช้กับคำขอ Responses API ที่ใช้เหตุผลแบบ persisted, WebSockets หรือ OpenAI compaction คำขออื่นสามารถทริกเกอร์การแจ้งเตือนได้ แต่จะไม่ถูกหยุดโดยอัตโนมัติ 

ก่อนการสตรีม misalignment monitoring สามารถบล็อกงานรันที่ครอบคลุมด้วย HTTP 403 และโค้ด misalignment_policy_violation ฝั่งไคลเอนต์แบบสตรีมอาจได้รับข้อผิดพลาดหลังเอาต์พุตเริ่มไปแล้ว API ไม่มีเส้นทางทั่วไปสำหรับการทำบทสนทนาที่ถูกหยุดให้ดำเนินต่อ

เช็กลิสต์การดีพลอยเอเจนต์ GPT-6 Astra

ก่อนย้ายเอเจนต์นี้จากเดโมในเครื่องไปสู่การดีพลอย ให้เพิ่มการควบคุมเหล่านี้ ควรวางไว้ในโค้ดของแอปพลิเคชัน ไม่ใช่ในคำสั่งของโมเดล

• ตั้ง timeout ชัดเจนบนการเรียก HTTP ของแอป staging และการเชื่อมต่อ WebSocket

• บันทึกอินพุตทั่วไป อินพุตจากแคช การเขียนแคช เอาต์พุต ไอดีของ response และจำนวนเทิร์น

• แจ้งเตือนเมื่อการรันไม่สมบูรณ์หรือชนเพดานจำนวนเทิร์น ตั้งการแจ้งเตือนแยกสำหรับงบประมาณที่เกิน

• ปักหมุดเวอร์ชัน SDK ของ openai และตรวจสอบพฤติกรรม async, steering และ configuration_update ใหม่ก่อนอัปเกรด

ควรใช้ GPT-6 Astra แบบ Async Tools หรือ Steering เมื่อไร?

เลือกเส้นทางที่ง่ายที่สุดที่ตอบโจทย์งาน

• เริ่มจากคำขอแบบ synchronous และเอาต์พุตแบบมีโครงสร้าง เมื่อเครื่องมือส่งคืนผลเร็ว และข้อกำหนดคงที่
• เพิ่ม async tool calling เมื่อโมเดลหรือเครื่องมืออื่นสามารถทำงานที่มีประโยชน์ระหว่างการเรียกที่ช้าได้ และเวลาที่ประหยัดคุ้มกับภาระการจัดการงานที่เพิ่มขึ้น
• ใช้การสั่งบังคับทิศทางระหว่างเทิร์นเมื่อข้อกำหนดเปลี่ยนระหว่างการรัน

บทส่งท้าย

การตรวจเช็กก่อนปล่อยแบบ synchronous มีประโยชน์มากขึ้นเมื่อเครื่องมือช้าสามารถทับซ้อนกันได้ แม้ผลจะไม่ใช่ชัยชนะขาดลอย จากสามครั้ง Async ลดเวลาสูงเฉลี่ยจาก 23.40 วินาทีเหลือ 18.94 วินาที และเผย race จากสถานะร่วมที่ลูปแบบลำดับซ่อนไว้ 

จะแยกเบราว์เซอร์และข้อมูลทดสอบ เก็บเทิร์นตามปกติไว้ที่ low และเพิ่มความพยายามด้านเหตุผลเฉพาะเมื่อหลักฐานต้องพิจารณาใกล้ชิด หากเครื่องมือจบเร็วและข้อกำหนดคงที่ ให้หยุดที่ลูป synchronous พร้อมเอาต์พุตแบบมีโครงสร้าง ใช้ async เมื่อสามารถทับงานที่เป็นอิสระกันได้ และใช้ steering เมื่อคำสั่งเปลี่ยนระหว่างการตอบกลับ

สำหรับพื้นฐาน API แนะนําให้เรียนคอร์ส Working with the OpenAI API ของเรา สำหรับระบบเอเจนต์ขนาดใหญ่ ดูคอร์ส Building Scalable Agentic Systems ของเรา