Google Cloud กำลังทำ Agent Ladder: จาก Prototype ไป Production Agent

Google Cloud เผยข่าวสำหรับ agent developers ในงาน I/O 26 วันที่ 20 พฤษภาคม 2026

ชื่อ product ที่ออกมารอบนี้เยอะมากครับ

Antigravity 2.0, Antigravity CLI, Managed Agents API, ADK 2.0, Agents CLI, A2A protocol, Skill Registry, Agent Gateway, Agent Identity, evaluation suite และ sandbox execution

ถ้าอ่านแบบข่าว launch ทั่วไป เราอาจสรุปง่าย ๆ ว่า Google Cloud เพิ่มเครื่องมือสร้าง AI Agent อีกหลายตัว

แต่ผมว่าอ่านแบบนั้นจะพลาดประเด็นสำคัญ

ประเด็นจริงคือ Google Cloud กำลังวาง “บันได” ให้ agent เดินจาก prototype ไป production

ไม่ใช่ทุก workflow ควรเริ่มจาก code-first framework ไม่ใช่ทุก workflow ควรจบที่ low-code ไม่ใช่ทุกทีมควรเอา agent ไปแตะ production ตั้งแต่วันแรก

คำถามที่ควรถามก่อนคือ:

workflow นี้ต้องการ control แค่ไหน

1) ข่าวนี้มีอะไรเกิดขึ้น

Google Cloud วาง agent development เป็น 4 rungs หรือ 4 ขั้นของบันได

ขั้นที่ 1 คือ Agent Studio

นี่คือ low-code visual workspace ใน Gemini Enterprise Agent Platform สำหรับทีมที่อยากเริ่มเร็ว ทดลอง prompt, model, tool และ agent โดยไม่ต้องเขียน code มาก

เหมาะกับงาน business-facing, proof of concept, internal assistant และ prototype ที่ยัง risk ต่ำ

ขั้นที่ 2 คือ Managed Agents API

Google บอกว่ามันคือทางเลือกสำหรับทีมเทคนิคที่อยาก “manage the mission, not the machine”

แปลเป็นภาษาคนทำงานคือ ทีม package instructions, skills และ tools แล้ว POST config เข้าไป จากนั้น Gemini สร้างและรัน agent ให้ใน Google Cloud sandbox

จุดสำคัญคือแต่ละ agent มี ephemeral sandbox ของตัวเอง และ sandbox นั้น provision ด้วย skills, MCP servers และ server-side tools

นี่คือจุดที่ข่าวเริ่มน่าสนใจ เพราะมันไม่ใช่แค่ API เรียก model แต่เป็น managed execution environment สำหรับ agent

ขั้นที่ 3 คือ Antigravity 2.0 และ Antigravity CLI

Google วาง Antigravity เป็น work surface สำหรับ coding agent และ agent orchestration

Antigravity 2.0 เป็น desktop app สำหรับ steer, customize และ orchestrate coding agents ส่วน CLI เอาประสบการณ์เดียวกันเข้ามาใน terminal

Google บอกว่า desktop และ CLI share authentication, context, skills และ configurations กัน

สิ่งนี้สะท้อนทิศทางเดียวกับที่เราเห็นในโลก coding agent ช่วงหลัง:

agent ไม่ได้อยู่แค่ใน chat box แล้ว แต่มันเริ่มมี workspace, context, permission, skills และงานที่รันข้ามหลาย step

ขั้นที่ 4 คือ ADK 2.0

ถ้า Managed Agents API เป็น configuration-first, ADK คือ engineering-first

ADK 2.0 เพิ่ม unified graph-based engine สำหรับงานที่ต้องผสม dynamic model-led reasoning กับ deterministic workflow

มี collaborative workflows ที่ coordinator delegate งานให้ subagents ผ่าน mode เช่น chat, task และ single-turn

มี dynamic workflows ที่ให้ developer เขียน routing logic ด้วยภาษาโปรแกรมปกติ

และมี Kotlin beta เพื่อเชื่อม mobile/on-device agents กับ backend agents

นี่คือชั้นที่เหมาะกับ workflow ที่มีหลาย path, หลาย subagent, หลาย tool และต้องควบคุม logic มากกว่า prompt เดียว

