Skip to main content
Back to articles

Google ADK รองรับ 5 ภาษา ให้สร้าง Agent โดยไม่ต้องย้ายทุกอย่างไป Python

Google ADK รองรับ Python, Go, TypeScript, Java และ Kotlin พร้อม MCP และ A2A ทีมพัฒนาควรเทียบ SDK การทดสอบและการ deploy ในภาษาเดิมของระบบ

Google ADK รองรับ 5 ภาษา ให้สร้าง Agent โดยไม่ต้องย้ายทุกอย่างไป Python

Google Cloud เผยแพร่บทความวันที่ 13 ตุลาคม 2026 ว่า Agent Development Kit หรือ ADK รองรับการพัฒนาในห้าภาษา ได้แก่ Python, Go, TypeScript, Java และ Kotlin โดยแต่ละชุดสร้างให้เข้ากับ runtime และระบบชนิดข้อมูลของภาษานั้น แต่ใช้แนวคิดสถาปัตยกรรมร่วมกัน ข่าวนี้มีผลต่อทีมที่อยากสร้าง AI agent โดยไม่ต้องย้ายงานทั้งหมดไป Python เพื่อใช้ framework เดียว

ปัญหาที่ Google พยายามแก้

agent ในระบบจริงอาจอยู่ใน Go service ที่รับคำขอพร้อมกันมาก หรือเป็น TypeScript ในระบบเว็บ ขณะที่ทีมข้อมูลมี Python และแอปองค์กรใช้ Java หรือ Kotlin หาก framework บังคับภาษาเดียว ทีมต้องเพิ่มบริการใหม่เพื่อคั่นกลาง หรือต้องเขียนระบบ orchestration ซ้ำในภาษาที่ใช้อยู่ Google เสนอ ADK หลายภาษาเพื่อให้เลือกภาษาให้เหมาะกับสภาพแวดล้อมเดิม โดยยังรักษาวิธีเชื่อมเครื่องมือและ agent ข้ามระบบ

ตามประกาศ ทั้งห้าเวอร์ชันมี MCP client เพื่อเรียกเครื่องมือที่เปิดผ่าน Model Context Protocol และรองรับ A2A สำหรับให้ agent ติดต่อ agent ระยะไกลผ่าน HTTP ประเด็นนี้สำคัญกว่าการมีแพ็กเกจครบห้าภาษา เพราะเปิดทางให้ทีมหนึ่งทำ agent ด้วย Go แต่อีกทีมใช้ Python แล้วคุยกันตาม protocol โดยไม่ต้องแชร์ runtime เดียวกัน อย่างไรก็ดี ความเข้ากันได้ของ protocol ไม่ได้แปลว่า state, authentication และการจัดการข้อผิดพลาดจะเหมือนกันทุกภาษา ต้องทดสอบการทำงานข้ามระบบจริง

เลือกภาษาอย่างไร

Google ยกตัวอย่าง Python ว่าเหมาะกับการทดลองเร็วและมีระบบเชื่อมต่อกับบริการข้อมูลหลายตัว ฟังก์ชันธรรมดาสามารถถูกนำไปประกาศเป็น tool โดยอาศัย type hints และ docstring เพื่อสร้าง schema ส่วน Go ใช้ชนิดข้อมูลและ generics ช่วยกำหนดขอบเขต input/output ให้ชัดใน backend ที่เน้นการทำงานจริง สำหรับ TypeScript, Java และ Kotlin ควรดูรูปแบบ SDK และ dependency ของแต่ละโครงการก่อนเริ่ม เพราะคำว่า “สถาปัตยกรรมร่วม” ไม่ควรถูกตีความว่า API ของทุกภาษามีรายละเอียดตรงกันทุกจุด

ถ้าทีมมีระบบงานอยู่แล้ว ให้เริ่มจากภาษาของบริการหลักก่อน วิธีนี้ลดต้นทุนการ deploy และการดูแลหลาย runtime หากโครงการยังอยู่ช่วงค้นหาแนวทางและต้องใช้เครื่องมือประเมิน agent บ่อย Python อาจมีข้อได้เปรียบ เพราะประกาศระบุว่ามีเครื่องมือ eval และ integrations กว้างที่สุด แต่ควรทดสอบการย้ายแนวคิดไปภาษา production ตั้งแต่เนิ่น ๆ เพื่อไม่ให้ prototype กลายเป็นข้อผูกมัดที่แก้ยาก

