Google Data Agent Kit เปิดใช้จริง แต่คำสั่งเดียวแตะข้อมูลสดได้

|ผู้เขียน: กองบรรณาธิการ QUASA|2 นาทีในการอ่าน| 1
Google Data Agent Kit เปิดใช้จริง แต่คำสั่งเดียวแตะข้อมูลสดได้

Google Cloud ประกาศให้ Data Agent Kit พร้อมใช้งานทั่วไปเมื่อ 30 กันยายน 2026 ชุดเครื่องมือนี้รวมการเชื่อมต่อผ่าน Model Context Protocol หรือ MCP กับ skills สำหรับ coding agent และเข้าถึงบริการ Google Data Cloud มากกว่า 15 บริการได้ตามสิทธิ์ที่กำหนด ชุดเครื่องมือไม่มีค่าใช้จ่ายเพิ่มเติม แต่บริการปลายทางที่เอเจนต์เรียกใช้ยังคิดค่าบริการตามปกติ

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

ความสามารถที่เพิ่มขึ้นเมื่อ Data Agent Kit เปิดใช้ทั่วไป

Data Agent Kit ทำหน้าที่เชื่อมสภาพแวดล้อมเขียนโค้ดกับบริการข้อมูลที่องค์กรใช้อยู่ เครื่องมือ MCP เปิดทางให้เอเจนต์ตรวจสคีมา เรียกคำสั่งสืบค้น อ่านบันทึกงาน และจัดการทรัพยากร ส่วน skills เป็นคำแนะนำขั้นตอนสำหรับงานเฉพาะ เช่น ปรับ SQL ของ BigQuery ออกแบบ row key ของ Bigtable หรือสร้าง pipeline ด้วย dbt ส่วนที่ลงมือกับข้อมูลจริงคือคำสั่งที่ส่งผ่านเครื่องมือ MCP ภายใต้สิทธิ์ของตัวตนที่ตั้งค่าไว้

การเปิดใช้ทั่วไปเพิ่ม BigQuery Graph, Bigtable และการเข้าถึงตารางใน lakehouse ผ่าน Managed Service for Apache Spark สำหรับ BigQuery Graph เอเจนต์สามารถช่วยจับคู่ตารางเป็นโหนดและความสัมพันธ์ เสนอแผนให้อนุมัติก่อนสร้างกราฟ แล้วเขียนคำสั่ง GQL เพื่อสืบค้นความสัมพันธ์นั้น Bigtable เพิ่มงานออกแบบสคีมา การดูอินสแตนซ์และตาราง ตลอดจนการสืบค้นด้วย GoogleSQL ความต่างจากการให้เอเจนต์เขียนตัวอย่างโค้ดคือขั้นตอนเหล่านี้อาจใช้โครงสร้างและข้อมูลที่มีอยู่จริงในโปรเจกต์

ขอบเขตยังครอบคลุมฐานข้อมูลอย่าง Spanner, AlloyDB และ Cloud SQL รวมถึงงาน pipeline และ orchestration ที่ใช้ Dataform หรือ Managed Service for Apache Airflow ฝั่ง Spark สามารถทำงานกับตาราง Apache Iceberg ผ่านบริการประมวลผลแบบไม่ต้องดูแลคลัสเตอร์เอง ความสามารถแต่ละอย่างใช้บริการและสิทธิ์ปลายทางต่างกัน ทีมที่ต้องการเพียงตรวจตารางใน BigQuery จึงไม่จำเป็นต้องเปิดเครื่องมือสำหรับสร้างฐานข้อมูลหรือกำหนดงานประมวลผลตามเวลาไปพร้อมกัน

จาก IDE ถึงข้อมูลจริง คำสั่งเดินทางผ่านอะไรบ้าง

