Thanawat Wongchai

Posted on Jul 10 • Originally published at apidog.com

GPT-5.6: โมเดลเขียนโค้ดเรียกใช้เครื่องมือและจัดลำดับการทำงานได้เอง

การเรียกใช้ฟังก์ชันแบบคลาสสิกเป็นรูปแบบที่นักพัฒนาเอเจนต์คุ้นเคย: โมเดลร้องขอเครื่องมือหนึ่งครั้ง แอปของคุณรันเครื่องมือ ส่งผลลัพธ์กลับ แล้วโมเดลจึงร้องขอครั้งถัดไป สี่เครื่องมือคือสี่รอบ และสี่สิบเครื่องมือคือสี่สิบรอบ แต่ละรอบเพิ่มทั้งความหน่วงเครือข่ายและบริบทที่ต้องประมวลผลซ้ำ เมื่อ OpenAI เปิดตัว GPT-5.6 สู่สาธารณะเมื่อวันที่ 9 กรกฎาคม 2026 ก็ได้เพิ่มแนวทางใหม่ใน Responses API คือ การเรียกใช้เครื่องมือแบบโปรแกรม (programmatic tool calling)

ลองใช้ Apidog วันนี้

แนวคิดคือ แทนที่จะให้โมเดลคืน tool call ทีละครั้งเพื่อให้แอปของคุณวนลูปเอง โมเดลจะเขียน JavaScript สำหรับจัดการการเรียกใช้เครื่องมือหลายรายการ เช่น ลูป เงื่อนไข และการรวมผลลัพธ์ โค้ดนี้ทำงานใน V8 runtime ที่แยกออกมาและไม่มีสิทธิ์เข้าถึงเครือข่าย เครื่องมือที่คุณประกาศยังคงเป็นช่องทางเดียวไปยังระบบภายนอก ดังนั้นขอบเขตความปลอดภัยที่ใช้กับ OpenAI function calling ยังคงเหมือนเดิม

สิ่งที่เปลี่ยนคือจุดที่ control flow ทำงาน: จากเดิมอยู่ในแอปพลิเคชันของคุณ ย้ายไปอยู่ในโค้ดที่โมเดลสร้างขึ้น บทความนี้อธิบายผลกระทบต่อ API tool ของคุณ และขั้นตอนทดสอบ endpoint ให้พร้อมก่อนเปิดให้โมเดลเรียกใช้ด้วย Apidog

สรุป

GPT-5.6 เปิดตัวสู่สาธารณะเมื่อวันที่ 9 กรกฎาคม 2026 และ Responses API ได้รับความสามารถในการเรียกใช้เครื่องมือแบบโปรแกรม
โมเดลสามารถเขียน JavaScript เพื่อสร้างลูป เงื่อนไข และรวมข้อมูลจากเครื่องมือที่คุณประกาศ
JavaScript ทำงานใน V8 sandbox ที่แยกออกมาและไม่มี network access; tool definition ของคุณยังเป็นขอบเขตความปลอดภัยหลัก
จำนวน round trip ไม่จำเป็นต้องเพิ่มตามจำนวน tool call เหมือนลูปเอเจนต์แบบคลาสสิก
อ่านพารามิเตอร์และข้อจำกัดล่าสุดจากเอกสาร OpenAI ก่อนใช้งานจริง
ทดสอบ Schema, error response, rate behavior และ idempotency ของทุก tool endpoint ก่อนเปิดใช้

สิ่งที่เปิดตัวเมื่อวันที่ 9 กรกฎาคม

GPT-5.6 เปิดตัวในสามระดับ:

gpt-5.6-sol สำหรับการให้เหตุผลเชิงลึก
gpt-5.6-terra สำหรับงานสมดุล
gpt-5.6-luna สำหรับงานที่ต้องการความเร็วและประหยัดค่าใช้จ่าย

นามแฝง gpt-5.6 จะชี้ไปที่ Sol ทั้งสามระดับใช้งานผ่าน API ได้ด้วยตนเอง หลังช่วงพรีวิวแบบจำกัดที่สิ้นสุดเมื่อมีการยกเลิกข้อจำกัดการเข้าถึงในวันที่ 8 กรกฎาคม

นอกจากชุดโมเดลแล้ว Responses API ยังได้รับความสามารถใหม่ ได้แก่:

การเรียกใช้เครื่องมือแบบโปรแกรม
Multi-agent เวอร์ชันเบต้า
การให้เหตุผลที่คงอยู่ข้ามหลายรอบ
การตั้งค่ารายละเอียดภาพที่คงขนาดภาพต้นฉบับ

ตามรายงานการเปิดตัวของ MarkTechPost และเอกสาร OpenAI การเรียกใช้เครื่องมือแบบโปรแกรมคือความสามารถที่โมเดลเขียน JavaScript เพื่อประสานงาน tool call หลายรายการใน V8 runtime ที่แยกออกจากกันและไม่มีเครือข่าย

ลูปที่การเรียกใช้เครื่องมือแบบโปรแกรมเข้ามาแทนที่

นี่คือตัวอย่าง function calling แบบคลาสสิกกับ Responses API:

import OpenAI from "openai";

const client = new OpenAI();

const tools = [
  {
    type: "function",
    name: "get_flight_status",
    description: "Return live status for a flight by IATA flight number.",
    parameters: {
      type: "object",
      properties: {
        flight_number: {
          type: "string",
          description: "IATA flight number, for example SQ317"
        }
      },
      required: ["flight_number"]
    }
  }
];

let response = await client.responses.create({
  model: "gpt-5.6",
  input: "Which of these 12 flights are delayed: SQ317, BA15, UA857...",
  tools
});

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

// One round trip per tool call.
while (hasFunctionCalls(response)) {
  const outputs = await executeToolCalls(response);

  response = await client.responses.create({
    model: "gpt-5.6",
    previous_response_id: response.id,
    input: outputs,
    tools
  });
}

สำหรับเที่ยวบิน 12 รายการ ลูปนี้อาจทำงาน 12 รอบ ปัญหาหลักมีสองด้าน:

ความหน่วงแบบอนุกรม

แต่ละรอบต้องเดินทางไปยัง OpenAI รอโมเดลประมวลผล รันเครื่องมือ และส่งผลลัพธ์กลับก่อนเริ่มรอบต่อไป
บริบทและโทเค็นสะสม

ผลลัพธ์จากเครื่องมือรอบก่อนหน้าจะอยู่ใน context ของรอบถัดไป ทำให้คำขอหลัง ๆ ต้องประมวลผลข้อมูลมากขึ้น

หากมีหลายเอเจนต์ ปัญหาจะขยายตามจำนวนลูป เช่น workflow ห้าขั้นตอนที่แต่ละขั้นตอนมีสิบรอบ อาจกลายเป็นการเรียกโมเดลห้าสิบครั้ง

โหมดโปรแกรมเปลี่ยนรูปแบบอย่างไร

เมื่อใช้ programmatic tool calling โมเดลสามารถเขียนโปรแกรม JavaScript ขนาดเล็กเพื่อ:

วนลูปผ่านหมายเลขเที่ยวบินทั้ง 12 รายการ
เรียก get_flight_status สำหรับแต่ละเที่ยวบิน
กรองเฉพาะเที่ยวบินที่ล่าช้า
เรียงลำดับตามระยะเวลาล่าช้า
คืนผลลัพธ์สรุป

เครื่องมือยังคงเป็นผู้ดำเนินการจริง แต่ control flow รอบเครื่องมือย้ายไปอยู่ใน sandbox ของโมเดล

คุณสมบัติสำคัญมีสามข้อ:

Runtime ถูกแยกออกมา

JavaScript ที่สร้างขึ้นทำงานใน V8 sandbox โดยไม่มี network access จึงไม่สามารถเรียก URL เปิด socket หรือส่งข้อมูลออกเองได้
เครื่องมือคือทางออกเดียวสู่ระบบภายนอก

หากคุณไม่ได้ประกาศ delete_record โมเดลก็ไม่สามารถลบข้อมูลได้ แม้จะสร้างโค้ดขึ้นมาก็ตาม
Control flow แสดงออกได้มากขึ้น

ลูป เงื่อนไข การหยุดก่อนกำหนด และการรวมผลลัพธ์สามารถเกิดขึ้นภายในการตอบกลับเดียว แทนการทำ N round trips

	การเรียกใช้ฟังก์ชันแบบคลาสสิก	การเรียกใช้เครื่องมือแบบโปรแกรม
