DEV Community: Thanawat Wongchai

Gemini 3.5 Flash-Lite เทียบกับ 3.6 Flash ควรเลือกรุ่นไหนดี?

Thanawat Wongchai — Wed, 22 Jul 2026 11:03:24 +0000

นี่คือแนวทางเลือกโมเดลแบบใช้งานได้จริง: เลือก Gemini 3.5 Flash-Lite สำหรับงานง่ายที่ต้องรันจำนวนมากและให้ความสำคัญกับต้นทุนหรือความเร็ว เช่น การจัดหมวดหมู่ การดึงข้อมูล การตอบแชทสั้น คำตอบ RAG และการเติมข้อความอัตโนมัติ เลือก Gemini 3.6 Flash เมื่องานต้องการคุณภาพสูงกว่า เช่น เอเจนต์หลายขั้นตอน การใช้เครื่องมือ การเขียนโค้ด การใช้งานคอมพิวเตอร์ หรือคำตอบที่ผิดพลาดแล้วมีต้นทุนสูง

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

ทั้งสองโมเดลเปิดตัวใน Google's Flash-tier refresh เมื่อวันที่ 21 กรกฎาคม 2026 และรองรับอินพุตสูงสุด 1 ล้านโทเค็นเหมือนกัน ความแตกต่างหลักคือจุดแลกเปลี่ยนระหว่างต้นทุน ความเร็ว และความสามารถในการให้เหตุผล

หมายเหตุเรื่องชื่อ: โมเดลหลักขยับเป็น 3.6 แต่รุ่น Lite ยังคงเป็น 3.5 ดังนั้น gemini-3.5-flash-lite เทียบกับ gemini-3.6-flash เป็นชื่อโมเดลที่ถูกต้อง ไม่ใช่การพิมพ์ผิด

คำตอบสั้นๆ

ใช้ Flash-Lite เป็นค่าเริ่มต้นสำหรับงานแคบ ๆ ที่มีปริมาณสูง และเปลี่ยนเฉพาะคำขอที่ต้องใช้การให้เหตุผล เครื่องมือ หรือโค้ดไปเป็น 3.6 Flash

อย่าบังคับให้ทั้งแอปใช้โมเดลเดียว ให้กำหนด routing ตามประเภทงานแทน:

function selectModel(task) {
  if (task.requiresTools || task.requiresCode || task.isMultiStep) {
    return "gemini-3.6-flash";
  }

  return "gemini-3.5-flash-lite";
}

เริ่มจาก Flash-Lite แล้วเก็บผลการประเมิน คุณภาพ และความหน่วงของคำตอบ หากกลุ่มคำขอใดตอบไม่ครบหรือผิดพลาดบ่อย ค่อยยกระดับเฉพาะกลุ่มนั้นไปใช้ 3.6 Flash

ราคาและความเร็วแบบเปรียบเทียบ

คุณสมบัติ	Gemini 3.5 Flash-Lite	Gemini 3.6 Flash
รหัสโมเดล	`gemini-3.5-flash-lite`	`gemini-3.6-flash`
ราคาอินพุต	$0.30 / 1 ล้านโทเค็น	$1.50 / 1 ล้านโทเค็น
ราคาเอาต์พุต	$2.50 / 1 ล้านโทเค็น	$7.50 / 1 ล้านโทเค็น
ปริมาณงาน	~350 โทเค็นเอาต์พุต/วินาที	ไม่ได้เผยแพร่แยกต่างหาก
Context window	1 ล้านโทเค็น	1 ล้านโทเค็น
รุ่นฟรี	มี (จำกัดอัตรา)	มี (จำกัดอัตรา)

Flash-Lite ถูกกว่า 5 เท่าสำหรับอินพุต และถูกกว่า 3 เท่าสำหรับเอาต์พุต Google เผยแพร่ปริมาณงานของ Flash-Lite ที่ประมาณ 350 โทเค็นเอาต์พุตต่อวินาที ซึ่งเหมาะกับ UX ที่ไวต่อความหน่วง เช่น แชทหรือ autocomplete

Google ไม่ได้เผยแพร่ตัวเลขโทเค็นต่อวินาทีแยกต่างหากสำหรับ 3.6 Flash แต่ระบุว่า 3.6 Flash สร้างโทเค็นเอาต์พุตน้อยกว่า 3.5 Flash รุ่นก่อนหน้าประมาณ 17% ซึ่งช่วยให้งานหลายขั้นตอนจบได้เร็วขึ้นกว่าที่ดูจากราคาเพียงอย่างเดียว

ตรวจสอบอัตราปัจจุบันได้จากหน้าการกำหนดราคา Gemini API และรายละเอียดการกำหนดราคา Gemini 3.6 Flash

คุณภาพและเกณฑ์มาตรฐาน

บน Terminal-Bench 2.1 ซึ่งวัดงานเทอร์มินัลแบบ Agentic:

Flash-Lite ได้ 54
3.6 Flash ได้ 78.0

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

3.6 Flash ยังรายงานคะแนนดังนี้:

83.0 บน OSWorld-Verified สำหรับการใช้งานคอมพิวเตอร์
58.7% บน SWE-Bench Pro
49% บน DeepSWE v1.1

ดังนั้น ถ้างานต้องควบคุมเบราว์เซอร์หรือเดสก์ท็อป วิเคราะห์ stack trace แก้หลายไฟล์ หรือเรียกใช้เครื่องมือต่อเนื่อง 3.6 Flash เป็นตัวเลือกที่เหมาะกว่า

ในทางกลับกัน Flash-Lite ไม่ใช่โมเดลที่อ่อนแอ คะแนน Terminal-Bench 2.1 เพิ่มจาก 31 ในรุ่น Lite ก่อนหน้าเป็น 54 จุดประสงค์ของมันคือให้เหตุผลได้ดีพอในต้นทุนและความหน่วงที่เหมาะกับงานปริมาณมาก ดูแนวทางการวางตำแหน่งโมเดลได้จากหน้าโมเดล Flash และประกาศเปิดตัว

เลือกโมเดลตามประเภทงาน

ใช้ตารางนี้เป็น baseline ก่อนปรับจากผลประเมินของระบบจริง

งาน	โมเดลที่เหมาะสม
การจัดหมวดหมู่หรือดึงข้อมูลปริมาณมาก	Flash-Lite
ผู้ช่วยแชทและการตอบกลับสั้น	Flash-Lite
คำตอบ RAG จากบริบทที่ดึงมา	Flash-Lite
UX ที่ต้องการความหน่วงต่ำ เช่น autocomplete	Flash-Lite
ไปป์ไลน์ระดับการค้นหาที่ต้องรันทุกคำขอ	Flash-Lite
เอเจนต์หลายขั้นตอน	3.6 Flash
การใช้เครื่องมือและ function calling ต่อเนื่อง	3.6 Flash
การเขียนโค้ดและการตรวจทานโค้ด	3.6 Flash
การใช้งานคอมพิวเตอร์ผ่านเบราว์เซอร์หรือเดสก์ท็อป	3.6 Flash
คำตอบความเสี่ยงสูงที่ข้อผิดพลาดมีต้นทุนสูง	3.6 Flash

ตัวอย่างเชิงปฏิบัติ:

ระบบติดแท็กหมวดหมู่ให้ตั๋ว support หลายล้านรายการต่อวัน: ใช้ Flash-Lite
RAG ที่สรุปข้อมูลจากเอกสารที่ดึงมา: เริ่มที่ Flash-Lite
เอเจนต์ที่อ่าน stack trace แก้ไขไฟล์ และเปิด pull request: ใช้ 3.6 Flash
workflow ที่เรียก API หลายตัวและต้องตัดสินใจจากผลลัพธ์แต่ละขั้น: ใช้ 3.6 Flash

หากคุณกำลังอัปเกรดจาก Gemini 3.5 Flash รุ่นปกติ ไม่ใช่ Flash-Lite โปรดดูการเปรียบเทียบ 3.6 Flash กับ 3.5 Flash

คำนวณต้นทุนจากปริมาณงานจริง

สมมติว่า workload รายวันมี:

อินพุต 10 ล้านโทเค็น
เอาต์พุต 2 ล้านโทเค็น

โมเดล	อินพุต 10M	เอาต์พุต 2M	รวมรายวัน
Flash-Lite	$3.00	$5.00	$8.00
3.6 Flash	$15.00	$15.00	$30.00

ในกรณีนี้ 3.6 Flash มีค่าใช้จ่ายมากกว่า 3.75 เท่า:

Flash-Lite: ประมาณ $240/เดือน
3.6 Flash: ประมาณ $900/เดือน

ตัวคูณต้นทุนจริงจะอยู่ราว 3–5 เท่า:

งานที่เน้นอินพุต เช่น RAG context ยาว เอกสารขนาดใหญ่ หรือการจัดหมวดหมู่ข้อมูลจำนวนมาก จะใกล้ 5 เท่า
งานที่เน้นการสร้างเอาต์พุตจะใกล้ 3 เท่า

คำถามที่ควรถามจึงไม่ใช่แค่ว่า “3.6 Flash ทำงานนี้ได้หรือไม่” แต่คือ:

คุณภาพที่เพิ่มขึ้นคุ้มกับค่าใช้จ่ายเพิ่ม 3–4 เท่าต่อคำขอใน workload ของคุณหรือไม่?

วิธีทำ A/B Test ทั้งคู่ใน Apidog

อย่าเลือกจาก benchmark เพียงอย่างเดียว เพราะ prompt, context และเกณฑ์คุณภาพของแต่ละระบบต่างกัน คุณสามารถส่งคำขอเดียวกันไปยังทั้งสองโมเดล แล้วเปรียบเทียบผลลัพธ์จริงด้วย Apidog

ทำตามขั้นตอนนี้:

สร้าง POST request ไปยัง Gemini API endpoint
เก็บ API key เป็น environment variable ของ Apidog แทนการวางไว้ใน request body หรือ commit ลง Git
สร้าง request แรกโดยใช้ model id gemini-3.5-flash-lite
Duplicate request แล้วเปลี่ยนเฉพาะ model id เป็น gemini-3.6-flash
ใช้ prompt, parameter และ context ชุดเดิมสำหรับทั้งสอง request
เปรียบเทียบคุณภาพของคำตอบ ความหน่วง และผลการตรวจสอบอัตโนมัติ

แนวคิดสำคัญคือให้เปลี่ยนเพียงตัวแปรเดียว:

{
  "model": "gemini-3.5-flash-lite"
}

เทียบกับ:

{
  "model": "gemini-3.6-flash"
}

เพิ่ม assertion ให้ request เพื่อกำหนดคำว่า “ดีพอ” อย่างชัดเจน เช่น:

HTTP status ต้องสำเร็จ
response ต้องมีฟิลด์ JSON ที่คาดไว้
คำตอบต้องมีข้อมูลสำคัญที่จำเป็น
ความหน่วงต้องไม่เกิน threshold ของระบบ

จากนั้นบันทึก request เป็น test scenario และรันซ้ำเป็นระยะ คุณสามารถกำหนดเวลาการทดสอบ API ใน Apidogเพื่อจับความเปลี่ยนแปลงของคุณภาพหรือความหน่วงหลังมีการอัปเดตโมเดล

Apidog ส่งคำขอและตรวจสอบ assertion ให้คุณ แต่ไม่ได้รันโมเดล และไม่สามารถตัดสินแทนคุณได้ว่าคำตอบใด “ฉลาดกว่า” ส่วนนี้ควรกำหนดด้วย test cases และเกณฑ์ธุรกิจของระบบคุณเอง

เริ่มต้นได้โดยดาวน์โหลด Apidog แล้วสร้าง request สำหรับ Gemini endpoint

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

Flash-Lite เป็นแค่ 3.6 Flash เวอร์ชันที่แย่กว่าหรือไม่?

ไม่ใช่ ทั้งคู่ถูกออกแบบมาสำหรับจุดที่ต่างกันบนเส้นต้นทุน คุณภาพ และความเร็ว Flash-Lite เหมาะกับงานที่แคบและมีปริมาณสูง ส่วน 3.6 Flash เหมาะกับงานที่ซับซ้อนและต้องการการให้เหตุผลมากกว่า

ทำไมรุ่นหนึ่งเป็น 3.5 แต่อีกรุ่นเป็น 3.6?

ในการอัปเดตนี้ Google ย้ายโมเดล Flash หลักไปที่ 3.6 แต่ยังคงรุ่น Lite ไว้ที่ 3.5 โดยการเปิดตัวเดียวกันยังมีโมเดล 3.5 Flash Cyber security ด้วย ดังนั้นอย่าตีความว่าเลข 3.5 ของ Flash-Lite หมายถึงโมเดลเก่าหรือถูกเลิกพัฒนา

ทั้งสองใช้ Context Window เท่ากันหรือไม่?

ใช่ ทั้งคู่รองรับอินพุตสูงสุด 1 ล้านโทเค็น เลือกโมเดลจากคุณภาพการให้เหตุผล ราคา และความเร็ว ไม่ใช่จากขนาด context window

ใช้ทั้งสองโมเดลในแอปเดียวกันได้หรือไม่?

ได้ และเป็นรูปแบบที่แนะนำ ให้ route งานง่ายและปริมาณสูงไป Flash-Lite แล้ว route งานที่ซับซ้อน เน้นโค้ด หรือใช้เครื่องมือไป 3.6 Flash เนื่องจากโครงสร้าง API เหมือนกัน ความแตกต่างหลักคือ model id

ทั้งสองมีรุ่นทดลองใช้ฟรีหรือไม่?

ทั้งคู่มีรุ่นฟรีใน Google AI Studio ซึ่งมีการจำกัดอัตรา Google อาจใช้ข้อมูลจากรุ่นฟรีเพื่อปรับปรุงผลิตภัณฑ์ จึงควรอ่านข้อกำหนดก่อนส่งข้อมูลละเอียดอ่อน

สรุป

ตั้ง Flash-Lite เป็นค่าเริ่มต้นสำหรับงานที่รวดเร็ว ราคาถูก และมีปริมาณสูง แล้วส่งต่อเฉพาะคำขอที่ต้องใช้เหตุผลหลายขั้นตอน เครื่องมือ การเขียนโค้ด หรือมีความเสี่ยงสูงไปยัง 3.6 Flash

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

เปรียบเทียบ Gemini 3.6 Flash กับ 3.5 Flash: ต่างกันอย่างไร และควรอัปเกรดไหม

Thanawat Wongchai — Wed, 22 Jul 2026 06:33:33 +0000

Google อัปเดต Flash tier เมื่อวันที่ 21 กรกฎาคม 2026 โดยโมเดลหลักเปลี่ยนเป็น Gemini 3.6 Flash หากคุณใช้ 3.5 Flash ใน production ให้เตรียมอัปเกรด: 3.6 Flash อยู่ในตระกูลเดียวกัน ใช้ context window 1 ล้านโทเค็นและราคาอินพุตเท่าเดิม แต่ราคาเอาต์พุตต่ำลง ใช้โทเค็นเอาต์พุตน้อยลง และทำคะแนนด้านการใช้งานคอมพิวเตอร์ได้ดีกว่า ดูรายละเอียดของโมเดลได้ที่ Gemini 3.6 Flash คืออะไร

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

คำตอบสั้นๆ

อัปเกรดเป็น gemini-3.6-flash หากคุณสามารถรันการประเมินและ regression test ได้

ราคาอินพุตยังคงอยู่ที่ $1.50 ต่อ 1 ล้านโทเค็น
ราคาเอาต์พุตลดจาก $9.00 เป็น $7.50 ต่อ 1 ล้านโทเค็น
ใช้โทเค็นเอาต์พุตน้อยกว่า 3.5 Flash ประมาณ 17% สำหรับงานเดียวกัน
คะแนน OSWorld-Verified เพิ่มจาก 78.4 เป็น 83.0
เวิร์กโฟลว์หลายขั้นตอนอาจใช้ reasoning step และ tool call น้อยลง

เหตุผลหลักที่ควรรอคือ คุณได้ตรึง gemini-3.5-flash และตรวจสอบผลลัพธ์ใน production แล้ว แต่ยังไม่มีเวลารันการประเมินซ้ำ

Gemini 3.6 Flash เทียบกับ 3.5 Flash

ตัวเลขต่อไปนี้อ้างอิงจากข้อมูลเปิดตัวของ Google ดูรายละเอียดเพิ่มเติมได้จาก บล็อกโพสต์ของ Google และ หน้าโมเดล DeepMind Flash

คุณสมบัติ	Gemini 3.6 Flash	Gemini 3.5 Flash
รหัสโมเดล	`gemini-3.6-flash`	`gemini-3.5-flash`
ราคาอินพุต (ต่อ 1 ล้านโทเค็น)	$1.50	$1.50
ราคาเอาต์พุต (ต่อ 1 ล้านโทเค็น)	$7.50	$9.00
ประสิทธิภาพโทเค็นเอาต์พุต	โทเค็นเอาต์พุตน้อยลง ~17%	ค่าพื้นฐาน
การใช้งานคอมพิวเตอร์ (OSWorld-Verified)	83.0	78.4
Context window	1 ล้านโทเค็นอินพุต	1 ล้านโทเค็นอินพุต

สิ่งที่ไม่เปลี่ยนคือราคาอินพุตและ context window ส่วนที่เปลี่ยนคือค่าใช้จ่ายฝั่งเอาต์พุตและประสิทธิภาพในการสร้างคำตอบ

สิ่งที่ปรับปรุงจริง

1. ใช้โทเค็นเอาต์พุตน้อยลง

Gemini 3.6 Flash สร้างโทเค็นเอาต์พุตน้อยกว่า 3.5 Flash ประมาณ 17% สำหรับงานเดียวกัน โทเค็นเอาต์พุตรวมโทเค็นที่ใช้ในการคิด ดังนั้นโมเดลที่ให้เหตุผลได้มีประสิทธิภาพขึ้นจึงสามารถใช้ข้อความน้อยลงเพื่อจบงานเดียวกันได้

ผลกระทบคือค่าใช้จ่ายลดลงโดยตรง เพราะคุณจ่ายตามจำนวนโทเค็นเอาต์พุตจริง

2. ราคาเอาต์พุตลดลง

ราคาเอาต์พุตลดจาก $9.00 เหลือ $7.50 ต่อ 1 ล้านโทเค็น หรือประมาณ 17% ต่อโทเค็น นี่เป็นส่วนลดเพิ่มเติมจากการที่โมเดลใช้โทเค็นเอาต์พุตน้อยลงอยู่แล้ว

3. การใช้งานคอมพิวเตอร์ดีขึ้น

ใน OSWorld-Verified ซึ่งเป็น benchmark สำหรับการควบคุม UI บนคอมพิวเตอร์จริง:

Gemini 3.6 Flash: 83.0
Gemini 3.5 Flash: 78.4

หากคุณสร้าง agent ที่ต้องคลิก UI กรอกฟอร์ม หรือเรียกใช้เครื่องมือ คะแนนที่ดีขึ้นอาจหมายถึงขั้นตอนล้มเหลวน้อยลง

4. ใช้ reasoning step และ tool call น้อยลง

ใน agent workflow แบบหลายขั้นตอน Gemini 3.6 Flash สามารถทำงานให้เสร็จโดยใช้ reasoning step และ tool call น้อยลง

ทุก tool call ที่ลดได้ช่วยลดทั้ง:

เวลา round trip
โทเค็นสะสมในแต่ละรอบ
ค่าใช้จ่ายรวมของ workflow

ความแม่นยำด้านโค้ดก็ดีขึ้น ซึ่งสำคัญสำหรับงานสร้าง diff แก้ไขไฟล์ หรือสร้างโค้ดที่โทเค็นผิดเพียงตัวเดียวอาจทำให้ build ล้มเหลวได้

รูปแบบ API ไม่ได้เปลี่ยน: request format, authentication, endpoint, input modality เช่น ข้อความ รูปภาพ วิดีโอ เสียง และ PDF ยังคงเหมือนเดิม

คำนวณผลกระทบด้านค่าใช้จ่าย

ส่วนลดสองส่วนนี้คูณกัน:

ราคาเอาต์พุตต่อโทเค็นต่ำลง
จำนวนโทเค็นเอาต์พุตที่สร้างต่ำลง

ตัวอย่าง: สมมติ workload หนึ่งสร้างเอาต์พุต 10 ล้านโทเค็นต่อวันบน Gemini 3.5 Flash

Gemini 3.5 Flash

10 ล้านโทเค็น × $9.00 ต่อ 1 ล้านโทเค็น = $90.00 ต่อวัน
Gemini 3.6 Flash

ใช้โทเค็นน้อยลง 17% เหลือประมาณ 8.3 ล้านโทเค็น

8.3 ล้านโทเค็น × $7.50 ต่อ 1 ล้านโทเค็น = $62.25 ต่อวัน

สำหรับส่วนเอาต์พุตของ workload นี้ ค่าใช้จ่ายลดลงประมาณ 31% โดยไม่ต้องเปลี่ยน prompt

ค่าอินพุตยังคงเท่าเดิม เพราะราคาอินพุตอยู่ที่ $1.50 ต่อ 1 ล้านโทเค็นสำหรับทั้งสองโมเดล

ผลประหยัดจริงขึ้นอยู่กับอัตราส่วน input/output ของคุณ:

งานอ่านข้อมูลมากแต่สร้างข้อความน้อย เช่น การจัดหมวดหมู่หรือดึงข้อมูล จะประหยัดโดยรวมน้อยกว่า
งานสร้างข้อความจำนวนมาก เช่น การร่างเอกสาร การสร้างโค้ด หรือ agent trace ยาวๆ จะได้ประโยชน์มากกว่า
agent ที่มี tool call จำนวนมากอาจลดค่าใช้จ่ายได้เพิ่ม หากจำนวนรอบการเรียกเครื่องมือลดลง

ดูรายละเอียดเพิ่มเติมได้ที่ ราคา Gemini 3.6 Flash และ เอกสารราคา Gemini API

มีเหตุผลใดที่จะยังใช้ 3.5 Flash หรือไม่?

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

คุณควรตรึง gemini-3.5-flash ชั่วคราวหาก:

คุณมี evaluation suite ที่ผูกกับการอนุมัติด้าน compliance
parser หรือบริการปลายทางพึ่งพารูปแบบเอาต์พุตเดิมอย่างเข้มงวด
regression test ยังไม่พร้อมใน sprint ปัจจุบัน
คุณไม่สามารถตรวจสอบคุณภาพและผลกระทบของเวอร์ชันใหม่ได้ก่อน deploy

การเปลี่ยนโมเดลอาจทำให้ถ้อยคำหรือโครงสร้างเอาต์พุตเปลี่ยนแบบละเอียด แม้ request schema จะไม่เปลี่ยน ดังนั้นอย่าเปลี่ยนในระบบที่ยังตรวจสอบซ้ำไม่ได้

Gemini 3.5 Flash ไม่ได้หายไปเมื่อ 3.6 Flash เปิดตัว และยังใช้ผ่าน API ได้ การตรึงเวอร์ชันเดิมจึงเป็นทางเลือกที่สมเหตุสมผลในระยะสั้น แต่สำหรับทีมส่วนใหญ่ที่รันการทดสอบได้ ทั้งต้นทุนและคุณภาพชี้ไปที่การอัปเกรด

วิธีการย้าย

การแก้โค้ดมีเพียงหนึ่งบรรทัด:

- gemini-3.5-flash
+ gemini-3.6-flash

ตัวอย่างแนวคิดใน request body:

{
  "model": "gemini-3.6-flash",
  "contents": [
    {
      "parts": [
        {
          "text": "สรุปเอกสารนี้เป็น bullet points"
        }
      ]
    }
  ]
}

request body, auth และ endpoint ยังคงเหมือนเดิม ดูตัวอย่างการเรียกใช้แบบละเอียดได้ที่ วิธีใช้ Gemini 3.6 Flash API และ เอกสาร Gemini API

งานสำคัญคือการตรวจสอบก่อน deploy:

รัน evaluation suite เดิมกับ 3.6 Flash แล้วเปรียบเทียบกับ baseline ของ 3.5 Flash
รัน regression test เพราะถ้อยคำและรูปแบบเอาต์พุตอาจเปลี่ยนระหว่างเวอร์ชัน
ตรวจสอบทุกจุดที่ parse เอาต์พุตแบบตายตัว เช่น JSON key, regex และ schema validation
วัด latency และจำนวนโทเค็นจากตัวอย่าง traffic จริง
เปิดใช้ผ่าน feature flag ก่อน แล้วค่อย rollout เต็มรูปแบบ

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