2) A2A ทำให้ข่าวนี้ไม่ใช่แค่ product list

ใต้ 4 ขั้นนี้ Google วาง A2A protocol เป็นฐานร่วม

A2A หรือ Agent2Agent เป็น open standard สำหรับให้ agent คุยและร่วมงานกันข้าม framework หรือ vendor

เอกสาร A2A อธิบายง่าย ๆ ว่า MCP คือ agent-to-tool communication ส่วน A2A คือ agent-to-agent communication

พูดอีกแบบ:

MCP ทำให้ agent ใช้ tool ได้ A2A ทำให้ agent คุยกับ agent อื่นได้

ถ้าเชื่อมกับข่าว Google Cloud รอบนี้ ภาพจะชัดขึ้น

agent ที่เริ่มจาก Agent Studio อาจกลายเป็น sub-agent ของระบบที่สร้างด้วย ADK ได้ agent ที่ใช้ Managed Agents API อาจถูกเรียกเป็นส่วนหนึ่งของ mesh ใหญ่กว่า coding agent ที่ developer ชอบอยู่แล้ว เช่น Claude Code หรือ Cursor อาจยังเป็น interface เดิม แต่ inference, governance และ infrastructure วิ่งผ่าน Google Cloud ได้

นี่คือทิศทาง platform มากกว่า tooling

Google ไม่ได้ขายแค่ “ใช้ tool เราสิ” แต่กำลังขายแนวคิดว่า agent แต่ละชนิดควรต่อกันได้ภายใต้ runtime, protocol และ governance เดียวกัน

3) Production agent ไม่ได้จบที่ prompt ดี

ส่วนที่ผมคิดว่าธุรกิจควรสนใจมากที่สุดไม่ใช่ Antigravity หรือ ADK เพียงอย่างเดียว

แต่คือคำว่า governance, evaluation, identity, gateway, registry และ sandbox

ในเอกสาร Agent Platform scale Google พูดถึง production capabilities หลัก ๆ เช่น:

• managed runtime
• sessions และ memory bank
• evaluation service
• tracing, logging และ monitoring
• secure sandbox execution
• code execution และ computer use ใน controlled environment

ในบทความ Google-managed MCP servers มีอีกภาพที่สำคัญมาก:

agent ที่เรียก BigQuery MCP server ไม่ควรถูกคุมด้วย prompt ว่า “ห้ามเขียนข้อมูล” อย่างเดียว

ควรมี IAM Deny policy ที่ block tool call ที่ไม่ใช่ read-only ตั้งแต่ระดับ platform

และ Model Armor สามารถ inspect MCP tool calls กับ responses เพื่อบล็อก prompt injection, malicious URI หรือ dangerous content

นี่คือ mindset ของ production agent

prompt เป็นแค่ชั้นหนึ่ง platform policy ต้องเป็นอีกชั้นหนึ่ง log ต้องมี eval ต้องมี identity ต้องมี rollback ต้องคิดไว้ approval ต้องออกแบบ

ถ้า agent แตะข้อมูลลูกค้า เงิน ระบบหลังบ้าน หรือ production แล้วไม่มีชั้นเหล่านี้ เราไม่ได้มี production agent ครับ

เรามี demo ที่โชคดีว่ายังไม่พัง

4) ธุรกิจไทยควรอ่านข่าวนี้ยังไง

ผมไม่คิดว่า SME ไทยควรตื่นขึ้นมาแล้วรีบเลือกว่าจะใช้ Agent Studio, Managed Agents API, Antigravity หรือ ADK

นั่นยังเป็นคำถามปลายทาง

คำถามต้นทางควรเป็น checklist แบบนี้:

1. workflow นี้ซ้ำบ่อยแค่ไหน
2. input และ output ชัดไหม
3. risk อยู่ตรงไหน
4. agent อ่านข้อมูลอย่างเดียวหรือเขียนข้อมูลด้วย
5. ต้องมีคน approve จุดไหน
6. ต้องเก็บ proof อะไรหลังงานจบ
7. ถ้า agent ทำผิด ต้อง rollback ยังไง
8. จะวัดคุณภาพด้วย example/eval/tracing อะไร

พอเห็นคำตอบแล้วค่อยเลือก rung

ถ้าเป็นงาน internal knowledge helper อาจเริ่ม low-code