ใครเขียน control flow	แอปพลิเคชันของคุณ	โมเดลในรูปแบบ JavaScript
Round trip สำหรับ tool call จำนวน N ครั้ง	N ครั้งแบบอนุกรม	รอบการตอบกลับเดียว
จุดที่ orchestration ทำงาน	โครงสร้างพื้นฐานของคุณ	V8 sandbox ที่แยกออกมา ไม่มีเครือข่าย
วิธีเรียกใช้เครื่องมือ	โค้ดของคุณเรียก	ผ่าน tool interface ที่คุณประกาศ
ขอบเขตความปลอดภัย	Tool definition	Tool definition เช่นเดิม

สิ่งที่ยังคงเหมือนเดิม

คุณยังนิยามเครื่องมือด้วยชื่อ คำอธิบาย และ JSON Schema เช่นเดิม โมเดลสามารถเรียกได้เฉพาะเครื่องมือที่คุณประกาศเท่านั้น

ดังนั้นคำถามว่า “เอเจนต์นี้ทำอะไรกับระบบของฉันได้บ้าง” ยังตอบได้เหมือนเดิม: มันทำได้เฉพาะสิ่งที่ tool interface ของคุณอนุญาต

แต่คุณภาพ Schema สำคัญกว่าเดิม เพราะ Schema ที่กำกวมอาจไม่ได้สร้างคำขอผิดเพียงครั้งเดียว ในโหมดโปรแกรม โมเดลอาจนำความเข้าใจผิดเดิมไปใช้ซ้ำภายในลูป

นำแนวทางจาก structured outputs มาใช้กับ tool definition โดยตรง:

ใช้ type ที่เข้มงวด
ใช้ enum สำหรับค่าที่มีชุดจำกัด
ระบุหน่วยและรูปแบบใน description
กำหนด field เป็น required เฉพาะเมื่อจำเป็นจริง
อธิบายรูปแบบวันที่ เวลา และ timezone ให้ชัดเจน
ระบุช่วงค่าที่ยอมรับได้ เช่น จำนวนสูงสุด/ต่ำสุด

ตัวอย่าง Schema ที่ชัดเจนขึ้น:

parameters: {
  type: "object",
  properties: {
    date: {
      type: "string",
      description: "Departure date in ISO 8601 format: YYYY-MM-DD."
    },
    timezone: {
      type: "string",
      enum: ["UTC", "Asia/Bangkok", "Europe/London"],
      description: "IANA timezone used when interpreting the date."
    },
    max_results: {
      type: "integer",
      minimum: 1,
      maximum: 100,
      description: "Maximum number of results to return."
    }
  },
  required: ["date", "timezone"]
}

ข้อจำกัดและคำถามที่ยังเปิดอยู่

ความสามารถนี้เพิ่งเปิดตัว จึงควรระวังเรื่องต่อไปนี้ก่อนปรับสถาปัตยกรรมเอเจนต์ทั้งหมด:

พารามิเตอร์คำขอ ข้อจำกัดการดำเนินการ และ timeout ให้ตรวจสอบจากเอกสารอ้างอิง API และคู่มือโมเดลของ OpenAI ก่อนเขียนโค้ดใช้งาน
การดีบักเปลี่ยนไป เพราะบางส่วนของ control flow ถูกสร้างใหม่ทุกคำขอ ควรเก็บ log ของลำดับ tool call, input, output และ error
ประวัติการใช้งานจริงใน production ยังมีจำกัด บันทึกวันแรกของ Simon Willison เกี่ยวกับ GPT-5.6 เป็นแหล่งติดตามการทดสอบอิสระที่มีประโยชน์
เริ่มจากเครื่องมือแบบ read-only ก่อน แล้วจึงค่อยพิจารณาเครื่องมือที่มีผลข้างเคียง

ลำดับการนำไปใช้ที่แนะนำ:

เลือก workflow ที่อ่านข้อมูลเป็นหลัก
เปิดใช้เฉพาะ tool แบบ read-only
เก็บ log ของ tool call ทุกครั้ง
เปรียบเทียบ latency และ token usage กับลูปเดิม
ทดสอบ input ผิดรูปแบบและ error response
ค่อยเปิดใช้เครื่องมือที่เปลี่ยนแปลงข้อมูลเมื่อมี guardrail เพียงพอ

เครื่องมือของคุณตอนนี้กลายเป็น API ที่โค้ดของผู้อื่นเรียกใช้

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

นั่นทำให้ทุก tool เป็น API contract สำหรับ client ที่เขียนโดยเครื่องจักร และคุณไม่สามารถตรวจสอบโค้ดนั้นล่วงหน้าก่อนรันได้

