ลองจินตนาการดู
คุณให้เครื่องมือห้าอย่างกับคำสั่งเดียวแก่เอเจนต์
กระบวนการคืนเงินของคุณอาจทำงานได้อย่างสมบูรณ์
แล้วอีเมลยืนยันก็ล้มเหลว
เอเจนต์เริ่มลำดับใหม่ทั้งหมด แล้วทำซ้ำการทำงานที่สำเร็จไปแล้ว
ผลลัพธ์คืออะไร? เงินคืนสองรอบ
โปรโตไทป์ทำงานได้อย่างสวยงาม แต่ระบบ production กลับไม่เป็นอย่างนั้น
ปัญหาไม่ใช่ที่ตัว prompt
ปัญหาคือการให้โมเดลรันกระบวนการที่มันไม่ควรจะรันตั้งแต่แรก!
LLMs ถูกบังคับให้ทำงาน routing, scheduling และ error management อยู่ตลอด
งานเหล่านี้เป็นงานที่ซอฟต์แวร์ทั่วไปจัดการได้อย่างแม่นยำสมบูรณ์แบบอยู่แล้ว
แต่เรากลับให้ AI ทำงานสองอย่างที่ขัดแย้งกัน:
- อ่านโลก: ทำความเข้าใจข้อมูลที่คาดเดาไม่ได้และไม่มีโครงสร้าง
- รันกระบวนการ: จัดลำดับเหตุการณ์ที่ตายตัวและกำหนดไว้ล่วงหน้า
อย่างแรกคือจุดที่ AI โดดเด่น ส่วนอย่างที่สองคือหน้าที่ของ code แบบดั้งเดิม
เมื่อรู้ขั้นตอนถัดไปอยู่แล้ว โมเดลก็ไม่ควรต้องเดา
จินตนาการเอเจนต์อัตโนมัติตัวเดียวที่ได้รับเครื่องมือห้าอย่างกับคำสั่งใหญ่หนึ่งชุด:
→ ดึงประวัติการซื้อ
→ ตรวจสอบนโยบายการคืนเงิน
→ ดำเนินการคืนเงินหากมีสิทธิ์
→ ส่งอีเมล
→ แล้วปิด ticket
เพื่อให้สำเร็จ เอเจนต์ต้องจำลำดับ ตรวจสอบผลลัพธ์ของทุกเครื่องมือ และคาดเดาว่าขั้นตอนถัดไปคืออะไร
ถ้าอีเมลยืนยันล้มเหลวหลังจากส่งเงินไปแล้ว โมเดลจะพยายามสร้าง workflow ขึ้นใหม่จาก context window แทนที่จะดำเนินการต่อจากสถานะการทำงานที่ปลอดภัย
ผลลัพธ์ก็คือการคืนเงินสองรอบที่พูดถึงตอนต้นนั่นแหละ
ADK 2.0 จัดการความวุ่นวายได้อย่างไร
ADK 2.0 ของ Google แก้ปัญหานี้ด้วยแนวทางใหม่ทั้งหมด
มันเปลี่ยนการทำงานที่คาดเดาได้กลับมาเป็นขั้นตอน workflow ที่เป็นรูปธรรม โดยใส่ AI ลงไปเฉพาะจุดที่ต้องตีความจริง ๆ เท่านั้น:
[กราฟ workflow การคืนเงิน - ที่มา: "Why we built ADK 2.0"]
ในตัวอย่างข้างต้น การดึงประวัติการซื้อ การคืนเงิน และการปิด ticket คือการทำงานของซอฟต์แวร์ปกติ
ส่วนการวิเคราะห์ข้อร้องเรียนและการร่างข้อความยืนยันเฉพาะบุคคลเป็นหน้าที่ของ AI
ผลลัพธ์คือการผสมผสานที่ลงตัว: การทำงานที่ตายตัว ควบคู่กับการใช้เหตุผลแบบเจาะจง
แต่คุณอาจจะคิดว่า: นี่มันแค่การกลับไปใช้ระบบอัตโนมัติแบบตายตัวไม่ใช่เหรอ?
เรากำลัง hard-code workflow ที่เอเจนต์ควรจะมาแทนที่หรือเปล่า?
จริง ๆ แล้วก็ไม่เชิง
Workflow จะเป็นตัวกำหนดขอบเขตที่รู้อยู่แล้ว
เอเจนต์ยังคงจัดการส่วนที่ต้องใช้การตีความ ภาษา หรือดุลยพินิจ
เป้าหมายไม่ใช่การลบความยืดหยุ่น แต่คือการหยุดบังคับให้โมเดลค้นหาเส้นทางการทำงานเดิมซ้ำแล้วซ้ำเล่าในทุก ๆ รอบ
เมื่อตัดการตัดสินใจที่ไม่จำเป็นของโมเดลออกไป สถาปัตยกรรมนี้ก็เปลี่ยนตัวเลขไปโดยสิ้นเชิง
Workflow การคืนเงินเดียวกัน โมเดลเดียวกัน
แต่กับ ADK 2.0 จำนวน token ลดจาก 5,152 เหลือ 2,265 และ latency ลดจาก 7.2 วิ เหลือ 5.7 วิ 🔥
[ที่มา: "Why we built ADK 2.0"]
โครงสร้างนี้ทำหน้าที่เหมือนตัวกรองธรรมชาติที่ลดการใช้ token ลงครึ่งหนึ่ง
แทนที่จะส่งประวัติทั้งหมด เอเจนต์จะเห็นเฉพาะสิ่งที่ต้องใช้ (เช่น policy agent เห็นเฉพาะข้อร้องเรียน)
ประโยชน์ที่ได้ทันที:
- ลดเสียงรบกวนใน prompt และเพิ่มความเป็นส่วนตัว
- การทำงานถูกจำกัดอยู่ในกรอบที่เข้มงวด
- ระบบกันพลาด: โมเดลอาจตัดสินใจผิดได้ แต่จะไม่มีทางคิดเส้นทางของตัวเองขึ้นมาได้
Frontend ก็ต้องการขอบเขตเช่นกัน: A2UI ทำให้ UI ของคุณอยู่ในการควบคุม
เยี่ยมมาก ตอนนี้ workflow การคืนเงินอยู่ในการควบคุมแล้ว
ADK 2.0 กำหนดเส้นทางและป้องกันไม่ให้เอเจนต์สร้างลำดับของตัวเองขึ้นมา
แต่ ผู้ใช้ยังต้องการวิธีที่ปลอดภัยในการเห็นและดำเนินการกับสิ่งที่เอเจนต์สร้างขึ้น
พูดง่าย ๆ คือ frontend ก็ต้องการขอบเขตเหมือนกัน!
สมมติว่าการคืนเงินที่อนุมัติทุกครั้งต้องมีการลงนามอนุมัติจากหัวหน้างาน
เอเจนต์ ไม่ควร สร้างข้อความง่าย ๆ แบบว่า:
"การคืนเงินนี้ได้รับการอนุมัติแล้ว"
มันต้องแสดงการ์ดที่มีโครงสร้าง ซึ่งประกอบด้วย
- จำนวนเงิน
- ธุรกรรม
- เหตุผลตามนโยบาย
- ปุ่ม 'อนุมัติ/ปฏิเสธ' ที่ชัดเจน
นี่คือจุดที่ A2UI ของ Google เข้ามามีบทบาท!
ด้วย A2UI เอเจนต์จะส่งคืน JSON payload แบบ declarative แทนที่จะเป็นโค้ด frontend ที่รันได้
Host จะตรวจสอบ payload นั้นและเรนเดอร์เฉพาะคอมโพเนนต์ที่อยู่ใน catalogue ของมันเท่านั้น
เอเจนต์ตัดสินใจว่าข้อมูลใดจะแสดง และแอปควบคุมวิธีเรนเดอร์
👇 ด้านล่างคือตัวอย่างการ์ดที่เรนเดอร์ด้วย A2UI ซึ่งแสดงให้เห็นความหลากหลายของ UI ที่ A2UI ทำได้:
เดโม A2UI-over-MCP Recipe Studio ของ Google แสดงสถาปัตยกรรมนี้ในทางปฏิบัติ:
ที่มา: Google Developers Blog
👆 คุณจะเห็นว่าฟอร์มเลือกแบบคงที่ถูกส่งผ่าน MCP Resource ขณะที่การ์ดสูตรอาหารที่สร้างแบบไดนามิกถูกส่งกลับผ่าน MCP Tool
A2UI เรนเดอร์ทั้งสองแบบได้โดยตรงภายในแอปพลิเคชัน host
เห็นความสมมาตรไหม?
- ADK 2.0 จำกัดสิ่งที่เอเจนต์ทำได้บน backend
- A2UI จำกัดสิ่งที่มันสร้างได้บน frontend
ในทั้งสองกรณี โมเดลมีพื้นที่ให้ใช้เหตุผล แต่เฉพาะภายในขอบเขตที่แอปพลิเคชันกำหนดไว้
กลับมาที่ตัวอย่างการคืนเงินที่เราคุยกันข้างต้น การคืนเงินทั่วไปอาจต้องการแค่การ์ดอนุมัติง่าย ๆ
แต่กรณีที่มีข้อโต้แย้ง เกี่ยวข้องกับข้อยกเว้น เอกสารแนบ หรือการชำระคืนบางส่วน อาจต้องใช้ประสบการณ์ที่สมบูรณ์กว่า
นี่คือจุดที่ MCP App เข้ามาช่วย โดยให้พื้นที่ทำงานแบบจำกัดสำหรับการโต้ตอบที่ซับซ้อน:
→ ADK ควบคุมสิ่งที่จะเกิดขึ้นได้
→ A2UI ทำให้ผลลัพธ์มองเห็นและดำเนินการได้
→ MCP Apps จัดการพื้นที่ทำงานที่ซับซ้อน
อยากรู้เพิ่มเติมไหม?
นี่คือทุกสิ่งที่คุณต้องใช้เพื่อสำรวจ ADK 2.0, A2UI และแพลตฟอร์ม agent ที่กว้างขึ้นของ Google Cloud:
- ADK 2.0: https://fandf.co/4yJhcyh
- A2UI: https://fandf.co/3S1O9pe
- A2UI over MCP: https://fandf.co/45vomJ3
- Gemini Enterprise Agent Platform: https://fandf.co/4x59VY7
เป็นเกียรติอย่างยิ่งที่ได้ร่วมงานกับ @googlecloud ในโปรเจกต์นี้! 🤝
ถ้าอยากติดตามข่าวสารล่าสุดเกี่ยวกับ LLMs, AI agents และ workflows สามารถติดตามผมได้ที่ @datachaz เพื่อรับข้อมูลเชิงลึกรายวัน
