DEV Community: Thanawat Wongchai

Strands Agents คืออะไร? SDK โอเพนซอร์สสำหรับเอเจนต์ที่ขับเคลื่อนด้วยโมเดลจาก AWS

Thanawat Wongchai — Fri, 26 Jun 2026 08:34:20 +0000

หากคุณเคยสร้าง AI agent ด้วยการต่อ if/else หรือ state machine ขนาดใหญ่ คุณจะรู้ว่ามันเปราะบางเร็วแค่ไหน Strands Agents ใช้แนวทางตรงข้าม: ให้โมเดลวางแผนเอง และให้คุณกำหนดเพียง system prompt กับรายการเครื่องมือ เป็น SDK โอเพนซอร์สจาก AWS เปิดตัวในเดือนพฤษภาคม 2025 ภายใต้ Apache License 2.0 และถูกใช้เป็นส่วนหนึ่งของ agent ที่ใช้งานจริงภายในทีม Amazon เช่น Amazon Q Developer และ AWS Glue

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

Strands Agents คืออะไร

Strands Agents คือ SDK สำหรับสร้างและรัน AI agent โดยใช้โครงสร้างหลัก 3 ส่วน:

Model: โมเดลที่ใช้ reasoning และตัดสินใจ
System prompt: คำสั่งหลักที่กำหนดบทบาทและขอบเขตของ agent
Tools: ฟังก์ชันหรือบริการที่ agent เรียกใช้เพื่อทำงานจริง

ลูปการทำงานคือ: โมเดลอ่านคำสั่ง → ตัดสินใจว่าจะใช้เครื่องมือใด → เรียกเครื่องมือ → อ่านผลลัพธ์ → ทำต่อจนกว่างานจะเสร็จ

SDK รองรับทั้ง Python และ TypeScript ชื่อ “Strands” สื่อถึงสองเส้นหลักของ agent: โมเดล และ เครื่องมือ AWS เปิดโอเพนซอร์สหลังจากใช้งานภายในองค์กรแล้ว จึงสะท้อนโจทย์การใช้งานจริงมากกว่าตัวอย่างเดโมทั่วไป

ตั้งแต่รุ่นพรีวิว Strands มียอดดาวน์โหลดบน PyPI มากกว่า 150,000 ครั้ง และเวอร์ชัน 1.0 เพิ่มพื้นฐานสำหรับ multi-agent รวมถึงรองรับโปรโตคอล Agent-to-Agent หรือ A2A

ถ้าคุณเคยใช้เฟรมเวิร์กอย่าง LangGraph หรือ Google ADK แนวคิดจะคุ้นเคย แต่ Strands เน้นให้โมเดลควบคุม flow มากกว่าให้คุณวาด graph เองทุกขั้น

แนวคิดหลัก: model-driven แทน hard-coded orchestration

เฟรมเวิร์ก agent หลายตัวให้คุณกำหนด workflow ล่วงหน้า เช่น node, edge, condition และ routing วิธีนี้ควบคุมได้ดี แต่ทุกความสามารถใหม่มักหมายถึง graph ที่ซับซ้อนขึ้น

Strands ย้ายภาระการวางแผนไปให้โมเดล คุณกำหนดเป้าหมายและเครื่องมือ จากนั้นโมเดลเลือกขั้นตอนเอง

แนวทาง	คุณต้องกำหนด	Flow ถูกควบคุมโดย	เมื่อเพิ่มความสามารถใหม่
Hard-coded orchestration	Node, edge, condition, routing	โค้ด graph	แก้ graph และทดสอบ path ใหม่
Model-driven ด้วย Strands	Prompt + tools	Reasoning loop ของโมเดล	เพิ่ม tool และปรับ prompt

ข้อแลกเปลี่ยนคือ model-driven สร้างเร็วและปรับง่ายกว่า แต่ผลลัพธ์อาจคาดเดายากกว่า graph ที่ล็อกทุกสาขาไว้ล่วงหน้า หาก workflow ต้องทำเหมือนเดิมทุกครั้ง คุณยังใช้ hooks หรือ multi-agent pattern เพื่อเพิ่มโครงสร้างได้

สร้าง Strands agent ตัวแรก

ตัวอย่างที่เล็กที่สุดคือ agent ที่มี tool หนึ่งตัว:

from strands import Agent, tool

@tool
def word_count(text: str) -> int:
    """Count the words in a block of text."""
    return len(text.split())

agent = Agent(
    system_prompt="You are a concise writing assistant.",
    tools=[word_count],
)

response = agent("How many words are in this sentence?")
print(response)

จุดที่ควรสังเกต:

@tool แปลงฟังก์ชัน Python ปกติให้โมเดลเรียกใช้ได้
Docstring กลายเป็นคำอธิบาย tool
Type hints กลายเป็น input schema
agent(...) จะรัน reasoning loop จนกว่าโมเดลจะเห็นว่างานเสร็จ

ในโปรเจกต์จริง ให้เขียน tool ให้เล็ก ชัดเจน และคืนค่าที่มีโครงสร้าง เช่น dict หรือ object ที่ schema คงที่ เพื่อให้ทดสอบง่าย

ตัวอย่าง tool ที่เรียก HTTP API:

from strands import tool
import requests

@tool
def get_user_profile(user_id: str) -> dict:
    """Fetch a user profile by user ID."""
    response = requests.get(
        f"https://api.example.com/users/{user_id}",
        timeout=10,
    )
    response.raise_for_status()
    return response.json()

แนวทางที่ควรทำ:

ตั้ง timeout ทุกครั้ง
handle error จาก API ให้ชัดเจน
คืน response ที่ predictable
แยก config เช่น base URL และ API key ออกจากโค้ด

เลือก model provider

Strands ใช้ Amazon Bedrock เป็น provider เริ่มต้น และโดยทั่วไป agent จะใช้ Claude Sonnet ใน region us-west-2 แต่ ID ของโมเดลเริ่มต้นอาจเปลี่ยนตามเวอร์ชัน SDK ดังนั้นควรตรวจสอบจากเวอร์ชันที่ติดตั้ง ไม่ควร hard-code โดยไม่ตรวจสอบ

Provider ที่ใช้งานได้รวมถึง:

Amazon Bedrock model ที่รองรับ tool use และ streaming
Anthropic Claude ผ่าน Anthropic API
Llama ผ่าน Llama API
Ollama สำหรับ local development
Provider อื่น เช่น OpenAI ผ่าน LiteLLM

แนวคิดสำคัญคือการเปลี่ยน provider ควรเป็นการเปลี่ยน model object ไม่ใช่เขียน agent ใหม่ทั้งหมด ดังนั้นคุณสามารถ prototype ด้วย Ollama ในเครื่อง แล้ว deploy ด้วย Bedrock ได้โดยยังใช้ prompt และ tools ชุดเดิม

ใช้ tools และ MCP ให้คุ้ม

Tool คือช่องทางที่ agent ใช้ติดต่อโลกภายนอก อาจเป็น:

ฟังก์ชัน Python ที่คุณเขียนเอง
เครื่องมือจาก community
HTTP API ที่ห่อด้วยฟังก์ชัน
MCP server ที่ expose tools หลายตัว

MCP หรือ Model Context Protocol เป็นมาตรฐานเปิดสำหรับเชื่อมโมเดลกับเครื่องมือและแหล่งข้อมูล เมื่อใช้กับ Strands คุณสามารถเชื่อมต่อ MCP server แล้วส่ง tools เหล่านั้นให้ agent ได้โดยตรง

แนวทางใช้งานที่ practical:

เริ่มจาก tool ที่เขียนเองก่อน หาก logic ยังเล็ก
ใช้ MCP เมื่อคุณมีระบบภายนอกหลายตัวหรือมี MCP server อยู่แล้ว
ทดสอบ MCP server แยกจาก agent เสมอ
กำหนด fallback behavior เมื่อ tool หรือ MCP server ล่ม

ถ้า MCP server มีปัญหา agent อาจดูเหมือน “โมเดลตอบผิด” ทั้งที่จริงแล้ว dependency ด้าน API ล้มเหลว ดังนั้นควรแยกทดสอบ transport, auth, response schema และ error case ให้ครบ

Multi-agent และ A2A

Agent ตัวเดียวเพียงพอสำหรับหลาย use case แต่ระบบจริงอาจต้องแบ่งงานเป็นหลาย agent เช่น:

agent หนึ่งวิเคราะห์ requirement
agent หนึ่งเรียก API
agent หนึ่งสรุปผลลัพธ์
agent หนึ่งตรวจสอบความถูกต้อง

Strands 1.0 เพิ่มพื้นฐานสำหรับ multi-agent เช่น:

Agent-as-Tool: ให้ agent หนึ่งถูกเรียกเหมือน tool โดย agent อื่น
Swarm coordination: ให้หลาย agent ร่วมกันแก้ปัญหา
A2A protocol: ให้ Strands agent สื่อสารกับ agent จากเฟรมเวิร์กอื่นได้

ใช้ multi-agent เมื่อบทบาทแยกกันชัดเจน อย่าแยกเพียงเพราะอยากให้ architecture ดูซับซ้อนขึ้น เพราะทุก agent ที่เพิ่มเข้ามาคือ surface area เพิ่มขึ้นสำหรับ latency, cost และ debugging

Deploy Strands agent

Strands ถูกออกแบบให้ย้ายจาก local development ไป production ได้โดยไม่ต้องเปลี่ยนเฟรมเวิร์ก เป้าหมาย deployment ที่พบบ่อยคือ:

Amazon Bedrock AgentCore สำหรับ managed agent runtime
AWS Lambda สำหรับ event-driven agent อายุสั้น
AWS Fargate หรือ Amazon EKS สำหรับ service แบบ container ที่รันต่อเนื่อง
Docker runtime ทั่วไปใน environment ที่คุณควบคุมเอง

Checklist ก่อน deploy:

แยก environment variables เช่น API keys, model ID, region
ตั้ง timeout และ retry ให้ tool ที่เรียก network
log tool calls และผลลัพธ์ที่สำคัญ
ปิด logging สำหรับข้อมูลลับ
ทดสอบ error cases เช่น API 401, 429, 500 และ timeout
เพิ่ม observability hooks เพื่อติดตามว่าโมเดลเรียก tool ใดและตัดสินใจอย่างไร

เพราะ Strands agent เป็น Python หรือ TypeScript application ปกติ การ package จึงใช้แนวทางเดียวกับ backend service ทั่วไป

Apidog เหมาะกับส่วนไหนของ Strands workflow

Strands ช่วยสร้าง agent แต่ไม่ได้สร้างหรือ validate API ที่ agent เรียกใช้ ในระบบจริง agent มักพึ่งพา HTTP endpoints อย่างน้อยสองกลุ่ม:

LLM provider API ที่อยู่เบื้องหลัง model
REST/tool API หรือ MCP endpoint ที่อยู่เบื้องหลัง tools

ถ้า endpoint เหล่านี้ผิด schema, timeout, auth fail หรือคืน error ที่ไม่ได้คาดไว้ agent อาจล้มเหลวในรูปแบบที่ดูเหมือนปัญหาของโมเดล ทั้งที่จริงเป็นปัญหา API

Apidog ใช้ทดสอบและจำลอง API เหล่านี้ก่อนให้ agent เรียกจริง ตัวอย่าง workflow ที่ใช้ได้ทันที:

Mock model หรือ tool endpoint ระหว่างพัฒนา เพื่อไม่ต้องเสีย token หรือชน rate limit ทุกครั้ง ดูตัวอย่างแนวทางในบทความ AI agent test harness ด้วย Apidog
ตรวจ response schema ของ tools เช่น field, type, status code และ error payload ด้วย API assertions
ตั้งค่า mock API เพื่อจำลอง success case และ failure case ที่ agent ต้อง handle
จัดการ API keys ตาม environment เช่น dev, staging และ production โดยไม่ hard-code credential ใน agent
รัน regression test ใน CI เพื่อให้รู้ทันทีเมื่อ backend contract เปลี่ยนและอาจทำให้ agent พัง

Apidog ไม่ใช่ agent framework และไม่ได้ orchestrate reasoning loop ให้ Strands ยังคงเป็นสมองของ agent ส่วน Apidog เป็น workbench สำหรับทดสอบ API, mock dependency และตรวจ contract ของ service ที่ agent เรียกใช้ คุณสามารถ ดาวน์โหลด Apidog แล้วเริ่ม mock tool endpoints ได้ภายในไม่กี่นาที

ตัวอย่าง workflow สำหรับทีม dev

หากต้องการเริ่มใช้ Strands แบบเป็นระบบ ให้ใช้ขั้นตอนนี้:

นิยาม use case ให้เล็ก
- เช่น “สรุปข้อมูล user จาก API แล้วตอบเป็น bullet”
- หลีกเลี่ยงงานกว้างเกินไปใน agent ตัวแรก
เขียน tools เป็นฟังก์ชันเล็ก
- หนึ่ง tool ต่อหนึ่งความสามารถ
- ใช้ type hints และ docstring ชัดเจน
mock API ก่อนเรียกของจริง
- สร้าง mock response สำหรับ success, not found, unauthorized, rate limit
- ตรวจว่า agent handle ทุกกรณีได้
เขียน system prompt
- ระบุบทบาท
- ระบุข้อจำกัด
- ระบุวิธีใช้ tool หากจำเป็น
- ระบุรูปแบบ output
ทดสอบแบบ end-to-end
- ทดสอบ prompt + tool + API
- เก็บ log ของ tool calls เพื่อ debug
เพิ่ม observability ก่อน production
- trace การเรียก tool
- record latency
- monitor error rate
- ตรวจ cost จาก model provider

ควรใช้ Strands Agents เมื่อใด

เลือกใช้ Strands เมื่อ:

คุณต้องการสร้าง agent ได้เร็ว
คุณเชื่อให้โมเดลวางแผนขั้นตอนเองได้
คุณใช้งาน AWS หรือ Bedrock อยู่แล้ว
คุณต้องการเริ่มจาก agent ตัวเดียวแล้วค่อยขยายเป็น multi-agent
คุณต้องการใช้ MCP tools โดยไม่เขียน integration เองทั้งหมด

อาจไม่เหมาะเมื่อ:

workflow ต้อง deterministic มาก
ทุก branch ต้องถูกกำหนดล่วงหน้า
compliance ต้องตรวจ flow แบบ static ได้ละเอียด
คุณต้องการ graph-based orchestration เป็นแกนหลัก

สรุปคือ Strands เหมาะกับงาน model-driven ส่วน graph-based framework เหมาะกับงานที่ต้องควบคุม path อย่างเข้มงวด หลายทีมสามารถใช้ทั้งสองแนวทางใน service คนละประเภทได้

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

Strands Agents เป็นโอเพนซอร์สและใช้ฟรีหรือไม่

ใช่ Strands Agents เป็นโอเพนซอร์สภายใต้ Apache License 2.0 และมีซอร์สโค้ดบน GitHub ไม่มีค่า license สำหรับ SDK แต่คุณยังต้องจ่ายค่า model provider และ cloud resource ที่ใช้ เช่น Bedrock inference หรือ Lambda execution

ต้องใช้ Amazon Bedrock กับ Strands หรือไม่

ไม่จำเป็น Bedrock เป็น provider เริ่มต้น แต่ Strands รองรับ Anthropic API, Llama API, Ollama สำหรับ local development และ provider อื่นผ่าน LiteLLM คุณเปลี่ยน model object ได้โดยไม่ต้องเขียน agent ใหม่ทั้งหมด

Strands ต่างจาก framework แบบ graph-first อย่างไร

Strands เป็น model-driven: คุณให้ prompt และ tools แล้วให้โมเดลตัดสินใจขั้นตอนเอง ส่วน graph-first framework ให้คุณกำหนด flow เป็น node และ edge ล่วงหน้า Strands ปรับเร็วกว่า แต่ graph-first ควบคุมได้ละเอียดและคาดเดาได้มากกว่า

จะทดสอบ API ที่ Strands agent พึ่งพาได้อย่างไร

ให้ทดสอบแยกจาก agent ตั้งแต่ต้น Mock LLM และ tool endpoints, validate response schema และรัน test เหล่านี้ใน CI เครื่องมืออย่าง Apidog ช่วยจัดการ mock และ assertion ได้ รวมถึงบทความ การทดสอบ ChatGPT API ด้วย Apidog ที่ครอบคลุม authentication, streaming และ tool-call testing

สรุป

Strands Agents เสนอวิธีสร้าง agent ที่เรียบง่าย: กำหนด model, prompt และ tools แล้วให้โมเดลรัน reasoning loop เอง มันเริ่มจาก agent ตัวเดียวได้ ขยายเป็น multi-agent ได้ รองรับ MCP และ A2A และ deploy บน AWS stack ได้โดยไม่ต้องเปลี่ยน architecture หลัก

งานของคุณคือทำให้ tools และ API ที่ agent เรียกใช้มี contract ชัดเจน ทดสอบได้ และล้มเหลวแบบคาดเดาได้ ตรงนี้คือจุดที่ Apidog ช่วยได้: mock, test และ validate endpoints ก่อนที่ปัญหาจะไปโผล่ใน production

Semantic Kernel คืออะไร: SDK จัดการ AI ของ Microsoft

Thanawat Wongchai — Fri, 26 Jun 2026 08:29:04 +0000

หากคุณพัฒนาซอฟต์แวร์บน Microsoft stack และต้องการเพิ่ม AI โดยไม่ต้องผูกบริการ Python เข้าไปเสริม Semantic Kernel คือ SDK โอเพนซอร์สจาก Microsoft สำหรับเชื่อมโค้ดและ API ที่มีอยู่กับโมเดลภาษาขนาดใหญ่ รองรับ C#, Python และ Java บทความนี้สรุปวิธีใช้ Semantic Kernel แบบลงมือทำ: kernel, plugins, functions, การนำเข้า OpenAPI specification และแนวทางทดสอบ API ที่เอเจนต์จะเรียกใช้งาน

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

Semantic Kernel คืออะไร

Semantic Kernel (SK) เป็น SDK โอเพนซอร์สจาก Microsoft สำหรับสร้างเอเจนต์ AI และผสานโมเดลเข้ากับโค้ดเบสของคุณ มองง่ายๆ คือ middleware ระหว่างแอปพลิเคชันกับโมเดล: รับคำสั่งจากโมเดล แปลงเป็นการเรียกฟังก์ชันจริง รันโค้ด แล้วส่งผลลัพธ์กลับไปให้โมเดล

จุดที่ทำให้ SK เหมาะกับงานจริงมี 3 เรื่องหลัก:

รองรับหลายภาษา: มี SDK อย่างเป็นทางการสำหรับ C#/.NET, Python และ Java พร้อมความเสถียรระดับ 1.0+
ไม่ผูกกับโมเดลเดียว: เชื่อมต่อ OpenAI, Azure OpenAI และผู้ให้บริการอื่นผ่าน connector ได้
ออกแบบสำหรับองค์กร: รองรับ telemetry, hooks และ filters เพื่อบันทึก ตรวจสอบ และควบคุมสิ่งที่ AI ทำ

ถ้า backend ของคุณเป็น .NET และต้องการนำ AI เข้ามาโดยไม่สร้าง Python sidecar เพิ่ม Semantic Kernel เป็นตัวเลือกที่ควรพิจารณา

แกนหลัก: kernel, plugins และ functions

ออบเจกต์หลักของ SK คือ Kernel ซึ่งทำหน้าที่คล้าย dependency injection container สำหรับ AI คุณลงทะเบียน model connector และ plugin ไว้ใน kernel จากนั้นให้ kernel จัดการลูปการทำงาน:

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

ใน SK มีแนวคิดสำคัญ 2 ระดับ:

Plugin: กลุ่มของฟังก์ชันที่เปิดให้โมเดลเรียกใช้
Function: ความสามารถหนึ่งรายการที่โมเดลสามารถเรียกได้

ฟังก์ชันมี 2 ประเภทหลัก:

Native functions: เมธอดปกติในโค้ด เช่น C# method หรือ Python function ที่ annotate เพื่อให้โมเดลเข้าใจ
Prompt functions: prompt template ที่เรียกโมเดลอีกครั้ง เหมาะกับงานสรุป จัดหมวดหมู่ หรือ rewrite ข้อความ

ตัวอย่าง C# ขั้นพื้นฐาน:

var builder = Kernel.CreateBuilder();

builder.AddOpenAIChatCompletion(
    modelId: "gpt-4o",
    apiKey: apiKey
);

builder.Plugins.AddFromType<LightsPlugin>("Lights");

Kernel kernel = builder.Build();

var result = await kernel.InvokePromptAsync(
    "Turn the kitchen light blue"
);

ตัวอย่าง plugin แบบ native function:

using Microsoft.SemanticKernel;
using System.ComponentModel;

public class LightsPlugin
{
    [KernelFunction("change_light_state")]
    [Description("Change the state and color of a light")]
    public string ChangeLightState(
        [Description("The room name, for example kitchen or bedroom")]
        string room,
        [Description("The target color")]
        string color
    )
    {
        // เรียก service หรือ API จริงของคุณที่นี่
        return $"Changed {room} light to {color}";
    }
}

เมื่อโมเดลตัดสินใจว่า intent ของผู้ใช้ต้องใช้ change_light_state kernel จะรันเมธอดจริง บันทึกผลลัพธ์ และส่งกลับไปยังโมเดลเพื่อสร้างคำตอบสุดท้าย

รูปแบบ OpenAPI-to-plugin

จุดที่มีประโยชน์มากของ Semantic Kernel คือการนำเข้า OpenAPI specification แล้วเปลี่ยนแต่ละ operation ให้เป็น function ที่โมเดลเรียกได้โดยอัตโนมัติ

แทนที่จะเขียน wrapper เองทุก endpoint คุณสามารถ:

เตรียม OpenAPI spec ของ REST API
ให้ SK import spec
ให้โมเดลเรียก operation ที่เหมาะสมผ่าน function calling
ให้ SK สร้าง HTTP request และจัดการ response

ตัวอย่าง C#:

await kernel.ImportPluginFromOpenApiAsync(
    pluginName: "lights",
    uri: new Uri("https://example.com/v1/swagger.json"),
    executionParameters: new OpenApiFunctionExecutionParameters
    {
        EnablePayloadNamespacing = true
    }
);

ใน Python แนวคิดเดียวกันคือใช้ add_plugin_from_openapi ส่วน Java ก็มี importer ที่เทียบเท่า

เบื้องหลัง SK จะ:

อ่าน path และ operation จาก OpenAPI spec
ดึงชื่อ คำอธิบาย parameter type และ schema
แปลง operation เป็น callable function
ส่ง metadata เหล่านี้ให้โมเดล
สร้าง HTTP request เมื่อโมเดลเลือกเรียก operation
อ่าน response แล้วส่งกลับเข้า context ของโมเดล

SK รองรับ OpenAPI 2.0 และ 3.0 และสามารถ downgrade 3.1 เป็น 3.0 ได้หากทำได้

เช็กลิสต์สำหรับทำ OpenAPI spec ให้เหมาะกับเอเจนต์

OpenAPI spec ที่เขียนเพื่อมนุษย์อ่านได้ อาจยังไม่ชัดพอสำหรับโมเดล ก่อนนำเข้า SK ควรตรวจรายการเหล่านี้:

ใช้ operationId ที่สื่อความหมาย เช่น getCustomerById แทน getData
เขียน description ของ endpoint ให้บอก intent ชัดเจน
เขียนคำอธิบาย parameter ให้บอก format และข้อจำกัด
ใช้ enum เมื่อค่าที่รับได้มีจำนวนจำกัด
หลีกเลี่ยง string กว้างๆ ที่ไม่มี schema ชัดเจน
แยก endpoint ที่จำเป็นจริงๆ ให้โมเดลใช้ ไม่ต้องเปิดทั้งระบบ
ตรวจ response schema ให้ตรงกับของจริง

ตัวอย่าง schema ที่ช่วยให้โมเดลเลือกใช้งานได้ดีขึ้น:

paths:
  /lights/{room}/state:
    post:
      operationId: changeLightState
      summary: Change light state in a specific room
      description: Use this operation to change the color or power state of a room light.
      parameters:
        - name: room
          in: path
          required: true
          description: Room name, such as kitchen, bedroom, or living_room.
          schema:
            type: string
            enum: [kitchen, bedroom, living_room]
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - color
              properties:
                color:
                  type: string
                  description: Target light color.
                  enum: [red, blue, green, white]

คุณภาพของ spec ส่งผลโดยตรงต่อคุณภาพของการเรียก tool ของเอเจนต์

เอเจนต์และการวางแผน

Semantic Kernel เริ่มจากแนวคิด planner ที่แยกเป้าหมายเป็นขั้นตอน แต่แนวทางปัจจุบันขยับไปใช้ function calling มากขึ้น โดยให้โมเดลตัดสินใจเองว่าจะเรียก function ใดและเรียกตามลำดับใด ซึ่งเข้ากับโมเดลสมัยใหม่ได้ดีกว่า

นอกจากนี้ SK ยังมี Agent Framework layer สำหรับ:

session-based state
agent loop
multi-agent pattern
การเชื่อมต่อเครื่องมือภายนอกผ่าน Model Context Protocol (MCP)

ถ้าคุณกำลังเลือก framework สำหรับงานเอเจนต์ ภาพรวมเปรียบเทียบมีดังนี้:

เฟรมเวิร์ก	ภาษาหลัก	โมเดลการจัดการ	เหมาะที่สุดสำหรับ
Semantic Kernel	C#/.NET, Python, Java	การเรียกฟังก์ชัน + เอเจนต์	ทีม .NET และองค์กร
LangGraph	Python, JS	กราฟสถานะที่ชัดเจน	เวิร์กโฟลว์เอเจนต์ที่ซับซ้อนและมีการแตกแขนง
Google ADK	Python	โมเดลเอเจนต์ + เครื่องมือ	สแต็ก Google Cloud และ Gemini
OpenAI Agents SDK	Python, JS	เอเจนต์ + การส่งต่อ	แอปที่เน้น OpenAI เป็นหลัก