ทดสอบ regression ใน Apidog

Apidog ใช้เป็น API client และแพลตฟอร์มทดสอบสำหรับเปรียบเทียบสองโมเดลได้ มันไม่ได้รันโมเดลเอง แต่ช่วยส่ง request ตรวจสอบ response และรัน assertions ก่อนที่คุณจะ deploy

ทำ A/B test ระหว่าง Gemini 3.5 Flash และ 3.6 Flash ตามขั้นตอนนี้:

บันทึก request Gemini เดิม

สร้าง POST request ไปยัง Gemini API ใน Apidog เก็บ API key ใน environment variable เพื่อไม่ให้คีย์อยู่ใน request body
ทำซ้ำ request

สร้าง request ชุดที่สอง แล้วเปลี่ยนเฉพาะ model ID:

   - gemini-3.5-flash
   + gemini-3.6-flash

อย่าเปลี่ยน prompt, parameter หรือ request body ส่วนอื่น เพื่อให้เปรียบเทียบได้ตรงกัน

เพิ่ม assertions ที่แอปอ่านจริง ตรวจสอบ status code และ JSON field ที่ระบบปลายทางต้องใช้ เช่น:

   pm.test("สถานะต้องเป็น 200", () => {
     pm.response.to.have.status(200);
   });

   const body = pm.response.json();

   pm.test("response ต้องมี candidates", () => {
     pm.expect(body).to.have.property("candidates");
   });

เปรียบเทียบ response, latency และ token usage

รัน request ทั้งสองตัวกับ input ชุดเดียวกัน ตรวจสอบว่า 3.6 Flash ผ่าน assertions เดิมทั้งหมด และบันทึกเวลาตอบกลับกับการใช้โทเค็น
บันทึกเป็น regression scenario

เก็บทั้งสอง request พร้อม assertions แล้วกำหนดเวลาให้เป็นการทดสอบ regression เพื่อจับความเปลี่ยนแปลงจากการแก้ prompt หรือการอัปเดตโมเดลในอนาคต

เวิร์กโฟลว์คือ: ทำซ้ำ request เปลี่ยนเฉพาะ model ID แล้วใช้ assertions เป็นตัวตัดสินว่าการย้ายปลอดภัยหรือไม่ ดาวน์โหลด Apidog หากต้องการทดสอบกับ Gemini request ของคุณเอง

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

Gemini 3.6 Flash ใช้แทน 3.5 Flash ได้ทันทีหรือไม่?

ในเชิง API ได้ เพียงเปลี่ยนจาก gemini-3.5-flash เป็น gemini-3.6-flash ส่วนอื่นของ request ยังคงเหมือนเดิม อย่างไรก็ตาม ควรรัน evaluation และ regression test ก่อนใช้ใน production เพราะถ้อยคำและโครงสร้างเอาต์พุตอาจเปลี่ยนได้

ราคาอินพุตเปลี่ยนหรือไม่?

ไม่ ราคาอินพุตยังคง $1.50 ต่อ 1 ล้านโทเค็นทั้งสองโมเดล ราคาเอาต์พุตเท่านั้นที่ลดจาก $9.00 เป็น $7.50 ต่อ 1 ล้านโทเค็น

ทำไม Flash เป็น 3.6 แต่ Lite และ Cyber เป็น 3.5?

ในการอัปเดตนี้ Google ปรับปรุงเฉพาะ Flash รุ่นหลักเป็น 3.6 ส่วน Flash-Lite และ Flash Cyber เปิดตัวในเวอร์ชัน 3.5 หมายเลขเวอร์ชันไม่ได้เรียงเหมือนกันทุก tier ดังนั้นให้ตรวจสอบ model ID ที่ใช้จริง

ค่าใช้จ่ายจะลดลง 31% เสมอหรือไม่?

ไม่ ตัวเลข 31% เป็นตัวอย่างสำหรับ workload ที่มีเอาต์พุตสูง การประหยัดจริงขึ้นอยู่กับอัตราส่วน input/output ของคุณ งานที่สร้างเอาต์พุตจำนวนมากจะเห็นผลมากกว่า งานที่เน้นอ่านข้อมูลจะเห็นผลน้อยกว่า

Gemini 3.5 Flash ยังใช้งานได้หรือไม่?

ใช่ ยังใช้ผ่าน API ได้ หากคุณตรวจสอบ 3.5 Flash ใน production แล้วแต่ยังไม่มีเวลาทดสอบซ้ำ การตรึงเวอร์ชันเดิมเป็นทางเลือกที่เหมาะสมในระยะสั้น วางแผนย้ายในช่วงทดสอบถัดไป

สำหรับรุ่นก่อนหน้า ดู Gemini 3.5 คืออะไร

สำหรับทีมส่วนใหญ่ ขั้นตอนที่เหมาะสมคือเปลี่ยน model ID เป็น gemini-3.6-flash รัน evaluation และ regression test ใน Apidog จากนั้น rollout อย่างควบคุมได้ เก็บ 3.5 Flash ไว้เฉพาะเมื่อข้อจำกัดด้านการตรวจสอบยังไม่อนุญาตให้ย้ายเท่านั้น

Gemini 3.5 Flash-Lite คืออะไร

Thanawat Wongchai — Wed, 22 Jul 2026 06:32:12 +0000

Google อัปเดต Flash tier เมื่อวันที่ 21 กรกฎาคม 2026 โดย Gemini 3.5 Flash-Lite เป็นโมเดล Gemini ที่ถูกที่สุดและเร็วที่สุดในกลุ่มนี้ เหมาะกับงานปริมาณสูงและความหน่วงต่ำ เช่น classification, extraction, แชทสั้น และคำตอบแบบ retrieval ง่ายๆ หากระบบของคุณต้องประมวลผลคำขอขนาดเล็กหลายล้านรายการต่อวัน โมเดลนี้ถูกออกแบบมาสำหรับ hot path ที่เน้น throughput และต้นทุนมากกว่าการให้เหตุผลเชิงลึก

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

การอัปเดตนี้มีโมเดลพร้อมกัน 3 รุ่น ได้แก่ Gemini 3.6 Flash, Gemini 3.5 Flash-Lite และ Gemini 3.5 Flash Cyber ดังนั้นก่อนนำไปใช้จริง ควรตรวจสอบทั้งชื่อโมเดล ราคา และลักษณะงานให้ตรงกัน

Gemini 3.5 Flash-Lite คืออะไร?

Gemini 3.5 Flash-Lite เป็นโมเดลขนาดเล็กและราคาประหยัดในตระกูล Gemini ของ Google โดยปรับแต่งมาเพื่อความเร็วและปริมาณงานสูง ไม่ได้มุ่งเน้นงาน reasoning ที่ซับซ้อนที่สุด

Google ระบุว่ารุ่นนี้สร้างเอาต์พุตได้ประมาณ 350 โทเค็นต่อวินาที และเรียกใช้งานผ่าน Gemini API ด้วยรหัสโมเดล:

gemini-3.5-flash-lite

ตัวอย่างงานที่เหมาะกับ Flash-Lite:

ติดแท็กหรือจัดหมวดหมู่ support tickets
ดึงข้อมูลแบบมีโครงสร้างจากข้อความหรือเอกสาร
สรุปคำตอบสั้นๆ จากข้อมูลที่ค้นคืนมา
สร้างแชทวิดเจ็ตที่ต้องตอบกลับเร็ว
ตรวจสอบหรือแปลงข้อความจำนวนมากใน background jobs

รุ่นนี้เปิดตัวพร้อมกับ Gemini 3.6 Flash ซึ่งเป็นโมเดลหลักใหม่ และ Gemini 3.5 Flash Cyber ซึ่งเป็นโมเดลความปลอดภัยแบบมีเกต ดูข้อมูลเพิ่มเติมได้จากบล็อกของ Google และหน้า DeepMind Flash

เดี๋ยวก่อน ทำไมถึงเป็น 3.5 ไม่ใช่ 3.6?

จุดที่ทำให้สับสนคือโมเดลหลักใช้ชื่อ Gemini 3.6 Flash แต่ Flash-Lite และ Flash Cyber ยังคงใช้หมายเลขเวอร์ชัน 3.5

นี่ไม่ใช่การพิมพ์ผิด Google กำหนดหมายเลขเวอร์ชันตามสายผลิตภัณฑ์ของแต่ละโมเดล ไม่ได้กำหนดตามวันที่เปิดตัว ดังนั้นในการเปิดตัวเดียวกันจึงมีทั้งรุ่น 3.6 และ 3.5

อีกจุดที่ควรตรวจสอบคือ Gemini 3.5 Flash-Lite ไม่ใช่Gemini 3.1 Flash-Lite รุ่นก่อนหน้า แม้ชื่อจะคล้ายกัน แต่เป็นคนละโมเดล

ก่อน deploy ให้ตรวจสอบ model ID ในโค้ดเสมอ:

const model = "gemini-3.5-flash-lite";

ข้อมูลจำเพาะและราคา

ราคาต่อไปนี้คิดต่อล้านโทเค็นผ่าน Gemini API:

คุณสมบัติ	ค่า
รหัสโมเดล	`gemini-3.5-flash-lite`
ราคาอินพุต	$0.30 / 1M tokens
ราคาเอาต์พุต	$2.50 / 1M tokens
ความเร็ว	~350 output tokens/second
ระดับฟรี	มีผ่าน Google AI Studio โดยมี rate limit
Context Caching	$0.03 / 1M tokens + $1.00 / 1M/hr storage

Flash-Lite มีราคาอินพุต $0.30 และเอาต์พุต $2.50 ต่อหนึ่งล้านโทเค็น ขณะที่ Gemini 3.6 Flash มีราคาอินพุต $1.50 และเอาต์พุต $7.50

สำหรับระบบที่ประมวลผลคำขอจำนวนมาก ความต่างนี้ส่งผลโดยตรงต่อต้นทุนรายเดือน โดยเฉพาะ workload ที่มี prompt สั้นและเรียกใช้งานบ่อย

ตรวจสอบราคาปัจจุบันก่อนนำไปใช้จริงได้จากเอกสารราคา Gemini API

ใช้ Context Caching เมื่อมี prompt ซ้ำ

หากระบบส่ง system prompt, กฎการจัดประเภท หรือเอกสารอ้างอิงชุดเดิมซ้ำๆ ให้พิจารณาใช้ Context Caching เพื่อลดต้นทุนของอินพุตที่ใช้ซ้ำ

กรณีที่เหมาะกับ caching:

system prompt ที่ใช้กับทุกคำขอ
คู่มือผลิตภัณฑ์ขนาดยาว
policy สำหรับตรวจสอบข้อความ
schema หรือคำอธิบายฟิลด์สำหรับ extraction

ประสิทธิภาพเป็นอย่างไร?

Gemini 3.5 Flash-Lite ได้คะแนน 54% ใน Terminal-Bench 2.1 เพิ่มขึ้นจาก 31% ของรุ่นก่อนหน้า ซึ่งเป็นการปรับปรุงที่สำคัญสำหรับโมเดลระดับ Lite

งานที่เหมาะสมที่สุดคือ:

Classification — เช่น แยก ticket เป็น billing, bug, feature request หรือ urgent
Extraction — เช่น ดึงชื่อ อีเมล หมายเลขคำสั่งซื้อ และวันที่จากข้อความ
Short chat responses — เช่น ตอบคำถามสั้นจาก FAQ
Simple RAG — เช่น ตอบคำถามจากเอกสารที่ retrieval system ดึงมาให้แล้ว

ตัวอย่าง prompt สำหรับ extraction:

ดึงข้อมูลต่อไปนี้จากข้อความ และตอบกลับเป็น JSON เท่านั้น:
- customer_name
- order_id
- issue_type
- urgency

ข้อความ:
"คุณสมชายแจ้งว่าคำสั่งซื้อ ORD-10482 ยังไม่ได้รับสินค้า และต้องการคำตอบภายในวันนี้"

ตัวอย่างผลลัพธ์ที่ควรตรวจสอบในแอปพลิเคชัน:

{
  "customer_name": "คุณสมชาย",
  "order_id": "ORD-10482",
  "issue_type": "delivery_delay",
  "urgency": "high"
}

ข้อจำกัดสำคัญคือ Flash-Lite แลกคุณภาพ reasoning กับราคาและความเร็ว จึงไม่ใช่ตัวเลือกหลักสำหรับ:

งาน agentic coding ที่ซับซ้อน
tool calling หลายขั้นตอน
การวางแผนที่ต้องมีเหตุผลต่อเนื่อง
การวิเคราะห์ codebase ขนาดใหญ่
งานที่คำตอบผิดมีต้นทุนสูง

สำหรับงานประเภทนี้ ให้พิจารณาใช้Gemini 3.6 Flash หรือโมเดลที่ใหญ่กว่าแทน

Google ใช้ Flash-Lite ที่ไหนบ้าง

Google นำ Flash-Lite ไปใช้กับ Google Search ด้วย ซึ่งเป็นสัญญาณว่าโมเดลนี้ถูกออกแบบมาให้รองรับการประมวลผลจำนวนมากได้จริง

สำหรับนักพัฒนา สิ่งที่ควรนำไปใช้คือแนวคิดเดียวกัน:

ใช้โมเดลราคาต่ำกับคำขอที่เกิดบ่อย
จำกัดขนาด prompt และ output ให้เหมาะกับงาน
แยกงานง่ายออกจากงาน reasoning หนัก
ตรวจสอบคุณภาพด้วยชุดทดสอบจริงของระบบ

หากโมเดลรองรับ workload ระดับ search ได้ ก็เหมาะกับ pipeline เช่น ticket classification, document extraction และ lightweight RAG เช่นกัน

Flash-Lite vs Gemini 3.6 Flash: คุณควรเลือกโมเดลไหนดี?

เลือก Gemini 3.5 Flash-Lite เมื่อ:

งานมีรูปแบบชัดเจน
ต้องประมวลผลจำนวนมาก
ต้องการ latency ต่ำ
ต้องควบคุมต้นทุนต่อคำขอ
งานเป็น classification, extraction หรือ short-form response

เลือก Gemini 3.6 Flash เมื่อ:

งานต้อง reasoning หลายขั้นตอน
ต้องเขียนหรือแก้ไขโค้ด
ต้องเรียกใช้ tools เป็นลำดับ
input มีความคลุมเครือสูง
ความถูกต้องสำคัญกว่าต้นทุนต่อคำขอ

แนวทางที่ใช้งานได้จริงคือ routing ตามความยากของงาน:

คำขอทั่วไป / ปริมาณสูง
        ↓
Gemini 3.5 Flash-Lite

คำขอซับซ้อน / ต้อง reasoning หรือ coding
        ↓
Gemini 3.6 Flash

ตัวอย่างเช่น ระบบ support อาจส่ง ticket ทั่วไปไปยัง Flash-Lite ก่อน แล้วส่งต่อเฉพาะเคสที่มีความเสี่ยงสูงหรืออธิบายไม่ชัดเจนไปยัง 3.6 Flash

ดูรายละเอียดราคาเพิ่มเติมได้ที่ราคาของ 3.6 Flash และเปรียบเทียบเชิงลึกได้ที่Gemini 3.5 Flash-Lite vs 3.6 Flash

วิธีเข้าถึงและทดสอบ

Flash-Lite ใช้งานผ่าน Gemini API เริ่มต้นได้เร็วที่สุดผ่านGoogle AI Studio เพื่อสร้าง API key และทดลองใช้ใน free tier

ตั้งค่า model เป็น:

gemini-3.5-flash-lite

ตัวอย่างคำขอ POST ด้วย cURL:

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash-lite:generateContent?key=$GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
    "contents": [
      {
        "parts": [
          {
            "text": "จัดหมวดหมู่ข้อความนี้เป็น billing, technical หรือ general: ฉันถูกเรียกเก็บเงินซ้ำ"
          }
        ]
      }
    ]
  }'

อย่า hardcode API key ลงใน source code ให้เก็บไว้ใน environment variable:

export GEMINI_API_KEY="your-api-key"

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

อ่านรูปแบบ request และ response เพิ่มเติมได้จากเอกสาร Gemini API

สร้าง regression test สำหรับ endpoint

หลังจากคำขอทำงานแล้ว ให้บันทึกเป็น regression test เพื่อตรวจจับปัญหาจากการเปลี่ยนแปลงของ API, rate limit หรือรูปแบบ response

ด้วยApidog คุณสามารถ:

สร้างคำขอ POST ไปยัง Gemini API
เก็บ API key เป็น environment variable
ตรวจสอบ status code เช่น 200
ตรวจสอบว่า response มีฟิลด์ JSON ที่แอปต้องใช้
บันทึกคำขอเป็น regression test
ตั้งเวลาให้รัน เพื่อพบปัญหาก่อนผู้ใช้

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

Status code ต้องเป็น 200
Response ต้องมี candidates
Response ต้องมีข้อความตอบกลับ
Response ต้องไม่ว่างเปล่า

Apidog ไม่ได้รันโมเดลแทน Gemini API แต่ช่วยให้คุณเรียกใช้งาน ตรวจสอบ และทดสอบ endpoint gemini-3.5-flash-lite ร่วมกับ API อื่นใน stack ได้

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

Gemini 3.5 Flash-Lite เหมือนกับ Gemini 3.6 Flash หรือไม่?

ไม่เหมือน ทั้งสองเป็นคนละโมเดลจากการอัปเดตวันที่ 21 กรกฎาคม 2026 Flash-Lite เน้นงานง่าย ปริมาณมาก และราคาต่ำ ส่วน 3.6 Flash เหมาะกับ reasoning, coding และงาน agent ที่ซับซ้อนกว่า

ทำไม Flash-Lite ใช้เวอร์ชัน 3.5 ไม่ใช่ 3.6?

Google กำหนดหมายเลขเวอร์ชันตามสายผลิตภัณฑ์ของโมเดล ไม่ได้กำหนดจากวันที่เปิดตัว รุ่น Flash หลักจึงเป็น 3.6 ขณะที่ Flash-Lite และ Flash Cyber ยังคงอยู่ที่ 3.5

Gemini 3.5 Flash-Lite คือ Gemini 3.1 Flash-Lite รุ่นเก่าหรือไม่?

ไม่ใช่ เป็นโมเดลใหม่คนละเวอร์ชัน ตรวจสอบ model ID ให้แน่ใจว่าใช้:

gemini-3.5-flash-lite

Gemini 3.5 Flash-Lite ฟรีหรือไม่?

มี free tier ผ่าน Google AI Studio พร้อม rate limit เหมาะสำหรับการทดลองและพัฒนาเบื้องต้น สำหรับ workload ระดับ production ที่มีปริมาณสูง ควรใช้ API key แบบชำระเงิน

Flash-Lite เหมาะกับงานใดมากที่สุด?

เหมาะกับ classification, extraction, แชทสั้น และ retrieval-augmented answers แบบง่ายที่ต้องประมวลผลจำนวนมากและตอบกลับเร็ว ไม่เหมาะกับงาน coding ซับซ้อนหรือ reasoning หลายขั้นตอนยาวๆ

Gemini 3.6 Flash ราคาปี 2026: ค่าใช้จ่ายจริงเท่าไร

Thanawat Wongchai — Wed, 22 Jul 2026 05:21:34 +0000

Gemini 3.6 Flash มีค่าใช้จ่าย 1.50 ดอลลาร์ต่อโทเค็นนำเข้า 1 ล้านโทเค็น และ 7.50 ดอลลาร์ต่อโทเค็นส่งออก 1 ล้านโทเค็น ซึ่งถูกกว่าโมเดลที่เข้ามาแทนที่ Google เปิดตัวเวอร์ชันปรับปรุงเมื่อวันที่ 21 กรกฎาคม 2026 สำหรับทีมที่ต้องติดตามบิล API นี่คือข่าวดี: Flash ระดับเรือธงทำงานเร็วขึ้นและมีราคาถูกลงพร้อมกัน

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

คู่มือนี้สรุปตัวเลขสำหรับวางแผนงบประมาณ ได้แก่ อัตราต่อโทเค็น, ค่าใช้จ่ายของ context caching, ขอบเขตแพ็กเกจฟรี และตัวอย่างคำนวณค่าใช้จ่ายรายเดือนก่อนเริ่มเขียนโค้ด ตัวเลขทั้งหมดอ้างอิงจากเอกสารราคา Gemini API ของ Google และประกาศเปิดตัว หากต้องการดูภาพรวมโมเดลก่อน อ่านGemini 3.6 Flash คืออะไร

หมายเหตุเรื่องเวอร์ชัน: โมเดลหลักข้ามมาเป็น 3.6 แต่ Flash-Lite ระดับราคาต่ำกว่ายังอยู่ที่ 3.5 แม้เปิดตัวพร้อมกัน จึงต้องระวังชื่อโมเดลเมื่อกำหนด routing และคำนวณต้นทุน

ราคา Gemini 3.6 Flash โดยสรุป

รายการ	ค่าใช้จ่าย
อินพุต	1.50 ดอลลาร์ต่อ 1 ล้านโทเค็น
เอาต์พุต (รวม thinking tokens)	7.50 ดอลลาร์ต่อ 1 ล้านโทเค็น
Context cache: อ่านอินพุตที่แคชไว้	0.15 ดอลลาร์ต่อ 1 ล้านโทเค็น
Context cache: จัดเก็บ	1.00 ดอลลาร์ต่อ 1 ล้านโทเค็นต่อชั่วโมง
แพ็กเกจฟรี	มี ผ่าน Google AI Studio และมีการจำกัดอัตรา

มีรายละเอียดสำคัญ 2 ข้อที่ต้องนำไปคิดในระบบ:

เอาต์พุตรวม thinking tokens แล้ว

โทเค็นที่โมเดลใช้ให้เหตุผลก่อนตอบจะถูกคิดที่อัตราเอาต์พุต 7.50 ดอลลาร์ต่อ 1 ล้านโทเค็น ไม่มีค่าใช้จ่ายแยกต่างหาก
Context caching ไม่ได้ฟรี

คุณจ่ายทั้งค่าอ่านข้อมูลที่แคชไว้ในอัตราที่ต่ำกว่า และค่าจัดเก็บรายชั่วโมง ดังนั้น cache จะคุ้มเมื่อมีการใช้ prompt prefix หรือเอกสารอ้างอิงชุดเดิมซ้ำหลายครั้งภายในช่วงเวลาสั้น ๆ

เปรียบเทียบกับ Gemini 3.5 Flash

อัตราเอาต์พุตลดจาก 9.00 ดอลลาร์ต่อ 1 ล้านโทเค็นใน Gemini 3.5 Flash เหลือ 7.50 ดอลลาร์ใน Gemini 3.6 Flash หรือถูกลงประมาณ 17% ต่อโทเค็นเอาต์พุต

แต่ผลประหยัดไม่ได้มาจากราคาเพียงอย่างเดียว หน้าโมเดล DeepMind Flash รายงานว่า Gemini 3.6 Flash สร้างโทเค็นเอาต์พุตน้อยลงประมาณ 17% สำหรับงานเดียวกัน เนื่องจากใช้ขั้นตอนการให้เหตุผลและการเรียกใช้เครื่องมือน้อยลงในงานหลายขั้นตอน

ผลลัพธ์คือคุณได้ทั้ง:

ราคาเอาต์พุตต่อโทเค็นที่ต่ำลง
จำนวนโทเค็นเอาต์พุตที่ลดลง

หากกำลังย้ายระบบจากโมเดลเดิม ให้ดูราคา Gemini 3.5 Flashควบคู่กัน และอ่านGemini 3.6 Flash vs 3.5 Flashเพื่อเปรียบเทียบความสามารถและประสิทธิภาพ

แพ็กเกจฟรีให้อะไรบ้าง

Gemini 3.6 Flash มีแพ็กเกจฟรีผ่านGoogle AI Studio คุณสามารถเรียกใช้โมเดลเพื่อสร้างต้นแบบและทดสอบได้โดยไม่ต้องใช้บัตรเครดิต

อย่างไรก็ตาม ให้แยกการใช้งานเป็น 2 ระยะชัดเจน:

ระยะ	ควรใช้แพ็กเกจฟรีหรือไม่
ทดลอง prompt และสร้าง prototype	ควรใช้
ทดสอบ integration ปริมาณน้อย	ใช้ได้
Production traffic	ไม่ควรใช้
ข้อมูลลูกค้า ข้อมูลลับ หรือข้อมูลกรรมสิทธิ์	ไม่ควรใช้