ผู้ใช้ VS Code, Cursor และเครื่องมือที่เข้ากันได้กับ VS Code ติดตั้ง Data Agent Kit เป็นส่วนขยายได้ ส่วน Claude Code, Codex CLI และ Antigravity CLI ใช้เส้นทางปลั๊กอินตามเครื่องมือ Cloud Shell กับ Cloud Workstations มีชุดเครื่องมือติดตั้งไว้แล้ว เมื่อใช้ส่วนขยายใน IDE ผู้ใช้เลือกบริการที่ต้องการเชื่อมใน Service integrations; การเลือกบริการช่วยตั้งค่า API, skills และเซิร์ฟเวอร์ MCP ที่เกี่ยวข้อง แต่ยังต้องลงชื่อเข้าใช้และมีสิทธิ์สำหรับงานที่จะทำ

เส้นทางหนึ่งของงานอ่านข้อมูลคือ ผู้ใช้ส่งคำขอใน IDE หรือ CLI → coding agent เลือก skill และเครื่องมือ MCP → เซิร์ฟเวอร์ MCP รับคำขอภายใต้ตัวตนที่ตั้งค่า → BigQuery หรือฐานข้อมูลปลายทางตรวจสิทธิ์และประมวลผล → ผลลัพธ์กลับไปยังเอเจนต์ ลำดับนี้อธิบายได้ว่าทำไมคำตอบที่ดูเหมือนข้อความสนทนาธรรมดาอาจมีงานสืบค้นเกิดขึ้นระหว่างทาง หากเอเจนต์เลือกเครื่องมือที่สร้างตาราง เปลี่ยนสคีมา หรือกำหนด pipeline ผลของคำสั่งก็อยู่ในทรัพยากรจริง ไม่ได้หยุดอยู่ในหน้าต่างสนทนา

การตั้งค่าโปรเจกต์และภูมิภาคจึงเป็นส่วนของขอบเขตงาน ไม่ใช่เพียงค่าที่ทำให้ส่วนขยายเริ่มทำงาน ใน IDE ควรตรวจว่าบัญชี โปรเจกต์ ภูมิภาค และบัญชีเรียกเก็บเงินที่ Data Agent Kit ใช้ตรงกับค่าของ Google Cloud CLI หากใช้ CLI plugin ต้องตั้งค่าข้อมูลรับรองของ gcloud และ application default credentials ด้วย การเลือกโปรเจกต์ผิดอาจทำให้เอเจนต์เห็นชุดข้อมูลคนละแห่งกับที่ผู้ใช้ตั้งใจ แม้ข้อความคำสั่งจะเหมือนเดิมทุกคำ

สิทธิ์เรียก MCP กับสิทธิ์ในฐานข้อมูลเป็นคนละด่าน

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

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

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

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

Dry run บอกอะไรเกี่ยวกับต้นทุน BigQuery

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

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

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

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

จุดอนุมัติควรอยู่ตรงไหนก่อนเอเจนต์ลงมือ

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

  • สำหรับ BigQuery ให้ดูตารางและคอลัมน์ที่คำสั่งจะอ่าน ผล dry run เงื่อนไขกรองพาร์ทิชัน และเพดานปริมาณข้อมูลที่เรียกเก็บหากใช้การคิดราคาตามปริมาณข้อมูล
  • สำหรับ Bigtable, Spanner, AlloyDB และ Cloud SQL ให้แยกสิทธิ์สืบค้นออกจากสิทธิ์เขียนข้อมูล สร้างตาราง หรือเปลี่ยนโครงสร้าง แล้วกำหนดผู้อนุมัติสำหรับการกระทำที่เปลี่ยนแปลงระบบ
  • สำหรับ Spark และ pipeline ให้ดูบริการประมวลผล ทรัพยากรที่จะสร้าง การตั้งเวลารันซ้ำ และบัญชีบริการที่จะใช้หลังงานออกจาก IDE

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

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

แชร์:

สมัครรับจดหมายข่าวของเรา

รับข่าวสารล่าสุดเกี่ยวกับ Web3, AI และคริปโตส่งตรงถึงกล่องจดหมายของคุณ

0