ไม่มีตัวเลือกที่ดีที่สุดสำหรับทุกกรณี ให้เลือกจากภาษาหลักของทีม provider ของโมเดล และระดับการควบคุม workflow ที่ต้องการ

Semantic Kernel เหมาะกับ Microsoft Agent Framework อย่างไร

Microsoft ได้เปิดตัว Microsoft Agent Framework (MAF) และเอกสารระบุว่าเป็นผู้สืบทอดโดยตรงของทั้ง Semantic Kernel และ AutoGen ซึ่งพัฒนาโดยทีมเดียวกัน MAF รวมแนวคิดเอเจนต์จาก AutoGen เข้ากับคุณสมบัติระดับองค์กรของ SK และเพิ่ม workflow แบบ graph สำหรับ multi-agent orchestration

ในทางปฏิบัติ:

แอป Semantic Kernel ที่มีอยู่ยังใช้งานต่อได้ และ SK ยังได้รับการสนับสนุน
โปรเจกต์ใหม่ที่ต้องการทิศทางล่าสุดควรอ่านเอกสาร MAF ก่อนเริ่ม
รูปแบบ OpenAPI-to-plugin ยังเป็นแนวทางสำคัญในทั้งสองเฟรมเวิร์ก
ถ้าคุณมีโค้ด SK อยู่แล้ว ไม่จำเป็นต้องรีบย้ายทันที
ถ้าคุณเริ่มใหม่และต้องทำ multi-agent ซับซ้อน ให้ประเมิน MAF ด้วย

สรุปคือ SK ยังเป็นตัวเลือกที่มั่นคงสำหรับ production โดยเฉพาะใน stack .NET ส่วน MAF คือทิศทางใหม่ที่ Microsoft กำลังลงทุนต่อ

เมื่อใดควรใช้ Semantic Kernel

เลือกใช้ Semantic Kernel เมื่อ:

backend ของคุณคือ .NET หรือ Java
คุณไม่ต้องการเพิ่ม Python service แยกเพื่อจัดการ AI
คุณมี REST API อยู่แล้วและต้องการให้โมเดลเรียกผ่าน OpenAPI spec
คุณต้องการ telemetry, filters, hooks และ auditability
คุณต้องการเปลี่ยน provider ของโมเดลได้โดยไม่ rewrite ทั้งแอป
คุณต้องการเริ่มจาก function calling ก่อน แล้วค่อยต่อยอดเป็น agent

ควรมองหาทางเลือกอื่นเมื่อ:

ทีมใช้ Python เป็นหลักทั้งหมด
ต้องการ multi-agent workflow ใหม่ล่าสุด
ต้องการ graph-based orchestration ที่ควบคุม state ทุกจุดอย่างชัดเจน

ในกรณีนั้น MAF หรือ framework แบบ graph-first อาจเหมาะกว่า

การทดสอบ API ที่อยู่เบื้องหลังเอเจนต์ Semantic Kernel

Semantic Kernel ไม่ได้แทนที่ API ของคุณ แต่มันเรียกใช้ API เหล่านั้น ดังนั้นคุณภาพของเอเจนต์ขึ้นอยู่กับคุณภาพของ endpoint และ OpenAPI spec โดยตรง

Apidog มีประโยชน์ในจุดนี้ เพราะช่วยออกแบบ ทดสอบ mock และตรวจสัญญา API ก่อนนำไปใช้กับเอเจนต์

งานที่ควรทำก่อนให้ SK import OpenAPI spec:

1. ตรวจ OpenAPI spec ก่อนนำเข้า

เพราะ SK ใช้ชื่อ operation, description, parameter และ schema จาก spec เพื่ออธิบาย tool ให้โมเดล ถ้า spec คลุมเครือ โมเดลก็มีโอกาสเรียก tool ผิด

ตรวจให้ครบ:

endpoint มี operationId
parameter มี type และ description
request body มี schema
response ตรงกับของจริง
auth mechanism ชัดเจน
error response ถูกระบุไว้

2. Mock API ระหว่างพัฒนา

ถ้า endpoint ยังไม่พร้อม คุณสามารถสร้าง mock API เพื่อให้ SK เรียกได้ก่อน วิธีนี้ช่วยแยกการพัฒนา agent loop ออกจาก backend จริง

ดูรูปแบบเพิ่มเติมได้ที่ วิธีจำลองการเรียกใช้ API

3. ยืนยัน response shape ด้วย assertions

ใช้ API assertions เพื่อตรวจว่า endpoint ที่เอเจนต์เรียกยังส่ง response ตาม schema ที่คาดหวัง เช่น:

field สำคัญต้องมีเสมอ
type ต้องตรง
status code ต้องถูกต้อง
error format ต้องคงที่

วิธีนี้ช่วยลดกรณีที่ backend เปลี่ยนแล้วพฤติกรรมของเอเจนต์เสียโดยไม่รู้ตัว

4. แยก environment และ credential

อย่าฮาร์ดโค้ด LLM key หรือ API key ในโค้ด agent ให้แยก environment เช่น:

dev
staging
prod

และใช้ key คนละชุดสำหรับแต่ละ environment เพื่อลดความเสี่ยงและควบคุม quota ได้ง่ายขึ้น

ถ้าต้องการตัวอย่างการทดสอบ tool call ของเอเจนต์แบบละเอียด ดู การทดสอบการเรียกใช้เครื่องมือของเอเจนต์ด้วย Apidog

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

Semantic Kernel เป็นโอเพนซอร์สและฟรีหรือไม่?

ใช่ Semantic Kernel เป็นโอเพนซอร์สและเผยแพร่โดย Microsoft บน GitHub ภายใต้ permissive license มี SDK สำหรับ C#/.NET, Python และ Java คุณจ่ายค่าการใช้งานโมเดล เช่น OpenAI หรือ Azure OpenAI ไม่ใช่ตัว SK เอง

Semantic Kernel รองรับภาษาใดบ้าง?

รองรับ C#/.NET, Python และ Java โดยทั้งหมดมีความเสถียรระดับ 1.0+ SDK สำหรับ C# มักสมบูรณ์ที่สุด แต่ Python และ Java ก็ครอบคลุมฟีเจอร์หลัก เช่น kernel, plugins และการนำเข้า OpenAPI

Semantic Kernel ใช้ OpenAPI specs อย่างไร?

คุณนำเข้าสเปกด้วย ImportPluginFromOpenApiAsync ใน C# หรือ add_plugin_from_openapi ใน Python จากนั้น SK จะเปลี่ยนแต่ละ operation ให้เป็น function ที่โมเดลเรียกได้ พร้อม metadata ของ parameter และ schema

ก่อนนำเข้า ควรตรวจ spec และทดสอบ endpoint จริงด้วย Apidog เพื่อให้แน่ใจว่า contract ถูกต้อง

ฉันควรใช้ Semantic Kernel หรือ Microsoft Agent Framework ดี?

ถ้ามีแอป Semantic Kernel อยู่แล้ว ให้ใช้ต่อได้ เพราะยังได้รับการสนับสนุนและมีความเสถียร ถ้าเริ่มโปรเจกต์ใหม่ ให้ตรวจเอกสาร Microsoft Agent Framework ล่าสุดก่อน เพราะ Microsoft วางให้เป็นผู้สืบทอดของ SK และ AutoGen

สำหรับการทดสอบ API ที่ framework เหล่านี้เรียกใช้ ดู วิธีทดสอบ ChatGPT API ด้วย Apidog

สรุป

Semantic Kernel เป็นวิธีที่ตรงไปตรงมาสำหรับทีมบน Microsoft stack ที่ต้องการเพิ่ม AI เข้าแอป: ใช้ kernel เชื่อมโมเดลกับโค้ด ใช้ plugins/functions เปิดความสามารถให้โมเดล และใช้ OpenAPI import เพื่อเปลี่ยน REST API ที่มีอยู่ให้เป็น tool ของเอเจนต์

ถ้าคุณใช้ .NET, Java หรือมี API จำนวนมากที่ต้องการให้โมเดลเรียกใช้งาน SK เป็นตัวเลือกที่ใช้งานได้จริงและเหมาะกับ production ส่วน Microsoft Agent Framework คือทิศทางใหม่ที่ควรติดตามสำหรับโปรเจกต์เอเจนต์รุ่นถัดไป

ไม่ว่าจะเลือกทางไหน API ที่เอเจนต์เรียกต้องถูกต้องและทดสอบได้ก่อนเสมอ หากต้องการออกแบบ mock และทดสอบ OpenAPI spec กับ endpoint ที่เอเจนต์พึ่งพา ให้ ดาวน์โหลด Apidog และสร้าง contract ให้ชัดเจนก่อนปล่อยให้เอเจนต์เรียกใช้งาน

PydanticAI คืออะไร: คู่มือเฟรมเวิร์กเอเจนต์ Python แบบ Type-Safe

Thanawat Wongchai — Fri, 26 Jun 2026 08:28:02 +0000

หากคุณเคยส่งมอบฟีเจอร์ LLM แล้วเจอ JSON รูปแบบผิดใน production, PydanticAI ถูกออกแบบมาเพื่อแก้ปัญหานี้โดยตรง มันคือเฟรมเวิร์กเอเจนต์ Python จากทีมเดียวกับ Pydantic ที่โฟกัสเอาต์พุตแบบ type-safe และผ่าน validation เหมาะกับงานที่ผลลัพธ์จากโมเดลต้องถูกส่งต่อเข้าโค้ดจริง เช่น API, database, billing flow หรือ workflow อัตโนมัติ บทความนี้สรุปวิธีใช้ PydanticAI แบบลงมือทำ และเปรียบเทียบกับเฟรมเวิร์ก Python อื่น เช่น LangGraph

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

PydanticAI คืออะไร

PydanticAI เป็นเฟรมเวิร์กเอเจนต์แบบโอเพนซอร์สสำหรับ Python ที่ไม่ผูกกับผู้ให้บริการโมเดลใดโมเดลหนึ่ง ทีมผู้ดูแลคือทีมเดียวกับ Pydantic Validation และ Pydantic Logfire เป้าหมายหลักคือทำให้การสร้างเอเจนต์มีประสบการณ์ใกล้เคียง FastAPI: ประกาศ schema ชัดเจน, validate อัตโนมัติ, และทำงานร่วมกับ type checker ได้ดี

แนวคิดหลักคือคุณกำหนดว่าเอเจนต์ต้องทำอะไร ใช้เครื่องมืออะไรได้บ้าง และเอาต์พุตต้องมีรูปแบบแบบใด จากนั้น PydanticAI จะจัดการการเรียกโมเดล ตรวจสอบผลลัพธ์กับโมเดล Pydantic และ retry เมื่อโมเดลตอบกลับมาไม่ตรง schema

โปรเจกต์นี้ออกเวอร์ชัน v2.0.0 ที่เสถียรเมื่อวันที่ 23 มิถุนายน 2026 หลังผ่านช่วงเบต้าหลายรอบ เวอร์ชัน 2 เน้นการออกแบบแบบ harness-first โดยให้เครื่องมือ, hooks, คำสั่ง และการตั้งค่าโมเดลประกอบกันเป็นหน่วยที่นำกลับมาใช้ซ้ำได้

ติดตั้งได้ด้วย:

pip install pydantic-ai

หรือถ้าใช้ uv:

uv add pydantic-ai

ทำไม type safety จึงสำคัญกับเอเจนต์

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

เขียนข้อมูลลงฐานข้อมูล
เรียก REST API ถัดไป
คำนวณราคา
เปิด ticket
trigger workflow อัตโนมัติ

ปัญหาที่พบบ่อยคือโมเดล “ส่วนใหญ่” ส่ง JSON ถูกต้อง แต่บางครั้งขาด field, ใช้ type ผิด, หรือห่อ JSON ด้วยข้อความอธิบาย ทำให้ parser หรือ pipeline พังใน production สุดท้ายทีมต้องเขียน regex cleanup, defensive parsing และ retry loop เอง

PydanticAI แก้จุดนี้โดยให้คุณประกาศสัญญาของเอาต์พุตผ่าน output_type:

from pydantic import BaseModel
from pydantic_ai import Agent

class SupportTicket(BaseModel):
    category: str
    priority: int
    summary: str

agent = Agent(
    'openai:gpt-4o',
    output_type=SupportTicket,
)

result = agent.run_sync('My payment failed three times today.')

ticket = result.output
print(ticket.category)
print(ticket.priority)
print(ticket.summary)

ผลลัพธ์ที่คุณได้คือ object ที่ผ่าน validation แล้ว ไม่ใช่ string ที่ต้องเดาเอง ถ้าโมเดลส่ง priority เป็นข้อความ หรือไม่ส่ง summary กลับมา PydanticAI จะส่ง validation error กลับไปให้ LLM และขอให้ลองตอบใหม่

หลักการเดียวกันใช้กับ tool arguments ด้วย เมื่อโมเดลเรียกใช้เครื่องมือ PydanticAI จะตรวจสอบ argument จาก type hints ก่อนเรียกฟังก์ชันจริง ทำให้ input ที่ผิดไม่ไหลเข้า business logic ของคุณ

แนวคิดหลักของ PydanticAI

1. Agent

Agent คือจุดเริ่มต้นหลัก คุณสร้างเอเจนต์ด้วย model identifier และคำสั่งเสริม:

from pydantic_ai import Agent

agent = Agent(
    'anthropic:claude-sonnet-4-6',
    instructions='Be concise, reply with one sentence.',
)

result = agent.run_sync('Where does "hello world" come from?')
print(result.output)

การสลับผู้ให้บริการมักทำได้โดยเปลี่ยน model string เพียงบรรทัดเดียว เช่นจาก Anthropic เป็น OpenAI:

agent = Agent(
    'openai:gpt-4o',
    instructions='Be concise, reply with one sentence.',
)

2. Typed output

ใช้ output_type เมื่อต้องการเอาต์พุตแบบมี schema:

from pydantic import BaseModel, Field
from pydantic_ai import Agent

class ProductSummary(BaseModel):
    name: str
    price: float
    tags: list[str] = Field(default_factory=list)

agent = Agent(
    'openai:gpt-4o',
    output_type=ProductSummary,
)

result = agent.run_sync(
    'Extract product info: Wireless mouse, 29.99 USD, gaming, bluetooth'
)

product = result.output

print(product.name)   # str
print(product.price)  # float
print(product.tags)   # list[str]

ข้อดีคือ IDE และ type checker เห็น field ทั้งหมด:

def save_product(product: ProductSummary) -> None:
    # product.price เป็น float ที่ validate แล้ว
    ...

คุณไม่ต้องเขียน logic แบบนี้เอง:

import json

raw = call_llm(...)
data = json.loads(raw)

if 'price' not in data:
    ...

3. Tools

Tools คือฟังก์ชันที่โมเดลสามารถเรียกใช้เพื่อเข้าถึงระบบภายนอก เช่น database, REST API หรือ calculation logic

ลงทะเบียน tool ด้วย @agent.tool:

from pydantic_ai import Agent, RunContext

agent = Agent(
    'openai:gpt-4o',
    deps_type=str,
)

@agent.tool
async def get_user_balance(
    ctx: RunContext[str],
    account_id: str,
) -> float:
    """Return the current balance for an account."""
    return await lookup_balance(ctx.deps, account_id)

PydanticAI จะอ่าน type hints และ docstring เพื่อสร้าง schema ที่โมเดลเห็น จากนั้น validate ทุก tool call ก่อนเรียกฟังก์ชันจริง

ตัวอย่าง flow:

ผู้ใช้ถามว่า “บัญชี A123 เหลือเงินเท่าไร”
โมเดลตัดสินใจเรียก get_user_balance
PydanticAI ตรวจว่า account_id เป็น str
ฟังก์ชัน tool ทำงาน
ผลลัพธ์ถูกส่งกลับให้โมเดลใช้ตอบผู้ใช้

4. Dependencies

เอเจนต์ production มักต้องใช้ dependency เช่น:

database connection
HTTP client
current user
API key
feature flag
service object

PydanticAI ใช้ dependency injection ผ่าน deps_type และ RunContext:

from dataclasses import dataclass
from pydantic_ai import Agent, RunContext

@dataclass
class Deps:
    api_base_url: str
    auth_token: str

agent = Agent(
    'openai:gpt-4o',
    deps_type=Deps,
)

@agent.tool
async def get_order_status(
    ctx: RunContext[Deps],
    order_id: str,
) -> str:
    """Get the status of an order."""
    return await fetch_order_status(
        base_url=ctx.deps.api_base_url,
        token=ctx.deps.auth_token,
        order_id=order_id,
    )

deps = Deps(
    api_base_url='https://api.example.com',
    auth_token='secret',
)

result = agent.run_sync(
    'Check order ORD-123',
    deps=deps,
)

ข้อดีคือทดสอบง่ายขึ้น เพราะคุณสามารถ inject fake dependency ใน test ได้โดยไม่ต้องแก้ logic ของ agent

5. Provider flexibility และ streaming

PydanticAI รองรับผู้ให้บริการหลายราย เช่น OpenAI, Anthropic, Gemini, DeepSeek, Grok, Cohere, Mistral, Perplexity รวมถึงตัวเลือกคลาวด์อย่าง Azure AI Foundry และ Amazon Bedrock และโมเดลที่โฮสต์เอง

การสลับ provider มักทำได้ด้วยการเปลี่ยน model string:

Agent('openai:gpt-4o')
Agent('anthropic:claude-sonnet-4-6')

นอกจากนี้ยังรองรับการ stream เอาต์พุตแบบ structured พร้อม validation ระหว่างข้อมูลทยอยเข้ามา ทำให้แสดงผลลัพธ์บางส่วนได้โดยยังรักษา type guarantees และสามารถเชื่อมกับ Pydantic Logfire สำหรับ tracing, debugging และ cost tracking ได้

PydanticAI เทียบกับเฟรมเวิร์กเอเจนต์ Python อื่นอย่างไร

ไม่มีเฟรมเวิร์กเดียวที่ดีที่สุดสำหรับทุกงาน ให้เลือกตามลักษณะระบบที่ต้องสร้าง:

เฟรมเวิร์ก	จุดแข็งหลัก	เหมาะเมื่อคุณต้องการ
PydanticAI	เอาต์พุตและ tool arguments แบบ type-safe พร้อม validation	ความน่าเชื่อถือใน production และ data flow ที่มี schema ชัดเจน
LangGraph	กราฟที่มี state และ control flow ชัดเจน	workflow หลายขั้นตอน, แตกแขนง, ทำงานนาน
Google ADK	การจัดระบบ multi-agent ใน ecosystem ของ Google	integration กับ Gemini และ Vertex AI
OpenAI Agents SDK	integration กับ OpenAI แน่น และรองรับ handoff	stack ที่เน้น OpenAI และต้องการเริ่มเร็ว

จุดเด่นของ PydanticAI คือ validation layer ถ้าเอเจนต์ของคุณส่งข้อมูลเข้า service อื่น การรับประกันว่า output ตรงกับ Pydantic model จะช่วยลด runtime error ได้มาก

ในทางกลับกัน LangGraph เหมาะกว่าเมื่อคุณต้องการ state machine หรือ workflow ที่มีหลาย branch ส่วน OpenAI Agents SDK เหมาะเมื่อระบบของคุณผูกกับ OpenAI เป็นหลัก และต้องการฟีเจอร์เช่น agent handoff หรือ MCP server support

คุณยังสามารถใช้ร่วมกันได้ เช่น ใช้ LangGraph จัด orchestration ระดับ workflow และใช้ PydanticAI เป็นเลเยอร์ที่รับผิดชอบ typed output ภายในบาง node

ควรใช้ PydanticAI เมื่อใด

เลือก PydanticAI เมื่อ:

เอาต์พุตของเอเจนต์ต้องเข้าโค้ดจริง ไม่ใช่แค่แสดงใน chat UI
รูปแบบข้อมูลต้องถูกต้อง เช่นต้องมี field ครบและ type ถูก
คุณใช้ Pydantic หรือ FastAPI อยู่แล้ว
คุณต้องการให้ IDE และ type checker เข้าใจ flow ของเอเจนต์
คุณต้องการสลับ provider ได้โดยไม่ rewrite agent ใหม่
คุณต้องการ observability เช่น tracing และ debugging ผ่าน Logfire

พิจารณาเฟรมเวิร์กอื่นเมื่อ:

workflow มี branch ซับซ้อนมาก
ต้องเก็บ state ระยะยาวหลายขั้นตอน
ต้องการ explicit graph orchestration
ระบบผูกกับ provider เฉพาะและต้องใช้ feature เฉพาะของ provider นั้น

ตัวอย่าง implementation: สร้างเอเจนต์จัดหมวดหมู่ ticket

ตัวอย่างนี้เหมาะกับ use case ที่พบบ่อย: รับข้อความจากลูกค้า แล้วแปลงเป็น structured ticket

from typing import Literal
from pydantic import BaseModel, Field
from pydantic_ai import Agent

class TicketClassification(BaseModel):
    category: Literal['billing', 'technical', 'account', 'other']
    priority: Literal['low', 'medium', 'high']
    summary: str = Field(max_length=200)

agent = Agent(
    'openai:gpt-4o',
    output_type=TicketClassification,
    instructions=(
        'Classify customer support messages. '
        'Return a concise summary and choose the best category and priority.'
    ),
)

result = agent.run_sync(
    'I was charged twice this month and need a refund immediately.'
)

ticket = result.output

print(ticket.category)  # billing
print(ticket.priority)  # high
print(ticket.summary)

จากนั้นคุณสามารถส่ง object นี้เข้า service ภายในได้โดยตรง:

def create_ticket(ticket: TicketClassification) -> None:
    # ticket ผ่าน validation แล้ว
    ...

ตัวอย่าง implementation: Agent ที่เรียก REST API ผ่าน tool

สมมติคุณมี order API และต้องการให้เอเจนต์ตอบสถานะคำสั่งซื้อ:

from dataclasses import dataclass
import httpx
from pydantic_ai import Agent, RunContext

@dataclass
class Deps:
    client: httpx.AsyncClient
    api_base_url: str
    token: str

agent = Agent(
    'openai:gpt-4o',
    deps_type=Deps,
    instructions='Help users check order status.',
)

@agent.tool
async def get_order_status(
    ctx: RunContext[Deps],
    order_id: str,
) -> str:
    """Return order status by order ID."""
    response = await ctx.deps.client.get(
        f'{ctx.deps.api_base_url}/orders/{order_id}',
        headers={'Authorization': f'Bearer {ctx.deps.token}'},
    )
    response.raise_for_status()

    data = response.json()
    return data['status']

รันเอเจนต์:

import asyncio
import httpx

async def main():
    async with httpx.AsyncClient() as client:
        deps = Deps(
            client=client,
            api_base_url='https://api.example.com',
            token='secret',
        )

        result = await agent.run(
            'What is the status of order ORD-123?',
            deps=deps,
        )

        print(result.output)

asyncio.run(main())

จุดสำคัญคือ order_id ถูก validate ก่อน tool ทำงาน และ dependency ถูกส่งเข้า tool อย่างชัดเจนผ่าน RunContext

การทดสอบและ mock API ที่อยู่เบื้องหลังเอเจนต์

เอเจนต์ PydanticAI จะน่าเชื่อถือได้ก็ต่อเมื่อ API ที่มันเรียกใช้มีความน่าเชื่อถือด้วย การเรียกหนึ่งครั้งอาจแตะทั้ง LLM provider และ REST endpoint ภายในหรือ third-party API หลายตัว จุดเหล่านี้คือแหล่งของ flaky behavior, cost ที่คาดไม่ถึง และ response schema ที่ไม่ตรงกัน

PydanticAI ตรวจสอบ output จากโมเดลได้ แต่ไม่ได้ตรวจสอบแทนคุณว่า upstream API ที่ tool เรียกใช้นั้นส่ง response ตรงตามที่โค้ดคาดหวังหรือไม่

นี่คือจุดที่ Apidog ช่วยได้ Apidog ไม่ได้สร้างหรือ orchestrate เอเจนต์ แต่เป็นแพลตฟอร์ม API สำหรับทดสอบและ mock endpoint ที่เอเจนต์ของคุณพึ่งพา

แนวทางใช้งานจริง:

Mock LLM หรือ tool endpoint ระหว่างพัฒนา

ชี้ tool ไปยัง mock API ที่คืน response คงที่ เพื่อลดการใช้ token และหลีกเลี่ยง rate limit ระหว่างปรับ logic
ตรวจ response schema ก่อนผูกกับ @agent.tool

ใช้ API assertions ตรวจว่า endpoint จริงส่ง field และ type ตรงกับที่ tool คาดไว้
แยก environment สำหรับ local, staging และ CI

เก็บ base URL, token และ provider key ใน environment แยกกัน เพื่อลด hard-coded config ในโค้ด
ทดสอบ LLM endpoint โดยตรง

ถ้าคุณเรียก provider ผ่าน HTTP สามารถ ทดสอบ ChatGPT API ด้วย Apidog เพื่อตรวจ authentication, streaming และรูปแบบ tool call ก่อนนำไปใช้ใน agent

ตัวอย่าง workflow ที่แนะนำ:

สร้าง API spec หรือ endpoint ใน Apidog
สร้าง mock response สำหรับ tool endpoint
ชี้ PydanticAI tool ไปยัง mock base URL ระหว่างพัฒนา
เขียน assertion ตรวจ response schema
เปลี่ยนเป็น staging หรือ production URL เมื่อพร้อม

หากต้องการลองใช้งาน ให้ ดาวน์โหลด Apidog แล้วเริ่มจาก mock endpoint หนึ่งตัวที่ agent ของคุณต้องเรียกใช้

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

PydanticAI ฟรีและเป็นโอเพนซอร์สหรือไม่?

ใช่ PydanticAI เป็นโอเพนซอร์สและติดตั้งจาก PyPI ได้ด้วย:

pip install pydantic-ai

หรือ:

uv add pydantic-ai