ควรยกระดับมาตรฐานในสี่ด้าน:

1. Schema ต้องแม่นยำ

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

2. Error response ต้องมีโครงสร้าง

อย่าส่ง 200 OK พร้อมข้อความผิดพลาดที่ฝังอยู่ใน string เพราะโค้ดที่สร้างขึ้นอาจตีความผลลัพธ์เป็นข้อมูลสำเร็จ

ใช้ HTTP status code ที่ตรงความหมาย และคืน error body ที่ตรวจสอบได้:

{
  "error": {
    "code": "FLIGHT_NOT_FOUND",
    "message": "No flight was found for the supplied IATA flight number.",
    "details": {
      "flight_number": "SQ999"
    }
  }
}

3. ต้องออกแบบให้รองรับ burst และ retry

การเรียก 12 ครั้งที่เดิมกระจายอยู่หลายรอบ อาจมาถึงใกล้เคียงกันในครั้งเดียว ตรวจสอบว่า endpoint รองรับสิ่งต่อไปนี้หรือไม่:

rate limit
concurrency
retry
idempotency key
timeout
partial failure

สำหรับเครื่องมือที่มีผลข้างเคียง เช่น สร้างคำสั่งซื้อหรือส่งข้อความ ควรออกแบบ idempotency ให้ชัดเจน:

POST /orders
Idempotency-Key: 9f7d1c8e-3a21-4f18-bc4d-123456789abc

4. Latency ของเครื่องมือมีผลโดยตรงต่อ workflow

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

ก่อนเปิดใช้ ให้ทดสอบอย่างน้อย:

response ปกติ
input ไม่ถูกต้อง
resource ไม่พบ
timeout
rate limit
response ขนาดใหญ่
การเรียกซ้ำด้วย input เดิม
การเรียกพร้อมกันหลายคำขอ

นี่คือจุดที่ API workbench มีประโยชน์: นำเข้าหรือกำหนดสเปก endpoint ของแต่ละ tool ส่ง test request และตรวจสอบว่า response ตรงกับ Schema ที่ tool definition รับประกัน

จากนั้นจำลอง API เพื่อทดสอบ orchestration กับข้อมูลที่คาดเดาได้โดยไม่แตะระบบ production ดาวน์โหลด Apidog เพื่อใช้ mock server สร้าง response ตาม Schema สำหรับ endpoint ที่คุณกำหนด และตรวจสอบพฤติกรรมของโมเดลก่อนเชื่อมต่อข้อมูลจริง

คุณสมบัติ GA อื่น ๆ โดยย่อ

การเรียกใช้เครื่องมือแบบโปรแกรมไม่ได้มาเพียงอย่างเดียว Responses API ยังเพิ่มความสามารถที่เกี่ยวข้อง:

Multi-agent เวอร์ชันเบต้า: รองรับการทำงานของ subagent แบบขนานที่ API จัดการให้ แต่ยังอยู่ในระยะเริ่มต้น
Persistent reasoning: ใช้บริบทการให้เหตุผลซ้ำข้ามรอบผ่าน reasoning.context เพื่อลดการสรุปข้อมูลเดิมซ้ำใน session ที่ยาว

เมื่อรวมกับ programmatic tool calling เอเจนต์สามารถรักษาบริบทการให้เหตุผลข้ามรอบ และจัดการ tool flow ได้เอง จึงลดงานซ้ำซ้อนต่อหนึ่ง task ได้มากขึ้น

การเรียกใช้เครื่องมือแบบโปรแกรมเทียบกับโหมด Ultra

การเปิดตัวยังมีโหมด Ultra ซึ่งอาจสับสนกับ programmatic tool calling เพราะทั้งคู่ทำงานได้มากขึ้นต่อคำขอ แต่แก้ปัญหาคนละด้าน

Ultra เป็นการตั้งค่าแบบหลายเอเจนต์ที่รันเอเจนต์สี่ตัวพร้อมกันโดยค่าเริ่มต้น ใช้โทเค็นมากขึ้นเพื่อลดเวลาจริง ตามข้อมูลของ OpenAI Ultra เพิ่มคะแนน Terminal-Bench 2.1 จาก 88.8% เป็น 91.9% โดยมีใน ChatGPT Work สำหรับแผน Pro และ Enterprise และใน Codex ตั้งแต่ Plus ขึ้นไป

