Google กำลังบอกให้เลิกยัดทุกอย่างลง Prompt: AI Agent ยุคใหม่ต้องโหลด Skill ตามงาน

Google โพสต์คู่มือ Developer’s Guide to Building ADK Agents with Skills เมื่อวันที่ 1 เมษายน 2026

หลายคนอาจมองว่านี่เป็นแค่ tutorial สำหรับคนใช้ ADK แต่ถ้าอ่านให้ลึก ผมคิดว่านี่คือสัญญาณสำคัญของตลาด AI agent ทั้งก้อน

เพราะสิ่งที่ Google กำลังผลัก ไม่ใช่แค่ feature ใหม่ แต่มันคือการเปลี่ยนวิธีออกแบบ agent จากโลกของ prompt ก้อนเดียว ไปสู่โลกของ skill ที่โหลดตามงานจริง

พูดง่ายๆ คือ จากเดิมที่หลายทีมพยายามยัด policy, SOP, style guide, API docs, troubleshooting, guardrails และ reference ทุกอย่างไว้ใน system prompt ก้อนเดียว ตอนนี้แนวคิดใหม่คือให้ agent เริ่มจากข้อมูลสั้นๆ ก่อน แล้วค่อยโหลด instruction หรือ resource เพิ่มเมื่อจำเป็น

Google เรียกสิ่งนี้ว่า progressive disclosure

และผมมองว่าแนวคิดนี้มีผลมากกว่าระดับ implementation detail เพราะมันกระทบทั้งต้นทุน, ความเร็ว, การดูแลรักษา, การ reuse ความรู้ และความสามารถในการ scale agent ให้โตขึ้นโดยไม่พังเร็วเกินไป

สิ่งที่เพิ่งเปลี่ยน

จากโพสต์ทางการของ Google วันที่ 1 เม.ย. ADK’s SkillToolset ถูกวางให้ agent โหลด domain expertise ตามต้องการ ไม่ต้องแบกทุกอย่างไว้ตั้งแต่ต้น

Google อธิบาย skill เป็น 3 ชั้นหลัก

• L1 Metadata: ชื่อและคำอธิบายสั้นๆ ของ skill
• L2 Instructions: คำสั่งหลักของ skill ที่โหลดเมื่อ agent ตัดสินใจใช้
• L3 Resources: reference, asset, หรือ resource อื่นที่โหลดเฉพาะตอนต้องใช้จริง

ถ้าดูเผินๆ อาจเหมือนแค่จัดเอกสารให้เป็นระเบียบขึ้น แต่ในทางปฏิบัติ มันคือการเปลี่ยนสถาปัตยกรรมของ context ทั้งระบบ

Google ยกตัวอย่างว่า ถ้า agent มี 10 skills มันอาจเริ่มแต่ละ call ด้วย metadata ระดับประมาณ 1,000 tokens แทนที่จะเริ่มด้วย prompt ยาว 10,000 tokens แบบยัดทุกอย่างไว้ในทีเดียว หรือคิดเป็นการลด baseline context usage ราว 90%

ตรงนี้สำคัญมาก เพราะปัญหาของ agent ในโลกจริงไม่ใช่แค่ “ตอบถูกไหม” แต่คือ “ยิ่งโต ยิ่งบวม”

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

ทำไมเรื่องนี้สำคัญกว่าที่ดู

ผมมองว่า skill architecture แบบนี้สำคัญอย่างน้อย 5 เรื่อง

1) มันเปลี่ยนจาก Prompt Engineering ไปสู่ Knowledge Orchestration

ช่วง 1-2 ปีที่ผ่านมา เวลาเราพูดเรื่อง AI agent เรามักวนอยู่กับคำถามว่า prompt ควรเขียนยังไง

แต่พอ workflow ซับซ้อนขึ้น คำถามที่สำคัญกว่าคือ

• ความรู้อะไรควรถูกโหลดตั้งแต่เริ่ม
• ความรู้อะไรควรโหลดเฉพาะเมื่อจำเป็น
• policy ไหนควรอยู่ใน skill
• reference ไหนควรอยู่ใน resource
• อะไรควรต่อผ่าน MCP หรือ fetch จาก docs สด