อย่างไรก็ตาม คุณยังต้องจ่ายค่าบริการ LLM provider ที่คุณใช้ เพราะเฟรมเวิร์กจะเรียก API เหล่านั้นแทนคุณ ระหว่างพัฒนา คุณสามารถลดค่าใช้จ่ายด้วยการ mock API response แทนการเรียกโมเดลจริงทุกครั้ง

PydanticAI ทำงานร่วมกับโมเดลใดได้บ้าง?

PydanticAI ไม่ผูกกับผู้ให้บริการรายเดียว เอกสารระบุการรองรับ OpenAI, Anthropic, Gemini, DeepSeek, Grok, Cohere, Mistral และ Perplexity รวมถึง Azure AI Foundry, Amazon Bedrock และโมเดลที่โฮสต์เอง

คุณเลือกโมเดลด้วย string เช่น:

Agent('anthropic:claude-sonnet-4-6')
Agent('openai:gpt-4o')

การสลับ provider มักเป็นการเปลี่ยนเพียงบรรทัดเดียว

PydanticAI ต่างจาก LangChain หรือ LangGraph อย่างไร?

PydanticAI โฟกัส type safety: structured output ที่ validate แล้ว และ tool arguments ที่ validate จาก type hints และ Pydantic model

LangGraph โฟกัส graph-based orchestration และ stateful workflow สำหรับงานหลายขั้นตอนที่มี branch ชัดเจน

ถ้าปัญหาหลักของคุณคือ “ต้องมั่นใจว่าเอาต์พุตตรง schema” ให้เริ่มจาก PydanticAI แต่ถ้าปัญหาหลักคือ “ต้องควบคุม state machine หลาย node” เฟรมเวิร์กแบบ graph อาจเหมาะกว่า

จำเป็นต้องรู้ Pydantic ก่อนใช้ PydanticAI หรือไม่?

ไม่จำเป็น แต่ช่วยมาก พื้นฐานที่ต้องรู้คือการประกาศ data model ด้วย BaseModel:

from pydantic import BaseModel

class User(BaseModel):
    id: int
    email: str

จากนั้น PydanticAI จะใช้ model เหล่านี้เป็น schema สำหรับ output และ validation ถ้าคุณเคยใช้ FastAPI หรือ Python สำหรับการทดสอบ API มาก่อน แนวคิดจะคุ้นเคยมาก

บทสรุป

PydanticAI ทำให้การสร้างเอเจนต์ Python ใช้งานจริงได้ปลอดภัยขึ้น โดยให้คุณประกาศ schema ของเอาต์พุตและ tool arguments แล้วปล่อยให้เฟรมเวิร์ก validate และ retry อัตโนมัติ เหมาะกับงาน production ที่ผลลัพธ์จาก LLM ต้องไหลเข้าโค้ดจริงและต้องเชื่อถือรูปแบบข้อมูลได้

ไม่ว่าคุณจะเลือกเฟรมเวิร์กใด API ที่อยู่เบื้องหลังเอเจนต์ยังต้องถูกทดสอบเสมอ ใช้ Apidog เพื่อ mock LLM หรือ tool endpoint, ตรวจ response schema และจัดการ environment แยกตาม local, staging และ CI เพื่อให้เอเจนต์ทำงานบน API surface ที่คุณตรวจสอบแล้ว

APIDOG อัปเดตเดือนมิถุนายน: เวิร์กโฟลว์ CLI พลัง AI, นำเข้าราบรื่นยิ่งขึ้น และรีเฟรช OAuth 2.0 อัตโนมัติ

Thanawat Wongchai — Fri, 26 Jun 2026 06:25:07 +0000

การอัปเดตเดือนมิถุนายนของ Apidog ช่วยให้เวิร์กโฟลว์ API ในชีวิตประจำวันทำงานอัตโนมัติได้ง่ายขึ้นและเสถียรขึ้น ตั้งแต่ CLI ที่พร้อมใช้กับ AI, การนำเข้าข้อมูลที่สะอาดขึ้น, OAuth 2.0 ที่รีเฟรชโทเค็นอัตโนมัติ ไปจนถึงการปรับปรุงงานทดสอบและการตั้งค่าที่ทีม API ใช้บ่อย

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

เป้าหมายของรอบนี้คือการลดงานซ้ำ ๆ ในทีม API: ให้เอเจนต์ AI ทำงานกับทรัพยากรโปรเจกต์จริงได้เป็นระบบมากขึ้น, ลดการแก้ไขหลังนำเข้า, ทำให้คำขอที่ใช้ OAuth ทำงานต่อเนื่อง และทำให้การตั้งค่าทดสอบ/มอนิเตอร์ทำได้เร็วขึ้น

การอัปเดตใหม่

Apidog CLI รองรับเวิร์กโฟลว์ API ที่ขับเคลื่อนด้วย AI

Apidog CLI กำลังถูกพัฒนาให้เป็นชั้นการทำงานสำหรับเวิร์กโฟลว์ API ที่ใช้ AI โดยแทนที่จะให้ผู้ใช้จำคำสั่งทั้งหมดเอง เอเจนต์ AI สามารถใช้ CLI เพื่อทำงานกับทรัพยากร Apidog จริงได้อย่างมีขอบเขตและตรวจสอบได้

สิ่งที่ทำได้ดีขึ้นในรอบนี้:

ใช้ CLI เป็นชั้นการทำงานสำหรับเอเจนต์ AI ที่ต้องอ่าน/เขียนทรัพยากรในโปรเจกต์ Apidog
รองรับการรันกรณีทดสอบ
กรณีสถานการณ์สามารถอ้างอิงเอนด์พอยต์, กรณีทดสอบ และสถานการณ์อื่นได้
การส่งออกทั้งรูปแบบเนทีฟและ OpenAPI รองรับการควบคุมขอบเขตที่ละเอียดขึ้น

แนวทางใช้งานที่เหมาะกับทีมพัฒนา:

ให้ AI ช่วยตรวจหรือสร้างการเปลี่ยนแปลงจากบริบทของโปรเจกต์
ใช้ CLI ตรวจสอบหรือรันกรณีทดสอบก่อนบันทึกกลับ
ส่งออกเฉพาะขอบเขตที่ต้องการ เช่น บางโมดูลหรือบางกลุ่ม API
ลดการคาดเดาของ AI ด้วยทรัพยากรที่มีโครงสร้างจาก Apidog

คิดว่า CLI เป็นสะพานระหว่างคำสั่งภาษามนุษย์ของ AI กับการทำงานที่เป็นระบบในโปรเจกต์ Apidog

เมื่อใช้ร่วมกับ Apidog Skills เอเจนต์ AI จะมีคำแนะนำและขอบเขตการทำงานที่ปลอดภัยขึ้น เช่น เข้าใจวิธีใช้ทรัพยากร Apidog, ตรวจสอบการเปลี่ยนแปลงก่อนบันทึก และทำงาน API ให้สำเร็จโดยต้องเดาน้อยลง

การปรับปรุงการนำเข้าและส่งออก

รอบนี้ปรับปรุงเวิร์กโฟลว์นำเข้า/ส่งออก โดยเฉพาะทีมที่ย้ายข้อมูลจาก Postman หรือดูแลข้อกำหนด API ผ่าน OpenAPI/Swagger

สิ่งที่เปลี่ยน:

เมื่อนำเข้าผ่าน Postman API, Apidog สามารถลบช่องว่างออกจากชื่อตัวแปรได้
เมื่อนำเข้าเวิร์กสเปซผ่าน Postman API, Apidog สามารถเปลี่ยนชื่อ My Workspace ให้ชัดเจนขึ้นโดยอิงจากผู้สร้างเวิร์กสเปซ
การนำเข้า/ส่งออก OpenAPI และ Swagger รองรับพารามิเตอร์ประเภทอ็อบเจกต์และพารามิเตอร์ประเภทการอ้างอิง

ตัวอย่างปัญหาที่ลดลงหลังนำเข้า:

ก่อนหน้า	ตอนนี้
ตัวแปรที่นำเข้าอาจต้องแก้ชื่อด้วยตนเอง	การนำเข้า Postman API สามารถลบช่องว่างออกจากชื่อตัวแปรได้
เวิร์กสเปซหลายรายการอาจใช้ชื่อที่สับสน เช่น `My Workspace`	ชื่อเวิร์กสเปซที่ไม่ชัดเจนสามารถเปลี่ยนให้ระบุได้ง่ายขึ้น
พารามิเตอร์ OpenAPI ที่ซับซ้อนอาจต้องปรับหลังนำเข้า/ส่งออก	OpenAPI/Swagger รองรับพารามิเตอร์ประเภทอ็อบเจกต์และการอ้างอิงมากขึ้น

แนวทางแนะนำหลังย้ายข้อมูล:

ตรวจสอบชื่อตัวแปร environment/collection หลังนำเข้า
จัดกลุ่มเวิร์กสเปซที่นำเข้าตามผู้สร้างหรือทีมที่เกี่ยวข้อง
ตรวจสอบ OpenAPI schema ที่มี object/reference parameter เพื่อยืนยันว่าโครงสร้างยังถูกต้อง
รันคำขอหรือกรณีทดสอบหลักเพื่อเช็กว่า endpoint ยังทำงานตามคาด

OAuth 2.0 รองรับการรีเฟรชโทเค็นอัตโนมัติ

OAuth 2.0 ใน Apidog รองรับการรีเฟรชโทเค็นอัตโนมัติแล้ว

เมื่อ access token ใกล้หมดอายุหรือหมดอายุไปแล้ว Apidog สามารถรีเฟรชโทเค็นให้โดยอัตโนมัติ ทำให้คุณส่งคำขอต่อได้โดยไม่ต้องยืนยันตัวตนใหม่หรือคัดลอกโทเค็นด้วยตนเอง

เหมาะกับงานเหล่านี้:

ดีบัก API ที่ป้องกันด้วย OAuth
รันคำขอซ้ำระหว่างพัฒนา
ตรวจสอบชุด API ที่ต้องใช้ session ต่อเนื่อง
ทดสอบ flow ที่ใช้ token ระยะสั้น

ฟีเจอร์นี้ช่วยลดการหยุดชะงักระหว่างดีบัก API, ทดสอบ และตรวจสอบคำขอซ้ำ ๆ

การปรับปรุงตามคำแนะนำของผู้ใช้

ความเข้ากันได้กับ MCP Client ที่ดีขึ้น

Apidog ปรับปรุงความเข้ากันได้กับ MCP Client และสามารถแยกวิเคราะห์สคีมาที่ไม่ได้มาตรฐานได้เสถียรขึ้น

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

ค้นหาขั้นตอนแบบคงที่ด้วยชื่อในชุดทดสอบ

เมื่อเพิ่มขั้นตอนแบบคงที่ในชุดทดสอบ ตอนนี้สามารถค้นหาด้วยชื่อได้แล้ว

สำหรับโปรเจกต์ที่มีเอนด์พอยต์, กรณีทดสอบ หรือสถานการณ์จำนวนมาก วิธีนี้ช่วยลดเวลาในการเลื่อนหา item ในรายการยาว ๆ

แนวทางใช้งาน:

เปิดชุดทดสอบที่ต้องการแก้ไข
เพิ่มขั้นตอนแบบคงที่
ค้นหาด้วยชื่อ endpoint/test case/scenario
เลือกรายการที่ต้องการและเพิ่มลงในชุดทดสอบ

งานที่กำหนดเวลาเพิ่มตัวเลือก “ทุก 8 ชั่วโมง”

งานที่กำหนดเวลารองรับตัวเลือก “ทุก 8 ชั่วโมง” แล้ว

เหมาะสำหรับ:

รัน automated test เป็นรอบ ๆ
ตรวจสอบ API health ระหว่างวัน
ทำ monitoring แบบ periodic
ตรวจ regression ในช่วงเวลาที่ถี่กว่า daily แต่ไม่ถี่เกินไป

ตัวอย่างรอบการรันที่พบได้บ่อย:

Use case	รอบที่เหมาะสม
Smoke test ระหว่างวัน	ทุก 8 ชั่วโมง
Health check รายวัน	ทุก 24 ชั่วโมง
Regression test หลัก	ตามรอบ release หรือ CI schedule

Apidog Web App รองรับการกำหนดค่าส่วนหัวที่สร้างขึ้นโดยอัตโนมัติ

Apidog Web App รองรับการกำหนดค่าส่วนหัวที่สร้างขึ้นโดยอัตโนมัติแล้ว

สิ่งนี้ช่วยให้ผู้ใช้ Web App ควบคุม request behavior ได้มากขึ้น โดยเฉพาะโปรเจกต์ที่มีข้อกำหนดเฉพาะเกี่ยวกับ header เช่น header มาตรฐานของทีม, header สำหรับ routing, header สำหรับ environment หรือ header ที่ต้องสอดคล้องกับ gateway/proxy

การแก้ไขข้อผิดพลาดและการปรับปรุงเล็กน้อย

รายการแก้ไขและปรับปรุงในเดือนนี้ประกอบด้วย:

ปรับปรุงประสิทธิภาพเมื่อเลือกสถานการณ์ทดสอบขนาดใหญ่ไปยังสาขาย่อย ลดโอกาสเกิด timeout
รายการสาขา Sprint และสาขาทั่วไปรองรับการแสดงรหัสสาขาและคัดลอกรหัส
แสดงข้อความแจ้งเตือนที่เป็นมิตรขึ้นเมื่อ macOS ไม่สามารถส่งคำขออินทราเน็ตได้
แก้ปัญหา Base URL ของบริการไม่ถูกนำเข้า และเอนด์พอยต์ไม่ถูกผูกกับบริการที่ระบุเมื่อนำเข้าข้อมูล Apidog ซ้ำไปยังโมดูลใหม่
แก้ปัญหา OAuth 1.0 ที่ตั้งค่าให้เพิ่มใน request header แต่ไม่ได้ถูกเพิ่มจริง
แก้ปัญหาโค้ดคำขอเอนด์พอยต์ที่สร้างขึ้นทำงานไม่ถูกต้องเมื่อ Basic Auth ใช้ตัวแปรภาษาจีน
แก้ปัญหาโค้ดคำขอที่สร้างขึ้นใช้ HTTPS ไม่ถูกต้องเมื่อเอนด์พอยต์ใช้ HTTP
แก้ปัญหาการรันสถานการณ์ CLI อาจรายงาน Unexpected token เมื่อขั้นตอนสถานการณ์อ้างอิง response body ในรูปแบบ raw
แก้ปัญหารายละเอียดรายงานการทดสอบยังแสดงว่ากำลังทำงาน หลังจากสถานการณ์ทดสอบอัตโนมัติถูกยกเลิกผิดปกติ
แก้ปัญหารายงานที่เกี่ยวข้องไม่แสดงในรายการรายงานการทดสอบหลังจากรันกรณีสถานการณ์ในโฟลเดอร์หลัก
แก้ปัญหาเมื่อรีเฟรช Apidog Web App แล้วโปรเจกต์กลับไปที่สาขาหลักโดยอัตโนมัติ
แก้ปัญหาตัวเลือกตัวกรองแท็กไม่มีเนื้อหาระหว่างการนำเข้าสาขาและเมื่อแทรกเอนด์พอยต์ใน Markdown
แก้ปัญหาบริการที่ไม่ใช่ค่าเริ่มต้นถูกเพิ่มซ้ำเมื่อนำเข้าไฟล์ Apidog ที่มีหลายโมดูลและบริการ
แก้ปัญหาแท็กเอกสาร Markdown ไม่ถูกนำเข้าอย่างถูกต้องเมื่อนำเข้าข้อมูล Apidog
แก้ปัญหายังคงแสดง conflict หลังจากรวมเอนด์พอยต์เข้ากับสาขาหลักในบางกรณี
แก้ปัญหา frontend error ในบางกรณีเมื่อดีบักเอนด์พอยต์ SSE
แก้ปัญหาสถิติโปรเจกต์ On-Premises นับเฉพาะข้อมูลจากโมดูลเริ่มต้น
แก้ปัญหาการนำเข้าไฟล์ Apidog แบบหลายโมดูลจากหน้ารายละเอียดทีมนำเข้าเอนด์พอยต์ไปยังโมดูลเริ่มต้นผิด
แก้ปัญหาการเปลี่ยนแปลงหายไปในบางกรณีหลังจากส่งการแก้ไข
แก้ปัญหาแสดงข้อความข้อผิดพลาดไม่ถูกต้องในขั้นตอนยืนยันอีเมลเมื่อเปลี่ยนรหัสผ่าน

ความหมายของการอัปเดตเหล่านี้

การอัปเดตชุดนี้ทำให้ Apidog ใช้งานได้ดีขึ้นในเวิร์กโฟลว์ที่มีทั้งนักพัฒนา, เอเจนต์ AI, ข้อกำหนด API และการทดสอบอัตโนมัติ

ส่วนที่เกี่ยวข้อง	สิ่งที่ปรับปรุง	ทำไมจึงสำคัญ
เวิร์กโฟลว์ CLI ที่ขับเคลื่อนด้วย AI	CLI ช่วยให้เอเจนต์ AI ทำงานกับทรัพยากรโปรเจกต์ Apidog, รันกรณีทดสอบ, อ้างอิงทรัพย์สินที่มีอยู่ และควบคุมการส่งออกได้ละเอียดขึ้น	เอเจนต์ AI ทำงาน API ได้จากบริบทโปรเจกต์ที่เป็นระบบ แทนที่จะเดาจากข้อมูลที่ไม่มีโครงสร้าง
การนำเข้าและส่งออก	Postman API import ล้างชื่อตัวแปรและทำให้ชื่อเวิร์กสเปซชัดขึ้น; OpenAPI/Swagger รองรับพารามิเตอร์ object/reference	ลดงานแก้หลังย้ายข้อมูล และรักษา API spec ที่ซับซ้อนได้ดีขึ้น
การยืนยันตัวตน	OAuth 2.0 refresh token ได้อัตโนมัติ	ลดการหยุดชะงักระหว่างดีบักและทดสอบ API
ความเข้ากันได้กับ MCP	MCP Client แยกวิเคราะห์สคีมาที่ไม่ได้มาตรฐานได้มากขึ้น	ทำงานกับเครื่องมือและเซิร์ฟเวอร์ MCP ในโลกจริงได้เสถียรขึ้น
เวิร์กโฟลว์การทดสอบ	ค้นหาขั้นตอนแบบคงที่ได้ง่ายขึ้น และ scheduled job รองรับทุก 8 ชั่วโมง	ตั้งค่าชุดทดสอบเร็วขึ้นและยืดหยุ่นขึ้นสำหรับการรันซ้ำ
การกำหนดค่า Web App	กำหนดค่าส่วนหัวที่สร้างอัตโนมัติได้ใน Apidog Web App	ควบคุม request behavior ได้ดีขึ้นในเวิร์กโฟลว์บนเบราว์เซอร์

สรุปคือทีมจะได้ flow ที่สะอาดขึ้น: AI มีบริบทโปรเจกต์ดีขึ้น, ข้อมูลนำเข้าต้องแก้น้อยลง, คำขอ OAuth ถูกขัดจังหวะน้อยลง และทีมควบคุมการทดสอบซ้ำกับการตั้งค่า request ได้มากขึ้น

เข้าร่วมการสนทนา

เชื่อมต่อกับวิศวกร API คนอื่น ๆ และทีม Apidog:

เข้าร่วมชุมชน Discord ของเราสำหรับการสนทนาและการสนับสนุนแบบเรียลไทม์
เข้าร่วมชุมชน Slack ของเราสำหรับการสนทนาทางเทคนิค
ติดตามเราบน X (Twitter) เพื่อรับการอัปเดตล่าสุด

ป.ล. สำหรับรายละเอียดทั้งหมดเกี่ยวกับการอัปเดตทั้งหมด โปรดดู Apidog Changelog

ขอแสดงความนับถือ,

ทีมงาน Apidog

เกิดอะไรขึ้นกับ GPT-5.6?

Thanawat Wongchai — Fri, 26 Jun 2026 05:31:30 +0000

รุ่นเรือธงถัดไปของ OpenAI, GPT-5.6, จะไม่ได้เปิดตัวแบบปกติตามรายงานวันที่ 25 มิถุนายน 2026 รัฐบาลสหรัฐฯ ขอให้ OpenAI ชะลอการเปิดตัวสู่สาธารณะ และให้เปิดใช้งานกับพันธมิตรที่ผ่านการคัดเลือกจำนวนน้อยก่อน กรณีนี้คล้ายกับเหตุการณ์ที่ Anthropic ต้องถอน โมเดล Fable 5 และ Mythos 5 ออกจากระบบภายใต้คำสั่งของรัฐบาลเมื่อไม่ถึงสองสัปดาห์ก่อน สำหรับทีมที่สร้างผลิตภัณฑ์บน AI API ประเด็นสำคัญไม่ใช่แค่ข่าวอุตสาหกรรม แต่คือความเสี่ยงด้านสถาปัตยกรรม: โมเดลที่คุณเรียกใช้วันนี้อาจถูกจำกัด ชะลอ หรือปิดใช้งานได้โดยมีเวลาเตือนน้อยมาก

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

เกิดอะไรขึ้นกับ GPT-5.6

รายละเอียดต่อไปนี้เป็น “รายงาน” ไม่ใช่การยืนยันอย่างเป็นทางการ เพราะทั้ง OpenAI และทำเนียบขาวยังไม่ได้ออกความเห็นต่อสาธารณะ

ผู้ร้องขอ: รัฐบาลทรัมป์ โดยเฉพาะสำนักงานผู้อำนวยการด้านไซเบอร์แห่งชาติและสำนักงานนโยบายวิทยาศาสตร์และเทคโนโลยี มีรายงานครั้งแรกโดย The Information และถูกรายงานต่อโดย Axios และ SiliconANGLE
รูปแบบการชะลอ: GPT-5.6 จะไม่เปิดสู่สาธารณะทันที แต่จะเปิดให้พันธมิตรกลุ่มเล็กก่อน มีรายงานว่ารัฐบาลต้องอนุมัติเป็นรายลูกค้าในช่วงพรีวิวนี้
เหตุผล: ความมั่นคงของชาติ โดยเฉพาะความกังวลว่าโมเดลที่ช่วยค้นหาช่องโหว่ซอฟต์แวร์หรือเจาะระบบได้ดีขึ้น อาจถูกใช้งานโดยฝ่ายตรงข้ามก่อนที่มาตรการป้องกันจะผ่านการพิสูจน์
ไทม์ไลน์: หน้าต่างการเปิดตัวเดือนมิถุนายนถูกเลื่อนออกไป และตอนนี้การเปิดตัวในวงกว้างดูมีแนวโน้มอยู่ในเดือนกรกฎาคม 2026 มากกว่า

สรุป: GPT-5.6 ดูเหมือนใกล้เปิดตัว แต่ถูกจัดการเหมือนการปล่อยใช้งานแบบควบคุม ไม่ใช่การเปิดตัวผลิตภัณฑ์ทั่วไป รุ่นเรือธงที่ใช้งานใน Public API ยังเป็น GPT-5.5

แบบอย่างจาก Fable 5 และ Mythos 5

กรณี GPT-5.6 ไม่ได้เกิดขึ้นเดี่ยว ๆ เมื่อวันที่ 12 มิถุนายน 2026 Anthropic ได้รับคำสั่งจากรัฐบาลให้ปิดใช้งานโมเดล Fable 5 และ Mythos 5 ที่เพิ่งประกาศไป

ตามรายงานของ CNBC, Fortune และ แถลงการณ์ของ Anthropic:

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

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

ทำไมเรื่องนี้สำคัญกับนักพัฒนา API

ถ้าผลิตภัณฑ์ของคุณเรียกใช้โมเดลแนวหน้าผ่าน API เหตุการณ์เหล่านี้คือ operational risk โดยตรง

ตัวอย่างสถานการณ์:

คุณ deploy ฟีเจอร์ที่พึ่งพาโมเดลเดียว
โมเดลนั้นถูกจำกัดหรือปิดใช้งานโดยคำสั่งภายนอก
retry logic ไม่ช่วย เพราะปัญหาไม่ใช่ transient error
ทีมไม่สามารถเปลี่ยน provider ได้ทันที เพราะโค้ดผูกกับ request/response format ของ vendor เดียว
ฟีเจอร์หยุดทำงานจนกว่าจะหาโมเดลสำรองและทดสอบใหม่

บทเรียนไม่ใช่ “อย่าใช้โมเดลแนวหน้า” แต่คือ “อย่าผูกแอปกับโมเดลเดียวที่คุณควบคุมไม่ได้”

ออกแบบแอปให้เปลี่ยนโมเดลได้

วิธีที่ปลอดภัยกว่าคือวางโมเดลไว้หลัง abstraction layer ภายในของคุณเอง ให้แอปเรียก interface เดียว แล้วค่อย route ไปยัง OpenAI, Anthropic, Google หรือโมเดลอื่นตาม config

ตัวอย่างแนวคิดแบบ TypeScript:

type ChatMessage = {
  role: "system" | "user" | "assistant";
  content: string;
};

type ChatResult = {
  text: string;
  provider: string;
  model: string;
};

interface LLMProvider {
  chat(messages: ChatMessage[]): Promise<ChatResult>;
}

จากนั้นสร้าง provider implementation แยกกัน:

class OpenAIProvider implements LLMProvider {
  constructor(private apiKey: string, private model: string) {}

  async chat(messages: ChatMessage[]): Promise<ChatResult> {
    const res = await fetch("https://api.openai.com/v1/chat/completions", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${this.apiKey}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        model: this.model,
        messages,
      }),
    });

    if (!res.ok) {
      throw new Error(`OpenAI error: ${res.status}`);
    }

    const data = await res.json();

    return {
      text: data.choices?.[0]?.message?.content ?? "",
      provider: "openai",
      model: this.model,
    };
  }
}

แล้วเลือก provider จาก environment variable:

function createLLMProvider(): LLMProvider {
  const provider = process.env.LLM_PROVIDER;

  if (provider === "openai") {
    return new OpenAIProvider(
      process.env.OPENAI_API_KEY!,
      process.env.OPENAI_MODEL ?? "gpt-5.5"
    );
  }

  throw new Error(`Unsupported provider: ${provider}`);
}