การเริ่มต้นตามประกาศ

บล็อกแนะนำคำสั่ง uvx google-agents-cli setup สำหรับตรวจการยืนยันตัวตน Google Cloud ติดตั้ง CLI และเตรียม skill ของ ADK จากนั้นใช้ scaffold สร้างโครงการพร้อม A2A endpoint และค่าการ deploy ไป Cloud Run, Gemini Enterprise Agent Runtime หรือ GKE ตัวอย่างในประกาศสร้าง Go agent ด้วย --agent adk_go และเลือก --deployment-target cloud_run ทีมที่ทดลองควรทำใน project แยกก่อน ตรวจสิทธิ์ของ service account และตรวจค่าใช้จ่ายของทรัพยากรปลายทางก่อน deploy

การ scaffold เป็นเพียงจุดเริ่ม โค้ดที่สร้างได้ยังต้องมีการตรวจคุณภาพของ tool, การจัดการ secret, timeout, retry และการบันทึกการตัดสินใจของ agent หากเปิด A2A endpoint ให้ agent อื่นเรียก ต้องกำหนดว่าใครยืนยันตัวตนอย่างไร คำขอใดทำได้ และจะป้องกันการเรียกซ้ำหรือคำสั่งที่มีผลข้างเคียงอย่างไร ส่วน MCP server ที่เชื่อมเข้ามาควรได้รับสิทธิ์เท่าที่จำเป็น ไม่ควรให้ agent เขียนไฟล์หรือแตะข้อมูล production เพียงเพราะเชื่อม protocol ได้

จุดตรวจสำหรับโครงการหลายภาษา

ทีมที่กำลังประเมิน ADK อาจสร้างตัวอย่างเดียวกันในสองภาษาที่สนใจ เช่น agent อ่าน ticket และเสนอการจัดหมวด แล้วทดสอบผลลัพธ์จากชุดข้อมูลเดียวกัน วัดเวลา build ขนาด artifact ความง่ายในการเขียน test และความชัดของ error message มากกว่าวัดเพียงความเร็วตอบของโมเดล ซึ่งมักถูกครอบโดยเวลาเรียก API ภายนอก หากจะให้ agent ต่างภาษาสื่อสารกัน ให้ทดสอบ schema evolution เช่น เพิ่มฟิลด์ใหม่โดยไม่ทำให้ไคลเอนต์เก่าพัง และลองกรณี agent ปลายทางล่มกลางงาน

สำหรับองค์กรที่มีหลายทีม การมีเครื่องมือห้าภาษาอาจลดแรงเสียดทานในการเริ่มต้น แต่จะเกิดประโยชน์จริงเมื่อทุกทีมตกลงเรื่อง contract และการสังเกตการณ์ร่วมกัน ควรกำหนดชื่อเหตุการณ์ trace ID และรูปแบบการรายงานความผิดพลาด เพื่อให้ตามงานข้ามภาษาได้ ไม่เช่นนั้น protocol มาตรฐานช่วยให้เรียกกันได้ แต่ไม่ได้ช่วยให้แก้ incident ง่ายขึ้น

สรุป

ประกาศของ Google เมื่อ 13 ตุลาคม 2026 เพิ่มทางเลือกให้สร้าง agent ในภาษาที่เหมาะกับระบบเดิม โดยใช้ MCP และ A2A เป็นสะพานเชื่อม จุดที่ควรทดลองก่อนตัดสินใจคือความครบของ SDK ในภาษาที่ทีมใช้ การทำงานข้าม agent และความสะดวกในการทดสอบกับ deploy มากกว่าการดูรายชื่อภาษาที่รองรับอย่างเดียว

แหล่งข่าวและวันที่ประกาศ: Google Cloud Blog, 13 ตุลาคม 2026