นี่ไม่ใช่แค่ prompt engineering แล้ว แต่มันคือ knowledge orchestration

คนที่ออกแบบ agent ดีในรอบต่อไป อาจไม่ใช่คนที่เขียน prompt เก่งที่สุด แต่เป็นคนที่จัดโครงสร้างความรู้และการเรียกใช้ความรู้ได้ดีที่สุด

2) ต้นทุนจะไม่บานปลายเร็วเท่าเดิม

เวลาทีมเริ่มทำ agent ใหม่ๆ ต้นทุนมักยังไม่รู้สึกมาก เพราะ use case ยังเล็ก แต่พอระบบเริ่มมีหลาย task, หลาย policy, หลาย role, หลาย reference ค่า context จะเริ่มสะสมแบบเงียบๆ

ถ้า architecture บังคับให้ทุก call แบกทุกอย่างไปด้วย คุณกำลังจ่ายแพงแม้ user จะถามเรื่องเล็กๆ

แนวคิดแบบ progressive disclosure ช่วยลด baseline cost ตั้งแต่โครงสร้าง ไม่ใช่แค่ไล่บีบคำใน prompt ทีหลัง

สำหรับทีมที่มี use case ยาวๆ หรือมี tool หลายตัว นี่คือเรื่องจริงจังมาก เพราะมันกระทบทั้ง latency และ budget พร้อมกัน

3) การดูแล policy และ SOP จะง่ายขึ้น

ในองค์กรจริง ความรู้ไม่ได้หยุดนิ่ง

• compliance เปลี่ยน
• process เปลี่ยน
• SDK เปลี่ยน
• รูปแบบการเขียน code เปลี่ยน
• style guide เปลี่ยน
• ขั้นตอนอนุมัติเปลี่ยน

ถ้าทุกอย่างฝังอยู่ใน prompt ก้อนเดียว ทุกครั้งที่มีอะไรเปลี่ยน คุณต้องกลับไปแตะ “สมองก้อนกลาง” ของ agent ซึ่งทั้งเสี่ยง ทั้งแก้ยาก และมีโอกาสทำอย่างหนึ่งดีขึ้นแต่อีกอย่างพัง

แต่ถ้าความรู้ถูกแยกเป็น skill หรือ reference เป็นโมดูล คุณสามารถแก้เฉพาะส่วนที่เปลี่ยนได้ง่ายกว่า และ reuse ข้ามหลาย agent ได้ด้วย

นี่คือคุณค่าที่ทีม platform, ops และ compliance ควรสนใจมาก

4) มันเริ่มทำให้ skill กลายเป็น asset ขององค์กร

จุดที่ผมว่าน่าสนใจมากคือ Google ไม่ได้วาง skill เป็นของเล่นเฉพาะ ADK อย่างเดียว ในโพสต์เดียวกัน เขาระบุว่ารูปแบบนี้อิงกับ agentskills.io specification และ generated skill สามารถใช้ได้กับ ecosystem ที่รองรับ format เดียวกัน เช่น Gemini CLI, Claude Code และ Cursor

ถ้าแนวคิดนี้ไปต่อจริง skill จะไม่ใช่แค่ helper file แต่มันจะกลายเป็น portable operating knowledge

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

อันนี้สำคัญมากสำหรับทีมที่ไม่อยากล็อกตัวเองกับ stack เดียวในระยะยาว

5) มันเปิดทางสู่ agent ที่ “ขยายความสามารถเอง” ได้

Google อธิบาย pattern สูงสุดว่าเป็น skill factory คือ agent มี meta-skill สำหรับสร้าง skill ใหม่ตาม requirement แล้วโหลด skill ที่เพิ่งสร้างขึ้นมาใช้ต่อทันที

อันนี้ฟังดูเหมือน sci-fi แต่จริงๆ มันบอกอะไรชัดมาก อนาคตของ agent อาจไม่ใช่แค่เรียก tool เป็น แต่อาจต้อง “เขียนคู่มือการทำงานของตัวเองเพิ่ม” ได้ด้วย