เมื่อมี provider สำรอง คุณควรเปลี่ยนการตั้งค่าได้โดยไม่ต้องแก้ business logic:

LLM_PROVIDER=openai
OPENAI_MODEL=gpt-5.5

ถ้าต้อง failover ไป provider อื่น ให้เพิ่ม implementation ใหม่ แต่ให้ interface ภายในเหมือนเดิม

ใช้ fallback แบบมีเงื่อนไข ไม่ใช่ retry อย่างเดียว

การ retry เหมาะกับ timeout หรือ 5xx ชั่วคราว แต่ไม่ช่วยกับกรณีโมเดลถูกจำกัดหรือถอนออก คุณควรแยก error ที่ควร retry ออกจาก error ที่ควร fallback

ตัวอย่าง pattern:

async function runWithFallback(
  primary: LLMProvider,
  fallback: LLMProvider,
  messages: ChatMessage[]
): Promise<ChatResult> {
  try {
    return await primary.chat(messages);
  } catch (err) {
    console.error("Primary model failed, switching to fallback", err);
    return fallback.chat(messages);
  }
}

ใน production ให้เพิ่มเงื่อนไขละเอียดขึ้น เช่น:

fallback เมื่อได้ 403, 404, 429, หรือ error ที่ระบุว่า model unavailable
retry เมื่อเป็น network timeout หรือ 5xx
log provider/model ที่ถูกใช้จริงทุกครั้ง
alert เมื่อ fallback ถูกใช้งานเกิน threshold

ทดสอบโมเดลสำรองก่อนเกิดเหตุ

อย่ารอให้โมเดลหลักหยุดทำงานแล้วค่อยเริ่มทดสอบโมเดลสำรอง ให้สร้าง test suite เดียวที่ใช้กับทุก provider

สิ่งที่ควรตรวจ:

response มี field ที่แอปต้องใช้ครบหรือไม่
output อยู่ใน format ที่ parser ของคุณรับได้หรือไม่
latency อยู่ในช่วงที่ยอมรับได้หรือไม่
คำตอบผ่าน business rules ขั้นต่ำหรือไม่
error handling ทำงานตามที่ออกแบบหรือไม่

ตัวอย่าง assertion ระดับ API:

{
  "text": "string",
  "provider": "string",
  "model": "string"
}

คุณสามารถใช้เครื่องมือ API เช่น Apidog เพื่อจัดการ request, environment, assertion และชุดทดสอบซ้ำกับหลาย endpoint ได้

แนวทางที่เกี่ยวข้อง:

จำลอง Model API เพื่อไม่ให้ทีมพัฒนาหยุดทำงาน

ถ้า endpoint จริงถูกจำกัดหรือ rate limit ทีม frontend, QA และ CI ไม่ควรถูกบล็อกทั้งหมด วิธีปฏิบัติที่ดีคือสร้าง mock API ที่คืน response รูปแบบเดียวกับโมเดลจริง

ตัวอย่าง mock response:

{
  "text": "นี่คือตัวอย่างคำตอบจากโมเดลจำลอง",
  "provider": "mock",
  "model": "mock-llm"
}

จากนั้นให้แอปเปลี่ยน base URL ได้ผ่าน config:

LLM_BASE_URL=https://mock-api.example.com

เมื่อ endpoint จริงกลับมา ให้เปลี่ยนกลับ:

LLM_BASE_URL=https://api.vendor.example.com

Mock API ช่วยให้:

frontend พัฒนาต่อได้
test pipeline ไม่ล้มเพราะ external dependency
QA ทดสอบ edge case ได้ซ้ำ
ทีมไม่ต้องรอสิทธิ์เข้าถึงโมเดลจริง

ดูเพิ่มเติม: Mock API

ติดตามต้นทุนและ latency ต่อโมเดล

เมื่อ failover ไป provider อื่น ค่าใช้จ่ายและ latency อาจเปลี่ยนทันที ดังนั้นอย่า track usage แค่ระดับระบบรวม ให้เก็บอย่างน้อย:

provider
model
feature
token/input size
latency
error rate
cost estimate

ตัวอย่าง log:

{
  "feature": "support-assistant",
  "provider": "openai",
  "model": "gpt-5.5",
  "latency_ms": 1420,
  "status": "success",
  "fallback_used": false
}

เมื่อ fallback ถูกใช้งาน:

{
  "feature": "support-assistant",
  "provider": "fallback-provider",
  "model": "fallback-model",
  "latency_ms": 2310,
  "status": "success",
  "fallback_used": true
}

อ่านเพิ่มเติม: ติดตามค่าใช้จ่าย API ต่อฟีเจอร์

Checklist สำหรับทีมที่ใช้ AI API

ใช้ checklist นี้ตรวจสถาปัตยกรรมของคุณ:

[ ] มี interface ภายในสำหรับเรียก LLM ไม่เรียก vendor SDK กระจายทั่ว codebase
[ ] เปลี่ยน provider/model ได้ผ่าน config
[ ] มี fallback provider ที่ทดสอบแล้ว
[ ] แยก retry error กับ fallback error
[ ] มี mock API สำหรับ development และ CI
[ ] มี test suite เดียวที่รันกับหลายโมเดล
[ ] มี assertion ตรวจ response shape ไม่ใช่แค่ HTTP 200
[ ] log provider/model/latency/cost ต่อ request
[ ] มี alert เมื่อ fallback ถูกใช้มากผิดปกติ
[ ] มี runbook สำหรับกรณี model unavailable

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

GPT-5.6 เปิดตัวแล้วหรือยัง?

ยัง ไม่มีการเปิดตัวสู่สาธารณะจนถึงปลายเดือนมิถุนายน 2026 รายงานระบุว่า OpenAI จะเปิดให้พันธมิตรที่ได้รับการคัดเลือกจำนวนน้อยก่อน และอาจเปิดกว้างขึ้นหลังจากนั้นหากการตรวจสอบของรัฐบาลเป็นไปด้วยดี OpenAI ยังไม่ได้ยืนยันวันที่อย่างเป็นทางการ และ Public API ยังทำงานบน GPT-5.5

ทำไมรัฐบาลถึงเข้ามาแทรกแซง GPT-5.6?

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

เกิดอะไรขึ้นกับ Fable 5 และ Mythos 5 ของ Anthropic?

เมื่อวันที่ 12 มิถุนายน 2026 Anthropic ได้รับคำสั่งควบคุมการส่งออกให้ระงับการเข้าถึงสำหรับพลเมืองต่างชาติ เนื่องจากไม่สามารถแยกผู้ใช้ต่างชาติออกจากผู้ใช้ในสหรัฐฯ ได้แบบเรียลไทม์ Anthropic จึงปิดใช้งาน Fable 5 และ Mythos 5 สำหรับทุกคน เหตุการณ์นี้กลายเป็นแบบอย่างที่รายงานเกี่ยวกับ GPT-5.6 อ้างอิงถึง

จะทำอย่างไรให้แอปยังทำงานได้หากโมเดลถูกถอนออก?

อย่าผูกแอปกับโมเดลเดียว ให้เรียกผ่าน interface ภายใน เตรียม fallback provider ทดสอบโมเดลสำรองไว้ล่วงหน้า และสร้าง mock API เพื่อให้ development/test/CI เดินต่อได้ หากเปลี่ยน provider ได้ด้วย config การถอนโมเดลจะกลายเป็น failover แทนที่จะเป็น outage หลายวัน เซิร์ฟเวอร์จำลอง Apidog และชุดทดสอบที่นำกลับมาใช้ซ้ำได้ช่วยลดความเสี่ยงนี้ได้ในระดับ implementation

สรุป

การที่ GPT-5.6 ถูกรายงานว่าถูกชะลอการเปิดตัว หลังจาก Fable 5 และ Mythos 5 ถูกถอนออกไปไม่นาน ชี้ให้เห็นรูปแบบใหม่ของการปล่อยโมเดลแนวหน้า: การเข้าถึงอาจถูกตรวจสอบ จำกัด หรือเปลี่ยนแปลงด้วยเหตุผลที่อยู่นอกการควบคุมของผู้ขาย

สำหรับนักพัฒนา การตอบสนองที่ถูกต้องคือออกแบบระบบให้ไม่พึ่งพาโมเดลเดียว:

แยก LLM ออกจาก business logic
ใช้ provider abstraction
เตรียม fallback
ทดสอบหลายโมเดลด้วยชุดเดียวกัน
ใช้ mock API เมื่อ endpoint จริงไม่พร้อม
ติดตาม cost และ latency ต่อโมเดล

คุณสามารถตั้งค่า request, assertion, mock API และชุดทดสอบซ้ำได้ใน Apidog เพื่อให้โมเดลเดียวไม่กลายเป็น single point of failure ของผลิตภัณฑ์คุณ.

วิธีใช้ OpenAI Function Calling

Thanawat Wongchai — Fri, 26 Jun 2026 05:29:31 +0000

เมื่ออ่านคู่มือนี้จบ คุณจะสามารถกำหนดเครื่องมือ ส่งไปยัง OpenAI อ่าน tool call ที่โมเดลส่งกลับมา แยกวิเคราะห์อาร์กิวเมนต์ JSON แล้วเรียกใช้ฟังก์ชันของคุณเองได้อย่างปลอดภัย จากนั้นเปิดใช้ strict mode และ parallel calls รวมถึงตรวจสอบและจำลองฝั่ง API ด้วย Apidog ก่อนนำไปใช้งานจริง แนะนำให้เปิด เอกสาร function calling ของ OpenAI ไว้อ้างอิง และดูภาพรวมเพิ่มเติมจากบทความ สร้างเอเจนต์ด้วย OpenAI Agents SDK

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

สิ่งที่คุณต้องมีก่อนเริ่มต้น

Function calling หรือ tool calling คือกลไกที่ให้โมเดลเลือก “ฟังก์ชันที่ควรเรียก” และส่งอาร์กิวเมนต์กลับมาเป็น JSON ให้แอปของคุณนำไปใช้ต่อ โมเดลไม่ได้รันโค้ดเอง หน้าที่ของโมเดลคือเลือก intent และจัดรูปแบบพารามิเตอร์ ส่วนโค้ดของคุณยังเป็นผู้ตรวจสอบและรันฟังก์ชันจริง

ตัวอย่างเช่น ผู้ใช้ถามว่า:

What is the weather in Paris right now?

โมเดลอาจส่ง tool call กลับมาเป็น:

get_weather({"location": "Paris, France"})

แทนที่คุณจะต้องแยกข้อความธรรมชาติเอง คุณจะได้ชื่อฟังก์ชันและอาร์กิวเมนต์ที่มีโครงสร้างชัดเจน

ก่อนเริ่ม คุณควรมี:

OpenAI API key
ฟังก์ชันในแอปของคุณที่ต้องการให้โมเดลเรียกได้
JSON Schema สำหรับอาร์กิวเมนต์ของฟังก์ชัน
API หรือ service ปลายทางที่ฟังก์ชันของคุณจะเรียกใช้
เครื่องมือทดสอบ เช่น Apidog สำหรับตรวจ payload และสร้าง mock API

คุณสามารถใช้ได้ทั้ง Chat Completions API และ Responses API ความสามารถคล้ายกัน แต่รูปแบบ request/response ต่างกันเล็กน้อย บทความนี้จะแสดงทั้งสองแนวทางในจุดที่จำเป็น

ขั้นตอนที่ 1: กำหนดเครื่องมือของคุณ

เครื่องมือคือคำอธิบายฟังก์ชันที่โมเดลอ่านได้ โดยประกอบด้วย:

name: ชื่อฟังก์ชัน
description: คำอธิบายว่าเมื่อใดควรใช้ฟังก์ชันนี้
parameters: JSON Schema ของอาร์กิวเมนต์

คำอธิบายสำคัญมาก เพราะโมเดลใช้ตัดสินใจว่าจะเรียกฟังก์ชันนี้หรือไม่ ให้เขียนเป็น instruction มากกว่าป้ายกำกับสั้นๆ

ตัวอย่าง tool definition สำหรับ Chat Completions:

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "Get the current weather for a city. Use when the user asks about temperature or conditions.",
    "parameters": {
      "type": "object",
      "properties": {
        "location": {
          "type": "string",
          "description": "City and country, e.g. Bogotá, Colombia"
        },
        "unit": {
          "type": "string",
          "enum": ["celsius", "fahrenheit"]
        }
      },
      "required": ["location"],
      "additionalProperties": false
    }
  }
}

ใน Responses API รูปแบบจะ flat กว่า โดย name, description, parameters และ strict อยู่ที่ระดับบนสุดของ object เครื่องมือ ไม่ต้องซ้อนใต้คีย์ function

ถ้าคุณมี OpenAPI spec อยู่แล้ว สามารถนำ schema ของ request body หรือ parameters มาใช้เป็นฐานได้เกือบโดยตรง ดูแนวทางเพิ่มเติมได้จากบทความ สร้างชุดการทดสอบจาก OpenAPI specs

ขั้นตอนที่ 2: ส่งคำขอแรกพร้อม tools

ส่งข้อความผู้ใช้พร้อมรายการเครื่องมือที่โมเดลสามารถเลือกใช้ได้ ตัวอย่าง Chat Completions request:

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4.1",
    "messages": [
      {
        "role": "user",
        "content": "What is the weather in Paris right now?"
      }
    ],
    "tools": [
      {
        "type": "function",
        "function": {
          "name": "get_weather",
          "description": "Get the current weather for a city.",
          "parameters": {
            "type": "object",
            "properties": {
              "location": {
                "type": "string"
              }
            },
            "required": ["location"],
            "additionalProperties": false
          }
        }
      }
    ]
  }'

ใน request นี้:

messages คือบริบทการสนทนา
tools คือฟังก์ชันที่คุณเปิดให้โมเดลเรียก
โมเดลจะตัดสินใจเองว่าจะตอบเป็นข้อความปกติหรือส่ง tool call กลับมา

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

ขั้นตอนที่ 3: อ่าน tool call ที่โมเดลส่งกลับมา

เมื่อโมเดลต้องการเรียกฟังก์ชัน มันจะส่ง tool call กลับมาแทนข้อความธรรมดา

ใน Chat Completions ให้ดูที่ tool_calls ของ assistant message:

{
  "id": "call_12345xyz",
  "type": "function",
  "function": {
    "name": "get_weather",
    "arguments": "{\"location\":\"Paris, France\"}"
  }
}

ใน Responses API tool call จะอยู่ใน output และมีรูปแบบ flat กว่า:

{
  "type": "function_call",
  "call_id": "call_12345xyz",
  "name": "get_weather",
  "arguments": "{\"location\":\"Paris, France\"}"
}

จุดสำคัญคือ arguments เป็น string ที่ encode JSON ไว้ ไม่ใช่ object ที่ parse แล้ว ดังนั้นต้อง parse เองทุกครั้ง

ตัวอย่าง Node.js:

const toolCall = response.choices[0].message.tool_calls[0];

const functionName = toolCall.function.name;
const args = JSON.parse(toolCall.function.arguments);

if (functionName === "get_weather") {
  const result = await getWeather(args.location, args.unit);
}

อย่าเรียกใช้ฟังก์ชันทันทีโดยไม่ตรวจสอบค่า เพราะแม้ schema จะช่วยจัดรูปแบบ แต่ business rule ยังต้องตรวจเอง เช่น เมืองนั้นอยู่ในพื้นที่ให้บริการหรือไม่

ขั้นตอนที่ 4: รันฟังก์ชันและส่งผลลัพธ์กลับไปยังโมเดล

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

ใน Chat Completions ให้เพิ่ม message ที่มี role เป็น tool และผูกกับ tool_call_id:

{
  "role": "tool",
  "tool_call_id": "call_12345xyz",
  "content": "{\"temperature\":18,\"condition\":\"Cloudy\"}"
}

ตัวอย่าง flow แบบย่อ:

const messages = [
  {
    role: "user",
    content: "What is the weather in Paris right now?"
  }
];

// 1. ส่ง request แรก
const firstResponse = await client.chat.completions.create({
  model: "gpt-4.1",
  messages,
  tools
});

// 2. อ่าน tool call
const assistantMessage = firstResponse.choices[0].message;
const toolCall = assistantMessage.tool_calls[0];
const args = JSON.parse(toolCall.function.arguments);

// 3. รันฟังก์ชันจริงของคุณ
const weather = await getWeather(args.location);

// 4. ส่งผลลัพธ์กลับไปให้โมเดล
messages.push(assistantMessage);
messages.push({
  role: "tool",
  tool_call_id: toolCall.id,
  content: JSON.stringify(weather)
});

const finalResponse = await client.chat.completions.create({
  model: "gpt-4.1",
  messages,
  tools
});

console.log(finalResponse.choices[0].message.content);

ใน Responses API แนวคิดเหมือนกัน แต่ส่งผลลัพธ์กลับด้วย item ประเภท function_call_output ที่อ้างอิง call_id

วงจรคือ:

โมเดลเลือกฟังก์ชัน
แอปของคุณ parse arguments
แอปของคุณรันฟังก์ชัน
แอปส่งผลลัพธ์กลับ
โมเดลสร้างคำตอบสุดท้าย

ขั้นตอนที่ 5: เปิด parallel calls และ strict mode

เมื่อ flow พื้นฐานทำงานแล้ว ให้ปรับสองเรื่องนี้เพื่อเพิ่มความน่าเชื่อถือและควบคุมพฤติกรรม

Parallel tool calls

โดยค่าเริ่มต้น โมเดลสามารถส่ง tool call หลายรายการใน response เดียวได้ เช่น ผู้ใช้ถามสภาพอากาศของสามเมือง โมเดลอาจส่งการเรียก get_weather สามครั้งพร้อมกัน

ถ้าฟังก์ชันเป็นอิสระต่อกัน คุณสามารถรันพร้อมกันได้:

const results = await Promise.all(
  toolCalls.map(async (call) => {
    const args = JSON.parse(call.function.arguments);
    return runTool(call.function.name, args);
  })
);

แต่ถ้าการเรียกต้องทำตามลำดับ หรือผลลัพธ์หนึ่งเป็น input ของอีกอัน ให้ตั้งค่า:

{
  "parallel_tool_calls": false
}

Strict mode

ตั้งค่า strict: true เพื่อบังคับให้อาร์กิวเมนต์ตรงกับ JSON Schema มากขึ้น แทนที่จะเป็น best effort

ตัวอย่าง schema แบบ strict:

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "Get the current weather for a city.",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "location": {
          "type": "string"
        },
        "unit": {
          "type": ["string", "null"],
          "enum": ["celsius", "fahrenheit", null]
        }
      },
      "required": ["location", "unit"],
      "additionalProperties": false
    }
  }
}

กฎสำคัญของ strict mode:

ทุก object ต้องมี additionalProperties: false
ทุก field ใน properties ต้องอยู่ใน required
ถ้าต้องการ optional field ให้ทำเป็น nullable เช่น ["string", "null"]
โมเดลอาจส่ง null แต่ไม่ควรละคีย์นั้นไป

การตั้งค่า	สิ่งที่ควบคุม	ค่าเริ่มต้น	เมื่อใดควรเปลี่ยน
`parallel_tool_calls`	อนุญาตให้มี tool call หลายรายการใน response เดียวหรือไม่	`true`	ตั้งเป็น `false` เมื่อการเรียกขึ้นต่อกันหรือต้องรันตามลำดับ
`strict`	บังคับให้อาร์กิวเมนต์ตรงกับ schema หรือไม่	best effort ถ้าไม่ตั้งค่า	ควรเปิดเมื่อคุณต้อง parse และใช้ payload ต่อโดยตรง
`tool_choice`	ควบคุมว่าโมเดลเรียก tool ได้หรือไม่ และเรียกตัวใด	`auto`	ใช้ `required` เพื่อบังคับเรียก, `none` เพื่อปิด, หรือระบุชื่อ tool เพื่อบังคับฟังก์ชันเดียว

Strict mode ช่วยลด payload ที่ผิดรูปแบบ แต่ไม่ได้รับประกัน business correctness เช่น location อาจเป็น string ที่ถูกต้องตาม schema แต่เป็นเมืองที่ระบบคุณไม่รองรับ ดังนั้นยังต้อง validate ฝั่งแอปและทดสอบปลายทางจริงหรือ mock เสมอ

วิธีทดสอบใน Apidog

ก่อนต่อ tool call เข้ากับ production flow คุณควรตรวจสองเรื่อง:

อาร์กิวเมนต์จากโมเดลตรงกับ schema ที่ฟังก์ชันคาดหวังหรือไม่
API ปลายทางที่ฟังก์ชันจะเรียกทำงานตามที่คาดหรือไม่

Apidog ช่วยตรวจและจำลองฝั่ง API ได้ แต่ไม่ได้รันฟังก์ชันในแอปของคุณเอง หน้าที่ของ Apidog คือช่วยตรวจ contract รอบๆ ฟังก์ชันเหล่านั้น

1. ตรวจโครงสร้าง arguments

นำค่า arguments จาก tool call จริงมาใช้เป็น request body แล้วตรวจใน Apidog เช่น:

{
  "location": "Paris, France",
  "unit": "celsius"
}

สิ่งที่ควร assert:

location มีอยู่จริง
location เป็น string
unit อยู่ใน enum ที่อนุญาต
ไม่มี field แปลกปลอมถ้า schema ใช้ additionalProperties: false
field ที่จำเป็นมีครบ

คุณสามารถใช้ JSONPath เพื่อดึงค่าเฉพาะจาก payload และใช้ JSON Schema validation เพื่อตรวจ schema เดียวกับที่ส่งให้ OpenAI

แนวทางที่ดีคือใช้ schema เดียวกันทั้งสามจุด:

tool definition ที่ส่งให้ OpenAI
validation ใน Apidog
validation ใน application code

2. จำลอง API ปลายทางที่ฟังก์ชันจะเรียก

สมมติฟังก์ชัน get_weather ของคุณต้องเรียก weather provider จริง ระหว่างพัฒนา provider อาจมี rate limit, มีค่าใช้จ่าย หรือยังไม่พร้อมใช้งาน

ให้สร้าง mock API ใน Apidog แล้วชี้ฟังก์ชันของคุณไปที่ mock แทน

ตัวอย่าง mock response:

{
  "location": "Paris, France",
  "temperature": 18,
  "unit": "celsius",
  "condition": "Cloudy"
}

จากนั้นทดสอบ flow ทั้งหมด:

ส่ง prompt ไปยัง OpenAI
รับ tool call
parse และ validate arguments
เรียก get_weather
ให้ get_weather เรียก Apidog mock
ส่งผลลัพธ์กลับไปยังโมเดล
ตรวจคำตอบสุดท้าย

ข้อดีคือคุณสามารถจำลอง error case ได้ เช่น:

timeout
HTTP 429
response body ผิดรูปแบบ
field บางตัวหายไป
provider ส่ง error message กลับมา

กรณีเหล่านี้มักทำซ้ำได้ยากกับ live API แต่จำเป็นต่อการทดสอบ production readiness

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

Function calling ใช้งานได้ทั้ง Chat Completions และ Responses API หรือไม่?

ได้ ทั้งสอง endpoint รองรับ function calling ความต่างหลักคือรูปแบบข้อมูล Chat Completions ซ้อนรายละเอียดไว้ใต้ function และส่งคืน tool_calls ส่วน Responses API ใช้ tool definition ที่ flat กว่า และส่งคืนรายการ function_call ใน output

ทำไม `arguments` เป็น string ไม่ใช่ object?

เพราะ API ส่ง arguments เป็น JSON-encoded string คุณต้อง parse เองเสมอ เช่น JSON.parse(...) และควร validate ผลลัพธ์ก่อนใช้จริง การตรวจด้วย JSON Schema validation ช่วยดัก payload ที่ผิดรูปแบบก่อนถึง business logic

Strict mode รับประกันว่าฟังก์ชันจะสำเร็จหรือไม่?

ไม่ Strict mode รับประกันเรื่องโครงสร้างตาม JSON Schema เท่านั้น ไม่ได้ตรวจ business rule และไม่ได้รันฟังก์ชันให้คุณ คุณยังต้องตรวจค่าด้วยตัวเอง และต้องจัดการ error จาก API ปลายทาง เช่น timeout, 404 หรือ 429

Apidog รันฟังก์ชันจริงของฉันได้หรือไม่?

ไม่ Apidog ไม่ได้รัน application function ของคุณ หน้าที่ของ Apidog คือช่วยตรวจ arguments ที่โมเดลสร้างขึ้น และจำลอง API ที่ฟังก์ชันของคุณพึ่งพา แอปของคุณยังเป็นผู้รันฟังก์ชันจริง

สรุป

Function calling คือ pattern ที่แบ่งหน้าที่ชัดเจน: โมเดลเลือกฟังก์ชันและสร้าง arguments ส่วนแอปของคุณ parse, validate, execute และส่งผลลัพธ์กลับไปให้โมเดลตอบผู้ใช้

ขั้นตอนใช้งานจริงคือ:

กำหนด tool ด้วยชื่อ คำอธิบาย และ JSON Schema
ส่ง tool พร้อมข้อความผู้ใช้ไปยัง OpenAI
อ่าน tool_calls หรือ function_call
parse arguments
validate payload
รันฟังก์ชันของคุณ
ส่งผลลัพธ์กลับไปยังโมเดล
เปิด strict และตั้งค่า parallel_tool_calls ให้เหมาะกับ flow
ใช้ Apidog ตรวจ schema และ mock API ปลายทางก่อนขึ้น production

ถ้าต้องการทดสอบด้าน API contract ให้ครบในที่เดียว ให้ ดาวน์โหลด Apidog เพื่อ validate tool call arguments กับ schema ของคุณ และจำลอง API ที่ฟังก์ชันของคุณต้องพึ่งพา

วิธีใช้งาน OpenAI API

Thanawat Wongchai — Fri, 26 Jun 2026 03:21:35 +0000

