Google ดัน Interactions API ขึ้น GA — อินเทอร์เฟซใหม่ของ Gemini ที่มาแทน generateContent มี state ฝั่งเซิร์ฟเวอร์ รัน background ได้ และเห็นทุกขั้นตอนของ agent

นักพัฒนาที่ต่อ Gemini API กันมาตั้งแต่ยุคแรกคุ้นกับ generateContent ดี — endpoint แบบ request/response ก้อนเดียว ส่ง prompt เข้า รับคำตอบออก จบ Google เพิ่งประกาศว่าอินเทอร์เฟซรุ่นถัดไปที่ชื่อ Interactions API ขึ้นสถานะ GA (พร้อมใช้งานจริงระดับ production) แล้ว และมันคือ “ทางหลัก” ที่ Google แนะนำให้เริ่มทุกโปรเจกต์ใหม่นับจากนี้ — โดย generateContent ยังใช้ได้ต่อในสถานะ legacy แต่ความสามารถใหม่ ๆ ของ agent จะลงเฉพาะที่ Interactions API เท่านั้น

ความต่างไม่ใช่แค่เปลี่ยนชื่อ endpoint แต่เป็นการ ออกแบบอินเทอร์เฟซใหม่ให้ “โลกที่เป็น agent” แทนโลกที่เป็นแค่ chat — รองรับทั้งการเรียกโมเดลธรรมดาและการสั่ง agent ที่ทำงานยาว ๆ หลายขั้นตอนผ่าน resource เดียวกัน

สามอย่างที่เปลี่ยนวิธีเขียนโค้ดจริง ๆ

1. State อยู่ฝั่งเซิร์ฟเวอร์ได้แล้ว — เดิมทุกครั้งที่คุยกับโมเดลคุณต้องแนบประวัติสนทนาทั้งก้อนกลับไปเองทุก request ตอนนี้แค่ส่ง previous_interaction_id ของ interaction ก่อนหน้า เซิร์ฟเวอร์จะต่อบริบทให้เอง ลดทั้งโค้ดฝั่ง client และ payload ที่ต้องส่งซ้ำ (ข้อควรระวัง: tools, system_instruction, generation_config ยังเป็น interaction-scoped ต้องระบุใหม่ทุกครั้ง — ส่วน data retention อยู่ที่ 55 วันบน paid tier, 1 วันบน free, ปิดได้ด้วย store=false)

2. รัน background ได้ — สั่ง background=true แล้วงานยาว ๆ (เช่น Deep Research, agent ที่รันหลายนาที) จะประมวลผลแบบ async ฝั่งเซิร์ฟเวอร์ ไม่ต้องถือ connection ค้างไว้ — เหมาะกับ agent ที่ทำงานเป็นนาทีหรือเป็นหลายขั้น

3. เห็นทุกขั้นตอน (observable steps) — แทนที่จะได้แค่ข้อความตอบกลับก้อนเดียว Interaction เก็บลำดับ execution step แบบมี type ชัดเจน: user_input, thought (ความคิดของโมเดล), function_call / function_result (การเรียก tool และผลลัพธ์), จนถึง model_output — ทำให้ debug, log และ render UI ที่โชว์ว่า agent “กำลังคิด/กำลังเรียกเครื่องมืออะไรอยู่” ได้ตรงไปตรงมา ไม่ต้องเดา

มาพร้อม managed agent, tool chaining และ flex/priority tier

นอกจากแกนหลักสามข้อ Interactions API ยังเปิดประตูฟีเจอร์ฝั่ง agent เต็มตัว: managed agent ที่ provision sandbox Linux ระยะไกลให้ (มี Antigravity เป็น agent ดีฟอลต์), tool chaining ที่ผสม built-in tool อย่าง Google Search / Maps กับฟังก์ชันของคุณเองในงานเดียว (และผล tool ส่งกลับเป็นภาพพร้อมข้อความได้), งาน media generation (Nano Banana 2, Lyria 3) รวมถึง Flex และ Priority tier ที่อ้างว่าลดต้นทุนได้สูงสุดราว 50%

ฝั่งเครื่องมือ: รองรับใน SDK google-genai (Python) และ @google/genai (JS) ตั้งแต่เวอร์ชัน 2.3.0 ขึ้นไป และ Google มี migration guide ที่แมปทุก field จาก generateContent ไปสคีมาใหม่ ให้แล้ว — เอกสารทางการตอนนี้ดีฟอลต์เป็น Interactions API พร้อมปุ่ม toggle กลับไปดูแบบ legacy ได้

มุมมอง AI Curator

นี่คือสัญญาณที่ชัดว่า ผู้ให้บริการโมเดลกำลังย้ายเส้นแบ่ง “แพลตฟอร์ม” จากระดับ chat completion ขึ้นไปที่ระดับ agent runtime — สิ่งที่เคยเป็นงานของเฟรมเวิร์กฝั่งคุณ (จัดการ state สนทนา, จัด orchestration, รันงาน async, เก็บ trace ทีละขั้น) ตอนนี้ถูกดูดเข้าไปเป็นฟีเจอร์ของ API เอง เทียบกับฝั่ง OpenAI ที่เดินทาง Responses API มาก่อนหน้านี้ เกมเดียวกันคือ ใครเป็นเจ้าของ “interaction loop” คนนั้นเป็นเจ้าของนักพัฒนา

ข้อดีจับต้องได้สำหรับทีมเล็ก/นักพัฒนาไทยคือ เขียน agent ที่ดูโปรได้ด้วยโค้ดน้อยลงมาก — state ฝั่งเซิร์ฟเวอร์และ observable step ช่วยให้สร้าง UI แบบ “เห็น agent คิดทีละสเต็ป” ได้โดยไม่ต้องประกอบ trace เอง และ background execution ทำให้งานยาว ๆ ไม่ต้องไปตั้ง queue/worker เองตั้งแต่วันแรก ลดเวลา prototype ลงเยอะ

แต่อีกด้านคือ lock-in ที่ลึกขึ้น — ยิ่งพึ่ง state ฝั่งเซิร์ฟเวอร์, managed agent และ tier เฉพาะของ Google มากเท่าไร การย้ายไปโมเดลอื่นก็ยากขึ้นเท่านั้น คำแนะนำเชิงปฏิบัติคือ ถ้าระบบของคุณต้องรองรับหลายผู้ให้บริการ ให้กันชั้น abstraction บาง ๆ คั่นไว้ (เช่นใช้ผ่าน adapter หรือมาตรฐานกลางอย่าง ACP/MCP) อย่าผูกตรงกับฟีเจอร์เฉพาะเจ้าจนถอนไม่ขึ้น — ใช้ความสะดวกของ Interactions API ได้ แต่อย่าให้สถาปัตยกรรมทั้งระบบยืนบนมันขาเดียว

แหล่งข่าว

• Google AI Studio’s Interactions API for Gemini models and agents — blog.google
• Interactions API overview — Gemini API docs
• Migrating to the Interactions API — Gemini API docs