อย่างไรก็ตาม Google ก็เตือนชัดว่าควรมี human-in-the-loop เพื่อตรวจ review skill ที่ generate ขึ้นมา และควรมี evaluation ก่อน deploy จริง

นั่นแปลว่าตลาดกำลังขยับไปสู่ agent ที่ self-extending ได้ แต่ยังไม่ใช่โลกที่ปล่อยให้มันสร้างความรู้ใหม่เองแบบไม่ต้องคุม

สิ่งที่น่าสนใจมาก: Google มี evidence รองรับ ไม่ได้พูดลอยๆ

ถ้าโพสต์วันที่ 1 เม.ย. เป็นเรื่อง architecture โพสต์ก่อนหน้านั้นของ Google วันที่ 25 มี.ค. คือหลักฐานเชิงผลลัพธ์ที่ช่วยให้เรื่องนี้น่าเชื่อมากขึ้น

ในบทความ Closing the knowledge gap with agent skills Google อธิบายว่าพวกเขาสร้าง Gemini API developer skill เพื่อช่วย coding agent ใช้เอกสารและ SDK ล่าสุดได้ดีขึ้น

ใน meta description ของโพสต์ Google ระบุว่า skill นี้ช่วยดัน performance จาก 28.2% เป็น 96.6% โดยให้ model เข้าถึง documentation และ coding primitives ที่อัปเดต

ตัวบทความยังย้ำอีกว่า model รุ่นใหม่ที่ reasoning ดีได้ประโยชน์จาก skill มากกว่ารุ่นเก่าอย่างชัดเจน

นี่เป็น insight ที่สำคัญมาก

เพราะมันบอกว่า skill ไม่ใช่เวทมนตร์ skill จะเวิร์กเมื่อจับคู่กับ model ที่ “รู้ว่าจะใช้มันเมื่อไร” และ “ใช้มันยังไง”

ดังนั้นถ้าใครอ่านข่าวนี้แล้วสรุปว่า “แค่เพิ่ม skill ทุกอย่างก็จบ” อันนี้ยังเร็วไป

แล้วมันต่างจาก MCP หรือ AGENTS.md ยังไง

นี่เป็นคำถามที่หลายทีมจะถามทันที

คำตอบแบบสั้นคือ มันไม่ใช่ของแทนกัน 100%

• Skill เหมาะกับ instruction และ reusable domain knowledge ที่เป็นโมดูล
• MCP เหมาะกับการเชื่อมระบบหรือดึงข้อมูล/เครื่องมือจาก source of truth แบบ live
• AGENTS.md หรือ project instructions เหมาะกับกติกา/แนวทำงานระดับ repo หรือ project

จริงๆ แล้วใน workflow ที่ดี มักต้องใช้ทั้งสามอย่างร่วมกัน

เช่น

• กฎการรีวิว security อยู่ใน skill
• docs ล่าสุดดึงผ่าน MCP
• มาตรฐาน project อยู่ใน AGENTS.md

คนที่ชนะรอบนี้น่าจะไม่ใช่คนที่เลือกอย่างใดอย่างหนึ่งอย่างสุดโต่ง แต่เป็นคนที่รู้ว่าแต่ละชิ้นควรอยู่ตรงไหน

มุมที่ทีมไทยควรอ่านให้ออก

ผมคิดว่ามี 4 เรื่องที่องค์กรไทยควรเริ่มคิดจากข่าวนี้

หนึ่ง อย่ามอง agent เป็นแค่ chatbot ที่เก่งขึ้น

ถ้ายังออกแบบ agent เหมือนแชตบอตที่ถูกอัด prompt เพิ่มเรื่อยๆ สุดท้ายคุณจะเจอปัญหาค่าใช้จ่าย, maintenance และความเปราะบางเร็วมาก

ข่าวนี้กำลังบอกว่า agent ที่โตได้จริงอาจต้องมีโครงสร้างความรู้แยกชั้นตั้งแต่แรก