แพ็กเกจฟรีมีการจำกัดอัตราการใช้งาน และ Google อาจใช้ข้อมูลจากแพ็กเกจฟรีเพื่อปรับปรุงผลิตภัณฑ์ เมื่อเตรียมขึ้น production ให้ย้ายไปใช้คีย์แบบชำระเงิน

ดูขั้นตอนเริ่มต้นใช้งานได้ที่วิธีใช้ Gemini 3.6 Flash ฟรี

คำนวณค่าใช้จ่ายจริง

สมมติว่าคุณมีเอเจนต์สำหรับค้นคืนข้อมูล ที่ใช้:

อินพุต 2 ล้านโทเค็นต่อวัน
เอาต์พุต 500,000 โทเค็นต่อวัน

คำนวณต้นทุน Gemini 3.6 Flash ได้ดังนี้:

ค่าอินพุต  = 2,000,000 / 1,000,000 × $1.50
           = $3.00 ต่อวัน

ค่าเอาต์พุต = 500,000 / 1,000,000 × $7.50
            = $3.75 ต่อวัน

รวม        = $6.75 ต่อวัน
รายเดือน   = $6.75 × 30
           = $202.50 ต่อเดือน

ผลประหยัดเมื่อเทียบกับ Gemini 3.5 Flash

สมมติว่างานเดียวกันสร้างเอาต์พุต 600,000 โทเค็นบน Gemini 3.5 Flash แต่ลดลงเหลือประมาณ 500,000 โทเค็นบน Gemini 3.6 Flash

โมเดล	เอาต์พุตต่อวัน	ราคาเอาต์พุต	ค่าเอาต์พุตต่อวัน
Gemini 3.5 Flash	600,000 โทเค็น	9.00 ดอลลาร์ / 1M	5.40 ดอลลาร์
Gemini 3.6 Flash	500,000 โทเค็น	7.50 ดอลลาร์ / 1M	3.75 ดอลลาร์

ต่างกัน 1.65 ดอลลาร์ต่อวัน หรือประมาณ 49.50 ดอลลาร์ต่อเดือนเฉพาะค่าเอาต์พุต

($5.40 - $3.75) / $5.40 × 100 = 30.6%

แม้ทั้งราคาและจำนวนโทเค็นจะลดลงราว 17% แต่เมื่อทั้งสองปัจจัยคูณกัน ค่าเอาต์พุตจริงจึงลดลงได้ประมาณ 31%

Flash-Lite ถูกกว่าอีกสำหรับงานง่าย

หาก workload ของคุณไม่ต้องใช้ reasoning ซับซ้อน Gemini 3.5 Flash-Lite เป็นตัวเลือกต้นทุนต่ำกว่า:

รายการ	Gemini 3.5 Flash-Lite
อินพุต	0.30 ดอลลาร์ต่อ 1 ล้านโทเค็น
เอาต์พุต	2.50 ดอลลาร์ต่อ 1 ล้านโทเค็น
อ่าน context cache	0.03 ดอลลาร์ต่อ 1 ล้านโทเค็น
จัดเก็บ context cache	1.00 ดอลลาร์ต่อ 1 ล้านโทเค็นต่อชั่วโมง
ความเร็วเอาต์พุต	ประมาณ 350 โทเค็นต่อวินาที

สำหรับปริมาณงานเดิม:

อินพุต 2 ล้านโทเค็นต่อวัน
เอาต์พุต 500,000 โทเค็นต่อวัน

ค่าอินพุต  = 2 × $0.30 = $0.60
ค่าเอาต์พุต = 0.5 × $2.50 = $1.25
รวม        = $1.85 ต่อวัน
รายเดือน   = $55.50 ต่อเดือน

คิดเป็นต้นทุนต่ำกว่า Gemini 3.6 Flash ราว 70% เมื่อใช้จำนวนโทเค็นเท่ากัน

เลือก Flash-Lite สำหรับงาน เช่น:

การจัดหมวดหมู่
การดึงข้อมูล
การกำหนดเส้นทางคำขอ
การตอบแบบ structured output สั้น ๆ

ส่วน Gemini 3.6 Flash เหมาะกับงานที่ต้องใช้ reasoning หลายขั้นตอนมากกว่า อ่านเพิ่มได้ที่Gemini 3.5 Flash-Lite คืออะไรและGemini 3.5 Flash-Lite vs 3.6 Flash

วิธีควบคุมและวัดค่าใช้จ่าย

ใช้ 4 แนวทางนี้ในการควบคุมบิล API

1. แคช context ที่ใช้ซ้ำ

หากทุกคำขอมี system prompt ยาว ๆ หรือเอกสารอ้างอิงชุดเดิม ให้ใช้ context caching

อินพุตปกติ:       $1.50 / 1M tokens
อ่านจาก cache:    $0.15 / 1M tokens
ค่าจัดเก็บ cache: $1.00 / 1M tokens / ชั่วโมง

ก่อนเปิด cache ให้ประเมินจำนวนครั้งที่จะ reuse context เดิม เพราะการแคชคุ้มสำหรับ prefix ที่ถูกเรียกซ้ำบ่อย ไม่ใช่ข้อมูลที่ใช้เพียงครั้งเดียว

2. ตัด prompt และจำกัดเอาต์พุต

เอาต์พุตมีราคาแพงกว่าอินพุต 5 เท่า จึงควร:

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

ตัวอย่าง prompt ที่กระชับ:

สรุปเอกสารต่อไปนี้เป็น JSON โดยมีฟิลด์:
- summary: ไม่เกิน 100 คำ
- risks: รายการไม่เกิน 5 ข้อ
- next_actions: รายการไม่เกิน 3 ข้อ

3. Route งานตามความซับซ้อน

อย่าใช้โมเดลเดียวกับทุก endpoint ให้แยกเส้นทางงาน เช่น:

classification / extraction / routing
  -> Gemini 3.5 Flash-Lite

multi-step reasoning / agent workflow / complex analysis
  -> Gemini 3.6 Flash

การทำ model routing แบบผสมมักลดต้นทุนได้มากกว่าการพยายามเลือกโมเดลเดียวที่เหมาะกับทุกงาน

4. เก็บค่า `usageMetadata` จากทุกคำขอ

อย่าคาดการณ์จาก prompt เพียงอย่างเดียว ให้บันทึก usageMetadata จาก response ของ Gemini ทุกครั้ง เพราะนี่คือข้อมูลที่บอกจำนวนโทเค็นจริงที่ใช้ในการเรียก API

โครงสร้างการเก็บข้อมูลในระบบอาจเป็นแบบนี้:

const usage = response.usageMetadata;

console.log({
  inputTokens: usage.promptTokenCount,
  outputTokens: usage.candidatesTokenCount,
  totalTokens: usage.totalTokenCount,
});

นำข้อมูลนี้ไปเก็บในระบบ observability หรือฐานข้อมูล แล้วคำนวณต้นทุนต่อ endpoint, ต่อผู้ใช้ หรือแต่ละ workflow ได้

ตัวอย่างสูตรคำนวณ:

const inputCost = (inputTokens / 1_000_000) * 1.5;
const outputCost = (outputTokens / 1_000_000) * 7.5;
const totalCost = inputCost + outputCost;

ทดสอบงบประมาณ API ก่อนขึ้น production

ในApidogคุณสามารถสร้างคำขอ POST ไปยัง Gemini API, เก็บ API key ใน environment variables และทดสอบด้วย prompt จริงของระบบได้

แนวทางที่ใช้งานได้จริง:

สร้าง request สำหรับ workflow หลักแต่ละเส้นทาง
ใช้ environment variable เก็บ API key แทนการใส่คีย์ลงใน request
ส่ง prompt ที่ใกล้เคียง production มากที่สุด
ตรวจสอบ usageMetadata ใน response
เพิ่ม assertion เพื่อป้องกัน token usage เพิ่มขึ้นโดยไม่ตั้งใจ
ตั้ง schedule ให้รันทดสอบเป็นระยะเพื่อตรวจจับต้นทุนที่เพิ่มขึ้น

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

// ทำให้การทดสอบล้มเหลวหากเอาต์พุตสูงเกินงบที่ตั้งไว้
expect(response.body.usageMetadata.candidatesTokenCount)
  .toBeLessThan(2000);

วิธีนี้ช่วยป้องกันกรณีที่แก้ prompt แล้วเอาต์พุตเพิ่มเป็นสองเท่าโดยไม่มีใครสังเกต จนบิล production เพิ่มขึ้นตามไปด้วย

คุณสามารถกำหนดเวลาทดสอบ APIเพื่อตรวจจับการเปลี่ยนแปลงได้ตั้งแต่เนิ่น ๆ หรือดาวน์โหลด Apidogเพื่อทดสอบ Gemini endpoint ก่อนนำระบบขึ้น production

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

Gemini 3.6 Flash มีค่าใช้จ่ายเท่าไรต่อ 1 ล้านโทเค็น?

อินพุตราคา 1.50 ดอลลาร์ต่อ 1 ล้านโทเค็น และเอาต์พุตราคา 7.50 ดอลลาร์ต่อ 1 ล้านโทเค็น การอ่าน context cache ราคา 0.15 ดอลลาร์ต่อ 1 ล้านโทเค็น พร้อมค่าจัดเก็บ 1.00 ดอลลาร์ต่อ 1 ล้านโทเค็นต่อชั่วโมง

ราคาเอาต์พุตรวม thinking tokens หรือไม่?

รวมแล้ว โทเค็นที่โมเดลใช้ให้เหตุผลก่อนตอบถูกคิดรวมในอัตราเอาต์พุต 7.50 ดอลลาร์ต่อ 1 ล้านโทเค็น ดังนั้น reasoning ที่มากขึ้นหมายถึงค่าใช้จ่ายเอาต์พุตที่สูงขึ้น

มีแพ็กเกจฟรีหรือไม่?

มี ผ่าน Google AI Studio แต่มีการจำกัดอัตราการใช้งาน เหมาะสำหรับ prototype และการทดสอบ ไม่เหมาะกับ production หรือข้อมูลละเอียดอ่อน

Gemini 3.6 Flash ถูกกว่า 3.5 Flash หรือไม่?

ถูกกว่า อัตราเอาต์พุตลดจาก 9.00 ดอลลาร์เหลือ 7.50 ดอลลาร์ต่อ 1 ล้านโทเค็น และ Gemini 3.6 Flash ใช้โทเค็นเอาต์พุตน้อยลงประมาณ 17% สำหรับงานเดียวกัน ทำให้ค่าเอาต์พุตจริงลดลงได้ประมาณ 31%

ควรใช้ Flash-Lite เมื่อใด?

ใช้เมื่อภารกิจมีปริมาณมากแต่ไม่ซับซ้อน เช่น classification, extraction, routing และ structured response แบบสั้น Flash-Lite มีราคาอินพุต 0.30 ดอลลาร์ และเอาต์พุต 2.50 ดอลลาร์ต่อ 1 ล้านโทเค็น จึงถูกกว่า Gemini 3.6 Flash ราว 70% สำหรับจำนวนโทเค็นเท่ากัน

สรุป

วางงบประมาณ Gemini 3.6 Flash ที่:

1.50 ดอลลาร์ต่อ 1 ล้านโทเค็นอินพุต
7.50 ดอลลาร์ต่อ 1 ล้านโทเค็นเอาต์พุต
0.15 ดอลลาร์ต่อ 1 ล้านโทเค็นสำหรับ cache read
1.00 ดอลลาร์ต่อ 1 ล้านโทเค็นต่อชั่วโมงสำหรับ cache storage

ลดต้นทุนด้วย context caching สำหรับข้อมูลที่ reuse บ่อย, ตัด prompt ให้กระชับ, จำกัดเอาต์พุต, และ route งานง่ายไปยัง Flash-Lite ที่สำคัญที่สุดคือวัด usageMetadata จากคำขอจริงเสมอ

สำหรับบริบทการเปลี่ยนแปลงต้นทุนในเวอร์ชันก่อนหน้า ดูค่าใช้จ่าย Gemini 3.0 API และใช้Apidogเพื่อตรวจสอบว่า token budget ที่วางไว้ตรงกับค่าใช้จ่ายจริงใน production.

วิธีใช้ Gemini 3.6 Flash ฟรี

Thanawat Wongchai — Wed, 22 Jul 2026 04:21:05 +0000

คำตอบสั้น ๆ: ได้ คุณสามารถใช้ Gemini 3.6 Flash ได้ฟรีผ่านแอป Gemini หรือบริการ Gemini API ฟรีใน Google AI Studio ทั้งสองทางมีข้อจำกัดด้านโควต้า และบริการ API ฟรีมีเงื่อนไขการใช้ข้อมูลที่ควรตรวจสอบก่อนส่งข้อมูลส่วนตัวหรือข้อมูลสำหรับการผลิต

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

Gemini 3.6 Flash คือโมเดลหลักที่ Google ปรับปรุงใหม่และ ประกาศเมื่อวันที่ 21 กรกฎาคม 2026 โดยมีราคาต่ำลงและทำงานเร็วกว่า Gemini 3.5 Flash ที่ถูกแทนที่ จึงเหมาะสำหรับสร้างต้นแบบก่อนเริ่มใช้งานแบบชำระเงิน

คุณสามารถใช้ Gemini 3.6 Flash ได้ฟรีหรือไม่?

ได้ โดยมี 2 วิธีสำหรับการใช้งานคนละแบบ

แอป Gemini

ใช้สำหรับสนทนาและทดลองโมเดลโดยไม่ต้องเขียนโค้ด เพียงลงชื่อเข้าใช้ด้วยบัญชี Google แล้วเริ่มพิมพ์คำสั่ง
บริการ Gemini API ฟรี

ใช้สำหรับนักพัฒนาที่ต้องการเรียกโมเดลจากแอปของตนเอง สร้าง API key ใน Google AI Studio แล้วส่งคำขอผ่าน HTTP หรือ SDK ได้ทันที

ข้อควรจำเกี่ยวกับชื่อโมเดล:

โมเดลหลักคือ Gemini 3.6 Flash
รุ่นที่ประหยัดกว่าคือ Gemini 3.5 Flash-Lite

ทั้งสองเปิดตัวพร้อมกันแต่ใช้หมายเลขเวอร์ชันต่างกัน ดูรายละเอียดเพิ่มเติมได้ที่ Gemini 3.6 Flash คืออะไร

ใช้ Gemini 3.6 Flash ฟรีผ่านแอป Gemini

หากต้องการทดลองโมเดลอย่างรวดเร็ว ให้เปิดแอป Gemini ลงชื่อเข้าใช้ด้วยบัญชี Google แล้วส่งคำถามหรือคำสั่งได้เลย Gemini 3.6 Flash เป็นโมเดลสำหรับงานตอบสนองรวดเร็วและการใช้งานทั่วไป

เหมาะกับงาน เช่น

ถามตอบและสรุปข้อมูล
ร่างอีเมลหรือเอกสาร
ตรวจสอบตรรกะของโค้ด
ทดลอง prompt ก่อนนำไปใช้ใน API

อย่างไรก็ตาม แอป Gemini ไม่เหมาะกับการรวมเข้ากับผลิตภัณฑ์ เพราะคุณไม่สามารถควบคุม request body, ตั้งค่าพารามิเตอร์ เช่น temperature หรือส่งคำขอแบบอัตโนมัติจำนวนมากได้ หากต้องการสิ่งเหล่านี้ ให้ใช้ API

ใช้ Gemini API ฟรีใน Google AI Studio

สำหรับนักพัฒนา ให้เริ่มตามขั้นตอนนี้

เปิด Google AI Studio และลงชื่อเข้าใช้
เลือก รับคีย์ API แล้วสร้าง API key
เก็บ key ไว้ใน environment variable แทนการเขียนลงใน source code
เรียกโมเดลด้วยรหัส gemini-3.6-flash

ตัวอย่างคำขอขั้นต่ำด้วย curl:

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.6-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [
      {
        "parts": [
          {
            "text": "Explain what a REST API is in two sentences."
          }
        ]
      }
    ]
  }'

ก่อนรันคำสั่ง ให้ตั้งค่า environment variable:

export GEMINI_API_KEY="YOUR_API_KEY"

บริการฟรีรับอินพุตประเภทเดียวกับบริการแบบชำระเงิน ได้แก่ ข้อความ รูปภาพ วิดีโอ เสียง และไฟล์ PDF โดยผลลัพธ์เป็นข้อความ และคุณยังใช้หน้าต่างบริบทขนาด 1M-token ของโมเดลได้

สำหรับตัวอย่างพารามิเตอร์และแนวทางทดสอบ API เพิ่มเติม โปรดดู วิธีใช้ Gemini 3.6 Flash API

ข้อจำกัดที่ต้องรู้ก่อนใช้บริการฟรี

คำว่า “ฟรี” ไม่ได้หมายความว่าใช้งานได้ไม่จำกัด โดยมีข้อจำกัดหลัก 2 เรื่อง

1. ขีดจำกัดอัตราและโควต้า

บริการฟรีจำกัดจำนวนคำขอต่อนาทีและต่อวัน เมื่อเกินขีดจำกัด API จะตอบกลับด้วย HTTP 429 Too Many Requests

อย่า hard-code ตัวเลขโควต้าไว้ในระบบ เพราะ Google อาจเปลี่ยนแปลงได้ ตรวจสอบค่าปัจจุบันจาก เอกสาร Gemini API สำหรับ key ของคุณเสมอ

แนวทางปฏิบัติ:

ใช้บริการฟรีสำหรับการเรียนรู้และสร้างต้นแบบ
จัดการ HTTP 429 ในโค้ด
เพิ่ม retry พร้อม exponential backoff
หลีกเลี่ยงการใช้ free tier รองรับทราฟฟิกจริง

ตัวอย่าง retry แบบง่ายใน JavaScript:

async function callGeminiWithRetry(request, retries = 3) {
  for (let attempt = 0; attempt < retries; attempt++) {
    const response = await fetch(request);

    if (response.status !== 429) {
      return response;
    }

    const delay = 1000 * 2 ** attempt;
    await new Promise((resolve) => setTimeout(resolve, delay));
  }

  throw new Error("Gemini API rate limit exceeded");
}

2. การใช้ข้อมูล

บริการฟรีมีเงื่อนไขที่ Google อาจใช้ข้อความที่ส่งเข้าไปและผลลัพธ์จากโมเดลเพื่อปรับปรุงผลิตภัณฑ์ของตน

ดังนั้น อย่าส่งข้อมูลต่อไปนี้ผ่าน free tier:

ข้อมูลลูกค้า
ความลับหรือ credential
source code ที่เป็นกรรมสิทธิ์
ข้อมูลส่วนบุคคล
ข้อมูลการผลิตที่มีความละเอียดอ่อน

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

แนวทางเดียวกันนี้ใช้กับรุ่นก่อนหน้าเช่นกัน ดูได้จาก วิธีใช้ Gemini 3.5 ฟรี

เมื่อใดควรย้ายไปใช้บริการแบบชำระเงิน

พิจารณาอัปเกรดเมื่อเกิดกรณีต่อไปนี้

ต้องการโควต้าสูงขึ้น

แอปจริงมักชน rate limit ของ free tier ได้เร็ว บริการแบบชำระเงินช่วยรองรับผู้ใช้จำนวนมากขึ้น
ต้องประมวลผลข้อมูลส่วนตัวหรือข้อมูลลูกค้า

หากข้อมูลที่ส่งเข้า API ต้องมีเงื่อนไขความเป็นส่วนตัวที่เหมาะสม ควรเปลี่ยนออกจากบริการฟรี
กำลังนำระบบขึ้น production

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

Gemini 3.6 Flash มีค่าใช้จ่าย $1.50 ต่อ 1 ล้านโทเค็นอินพุต และ $7.50 ต่อ 1 ล้านโทเค็นเอาต์พุต โดยราคาเอาต์พุตลดลงจาก $9.00 ของ Gemini 3.5 Flash นอกจากนี้ โมเดลยังมีแนวโน้มใช้โทเค็นเอาต์พุตน้อยลงสำหรับงานเดียวกัน

ดูรายละเอียดค่าใช้จ่ายได้ที่ ราคา Gemini 3.6 Flash

ทางเลือกที่ประหยัดกว่า: Gemini 3.5 Flash-Lite

หากงานของคุณเน้นปริมาณมากมากกว่าการให้เหตุผลซับซ้อน ให้พิจารณา Gemini 3.5 Flash-Lite

ราคา:

ประเภท	ราคา
อินพุต	$0.30 ต่อ 1 ล้านโทเค็น
เอาต์พุต	$2.50 ต่อ 1 ล้านโทเค็น

Flash-Lite สามารถสตรีมเอาต์พุตได้ประมาณ 350 โทเค็นต่อวินาที และมี free tier ของตัวเอง

เหมาะกับงาน เช่น

การจัดประเภทข้อความ
การติดแท็กข้อมูล
การแยกข้อมูลสั้น ๆ
การกำหนดเส้นทางคำขอ
งานซ้ำจำนวนมากที่ต้องการ latency ต่ำ

เลือก Gemini 3.6 Flash เมื่อต้องการการให้เหตุผลที่แข็งแรงขึ้นหรือการใช้เครื่องมือ เลือก Flash-Lite เมื่อต้องการทำงานง่าย ๆ จำนวนมากในต้นทุนต่อคำขอที่ต่ำกว่า

อ่านเพิ่มเติมที่ Gemini 3.5 Flash-Lite คืออะไร

ทดสอบ Gemini API ฟรีด้วย Apidog

Free tier เป็นจุดที่ปัญหา API มักปรากฏชัด เช่น API key ใช้งานได้ แต่คำขอจำนวนมากเริ่มได้รับ HTTP 429 หรือ response มีโครงสร้างต่างจากที่โค้ดคาดไว้

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

ตั้งค่าเพียงครั้งเดียวแล้วใช้ซ้ำได้ในทีม:

สร้างคำขอ POST

ใช้ endpoint นี้:

   https://generativelanguage.googleapis.com/v1beta/models/gemini-3.6-flash:generateContent

เก็บ API key เป็น environment variable

ตั้ง header:

   x-goog-api-key: {{GEMINI_API_KEY}}
   Content-Type: application/json

กำหนด request body

   {
     "contents": [
       {
         "parts": [
           {
             "text": "Explain what a REST API is in two sentences."
           }
         ]
       }
     ]
   }

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

ตรวจสอบว่า API ตอบกลับด้วยสถานะ 200 และมีฟิลด์ JSON ที่แอปต้องใช้ วิธีนี้ช่วยตรวจจับการเปลี่ยนแปลงของ response schema ได้เร็วขึ้น

เฝ้าระวัง HTTP 429

ส่งคำขอเป็นชุดเพื่อดูพฤติกรรมของ rate limit โดยตรง เมื่อโควต้าหมด คุณจะเห็นสถานะ 429 ในเครื่องมือทดสอบแทนที่จะพบปัญหาหลัง deploy

ตั้งเวลารัน regression test

เปลี่ยนคำขอเป็น การทดสอบ API ตามกำหนดเวลา เพื่อตรวจหาการเปลี่ยนแปลงด้านโควต้าหรือความคลาดเคลื่อนของ API contract โดยอัตโนมัติ

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

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

Gemini 3.6 Flash ฟรีแบบไม่จำกัดหรือไม่?

ไม่ ฟรีมีขีดจำกัดจำนวนคำขอต่อนาทีและต่อวัน เมื่อเกินโควต้า API จะตอบกลับด้วย HTTP 429 ตรวจสอบโควต้าปัจจุบันได้จาก เอกสาร Gemini API

ข้อมูลในบริการฟรีเป็นส่วนตัวหรือไม่?

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

ต้องใส่บัตรเครดิตเพื่อใช้ API ฟรีหรือไม่?

ไม่ คุณสามารถสร้าง key ใน Google AI Studio และเริ่มเรียกใช้ API ได้โดยไม่ต้องตั้งค่าการเรียกเก็บเงิน เพิ่มวิธีชำระเงินเมื่อจำเป็นต้องใช้บริการแบบชำระเงินหรือโควต้าที่สูงขึ้น

แอป Gemini เหมือนกับ Gemini API ฟรีหรือไม่?