ถ้าเป็น workflow ที่มี instructions, tools และ skills ชัด แต่ไม่อยากดูแล infrastructure เอง อาจดู Managed Agents API

ถ้าเป็นงาน software delivery อาจเริ่มที่ coding-agent work surface อย่าง Antigravity หรือ coding tool ที่ทีมใช้อยู่ แล้วต่อเข้ากับ cloud governance

ถ้าเป็น workflow ที่มี routing, branch, subagent, tool orchestration และต้องการ deterministic บางส่วน ค่อยลงทุนกับ ADK

นี่คือเหตุผลที่ผมเรียกมันว่า Agent Ladder

ไม่ใช่เพราะบันไดของ Google สำคัญที่สุด แต่เพราะวิธีคิดแบบบันไดสำคัญกับทุกทีมที่กำลังเอา AI Agent เข้างานจริง

5) มุม Data-Espresso: จาก chatbot ไปเป็น operating layer

สิ่งที่ข่าวนี้ยืนยันคือ AI Agent กำลังขยับจาก chatbot ไปเป็น operating layer

operating layer แปลว่า agent ไม่ได้มีแค่ model แต่ต้องมี:

• runtime ที่รันงานได้
• memory และ session ที่เก็บ state ได้
• skills ที่เก็บวิธีทำงานได้
• tools ที่เชื่อมระบบจริงได้
• protocol ที่ให้ agent คุยกันได้
• sandbox ที่ลด blast radius ได้
• eval ที่วัดคุณภาพได้
• identity และ gateway ที่คุมสิทธิ์ได้
• logs และ trace ที่พิสูจน์ได้ว่าเกิดอะไรขึ้น

นี่คือ pattern เดียวกับที่เราพูดใน OPB Stack และ Business OS มาตลอด

AI coworker ที่ใช้ได้จริงต้องมีบ้าน ต้องมีขอบเขต ต้องมีเครื่องมือ ต้องมี memory ต้องมี proof และต้องมี approval

ข่าว Google Cloud รอบนี้จึงไม่ใช่แค่ข่าวสำหรับ developer

มันเป็นสัญญาณให้เจ้าของธุรกิจและทีมปฏิบัติการเห็นว่า ถ้าจะเอา agent เข้าระบบจริง เราต้องออกแบบ workflow, control และ governance ตั้งแต่ต้น

ไม่ใช่ค่อยตามแก้ทีหลัง

6) คำถามที่ควรถามก่อนเริ่ม agent project ถัดไป

ก่อนจะเลือก platform ผมอยากให้ทีมถาม 6 ข้อนี้ก่อน:

1. งานนี้ agent ต้องอ่านอะไร และเขียนอะไร
2. ถ้า agent เรียก tool ผิด จะเสียหายระดับไหน
3. approval gate อยู่ตรงไหน
4. proof หลังจบงานคืออะไร
5. eval จะทดสอบพฤติกรรมผิดพลาดแบบไหน
6. workflow นี้ควรเริ่มที่ prototype, managed sandbox, coding surface หรือ code-first orchestration

ถ้าตอบไม่ได้ แปลว่ายังไม่ควรรีบ production

เริ่มจาก shadow mode ก่อน ให้ agent แนะนำ ให้คนตรวจ ให้ระบบเก็บ log แล้วค่อยขยับขึ้นบันได

นี่คือวิธีที่ปลอดภัยกว่า และเป็นวิธีที่มีโอกาสสร้างมูลค่าจริงมากกว่า

สรุป

Google Cloud I/O 26 รอบนี้ไม่ได้ประกาศแค่เครื่องมือสร้าง agent เพิ่ม

มันประกาศภาพของ agent stack ที่มีตั้งแต่ low-code, managed sandbox, coding-agent work surface, ADK orchestration, A2A, MCP, Skill Registry, eval, identity, gateway และ governance

สำหรับคนทำธุรกิจ ประโยคสำคัญไม่ใช่ “ควรใช้ตัวไหนดี”

แต่คือ:

เริ่มจาก workflow risk แล้วค่อยเลือก rung

ถ้า AI Agent ไม่มี boundary, proof, eval และ approval มันยังไม่ใช่ระบบ production

มันยังเป็นแค่ demo ที่ดูดีครับ