Gemini agent รับ “เป้าหมาย” แทนคำสั่ง—เริ่มจากลูกค้าองค์กรก่อน

Google Cloud ประกาศเปิดตัว Gemini agent ในงาน Gemini at Work 2026 วันที่ 8 ตุลาคม 2026 โดย Thomas Kurian ซีอีโอของ Google Cloud อธิบายหลักการมอบหมายงานว่า “You give it objectives, not instructions.” ระบบที่นำเสนอรับเป้าหมายและบริบทของธุรกิจ วางแผน เลือกทักษะกับเครื่องมือ แล้วส่งชิ้นงานกลับไปยังเอกสาร กล่องจดหมาย หรือสภาพแวดล้อมพัฒนาที่พนักงานใช้อยู่

การเปิดตัวเริ่มกับธุรกิจก่อน โดย Sundar Pichai ให้เหตุผลเรื่องความปลอดภัย ขนาดระบบ และประสิทธิภาพตามรายงานของ TechCrunch สำหรับลูกค้าที่จะใช้งานทันที ขอบเขตยังแคบกว่าคำว่าเปิดตัว: โฆษก Google Cloud ยืนยันกับVentureBeat ว่าเริ่มให้ลูกค้าที่ได้รับเลือกทดลองแบบส่วนตัว และยังไม่กำหนดวันเปิดใช้งานวงกว้าง

จากเป้าหมายที่มอบหมายถึงชิ้นงานที่ส่งกลับ

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

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

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

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

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

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

ทักษะ เครื่องมือ และโมเดลทำหน้าที่ต่างกัน

Gemini agent เป็นตัวประสานงาน ส่วนโมเดลเป็นส่วนที่ใช้ประมวลผลในแต่ละขั้น ระบบอาจเลือกโมเดลให้เหมาะกับลักษณะงาน หรือผู้ดูแลอาจจำกัดชุดโมเดลที่อนุญาตให้ใช้ได้ แนวทางที่ประกาศครอบคลุมโมเดลตระกูล Gemini และ Claude ของ Anthropic ขณะที่การรองรับโมเดลอื่นเป็นแผนในอนาคต การเปลี่ยนโมเดลจึงไม่จำเป็นต้องเปลี่ยนบริบท เครื่องมือ และวิธีมอบหมายงานทั้งหมดพร้อมกัน

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

เครื่องมือทำอีกหน้าที่หนึ่ง คือเชื่อมเอเจนต์กับระบบที่ใช้เก็บข้อมูลหรือรับผลลัพธ์ รายชื่อระบบที่ประกาศรองรับมีทั้ง Google Workspace, Microsoft 365, Slack, Jira, Salesforce, BigQuery และ Snowflake รวมถึงเซิร์ฟเวอร์ที่ใช้ Model Context Protocol หรือ MCP ตัวเชื่อมเหล่านี้เปิดทางให้ภารกิจข้ามแอป แต่ข้อมูลที่มองเห็นจริงยังขึ้นกับระบบซึ่งองค์กรเชื่อมและสิทธิ์ที่ตั้งไว้ การมีชื่อแอปอยู่ในรายการจึงไม่ได้ทำให้เอเจนต์อ่านทุกพื้นที่ของแอปนั้นได้

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

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

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

เอเจนต์ที่ลงมือทำต้องมีตัวตนและขอบเขตสิทธิ์

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

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

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

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

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

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

ใครได้ใช้ก่อน และค่าใช้จ่ายอยู่ตรงไหน

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

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

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

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

อ่านเพิ่มเติม:

• Gemini 4 Argon เปิดตัวแล้ว แต่คนทั่วไปยังใช้ไม่ได้
• Gemini 3.8 Live สร้างอวตารสดได้ 97 ภาษา แต่ API ยังมีเงื่อนไข
• Claude Code หรือ Gemini CLI: ตัวเก่งเปลี่ยนตามโมเดลและชุดทดสอบ