ไม่ แอป Gemini เป็นอินเทอร์เฟซสนทนาสำหรับผู้ใช้ทั่วไป ส่วน Gemini API ฟรีให้ key และการเข้าถึงแบบ programmatic สำหรับนำไปใช้ในซอฟต์แวร์ของคุณ

ควรเริ่มด้วย Flash หรือ Flash-Lite?

เริ่มด้วย Gemini 3.6 Flash สำหรับงานทั่วไป งานที่ต้องใช้การให้เหตุผล หรือการใช้เครื่องมือ เลือก Gemini 3.5 Flash-Lite เมื่อมีคำขอแบบง่ายจำนวนมากและต้องการต้นทุนต่อคำขอที่ต่ำที่สุด

ขั้นตอนถัดไป

เริ่มจากแอป Gemini หากต้องการทดลองโมเดลแบบไม่เขียนโค้ด จากนั้นย้ายไปใช้ Gemini API ฟรีใน Google AI Studio เมื่อพร้อมสร้างแอป

สำหรับการใช้งานจริง:

เก็บ API key ใน environment variable
หลีกเลี่ยงการส่งข้อมูลละเอียดอ่อนผ่าน free tier
จัดการ HTTP 429 และเพิ่ม retry logic
ทดสอบ request และ response schema ก่อน deploy
ย้ายไปใช้บริการแบบชำระเงินเมื่อมีทราฟฟิกจริงหรือข้อกำหนดด้านข้อมูล

เชื่อมต่อคำขอ Gemini ผ่าน Apidog ตั้งแต่เริ่มต้น เพื่อให้คุณตรวจพบ rate limit และความผิดปกติของ API ในขั้นตอนทดสอบ ไม่ใช่หลังผู้ใช้เจอปัญหา

Gemini 3.5 Flash Cyber คืออะไร? โมเดลความปลอดภัยขั้นสูงจาก Google

Thanawat Wongchai — Wed, 22 Jul 2026 04:11:02 +0000

Gemini 3.5 Flash Cyber คือโมเดล Flash ของ Google ที่ปรับแต่งสำหรับค้นหาและแก้ไขช่องโหว่ซอฟต์แวร์ ภายใต้โครงการ CodeMender เปิดตัวเมื่อวันที่ 21 กรกฎาคม 2026 พร้อมโมเดล Flash อีกสองรุ่น อย่างไรก็ตาม นักพัฒนาทั่วไปยังใช้งานไม่ได้: โมเดลนี้เป็นโครงการนำร่องแบบจำกัดสิทธิ์สำหรับหน่วยงานรัฐบาลและพันธมิตรที่เชื่อถือได้เท่านั้น ไม่มี Public API และไม่มีราคาที่เผยแพร่สู่สาธารณะ

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

ดังนั้นบทความนี้ไม่ใช่คู่มือตั้งค่า Cyber เพราะยังไม่มี API key, model ID หรือโค้ดตัวอย่างที่เรียกใช้ได้จริง แต่จะอธิบายสถานะของโมเดล สิ่งที่โมเดลทำได้ และแนวทางที่คุณนำไปใช้กับงาน security ได้ตั้งแต่วันนี้

Gemini 3.5 Flash Cyber คืออะไร?

Gemini 3.5 Flash Cyber คือโมเดลเฉพาะทางด้านช่องโหว่ความปลอดภัยในโค้ด โดยเป็นส่วนหนึ่งของโครงการ CodeMender ของ Google ซึ่งมุ่งค้นหาและแก้ไขช่องโหว่ซอฟต์แวร์

ต่างจาก Flash รุ่นทั่วไปที่รองรับงานเขียนโค้ด วิเคราะห์ข้อมูล และงาน reasoning ที่หลากหลาย Cyber ถูกปรับแต่งเพื่อเป้าหมายหลักเดียว:

ตรวจจับรูปแบบโค้ดที่มีความเสี่ยง
ระบุช่องโหว่ที่อาจเกิดขึ้น
เสนอแนวทางแก้ไขโค้ด

Google ประกาศโมเดลนี้ในโพสต์โมเดล Gemini เดียวกับการอัปเดต Flash รุ่นอื่น ๆ ส่วนรายละเอียดของ Flash สำหรับงานทั่วไปดูได้จากหน้าโมเดล DeepMind Flash

ข้อควรแยกให้ชัดเจน:

CodeMender คือโปรแกรมหรือโครงการ
Gemini 3.5 Flash Cyber คือโมเดลที่พัฒนาขึ้นเพื่อสนับสนุนงานในโครงการนั้น
ชื่อโมเดลคือ 3.5 Flash Cyber ไม่ใช่ 3.6

ข้อจำกัด: คุณอาจยังใช้มันไม่ได้

สถานะปัจจุบันของ Gemini 3.5 Flash Cyber คือการเข้าถึงแบบจำกัด Google เปิดให้เฉพาะรัฐบาลและพันธมิตรที่เชื่อถือได้ ยังไม่มีการเปิดใช้งานทั่วไปสำหรับนักพัฒนา

ในทางปฏิบัติ หมายความว่า:

ไม่มี Public API

คุณยังไม่สามารถระบุ model ID ของ Cyber ในแอปแล้วเรียกใช้งานเหมือนโมเดล Gemini ทั่วไปได้
ไม่มีราคาสาธารณะ

Google ยังไม่เผยแพร่อัตราค่าบริการต่อโทเค็น เพราะยังไม่มีช่องทางการเข้าถึงแบบเปิด เปรียบเทียบกับโมเดล Flash มาตรฐานที่มีราคาในเอกสารราคา Gemini API
ไม่มีการสมัครใช้งานด้วยตนเอง

ไม่มีปุ่มในคอนโซลหรือฟอร์มสาธารณะสำหรับเปิดใช้ Cyber ในบัญชีนักพัฒนาทั่วไป

หากคุณพบคู่มือที่อ้างว่ามี Cyber API, model string หรือราคา ให้ตรวจสอบแหล่งข้อมูลอย่างระมัดระวัง เพราะ Google ยังไม่ได้เผยแพร่ข้อมูลเหล่านี้สำหรับสาธารณะ

ทำไม Google ถึงจำกัดการเข้าถึง?

เหตุผลหลักคือความเสี่ยงจากการใช้งานได้สองทาง หรือ dual-use

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

รูปแบบการเปิดตัวแบบจำกัดช่วยให้ Google สามารถ:

ใช้งานโมเดลกับกรณีป้องกันระบบจริง
สังเกตพฤติกรรมและผลกระทบจากการใช้งาน
ประเมินความเสี่ยงก่อนขยายสิทธิ์การเข้าถึง

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

ตำแหน่งในตระกูล Flash

การอัปเดตวันที่ 21 กรกฎาคมเปิดตัวโมเดล Flash สามรุ่น ซึ่งใช้เลขเวอร์ชันต่างกัน:

Gemini 3.6 Flash

โมเดลอเนกประสงค์สำหรับงานเขียนโค้ดและวิเคราะห์ รองรับ context window 1 ล้านโทเค็น มี Free tier ใน Google AI Studio และมีราคาแบบสาธารณะ: 1.50 ดอลลาร์ต่อล้านโทเค็นอินพุต และ 7.50 ดอลลาร์ต่อล้านโทเค็นเอาต์พุต ดูรายละเอียดได้ที่ Gemini 3.6 Flash คืออะไร
Gemini 3.5 Flash-Lite

รุ่นสำหรับงานปริมาณสูงและเน้นต้นทุน เป็นรุ่นที่เร็วที่สุดในกลุ่ม โดยประมาณ 350 โทเค็นเอาต์พุตต่อวินาที ราคา 0.30 ดอลลาร์ต่อล้านโทเค็นอินพุต และ 2.50 ดอลลาร์ต่อล้านโทเค็นเอาต์พุต ดูรายละเอียดได้ที่ Gemini 3.5 Flash-Lite คืออะไร
Gemini 3.5 Flash Cyber

โมเดลเฉพาะทางด้านความปลอดภัย เข้าถึงได้เฉพาะรัฐบาลและพันธมิตรที่เชื่อถือได้ ไม่มี Public API และไม่มีราคาสาธารณะ

จุดที่อาจทำให้สับสนคือรุ่นหลักใช้หมายเลข 3.6 ขณะที่ Flash-Lite และ Cyber ใช้หมายเลข 3.5 นี่ไม่ใช่การพิมพ์ผิด แต่เป็นโมเดลที่อยู่คนละสายเวอร์ชัน

หากต้องเลือกระหว่างตัวเลือกแบบสาธารณะ ดูการเปรียบเทียบได้ที่ Gemini 3.6 Flash vs 3.5 Flash

นักพัฒนาควรทำอะไรได้บ้างในวันนี้?

แม้ยังใช้ Cyber ไม่ได้ แต่คุณสามารถสร้าง workflow ด้าน security ที่ใช้งานจริงได้ด้วยสองแนวทางต่อไปนี้

1. ใช้ Gemini 3.6 Flash สำหรับ security code review เบื้องต้น

Gemini 3.6 Flash เป็นโมเดลสาธารณะที่สามารถใช้ช่วยตรวจโค้ดได้ เช่น ขอให้ตรวจหา:

การตรวจสอบ input ที่ขาดหายไป
การจัดการ authentication หรือ authorization ที่ผิดพลาด
การใช้ secret หรือ token อย่างไม่ปลอดภัย
การ query ที่มีความเสี่ยงต่อ injection
การ validate ข้อมูลก่อนบันทึกลงฐานข้อมูลไม่เพียงพอ

ตัวอย่าง prompt:

ตรวจสอบโค้ด API endpoint นี้ในมุมมองความปลอดภัย

- ระบุจุดที่อาจเกิดช่องโหว่
- อธิบายผลกระทบของแต่ละจุด
- เสนอแนวทางแก้ไขแบบเฉพาะเจาะจง
- อย่าสรุปว่าปลอดภัยหากไม่มีหลักฐานจากโค้ด

[วางโค้ดของคุณที่นี่]

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

2. ทดสอบความปลอดภัยของ API อย่างเป็นระบบ

ปัญหา API ที่พบได้จริงจำนวนมากมักเกิดจาก:

ไม่มี authentication หรือ authorization ที่ถูกต้อง
การตั้งค่า transport security อ่อนแอ
endpoint ไม่เป็นไปตาม API contract หลังการเปลี่ยนแปลง
regression ที่เกิดขึ้นหลัง deploy

คุณสามารถทดสอบประเด็นเหล่านี้ได้โดยไม่ต้องใช้โมเดลเฉพาะทาง

Apidog ช่วยให้คุณส่งคำขอ API, เพิ่ม assertion และทำงานทดสอบซ้ำได้ โดยเริ่มจากกรณีต่อไปนี้

ตรวจสอบ authentication

ส่งคำขอไปยัง endpoint เดียวกันด้วยหลายสถานะของ token:

ไม่มี token
token หมดอายุ
token ไม่ถูกต้อง
token ที่ถูกต้องแต่ไม่มีสิทธิ์
token ที่ถูกต้องและมีสิทธิ์

ตัวอย่าง expectation:

GET /api/admin/users

ไม่มี token                 -> 401
token ไม่ถูกต้อง            -> 401
token ถูกต้องแต่ไม่มีสิทธิ์ -> 403
token ถูกต้องและมีสิทธิ์    -> 200

หากคำขอที่ไม่มี token ได้รับ 200 OK แทน 401 Unauthorized นั่นคือปัญหาที่ต้องแก้ไขทันที

ตรวจสอบ mTLS และใบรับรองไคลเอนต์

หากบริการของคุณต้องใช้ client certificate ให้ทดสอบทั้งกรณีที่ควรผ่านและควรถูกปฏิเสธ:

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

ดูขั้นตอนได้ที่ การทดสอบ API ด้วยใบรับรองไคลเอนต์และ mTLS ใน Apidog

ตั้งเวลาทดสอบ API contract

ทุก endpoint ควรมี assertion ขั้นต่ำ เช่น:

HTTP status code
ฟิลด์สำคัญใน JSON response
data type ของฟิลด์
รูปแบบ error response
header ที่เกี่ยวข้องกับ security

ตัวอย่าง assertion สำหรับ endpoint สร้างผู้ใช้:

POST /users

คาดหวัง:
- status code = 201
- response.body.id เป็น string
- response.body.email ตรงกับรูปแบบอีเมล
- response.body.password ไม่มีอยู่ใน response

จากนั้นตั้งเวลารันชุดทดสอบซ้ำเพื่อจับ regression หลังมีการเปลี่ยนแปลง ดูวิธีทำได้ที่ ตั้งเวลาทดสอบ API แบบซ้ำ

เริ่มต้นได้จากการตรวจสอบ authentication ก่อน เพราะมักตรวจพบปัญหาที่มีผลกระทบสูงด้วย effort ที่ไม่มากนัก ดาวน์โหลด Apidog เพื่อสร้างและรันชุดทดสอบ API ของคุณ

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

ฉันสามารถเข้าถึง Gemini 3.5 Flash Cyber ได้หรือไม่?

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

ฉันจะขอสิทธิ์เข้าถึงได้อย่างไร?

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

สำหรับการเปลี่ยนแปลงสถานะ ให้ติดตามบล็อกของ Google และหน้าโมเดล DeepMind

มี API หรือราคาที่เผยแพร่แล้วหรือไม่?

ไม่มีสำหรับการใช้งานสาธารณะ ยังไม่มี model ID ที่นักพัฒนาทั่วไปเรียกใช้ได้ และไม่มีอัตราค่าบริการต่อโทเค็นที่ Google เผยแพร่

CodeMender คืออะไร?

CodeMender คือโครงการของ Google ที่มุ่งค้นหาและแก้ไขช่องโหว่ในโค้ด ส่วน Gemini 3.5 Flash Cyber คือโมเดลที่ปรับแต่งสำหรับงานดังกล่าว

ระหว่างนี้ควรใช้เครื่องมืออะไรสำหรับงาน security?

ใช้ Gemini 3.6 Flash สำหรับการตรวจโค้ดเบื้องต้น แล้วเสริมด้วยการทดสอบ API จริง โดยเน้น authentication, authorization, mTLS และ API contract regression

สรุป

Gemini 3.5 Flash Cyber เป็นโมเดลด้านความปลอดภัยของ Google สำหรับค้นหาและแก้ไขช่องโหว่ในโค้ดภายใต้โครงการ CodeMender แต่ยังเป็นโครงการนำร่องที่จำกัดสิทธิ์สำหรับรัฐบาลและพันธมิตรที่เชื่อถือได้

สำหรับนักพัฒนาทั่วไป ตอนนี้ยังไม่มี Public API, ราคา หรือวิธีสมัครใช้งานด้วยตนเอง

สิ่งที่ทำได้ทันทีคือใช้ Gemini 3.6 Flash ช่วยตรวจโค้ด และสร้างชุดทดสอบ API ที่ตรวจสอบ authentication, mTLS และ API contract อย่างต่อเนื่อง เพื่อจับปัญหาก่อนกลายเป็น incident ใน production

วิธีใช้ Gemini 3.6 Flash API

Thanawat Wongchai — Wed, 22 Jul 2026 04:06:47 +0000

คุณเรียกใช้งาน Gemini 3.6 Flash ผ่าน Gemini API ของ Google ด้วย model ID คือ gemini-3.6-flash Google เปิดตัว Flash รุ่นปรับปรุงเมื่อวันที่ 21 กรกฎาคม 2026 และ 3.6 Flash คือรุ่นหลักสำหรับการทำงาน: มีค่าใช้จ่ายต่ำกว่า 3.5 Flash, รองรับ context window ขนาด 1M โทเค็น และรับอินพุตเป็นข้อความ รูปภาพ วิดีโอ เสียง และ PDF ได้ คู่มือนี้จะแสดงขั้นตอนตั้งแต่รับ API key, เรียกใช้งานด้วย curl และ Python, ปรับพารามิเตอร์สำคัญ ไปจนถึงตั้งค่า regression test สำหรับตรวจสอบ API หลังนำขึ้นใช้งานจริง

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

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

เริ่มต้นได้โดยไม่ต้องตั้งค่าการเรียกเก็บเงินล่วงหน้า โดยเตรียมเพียง:

บัญชี Google สำหรับลงชื่อเข้าใช้และสร้าง API key
Gemini API key จาก Google AI Studio
เครื่องมือส่ง HTTP request เช่น curl, Python หรือ API client เช่น Apidog

ระดับฟรีใช้งานผ่าน AI Studio และมีการจำกัดอัตรา (rate limit) จึงเหมาะสำหรับทดสอบและสร้างต้นแบบโดยไม่ต้องใช้บัตรเครดิต

รับ Gemini API key

ไปที่ Google AI Studio แล้วลงชื่อเข้าใช้ด้วยบัญชี Google ของคุณ

คลิก Get API key
คลิก Create API key
คัดลอก key และเก็บไว้ในที่ปลอดภัย

ปฏิบัติต่อ API key เหมือนรหัสผ่าน เพราะผู้ที่มี key สามารถเรียกใช้บริการผ่านบัญชีของคุณได้

อย่า hard-code key ในโค้ด หรือ commit ลง repository ให้ตั้งเป็น environment variable แทน:

export GEMINI_API_KEY="your_key_here"

Python SDK อย่างเป็นทางการสามารถอ่านตัวแปรนี้ได้โดยตรง ทำให้ไม่ต้องเก็บ secret ใน source code ดูรายละเอียดการตั้งค่าเพิ่มเติมได้จากเอกสาร Gemini API ของ Google

เรียก Gemini 3.6 Flash ครั้งแรกด้วย curl

Gemini REST API ใช้ POST ไปยังเมธอด generateContent ของโมเดล

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.6-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
    "contents": [
      {
        "parts": [
          {"text": "Explain how APIs work"}
        ]
      }
    ]
  }'

จุดสำคัญของ request นี้:

ส่ง API key ผ่าน header x-goog-api-key
ระบุ request body เป็น JSON
contents เป็นอาร์เรย์ของข้อความหรือข้อมูลที่ส่งให้โมเดล
แต่ละ content มี parts ซึ่งใช้ผสมข้อความ รูปภาพ หรือไฟล์ใน request เดียวได้

เมื่อสำเร็จ ข้อความที่โมเดลสร้างจะอยู่ในฟิลด์:

candidates[0].content.parts[0].text

เก็บ path นี้ไว้ใช้ตรวจสอบผลลัพธ์ใน regression test ภายหลัง

เรียกใช้งานด้วย Python

ติดตั้ง Google Gen AI SDK ก่อน:

pip install google-genai

จากนั้นสร้างไฟล์ Python ดังนี้:

from google import genai

client = genai.Client()  # อ่าน GEMINI_API_KEY จาก environment

resp = client.models.generate_content(
    model="gemini-3.6-flash",
    contents="Explain how APIs work",
)

print(resp.text)

SDK จะอ่าน GEMINI_API_KEY จาก environment โดยอัตโนมัติ ดังนั้น API key จะไม่ปรากฏในโค้ด และ resp.text คือข้อความตอบกลับจากโมเดล

พารามิเตอร์สำคัญที่ควรรู้

คำขอพื้นฐานใช้งานได้ทันที แต่พารามิเตอร์ต่อไปนี้ช่วยควบคุมผลลัพธ์ได้มากขึ้น

System instruction

ใช้กำหนดกฎหรือบทบาทของโมเดลตลอดบทสนทนา เช่น “ตอบเป็น JSON เท่านั้น” หรือ “ทำหน้าที่เป็น code reviewer ที่ตอบแบบกระชับ” แยกออกจาก prompt ของผู้ใช้ จึงไม่ต้องใส่คำสั่งเดิมซ้ำทุกข้อความ
Max output tokens

ใช้จำกัดความยาวของคำตอบ Gemini 3.6 Flash สร้าง output ได้สูงสุด 64k โทเค็น เพิ่มค่านี้สำหรับงานสร้างเนื้อหายาว และลดลงเมื่อต้องการควบคุมค่าใช้จ่ายหรือ latency
Multimodal inputs

โมเดลรับข้อความ รูปภาพ วิดีโอ เสียง และ PDF ได้ใน request เดียว โดยเพิ่มข้อมูลเป็นรายการใน parts ควบคู่กับข้อความ ผลลัพธ์เป็นข้อความ และ context window รองรับอินพุตได้สูงสุด 1M โทเค็น
Thinking and reasoning

สำหรับ prompt ที่ซับซ้อน โมเดลอาจให้เหตุผลก่อนตอบ ซึ่งช่วยงานแบบหลายขั้นตอน แต่ thinking tokens จะรวมอยู่ในค่า output ด้วย คุณจึงควรปรับระดับการให้เหตุผลให้สมดุลกับความเร็วและงบประมาณ

ตรวจสอบชื่อฟิลด์และพารามิเตอร์ล่าสุดจากเอกสาร Gemini API เสมอ แทนการเดาชื่อพารามิเตอร์เอง

ราคาและระดับฟรี

Gemini 3.6 Flash มีค่าใช้จ่าย:

$1.50 ต่อ 1M โทเค็นอินพุต
$7.50 ต่อ 1M โทเค็นเอาต์พุต

ราคา output ลดลงจาก $9.00 ของ Gemini 3.5 Flash และ Gemini 3.6 Flash มีแนวโน้มใช้ output tokens น้อยลงประมาณ 17% สำหรับงานเดียวกัน

ข้อควรระวังคือราคา output รวม thinking tokens ด้วย ดังนั้น prompt ที่ต้องใช้การให้เหตุผลมากอาจมีค่าใช้จ่ายสูงกว่าความยาวคำตอบที่เห็นบนหน้าจอ ดูตัวอย่างการคำนวณได้จากคู่มือราคา Gemini 3.6 Flash

ระดับฟรีผ่าน AI Studio เหมาะกับการเรียนรู้และสร้างต้นแบบ แต่มี rate limit ทั้งต่อนาทีและต่อวัน นอกจากนี้ Google อาจใช้ข้อมูลจากระดับฟรีเพื่อปรับปรุงผลิตภัณฑ์ หากต้องการใช้งานจริง ให้เปิดใช้งานการเรียกเก็บเงิน โดยยังใช้ API key เดิมและโค้ดเดิมได้

อ่านรายละเอียดเพิ่มเติมได้ที่วิธีใช้ Gemini 3.6 Flash ฟรี

ทดสอบและแก้ไขข้อบกพร่อง Gemini API ใน Apidog

การใช้ curl ช่วยยืนยันว่า request ทำงานได้หนึ่งครั้ง แต่ไม่สามารถแจ้งเตือนคุณได้เมื่อ:

response field เปลี่ยน
API key หมดอายุ
การ deploy ทำให้ request เสียหาย
API เริ่มตอบกลับไม่ตรงตามที่แอปคาดหวัง

Apidog ช่วยบันทึก request และทำ regression test ซ้ำได้ตามขั้นตอนต่อไปนี้

สร้าง request สร้าง POST request ใหม่ด้วย URL:

   https://generativelanguage.googleapis.com/v1beta/models/gemini-3.6-flash:generateContent

จากนั้นวาง JSON body เดียวกับตัวอย่าง curl

เก็บ key ใน environment variable เพิ่มตัวแปรชื่อ GEMINI_API_KEY ใน Apidog environment แล้วกำหนดค่า header ดังนี้:

   x-goog-api-key: {{GEMINI_API_KEY}}

วิธีนี้ช่วยป้องกันไม่ให้ secret ปรากฏใน request ที่แชร์ และสลับ key ระหว่าง dev, staging และ prod ได้โดยไม่แก้ request

เพิ่ม assertions ตรวจสอบว่า:

HTTP status เป็น 200
candidates[0].content.parts[0].text มีอยู่
ข้อความตอบกลับไม่ว่างเปล่า

Assertions เหล่านี้ช่วยยืนยันว่า API ตอบกลับข้อมูลที่แอปใช้งานได้จริง ไม่ใช่เพียงตอบกลับบางอย่าง

บันทึกและตั้งเวลา run เก็บ request ไว้ใน collection แล้วกำหนดเวลาให้ทำงานเป็น regression test จะเรียกตามเวลา หรือรันใน CI ก็ได้

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

ข้อผิดพลาดและการแก้ไขที่พบบ่อย

401 Unauthorized: invalid key

สาเหตุที่เป็นไปได้:

API key ไม่ถูกต้อง
key ถูกยกเลิก
ไม่มี header x-goog-api-key
environment variable ไม่ถูกแทนค่า