คู่มือนี้พาคุณใช้งาน OpenAI Responses API แบบลงมือทำ: ส่งคำขอไปยัง POST /v1/responses, อ่านเอาต์พุตแบบซ้อนกัน, เปิดใช้เครื่องมือในตัว, รักษาสถานะการสนทนาข้าม request และตรวจสอบสัญญา API ด้วย Apidog Responses API คืออินเทอร์เฟซใหม่ของ OpenAI สำหรับสร้างเอาต์พุตจากโมเดล และ คู่มือ Responses อย่างเป็นทางการ อธิบายว่าเหตุใด OpenAI จึงแนะนำให้โปรเจกต์ใหม่ใช้ API นี้ หากคุณเคยทดสอบเอนด์พอยต์เดิมอยู่แล้ว คุณสามารถนำ workflow ส่วนใหญ่กลับมาใช้ซ้ำได้ คล้ายกับ คู่มือการทดสอบ ChatGPT API ของเรา

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

สิ่งที่คุณต้องมีก่อน

ก่อนเริ่มเรียก POST /v1/responses ให้เตรียมสิ่งต่อไปนี้:

OpenAI API key ที่เข้าถึงโมเดลที่ต้องการได้ เก็บไว้ใน environment variable ไม่ใส่ตรง ๆ ในคำสั่งหรือไฟล์ที่แชร์
ชื่อโมเดลที่บัญชีของคุณเรียกใช้ได้ ตรวจสอบจากแดชบอร์ด OpenAI หรือทดลองเรียกเอนด์พอยต์แทนการฮาร์ดโค้ด
เครื่องมือส่ง HTTP request และดู JSON response เช่น curl สำหรับทดสอบเร็ว ๆ และ Apidog สำหรับตรวจสอบ schema, assertion และ mock response

Responses API มีเอนด์พอยต์หลักคือ POST /v1/responses คุณส่ง model และ input แล้วจะได้ response object ที่อาจมีข้อความ, function call และผลลัพธ์จากเครื่องมือที่ OpenAI โฮสต์ เช่น web search หรือ file search

การเรียกครั้งเดียวอาจมีหลายขั้นตอน เช่น โมเดลตัดสินใจค้นเว็บ อ่านผลลัพธ์ แล้วจึงเขียนคำตอบ รายละเอียดแต่ละขั้นตอนจะอยู่ใน output

จุดต่างหลักจาก API แบบข้อความเดิมมี 2 อย่าง:

ใช้เครื่องมือในตัวฝั่งเซิร์ฟเวอร์ได้ ไม่ต้องสร้างระบบค้นหา ไฟล์ หรือ sandbox เองทั้งหมด
มี state โดยค่าเริ่มต้น ทุก response มี id และคุณส่ง id นั้นเป็น previous_response_id ใน request ถัดไปเพื่อสนทนาต่อได้

OpenAI อธิบาย Responses API ว่าเป็นวิวัฒนาการของ Chat Completions และแนะนำสำหรับโปรเจกต์ใหม่ โดยรวมบทเรียนจาก Assistants API beta ให้เหลือโมเดลการทำงานเดียว

ทำความเข้าใจว่าต่างจาก Chat Completions อย่างไร

ถ้าคุณเคยใช้ POST /v1/chat/completions ความต่างหลักคือรูปแบบ request/response และการจัดการ state

Chat Completions ใช้ messages array และคืนค่าใน choices คุณต้องส่งประวัติการสนทนาทั้งหมดซ้ำในการเรียกแต่ละครั้ง และต้องจัดการ tool execution เอง

Responses API ใช้ input ซึ่งเป็น string หรือรายการแบบระบุชนิด และคืนค่าใน output ซึ่งเป็นรายการแบบระบุชนิดเช่นกัน นอกจากนี้ยังจัดเก็บสถานะและเรียกใช้เครื่องมือที่โฮสต์โดย OpenAI ได้

ด้าน	Chat Completions	Responses API
เอนด์พอยต์	`POST /v1/chat/completions`	`POST /v1/responses`
เนื้อหาคำขอ	`messages` array	`input` + `instructions`
รูปแบบเอาต์พุต	`choices[].message`	`output` array ของรายการแบบระบุชนิด
สถานะการสนทนา	ต้องส่งประวัติทั้งหมดซ้ำ	ใช้ `store` + `previous_response_id`
เครื่องมือในตัว	ต้องสร้างเอง	`web_search`, `file_search`, `code_interpreter` และอื่น ๆ
สถานะผลิตภัณฑ์	ยังรองรับ ไม่มีประกาศเลิกใช้	แนะนำสำหรับโปรเจกต์ใหม่

Chat Completions ยังไม่หายไป OpenAI ระบุว่าจะยังรองรับต่อ และคุณสามารถย้าย workflow ทีละส่วนได้ ไม่จำเป็นต้องเขียนใหม่ทั้งหมดในครั้งเดียว

ส่วน Assistants API กำลังจะถูกเลิกใช้งาน: OpenAI เลิกใช้งานเมื่อวันที่ 26 สิงหาคม 2025 และมีกำหนดสิ้นสุดวันที่ 26 สิงหาคม 2026 ดังนั้นงาน agent ใหม่ควรเริ่มบน Responses API

เรียก Responses API ครั้งแรก

เริ่มด้วย request ขั้นต่ำนี้ เปลี่ยนชื่อโมเดลให้ตรงกับโมเดลที่บัญชีของคุณเข้าถึงได้ และเก็บ API key ไว้ใน environment variable:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "input": "Write one sentence describing what an API mock server does.",
    "instructions": "You are a concise technical writer. No marketing language.",
    "store": true
  }'

ฟิลด์สำคัญใน request นี้คือ:

model: โมเดลที่ต้องการใช้
input: prompt หรือข้อมูลที่ส่งให้โมเดล
instructions: คำสั่งระดับระบบหรือแนวทางการตอบ
store: ตั้งเป็น true เพื่อให้ OpenAI บันทึก response object และนำไปใช้สนทนาต่อได้

อ่าน response ที่ได้กลับมา

ตัวอย่าง response แบบตัดทอน:

{
  "id": "resp_abc123",
  "object": "response",
  "status": "completed",
  "model": "gpt-5.5",
  "output": [
    {
      "type": "message",
      "role": "assistant",
      "content": [
        {
          "type": "output_text",
          "text": "A mock server returns predefined API responses so clients can be developed and tested before the real backend exists."
        }
      ]
    }
  ],
  "usage": {
    "input_tokens": 28,
    "output_tokens": 24,
    "total_tokens": 52
  }
}

จุดที่ควรสังเกต:

ข้อความอยู่ที่ output[0].content[0].text
ไม่ได้อยู่ใน field ระดับบนสุด
id ระดับบนสุดคือค่าที่ใช้ต่อกับ previous_response_id
usage.total_tokens ใช้ดูปริมาณ token ของ request นั้น

SDK อย่างเป็นทางการอาจมี helper เช่น output_text เพื่อรวมข้อความให้เป็น string เดียว แต่ถ้าคุณเรียก HTTP API โดยตรง ให้ parse จาก path ที่ซ้อนอยู่ใน output

ตัวอย่างอ่านค่าด้วย jq:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "input": "Write one sentence describing what an API mock server does."
  }' | jq -r '.output[0].content[0].text'

เพิ่มเครื่องมือในตัว

Responses API สามารถให้ OpenAI เรียกใช้เครื่องมือบางอย่างให้คุณได้ โดยประกาศใน tools array แล้วให้โมเดลตัดสินใจเองว่าจะเรียกใช้เมื่อใด

ประเภทเครื่องมือในตัวที่กล่าวถึง ได้แก่:

web_search สำหรับค้นหาอินเทอร์เน็ตแบบเรียลไทม์พร้อม citation (web_search_preview แบบเก่ายังใช้ได้กับ integration เดิม แต่ไม่มี control ใหม่)
file_search สำหรับดึงข้อมูลจากไฟล์ที่คุณอัปโหลด
code_interpreter สำหรับรันและวิเคราะห์โค้ดใน sandbox
computer_use สำหรับควบคุมอินเทอร์เฟซคอมพิวเตอร์
image_generation สำหรับสร้างภาพใน response

ตัวอย่างเปิดใช้ web search:

{
  "model": "gpt-5.5",
  "input": "What changed in the latest OpenAPI release? Cite sources.",
  "tools": [
    {
      "type": "web_search"
    }
  ]
}

เมื่อโมเดลใช้เครื่องมือ output จะมีรายการที่บันทึกขั้นตอน เช่น web_search_call และตามด้วย message สุดท้าย คุณจึงตรวจสอบได้ว่าโมเดลเรียกใช้เครื่องมือจริง ไม่ใช่แค่ตอบข้อความกลับมา

ตัวอย่าง assertion ที่ควรตรวจ:

{
  "expected_tool_call_type": "web_search_call"
}

path ที่ใช้ตรวจใน response คือรายการใดรายการหนึ่งใน output ที่มี:

{
  "type": "web_search_call"
}

สนทนาต่อข้าม request

Responses API ใช้ 2 parameter สำหรับ state:

store: ควบคุมว่า OpenAI จะจัดเก็บ response object หรือไม่ ค่าเริ่มต้นเป็นจริง และเก็บไว้ 30 วันโดยค่าเริ่มต้น
previous_response_id: ใช้เชื่อม request ใหม่กับ response เดิม

ตัวอย่าง request ถัดไป:

{
  "model": "gpt-5.5",
  "input": "Now rewrite that for a non-technical audience.",
  "previous_response_id": "resp_abc123"
}

คุณไม่ต้องส่งประวัติการสนทนาทั้งหมดซ้ำ เพราะ OpenAI ใช้ previous_response_id เพื่อผูกบริบทให้

ถ้าต้องการทำงานแบบ stateless หรือมีข้อกำหนดห้ามเก็บข้อมูล ให้ตั้งค่า:

{
  "store": false
}

แล้วจัดการบริบทเองในฝั่งแอป

สำหรับงาน voice และ low-latency realtime audio OpenAI ใช้พื้นผิว API คนละแบบ ดูเพิ่มเติมใน คู่มือ GPT realtime API ของเรา และถ้าคุณสร้าง agent หลายขั้นตอน รูปแบบโดยรวมจะสอดคล้องกับ OpenAI Agents SDK

วิธีทดสอบใน Apidog

Apidog เป็นแพลตฟอร์มสำหรับทดสอบ ออกแบบ และ mock API ไม่ใช่ OpenAI SDK ดังนั้น workflow คือ:

สร้าง HTTP request ไปที่ /v1/responses
ส่ง request พร้อม header และ body ที่ถูกต้อง
ดู JSON response จริง
เขียน assertion บน field ที่แอปของคุณต้องใช้
บันทึก response ที่เป็นตัวแทนไว้ใช้ mock สำหรับ dev/test

1. เก็บ API key ใน environment variable

ใน Apidog ให้สร้าง environment เช่น OpenAI Prod แล้วเพิ่มตัวแปร:

OPENAI_API_KEY=sk-...

จากนั้นสร้าง request ใหม่:

POST https://api.openai.com/v1/responses

เพิ่ม header:

Authorization: Bearer {{OPENAI_API_KEY}}
Content-Type: application/json

Apidog จะแทนค่าตัวแปรตอนส่ง request ทำให้ไม่ต้องใส่ secret ลงใน request ที่อาจถูกแชร์ในทีม

2. ใส่ JSON body

ใช้ body แบบนี้เป็น baseline:

{
  "model": "gpt-5.5",
  "input": "Write one sentence describing what an API mock server does.",
  "instructions": "You are a concise technical writer. No marketing language.",
  "store": true
}

กดส่ง แล้วตรวจ response ที่ได้ โดยเฉพาะ:

id
status
output
usage.total_tokens

3. ยืนยัน field ที่แอปต้องพึ่งพา

HTTP 200 ไม่ได้แปลว่า response มีรูปแบบตรงกับที่แอปคาดหวังเสมอ ให้เพิ่ม assertion เพื่อให้ regression fail ชัดเจน

ตัวอย่าง validation ที่ควรมี:

status เท่ากับ completed
output[0].content[0].text มีอยู่และไม่เป็นค่าว่าง
usage.total_tokens มากกว่า 0
เมื่อส่ง tools แล้ว ใน output มี item ที่ type เท่ากับ web_search_call

ตัวอย่างแนวคิด assertion:

status == "completed"
output[0].content[0].text exists
usage.total_tokens > 0
output[*].type contains "web_search_call"

เครื่องมือ assertion แบบ visual ของ Apidog ช่วยกำหนด JSON path เหล่านี้ได้โดยไม่ต้องเขียน test script เอง ดูแนวทางจัดโครงสร้างได้จาก เทมเพลตกรณีทดสอบ API

เมื่อบันทึก request ลง collection แล้ว คุณสามารถรันซ้ำใน CI เพื่อจับ breaking change ได้

4. Mock response สำหรับพัฒนาแบบออฟไลน์

การเรียก OpenAI มีค่าใช้จ่ายและต้องใช้ network ซึ่งไม่เหมาะกับทุกกรณี เช่น:

สร้าง UI ที่อ่าน response object
รัน test pipeline ที่ไม่ควรเรียก API แบบเสียเงิน
ต้องการผลลัพธ์ deterministic
ทำงาน offline

วิธีทำใน Apidog:

ส่ง request จริงไปยัง /v1/responses
บันทึก payload response ที่เป็นตัวแทน
สร้าง mock จาก payload นั้น
ชี้ frontend หรือ test client ไปที่ mock URL ของ Apidog
ใช้ JSON shape เดียวกับ production โดยไม่ใช้ token จริง

เมื่อ response shape ของเอนด์พอยต์จริงเปลี่ยน คุณอัปเดต mock เพียงจุดเดียว แทนที่จะไล่แก้ test หลายที่ อ่านแนวคิดเพิ่มเติมได้ใน คำอธิบาย API จำลอง

แนวทางที่ดีคือแยกการใช้งานเป็น 2 ชั้น:

ใช้เอนด์พอยต์จริงเพื่อตรวจ contract กับ OpenAI
ใช้ mock เพื่อพัฒนาและทดสอบแบบรวดเร็ว ควบคุมได้ และไม่พึ่ง network

ทั้งสองอย่างจัดการได้ในโปรเจกต์ Apidog เดียวกัน

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

Responses API จะมาแทนที่ Chat Completions หรือไม่?

ไม่ได้บังคับ OpenAI เรียก Responses ว่าเป็นวิวัฒนาการของ Chat Completions และแนะนำสำหรับโปรเจกต์ใหม่ แต่ Chat Completions ยังรองรับอยู่โดยไม่มีประกาศวันเลิกใช้งาน คุณสามารถย้าย workflow ทีละส่วนได้

ส่วน Assistants API เป็น API ที่กำลังจะเลิกใช้งาน โดยมีวันสิ้นสุดในปี 2026

ความแตกต่างระหว่าง `store` และ `previous_response_id` คืออะไร?

store ควบคุมว่า OpenAI จะบันทึก response object หรือไม่ ค่าเริ่มต้นเป็นจริงและเก็บไว้ 30 วันโดยค่าเริ่มต้น

previous_response_id ใช้เชื่อม request ใหม่กับ response ที่บันทึกไว้ เพื่อให้โมเดลสนทนาต่อฝั่งเซิร์ฟเวอร์

ใช้ร่วมกันเมื่อต้องการ thread แบบมี state และตั้ง store: false เมื่อต้องการควบคุม context เอง

โมเดลใดบ้างที่รองรับ Responses API?

โมเดลทั่วไปในปัจจุบันของ OpenAI ถูกออกแบบให้ทำงานกับ Responses API แต่ความพร้อมใช้งานขึ้นอยู่กับบัญชีและโมเดลที่คุณเลือก

แนวทางที่ปลอดภัยคือ:

ตรวจรายการโมเดลในแดชบอร์ด OpenAI
ส่ง request ทดสอบผ่าน Apidog หรือ curl
อ่านค่า model ใน response เพื่อยืนยันว่า key ของคุณเรียกใช้งานได้

ทดสอบเครื่องมือในตัวโดยไม่เขียนโค้ดได้ไหม?

ได้ เพิ่ม tools array ใน JSON body ผ่าน Apidog ส่ง request แล้วตรวจว่า item การเรียกเครื่องมือ เช่น web_search_call ปรากฏใน output

ตัวอย่าง body:

{
  "model": "gpt-5.5",
  "input": "Summarize the latest API design best practices and cite sources.",
  "tools": [
    {
      "type": "web_search"
    }
  ]
}

จากนั้น assert ว่า:

output[*].type contains "web_search_call"

การทดสอบนี้เป็นการตรวจพฤติกรรมผ่าน HTTP โดยตรง จึงไม่ต้องใช้ SDK สำหรับการสร้างชุดทดสอบ agent หรือ API ที่ใหญ่ขึ้น ดู วิธีสร้างชุดการทดสอบ API จาก OpenAPI specs

สรุป

Responses API รวมข้อความ เครื่องมือที่ OpenAI โฮสต์ และ state การสนทนาไว้ในเอนด์พอยต์เดียวคือ POST /v1/responses

workflow หลักคือ:

ส่ง model, input และ instructions
อ่านผลลัพธ์จาก output[0].content[0].text
เปิดใช้เครื่องมือผ่าน tools
ใช้ previous_response_id เพื่อสนทนาต่อ
เพิ่ม assertion เพื่อยืนยัน contract ของ response

เพราะ response shape ต่างจาก Chat Completions วิธีที่ปลอดภัยที่สุดคือทดสอบ contract จริง ไม่พึ่งความจำจาก API เดิม

ใน Apidog คุณสามารถสร้าง request, เก็บ key เป็น environment variable, assert field ที่ซ้อนอยู่ใน output และ mock response สำหรับงาน offline ได้ในโปรเจกต์เดียว ดาวน์โหลด Apidog แล้วชี้การทดสอบไปที่ /v1/responses เพื่อดูว่า integration ของคุณได้รับ JSON แบบใดจริง ๆ หรือเริ่มตั้งค่าทั้งหมดใน Apidog ได้โดยไม่ต้องเขียน test code แม้แต่บรรทัดเดียว

วิธีใช้งาน OpenAI Structured Outputs

Thanawat Wongchai — Fri, 26 Jun 2026 03:18:39 +0000

เมื่อจบคู่มือนี้ คุณจะสามารถเรียกใช้ structured outputs ของ OpenAI จากโค้ดของคุณเองได้: ส่ง JSON Schema ให้โมเดล, ตั้งค่า strict: true และรับผลตอบกลับที่ตรงกับรูปแบบที่ต้องการ จากนั้นคุณจะได้ส่งคำขอแรก, parse ผลลัพธ์, จัดการกรณีปฏิเสธ/ตัดทอน และสร้างชุดการทดสอบ API ใน Apidog เพื่อยืนยันว่า payload ตรงตาม schema จริง

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

สิ่งที่คุณต้องมีก่อนเริ่มต้น

Structured outputs จำกัดการสร้างผลลัพธ์ของโมเดลให้เป็นไปตาม JSON Schema ที่คุณกำหนด เมื่อส่ง schema พร้อม strict: true โมเดลจะสร้างผลลัพธ์ที่มีคีย์, ประเภทข้อมูล และค่า enum ตรงตามข้อกำหนด แทนที่จะต้องเขียนโค้ดกัน parsing พังจาก JSON ที่รูปร่างไม่แน่นอน

Structured outputs ต่างจากการ prompt แบบ “ตอบกลับเป็น JSON เท่านั้น” เพราะคำสั่งแบบนั้นรับประกันได้แค่ในเชิงพฤติกรรม ไม่ใช่ข้อบังคับระดับ schema โมเดลอาจเพิ่มข้อความอธิบาย, คืนชนิดข้อมูลผิด หรือขาดฟิลด์ที่จำเป็นได้ ส่วน structured outputs บังคับใช้ข้อจำกัด ณ เวลาถอดรหัส

ก่อนเริ่ม คุณต้องมี:

OpenAI API key ที่ตั้งค่าไว้ใน environment variable ชื่อ OPENAI_API_KEY
โมเดลที่รองรับ schema แบบเข้มงวด
JSON Schema ที่อธิบาย output ที่ต้องการ

เลือกโมเดลที่เหมาะสม

Structured outputs ใช้งานได้ในโมเดล OpenAI รุ่นใหม่ตั้งแต่ตระกูล GPT-4o และต่อเนื่องถึงซีรีส์ GPT-5 เอกสารของ OpenAI แนะนำให้เริ่มโปรเจกต์ใหม่ด้วยโมเดลเรือธงล่าสุด (gpt-5.5 ในขณะที่เขียน)

โมเดลรุ่นเก่าและโมเดลยุค gpt-3.5 รองรับ JSON mode แต่ไม่รองรับการบังคับใช้ schema แบบเข้มงวด หากคุณต้องพึ่ง strict: true ให้ตรวจสอบ model ID ที่ใช้จริงก่อน deploy เพราะความสามารถนี้ผูกกับเวอร์ชันของโมเดล

OpenAI มี 2 ฟีเจอร์ที่คล้ายกันแต่ไม่เหมือนกัน:

JSON mode

{
  "response_format": {
    "type": "json_object"
  }
}

JSON mode รับประกันว่า output เป็น JSON ที่ถูกต้องตามไวยากรณ์ แต่ไม่รับประกันว่าฟิลด์, ชนิดข้อมูล หรือ enum จะตรงกับ schema ของคุณ

Structured outputs

{
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "schema_name",
      "strict": true,
      "schema": {}
    }
  }
}

Structured outputs รับประกันทั้ง JSON ที่ถูกต้องและรูปร่างที่ตรงกับ schema

	โหมด JSON	Structured outputs แบบเข้มงวด
พารามิเตอร์	`response_format: {"type":"json_object"}`	`response_format` พร้อม `type: "json_schema"` และ `strict: true`
JSON ถูกต้อง	ใช่	ใช่
ตรงกับ schema	ไม่	ใช่
บังคับฟิลด์ที่จำเป็น	ไม่	ใช่
บังคับ type และ enum	ไม่	ใช่
ยังควร validate ต่อไหม	ควรเสมอ	ควรสำหรับกฎระดับค่าและ regression test

หมายเหตุเรื่อง API: Chat Completions ใช้ response_format ส่วน Responses API รุ่นใหม่แสดงแนวคิดเดียวกันภายใต้ text.format พร้อม type: "json_schema" กฎของ schema เหมือนกัน ต่างกันแค่ตำแหน่งของฟิลด์ใน request

ส่งคำขอ structured output ครั้งแรก

ตัวอย่างนี้ดึงข้อมูลจากข้อความ ticket support ให้เป็น object ที่มี schema ชัดเจน

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "messages": [
      {
        "role": "system",
        "content": "Extract the ticket into the schema."
      },
      {
        "role": "user",
        "content": "My checkout 500s every time I use a saved card. Started today. Account: acct_8842."
      }
    ],
    "response_format": {
      "type": "json_schema",
      "json_schema": {
        "name": "support_ticket",
        "strict": true,
        "schema": {
          "type": "object",
          "properties": {
            "summary": {
              "type": "string"
            },
            "category": {
              "type": "string",
              "enum": ["billing", "bug", "account", "other"]
            },
            "severity": {
              "type": "integer"
            },
            "account_id": {
              "anyOf": [
                { "type": "string" },
                { "type": "null" }
              ]
            }
          },
          "required": ["summary", "category", "severity", "account_id"],
          "additionalProperties": false
        }
      }
    }
  }'

จุดที่ต้องสังเกต:

type: "json_schema" เปิด structured outputs
strict: true บังคับให้ output ตรง schema
ทุก property อยู่ใน required
additionalProperties: false ป้องกันคีย์ส่วนเกิน
ฟิลด์ที่อาจไม่มีค่าใช้ anyOf ร่วมกับ null

อ่านผลตอบกลับ

โมเดลจะคืน message.content เป็น string JSON ที่ตรงกับ schema เช่น:

{
  "summary": "Checkout returns HTTP 500 when paying with a saved card",
  "category": "bug",
  "severity": 3,
  "account_id": "acct_8842"
}

ในแอปจริง คุณควร parse JSON หลังจากตรวจสอบว่าไม่มี refusal และผลลัพธ์ไม่ถูกตัดทอน

ตัวอย่าง Python:

import json

msg = response.choices[0].message

if msg.refusal:
    handle_refusal(msg.refusal)
else:
    ticket = json.loads(msg.content)
    process_ticket(ticket)

เขียน schema ให้อยู่ใน subset ที่รองรับ

Structured outputs รองรับเพียง subset ของ JSON Schema เพื่อให้ OpenAI บังคับใช้ข้อจำกัดได้อย่างน่าเชื่อถือและ cache schema ที่ compile แล้วได้

กฎสำคัญ:

root ต้องเป็น object

ใช้ไม่ได้:

   {
     "type": "array"
   }

ใช้ object ห่อแทน:

   {
     "type": "object",
     "properties": {
       "items": {
         "type": "array",
         "items": {
           "type": "string"
         }
       }
     },
     "required": ["items"],
     "additionalProperties": false
   }

ทุก property ต้องอยู่ใน required

Structured outputs ไม่มี optional field แบบดั้งเดิม หากค่าขาดได้ ให้ทำเป็น nullable:

   {
     "account_id": {
       "anyOf": [
         { "type": "string" },
         { "type": "null" }
       ]
     }
   }

ทุก object ต้องมี additionalProperties: false

วิธีนี้ทำให้โมเดลไม่สร้างคีย์ที่ schema ไม่ได้ประกาศไว้

schema มีข้อจำกัดด้านขนาด

โดยทั่วไป schema รองรับ object properties ได้ประมาณ 100 รายการ และซ้อนกันได้สูงสุด 5 ระดับ หาก schema กว้างหรือลึกเกินไป อาจถูกปฏิเสธ ควร flatten เท่าที่เหมาะสม

บาง keyword ไม่ได้ถูกบังคับใช้โดยโมเดล

keyword อย่าง pattern, format, minLength และ minimum ไม่ได้รับประกันจากโมเดล ถ้าคุณต้องการ regex, date format หรือช่วงตัวเลขที่เข้มงวด ให้ validate ซ้ำในแอปหรือ test pipeline