ส่วน programmatic tool calling เป็นความสามารถระดับ API ที่ให้เอเจนต์หนึ่งตัวจัดการเครื่องมือผ่านโค้ด

สรุป:

หากคอขวดคือ latency จาก tool call หลายรอบ ให้ใช้ programmatic tool calling
หากคอขวดคือ เวลาคิดวิเคราะห์ของปัญหาซับซ้อน ให้พิจารณา Ultra

อ่านรายละเอียดเพิ่มเติมได้ในบทความ โหมด Ultra ของ GPT-5.6

คำถามที่พบบ่อย

ฉันจำเป็นต้องเขียนคำจำกัดความเครื่องมือที่มีอยู่ใหม่หรือไม่?

ไม่จำเป็น เครื่องมือยังใช้ JSON Schema รูปแบบเดิม และ definition สำหรับ function calling แบบคลาสสิกยังใช้ได้

อย่างไรก็ตาม ควรปรับให้ชัดเจนขึ้นด้วย enum, format, range และ description ที่เฉพาะเจาะจง เพื่อไม่ให้โค้ดที่โมเดลสร้างตีความผิด

JavaScript ที่สร้างขึ้นสามารถเข้าถึงอินเทอร์เน็ตได้หรือไม่?

ไม่ได้ โค้ดทำงานใน V8 runtime ที่แยกออกมาและไม่มี network access เครื่องมือที่คุณประกาศเป็นวิธีเดียวที่โค้ดจะกระทบระบบภายนอกได้

ดังนั้นควรตรวจสอบ tool interface ด้วยมาตรฐานเดียวกับ API สาธารณะ โดยเฉพาะ authorization, validation, rate limit และ audit log

โมเดล GPT-5.6 ใดบ้างที่รองรับการเรียกใช้เครื่องมือแบบโปรแกรม?

OpenAI ระบุความสามารถนี้สำหรับ Responses API ของตระกูล GPT-5.6 โดยทั้งสามระดับคือ gpt-5.6-sol, gpt-5.6-terra และ gpt-5.6-luna ใช้งานผ่าน API ได้

ตรวจสอบเอกสาร API สำหรับรายละเอียดระดับชั้นก่อนเลือกใช้ และดูคู่มือเริ่มต้นได้ที่ วิธีใช้ GPT-5.6 API

สิ่งนี้แตกต่างจาก Code Interpreter อย่างไร?

Code Interpreter รันโค้ดเพื่อสร้างผลลัพธ์ เช่น วิเคราะห์ข้อมูล สร้างกราฟ หรือแปลงไฟล์

ส่วน programmatic tool calling สร้างโค้ดเพื่อประสานงานเครื่องมือที่คุณประกาศไว้ ผลลัพธ์สุดท้ายมาจากการเรียกใช้เครื่องมือ ไม่ใช่ตัวโค้ดเอง

สิ่งนี้ส่งผลต่อคุณอย่างไร

ลูป round trip เป็นส่วนที่น่าเบื่อที่สุดของเอเจนต์จำนวนมาก และ GPT-5.6 ทำให้ลูปนี้เป็นทางเลือกได้ แต่เมื่อ control flow ย้ายไปอยู่กับโมเดล ความรับผิดชอบในการออกแบบ API tool ที่สะอาด แม่นยำ และทนทานก็มีความสำคัญมากขึ้น

เริ่มแบบลงมือทำได้ดังนี้:

เลือก workflow ที่เน้น read operation หนึ่งรายการ
ตรวจสอบ tool Schema ให้ระบุ type, format, unit และ error อย่างชัดเจน
ทดสอบทุก endpoint ด้วย input ปกติและ input ผิดรูปแบบ
จำลอง timeout, 429, 404 และ 500
ทดสอบ burst request และ retry behavior
ใช้ API client และ mock server ของ Apidog ตรวจสอบ API contract ก่อนต่อเข้ากับระบบจริง
เปิดใช้เครื่องมือแบบมีผลข้างเคียงหลังจากมี idempotency, authorization และ audit log พร้อมแล้ว

เมื่อโมเดลเริ่มเขียนโค้ดเพื่อใช้เครื่องมือของคุณ คุณควรมั่นใจว่า API surface ที่มันเรียกใช้นั้นผ่านการทดสอบสำหรับทั้งคำขอที่คาดหวังและคำขอที่ผิดพลาดแล้ว

DEV Community