ตรวจสอบว่า key จาก AI Studio ถูกส่งอย่างถูกต้อง และไม่มีช่องว่างเกินท้ายค่า โดยเฉพาะเมื่อใช้ {{GEMINI_API_KEY}}

429 Too Many Requests: rate limit

คุณอาจถึงขีดจำกัดคำขอต่อนาทีหรือต่อวันของระดับฟรี

แนวทางแก้ไข:

ลดอัตราการส่ง request
เพิ่ม retry พร้อม backoff
เปิดใช้งานการเรียกเก็บเงินเพื่อใช้ขีดจำกัดที่สูงขึ้น

ลูปทดสอบที่ยิง request ถี่มากเป็นสาเหตุที่พบบ่อยของข้อผิดพลาดนี้

404 Not Found: model not found

ตรวจสอบ model ID ให้ตรงตามนี้:

gemini-3.6-flash

อย่าสลับเป็น:

gemini-3.5-flash
gemini-flash-3.6

โมเดล Lite ของสายนี้คือ gemini-3.5-flash-lite ซึ่งเป็นโมเดลคนละตัวในสาย 3.5

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

model ID ที่แน่นอนสำหรับ Gemini 3.6 Flash คืออะไร?

ใช้ gemini-3.6-flash ทั้งใน SDK และ REST URL path ก่อน :generateContent

Gemini 3.6 Flash API ใช้งานฟรีหรือไม่?

มีระดับฟรีผ่าน AI Studio และมี rate limit เหมาะสำหรับเรียนรู้และสร้างต้นแบบ การใช้งานจริงต้องเปิดใช้งานการเรียกเก็บเงิน ดูรายละเอียดได้ที่วิธีใช้ Gemini 3.6 Flash ฟรี

ส่งอะไรไปยังโมเดลได้บ้าง?

ส่งข้อความ รูปภาพ วิดีโอ เสียง และ PDF ได้ โดยรองรับ context window สูงสุด 1M โทเค็น และผลลัพธ์เป็นข้อความ

ทำไมค่าใช้จ่ายสูงกว่าความยาวคำตอบที่เห็น?

ราคา output ที่ $7.50 ต่อ 1M โทเค็นรวม thinking tokens ของโมเดลด้วย Prompt ที่ใช้เหตุผลมากจึงอาจมีค่าใช้จ่ายสูงกว่าคำตอบที่แสดง

ใช้เหมือน Gemini 3.5 Flash API หรือไม่?

รูปแบบการเรียกใช้งานเหมือนกัน หากคุณเคยใช้ Gemini 3.5 API คุณเพียงเปลี่ยน model ID เป็น gemini-3.6-flash โดย 3.6 Flash มีค่า output ต่ำกว่าและใช้ output tokens น้อยลงสำหรับงานเดียวกัน

ใช้ API key เดียวกันกับ curl, Python และ Apidog ได้หรือไม่?

ได้ API key เดียวจาก AI Studio ใช้ได้กับทุกเครื่องมือ ควรเก็บ key เป็น environment variable ในแต่ละเครื่องมือ แทนการ hard-code เพื่อให้เปลี่ยนหรือยกเลิก key ได้ง่าย

จะไปต่อจากนี้ที่ไหน

ตอนนี้คุณมี:

Gemini API key
ตัวอย่าง request ที่ใช้งานได้ด้วย curl
ตัวอย่าง Python SDK
แนวทางเลือกพารามิเตอร์
แนวทางตั้ง regression test สำหรับ endpoint

เริ่มจากระดับฟรี เก็บ API key ไว้ใน environment variable และอ้างอิงเอกสาร Gemini API อย่างเป็นทางการ เมื่อต้องใช้งานความสามารถเพิ่มเติม

เมื่อ Gemini API กลายเป็นส่วนสำคัญของแอป ให้ห่อหุ้ม request ด้วยการทดสอบในApidog เพื่อให้คุณตรวจพบการเปลี่ยนแปลงของ API ก่อนที่ผู้ใช้จะพบปัญหา

Gemini 3.6 Flash คืออะไร

Thanawat Wongchai — Wed, 22 Jul 2026 04:06:40 +0000

Gemini 3.6 Flash เป็นโมเดลหลักตัวใหม่ของ Google ที่เปิดให้ใช้งานทั่วไปเมื่อวันที่ 21 กรกฎาคม 2026 โดยมีต้นทุนต่ำลงและใช้โทเค็นได้มีประสิทธิภาพกว่า Gemini 3.5 Flash ที่ถูกแทนที่ เหมาะสำหรับระบบที่ส่งคำขอ API ปริมาณสูงและต้องการผลลัพธ์ที่เชื่อถือได้โดยไม่ต้องใช้โมเดลระดับเรือธง

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

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

Gemini 3.6 Flash คืออะไร?

Gemini 3.6 Flash คือโมเดลระดับกลางสำหรับงานปริมาณสูงในตระกูล Gemini ของ Google หรือโมเดล “workhorse” สำหรับงาน production ทั่วไป เช่น

สรุปข้อความ
ดึงข้อมูลจากเอกสาร
จัดหมวดหมู่ข้อมูล
สร้างแชตหรือผู้ช่วยสนทนา
เรียกใช้เครื่องมือหลายขั้นตอนใน agent workflow

โมเดลรองรับอินพุตเป็นข้อความ รูปภาพ วิดีโอ เสียง และ PDF ในคำขอเดียว แต่สร้างเอาต์พุตเป็นข้อความเท่านั้น

Google เปิดตัวพร้อมอีกสองโมเดลเมื่อวันที่ 21 กรกฎาคม 2026:

Gemini 3.5 Flash-Lite: รุ่นที่ถูกกว่าและเร็วกว่า สำหรับงานปริมาณมาก
Gemini 3.5 Flash Cyber: โมเดลด้านความปลอดภัยที่จำกัดการเข้าถึงสำหรับรัฐบาลและพันธมิตรที่เชื่อถือได้

อ่านรายละเอียดเพิ่มเติมได้ที่ Gemini 3.5 Flash-Lite คืออะไร และ Gemini 3.5 Flash Cyber คืออะไร

ข้อควรระวังคือหมายเลขเวอร์ชันของแต่ละระดับไม่เหมือนกัน:

gemini-3.6-flash
gemini-3.5-flash-lite

สองรหัสนี้เป็นคนละโมเดล ไม่ใช่การพิมพ์ผิด ตรวจสอบ model ID ให้ตรงก่อนอัปเดตระบบ

Google เผยแพร่รายละเอียดไว้บนบล็อกของ Google และหน้า DeepMind Flash

มีอะไรใหม่เมื่อเทียบกับ Gemini 3.5 Flash

การเปลี่ยนแปลงหลักของ Gemini 3.6 Flash คือประสิทธิภาพต่อคำขอ

ใช้โทเค็นขาออกน้อยกว่า Gemini 3.5 Flash ประมาณ 17% สำหรับงานเดียวกัน
ราคาโทเค็นขาออกลดจาก $9.00 เป็น $7.50 ต่อ 1M tokens
ทำงานด้าน coding และ computer use ได้ดีขึ้น
ใช้ขั้นตอน reasoning และ tool calls น้อยลงใน workflow หลายขั้นตอน

สำหรับระบบ agent ความแตกต่างนี้ส่งผลโดยตรงต่อ latency และต้นทุน เพราะทุก reasoning loop และ tool call เพิ่มทั้งเวลาและค่าใช้จ่าย

ก่อนย้าย workload ให้เปรียบเทียบผลลัพธ์จาก prompt จริงของคุณกับบทความ Gemini 3.6 Flash เทียบกับ 3.5 Flash

ข้อมูลจำเพาะของ Gemini 3.6 Flash

คุณสมบัติ	Gemini 3.6 Flash
รหัสโมเดล	`gemini-3.6-flash`
หน้าต่างบริบทอินพุต	1M tokens
เอาต์พุตสูงสุด	64k tokens
รูปแบบอินพุต	ข้อความ, รูปภาพ, วิดีโอ, เสียง, PDF
เอาต์พุต	ข้อความเท่านั้น
ราคาอินพุต	$1.50 ต่อ 1M tokens
ราคาเอาต์พุต	$7.50 ต่อ 1M tokens รวมโทเค็นการคิด
ระดับฟรี	มี ผ่าน Google AI Studio และมี rate limit
เปิดตัวเมื่อ	21 กรกฎาคม 2026

หน้าต่างบริบท 1M tokens ช่วยให้ส่งเอกสารขนาดใหญ่ transcript ยาว หรือโค้ดเบสจำนวนมากในคำขอเดียวได้

อย่างไรก็ตาม เอาต์พุตสูงสุดคือ 64k tokens ต่อคำขอ หากต้องสร้างรายงานหรือเนื้อหายาวมาก ควรแบ่งงานเป็นหลายส่วน เช่น:

สร้างโครงร่าง
สร้างเนื้อหาแต่ละส่วน
รวมและตรวจสอบผลลัพธ์รอบสุดท้าย

ประสิทธิภาพเป็นอย่างไร

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

งานเขียนโค้ด

Benchmark	คะแนน
SWE-Bench Pro	58.7%
DeepSWE v1.1	49%
Terminal-bench 2.1	78.0%

SWE-Bench Pro วัดความสามารถในการแก้ปัญหา GitHub จริงในคลังโค้ด ขณะที่ Terminal-bench วัดการทำงานผ่านคำสั่งใน terminal

งาน computer use

Gemini 3.6 Flash ทำคะแนน 83.0% บน OSWorld-Verified เพิ่มจาก 78.4% ของ Gemini 3.5 Flash ซึ่งสำคัญสำหรับทีมที่พัฒนา agent เพื่อควบคุมเดสก์ท็อปหรือแอปพลิเคชัน

คุณภาพงานระดับมืออาชีพ

Gemini 3.6 Flash มีคะแนน GDPVal-AA v2 Elo 1421 โดย GDPVal ใช้วัดประสิทธิภาพในงานระดับมืออาชีพจริง และคะแนน Elo ที่สูงกว่าหมายถึงโมเดลชนะในการเปรียบเทียบแบบตัวต่อตัวมากกว่า

การใช้บริบทยาว

ที่บริบท 128k tokens: การเรียกคืนข้อมูลเฉลี่ย 91.8%
ที่บริบทเต็ม 1M tokens: การเรียกคืนข้อมูลแบบจุดต่อจุดลดเหลือ 54.0%

ดังนั้น อย่าส่งข้อมูลขนาด 1M tokens แล้วคาดหวังว่าระบบจะค้นหารายละเอียดได้ครบทุกจุดเสมอไป ควรสร้างชุดทดสอบจากเอกสารและความยาวบริบทที่ระบบของคุณใช้จริง

ราคาโดยสรุป

รายการ	ราคา
อินพุต	$1.50 ต่อ 1M tokens
เอาต์พุต	$7.50 ต่อ 1M tokens
Context caching	$0.15 ต่อ 1M tokens
Cache storage	$1.00 ต่อ 1M tokens ต่อชั่วโมง

ราคาเอาต์พุตรวมโทเค็นการคิดด้วย แม้ reasoning บางส่วนจะไม่แสดงในคำตอบสุดท้าย แต่ยังถูกคิดค่าใช้จ่าย

Context caching เหมาะกับระบบที่ส่ง system prompt เอกสาร หรือข้อมูลอ้างอิงชุดเดิมซ้ำ ๆ ในหลายคำขอ

มีระดับฟรีผ่าน Google AI Studio แต่มี rate limit และ Google อาจใช้ข้อมูลจากระดับฟรีเพื่อปรับปรุงผลิตภัณฑ์ จึงควรใช้สำหรับ prototype มากกว่างาน production

อ่านเพิ่มเติมได้ที่:

วิธีเข้าถึง Gemini 3.6 Flash

คุณเข้าถึง Gemini 3.6 Flash ได้ผ่านช่องทางต่อไปนี้:

Gemini API ผ่าน Google AI Studio: รับ API key แล้วเรียกใช้ gemini-3.6-flash จาก REST client หรือ SDK
Google Antigravity: แพลตฟอร์มพัฒนา agent ของ Google
Gemini Enterprise Agent platform: สำหรับทีมที่ต้องการสร้าง agent พร้อมการกำกับดูแล
Gemini app: สำหรับใช้งานผ่านการสนทนาโดยตรง

สำหรับนักพัฒนา API คือช่องทางหลัก เริ่มต้นด้วยขั้นตอนนี้:

สร้าง API key ใน Google AI Studio
สร้างคำขอ POST โดยระบุ model ID เป็น gemini-3.6-flash
เก็บ API key ใน environment variable
ส่ง prompt และตรวจสอบ response schema
บันทึกคำขอเป็น regression test ก่อนเปลี่ยนโมเดลใน production

ดูรายละเอียดเพิ่มเติมใน วิธีใช้ Gemini 3.6 Flash API, คู่มือ Google Gemini 3 API และเอกสาร Gemini API อย่างเป็นทางการ

ตำแหน่งในผลิตภัณฑ์ของ Google

เลือกโมเดลตามคุณภาพที่ต้องการ ต้นทุน และ latency ที่ระบบรับได้

โมเดล	เหมาะกับงาน
Gemini 3.5 Flash-Lite	งานปริมาณมาก ความหน่วงต่ำ และไม่ต้องการคุณภาพสูงสุด
Gemini 3.6 Flash	งานทั่วไปที่ต้องการคุณภาพเชื่อถือได้ เช่น agent, coding, extraction และ chat
Gemini 3.5 Flash Cyber	งานด้านความปลอดภัยสำหรับผู้ที่ได้รับสิทธิ์เข้าถึง

Gemini 3.5 Flash-Lite มีราคา $0.30 สำหรับอินพุต และ $2.50 สำหรับเอาต์พุตต่อ 1M tokens พร้อมความเร็วประมาณ 350 โทเค็นขาออกต่อวินาที จึงเหมาะกับงานที่เน้นต้นทุนและ throughput

ส่วน Gemini 3.6 Flash เหมาะเมื่อ task ซับซ้อนขึ้น หรือผลลัพธ์ต้องมีความน่าเชื่อถือกว่าระดับ Lite

ข้อควรทราบ:

Gemini 3.5 Pro ยังไม่เปิดตัวสู่สาธารณะ โดย Google ระบุว่ายังทดสอบกับพันธมิตร
Google แย้มการฝึก Gemini 4 ล่วงหน้า แต่ยังไม่มีโมเดลให้เรียกใช้งาน
Gemini 3.6 Flash เป็นโมเดลระดับกลาง ไม่ใช่โมเดลเรือธงที่ทันสมัยที่สุด

สำหรับข้อมูลพื้นฐานของรุ่นก่อนหน้า ดู Gemini 3.5 คืออะไร

การทดสอบ Gemini 3.6 Flash ใน Apidog

อย่าตัดสินใจย้ายโมเดลจาก benchmark เพียงอย่างเดียว ให้ทดสอบกับ prompt, context length และ response format ที่ระบบของคุณใช้งานจริง

Apidog ช่วยส่งคำขอ REST, จัดการ environment variables และสร้าง regression test สำหรับ Gemini API ได้

ขั้นตอนตั้งค่า regression test

สร้างคำขอ POST ไปยัง Gemini API และกำหนด model เป็น gemini-3.6-flash
เก็บ API key ไว้ใน environment variable แทนการใส่ลงใน URL หรือ request โดยตรง
ส่งคำขอด้วย prompt ตัวแทนของ production
เพิ่ม assertions สำหรับ status code และฟิลด์ JSON ที่สำคัญ
บันทึกคำขอเป็น regression test
กำหนดเวลาให้รัน เพื่อตรวจจับการเปลี่ยนแปลงของ response หรือ latency

ตัวอย่างสิ่งที่ควรตรวจสอบในแต่ละรอบทดสอบ:

- HTTP status ต้องเป็น 200
- ฟิลด์ข้อความตอบกลับต้องมีค่า
- JSON response ต้องตรง schema ที่แอปพลิเคชันคาดหวัง
- เวลา response ต้องไม่เกินเกณฑ์ที่ทีมกำหนด
- ผลลัพธ์จาก prompt สำคัญต้องไม่เปลี่ยนจนกระทบ workflow

Apidog ไม่ได้รันโมเดลและไม่ใช่ AI framework แต่เป็นเครื่องมือสำหรับสร้าง ส่ง และตรวจสอบคำขอ API เมื่อ Google อัปเดตโมเดลในอนาคต regression test ที่บันทึกไว้จะช่วยบอกได้รวดเร็วว่า integration ของคุณเปลี่ยนไปหรือไม่

ดาวน์โหลด Apidog เพื่อเริ่มสร้างคำขอแรก

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

Gemini 3.6 Flash ฟรีหรือไม่?

มีระดับฟรีผ่าน Google AI Studio แต่มี rate limit และเหมาะกับการสร้าง prototype Google อาจใช้ข้อมูลจากระดับฟรีเพื่อปรับปรุงผลิตภัณฑ์ สำหรับ production จะคิดราคา $1.50 ต่อ 1M input tokens และ $7.50 ต่อ 1M output tokens

Gemini 3.6 Flash ดีกว่า Gemini 3.5 Flash หรือไม่?

สำหรับงานส่วนใหญ่ใช่ Gemini 3.6 Flash ใช้โทเค็นขาออกน้อยลงประมาณ 17% ลดราคาเอาต์พุตจาก $9.00 เหลือ $7.50 ต่อ 1M tokens และมีประสิทธิภาพด้าน coding กับ computer use ดีขึ้น รวมถึงคะแนน OSWorld-Verified ที่เพิ่มจาก 78.4% เป็น 83.0%

Gemini 3.5 Pro เปิดตัวแล้วหรือยัง?

ยังไม่เปิดตัว Google ระบุว่ายังคงทดสอบ Gemini 3.5 Pro กับพันธมิตร และ Gemini 4 ที่ถูกแย้มไว้ก็ยังไม่มีให้เรียกใช้

รหัสโมเดลคืออะไร?

ใช้รหัสนี้:

gemini-3.6-flash

อย่าสับสนกับ gemini-3.5-flash-lite ซึ่งเป็นโมเดล Flash-Lite ที่ราคาถูกกว่า

Gemini 3.6 Flash ทำอะไรไม่ได้บ้าง?

โมเดลสร้างเอาต์พุตเป็นข้อความเท่านั้น จึงไม่สามารถสร้างรูปภาพ เสียง หรือวิดีโอได้ แม้จะอ่านไฟล์เหล่านี้เป็นอินพุตได้

นอกจากนี้ ความแม่นยำด้านการเรียกคืนข้อมูลลดลงเมื่อใช้บริบทใกล้ขีดจำกัด 1M tokens โดยอยู่ที่ประมาณ 54.0% สำหรับการเรียกคืนข้อมูลแบบจุดต่อจุดที่ความยาวเต็ม

Gemini 3.6 Flash เหมาะสำหรับ workload Gemini API ส่วนใหญ่ที่ต้องการต้นทุนต่ำลง ใช้โทเค็นได้มีประสิทธิภาพขึ้น และรองรับงาน agent ได้ดีขึ้นกว่ารุ่นที่แทนที่ ก่อนย้ายระบบในวงกว้าง ให้บันทึก API tests สำหรับ prompt สำคัญและรันซ้ำอย่างสม่ำเสมอ

เว็บดาต้า API สำหรับนักพัฒนา: ทุกสิ่งที่คุณต้องรู้ในปี 2026

Thanawat Wongchai — Tue, 21 Jul 2026 18:53:50 +0000

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

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

ไม่ว่าจะเป็นแอปพยากรณ์อากาศแบบเรียลไทม์ แพลตฟอร์มอีคอมเมิร์ซที่แสดงสถานะสินค้า แดชบอร์ดการเงินที่ติดตามตลาด หรือแอป AI ที่ดึงข้อมูลภายนอก ประสบการณ์ดิจิทัลเหล่านี้ล้วนต้องพึ่งพาการแลกเปลี่ยนข้อมูลผ่าน API

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

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

Web Data API คืออะไร?

Web Data API คืออินเทอร์เฟซที่ช่วยให้แอปพลิเคชันเข้าถึงและแลกเปลี่ยนข้อมูลผ่านอินเทอร์เน็ตได้

แทนที่แอปจะเข้าถึงฐานข้อมูลของอีกระบบโดยตรง API จะเป็นชั้นสื่อสารที่ควบคุมระหว่างไคลเอนต์และแหล่งข้อมูลภายนอก

Application
      |
      v
 Web Data API
      |
      v
External Data Source

ตัวอย่างเช่น แอปพยากรณ์อากาศไม่ต้องดูแลฐานข้อมูลสภาพอากาศทั่วโลกเอง แต่สามารถเรียกข้อมูลจาก Weather API ได้

GET /weather?city=London

API ประมวลผลคำขอและส่งข้อมูลที่มีโครงสร้างกลับมา เช่น JSON:

{
  "city": "London",
  "temperature": 22,
  "condition": "Cloudy"
}

จากนั้นแอปพลิเคชันจึงนำข้อมูลไปแสดงผลหรือใช้ในตรรกะของระบบต่อไป

Web Data API ทำงานอย่างไร?

Web Data API ส่วนใหญ่ใช้รูปแบบ request-response ผ่าน HTTP โดยมีขั้นตอนหลัก 3 ส่วน

1. ไคลเอนต์ส่งคำขอ

แอปพลิเคชันไคลเอนต์ส่งคำขอไปยัง API endpoint โดยคำขออาจประกอบด้วย:

HTTP method
URL ของ endpoint
Headers
ข้อมูลการยืนยันตัวตน
Query parameters
Request body

ตัวอย่าง:

GET https://api.example.com/products
Authorization: Bearer token123

2. API ประมวลผลคำขอ

ฝั่ง API จะดำเนินการ เช่น:

ตรวจสอบการยืนยันตัวตน
ตรวจสอบสิทธิ์การเข้าถึง
ตรวจสอบและประมวลผลพารามิเตอร์
เรียกข้อมูลจากฐานข้อมูลหรือบริการภายนอก
ใช้ business logic

3. API ส่งคืนการตอบกลับ

API ส่งผลลัพธ์กลับมา โดยมักอยู่ในรูปแบบ JSON:

{
  "product": "Laptop",
  "price": 1200,
  "availability": true
}

ฝั่งไคลเอนต์ควรตรวจสอบทั้ง HTTP status code และโครงสร้างข้อมูลก่อนนำ response ไปใช้งาน

ประเภททั่วไปของ Web Data API

REST API

REST API เป็นรูปแบบ Web Data API ที่ใช้งานแพร่หลาย ใช้ HTTP method มาตรฐาน เช่น:

GET
POST
PUT
DELETE

ตัวอย่าง:

GET /users
POST /orders
DELETE /products/123

REST API มักตอบกลับเป็น JSON และพบได้บ่อยในเว็บและแอปมือถือ

GraphQL API

GraphQL ช่วยให้ไคลเอนต์ระบุฟิลด์ข้อมูลที่ต้องการได้อย่างชัดเจน โดยทั่วไปจะใช้ endpoint เดียว

{
  user {
    name
    email
  }
}

เหมาะกับแอปพลิเคชันที่ต้องการรูปแบบการดึงข้อมูลยืดหยุ่น

Web API สำหรับข้อมูลแบบเรียลไทม์

บางระบบต้องรับข้อมูลที่อัปเดตต่อเนื่อง เช่น:

ราคาหุ้น
ราคาสกุลเงินดิจิทัล
คะแนนกีฬา
การแจ้งเตือนสด

API กลุ่มนี้อาจใช้ WebSockets หรือการเชื่อมต่อแบบสตรีมมิง

การใช้งานทั่วไปของ Web Data API

แอปพลิเคชันทางการเงิน

แพลตฟอร์มการเงินใช้ API เพื่อเข้าถึง:

ข้อมูลตลาดหุ้น
อัตราแลกเปลี่ยน
การประมวลผลการชำระเงิน
ข้อมูลธนาคาร

ตัวอย่างเช่น แดชบอร์ดการเงินสามารถดึงข้อมูลตลาดแบบเรียลไทม์โดยไม่ต้องดูแลฐานข้อมูลการเงินเอง

แพลตฟอร์มอีคอมเมิร์ซ

ร้านค้าออนไลน์พึ่งพา API สำหรับ:

ข้อมูลสินค้า
การจัดการสินค้าคงคลัง
การชำระเงิน
การอัปเดตสถานะการจัดส่ง

แอปพลิเคชันปัญญาประดิษฐ์

แอป AI มักใช้ API เพื่อ:

เข้าถึงโมเดล AI
ดึงข้อมูลจากภายนอก
ค้นหาข้อมูล
เชื่อมต่อแหล่งความรู้

เมื่อระบบ AI เชื่อมต่อบริการมากขึ้น ความน่าเชื่อถือของ API integration ก็ยิ่งสำคัญ

บริการตำแหน่งและการทำแผนที่

แอปนำทางใช้ API สำหรับ:

แผนที่
พิกัดทางภูมิศาสตร์
เส้นทาง
การคำนวณระยะทาง

แพลตฟอร์มโซเชียล

API ของโซเชียลมีเดียอาจเปิดให้เข้าถึง:

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

ความท้าทายเมื่อทำงานกับ Web Data API

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

การยืนยันตัวตนและความปลอดภัย

API ส่วนใหญ่ต้องมีการยืนยันตัวตน วิธีที่พบได้บ่อย ได้แก่:

API keys
OAuth tokens
JWT authentication
Access tokens

อย่าฮาร์ดโค้ด credential ลงใน source code หรือ commit secret ลง repository ให้เก็บค่าเหล่านี้ใน environment variables หรือ secret manager แทน

API_KEY=your_secret_key

สำหรับ CI/CD ให้เก็บ token ใน repository secrets และส่งต่อเป็น environment variable ตอนรัน pipeline

การเปลี่ยนแปลงและการกำหนดเวอร์ชันของ API

API ภายนอกอาจเปลี่ยนแปลงเมื่อเวลาผ่านไป แม้เป็นการเปลี่ยนชื่อฟิลด์เพียงเล็กน้อยก็อาจทำให้แอปเสียหายได้

ตัวอย่าง response เดิม:

{
  "username": "developer"
}

เปลี่ยนเป็น:

{
  "user_name": "developer"
}

เพื่อลดผลกระทบ:

ตรวจสอบ schema ของ response
จัดการกรณีฟิลด์หายหรือชนิดข้อมูลไม่ตรง
ติดตามเอกสารและประกาศการเปลี่ยนแปลงของ API
รัน contract test ก่อน deploy

การทดสอบความน่าเชื่อถือของ API

การทดสอบ request ทุกตัวด้วยมือไม่เหมาะกับระบบขนาดใหญ่ ควรมี automated test เพื่อตรวจสอบว่า:

Response ถูกต้อง
การยืนยันตัวตนยังทำงาน
โครงสร้างข้อมูลสอดคล้องกับที่คาดไว้
การเปลี่ยนแปลงของ API ไม่ทำให้ flow สำคัญเสียหาย

อย่างน้อยแต่ละ test ควรตรวจสอบ status code และฟิลด์สำคัญใน response

if (response.status !== 200) {
  throw new Error(`Unexpected status: ${response.status}`);
}

if (!response.body.product) {
  throw new Error("Missing product field");
}

การจัดการเอกสารประกอบ

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

Endpoint ที่รองรับ
พารามิเตอร์ที่จำเป็นและไม่จำเป็น
วิธีการยืนยันตัวตน
รูปแบบ request และ response
HTTP status code
รูปแบบ error response
ข้อจำกัดอัตรา หรือ rate limits

แนวทางปฏิบัติที่ดีที่สุดสำหรับ Web Data API

1. อ่านเอกสาร API ก่อนเริ่มเชื่อมต่อ

ก่อนเขียนโค้ด ให้ตรวจสอบ:

Endpoint ที่ใช้งานได้
ข้อกำหนดการยืนยันตัวตน
Rate limits
รูปแบบ response
Error codes ที่อาจเกิดขึ้น

เริ่มจากทดลอง request ใน environment แยกก่อนเชื่อมเข้ากับ production flow

2. ใช้ Environment Variables สำหรับข้อมูลลับ

อย่าเก็บ API key หรือ token ในโค้ดโดยตรง:

API_KEY=your_secret_key

ตัวอย่างการเรียกใช้ใน Node.js:

const response = await fetch("https://api.example.com/products", {
  headers: {
    Authorization: `Bearer ${process.env.API_KEY}`
  }
});

3. ตรวจสอบ Response ของ API

อย่าคาดเดาว่า response จะมีโครงสร้างเดิมเสมอ ควรตรวจสอบ:

Status code
ฟิลด์ที่จำเป็น
ชนิดข้อมูล
รูปแบบ error

การตรวจสอบ response ช่วยตรวจจับ breaking change ได้ก่อนกระทบผู้ใช้

4. ทำให้การทดสอบ API เป็นอัตโนมัติ

ให้ test รันทุกครั้งเมื่อมีการเปลี่ยนแปลงโค้ดหรือ definition ของ API แทนการตรวจด้วยมือหลังแก้ไขแต่ละครั้ง

ควรมีอย่างน้อย:

Smoke test สำหรับ endpoint สำคัญ
Test การยืนยันตัวตน
Schema validation
Test flow หลายขั้นตอน เช่น login → create → fetch → verify

5. อัปเดตเอกสารให้สอดคล้องกับ API

เอกสารควรเปลี่ยนไปพร้อม implementation หาก endpoint, parameter หรือ response เปลี่ยน ควรอัปเดตเอกสารและ test ที่เกี่ยวข้องใน pull request เดียวกัน

ใช้ Apidog CLI สำหรับการทดสอบและระบบอัตโนมัติของ Web Data API

เมื่อ API workflow เติบโตขึ้น การส่ง request อย่างเดียวไม่เพียงพอ การพัฒนา API สมัยใหม่ต้องมีการตรวจสอบ การทดสอบ ระบบอัตโนมัติ และการทำงานร่วมกันตลอด lifecycle

Apidog CLI นำความสามารถของ Apidog มาใช้จาก terminal และ CI/CD pipeline ได้โดยตรง

นักพัฒนาสามารถใช้ CLI เพื่อจัดการทรัพยากร API เรียกใช้การทดสอบอัตโนมัติ ตรวจสอบ schema จัดการ environment และทำ workflow ซ้ำ ๆ ให้เป็นอัตโนมัติ โดยไม่ต้องออกจาก command line

การจัดการทรัพยากร API

จัดการทรัพยากรจาก terminal ได้ เช่น:

HTTP API endpoints
Schema
ทรัพยากรเอกสารประกอบ
API assets

แนวทางนี้ช่วยให้ definition ของ API อยู่ใน workflow การพัฒนาของทีมได้ชัดเจนขึ้น

การทดสอบ API อัตโนมัติ

Apidog CLI รองรับ:

กรณีทดสอบ (Test cases)
สถานการณ์ทดสอบ (Test scenarios)
ชุดทดสอบ (Test suites)
การดำเนินการแบบอัตโนมัติ

คุณสามารถรันการทดสอบในเครื่องระหว่างพัฒนา หรือเรียกใช้ผ่าน CI/CD pipeline ก่อน merge และ deploy

การจัดการสถานการณ์ทดสอบ

API workflow ที่ซับซ้อนมักมีหลายขั้นตอน เช่น:

ยืนยันตัวตนผู้ใช้
สร้างทรัพยากร
เรียกคืนทรัพยากร
ตรวจสอบ response

Apidog CLI รองรับสถานการณ์ทดสอบแบบหลายขั้นตอนด้วย:

การแยกตัวแปร
Assertions
Request chaining
การควบคุม flow

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

Login
  ↓
Extract access token
  ↓
Create resource
  ↓
Fetch resource
  ↓
Assert expected fields

การตรวจสอบ Schema

ก่อนสร้างหรืออัปเดตทรัพยากร API ให้ตรวจสอบไฟล์ JSON กับ schema ที่กำหนดไว้ล่วงหน้า

apidog cli-schema validate endpoint-create --file ./endpoint.json

การตรวจสอบนี้ช่วยจับปัญหาก่อนส่งการเปลี่ยนแปลง เช่น:

ฟิลด์ที่หายไป
ชนิดข้อมูลไม่ถูกต้อง
โครงสร้าง JSON ไม่ถูกต้อง

การจัดการสภาพแวดล้อมและตัวแปร

แต่ละ environment มักใช้ค่าการกำหนดค่าต่างกัน เช่น:

URL สำหรับ development
สภาพแวดล้อมทดสอบ
Endpoint สำหรับ production

Apidog CLI ช่วยจัดการ:

Environments
Variables
Runtime settings

ควรแยกค่าระหว่าง environment และหลีกเลี่ยงการใช้ production credential ในงานทดสอบ

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

โปรเจกต์ API อาจต้องย้ายข้อมูลระหว่างเครื่องมือ Apidog CLI รองรับการนำเข้าและส่งออกข้อมูล API หลายรูปแบบ เช่น:

OpenAPI
Postman
HAR
JMeter
WSDL
Markdown

ช่วยให้สามารถนำ API assets ที่มีอยู่มารวมเข้ากับ workflow ใหม่ได้ง่ายขึ้น

การติดตั้ง Apidog CLI

ติดตั้ง Apidog CLI ผ่าน npm:

npm install -g apidog-cli@latest

หลังติดตั้ง ให้ตรวจสอบว่าคำสั่งพร้อมใช้งาน:

apidog --help

การยืนยันตัวตนด้วย Apidog CLI

ก่อนเข้าถึงโปรเจกต์ส่วนตัว ให้ยืนยันตัวตนด้วย token:

apidog login --with-token <token>

CLI จะจัดเก็บข้อมูลการยืนยันตัวตนไว้ในเครื่องเพื่อใช้กับคำสั่งต่อไป

สำหรับ CI/CD ไม่ควรใส่ token ลงในไฟล์ pipeline โดยตรง ให้เก็บไว้ใน repository secrets แล้วอ้างอิงผ่าน environment variable

การเรียกใช้การทดสอบ API จาก Command Line

เรียกใช้ test scenario จาก terminal ได้โดยตรง:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <testScenarioId>

รูปแบบนี้ช่วยให้คุณใส่ API test เข้าไปใน workflow การพัฒนาอัตโนมัติได้ เช่น รันก่อน merge pull request หรือก่อน deploy

การรวมการทดสอบ Web Data API เข้ากับ CI/CD

ทีมสมัยใหม่ควรรัน API test ทุกครั้งที่มีการเปลี่ยนแปลงโค้ดหรือ configuration ที่เกี่ยวข้องกับ API

Apidog CLI สามารถทำงานร่วมกับ CI/CD platform เช่น:

GitHub Actions
GitLab CI/CD
Jenkins
Azure Pipelines
CircleCI
Bitbucket Pipelines

ตัวอย่างขั้นตอนที่ควรอยู่ใน pipeline:

Install dependencies
  ↓
Run unit tests
  ↓
Run API schema validation
  ↓
Run API test scenarios
  ↓
Deploy only when tests pass

แนวทางนี้ช่วยให้ทีมตรวจพบปัญหา API ก่อนเข้าสู่ production

Web Data API และอนาคตของการพัฒนา

API จะสำคัญมากขึ้นตามการเติบโตของ:

แอปพลิเคชัน AI
บริการคลาวด์
ไมโครเซอร์วิส
แอปพลิเคชันมือถือ
แพลตฟอร์มที่ขับเคลื่อนด้วยข้อมูล

นักพัฒนาจึงต้องก้าวข้ามการทดสอบ endpoint ด้วยมือ และนำแนวทางที่รองรับ schema validation, automation และ CI/CD integration มาใช้

เครื่องมือ command line มีประโยชน์เป็นพิเศษ เพราะสามารถทำงานร่วมกับ pipeline ระบบอัตโนมัติและสภาพแวดล้อมการพัฒนาสมัยใหม่ได้โดยตรง

ข้อคิดสุดท้าย

Web Data API คือรากฐานของแอปพลิเคชันสมัยใหม่ ช่วยให้ระบบเชื่อมต่อกัน ดึงข้อมูลจากภายนอก และสร้างประสบการณ์ผู้ใช้ที่สมบูรณ์ขึ้น

แต่ API integration ที่น่าเชื่อถือไม่ได้เกิดจากการส่ง HTTP request เพียงอย่างเดียว คุณต้องมีการจัดการ secret การตรวจสอบ response การทดสอบ schema เอกสารที่เป็นปัจจุบัน และ automated test ที่รันได้ใน CI/CD

เมื่อรวมแนวทางเหล่านี้เข้ากับเครื่องมืออัตโนมัติ เช่น Apidog CLI ทีมจะลดงานทดสอบด้วยมือ ตรวจพบปัญหาได้เร็วขึ้น และรักษาคุณภาพของ API ได้ดีขึ้นเมื่อระบบเติบโต

เครื่องมือ API ยังจำเป็นอยู่ไหมในยุคเอไอเอเจนต์

Thanawat Wongchai — Tue, 21 Jul 2026 10:18:22 +0000

คุณให้ Cursor สร้างเอนด์พอยต์ ให้ Copilot เติมเนื้อหาคำขอ ให้ Claude Code เขียนและรันการทดสอบหนึ่งรอบ คำถามที่ตามมาคือ: เมื่อเอเจนต์ทำงานเหล่านี้ได้แล้ว เรายังต้องมีเครื่องมือ API โดยเฉพาะหรือไม่?

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

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

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

เกิดอะไรขึ้นเมื่อเอเจนต์เข้าสู่ขั้นตอนการทำงาน

เดิมไคลเอนต์ API คือพื้นที่ทำงานแบบแมนนวล: พิมพ์ URL, ตั้ง header, วาง token, บันทึกคำขอ และเขียน assertion

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

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

สำหรับ API จุดคอขวดจึงเปลี่ยนจาก “เขียนคำขอ” เป็น “เชื่อถือสิ่งที่ถูกสร้างขึ้น”

สี่งานที่เอเจนต์ AI ไม่ได้แบ่งเบาภาระของคุณ

งาน	เอเจนต์ทำได้เอง?	สิ่งที่ยังต้องการเครื่องมือ
ร่างคำขอหรือการทดสอบเบื้องต้น	ใช่ ทำได้ดี	พื้นที่สำหรับรัน บันทึก และรันซ้ำ
รันชุดทดสอบและควบคุม CI เมื่อผ่านหรือไม่ผ่าน	ไม่ ผลลัพธ์อาจต่างกัน	รันเนอร์แบบกำหนดผลได้ในไปป์ไลน์
เก็บสเปก API เป็นแหล่งความจริง	ไม่ อาจคลาดเคลื่อน	ที่เก็บสเปกที่เอเจนต์อ่านได้
สร้างการเรียกใช้ที่ล้มเหลวซ้ำสำหรับมนุษย์	ไม่	ประวัติคำขอที่ตรวจสอบได้
จำลอง upstream 500, 429 หรือ timeout	บางส่วน	เซิร์ฟเวอร์จำลองที่ควบคุมได้
ตัดสินว่าสัญญาถูกต้อง	ไม่	มนุษย์ร่วมกับการยืนยัน

สี่งานที่ตอบว่า “ไม่” คือจุดที่ยังควรเก็บเครื่องมือ API ไว้ในเวิร์กโฟลว์

1. รันและควบคุมการทดสอบอย่างเด็ดขาด

เอเจนต์มีลักษณะ probabilistic หากสั่งให้รันงานเดิมสองครั้ง คุณอาจได้สรุปหรือคำตัดสินคนละแบบ นี่เหมาะกับการสำรวจ แต่ไม่เหมาะกับ merge gate ที่คอมมิตเดียวกันควรให้ผลผ่านหรือไม่ผ่านแบบเดิมทุกครั้ง

แนวทางที่ใช้งานได้จริงคือแยกหน้าที่ให้ชัดเจน:

ให้เอเจนต์ร่าง test case หรือ assertion
บันทึก test case ไว้ในโปรเจกต์
ให้ CI รันชุดทดสอบทุก pull request
ให้ exit code เป็นตัวตัดสินว่าจะ merge ได้หรือไม่

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

- name: Run API tests
  run: apidog-cli run --environment ci

คำถามตรวจสอบง่าย ๆ คือ: หากสัญญา API เสีย ระบบทำให้บิลด์ล้มเหลวได้โดยไม่มีคนเฝ้าหรือไม่?

หากมีเพียงเอเจนต์ในหน้าต่างแชทที่รันการทดสอบ คำตอบคือไม่ เพราะไม่มีใครรับประกันว่าจะรันแชทซ้ำในทุก pull request แต่รันเนอร์ใน CI ที่คืน exit code จริงทำได้

Apidog CLI ในเวิร์กโฟลว์เอเจนต์หรือ CI ใช้รันเคสทดสอบที่บันทึกไว้แบบ headless ส่งคืน exit code และทำให้บิลด์ล้มเหลวเมื่อสัญญาเสีย สำหรับรายละเอียดเรื่อง failure mode ดู ทำไมเอเจนต์ AI จึงล้มเหลวในการผลิต

2. เก็บสัญญา API ไว้เป็นแหล่งความจริง

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

วิธีแก้ไม่ใช่เพียงเขียน prompt ให้ดีขึ้น แต่คือให้เอเจนต์เข้าถึงสเปกจริงผ่าน Model Context Protocol

ตัวอย่าง:

เอเจนต์อาจเดาว่า API การชำระเงินใช้ POST /v1/charges
แต่ API จริงของคุณอาจใช้ POST /v1/payments
และอาจต้องมี idempotency header รวมถึง request body คนละรูปแบบ

เมื่อเชื่อมสเปกผ่าน MCP เอเจนต์จะอ่าน path, schema และข้อกำหนดการยืนยันตัวตนก่อนเขียนโค้ด ลดข้อผิดพลาดตั้งแต่ขั้นตอนสร้างงาน

Apidog MCP Server ทำให้คำจำกัดความ OpenAPI พร้อมใช้งานสำหรับ Cursor, Copilot, Claude Code หรือ Cline:

npx apidog-mcp-server

แนวทางนี้ใช้กับคำจำกัดความ OpenAPI ที่ทีมดูแลอยู่แล้ว และคำสั่งนี้ไม่ต้องมีบัญชีเพื่อเริ่มทดลอง ดูตัวอย่างเพิ่มใน การเขียนโค้ดด้วย Apidog MCP Server และ ยังต้องใช้ API client หรือไม่เมื่อเขียนโค้ดใน AI IDE

3. จำลองความล้มเหลวที่เอเจนต์ต้องเอาชีวิตรอด

API จริงอาจตอบกลับ:

429 เมื่อถูก rate limit
500 ระหว่าง incident
timeout เมื่อบางภูมิภาคมีปัญหา

โค้ดที่เอเจนต์สร้างต้องรับมือกับแต่ละกรณี เช่น retry, backoff หรือ fallback แต่คุณทดสอบเส้นทางเหล่านี้ไม่ได้หาก sandbox ตอบ 200 OK ตลอดเวลา

ให้ชี้โค้ดไปยัง mock server ที่ควบคุมได้ แล้วบังคับผลลัพธ์ที่ต้องการ:

GET /upstream-resource
→ 500 Internal Server Error

จากนั้นตรวจสอบว่าแอปทำสิ่งที่คาดหวังหรือไม่:

429 → รอและลองใหม่ตาม backoff
500 → ใช้ fallback หรือแสดงข้อผิดพลาดที่เหมาะสม
timeout → ยกเลิกคำขอและคืนค่าที่จัดการได้

Apidog smart mock ช่วยส่งคืน response เหล่านี้โดยไม่ต้องตั้งเซิร์ฟเวอร์ที่เสียขึ้นมาเอง ดูแนวทางเพิ่มเติมใน การทดสอบ API ด้วยเอเจนต์ AI

4. ดูสิ่งที่เอเจนต์ส่งไปจริง

เมื่อ API call ล้มเหลว สรุปจากเอเจนต์ไม่ใช่หลักฐานบนเครือข่าย คุณต้องตรวจดูข้อมูลดิบ เช่น:

request header
request body
status code
response body
ลำดับของการเรียกใช้

เอเจนต์อาจ “คิด” ว่าส่ง token ถูกต้อง แต่ไคลเอนต์จริงอาจส่ง token ที่หมดอายุ ความต่างนี้จะเห็นได้เมื่ออ่าน request และ response จริงเท่านั้น

Apidog เก็บประวัติคำขอ และ Apidog AI Agent Debugger ช่วยไล่ดูการทำงานของเอเจนต์ทีละขั้น ทั้ง LLM call, MCP tool call และการแลกเปลี่ยนหลายรอบ

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

สิ่งที่เอเจนต์แทนที่ได้จริง

เอเจนต์ลดงานซ้ำ ๆ ได้จริง โดยเฉพาะ:

การพิมพ์คำขอ CRUD ทั่วไปด้วยมือ
โค้ดไคลเอนต์ boilerplate ในภาษาที่ทีมใช้
ร่างแรกของ test หรือ mock
การค้นหาเอนด์พอยต์ที่ถูกต้อง เมื่อเชื่อมสเปกผ่าน MCP

ดังนั้น API client แบบแมนนวลในฐานะ “พื้นที่พิมพ์คำขอ” จึงสำคัญน้อยลงกว่าปี 2020 แต่เวิร์กโฟลว์ API ไม่ได้หายไป มันเปลี่ยนจากการสร้างด้วยมือไปสู่การตรวจสอบผลลัพธ์จากเอเจนต์

เมื่อคุณอาจไม่จำเป็นต้องมีเครื่องมือ API โดยเฉพาะ

คุณอาจข้ามแพลตฟอร์ม API เต็มรูปแบบได้เมื่อ:

เขียนสคริปต์ใช้ครั้งเดียว และ curl คำสั่งเดียวเพียงพอ
สร้าง prototype คนเดียว มีเพียง 2–3 เอนด์พอยต์
ไม่มีทีมอื่นหรือบริษัทอื่นต้องพึ่งพาสัญญา API ของคุณ

ในกรณีเหล่านี้ เอเจนต์ร่วมกับ curl อาจเพียงพอ และแพลตฟอร์มเต็มรูปแบบอาจเกินความจำเป็น

แต่ควรเพิ่มเครื่องมือเฉพาะเมื่อความเสี่ยงเพิ่มขึ้น เช่น:

API ถูกส่งต่อให้ผู้ใช้หรือทีมอื่น
มี CI และ merge gate
ทีมอื่นพัฒนาต่อบนสัญญาของคุณ
response ที่ผิดพลาดสร้างต้นทุนหรือผลกระทบต่อระบบ

Apidog มีบทบาทอย่างไรในเวิร์กโฟลว์ของเอเจนต์

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

ในเวิร์กโฟลว์นี้ Apidog ใช้สำหรับ:

รัน test ที่เอเจนต์ร่างไว้
จัดเก็บสเปกที่เอเจนต์อ่านผ่าน MCP
จำลอง failure response ที่โค้ดต้องรับมือ
ตรวจสอบ request และ response เมื่อเกิดปัญหา

เริ่มต้นโดยไม่ต้องมีบัญชีได้ด้วย:

npx apidog-mcp-server

จากนั้นใช้ CLI ใน CI เพื่อรันการทดสอบแบบ headless

หากกำลังเปรียบเทียบเครื่องมือ ดู Apidog เทียบกับ Postman สำหรับการทดสอบ API ด้วย AI และ LLM หรือ 30 เครื่องมือทดสอบ API ที่ดีที่สุด รวมถึงบทความ Postman ตายแล้วหรือไม่ในปี 2026 และ เครื่องมือทดสอบ API ที่ดีที่สุดสำหรับเอเจนต์ AI

ดาวน์โหลด Apidog เพื่อทำตามขั้นตอนข้างต้น โดยแผนฟรีครอบคลุมความสามารถที่กล่าวถึงในบทความนี้

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

เอเจนต์ AI สามารถแทนที่การทดสอบ API ได้ทั้งหมดหรือไม่?

ไม่ได้ เอเจนต์ร่างการทดสอบได้ดี แต่การรันแบบกำหนดผลได้และการควบคุม merge จากผลทดสอบต้องใช้รันเนอร์ที่เสถียร ส่วนการตัดสินว่าสัญญาถูกต้องยังต้องอาศัยมนุษย์และการยืนยัน

ฉันยังต้องใช้ Postman หรือ Apidog หรือไม่ หากใช้ Cursor หรือ Copilot?

โดยทั่วไปยังต้องใช้ สำหรับงานที่เอเจนต์ใน IDE ไม่ครอบคลุม:

ป้อนสเปก API จริงให้เอเจนต์ผ่าน Apidog MCP Server
รันการทดสอบที่ได้ใน CI

เอเจนต์เขียนการเรียกใช้ได้ แต่คุณยังต้องมีระบบตรวจสอบ