ดังนั้น “JSON ที่รับประกัน” หมายถึงรูปร่างของ object ถูกล็อก ไม่ได้หมายความว่ากฎทางธุรกิจถูกต้องทั้งหมด ถ้าคุณเคยใช้ oneOf/anyOf/allOf เพื่อสร้าง optional หรือ union fields แนวคิดจะคล้ายกัน: schema คุมโครงสร้าง ส่วน business validation ต้องทำต่อเอง

จัดการ refusal และ output ที่ถูกตัดทอน

มีกรณีที่ output จะไม่ตรง schema โดยตั้งใจ: เมื่อโมเดลปฏิเสธคำขอที่ไม่ปลอดภัย โมเดลจะคืน refusal แทน content ที่เป็น JSON ตาม schema

ตรวจสอบ refusal ก่อน parse เสมอ:

import json

msg = response.choices[0].message

if msg.refusal:
    handle_refusal(msg.refusal)
    return

ticket = json.loads(msg.content)

กรณีอื่นที่ต้องระวัง:

response ถูกตัดกลางคันเพราะถึง max_tokens
ใช้ parallel tool calls ร่วมกับ structured outputs

ถ้าคุณใช้ tool calls ร่วมด้วย ให้ตั้งค่า:

{
  "parallel_tool_calls": false
}

ทดสอบ structured outputs ใน Apidog

โหมดเข้มงวดช่วยบังคับ schema ตอนโมเดลสร้างผลลัพธ์ แต่ยังไม่แทนที่การทดสอบ เพราะ model ID อาจถูกเปลี่ยน, schema อาจถูกแก้, prompt อาจเปลี่ยน หรือเส้นทาง refusal อาจทำงานต่างจากเดิม

คุณสามารถใช้ Apidog เพื่อสร้าง request, assertion และ mock สำหรับ workflow นี้

การแบ่งหน้าที่ควรเป็นแบบนี้:

OpenAI structured outputs: สร้าง JSON ให้ตรง schema
Apidog: ตรวจสอบ response ที่ได้รับเทียบกับ schema และทำให้ความผิดพลาดถูกจับได้ใน CI

ขั้นตอนใช้งาน

สร้าง request

สร้าง request ไปยัง Chat Completions ใน Apidog ใส่ headers และ body ที่มี response_format ตามตัวอย่างด้านบน จากนั้นบันทึกไว้ใน collection

เพิ่ม assertion สำหรับ response

ตรวจสอบค่าหลัก เช่น:

category ต้องเป็น billing, bug, account หรือ other
severity ต้องเป็น integer
account_id ต้องเป็น string หรือ null

Apidog สามารถตรวจสอบ response เทียบกับ JSON Schema ได้โดยแนบ schema เดียวกับที่คุณส่งให้ OpenAI

รันใน CI

ใส่ collection เข้า pipeline เพื่อให้ทุกการเปลี่ยน model, prompt หรือ schema ถูกทดสอบซ้ำ หาก response ผิด contract ให้ build fail ทันที

สร้าง mock API

ก่อนต่อ OpenAI จริง หรือเมื่อต้องการทดสอบ frontend/consumer โดยไม่ใช้ token ให้ตั้งค่า mock API ที่คืนตัวอย่าง response ตาม schema เดียวกัน

แนวทางนี้ช่วยให้ทีมที่ consume structured output ทำงานต่อได้โดยไม่ต้องรอ integration เสร็จทั้งหมด คุณสามารถดาวน์โหลด Apidog แล้วจัดการ request, assertion และ mock ในที่เดียว

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

JSON mode ถูกแทนที่ด้วย structured outputs แล้วหรือยัง?

ยังไม่ถูกแทนที่ JSON mode ยังใช้ได้และยังรับประกัน JSON ที่ valid แต่ไม่บังคับ schema สำหรับโค้ดใหม่ที่มีรูปแบบข้อมูลชัดเจน ควรใช้ structured outputs พร้อม strict: true

root schema เป็น array ได้ไหม?

ไม่ได้ ระดับบนสุดต้องเป็น object ให้ห่อ array ไว้ใน property เช่น:

{
  "type": "object",
  "properties": {
    "items": {
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  },
  "required": ["items"],
  "additionalProperties": false
}

ทำ optional field อย่างไร?

Structured outputs กำหนดให้ทุก property อยู่ใน required ถ้าค่าหายได้ ให้ใช้ nullable field:

{
  "nickname": {
    "anyOf": [
      { "type": "string" },
      { "type": "null" }
    ]
  }
}

คีย์ nickname จะมีเสมอ แต่ค่าเป็น null ได้

ใช้ strict mode แล้วข้าม validation ได้ไหม?

ข้ามการ validate รูปร่างพื้นฐานได้ในหลายกรณี แต่ยังควร validate กฎระดับค่า เช่น regex, format, min/max และ business rules เพราะ keyword บางตัวไม่ได้ถูกบังคับใช้โดยโมเดล นอกจากนี้ refusal และ truncation ยังต้องจัดการแยกต่างหาก หากยังไม่คุ้นกับ schema อ่านพื้นฐานได้ที่บทนำ JSON Schema

ควรใช้โมเดลใด?

Structured outputs ใช้งานได้กับ GPT-4o และรุ่นใหม่กว่า รวมถึงซีรีส์ GPT-5 เอกสาร OpenAI แนะนำให้ใช้โมเดลเรือธงปัจจุบันสำหรับโปรเจกต์ใหม่ แต่คุณควรตรวจสอบ model ID ที่ใช้จริงว่ารองรับ strict: true ก่อนนำไป production

สรุป

workflow ที่ควรใช้คือ: เลือกโมเดลที่รองรับ structured outputs, ส่ง schema ผ่าน response_format พร้อม strict: true, เขียน schema ให้อยู่ใน subset ที่รองรับ, ตรวจ refusal ก่อน parse, และ validate กฎระดับค่าซ้ำเมื่อจำเป็น จากนั้นใช้ Apidog เพื่อยืนยัน response เทียบกับ schema และสร้าง mock สำหรับส่วนอื่นของระบบ โมเดลช่วยรับประกันรูปร่าง ส่วน test suite ช่วยพิสูจน์ว่าสัญญานั้นยังไม่พังเมื่อระบบเปลี่ยนแปลง

วิธีใช้ OpenAI Batch API

Thanawat Wongchai — Thu, 25 Jun 2026 10:16:06 +0000

เมื่ออ่านจบ คุณจะเรียกใช้ OpenAI Batch API เพื่อรันคำขอโมเดลจำนวนมากเป็นงานอะซิงโครนัสเดียวได้: เตรียมไฟล์ JSONL, อัปโหลด, สร้างแบทช์, ตรวจสอบสถานะ และดาวน์โหลดผลลัพธ์ โดย Batch API มีส่วนลด 50% เมื่อเทียบกับ synchronous API สำหรับโทเค็นขาเข้าและขาออก จากนั้นคุณสามารถทดสอบ flow ทั้งหมดใน Apidog ก่อนนำไปใช้จริง หากงานของคุณต้องตอบกลับผู้ใช้ทันที ให้ใช้ synchronous API แทน และดูวิธี ทดสอบ ChatGPT API ด้วย Apidog

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

Batch API คืออะไร และควรใช้เมื่อใด

Batch API คือ endpoint แบบอะซิงโครนัสสำหรับงานที่มีคำขอจำนวนมากและยอมรับ latency ได้ แทนที่จะยิง HTTP request ทีละ prompt คุณรวมคำขอทั้งหมดไว้ในไฟล์ JSONL ไฟล์เดียว ส่งเป็น batch job แล้ว poll สถานะจนกว่าจะเสร็จ OpenAI จะประมวลผลและส่งผลลัพธ์กลับมาเป็นไฟล์ output

เหมาะกับงาน offline ปริมาณมาก เช่น:

จัดหมวดหมู่หรือติดแท็กข้อมูลย้อนหลัง
สร้าง embeddings สำหรับ dataset ขนาดใหญ่
สร้างเนื้อหาจำนวนมาก เช่น product descriptions, summaries, translations
รัน evaluation suite หรือ benchmark โมเดลกับ dataset

ไม่เหมาะกับงานที่ผู้ใช้รอผลแบบ real-time เช่น chat UI, autocomplete หรือ live agents เพราะ Batch API รับประกันกรอบเวลาสูงสุด 24 ชั่วโมง ไม่ใช่การตอบกลับทันที

ถ้าคุณต้องสร้าง config หรือตัวแทนจำนวนมากพร้อมกัน การประมวลผลแบบ batch จะเหมาะกับ use case นี้ ดูตัวอย่างเพิ่มเติมได้ที่ สร้างการกำหนดค่าตัวแทนมากกว่า 100 รายการด้วยการประมวลผลแบบแบทช์

สิ่งที่ต้องมีก่อนเริ่มต้น

คุณจะใช้ 2 endpoints หลัก:

ขั้นตอน	Endpoint	หน้าที่
1. อัปโหลดไฟล์	`POST /v1/files`	อัปโหลดไฟล์ `.jsonl` พร้อม `purpose: "batch"` แล้วรับ file ID
2. สร้างแบทช์	`POST /v1/batches`	ส่ง file ID, endpoint เป้าหมาย และ completion window
3. ตรวจสอบสถานะ	`GET /v1/batches/{id}`	poll `status` จนเป็น `completed`
4. ดาวน์โหลดผลลัพธ์	`GET /v1/files/{id}/content`	ดาวน์โหลด output ผ่าน `output_file_id`

สิ่งที่ต้องเตรียม:

OpenAI API key ตั้งเป็น environment variable: OPENAI_API_KEY
ไฟล์ JSONL ที่มี request ต่อบรรทัด
เครื่องมือสำหรับยิง request และตรวจสอบ response เช่น curl หรือ Apidog

ขั้นตอนที่ 1: สร้างและอัปโหลดไฟล์ JSONL

ไฟล์ input ต้องเป็น JSONL โดย 1 บรรทัด = 1 request ที่สมบูรณ์ แต่ละบรรทัดต้องมีฟิลด์หลัก:

custom_id: ID ที่คุณกำหนดเอง ต้องไม่ซ้ำภายในไฟล์
method: โดยทั่วไปคือ POST
url: endpoint เป้าหมาย เช่น /v1/chat/completions
body: request body จริงที่ส่งให้โมเดล

ตัวอย่าง requests.jsonl:

{"custom_id": "req-1", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4.1-mini", "messages": [{"role": "user", "content": "Classify the sentiment of: 'shipping was slow but the product is great'"}]}}
{"custom_id": "req-2", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4.1-mini", "messages": [{"role": "user", "content": "Classify the sentiment of: 'returned it the same day'"}]}}

ผลลัพธ์ไม่ได้รับประกันลำดับเดียวกับ input ดังนั้นให้ใช้ custom_id เพื่อจับคู่ response กลับไปยัง request เดิมเสมอ

ข้อจำกัดสำคัญ:

1 batch รองรับได้สูงสุด 50,000 requests
ขนาดไฟล์สูงสุด 200 MB
custom_id ต้องไม่ซ้ำกัน

อัปโหลดไฟล์ไปยัง Files API โดยตั้ง purpose=batch:

curl https://api.openai.com/v1/files \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -F purpose="batch" \
  -F file="@requests.jsonl"

response จะมี id ของไฟล์ เช่น:

{
  "id": "file-abc123",
  "object": "file",
  "purpose": "batch"
}

เก็บค่านี้ไว้เป็น input_file_id สำหรับขั้นตอนถัดไป

ขั้นตอนที่ 2: สร้างแบทช์

สร้าง batch job โดยส่ง:

input_file_id: file ID จากขั้นตอนก่อนหน้า
endpoint: endpoint ที่ตรงกับ url ใน JSONL
completion_window: ปัจจุบันใช้ "24h"
metadata: optional สำหรับติด tag งาน

curl https://api.openai.com/v1/batches \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "input_file_id": "file-abc123",
    "endpoint": "/v1/chat/completions",
    "completion_window": "24h",
    "metadata": {
      "job": "sentiment-backfill"
    }
  }'

endpoint ต้องตรงกับ url ในแต่ละบรรทัดของ JSONL เช่นถ้า JSONL ใช้ /v1/chat/completions batch ก็ต้องระบุ /v1/chat/completions

ตัวอย่าง response:

{
  "id": "batch_abc123",
  "object": "batch",
  "endpoint": "/v1/chat/completions",
  "input_file_id": "file-abc123",
  "completion_window": "24h",
  "status": "validating",
  "output_file_id": null,
  "error_file_id": null,
  "request_counts": {
    "total": 0,
    "completed": 0,
    "failed": 0
  },
  "created_at": 1733452800,
  "metadata": {
    "job": "sentiment-backfill"
  }
}

ฟิลด์ที่ควรเก็บไว้:

id: batch ID ใช้สำหรับ poll สถานะ
status: สถานะปัจจุบัน
output_file_id: ใช้ดาวน์โหลดผลลัพธ์เมื่อเสร็จ
error_file_id: ใช้ดู request ที่ error
request_counts: จำนวน request ทั้งหมด/สำเร็จ/ล้มเหลว

ขั้นตอนที่ 3: ตรวจสอบสถานะแบทช์

เรียก GET /v1/batches/{batch_id} เพื่อดูสถานะ:

curl https://api.openai.com/v1/batches/batch_abc123 \
  -H "Authorization: Bearer $OPENAI_API_KEY"

สถานะที่ควรรู้:

สถานะ	ความหมาย
`validating`	กำลังตรวจสอบไฟล์ input
`in_progress`	กำลังประมวลผล request
`finalizing`	ประมวลผลเสร็จและกำลังเตรียม output file
`completed`	เสร็จแล้ว ดาวน์โหลดผลลัพธ์ได้
`failed`	validation ล้มเหลว ไม่มี request ถูกประมวลผล
`expired`	ครบกรอบเวลา 24 ชั่วโมงก่อนประมวลผลครบ
`cancelling` / `cancelled`	กำลังยกเลิกหรือยกเลิกแล้ว

ระหว่าง in_progress ให้ดู progress จาก:

"request_counts": {
  "total": 50000,
  "completed": 30000,
  "failed": 12
}

ไม่มี webhook สำหรับรอผล ดังนั้นให้ poll เป็นระยะ เช่น ทุก 2–5 นาที ไม่ควร poll ทุกวินาที

ถ้าต้องการยกเลิกงาน:

curl -X POST https://api.openai.com/v1/batches/batch_abc123/cancel \
  -H "Authorization: Bearer $OPENAI_API_KEY"

ขั้นตอนที่ 4: ดาวน์โหลดผลลัพธ์

เมื่อ status เป็น completed response ของ batch จะมี output_file_id

ดาวน์โหลดไฟล์ output:

curl https://api.openai.com/v1/files/file-output456/content \
  -H "Authorization: Bearer $OPENAI_API_KEY" > results.jsonl

ผลลัพธ์จะเป็น JSONL เช่นกัน โดย 1 บรรทัดต่อ 1 request และมี custom_id สำหรับจับคู่กับ input

ตัวอย่างโครงสร้างผลลัพธ์:

{
  "custom_id": "req-1",
  "response": {
    "status_code": 200,
    "body": {
      "id": "chatcmpl-...",
      "object": "chat.completion"
    }
  },
  "error": null
}

แนวทาง parse ผลลัพธ์:

อ่าน results.jsonl ทีละบรรทัด
parse เป็น JSON
ใช้ custom_id เพื่อ map กลับไปยัง record เดิม
ตรวจสอบ response.status_code
ถ้ามี error_file_id ให้ดาวน์โหลด error file เพิ่มเติม

ตัวอย่าง parse ด้วย Node.js:

import fs from "node:fs";
import readline from "node:readline";

const input = fs.createReadStream("results.jsonl");

const rl = readline.createInterface({
  input,
  crlfDelay: Infinity,
});

for await (const line of rl) {
  if (!line.trim()) continue;

  const item = JSON.parse(line);

  console.log({
    customId: item.custom_id,
    statusCode: item.response?.status_code,
    hasError: Boolean(item.error),
  });
}

ข้อควรพิจารณาเรื่องต้นทุนและกรอบเวลา

Batch API เหมาะเมื่อคุณยอมรับ latency ได้สูงสุด 24 ชั่วโมงเพื่อแลกกับต้นทุน token ที่ลดลง 50%

ใช้ได้ดีกับ:

nightly jobs
backfill ข้อมูล
offline evaluation
batch embeddings
content generation จำนวนมาก

ไม่ควรใช้กับ:

request ที่ผู้ใช้รอหน้า UI
chatbot แบบ real-time
workflow ที่ต้องการผลลัพธ์ภายในไม่กี่วินาที

ข้อควรจำ:

ส่วนลด 50% ใช้กับโทเค็นขาเข้าและขาออกสำหรับโมเดลที่รองรับ
กรอบเวลา 24 ชั่วโมงคือเพดาน ไม่ใช่ SLA ว่าจะเสร็จเร็ว
ถ้า batch เป็น expired เฉพาะ request ที่ประมวลผลสำเร็จแล้วเท่านั้นที่จะถูกส่งคืนและถูกเรียกเก็บเงิน
batch jobs ใช้ rate limit pool แยกจาก synchronous traffic จึงไม่กระทบ real-time API limits ของคุณ
ควรใช้ metadata เพื่อติด tag งานและ track cost ภายหลัง

ถ้าคุณต้องจัดการ rate limit ฝั่ง synchronous ดูเพิ่มเติมที่ GPT API rate limits และวิธีการทดสอบ

ถ้าต้องการแยกต้นทุนตาม feature หรือ job ดู คู่มือการจัดสรรต้นทุนสำหรับการใช้จ่าย OpenAI

วิธีทดสอบใน Apidog

Batch API มีจุดที่พลาดได้หลายจุด เช่น JSONL format, multipart upload, batch lifecycle, polling, output parsing และ error handling การทดสอบ flow ก่อน automate จะช่วยลดเวลารอซ้ำเมื่อ batch ล้มเหลว

Apidog ช่วยให้คุณทดสอบแต่ละ endpoint, chain request และตรวจสอบ response ได้โดยไม่ต้องเขียนสคริปต์ทั้งหมดตั้งแต่แรก

ตั้งค่า flow ทดสอบแบบนี้:

ตรวจ JSONL ก่อนอัปโหลด

ตรวจว่าทุกบรรทัดมี custom_id, method, url, body, body.model และ payload ที่ถูกต้อง
ทดสอบ multipart upload

เรียก POST /v1/files พร้อม purpose=batch และแนบไฟล์ .jsonl จากนั้นบันทึก id ที่ได้เป็น environment variable เช่น input_file_id
สร้าง batch

เรียก POST /v1/batches โดยใช้ input_file_id แล้วตรวจว่า:
- status เป็น validating
- endpoint ตรงกับที่ส่ง
- input_file_id ถูกต้อง
poll สถานะ

เรียก GET /v1/batches/{id} ซ้ำเป็นระยะ และดู status, request_counts, output_file_id, error_file_id
ดาวน์โหลด output

เมื่อ completed ให้ใช้ output_file_id เรียก GET /v1/files/{id}/content
ทดสอบ error path

ส่ง JSONL ที่ตั้งใจให้ผิด เช่นขาด custom_id หรือ body เพื่อดู behavior ของ failed และทดสอบ POST /v1/batches/{id}/cancel

เนื่องจาก output file อาจมาช้า คุณสามารถใช้ mock API เพื่อจำลอง batch ที่เสร็จแล้ว และ mock ไฟล์ผลลัพธ์สำหรับทดสอบ parser โดยไม่ต้องรอ 24 ชั่วโมงหรือใช้ token จริง

ถ้าทีมทำงานแบบ spec-first คุณยังสามารถ สร้างคอลเลกชันการทดสอบได้โดยตรงจาก OpenAPI spec เพื่อให้ endpoints ของ batch อยู่ใน regression test ได้

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

แบทช์ใช้เวลานานเท่าไหร่

OpenAI รับประกันกรอบเวลาสูงสุด 24 ชั่วโมง หลายงานอาจเสร็จเร็วกว่านั้น แต่ควรออกแบบระบบโดยสมมติ worst case ที่ 24 ชั่วโมง

ถ้าไม่เสร็จภายในกรอบเวลา batch จะเป็น expired และเฉพาะ request ที่ประมวลผลสำเร็จแล้วเท่านั้นที่จะถูกส่งคืนและถูกเรียกเก็บเงิน

ส่วนลดคือเท่าไหร่

Batch API ให้ส่วนลด 50% เมื่อเทียบกับ synchronous endpoints สำหรับโทเค็นขาเข้าและขาออก เหมาะกับงาน offline ที่มี volume สูง

ถ้าต้องการแบ่งต้นทุนกลับไปยัง feature หรือ job ต่าง ๆ ดู คู่มือการจัดสรรต้นทุน

ใช้ endpoint ใดใน Batch API ได้บ้าง

คุณต้องตั้ง endpoint ให้ตรงกันทั้งใน:

url ของแต่ละบรรทัดใน JSONL
endpoint ตอนสร้าง batch

ตัวอย่าง endpoint ที่รองรับ:

/v1/chat/completions
/v1/responses
/v1/embeddings
/v1/completions
/v1/moderations

รวมถึง endpoints รูปภาพและวิดีโอบางส่วน ควรตรวจเอกสาร OpenAI ล่าสุดก่อนใช้งานจริง เพราะรายการ endpoint อาจมีการอัปเดต

ทำไมผลลัพธ์ไม่เรียงตาม input

เป็น behavior ปกติของ Batch API ไฟล์ output ไม่รับประกันลำดับเดียวกับไฟล์ input

ให้ใช้ custom_id เพื่อ map ผลลัพธ์กลับไปยัง request เดิมเสมอ ห้ามอ้างอิงจากลำดับบรรทัด

ถ้า request บางรายการล้มเหลวต้องทำอย่างไร

ตรวจสอบทั้ง:

output_file_id: request ที่มีผลลัพธ์
error_file_id: request ที่ error

จากนั้นใช้ custom_id เพื่อแยกเฉพาะรายการที่ล้มเหลว แล้วสร้าง JSONL ใหม่สำหรับ retry เฉพาะ request เหล่านั้น

บทสรุป

Flow หลักของ OpenAI Batch API คือ:

สร้างไฟล์ JSONL
อัปโหลดด้วย POST /v1/files
สร้าง batch ด้วย POST /v1/batches
poll สถานะด้วย GET /v1/batches/{id}
ดาวน์โหลด output ด้วย GET /v1/files/{id}/content
parse ผลลัพธ์ด้วย custom_id

Batch API เหมาะกับงาน offline ปริมาณมากที่รับ latency ได้สูงสุด 24 ชั่วโมง และต้องการลดต้นทุน token ลง 50%

ก่อน automate ใน production ให้รัน lifecycle ด้วยตนเองใน Apidog เพื่อตรวจ JSONL, ทดสอบ upload, สร้าง batch, poll สถานะ, ทดสอบ cancel/error path และยืนยัน response fields ให้ครบก่อนปล่อยงานจริงขนาดใหญ่

Google ADK (Agent Development Kit) คืออะไร? คู่มือใช้งานจริง

Thanawat Wongchai — Thu, 25 Jun 2026 08:15:20 +0000

Google ADK เป็นเฟรมเวิร์กโอเพนซอร์สสำหรับสร้าง ประเมิน และปรับใช้ AI เอเจนต์ ใช้จริงภายในผลิตภัณฑ์ของ Google เช่น Agentspace หากคุณเคยใช้สแต็กเอเจนต์อย่าง OpenAI Agents SDK มาก่อน ADK จะอยู่ในกลุ่มเดียวกัน แต่ผสานกับ Gemini และ Vertex AI ได้แน่นกว่า บทความนี้สรุปวิธีคิด โครงสร้างหลัก วิธีเริ่มเขียนเอเจนต์ และจุดที่ Apidog ช่วยทดสอบ API ที่เอเจนต์เรียกใช้ได้

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

Google ADK คืออะไร

ADK ย่อมาจาก Agent Development Kit เป็นชุดเครื่องมือโอเพนซอร์สที่ Google เปิดตัวในงาน Google Cloud Next เดือนเมษายน 2025 สำหรับวงจรชีวิตของเอเจนต์แบบครบขั้นตอน:

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

ADK เริ่มจาก Python เป็นหลัก และ Google ได้เพิ่ม Java เข้ามาแล้ว โดยมี Go และ TypeScript ตามมา เฟรมเวิร์กนี้เป็นชุดเดียวกับที่ Google ใช้ภายในสำหรับเอเจนต์ใน Agentspace และ Customer Engagement Suite จึงออกแบบมาสำหรับงาน production ไม่ใช่แค่ตัวอย่างทดลอง

ADK เป็นแบบ model-agnostic แต่เหมาะกับระบบของ Google เป็นพิเศษ โดยทำงานได้ดีกับ Gemini และโมเดลที่อยู่ใน Vertex AI Model Garden นอกจากนี้ยังเชื่อมกับ LiteLLM เพื่อใช้โมเดลจากผู้ให้บริการอื่น เช่น Anthropic, Meta และ Mistral ได้ด้วย

ADK อยู่ตรงไหนในระบบ Gemini และ Vertex AI

ให้มอง ADK เป็นหนึ่งเลเยอร์ในสแต็กเอเจนต์:

โมเดล: Gemini หรือโมเดลอื่นผ่าน Vertex AI Model Garden / LiteLLM ทำหน้าที่ reasoning
เฟรมเวิร์ก: ADK คือเลเยอร์โค้ดสำหรับกำหนดเอเจนต์ เครื่องมือ และเวิร์กโฟลว์
รันไทม์: Vertex AI Agent Engine ใช้โฮสต์เอเจนต์แบบ managed และ scalable หรือจะปรับใช้บน Cloud Run / container runtime อื่นก็ได้

สรุปคือ Gemini ให้ความสามารถด้านโมเดล, ADK ให้โครงสร้างการพัฒนา, และ Vertex AI Agent Engine ให้รันไทม์สำหรับ production คุณสามารถใช้ครบทั้งสามส่วน หรือใช้ ADK ในเครื่องแล้ว deploy ไปยังแพลตฟอร์มอื่นก็ได้

แนวคิดหลักของ ADK

ส่วนที่คุณจะใช้บ่อยมีไม่กี่อย่าง: Agent, Tool, Multi-agent workflow, Runner, Evaluation และ Deployment

1. Agent

เอเจนต์คือหน่วยหลักที่ขับเคลื่อนด้วย LLM ใน Python คุณอิมพอร์ต Agent จาก google.adk.agents แล้วกำหนด:

name: ชื่อเอเจนต์
model: โมเดลที่ใช้
instruction: system instruction / behavior
tools: ฟังก์ชันที่เอเจนต์เรียกใช้ได้

ตัวอย่างเอเจนต์สำหรับดูอัตราแลกเปลี่ยน:

from google.adk.agents import Agent

def get_exchange_rate(base: str, target: str) -> dict:
    """Return the exchange rate between two currencies."""
    # ในงานจริง ให้เรียก FX API ของคุณตรงนี้
    return {
        "base": base,
        "target": target,
        "rate": 1.08,
    }

currency_agent = Agent(
    name="currency_exchange_agent",
    model="gemini-2.0-flash",
    instruction="You help users convert between currencies. Stick to the facts.",
    tools=[get_exchange_rate],
)

โค้ดนี้สร้างเอเจนต์หนึ่งตัวที่รู้ว่าต้องตอบเรื่องการแปลงสกุลเงิน และมีเครื่องมือ get_exchange_rate() ให้เรียกเมื่อจำเป็น

2. Tool

Tool คือสิ่งที่ทำให้เอเจนต์ทำงานนอกเหนือจากการสร้างข้อความ เช่น เรียก REST API, ค้นข้อมูล, อ่านฐานข้อมูล หรือรันโค้ด

ใน ADK ฟังก์ชัน Python ธรรมดาสามารถเป็น tool ได้ โดยโมเดลจะใช้ข้อมูลเหล่านี้เพื่อเลือกว่าจะเรียกใช้เมื่อใด:

ชื่อฟังก์ชัน
type hints
docstring
return shape

ตัวอย่าง tool ที่เรียก API จริง:

import requests

def search_hotels(city: str, check_in: str, check_out: str) -> dict:
    """Search hotel options for a city and date range."""
    response = requests.get(
        "https://api.example.com/hotels",
        params={
            "city": city,
            "check_in": check_in,
            "check_out": check_out,
        },
        timeout=10,
    )
    response.raise_for_status()
    return response.json()

ข้อควรทำ:

เขียน docstring ให้ชัดว่า tool ทำอะไร
กำหนด input/output ให้สม่ำเสมอ
handle error จาก API ภายนอก
test tool แยกจาก agent ก่อนนำไปใช้จริง

ADK ยังมีเครื่องมือในตัว เช่น google_search และ code execution รวมถึงรองรับ Model Context Protocol หรือ MCP สำหรับเชื่อมต่อ tool server ภายนอก คุณยังสามารถ wrap ไลบรารีอย่าง LangChain, LlamaIndex หรือใช้เอเจนต์อื่นเป็น tool ได้

3. ระบบเอเจนต์หลายตัว

เอเจนต์ตัวเดียวเหมาะกับงานง่าย แต่ถ้างานซับซ้อน คุณสามารถแยกความรับผิดชอบเป็นหลายเอเจนต์ เช่น:

เอเจนต์ค้นเที่ยวบิน
เอเจนต์ค้นโรงแรม
เอเจนต์สรุปแผนเดินทาง
เอเจนต์ตรวจสอบงบประมาณ

ADK มี workflow agents สำหรับควบคุม flow แบบกำหนดได้:

SequentialAgent: รันซับเอเจนต์ตามลำดับ
ParallelAgent: รันหลายซับเอเจนต์พร้อมกัน
LoopAgent: ทำซ้ำจนกว่าจะเข้าเงื่อนไข

รูปแบบนี้เหมาะกับงานที่ต้องแบ่งขั้นตอนชัดเจน เช่น research pipeline, customer support routing หรือ travel planning

4. Runner

ในการใช้งานจริง คุณไม่ได้เรียกเอเจนต์โดยตรงตลอดเวลา แต่ใช้ Runner เป็นเอนจินประมวลผลของ ADK

Runner ดูแลเรื่อง:

session
event flow
state update
model call
tool invocation
orchestration ระหว่างเอเจนต์

ช่วงพัฒนา คุณสามารถใช้ CLI เพื่อลองเอเจนต์ได้ทันที:

adk run

คำสั่งนี้เปิด interactive terminal session

หรือใช้:

adk web

คำสั่งนี้เปิด UI บน browser เพื่อคุยกับเอเจนต์และดูแต่ละ step ระหว่าง execution เหมาะมากสำหรับ debug ว่าเอเจนต์เลือก tool ถูกหรือไม่ และ input/output ของ tool เป็นอย่างไร

5. การประเมินผลและการปรับใช้

ADK มีเครื่องมือสำหรับ evaluation เพื่อให้คุณตรวจสอบได้ว่าเอเจนต์ทำงานตาม expected path และ expected response หรือไม่ ไม่ใช่ดูแค่คำตอบสุดท้าย

ควรประเมินเมื่อคุณเปลี่ยน:

prompt / instruction
tool
model
workflow
routing logic

สำหรับ deployment มีสองแนวทางหลัก:

ใช้ Vertex AI Agent Engine ถ้าต้องการ managed runtime ที่ scale ได้
containerize แล้ว deploy ไปยัง Cloud Run หรือ container platform อื่น ถ้าต้องการ portability มากกว่า

ตัวอย่าง: สร้างระบบเอเจนต์วางแผนทริป

ตัวอย่างนี้มี coordinator หนึ่งตัว และ sub-agent สองตัวสำหรับค้นเที่ยวบินและโรงแรม

from google.adk.agents import Agent

def search_flights(origin: str, destination: str, date: str) -> dict:
    """Search flight options for a route and date."""
    # เรียก flights API จริงของคุณตรงนี้
    return {
        "origin": origin,
        "destination": destination,
        "date": date,
        "options": [],
    }

def search_hotels(city: str, check_in: str, check_out: str) -> dict:
    """Search hotel options near the destination."""
    # เรียก hotels API จริงของคุณตรงนี้
    return {
        "city": city,
        "check_in": check_in,
        "check_out": check_out,
        "options": [],
    }

flights = Agent(
    name="flight_agent",
    model="gemini-2.0-flash",
    instruction="Find flight options for the user's route and dates.",
    tools=[search_flights],
)

hotels = Agent(
    name="hotel_agent",
    model="gemini-2.0-flash",
    instruction="Find hotel options near the destination.",
    tools=[search_hotels],
)

trip_planner = Agent(
    name="trip_planner",
    model="gemini-2.0-flash",
    instruction="Plan a trip. Delegate flight and hotel lookups to your sub-agents.",
    sub_agents=[flights, hotels],
)

flow โดยทั่วไปคือ:

ผู้ใช้ถามให้วางแผนทริป
trip_planner วิเคราะห์คำขอ
ส่งงานค้นเที่ยวบินให้ flight_agent
ส่งงานค้นโรงแรมให้ hotel_agent
รวมผลลัพธ์และตอบผู้ใช้

ตอน debug ให้เริ่มจาก adk web เพื่อดูว่า coordinator ส่งงานไปยัง sub-agent ถูกต้องหรือไม่ และ tool ได้ input ตามที่คาดไว้หรือเปล่า

ADK vs OpenAI Agents SDK

ทั้ง Google ADK และ OpenAI Agents SDK เป็นเฟรมเวิร์กสำหรับสร้างเอเจนต์แบบ code-first มีแนวคิดเรื่อง tools, handoffs / delegation และ tracing คล้ายกัน จุดต่างหลักคือ ecosystem ที่แต่ละตัวเน้น

	Google ADK	OpenAI Agents SDK
Default model	Gemini ผ่าน Vertex AI	OpenAI models
โมเดลอื่น	Vertex AI Model Garden, LiteLLM	LiteLLM และอื่น ๆ
ภาษา	Python, Java, Go, TypeScript	Python, JavaScript/TypeScript
Multi-agent	Sub-agents + Sequential, Parallel, Loop workflow agents	Agents-as-tools และ handoffs
Managed runtime	Vertex AI Agent Engine	Bring your own
Tool protocol	MCP, built-in tools, function tools	MCP, function tools

ถ้าทีมของคุณอยู่บน Google Cloud อยู่แล้ว ADK + Vertex AI เป็นตัวเลือกที่เข้ากันดี ถ้าสต็กหลักเป็น OpenAI อยู่แล้ว OpenAI Agents SDK อาจเหมาะกว่า ทั้งสองรองรับ MCP จึงสามารถแชร์ tool server บางส่วนร่วมกันได้

ควรใช้ ADK เมื่อใด

เลือกใช้ ADK เมื่อ:

คุณสร้างระบบบน Google Cloud และต้องการใช้ Gemini กับ Vertex AI Agent Engine
คุณต้องการ orchestration ของหลายเอเจนต์แบบชัดเจน
งานต้องใช้ workflow แบบ sequential, parallel หรือ loop
คุณต้องการ evaluation ในเฟรมเวิร์ก ไม่ใช่เพิ่มทีหลัง
คุณต้องการสลับโมเดลผ่าน Vertex AI Model Garden หรือ LiteLLM

อาจยังไม่จำเป็นต้องใช้ ADK ถ้า:

use case เป็น prompt เดียว + function call ง่าย ๆ
ไม่มี workflow หลายขั้นตอน
ไม่ต้องการ multi-agent
ทีมอยู่กับ ecosystem อื่นแบบชัดเจน

เฟรมเวิร์กเอเจนต์ช่วยเพิ่มโครงสร้าง แต่โครงสร้างก็มีต้นทุน ถ้างานเล็กมาก การเรียก LLM API ตรง ๆ อาจง่ายกว่า

Apidog ช่วยตรงไหน: ทดสอบและจำลอง API ที่เอเจนต์เรียกใช้

ADK จัดการ logic ของเอเจนต์ แต่ไม่ได้แทนที่การทดสอบ API ภายนอกที่ tool ของคุณเรียกใช้ และนี่คือจุดที่ควรแยกมาทดสอบตั้งแต่ต้น

ในระบบเอเจนต์จริง tool มักจะเรียกสิ่งเหล่านี้:

LLM endpoint
payment API
internal microservice
search service
CRM / ticketing API
third-party data provider

ถ้า API เหล่านี้ส่ง response ผิดรูปแบบ เอเจนต์จะ reason ต่อจากข้อมูลผิด และ debug ยาก เพราะปัญหาอาจดูเหมือน prompt ไม่ดี ทั้งที่จริงคือ contract ของ API เปลี่ยน

Apidog ไม่ใช่เฟรมเวิร์กเอเจนต์และไม่ได้แทนที่ ADK แต่ทำงานในเลเยอร์ API ที่ tool ของเอเจนต์พึ่งพา

วิธีใช้ Apidog ระหว่างพัฒนา ADK

1. Mock endpoint ที่ tool เรียกใช้

ตั้งค่า mock API สำหรับ endpoint ที่ยังไม่พร้อม หรือ endpoint ที่ไม่อยากเรียกจริงระหว่างพัฒนา เช่น LLM, payment หรือ third-party API

ข้อดี:

พัฒนาเอเจนต์ได้โดยไม่ต้องรอ backend
ลดค่า token หรือค่า API call
ทดสอบ error case ได้ง่าย
ควบคุม response ได้คงที่

ตัวอย่าง tool ที่ชี้ไปยัง mock endpoint:

import os
import requests

def get_customer_profile(customer_id: str) -> dict:
    """Fetch a customer profile by customer ID."""
    base_url = os.environ["CUSTOMER_API_BASE_URL"]

    response = requests.get(
        f"{base_url}/customers/{customer_id}",
        timeout=10,
    )
    response.raise_for_status()
    return response.json()

ระหว่าง development ให้ CUSTOMER_API_BASE_URL ชี้ไปยัง mock server ใน Apidog ส่วน staging / production ค่อยเปลี่ยนเป็น endpoint จริง

2. ตรวจ response schema ก่อนให้เอเจนต์ใช้

ใช้ การยืนยัน API เพื่อตรวจว่า response มี field ที่เอเจนต์ต้องใช้ เช่น:

{
  "customer_id": "cus_123",
  "name": "Jane Doe",
  "tier": "gold",
  "open_tickets": 2
}

ถ้า tool คาดหวัง tier แต่ API เปลี่ยนเป็น plan เอเจนต์อาจตอบผิดทันที การทดสอบ contract จะจับปัญหานี้ก่อนเข้าสู่ agent transcript

3. แยก environment keys

เก็บ key และ base URL แยกตาม environment:

dev
staging
production

การทำแบบนี้ช่วยให้ tool function เดิมทำงานได้ทุก stage โดยเปลี่ยนแค่ environment config ไม่ต้องแก้โค้ด

4. ทดสอบ tool แยกจาก agent

ก่อนนำ tool เข้า tools=[...] ให้ทดสอบ API call ตรง ๆ ก่อน:

def test_get_customer_profile():
    result = get_customer_profile("cus_123")

    assert "customer_id" in result
    assert "tier" in result
    assert isinstance(result["open_tickets"], int)

แนวคิดคืออย่า debug พร้อมกันทั้ง agent, prompt, model และ API ให้แยก API contract ออกมาก่อน

ถ้าต้องการแนวทางเฉพาะสำหรับเอเจนต์ ดูวิธี ทดสอบการเรียกใช้เครื่องมือของ AI เอเจนต์ ก่อนเกิดปัญหาใน production หรือ ดาวน์โหลด Apidog แล้วเริ่ม mock endpoint แรกได้ภายในไม่กี่นาที

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

Google ADK ฟรีและโอเพนซอร์สหรือไม่

ใช่ ADK เป็นโอเพนซอร์สใน repository บน GitHub ภายใต้ Apache license คุณสามารถรันในเครื่องได้โดยไม่มีค่าใช้จ่าย แต่ยังต้องจ่ายค่าโมเดลที่เรียกใช้ และค่า managed runtime หาก deploy ไปยังบริการอย่าง Vertex AI Agent Engine

ADK ทำงานกับ Gemini เท่านั้นหรือไม่

ไม่ ADK ได้รับการปรับให้เหมาะกับ Gemini และ Vertex AI แต่ยังเป็น model-agnostic ผ่าน Vertex AI Model Garden และ LiteLLM คุณสามารถใช้โมเดลจาก Anthropic, Meta, Mistral และผู้ให้บริการอื่นได้ Gemini เป็นค่าเริ่มต้นที่เข้ากันดีที่สุด แต่ไม่ใช่ข้อบังคับ

ADK รองรับภาษาอะไรบ้าง

Python เป็นภาษาแรกและยังมีความสมบูรณ์ที่สุด Google ได้เพิ่ม Java แล้ว และมี Go กับ TypeScript ตามมา หากต้องการ feature coverage ที่กว้างที่สุดตอนนี้ Python ยังเป็นตัวเลือกที่ปลอดภัยที่สุด

ควร debug เอเจนต์ ADK อย่างไร

เริ่มจาก adk web เพื่อดู execution step, tool call, input และ output ของแต่ละ tool จากนั้นแยกทดสอบ tool function ด้วย unit test หรือ API test อย่าแก้ prompt ก่อนถ้ายังไม่มั่นใจว่า API response ถูกต้อง

ฉันจะทดสอบ API ที่เอเจนต์ ADK พึ่งพาได้อย่างไร

ทดสอบ API แยกจากเอเจนต์ก่อน จำลอง endpoint ที่ยังไม่พร้อมหรือไม่อยากเรียกจริง แล้วตรวจ response schema ให้ตรงกับสิ่งที่ tool คาดหวัง Apidog รองรับทั้ง mock และ assertion คู่มือ ทดสอบ ChatGPT API ใช้ pattern เดียวกันกับ LLM endpoint ที่ tool ของคุณอาจเรียกใช้

สรุป

Google ADK เป็นเฟรมเวิร์กที่เหมาะสำหรับสร้างเอเจนต์และระบบหลายเอเจนต์ โดยเฉพาะถ้าคุณใช้ Gemini, Vertex AI หรือ Google Cloud อยู่แล้ว วิธีเริ่มที่ practical คือสร้างเอเจนต์หนึ่งตัว เพิ่ม tool ไม่กี่ตัว รันด้วย adk web เพื่อดูพฤติกรรม แล้วค่อยขยายเป็น sub-agents หรือ deploy ไปยัง managed runtime

เมื่อเอเจนต์ของคุณเริ่มพึ่งพา API ภายนอกมากขึ้น ให้ทดสอบ API เหล่านั้นเป็น contract แยกต่างหาก จำลอง response, ตรวจ schema และแยก environment ให้ชัดเจน นั่นคือเลเยอร์ที่ Apidog ช่วยจัดการ และมักเป็นจุดเริ่มต้นของพฤติกรรมเอเจนต์ที่ดูเหมือนไม่แน่นอน

LangGraph คืออะไร? คู่มือสร้าง Stateful AI Agent

Thanawat Wongchai — Thu, 25 Jun 2026 08:07:27 +0000

โค้ดเอเจนต์ส่วนใหญ่เริ่มต้นง่าย ๆ แล้วเริ่มพังเมื่อเวิร์กโฟลว์ต้องวนซ้ำ แยกสาขา หรือหยุดรอมนุษย์ LangGraph แก้ปัญหานี้ด้วยการจำลองเอเจนต์เป็นกราฟที่มีสถานะร่วมกัน ทำให้การวนซ้ำและการกำหนดเส้นทางเป็นโครงสร้างหลัก ไม่ใช่ชุด if ที่ซ้อนกัน คู่มือนี้อธิบายว่า LangGraph คืออะไร ควรใช้เมื่อใด และ การทดสอบ API มีบทบาทอย่างไรเมื่อเอเจนต์เรียกใช้บริการจริง

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

LangGraph คืออะไร

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

pip install -U langgraph

แนวคิดหลักคืออธิบายเอเจนต์เป็นกราฟ:

โหนด (Nodes) ทำงาน เช่น เรียกโมเดล รันเครื่องมือ หรือแปลงข้อมูล
เส้นเชื่อม (Edges) ตัดสินใจว่าจะรันโหนดใดต่อ
สถานะ (State) เป็นข้อมูลร่วมที่ไหลผ่านทุกโหนด
วงจร (Cycles) ทำให้เอเจนต์วนกลับไปคิดหรือเรียกเครื่องมือซ้ำได้

ถ้า chain แบบเดิมคือ pipeline เช่น ขั้นตอน 1 → 2 → 3 → จบ LangGraph คือ state machine ที่สามารถเลือกเส้นทาง วนกลับ หรือหยุดรอ input เพิ่มได้ เหมาะกับเอเจนต์ที่ทำงานแบบ “คิด → ทำ → สังเกต → คิดอีกครั้ง”

ปัญหาที่ LangGraph แก้ไข

เวิร์กโฟลว์ของเอเจนต์มักไม่เป็นเส้นตรง เอเจนต์ต้องเรียกเครื่องมือ ดูผลลัพธ์ แล้วตัดสินใจว่าจะทำต่อหรือหยุด หากเขียนทั้งหมดด้วย if/else และ loop เอง โค้ดจะอ่านยากและทดสอบยาก

LangGraph ช่วยจัดการสิ่งเหล่านี้:

การวนซ้ำพร้อมเงื่อนไขหยุด: เรียกเครื่องมือซ้ำจนกว่างานจะเสร็จ โดยไม่วนไม่รู้จบ
การแยกสาขาตามสถานะ: ส่งงานไปยังโหนดที่ต่างกันตามผลลัพธ์จากโมเดล
Persistence: บันทึกสถานะเพื่อ resume หลัง timeout, crash หรือ restart
Human-in-the-loop: หยุดให้มนุษย์ตรวจสอบหรือแก้ไขสถานะก่อนทำต่อ
Streaming: ส่ง token และ update ระหว่างทาง ไม่ต้องรอผลลัพธ์สุดท้ายเท่านั้น

ผลลัพธ์คือคุณได้ runtime สำหรับเอเจนต์ที่ทนทานกว่า script เชิงเส้น โดยเฉพาะงานที่กินเวลาหลายนาทีหรือหลายชั่วโมง

แนวคิดหลัก: กราฟ สถานะ โหนด เส้นเชื่อม

LangGraph ประกอบด้วย 4 ส่วนหลัก

1. State

State คือออบเจกต์ที่แชร์ระหว่างทุกโหนด คุณกำหนด schema ได้ เช่น TypedDict หรือใช้ schema ที่มีให้แล้วอย่าง MessagesState สำหรับเก็บรายการข้อความแชท

2. Nodes

Node คือฟังก์ชันที่รับ state ปัจจุบัน แล้วคืนค่า update บางส่วน

3. Edges

Edge เชื่อมโหนดเข้าด้วยกัน:

add_edge() ใช้สำหรับเส้นทางคงที่ เช่น A → B
add_conditional_edges() ใช้สำหรับ routing ตาม state เช่น ถ้าโมเดลเรียก tool ให้ไป node tools ไม่เช่นนั้นจบ

4. START และ END

START และ END เป็น marker พิเศษสำหรับจุดเริ่มต้นและจุดสิ้นสุดของกราฟ

ตัวอย่างโครงสร้างพื้นฐาน:

from langgraph.graph import StateGraph, START, END, MessagesState

def call_model(state: MessagesState):
    response = model.invoke(state["messages"])
    return {"messages": [response]}

def should_continue(state: MessagesState) -> str:
    last = state["messages"][-1]
    return "tools" if last.tool_calls else END

builder = StateGraph(MessagesState)

builder.add_node("model", call_model)
builder.add_node("tools", tool_node)

builder.add_edge(START, "model")
builder.add_conditional_edges("model", should_continue)
builder.add_edge("tools", "model")   # loop back

graph = builder.compile()

จุดสำคัญคือบรรทัดนี้:

builder.add_edge("tools", "model")

หลังจากรัน tool แล้ว control จะวนกลับไปที่ model เพื่อให้โมเดลตัดสินใจต่อว่าจะเรียก tool เพิ่มหรือจบงาน นี่คือ use case หลักที่ LangGraph ถูกออกแบบมาเพื่อรองรับ

การคงอยู่ของข้อมูลและ Human-in-the-loop

ถ้าต้องการให้กราฟ resume ได้ ให้ compile พร้อม checkpointer จากนั้นส่ง thread_id ตอนเรียกใช้งาน LangGraph จะบันทึก snapshot ของ state หลังแต่ละ step และกู้คืน checkpoint ล่าสุดในการเรียกครั้งถัดไป

from langgraph.checkpoint.memory import InMemorySaver

graph = builder.compile(checkpointer=InMemorySaver())

config = {
    "configurable": {
        "thread_id": "user-42"
    }
}

graph.invoke(
    {"messages": [user_message]},
    config
)

InMemorySaver เหมาะสำหรับ development ถ้าต้องการให้รอดจาก process restart ให้ใช้ checkpointer ที่ backed ด้วย database เช่น SQLite สำหรับ server เดี่ยว หรือ Postgres สำหรับหลาย instance

เมื่อ state ถูกบันทึกไว้ คุณสามารถสร้าง workflow แบบ human-in-the-loop ได้ เช่น:

รันกราฟจนถึงจุดที่ต้องอนุมัติ
แสดง state ปัจจุบันให้ผู้ใช้ตรวจสอบ
ให้ผู้ใช้แก้ไขหรือยืนยัน
Resume จาก checkpoint เดิม

รูปแบบนี้เหมาะกับงานเช่น approval flow, manual correction หรือขั้นตอน “ยืนยันก่อนส่งจริง”

LangGraph ยังรองรับ streaming เพื่อให้ UI แสดง token หรือ node update ระหว่างรัน แทนที่จะรอ response ตอนจบเพียงครั้งเดียว

LangGraph เกี่ยวข้องกับ LangChain อย่างไร

LangChain คือชุดเครื่องมือที่กว้างกว่า เช่น model wrappers, prompt templates, retrievers, document loaders และ integrations จำนวนมาก ส่วน LangGraph คือ orchestration layer สำหรับควบคุม workflow ของเอเจนต์ที่มีสถานะและมีวงจร

คุณไม่จำเป็นต้องใช้ LangChain เพื่อใช้ LangGraph คุณสามารถกำหนด state, node และ edge เอง แล้วเรียก model client ใดก็ได้ภายใน node แต่หลายทีมใช้ร่วมกันเพราะ abstraction ของ LangChain ช่วยลด boilerplate สำหรับ model และ tools

หัวข้อ	LangChain	LangGraph
บทบาท	ส่วนประกอบและ integrations	Orchestration และ runtime
Control flow	Chain เชิงเส้น	Graph ที่มีวงจรและสาขา
State ในตัว	จำกัด	แชร์ได้ มี schema และทนทาน
Persistence / Resume	ไม่ใช่จุดเน้นหลัก	Checkpointers + thread ID
เหมาะกับ	การรวม model และ tools	เอเจนต์หลายขั้นตอนที่มี state

ข้อสังเกตสำหรับผู้ใช้ปัจจุบัน: LangGraph v1.0 ซึ่งเสถียรตั้งแต่ปลายปี 2025 ได้ย้าย helper agent ที่สร้างไว้ล่วงหน้าไปที่ langchain.agents.create_agent ดังนั้นควรตรวจสอบเวอร์ชันที่ติดตั้งและ เอกสารอ้างอิงทางการ ก่อนคัดลอกตัวอย่างเก่า ๆ

ถ้าต้องการภาพรวมการสร้างเอเจนต์แบบกำหนดเอง ดูเพิ่มเติมได้ที่ การสร้าง AI เอเจนต์แบบกำหนดเอง

แพลตฟอร์มและสตูดิโอของ LangGraph

ไลบรารีโอเพนซอร์สคือแกนหลัก แต่มีเครื่องมือเสริมที่ช่วยตอน debug และ deploy

LangGraph Studio

LangGraph Studio คือ IDE สำหรับเอเจนต์แบบภาพ ใช้ดูกราฟ รัน workflow และ inspect state ในแต่ละโหนด เหมาะมากเมื่อกราฟมี loop และ conditional routing เพราะคุณเห็น path ที่เอเจนต์เลือกจริง แทนที่จะไล่อ่าน log ทีละบรรทัด

LangGraph Platform

LangGraph Platform เป็นส่วนสำหรับ production deployment เช่น API endpoint สำหรับเอเจนต์, persistence ในตัว และตัวเลือก hosting ตั้งแต่ self-hosted ไปจนถึง managed cloud คุณไม่จำเป็นต้องใช้เพื่อเริ่มต้นกับ LangGraph แต่มีประโยชน์เมื่อ workflow เริ่มต้องการ infrastructure สำหรับ production

เมื่อใดควรใช้ LangGraph

ใช้ LangGraph เมื่อ workflow ของเอเจนต์มี control flow จริง เช่น:

งานเป็น loop ไม่ใช่ลำดับตรง ๆ เช่น call tool → inspect → retry
ต้อง branch ตามการตัดสินใจของโมเดล
งานใช้เวลานานและต้อง resume หลัง crash หรือ timeout
ต้องมีมนุษย์อนุมัติหรือแก้ไขระหว่างทาง
มีหลาย actor หรือหลาย sub-agent ที่ใช้ state ร่วมกัน

ไม่จำเป็นต้องใช้ LangGraph ถ้างานเป็นการเรียกโมเดลครั้งเดียวหรือ chain สั้น ๆ เช่น “สรุปข้อความนี้” เพราะกราฟจะเพิ่ม overhead โดยไม่จำเป็น

การทดสอบ API และ Mocking มีบทบาทอย่างไร

เอเจนต์ LangGraph จะเชื่อถือได้เท่ากับ API ที่มันเรียกใช้เท่านั้น เช่น LLM endpoint, search API, CRM, internal backend หรือ tool API อื่น ๆ LangGraph ช่วยจัดการ workflow แต่ไม่ได้ทดสอบ API เหล่านั้น นี่คือจุดที่ Apidog เข้ามาช่วยในขั้นตอน development และ testing

มี 2 ปัญหาที่ควรจัดการตั้งแต่ต้น

1. Mock API เพื่อลดต้นทุนและทำให้ test repeatable

ถ้ารัน API จริงทุกครั้ง คุณจะเจอปัญหา token cost, rate limit และผลลัพธ์ที่ไม่ deterministic ระหว่างพัฒนา logic ของกราฟ ให้ mock endpoint ที่เอเจนต์พึ่งพาแทน

ตัวอย่างแนวทาง:

ระบุ tool API ทั้งหมดที่ node เรียกใช้
สร้าง mock response สำหรับแต่ละ endpoint
ให้ test environment ชี้ไปยัง mock server
ทดสอบ routing ของกราฟโดยไม่เรียก API จริง

คุณสามารถใช้ การจำลอง API เพื่อให้ endpoint ส่ง response ที่แน่นอนและรวดเร็ว เหมาะสำหรับทดสอบว่า conditional edge เลือก path ถูกต้องหรือไม่

2. ใช้ API assertions เพื่อตรวจ schema drift

Node ของคุณมักคาดหวัง response shape ที่แน่นอน เช่น field name, status code หรือ nested object ถ้า API เปลี่ยน field แบบเงียบ ๆ conditional edge อาจอ่านค่าผิด แล้วทำให้เอเจนต์วนซ้ำหรือหยุดผิดจุด

ให้กำหนด contract ด้วย API assertions เช่น:

status code ต้องเป็น 200
response ต้องมี field ที่ node ใช้
type ของ field ต้องตรงตาม schema
error response ต้องอยู่ในรูปแบบที่กราฟจัดการได้

สำหรับ workflow ที่เน้น AI agent โดยตรง ดู ชุดทดสอบ Apidog สำหรับ AI เอเจนต์ เพื่อวางกระบวนการ mock, assert และทดสอบ API ที่อยู่เบื้องหลังเอเจนต์

ข้อสำคัญ: Apidog ไม่ได้ orchestrate agent แทน LangGraph แต่ใช้ทดสอบและจำลอง API ที่ agent เรียกใช้

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

LangGraph มาแทนที่ LangChain ใช่หรือไม่?

ไม่ใช่ LangGraph คือ orchestration runtime สำหรับ workflow ที่มี state และ loop ส่วน LangChain คือชุด components และ integrations ที่กว้างกว่า คุณใช้ LangGraph โดยไม่ใช้ LangChain ได้ หรือใช้ร่วมกันก็ได้

ต้องรู้ LangChain ก่อนเริ่มใช้ LangGraph หรือไม่?

ไม่จำเป็น คุณเริ่มจาก StateGraph เพิ่ม node และ edge แล้วเรียก model client ที่ต้องการภายใน node ได้เลย LangChain ช่วยลด boilerplate แต่ไม่ใช่ข้อบังคับ

LangGraph จำ state ระหว่างการเรียกใช้ได้อย่างไร?

ผ่าน checkpointer เมื่อ compile graph พร้อม checkpointer และส่ง thread_id LangGraph จะบันทึก snapshot ของ state หลังแต่ละ step และกู้คืน checkpoint ล่าสุดในการเรียกครั้งถัดไป

จะทดสอบ API ที่เอเจนต์เรียกได้อย่างไร?

แยกการทดสอบ API ออกจากกราฟ Mock LLM endpoint และ tool endpoint เพื่อให้ test เร็วและคุมผลลัพธ์ได้ จากนั้นใช้ assertions ตรวจ response schema เพื่อป้องกัน field เปลี่ยนแล้วทำให้ node ทำงานผิด ดูตัวอย่างเพิ่มเติมได้ในคู่มือ ทดสอบ ChatGPT API

สรุป

LangGraph เหมาะกับเอเจนต์ที่ต้องวนซ้ำ แยกสาขา เก็บ state และหยุดรอมนุษย์ โครงสร้างหลักคือ graph, state, node และ edge ส่วน checkpointer ช่วยให้ resume และสร้าง workflow แบบ human-in-the-loop ได้

เมื่อเอเจนต์เริ่มเรียก API จริง ให้แยกการทดสอบ API ออกจาก orchestration layer ใช้ mock เพื่อลดต้นทุนและทำให้ test predictable และใช้ assertions เพื่อป้องกัน schema drift คุณสามารถทดสอบและจำลอง API เหล่านั้นใน Apidog และ ดาวน์โหลด Apidog เพื่อเริ่มสร้าง mock endpoint และตรวจ response ก่อนให้เอเจนต์เรียกใช้จริง

OpenAI AgentKit คืออะไร

Thanawat Wongchai — Thu, 25 Jun 2026 07:40:55 +0000

OpenAI AgentKit คือชุดเครื่องมือสำหรับสร้าง ปรับใช้ และวัดผล AI agent บนแพลตฟอร์มของ OpenAI หากคุณเคยสร้าง agent เองและต้องดูแล orchestration, connector, prompt, eval script และ UI แยกกัน AgentKit คือแนวทางของ OpenAI ในการรวมชิ้นส่วนเหล่านี้ไว้ด้วยกัน บทความนี้สรุปว่า AgentKit มีอะไรบ้าง เหมาะกับใคร ควรเริ่มสร้างอย่างไรในปี 2026 และเครื่องมือทดสอบ API อย่าง Apidog ควรอยู่ตรงไหนเมื่อ agent ของคุณเริ่มเรียกใช้บริการภายนอก

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

AgentKit คืออะไร

OpenAI เปิดตัว AgentKit ในงาน DevDay เมื่อวันที่ 6 ตุลาคม 2025 โดย AgentKit ไม่ใช่ผลิตภัณฑ์เดี่ยว แต่เป็นชุดส่วนประกอบที่ทำงานบน OpenAI API และ OpenAI Agents SDK เป้าหมายคือย่นระยะจาก “มีไอเดีย agent” ไปสู่ “มี agent ที่ใช้งานกับผู้ใช้จริงได้”

ก่อนมี AgentKit การสร้าง agent มักต้องทำหลายอย่างเอง เช่น:

เขียน orchestration logic
สร้าง connector สำหรับแต่ละแหล่งข้อมูล
ทำ evaluation pipeline เอง
ปรับ prompt ด้วยมือ
สร้าง UI แชทหรือ front-end สำหรับใช้งานจริง

AgentKit รวมเครื่องมือสำหรับงานเหล่านี้ไว้ในชุดเดียว แต่มีประเด็นสำคัญในปี 2026: OpenAI ประกาศเมื่อวันที่ 3 มิถุนายน 2026 ว่าจะยุติการใช้งาน AgentKit บางส่วน ได้แก่ Agent Builder และ Evals ดังนั้นหากคุณต้องการสร้างระบบที่ดูแลต่อได้ระยะยาว เส้นทางหลักควรเป็น Agents SDK มากกว่า visual workflow

ส่วนประกอบของ AgentKit

AgentKit เปิดตัวพร้อมส่วนประกอบหลัก 4 ส่วน แต่ละส่วนมีบทบาทและสถานะต่างกันในปี 2026

Agent Builder

Agent Builder คือ workspace แบบ visual สำหรับออกแบบ workflow ของ agent แบบหลายขั้นตอน คุณสามารถลากและวาง node, เชื่อม flow, preview การรันด้วย input จริง และ publish workflow snapshot แบบมี version ได้

สำหรับนักพัฒนา จุดสำคัญคือ Agent Builder ไม่ได้แยกจากโค้ดโดยสิ้นเชิง เพราะมีแท็บ Agents SDK ที่ส่งออก workflow เป็นโค้ด Python หรือ TypeScript ได้ คุณจึงใช้ visual builder เพื่อ prototype แล้วนำโค้ดไปต่อใน environment ของทีมได้

อย่างไรก็ตาม OpenAI กำลังยกเลิก Agent Builder โดยจะปิดแพลตฟอร์มวันที่ 30 พฤศจิกายน 2026 ตาม หน้าประกาศการยุติการใช้งาน ดังนั้นถ้าเริ่มโปรเจกต์ใหม่ ให้ใช้ Agent Builder เป็นเครื่องมือ prototype เท่านั้น และวางแผนย้าย workflow ไปยัง Agents SDK

ChatKit

ChatKit คือ UI แชทที่ฝังในแอปของคุณได้ แทนที่จะสร้าง chat interface เองตั้งแต่ศูนย์ คุณสามารถใส่ web component, ชี้ไปยัง workflow ID ที่ publish แล้ว และปรับแต่ง theme หรือ behavior ได้

ChatKit จัดการงานทั่วไปของ UI agent เช่น:

streaming response
thread
chat interaction
embedding ลงในผลิตภัณฑ์

ChatKit ยังใช้งานได้ และเป็นส่วนของ AgentKit ที่ได้รับผลกระทบน้อยจากการเปลี่ยนแปลงปี 2026

Connector Registry

Connector Registry คือพื้นที่สำหรับ admin ในการจัดการการเชื่อมต่อข้อมูลและเครื่องมือในผลิตภัณฑ์ของ OpenAI ทั้ง ChatGPT และ API

ตัวอย่าง connector ที่รองรับ ได้แก่:

Dropbox
Google Drive
SharePoint
Microsoft Teams
MCP server ของบุคคลที่สาม

แนวคิดคือให้องค์กรควบคุมได้ว่า agent เข้าถึงข้อมูลหรือเครื่องมือใดได้บ้างจากศูนย์กลางเดียว

ถ้าคุณต้องการเข้าใจฝั่ง MCP เพิ่มเติม อ่านคู่มือ เซิร์ฟเวอร์ MCP และ OpenAI Agents SDK

Evals และการเพิ่มประสิทธิภาพ

Evals เพิ่มความสามารถด้านการวัดคุณภาพของ agent เช่น:

dataset สำหรับทดสอบ
trace grading สำหรับให้คะแนนแต่ละขั้นตอนของ multi-agent run
prompt optimization อัตโนมัติ
การให้คะแนนเทียบกับโมเดลของบุคคลที่สาม ไม่จำกัดเฉพาะ OpenAI

แต่เช่นเดียวกับ Agent Builder, Evals กำลังถูกยุติการใช้งาน โดยจะเป็นแบบอ่านอย่างเดียวสำหรับผู้ใช้เดิมวันที่ 31 ตุลาคม 2026 และปิดตัววันที่ 30 พฤศจิกายน 2026

AgentKit เกี่ยวข้องกับ Agents SDK อย่างไร

ให้มอง AgentKit เป็นชุดเครื่องมือรอบ ๆ Agents SDK:

Agents SDK คือ framework ระดับโค้ดสำหรับกำหนด agent, tool, handoff และ guardrails
Agent Builder คือ visual layer ที่สร้าง workflow และ export เป็นโค้ด SDK ได้
ChatKit คือ layer สำหรับฝังประสบการณ์แชท
Connector Registry คือ layer สำหรับจัดการ connector และ MCP server
Evals คือ layer สำหรับวัดผลและปรับ prompt

เลเยอร์	คืออะไร	สถานะในปี 2026
Agents SDK	framework โค้ดสำหรับกำหนด agent, tool และ guardrails	ใช้งานอยู่ และเป็นเส้นทางระยะยาวที่แนะนำ
Agent Builder	workspace แบบ visual ที่ export โค้ด Agents SDK ได้	ถูกยกเลิก ปิดตัว 30 พ.ย. 2026
ChatKit	UI แชทที่ฝังได้ ผูกกับ workflow ID	ใช้งานได้
Connector Registry	admin panel สำหรับ connector และ MCP server	ใช้งานได้
Evals	trace grading และ prompt optimization	อ่านอย่างเดียว 31 ต.ค. 2026, ปิดตัว 30 พ.ย. 2026

คำแนะนำเชิงปฏิบัติ:

ถ้าคุณสร้างระบบสำหรับ production และต้อง maintain ต่อ: ใช้ Agents SDK
ถ้าคุณต้องการ prototype แบบ visual: ใช้ Agent Builder แล้ว export เป็นโค้ด
ถ้าต้องการ UI แชท: ใช้ ChatKit
ถ้าต้องควบคุม data access ในองค์กร: ใช้ Connector Registry

AgentKit เหมาะกับใคร

AgentKit เหมาะกับทีมที่ต้องการลดงานซ้ำในการสร้าง agent:

ทีม product ที่ต้องการ prototype agent เร็ว
ทีม engineering ที่ต้องการ framework สำหรับกำหนด agent และ tool แบบชัดเจน
องค์กรที่ต้องการควบคุม connector และ data access
ทีมที่ต้องการนำ agent ไปใช้งานผ่าน UI แชท

แต่เมื่อพิจารณาการยกเลิก Agent Builder และ Evals ในปี 2026 แนวทางที่ปลอดภัยสำหรับนักพัฒนาคือ:

เริ่มจาก Agents SDK และใช้ส่วนอื่นของ AgentKit เฉพาะเมื่อเหมาะกับ use case

ขั้นตอนการสร้าง agent ในระดับสูง

ไม่ว่าคุณจะเริ่มจาก visual builder หรือโค้ด ขั้นตอนหลักจะคล้ายกัน

1. กำหนดหน้าที่ของ agent

ตอบคำถามเหล่านี้ก่อน:

agent ต้องทำงานอะไร
ต้องใช้ข้อมูลจากที่ไหน
ต้องเรียก API หรือ service ใด
มีข้อจำกัดด้าน permission หรือ compliance หรือไม่

ตัวอย่างงานของ agent:

ค้นหาคำสั่งซื้อล่าสุดของลูกค้า
สรุป ticket จากระบบ support
ตรวจสอบสถานะ shipment
ดึงข้อมูลจาก CRM

2. ออกแบบ workflow

ถ้าใช้ Agent Builder คุณจะลาก node และเชื่อม flow

ถ้าใช้ Agents SDK คุณจะกำหนด agent, tool และ handoff ด้วยโค้ด เช่น:

// ตัวอย่างเชิงแนวคิด: กำหนด agent พร้อม tool
const supportAgent = {
  name: "support_agent",
  instructions: "ช่วยตอบคำถามลูกค้าจากข้อมูลคำสั่งซื้อ",
  tools: [getRecentOrders]
};

3. เพิ่ม guardrails

ควรเพิ่ม guardrails เพื่อจัดการความเสี่ยง เช่น:

ซ่อนหรือแจ้งเตือนข้อมูล PII
ตรวจจับ prompt injection
จำกัด tool ที่เรียกใช้ได้
validate input ก่อนส่งเข้า tool

OpenAI มี guardrails แบบ open-source ที่ใช้เป็น workflow node หรือ standalone library ได้

4. เชื่อมต่อข้อมูลและเครื่องมือ

Agent มักเรียกใช้เครื่องมือผ่าน:

function tool
HTTP API
MCP server
connector ที่องค์กรอนุญาต

จุดนี้คือส่วนที่ควรออกแบบ schema ให้ชัด เพราะโมเดลจะตัดสินใจเรียก tool จาก description และ parameter schema

5. ทดสอบและประเมินผล

ทดสอบอย่างน้อย 3 ระดับ:

ทดสอบ tool/API แยกจาก agent
ทดสอบ agent run ด้วย input จริง
ทดสอบ edge case เช่น API timeout, empty result, invalid response

6. ปรับใช้

ตัวเลือกหลักคือ:

ฝัง UI ด้วย ChatKit
รันโค้ด Agents SDK บน infrastructure ของคุณเอง
ใช้ Connector Registry เพื่อควบคุม data access

ตัวอย่างที่สมจริง: tool ที่ agent เรียกใช้

agent จะทำงานได้ดีเท่ากับ tool ที่มันเรียกใช้ได้ และ tool ส่วนใหญ่คือ HTTP API

สมมติคุณต้องการให้ agent ดึงคำสั่งซื้อล่าสุดของลูกค้า คุณอาจกำหนด tool schema แบบนี้:

{
  "type": "function",
  "name": "get_recent_orders",
  "description": "ค้นหาคำสั่งซื้อล่าสุดของลูกค้าด้วย ID ลูกค้า",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "ตัวระบุเฉพาะของลูกค้า"
      },
      "limit": {
        "type": "integer",
        "description": "จำนวนคำสั่งซื้อที่จะส่งคืน",
        "default": 5
      }
    },
    "required": ["customer_id"],
    "additionalProperties": false
  }
}