สอง ความรู้ภายในองค์กรควรถูก modularize

หลายองค์กรมี SOP, checklist, policy, knowledge base, template, FAQs กระจายเต็มไปหมด ถ้ายังเก็บทั้งหมดเป็นเอกสารที่คนเปิดเองอย่างเดียว คุณยังไม่ได้แปลงมันให้ agent ใช้งานได้ดี

อนาคตน่าจะเป็นการค่อยๆ เปลี่ยน knowledge เหล่านี้ให้กลายเป็น skill หรือ resource ที่ agent โหลดใช้ได้อย่างมีระบบ

สาม ใครทำ internal tools ก่อน มีโอกาสเห็นผลก่อน

use case ที่เหมาะกับแนวคิดนี้มากคือ internal workflow เช่น

• compliance review
• code review guideline
• sales proposal checklist
• onboarding assistant
• support triage
• internal research workflow

เพราะงานเหล่านี้มีกฎ มี reference และมี step ที่ชัด เหมาะกับการทำ skill-based agent มากกว่างานปลายเปิดแบบกว้างๆ

สี่ governance จะสำคัญขึ้น ไม่ใช่น้อยลง

ยิ่ง agent โหลด knowledge ได้ดีขึ้น และสร้าง skill ใหม่ได้มากขึ้น governance จะยิ่งสำคัญ

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

• skill ไหนใครแก้ได้
• versioning ทำยังไง
• ใคร review ก่อนใช้จริง
• reference ไหนคือ source of truth
• ถ้า skill เก่า จะเตือนยังไง

ถ้าไม่คิดเรื่องนี้ตั้งแต่ต้น ระบบจะโตเร็วแต่เละเร็วเหมือนกัน

ข้อควรระวัง: ข่าวนี้ไม่ได้แปลว่า problem ถูกแก้หมดแล้ว

Google เองก็ไม่ได้พูดว่า skill คือคำตอบสุดท้ายของทุกอย่าง

มี caveat สำคัญอย่างน้อย 3 เรื่อง

1) ฟีเจอร์ยัง experimental

เอกสาร ADK ระบุชัดว่า Skills feature ยังเป็น experimental และยังมี known limitations อยู่ ดังนั้นถ้าจะใช้ใน production ต้องเผื่อความเปลี่ยนแปลงของ API และ behavior ไว้ด้วย

2) เรื่อง update ยังไม่สวย

ในโพสต์วันที่ 25 มี.ค. Google ยอมรับเองว่า skill ยังมีปัญหาเรื่องการอัปเดต เพราะผู้ใช้ต้อง update เองเป็นหลัก ถ้าปล่อย skill เก่าคาไว้ใน workspace มันอาจให้ข้อมูลที่ล้าสมัยและกลายเป็นผลเสียแทน

นี่คือ pain point จริงของทุกองค์กร เพราะ “ความรู้เก่าแต่ดูเหมือนถูกต้อง” อันตรายกว่าการไม่มีความรู้ด้วยซ้ำ

3) Reasoning model ยังสำคัญมาก

skill ไม่ได้ทำให้ model อ่อนกลายเป็นเก่งโดยอัตโนมัติ Google ชี้ว่ารุ่นใหม่ที่ reasoning ดีกว่าจะใช้ skill ได้มีประสิทธิภาพกว่าชัดเจน

แปลว่า architecture ดีอย่างเดียวไม่พอ คุณยังต้องจับคู่ model, workflow และ knowledge layer ให้เหมาะกันด้วย

Playbook 30 วันสำหรับทีมที่อยากลองจริง

ถ้าผมต้องแปลง insight นี้เป็น action plan ให้ทีมหนึ่ง ผมจะทำแบบนี้

สัปดาห์ที่ 1: หยิบ use case เดียวที่มีกฎชัด

เลือกงานที่มี checklist, SOP, หรือ reference ชัดเจน เช่น review เอกสาร, triage ticket, compliance pre-check, proposal QA

อย่าเริ่มจาก use case ที่ปลายเปิดเกินไป