ไคลเอนต์ API ตายแล้วหรือไม่?

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

“การตรวจสอบที่เด็ดขาด” หมายถึงอะไร?

อินพุตเดียวกันต้องให้ผลผ่านหรือไม่ผ่านเหมือนเดิมทุกครั้งที่รัน นี่คือสิ่งที่ CI ต้องพึ่งพา แต่เอเจนต์อาจให้ผลต่างกันในแต่ละรอบ จึงไม่ควรใช้เอเจนต์เองเป็น merge gate

Apidog ทำงานได้โดยไม่ต้องมีบัญชีหรือไม่?

ส่วนที่ใช้กับเอเจนต์ทำได้ npx apidog-mcp-server และ Apidog CLI ทำงานแบบ headless โดยไม่ต้องเข้าสู่ระบบ จึงเชื่อมเข้ากับเอเจนต์หรือไปป์ไลน์ก่อน แล้วค่อยลงชื่อเข้าใช้ภายหลังได้

คำถามที่แท้จริง

ประเด็นไม่ใช่ “เครื่องมือหรือเอเจนต์” แต่คือการแบ่งหน้าที่ให้ถูกต้อง

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

เก็บทั้งสองส่วนไว้ และให้แต่ละส่วนทำงานที่มันทำได้ดีที่สุด

เริ่มจาก npx apidog-mcp-server และ Apidog CLI หรือ ลองใช้ Apidog ฟรี

การกู้คืนข้อผิดพลาด AI Agent: รูปแบบ Retry, Timeout, Backoff และ Circuit Breaker

Thanawat Wongchai — Tue, 21 Jul 2026 08:57:18 +0000

เอเจนต์ของคุณเรียกใช้ API แล้วได้รับสถานะ 429 Too Many Requests จึงพยายามเรียกซ้ำทันที ได้ 429 อีกครั้ง แล้ววนซ้ำต่อไปจนงานหยุดลงหรือค่าใช้จ่ายพุ่งสูงขึ้น ไม่มีใครตั้งใจเขียนวงจรแบบนี้ แต่มันมักเกิดจากการจัดการข้อผิดพลาดแบบตรงไปตรงมาเกินไป และเป็นปัญหาที่พบบ่อยในกระดานสนทนา Anthropic SDK

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

การกู้คืนข้อผิดพลาดคือสิ่งที่แยกเดโมที่ดูดีออกจากเอเจนต์ที่พร้อมใช้งานจริง ปัญหาไม่ได้อยู่ที่โมเดล แต่อยู่ที่โค้ดของคุณทำอะไรเมื่อ tool call ช้า ถูกจำกัดอัตรา หรือใช้งานไม่ได้ หากออกแบบถูกต้อง dependency ที่ไม่เสถียรจะกลายเป็นเพียงการหยุดชั่วคราวที่ผู้ใช้แทบไม่สังเกตเห็น แต่หากออกแบบผิด สถานะ 500 ครั้งเดียวอาจลุกลามเป็น incident ได้

บทความนี้ครอบคลุม 4 รูปแบบหลักสำหรับการกู้คืน:

Retry ด้วย Exponential Backoff และ Jitter
Timeout สำหรับทุกการเรียกออก
Circuit Breaker
Idempotency Key

จากนั้นจะนำทั้งหมดไปทดสอบกับ Mock API ก่อนที่ผู้ใช้จริงจะพบช่องโหว่ สำหรับภาพรวมเพิ่มเติมเกี่ยวกับความล้มเหลวของเอเจนต์ AI ใน production โปรดดูสาเหตุที่เอเจนต์ AI พังในการใช้งานจริง

คุณไม่สามารถทดสอบการกู้คืนกับ API ที่ทำงานปกติได้

นี่คือกับดักที่พบบ่อย: dependency ทำงานปกติใน development คุณเขียนเอเจนต์ การเรียกสำเร็จ เดโมผ่าน แล้วจึง deploy แต่โค้ด recovery ไม่เคยถูกเรียกใช้งานเลย เพราะ API ไม่ได้ส่ง error ที่คุณต้องจัดการ

ผลคือครั้งแรกที่ retry, timeout หรือ circuit breaker ทำงาน คือระหว่าง incident จริงที่มีผู้ใช้กำลังรออยู่

แนวทางที่ถูกต้องคือต้องสร้าง failure โดยตั้งใจ:

สร้าง Mock ของ API ที่เอเจนต์เรียกใช้
กำหนดให้ Mock ส่งกลับ 429, 500, timeout หรือ response body ที่ผิดรูปแบบ
ชี้ tool ของเอเจนต์ไปยัง Mock แทน service จริง
ตรวจสอบว่าเอเจนต์ retry, back off, หยุด retry หรือส่ง error กลับอย่างไร

ด้วยวิธีนี้ failure จะเป็นสิ่งที่คุณเรียกใช้ได้ใน test suite แทนที่จะเป็นสิ่งที่ปลุกคุณตอนตี 3 คุณสามารถใช้Apidogเพื่อสร้าง Mock และกำหนด response sequence สำหรับสถานการณ์เหล่านี้

Retry ด้วย Exponential Backoff และ Jitter

Retry คือแนวป้องกันแรก แต่ retry แบบ “เจอ error แล้วเรียกใหม่ทันที” คือกับดัก

เมื่อบริการกำลังรับภาระสูง ไคลเอ็นต์ที่ล้มเหลวทุกตัวจะ retry พร้อมกัน ทำให้ dependency ถูกถล่มหนักกว่าเดิม ปัญหานี้มักเรียกว่า retry storm

ให้ใช้ 2 เทคนิคคู่กัน:

Exponential Backoff: เพิ่มเวลารอเป็นลำดับ เช่น 1, 2, 4, 8 วินาที
Jitter: เพิ่มค่าสุ่มในเวลารอ เพื่อไม่ให้ไคลเอ็นต์จำนวนมาก retry พร้อมกัน

ตัวอย่าง Python สำหรับ retry ที่มีเพดานจำนวนครั้งและเพดาน delay:

import random
import time
import requests

MAX_RETRIES = 4
MAX_DELAY_SECONDS = 30

def retry_delay(attempt: int) -> float:
    base_delay = min(2 ** attempt, MAX_DELAY_SECONDS)
    jitter = random.uniform(0, base_delay * 0.25)
    return base_delay + jitter

def call_api(url: str, payload: dict):
    for attempt in range(MAX_RETRIES):
        try:
            response = requests.post(
                url,
                json=payload,
                timeout=(3, 10),  # connect timeout, read timeout
            )

            if response.status_code == 429:
                retry_after = response.headers.get("Retry-After")
                if retry_after:
                    delay = float(retry_after)
                else:
                    delay = retry_delay(attempt)

                time.sleep(delay)
                continue

            if 500 <= response.status_code < 600:
                time.sleep(retry_delay(attempt))
                continue

            response.raise_for_status()
            return response.json()

        except requests.exceptions.Timeout:
            time.sleep(retry_delay(attempt))

    raise RuntimeError("API call failed after maximum retry attempts")

ควรจำกัด 2 ค่าเสมอ:

จำนวนครั้งที่ retry เพื่อไม่ให้ permanent failure กลายเป็น loop
เวลารอสูงสุด เพื่อไม่ให้ผู้ใช้ต้องรอหลายนาที

โดยทั่วไป retry ประมาณ 3–5 ครั้งมักเพียงพอสำหรับ transient error หากมากกว่านั้น คุณอาจกำลัง retry สิ่งที่ไม่มีทางสำเร็จ

Anthropic SDK มีการ retry สำหรับบาง error ของการเรียก SDK เองด้วย Exponential Backoff และกำหนดจำนวนครั้งได้ผ่าน max_retries แต่ไม่ได้ครอบคลุม API อื่นที่ tool ของเอเจนต์เรียกใช้ คุณยังต้องนำรูปแบบนี้ไปใช้กับ dependency ของคุณเอง

สำหรับตัวอย่างความเสียหายที่เกิดจาก retry ที่ออกแบบไม่ดี โปรดดูตรรกะการลองใหม่สำหรับ API ที่มีความเสี่ยงสูง

ตั้งค่า Timeout ในทุกการเรียกใช้

Retry ช่วยได้เมื่อ request ล้มเหลว แต่กรณีที่แย่กว่าคือ request ที่ไม่ตอบกลับเลย

Dependency อาจรับ connection แล้วค้างอยู่โดยไม่ส่ง response หากไม่มี timeout tool call จะ block และ workflow ทั้งหมดอาจหยุดอยู่บน socket เดียว ไม่มี error ไม่มี retry และไม่มี recovery

ทุก outbound call ควรมีอย่างน้อย 3 ระดับ:

Connect timeout — เวลาสูงสุดสำหรับการเปิด connection
Read timeout — เวลาสูงสุดสำหรับการรอ response
Operation deadline — งบเวลารวมของงานหรือ workflow ทั้งหมด

ตัวอย่างด้วย httpx:

import httpx

timeout = httpx.Timeout(
    connect=3.0,
    read=10.0,
    write=10.0,
    pool=5.0,
)

with httpx.Client(timeout=timeout) as client:
    response = client.get("https://api.example.com/search")
    response.raise_for_status()

หากคุณมี agent workflow หลายขั้นตอน ให้กำหนด deadline ระดับงานด้วย ตัวอย่างเช่น หากผู้ใช้รอได้สูงสุด 30 วินาที อย่าปล่อยให้ tool call เดียวใช้เวลา 25 วินาที แล้วให้ retry อีกหลายครั้งจนเกินงบ

เลือก timeout จาก latency จริง ไม่ใช่การเดา:

ใช้ค่า p99 ของ dependency เป็นจุดเริ่มต้น
เพิ่ม buffer สำหรับ network variability
อย่าตั้งสั้นเกินไปจนตัด request ที่ควรสำเร็จ
อย่าตั้งนานเกินไปจน dependency ที่ค้างทำให้ agent ใช้งานไม่ได้

สำหรับ streaming response ควรมี timeout แยกต่างหาก เพราะงาน streaming ที่ใช้เวลานานอาจเป็นพฤติกรรมปกติ

ใช้ Circuit Breaker เมื่อ Dependency ล่ม

Backoff เหมาะสำหรับบริการที่กำลังยุ่งชั่วคราว แต่ไม่เหมาะกับบริการที่ล่มต่อเนื่อง

หาก dependency ล้มเหลวมาหลายนาที request ถัดไปก็มักจะล้มเหลวเช่นกัน การ retry ต่อไปจึงเพิ่มภาระให้ระบบที่เสียอยู่แล้ว และบังคับให้ผู้ใช้รอ timeout ที่คาดเดาได้

Circuit Breaker มี 3 สถานะ:

Closed: สถานะปกติ Request ผ่านได้ และระบบนับ failure
Open: เมื่อ failure เกินเกณฑ์ ระบบหยุดส่ง request ไปยัง dependency และ fail fast
Half-open: หลังช่วง cool-down ระบบอนุญาต probe request หนึ่งครั้ง หากสำเร็จจึงกลับไป Closed หากล้มเหลวจะกลับไป Open

แนวคิดแบบย่อ:

class CircuitBreaker:
    def __init__(self, failure_threshold=5):
        self.failure_threshold = failure_threshold
        self.failures = 0
        self.state = "closed"

    def allow_request(self):
        return self.state != "open"

    def record_success(self):
        self.failures = 0
        self.state = "closed"

    def record_failure(self):
        self.failures += 1
        if self.failures >= self.failure_threshold:
            self.state = "open"

ใน production คุณต้องเพิ่ม cool-down timer และ half-open probe แต่หลักสำคัญคือ:

สร้าง Circuit Breaker แยกตาม dependency ไม่ใช่สร้างตัวเดียวทั่วทั้งเอเจนต์

ตัวอย่าง: หาก Search API ล่ม เอเจนต์ยังควรเรียก Billing API ที่ทำงานปกติได้

สำหรับเอเจนต์ Circuit Breaker จะเปลี่ยน “Payment API ล่ม” ให้เป็น error ที่รวดเร็วและวิเคราะห์ได้ แทนที่จะปล่อยให้ workflow เสียเวลา timeout ซ้ำหลายครั้งจนใช้งบ token และเวลาหมด

ทำให้ Retry ปลอดภัยด้วย Idempotency Key

Retry จะปลอดภัยก็ต่อเมื่อ operation นั้นทำซ้ำได้อย่างปลอดภัย แต่ request ที่เปลี่ยนแปลงสถานะมักไม่เป็นเช่นนั้น

ตัวอย่าง:

เอเจนต์ส่ง POST /charge
Server ประมวลผลการชำระเงินสำเร็จ
Response timeout ระหว่างส่งกลับ
เอเจนต์คิดว่า request ล้มเหลวและ retry
ลูกค้าถูกเรียกเก็บเงิน 2 ครั้ง

ปัญหาไม่ใช่ retry ทำงานผิด แต่เป็น request ถูกออกแบบโดยไม่มี idempotency

ให้สร้าง Idempotency Key หนึ่งค่า สำหรับหนึ่ง logical operation แล้วส่งไปใน header:

import uuid
import requests

idempotency_key = str(uuid.uuid4())

response = requests.post(
    "https://api.example.com/charge",
    json={
        "customer_id": "cus_123",
        "amount": 500,
    },
    headers={
        "Idempotency-Key": idempotency_key,
    },
    timeout=(3, 10),
)

ข้อสำคัญคือสร้าง key ก่อนเข้าสู่ retry loop:

import uuid

idempotency_key = str(uuid.uuid4())

for attempt in range(3):
    response = requests.post(
        "https://api.example.com/charge",
        json=payload,
        headers={"Idempotency-Key": idempotency_key},
        timeout=(3, 10),
    )

อย่าสร้าง key ใหม่ในการ retry แต่ละครั้ง:

# ไม่ถูกต้อง: retry แต่ละครั้งมี key ใหม่
for attempt in range(3):
    requests.post(
        "https://api.example.com/charge",
        headers={"Idempotency-Key": str(uuid.uuid4())},
    )

Server ต้องบันทึก key ที่พบครั้งแรก และเมื่อได้รับ key เดิมอีกครั้ง ต้องส่งผลลัพธ์เดิมกลับแทนการทำ operation ซ้ำ

ใช้ Idempotency Key กับทุก request ที่สร้างหรือแก้ไข state เช่น:

การชำระเงิน
การสร้างคำสั่งซื้อ
การส่งอีเมลหรือข้อความ
การสร้าง record
การอัปเดตข้อมูลสำคัญ

สำหรับการเรียก read-only เช่น GET /users/123 โดยทั่วไป retry ได้โดยไม่ต้องใช้ key

ดูรายละเอียดฝั่ง server ได้ในคู่มือIdempotency Keys

รับมือ Rate Limits และวงจร `RateLimitError`

Rate limit ต้องได้รับการจัดการเป็นกรณีพิเศษ เพราะ server มักส่งคำแนะนำมาให้แล้ว

Response 429 มักมี header Retry-After ซึ่งระบุเวลาที่ควรรอก่อน retry เช่น:

HTTP/1.1 429 Too Many Requests
Retry-After: 30

หาก server บอกให้รอ 30 วินาที แต่คุณ retry ใน 2 วินาที คุณก็จะได้ 429 อีกครั้ง และสร้าง RateLimitError loop:

ได้ 429
retry เร็วเกินไป
ได้ 429 อีกครั้ง
ถูกจำกัดหนักขึ้น
วนซ้ำจน workflow ล้มเหลว

ดูรายละเอียดเพิ่มเติมได้ที่คู่มือแก้ไข Rate Limit Exceededและเธรด Anthropic SDK นี้

ลำดับการจัดการที่ควรใช้คือ:

def get_retry_delay(response, attempt):
    retry_after = response.headers.get("Retry-After")

    if retry_after is not None:
        return float(retry_after)

    return retry_delay(attempt)

หลักการคือ:

ถ้ามี Retry-After ให้เคารพค่าจาก server
ถ้าไม่มี ให้ fallback ไปใช้ Exponential Backoff + Jitter
จำกัดจำนวน retry เพื่อให้ sustained rate limit จบด้วย error ที่ชัดเจน
อย่ารอแบบไม่มีที่สิ้นสุด

นอกจากนี้ควรป้องกันเชิงรุกด้วย rate limiter ฝั่ง client เช่น Token Bucket เพื่อควบคุมความเร็ว request ของตัวเองให้อยู่ภายใต้ quota ของ provider

Recovery ช่วยจัดการ rate limit ที่เกิดขึ้นแล้ว ส่วน pacing ช่วยไม่ให้คุณไปชน rate limit ตั้งแต่แรก

วิธีทดสอบเส้นทางการกู้คืน

รูปแบบ recovery จะมีค่าเมื่อคุณพิสูจน์ได้ว่ามันทำงานจริง โดยต้องใช้ Mock API ที่สร้าง failure ตามคำสั่งได้

นำ flow ต่อไปนี้ไปใช้กับทุก dependency:

สร้าง Mock ของ dependency

Mock API ที่ tool ของเอเจนต์เรียกใช้ เพื่อควบคุม status code, header, response body และ delay ได้ทั้งหมด โดยไม่ต้องเรียกเก็บเงินจริงหรือส่งอีเมลจริง
กำหนด response sequence

ตั้งค่าให้ endpoint เดียวตอบกลับตามลำดับ:
- ครั้งที่ 1: 429 พร้อม Retry-After: 2
- ครั้งที่ 2: 500
- ครั้งที่ 3: 200 พร้อม body ที่ถูกต้อง
ชี้เอเจนต์ไปยัง Mock

เปลี่ยน base URL ของ tool จาก service จริงเป็น Mock URL
ยืนยันพฤติกรรม

ตรวจสอบว่าเอเจนต์:
- รออย่างน้อย 2 วินาทีหลัง 429
- retry หลัง 500
- สำเร็จในการเรียกครั้งที่ 3
- ไม่เกินจำนวน retry ที่กำหนด

ตัวอย่าง pseudo-test:

def test_agent_recovers_from_429_then_500(mock_api, agent):
    mock_api.sequence([
        {
            "status": 429,
            "headers": {"Retry-After": "2"},
        },
        {
            "status": 500,
            "body": {"error": "temporary failure"},
        },
        {
            "status": 200,
            "body": {"result": "success"},
        },
    ])

    started_at = time.time()
    result = agent.run()
    elapsed = time.time() - started_at

    assert result["result"] == "success"
    assert elapsed >= 2
    assert mock_api.request_count == 3

เพิ่ม test อีกอย่างน้อย 3 กลุ่ม:

1. Give-up path

กำหนดให้ Mock ล้มเหลวทุกครั้ง แล้วตรวจสอบว่าเอเจนต์หยุดเมื่อถึง retry limit และส่ง error ที่ชัดเจน

def test_agent_stops_after_retry_limit(mock_api, agent):
    mock_api.always_return(status=500)

    with pytest.raises(RuntimeError):
        agent.run()

    assert mock_api.request_count == 4

2. Circuit Breaker path

กำหนดให้ request ติดต่อกันล้มเหลว แล้วตรวจสอบว่า circuit เปิดและ request ถัดไป fail fast แทนการรอ timeout ทุกครั้ง

3. Idempotency path

กำหนดให้ Mock รับ mutating request สำเร็จ แต่ตัด response ทิ้งเพื่อให้ client คิดว่า timeout จากนั้นให้เอเจนต์ retry แล้วตรวจสอบว่า:

Request ทั้งสองมี Idempotency-Key เดียวกัน
Server ประมวลผล logical operation เพียงครั้งเดียว
ไม่มีการสร้าง charge, order หรือ record ซ้ำ

แนวทางที่ครอบคลุมกว่านี้อยู่ในคู่มือทดสอบเอเจนต์ที่เรียกใช้ API ของคุณ

รายการตรวจสอบการกู้คืนข้อผิดพลาด

ก่อน deploy เอเจนต์ ให้ตรวจสอบรายการนี้:

[ ] Outbound call ทุกตัวมี connect timeout, read timeout และ operation deadline
[ ] Retry ใช้ Exponential Backoff พร้อม Jitter
[ ] Retry มีเพดานทั้งจำนวนครั้งและเวลารอสูงสุด
[ ] Response 429 อ่านและเคารพ Retry-After
[ ] Circuit Breaker แยกตาม dependency
[ ] Mutating request ทุกตัวมี Idempotency Key ที่คงที่ตลอด retry
[ ] Give-up path ส่ง error ที่ชัดเจน ไม่ใช่ loop หรือการรอไม่สิ้นสุด
[ ] Recovery flow ทุกแบบมี test ที่บังคับให้เกิด failure ผ่าน Mock

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

Apidog เหมาะกับอะไร และไม่เหมาะกับอะไร

กำหนดขอบเขตของเครื่องมือให้ชัดเจน: Apidog ไม่ใช่ agent framework, model host หรือ runtime สำหรับเอเจนต์ ไม่ได้สร้าง รัน หรือจัดการเอเจนต์ของคุณ และไม่ได้ประเมินคุณภาพ output ของโมเดล

สิ่งที่ Apidog ช่วยได้คือ API layer ที่เอเจนต์เรียกใช้ ซึ่งเป็นจุดที่ recovery สำเร็จหรือล้มเหลว

สำหรับ use case นี้ Apidog มีบทบาทหลัก 3 อย่าง:

Mock dependency

สร้าง stand-in ที่ควบคุมได้สำหรับ API ภายนอก
จำลอง failure response

กำหนด 429 พร้อม Retry-After, 500, timeout หรือ malformed body เพื่อทดสอบ recovery path
ตรวจสอบ request ที่ Mock ได้รับ

ตรวจว่า Idempotency-Key มีอยู่และคงที่, request shape ถูกต้อง และจำนวน request เป็นไปตามที่คาดไว้

กล่าวคือ Apidogช่วยจำลอง failure ที่เอเจนต์ต้องรับมือ และตรวจสอบสิ่งที่เอเจนต์ส่งกลับไป

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

Anthropic SDK ไม่จัดการ retry ให้แล้วหรือ?

สำหรับการเรียกผ่าน SDK เอง ใช่ Anthropic SDK จะ retry error บางประเภทด้วย Exponential Backoff และเคารพ Retry-After โดยกำหนดจำนวนครั้งสูงสุดผ่าน max_retries ได้

แต่ SDK ไม่ได้จัดการ API อื่นที่ tool ของเอเจนต์เรียกใช้ คุณต้องใช้ retry, timeout, circuit breaker และ idempotency pattern เดียวกันกับ dependency เหล่านั้นเอง

เมื่อไรที่ต้องใช้ Idempotency Key?

ใช้กับทุก operation ที่สร้างหรือเปลี่ยนแปลง state เช่น charge, order, message ที่ส่งออก หรือ record ใหม่

สำหรับ read-only call เช่น GET โดยทั่วไป retry ได้โดยไม่จำเป็นต้องมี key

สร้าง key หนึ่งครั้งต่อ logical action และใช้ key เดิมในทุก retry ของ action นั้น

ฝึกซ้อม Failure หนึ่งครั้งในสัปดาห์นี้

คุณไม่จำเป็นต้องสร้างทั้ง 4 รูปแบบพร้อมกัน เริ่มจาก failure ที่สร้างความเสียหายมากที่สุดในระบบของคุณ ซึ่งมักเป็น rate-limit loop หรือ mutating request ที่ไม่มี idempotency

ลองทำตามนี้:

สร้าง Mock endpoint
ตั้งค่าให้ตอบ 429 พร้อม Retry-After
จำลอง response timeout หลัง server ประมวลผล request
ตรวจดูว่าเอเจนต์ back off อย่างถูกต้องหรือไม่
ตรวจว่า retry ใช้ Idempotency Key เดิมหรือไม่
ยืนยันว่าไม่มี operation ซ้ำเกิดขึ้น

เมื่อคุณเห็น retry ที่เว้นจังหวะถูกต้อง และเห็น Idempotency Key เดิมตลอดการ retry คุณจะมีเหตุผลที่ดีกว่าเดโมที่ราบรื่นในการเชื่อมั่นว่าเอเจนต์พร้อมรับมือกับ production failure

ระบบป้องกันเอเจนต์ AI: ด่านอนุมัติและการจำกัดรัศมีผลกระทบ

Thanawat Wongchai — Tue, 21 Jul 2026 08:33:36 +0000

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

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

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

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