เมื่อโมเดลตัดสินใจเรียก get_recent_orders โค้ดของคุณจะรับ argument แล้วเรียก API จริง เช่น:

curl https://api.your-company.com/v1/customers/cus_8842/orders?limit=5 \
  -H "Authorization: Bearer $ORDERS_API_KEY" \
  -H "Content-Type: application/json"

จุดที่ต้องระวังคือ agent จะ reasoning ต่อจาก response ที่ API ส่งกลับมา ถ้า API:

ช้า
ล่ม
ส่ง field ผิดชื่อ
response ไม่ตรง schema
คืนข้อมูลว่างโดยไม่อธิบาย

agent ก็มีโอกาสตอบผิดหรือเลือก workflow ผิดได้

ดังนั้น API ที่เป็น tool ของ agent ควรถูก test และ mock ตั้งแต่ต้น ไม่ใช่รอจนเชื่อม agent เสร็จแล้วค่อยตรวจ

การทดสอบและ Mock API เข้ามามีบทบาทอย่างไร

Apidog ไม่ใช่ agent framework และไม่ได้สร้าง agent แทน AgentKit หรือ Agents SDK แต่ Apidog อยู่ใน layer ด้านล่าง: ใช้สำหรับทดสอบ mock และจัดทำเอกสาร API ที่ agent เรียกใช้

1. Mock API ก่อน backend พร้อม

ถ้า agent ต้องเรียก service คำสั่งซื้อ แต่ทีม backend ยังสร้างไม่เสร็จ คุณสามารถ สร้าง Mock API ที่คืน response ตาม schema ที่ตกลงกันไว้

สิ่งที่ควร mock:

success response
empty result
validation error
unauthorized
timeout หรือ slow response
field ที่ optional

ตัวอย่าง mock response:

{
  "customer_id": "cus_8842",
  "orders": [
    {
      "order_id": "ord_1001",
      "status": "shipped",
      "total": 1290,
      "currency": "THB"
    }
  ]
}

ข้อดีคือ frontend, agent logic และ backend contract พัฒนาไปพร้อมกันได้โดยไม่ต้องรอกัน

2. ตรวจว่า response ตรงกับสิ่งที่ agent คาดหวัง

API ที่คืน 200 OK แต่ field ผิดชื่ออันตรายกว่าการ fail ชัดเจน เพราะโมเดลอาจพยายาม reasoning จากข้อมูลที่ผิด

ควรเขียน กรณีทดสอบ API เพื่อตรวจอย่างน้อย:

status code
response schema
required fields
data type
error format
response time

ตัวอย่าง assertion ที่ควรมี:

pm.test("response has orders array", function () {
  pm.expect(pm.response.json().orders).to.be.an("array");
});

pm.test("order has required fields", function () {
  const order = pm.response.json().orders[0];
  pm.expect(order).to.have.property("order_id");
  pm.expect(order).to.have.property("status");
  pm.expect(order).to.have.property("total");
});

3. แยก environment และ secret

tool ของ agent มักต้องใช้ secret เช่น:

ORDERS_API_KEY=...
CRM_API_KEY=...
INTERNAL_API_TOKEN=...

ควรแยก environment อย่างน้อย:

local
dev
staging
production

และไม่ควร hardcode key ในโค้ด agent

คุณสามารถ ดาวน์โหลด Apidog แล้วนำ endpoint ของ tool เข้ามาใน project เพื่อทดสอบแยกจาก runtime ของ agent ได้

อ่านเพิ่มเติม: วิธีทดสอบการเรียกใช้เครื่องมือของ AI agent

Checklist สำหรับสร้าง agent ที่เรียก API ภายนอก

ใช้ checklist นี้ก่อนนำ agent ไปใช้งานจริง:

[ ] tool ทุกตัวมี JSON schema ชัดเจน
[ ] description ของ tool บอกว่าใช้เมื่อไรและไม่ควรใช้เมื่อไร
[ ] API ที่ tool เรียกมี mock response
[ ] มี test case สำหรับ success และ error
[ ] response schema ถูก validate
[ ] secret ไม่ถูก hardcode
[ ] แยก base URL ตาม environment
[ ] มี timeout และ retry policy
[ ] มี logging สำหรับ tool call
[ ] มี guardrails สำหรับข้อมูล sensitive

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

OpenAI AgentKit ฟรีหรือไม่

เครื่องมือของ AgentKit ทำงานบนการใช้งาน OpenAI API ของคุณ ดังนั้นค่าใช้จ่ายหลักคือค่า token ของโมเดลและค่า API/tool call ที่ agent สร้างขึ้น ไม่มี subscription แยกเฉพาะสำหรับ AgentKit ตามข้อมูลในบทความนี้ ควรตรวจสอบราคาปัจจุบันจากแพลตฟอร์มของ OpenAI เสมอ เพราะราคาโมเดลอาจเปลี่ยนได้

ความแตกต่างระหว่าง AgentKit กับ Agents SDK คืออะไร

Agents SDK คือ framework ระดับโค้ดสำหรับกำหนด agent, tool และ guardrails ส่วน AgentKit คือชุดเครื่องมือที่กว้างกว่า ซึ่งรวม Agent Builder, ChatKit, Connector Registry และ Evals ไว้รอบ SDK

เมื่อ Agent Builder และ Evals ถูกยุติการใช้งานในช่วงปลายปี 2026 เส้นทางที่คงทนสำหรับทีมวิศวกรคือ Agents SDK อ่านคู่มือเพิ่มเติมได้ที่ คู่มือ Agents SDK

Agent Builder กำลังจะถูกยกเลิกหรือไม่

ใช่ OpenAI ประกาศเมื่อวันที่ 3 มิถุนายน 2026 ว่าจะยกเลิก Agent Builder และ Evals โดยทั้งสองจะปิดตัววันที่ 30 พฤศจิกายน 2026 และ Evals จะเป็นแบบอ่านอย่างเดียววันที่ 31 ตุลาคม 2026

ChatKit ยังใช้งานได้ และ OpenAI แนะนำให้ย้าย workflow ที่เน้นโค้ดไปยัง Agents SDK ส่วน workflow ที่ใช้ภาษาธรรมชาติให้ใช้ Workspace Agents ใน ChatGPT

ฉันสามารถทดสอบ API ที่ agent ของ AgentKit เรียกใช้ได้หรือไม่

ได้ และควรทำ ทุก tool ที่ agent เรียกใช้คือ HTTP API ที่มี request และ response คุณควร mock API เหล่านั้นระหว่างพัฒนา ตรวจ response schema และจัดการ key แยกตาม environment แพลตฟอร์มอย่าง Apidog ช่วยจัดการงานเหล่านี้ก่อนที่ agent จะไปถึงผู้ใช้จริง

สรุป

AgentKit ช่วยให้นักพัฒนา OpenAI สร้าง agent ได้เร็วขึ้นผ่าน Agent Builder, ChatKit, Connector Registry และ Evals แต่ในปี 2026 Agent Builder และ Evals กำลังถูกยุติการใช้งาน ดังนั้นทีมวิศวกรควรลงทุนกับ Agents SDK เป็นหลัก และใช้ ChatKit หรือ Connector Registry เมื่อเหมาะกับงาน

ไม่ว่าคุณเลือกเส้นทางใด ความน่าเชื่อถือของ agent ขึ้นอยู่กับ API ที่มันเรียกใช้ จำลอง API ตั้งแต่ต้น ตรวจ response ให้ตรง schema และจัดการ secret อย่างเป็นระบบ Apidog ช่วยให้คุณทดสอบและ mock endpoint ของ tool ที่ agent พึ่งพาได้ในที่เดียว ก่อนนำ agent ไปใช้งานจริงกับผู้ใช้.