สัปดาห์ที่ 2: แยก knowledge ออกจาก prompt

ลองแตกสิ่งที่เคยอยู่ใน prompt ใหญ่เป็น

• metadata สั้นๆ
• instruction หลัก
• reference หรือ resource เฉพาะทาง

แค่นี้ทีมก็จะเริ่มเห็นแล้วว่าความรู้ก้อนไหนควรอยู่ตรงไหน

สัปดาห์ที่ 3: ตั้งกติกาเรื่อง update และ review

กำหนด owner ของแต่ละ skill กำหนดว่าแก้เมื่อไร review โดยใคร และ version ยังไง ถ้าไม่มี owner skill จะกลายเป็นซากเอกสารเวอร์ชันใหม่รูปแบบหนึ่ง

สัปดาห์ที่ 4: วัดผลมากกว่าดู demo

ดูอย่างน้อย 4 อย่าง

• latency
• token usage
• success rate
• rate ของงานที่ต้อง human correction

ถ้าดีขึ้นจริง ค่อยขยายไป workflow ถัดไป

คำถามที่หลายคนน่าจะสงสัย

ถ้าเราใช้ Claude Code หรือ Cursor อยู่ ต้องสนใจข่าวจาก Google ไหม

ควรสนใจ

เพราะสัญญาณสำคัญไม่ใช่ ADK เองอย่างเดียว แต่คือแนวคิดเรื่อง skill format ที่เริ่มคุยกันข้าม ecosystem มากขึ้น และ Google เองก็ยกตัวอย่างเครื่องมือเหล่านี้ในบทความและเอกสาร

งั้น prompt engineering จะหายไปไหม

ไม่หาย แต่บทบาทมันจะเปลี่ยน

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

ควรให้ agent สร้าง skill เองเลยไหม

เริ่มได้ใน sandbox แต่ไม่ควรปล่อยเข้า production แบบไม่ review

แนวคิด skill factory น่าสนใจมาก แต่ยิ่งให้ agent สร้างความรู้เอง ยิ่งต้องมี review และ eval ที่จริงจัง

เรื่องนี้สำคัญกับคนที่ไม่ใช่ developer ไหม

สำคัญ

เพราะสุดท้าย skill ไม่ได้มีไว้เขียนโค้ดอย่างเดียว มันใช้กับ SOP, policy, compliance, onboarding, support, sales และ knowledge workflow ได้หมด

สรุป

สิ่งที่ Google ทำรอบนี้ไม่ได้เป็นแค่ tutorial สำหรับคนเล่น ADK

มันกำลังส่งสัญญาณชัดว่า agent architecture ยุคต่อไปอาจไม่ใช่การแข่งขันกันว่าใครเขียน prompt ยาวและฉลาดกว่ากัน แต่เป็นการแข่งขันกันว่าใครออกแบบ knowledge loading ได้ดีกว่า

ถ้าคุณยังยัดทุกอย่างไว้ใน prompt ก้อนเดียว มันอาจพอไหวตอน use case ยังเล็ก แต่พอ agent ต้องโต ต้องคุมต้นทุน ต้องเปลี่ยน policy บ่อย และต้องใช้ข้ามทีม ปัญหาจะเริ่มโผล่เร็วมาก

แนวคิดแบบ skill + progressive disclosure จึงน่าสนใจ ไม่ใช่เพราะมันดูเท่ แต่เพราะมันเริ่มตอบโจทย์ของโลกจริงมากขึ้น

ผมมองว่านี่คืออีกหนึ่งสัญญาณว่า ปี 2026 เราเริ่มขยับจากยุค prompt engineering ไปสู่ยุค knowledge orchestration แล้วจริงๆ

และถ้าใครอ่านเกมนี้ออกก่อน ก็มีโอกาสสร้าง agent ที่ scale ได้ง่ายกว่า คุมง่ายกว่า และต่อยอดข้าม tool ได้ดีกว่า

✍️ เนื้อหาและมุมมองโดย Arty | มี Espresso Bot ☕🤖 ช่วยรวบรวมข้อมูลและจัดเรียบเรียง