รายการที่อนุญาตให้ทำงานอัตโนมัติ (allowlist)
ด่านอนุมัติ (approval gate)
โหมดทดลองทำงาน (dry-run)
ข้อจำกัดขอบเขตความเสียหาย (blast-radius limits)

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

จัดเรียงการดำเนินการตามระดับความเสียหายที่อาจเกิดขึ้น

ไม่ใช่ทุกการดำเนินการต้องผ่านการอนุมัติ เอเจนต์ที่อ่านปฏิทิน ดึงข้อมูลพยากรณ์ หรือเรียกดูรายงานแบบ read-only ควรทำงานอัตโนมัติได้ การบังคับให้มนุษย์กด “อนุมัติ” ทุกครั้งจะทำให้คนเริ่มกดผ่านโดยไม่ตรวจสอบ และด่านอนุมัติจะไร้ค่าเมื่อเกิดกรณีสำคัญจริง

เริ่มจากแบ่งเครื่องมือหรือ endpoint ของเอเจนต์เป็น 2 กลุ่ม

กลุ่ม	ตัวอย่าง	พฤติกรรม
Allowlist	อ่านข้อมูล, ค้นหา, การดำเนินการแบบ idempotent, การแก้ไขที่ย้อนกลับได้	รันอัตโนมัติ
ต้องมี Guardrail	ส่งอีเมล, ลบข้อมูล, ชำระเงิน, เขียนข้อมูลลงระบบ, การกระทำที่ลูกค้าหรือทีมมองเห็น	ขออนุมัติหรือบล็อก

ใช้คำถามนี้ช่วยตัดสินใจ:

“ถ้าเอเจนต์ทำสิ่งนี้ผิดพลาด 100 ครั้ง ผลเสียจะร้ายแรงแค่ไหน?”

ถ้าคำตอบไม่ใช่ “ไม่เป็นไร” การดำเนินการนั้นไม่ควรอยู่ใน allowlist

อย่าจัดกลุ่มตาม HTTP verb เพียงอย่างเดียว ตัวอย่างเช่น POST สร้างอีเมลฉบับร่างอาจย้อนกลับได้ แต่ POST ที่สร้างและส่งอีเมลทันทีมีผลข้างเคียงที่ย้อนกลับยาก แม้โค้ดจะดูคล้ายกัน แต่ต้องจัดระดับความเสี่ยงจากผลลัพธ์จริง

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

type ToolRisk = "safe" | "approval_required";

const toolPolicy: Record<string, ToolRisk> = {
  "calendar.list": "safe",
  "weather.get": "safe",
  "tickets.search": "safe",
  "email.createDraft": "safe",

  "email.send": "approval_required",
  "customer.delete": "approval_required",
  "payment.create": "approval_required",
  "issue.close": "approval_required",
};

function requiresApproval(toolName: string) {
  return toolPolicy[toolName] !== "safe";
}

กำหนดค่าเริ่มต้นให้เป็น approval_required เสมอ หากมีเครื่องมือใหม่ที่ยังไม่ได้จัดประเภท อย่าปล่อยให้มันทำงานอัตโนมัติโดยบังเอิญ

ให้มนุษย์เข้ามาเกี่ยวข้องในการดำเนินการที่ก่อความเสียหาย

เมื่อรู้แล้วว่าการดำเนินการใดมีความเสี่ยง ให้เพิ่ม approval gate เอเจนต์ต้องหยุดก่อนเรียกใช้เครื่องมือ แสดงสิ่งที่จะทำ และรอการยืนยันจากมนุษย์

รูปแบบนี้คือ human-in-the-loop และมีคุณค่าสูง เพราะเปลี่ยนความผิดพลาดที่ย้อนกลับไม่ได้ให้เป็นคำขอที่ผู้ตรวจสอบสามารถปฏิเสธได้

ด่านอนุมัติที่ดีต้องแสดง payload จริง ไม่ใช่แค่ข้อความสรุปจากเอเจนต์

ข้อมูลที่ควรแสดงก่อนอนุมัติ

ชื่อเครื่องมือหรือ endpoint
HTTP method และ URL
ผู้รับหรือทรัพยากรที่ได้รับผลกระทบ
request body จริง
เหตุผลที่เอเจนต์เสนอการดำเนินการนี้
ผลกระทบที่คาดว่าจะเกิดขึ้น
ตัวเลือกอนุมัติและปฏิเสธที่ชัดเจน

ตัวอย่าง request ที่ควรส่งให้ผู้ตรวจสอบ:

{
  "tool": "email.send",
  "reason": "ตั๋วถูกจัดเป็นกรณีส่งเรื่องให้ผู้บริหาร",
  "request": {
    "method": "POST",
    "url": "/v1/emails/send",
    "body": {
      "to": ["manager@example.com"],
      "subject": "สรุปตั๋วสนับสนุนที่ต้องส่งเรื่อง",
      "text": "..."
    }
  }
}

อย่าให้ผู้ตรวจสอบต้องเชื่อคำสรุปว่า “เอเจนต์จะส่งอีเมล” เพราะสิ่งที่ต้องตรวจคือผู้รับ หัวข้อ และเนื้อหา

นอกจากนี้ การปฏิเสธต้องทำได้ง่าย หากปุ่มปฏิเสธไม่ชัดเจนหรือ workflow ช้า ผู้ตรวจสอบจะเริ่มอนุมัติทุกอย่างโดยอัตโนมัติ การพูดคุยเกี่ยวกับการ เพิ่มขั้นตอนการอนุมัติโดยมนุษย์ก่อนที่เอเจนต์จะดำเนินการ มักย้ำประเด็นเดียวกัน: ผู้ตรวจสอบต้องเห็น payload ที่เป็นรูปธรรมจึงจะตัดสินใจได้จริง

บันทึกผลทุกครั้งด้วย:

await auditLog.write({
  agentRunId,
  tool: "email.send",
  decision: "rejected",
  reviewerId: currentUser.id,
  payload,
  createdAt: new Date().toISOString(),
});

บันทึกการอนุมัติและปฏิเสธช่วยให้คุณตรวจสอบได้ว่า Guardrail ใดทำงานผิดพลาด หากมีการดำเนินการอันตรายหลุดออกไป

ให้เอเจนต์มีโหมดทดลองทำงาน (dry-run)

Approval gate ป้องกัน production ส่วน dry-run ป้องกันความมั่นใจก่อนนำระบบไปใช้งานจริง

ในโหมด dry-run เอเจนต์ยังคงทำงานตามปกติ:

เลือกเครื่องมือ
สร้าง request
เลือกอาร์กิวเมนต์
วางแผนลำดับการเรียก API

แต่จะไม่ส่งคำขอที่ก่อให้เกิดผลข้างเคียงจริง กลับรายงานสิ่งที่ “จะทำ” แทน

ตัวอย่าง implementation:

async function executeToolCall(
  toolName: string,
  payload: unknown,
  options: { dryRun: boolean }
) {
  if (options.dryRun) {
    return {
      status: "dry_run",
      toolName,
      payload,
      message: "ไม่มีการเรียก API จริง",
    };
  }

  return callRealTool(toolName, payload);
}

Dry-run มีประโยชน์ 2 ด้าน:

คุณเห็นพฤติกรรมเต็มรูปแบบของเอเจนต์กับข้อมูลจริงโดยไม่มีผลข้างเคียง
คุณได้ลำดับการเรียก API ที่เอเจนต์ตั้งใจทำ พร้อม argument ของแต่ละขั้นตอน

ตัวอย่างผลลัพธ์ dry-run ที่ควรเก็บ:

{
  "runId": "run_123",
  "dryRun": true,
  "plannedCalls": [
    {
      "step": 1,
      "tool": "tickets.get",
      "arguments": { "ticketId": "T-1024" }
    },
    {
      "step": 2,
      "tool": "email.send",
      "arguments": {
        "to": ["manager@example.com"],
        "subject": "Escalation summary"
      }
    }
  ]
}

เมื่อคุณเห็นว่าเอเจนต์พยายามเรียก endpoint ลบข้อมูลในขั้นตอนที่ 4 คุณสามารถแก้ prompt, tool definition หรือ policy ได้ก่อนที่ผลเสียจะเกิดขึ้นจริง การมีมุมมองจาก เครื่องมือดีบักเอเจนต์ AI โดยเฉพาะ ช่วยเปลี่ยนข้อความคลุมเครืออย่าง “เอเจนต์ทำอะไรแปลก ๆ” ให้เป็นข้อมูลที่แก้ปัญหาได้

อย่าสับสนระหว่าง dry-run กับ approval gate:

Dry-run: ใช้ใน development และ staging เพื่อดูแผนการทำงานโดยไม่เกิดผลจริง
Approval gate: ใช้ใน production เพื่อให้มนุษย์อนุมัติการกระทำจริง

คุณควรมีทั้งสองอย่าง

จำกัดขอบเขตความเสียหาย

Allowlist, approval gate และ dry-run ควบคุมว่าการดำเนินการหนึ่งครั้งควรเกิดขึ้นหรือไม่ แต่ blast-radius limits ควบคุมความเสียหายรวมที่เอเจนต์ทำได้จากหลายการดำเนินการ แม้บางรายการจะผ่านการอนุมัติแล้วก็ตาม

เริ่มจากข้อจำกัด 3 ประเภทนี้

1. Scopes

ให้ credential แก่เอเจนต์เท่าที่จำเป็น

เอเจนต์ที่ดูแล issue ของโปรเจกต์เดียวควรใช้ token ที่เข้าถึงได้เฉพาะโปรเจกต์นั้น ไม่ใช่ API key ระดับผู้ดูแลระบบทั้งองค์กร

agent_token:
  scopes:
    - projects:project-42:read
    - projects:project-42:write
  denied_scopes:
    - organization:admin
    - billing:write
    - users:delete

2. Quotas

จำกัดจำนวนครั้งที่เอเจนต์เรียกการดำเนินการในช่วงเวลาหนึ่ง เพื่อให้ loop ที่ผิดพลาดหยุดก่อนส่งอีเมลหลายพันฉบับ

const quota = {
  "email.send": { maxCalls: 10, windowMs: 60 * 60 * 1000 },
  "customer.delete": { maxCalls: 2, windowMs: 24 * 60 * 60 * 1000 },
};

3. Spend caps

กำหนดเพดานการใช้ token และค่าใช้จ่ายของเครื่องมือต่องานและต่อวัน

const limits = {
  maxTokensPerRun: 100_000,
  maxToolCostPerRunUsd: 10,
  maxDailyToolCostUsd: 100,
};

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

ติดตาม metric ของขีดจำกัดเหล่านี้เหมือนที่ติดตาม API observability:

จำนวนการเรียกต่อ agent run
จำนวนอีเมลหรือรายการที่สร้างต่อช่วงเวลา
การใช้ token ต่องาน
ค่าใช้จ่ายต่อวัน
อัตราข้อผิดพลาดเมื่อเข้าใกล้ quota
จำนวนครั้งที่การดำเนินการถูกบล็อกด้วย policy

OWASP ระบุความเสี่ยงเรื่อง “Excessive agency” ไว้ใน OWASP Top 10 สำหรับแอปพลิเคชัน LLM และข้อจำกัดเหล่านี้คือวิธีลดอำนาจของเอเจนต์ให้เหลือเท่าที่จำเป็น

วิธีทดสอบ Guardrail

Guardrail คือ branch ในโค้ดที่มักทำงานเฉพาะเมื่อกำลังจะเกิดเรื่องอันตราย ซึ่งทำให้เป็นเส้นทางที่ถูกใช้งานน้อยที่สุดและมีโอกาสเสียโดยไม่รู้ตัวมากที่สุด

Guardrail ที่ไม่ได้ทดสอบ คือ Guardrail ที่คุณยังไม่มี

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

ขั้นตอนการทดสอบ

Mock endpoint ที่มีผลข้างเคียง

สร้าง mock สำหรับ API ส่งอีเมล ลบข้อมูล หรือชำระเงิน โดยไม่เรียก API จริง
รันสถานการณ์อันตราย

ส่งตั๋วที่ต้องส่งเรื่องให้ผู้บริหาร คำขอลบข้อมูล หรือคำสั่งซื้อที่มีมูลค่าสูงให้เอเจนต์
ยืนยันเส้นทาง ไม่ใช่แค่ผลลัพธ์

ตรวจว่า endpoint จริงไม่ได้รับ request และมีการสร้างคำขออนุมัติแทน
ทดสอบเส้นทางปลอดภัยด้วย

ตรวจว่าการอ่านข้อมูลหรือการค้นหาผ่านได้โดยไม่ต้องรอ approval ที่ไม่จำเป็น

ตัวอย่างด้วย Jest:

it("ขออนุมัติก่อนส่งอีเมล และไม่เรียก endpoint จริง", async () => {
  const sendEmail = jest.fn();
  const createApprovalRequest = jest.fn();

  await runAgent({
    input: "สรุปตั๋วนี้แล้วส่งให้ผู้บริหาร",
    tools: {
      "email.send": sendEmail,
    },
    createApprovalRequest,
  });

  expect(sendEmail).not.toHaveBeenCalled();

  expect(createApprovalRequest).toHaveBeenCalledWith(
    expect.objectContaining({
      tool: "email.send",
      request: expect.objectContaining({
        method: "POST",
      }),
    })
  );
});

และทดสอบ allowlist เพื่อป้องกัน Guardrail ที่เข้มเกินไป:

it("อนุญาตให้ค้นหาตั๋วได้โดยไม่ขออนุมัติ", async () => {
  const searchTickets = jest.fn().mockResolvedValue([]);
  const createApprovalRequest = jest.fn();

  await runAgent({
    input: "ค้นหาตั๋วที่เปิดอยู่",
    tools: {
      "tickets.search": searchTickets,
    },
    createApprovalRequest,
  });

  expect(searchTickets).toHaveBeenCalled();
  expect(createApprovalRequest).not.toHaveBeenCalled();
});

เงื่อนไขที่ต้องผ่านไม่ใช่แค่ “เอเจนต์ตอบถูก” แต่คือ:

ผลข้างเคียงไม่เกิดขึ้น
มีคำขออนุมัติถูกสร้าง
payload ที่แสดงผู้ตรวจสอบตรงกับ request ที่เอเจนต์ตั้งใจส่ง
การดำเนินการปลอดภัยไม่ถูกบล็อกโดยไม่จำเป็น

ดูรายละเอียดเพิ่มเติมในคู่มือ วิธีทดสอบเอเจนต์ AI ที่เรียกใช้ API ของคุณ และ การทดสอบเอเจนต์ AI และ API

Apidog เหมาะสมกับตรงไหน (และไม่เหมาะสมกับตรงไหน)

กำหนดหน้าที่ของเครื่องมือให้ชัดเจน Apidog ไม่ใช่ agent framework, model host, Guardrail library หรือ evaluation platform มันไม่ได้สร้างหรือรันเอเจนต์ของคุณ และไม่ได้ตัดสินใจว่าการกระทำใดปลอดภัย

โค้ดและ orchestration layer ของคุณยังคงเป็นเจ้าของ:

allowlist
approval gate
dry-run switch
scopes
quotas
spend caps

Apidog อยู่ในชั้น API ที่ Guardrail เหล่านี้ต้องป้องกัน คุณสามารถจำลอง endpoint ที่มีผลข้างเคียง เช่น การส่ง การลบ หรือการเรียกเก็บเงิน เพื่อให้เอเจนต์ฝึกทำงานกับ API โดยไม่เกิดผลลัพธ์จริง

แนวทางใช้งานคือ:

สร้าง mock endpoint สำหรับ API ที่มีผลข้างเคียง
กำหนด response ให้ใกล้เคียงบริการจริง รวมถึงกรณี error
รันเอเจนต์ใน dry-run หรือ test environment
ตรวจสอบ request ที่เอเจนต์พยายามส่ง
ยืนยันว่าเส้นทางจริงไม่มี traffic และเส้นทางอนุมัติทำงานตามคาด

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

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

ความแตกต่างระหว่าง allowlist กับ approval gate คืออะไร?

Allowlist ระบุว่าการดำเนินการใดทำงานอัตโนมัติได้โดยไม่ต้องมีมนุษย์เข้ามาเกี่ยวข้อง ส่วน approval gate คือจุดหยุดสำหรับการดำเนินการที่ไม่ได้อยู่ใน allowlist เพื่อให้มนุษย์ตรวจสอบและยืนยันก่อนทำงานจริง

Allowlist ทำหน้าที่จัดประเภท ส่วน gate ทำหน้าที่หยุดและขออนุมัติ

Guardrail ทำให้เอเจนต์ช้าลงมากเกินไปหรือไม่?

จะช้าเกินไปก็ต่อเมื่อคุณวาง gate ผิดตำแหน่ง เก็บการอ่านข้อมูลและการดำเนินการที่ย้อนกลับได้ไว้ใน allowlist แล้วใช้ approval gate เฉพาะงานที่มีต้นทุนสูงหรือย้อนกลับยาก ขั้นตอนส่วนใหญ่จึงยังทำงานต่อได้โดยไม่ติดขัด

ฉันสามารถทดสอบ Guardrail โดยไม่เรียก API จริงได้หรือไม่?

ได้ และควรทำเช่นนั้นเสมอ จำลอง endpoint ที่มีผลข้างเคียง รันเอเจนต์ในสถานการณ์อันตราย แล้วตรวจว่า mock ของ endpoint จริงไม่ได้ถูกเรียก ขณะที่ workflow อนุมัติทำงานตามที่กำหนด

ฉันควรใส่อะไรไว้หลัง approval gate เป็นอันดับแรก?

เริ่มจากสิ่งที่แก้ไขยากที่สุด:

การชำระเงิน
การลบข้อมูล
การส่งอีเมลหรือข้อความถึงลูกค้า
การเปลี่ยนสถานะที่ทีมอื่นมองเห็น
การแก้ไขข้อมูลถาวร

หากการทำผิดเพียงครั้งเดียวสร้างความเสียหายร้ายแรง การดำเนินการนั้นควรอยู่หลัง gate ไม่ใช่อยู่ใน allowlist

เริ่มจากการดำเนินการที่สร้างความเสียหายมากที่สุด

คุณไม่จำเป็นต้องสร้าง Guardrail ทั้ง 4 ประเภทในวันแรก

ให้เลือกการดำเนินการเดียวที่คุณไม่อยากอธิบายในการตรวจสอบเหตุการณ์ เช่น “เอเจนต์ส่งอีเมลถึงลูกค้าเอง” หรือ “เอเจนต์ลบข้อมูล production เอง” แล้วทำ 3 อย่างภายในสัปดาห์นี้:

เพิ่ม approval gate ให้การดำเนินการนั้น
สร้าง mock endpoint สำหรับผลข้างเคียง
เขียน test ที่ยืนยันว่าเอเจนต์ขออนุมัติก่อนดำเนินการ

เมื่อคุณเห็น test ล้มเหลวทันทีที่ปิดหรือทำ Guardrail เสีย คุณจะเชื่อมั่นในด่านป้องกันด้วยเหตุผลที่ถูกต้อง: มันผ่านการพิสูจน์แล้ว

ดาวน์โหลด Apidog เพื่อจำลอง endpoint ที่ก่อให้เกิดความเสียหาย กำหนด response และตรวจสอบว่าเอเจนต์ใช้เส้นทางอนุมัติแทนการเรียก API จริง

DEV Community: Thanawat Wongchai

Gemini 3.5 Flash-Lite เทียบกับ 3.6 Flash ควรเลือกรุ่นไหนดี?

คำตอบสั้นๆ

ราคาและความเร็วแบบเปรียบเทียบ

คุณภาพและเกณฑ์มาตรฐาน

เลือกโมเดลตามประเภทงาน

คำนวณต้นทุนจากปริมาณงานจริง

วิธีทำ A/B Test ทั้งคู่ใน Apidog

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

Flash-Lite เป็นแค่ 3.6 Flash เวอร์ชันที่แย่กว่าหรือไม่?

ทำไมรุ่นหนึ่งเป็น 3.5 แต่อีกรุ่นเป็น 3.6?

ทั้งสองใช้ Context Window เท่ากันหรือไม่?

ใช้ทั้งสองโมเดลในแอปเดียวกันได้หรือไม่?

ทั้งสองมีรุ่นทดลองใช้ฟรีหรือไม่?

สรุป

เปรียบเทียบ Gemini 3.6 Flash กับ 3.5 Flash: ต่างกันอย่างไร และควรอัปเกรดไหม

คำตอบสั้นๆ

Gemini 3.6 Flash เทียบกับ 3.5 Flash

สิ่งที่ปรับปรุงจริง

1. ใช้โทเค็นเอาต์พุตน้อยลง

2. ราคาเอาต์พุตลดลง

3. การใช้งานคอมพิวเตอร์ดีขึ้น

4. ใช้ reasoning step และ tool call น้อยลง

คำนวณผลกระทบด้านค่าใช้จ่าย

มีเหตุผลใดที่จะยังใช้ 3.5 Flash หรือไม่?

วิธีการย้าย

ทดสอบ regression ใน Apidog

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

Gemini 3.6 Flash ใช้แทน 3.5 Flash ได้ทันทีหรือไม่?

ราคาอินพุตเปลี่ยนหรือไม่?

ทำไม Flash เป็น 3.6 แต่ Lite และ Cyber เป็น 3.5?

ค่าใช้จ่ายจะลดลง 31% เสมอหรือไม่?

Gemini 3.5 Flash ยังใช้งานได้หรือไม่?

Gemini 3.5 Flash-Lite คืออะไร

Gemini 3.5 Flash-Lite คืออะไร?

เดี๋ยวก่อน ทำไมถึงเป็น 3.5 ไม่ใช่ 3.6?

ข้อมูลจำเพาะและราคา

ใช้ Context Caching เมื่อมี prompt ซ้ำ

ประสิทธิภาพเป็นอย่างไร?

Google ใช้ Flash-Lite ที่ไหนบ้าง

Flash-Lite vs Gemini 3.6 Flash: คุณควรเลือกโมเดลไหนดี?

วิธีเข้าถึงและทดสอบ

สร้าง regression test สำหรับ endpoint

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

Gemini 3.6 Flash ราคาปี 2026: ค่าใช้จ่ายจริงเท่าไร

ราคา Gemini 3.6 Flash โดยสรุป

เปรียบเทียบกับ Gemini 3.5 Flash

แพ็กเกจฟรีให้อะไรบ้าง

คำนวณค่าใช้จ่ายจริง

ผลประหยัดเมื่อเทียบกับ Gemini 3.5 Flash

Flash-Lite ถูกกว่าอีกสำหรับงานง่าย

วิธีควบคุมและวัดค่าใช้จ่าย

1. แคช context ที่ใช้ซ้ำ

2. ตัด prompt และจำกัดเอาต์พุต

3. Route งานตามความซับซ้อน

4. เก็บค่า usageMetadata จากทุกคำขอ

ทดสอบงบประมาณ API ก่อนขึ้น production

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

Gemini 3.6 Flash มีค่าใช้จ่ายเท่าไรต่อ 1 ล้านโทเค็น?

ราคาเอาต์พุตรวม thinking tokens หรือไม่?

มีแพ็กเกจฟรีหรือไม่?

Gemini 3.6 Flash ถูกกว่า 3.5 Flash หรือไม่?

ควรใช้ Flash-Lite เมื่อใด?

สรุป

วิธีใช้ Gemini 3.6 Flash ฟรี

คุณสามารถใช้ Gemini 3.6 Flash ได้ฟรีหรือไม่?

ใช้ Gemini 3.6 Flash ฟรีผ่านแอป Gemini

ใช้ Gemini API ฟรีใน Google AI Studio

ข้อจำกัดที่ต้องรู้ก่อนใช้บริการฟรี

1. ขีดจำกัดอัตราและโควต้า

2. การใช้ข้อมูล

เมื่อใดควรย้ายไปใช้บริการแบบชำระเงิน

ทางเลือกที่ประหยัดกว่า: Gemini 3.5 Flash-Lite

ทดสอบ Gemini API ฟรีด้วย Apidog

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

Gemini 3.6 Flash ฟรีแบบไม่จำกัดหรือไม่?

ข้อมูลในบริการฟรีเป็นส่วนตัวหรือไม่?

ต้องใส่บัตรเครดิตเพื่อใช้ API ฟรีหรือไม่?

แอป Gemini เหมือนกับ Gemini API ฟรีหรือไม่?

ควรเริ่มด้วย Flash หรือ Flash-Lite?

4. เก็บค่า `usageMetadata` จากทุกคำขอ