Google ADK Skills: เมื่อ Agent เริ่มมีคู่มือทำงาน ไม่ใช่จำทุกอย่างไว้ในหัว

หลายทีมที่เริ่มทำ AI agent จะเจออาการเดียวกันครับ

ช่วงแรกทุกอย่างดูง่ายมาก

เขียน prompt ยาวขึ้นนิดหนึ่ง ใส่ tool เพิ่มอีกหน่อย agent ก็เริ่มทำงานได้

แต่พองานจริงเริ่มเยอะขึ้น ความรู้เริ่มกระจัดกระจายทันที

คู่มืออยู่ใน Google Docs

policy อยู่ใน Notion

template อยู่ใน Drive

ตัวอย่างงานดี ๆ อยู่ใน Slack

script อยู่ใน repo

ส่วน prompt อยู่ในหัวคนทำระบบ

แล้วเราก็เริ่มแก้ปัญหาด้วยวิธีคลาสสิกมาก คือยัดทุกอย่างเข้า prompt

ผลลัพธ์คือ agent ยังไม่ทันทำงานก็แบก context หนักเหมือนเด็กฝึกงานที่โดนโยน handbook ทั้งบริษัทใส่หน้าในวันแรก

อ่านหมดไหม ไม่หมด

จำได้ไหม ไม่ครบ

เอาไปใช้ถูกจังหวะไหม แล้วแต่ดวงครับ

Google ADK หน้าใหม่เรื่อง Skills for ADK agents น่าสนใจตรงนี้ เพราะมันไม่ได้พูดแค่ว่า agent ควรมี tool อะไร

แต่มันเริ่มพูดถึงวิธีแพ็ก “ความสามารถเฉพาะงาน” ให้ agent โหลดใช้เป็นชิ้น ๆ

นี่คือเรื่องใหญ่กว่าที่เห็นครับ

1) ADK Skill คืออะไร

ตาม docs ของ Google ADK, Skill คือหน่วยความสามารถแบบ self-contained ที่ agent ใช้ทำงานเฉพาะอย่างได้

ใน Skill หนึ่งชุดจะรวมสิ่งที่จำเป็นต่อการทำงานนั้น เช่น instructions, resources และ tools ที่เกี่ยวข้อง

แปลเป็นภาษาคนทำงาน:

Skill คือคู่มือปฏิบัติงานของ agent สำหรับงานหนึ่งประเภท

เช่น:

• วิธีเขียน proposal ในสไตล์บริษัท
• วิธีตรวจ invoice ก่อนส่งลูกค้า
• วิธีสรุป meeting เป็น action items
• วิธี review code ตามมาตรฐานทีม
• วิธีสร้าง Facebook post ในเสียงแบรนด์
• วิธีคัด lead ว่าควร follow-up ต่อหรือไม่

แทนที่จะเอาทุกอย่างไปยัดใน system prompt หลัก เราแยกมันออกมาเป็น skill เฉพาะทาง

เมื่อ agent เจองานที่ตรงกับ skill นั้น ค่อยโหลด instructions และ resources ที่เกี่ยวข้องเข้ามา

นี่คือแนวคิดที่เรียบง่าย แต่ใช้งานจริงได้มาก

เพราะงานในบริษัทไม่ได้มีแค่ “คุยกับ AI”

งานจริงมีขั้นตอน มี template มีข้อห้าม มีตัวอย่าง มี edge case มีคนรับผิดชอบ และมี definition of done

ถ้า agent จะทำงานจริง มันต้องเข้าถึงสิ่งเหล่านี้ได้แบบเป็นระบบ

2) โครงสร้างของ Skill: เล็ก แต่คิดมาดี

ADK อ้างอิง Agent Skill specification ซึ่งมอง skill เป็น directory หนึ่งชุด

โครงสร้างหลักประมาณนี้:

skill-name/
  SKILL.md
  references/
  assets/
  scripts/

ไฟล์ที่จำเป็นจริง ๆ มีแค่ SKILL.md

SKILL.md มี YAML frontmatter สำหรับ metadata เช่น name และ description แล้วตามด้วย markdown instructions

ส่วน folder อื่นเป็น optional:

• references/ สำหรับเอกสารเสริม เช่น API docs, workflow guide, policy, ตัวอย่าง edge case
• assets/ สำหรับ resource เช่น template, schema, form, sample data, image, config
• scripts/ สำหรับ helper script ที่ agent runtime รองรับ

มองแบบธุรกิจ นี่คือการแปลงความรู้ในหัวคนให้กลายเป็น operational package

ไม่ใช่แค่ prompt

ไม่ใช่แค่ knowledge base

แต่เป็นชุดคำสั่งพร้อม resource ที่ agent ใช้งานได้

ส่วนที่ผมชอบคือ docs อธิบายว่า skill ถูกจัดเป็น 3 ระดับ:

1. Metadata: agent เห็นชื่อและ description เพื่อรู้ว่ามี skill อะไรให้ใช้
2. Instructions: โหลด SKILL.md เมื่อ skill นั้นเกี่ยวข้องกับงาน
3. Resources: โหลดไฟล์เสริมเฉพาะเมื่อจำเป็น

นี่คือ context engineering แบบที่ practical มาก

ไม่ต้องโหลดทุกอย่างตั้งแต่ต้น

โหลดเท่าที่งานต้องใช้

3) ทำไมเรื่องนี้สำคัญกว่า prompt library

หลายบริษัทมี prompt library อยู่แล้ว

แต่ prompt library มักกลายเป็นโกดังข้อความ

มี prompt ดี ๆ เยอะ แต่ไม่รู้ว่า prompt ไหนควรใช้เมื่อไร ใครเป็นเจ้าของ แก้ล่าสุดตอนไหน และ output ที่ดีหน้าตาเป็นอย่างไร

Skill ต่างออกไปนิดหนึ่ง เพราะมันบังคับให้เราคิดเป็น “งาน”

Skill ที่ดีควรตอบได้ว่า:

• ใช้เมื่อไร
• ไม่ควรใช้เมื่อไร
• input ต้องมีอะไร
• output ควรเป็นแบบไหน
• ต้องเช็คอะไรบ้างก่อนจบ
• มีตัวอย่างงานดีไหม
• มีข้อควรระวังอะไร
• ถ้า fail ต้องทำอย่างไร

นี่คือสิ่งที่ prompt เดี่ยว ๆ มักไม่มี

ถ้าพูดแบบบ้าน ๆ:

prompt library คือคลังประโยค

skill library คือคลังคู่มือทำงาน

สองอย่างนี้ไม่เหมือนกันครับ

Agent ที่ทำงานจริงต้องการอย่างหลังมากขึ้นเรื่อย ๆ

4) ตัวอย่างใน ADK: ใช้ SkillToolset

ใน ADK คุณทำให้ agent ใช้ skill ได้ผ่าน SkillToolset

ตัวอย่าง Python ใน docs มี pattern ประมาณนี้:

from google.adk import Agent
from google.adk.skills import load_skill_from_dir
from google.adk.tools import skill_toolset

weather_skill = load_skill_from_dir("./skills/weather_skill")

my_skill_toolset = skill_toolset.SkillToolset(
    skills=[weather_skill],
    additional_tools=[get_weather_tool],
)

root_agent = Agent(
    model="gemini-flash-latest",
    name="skill_user_agent",
    instruction="You are a helpful assistant that can leverage skills.",
    tools=[my_skill_toolset],
)

แก่นของมันคือ agent ไม่ได้มีแค่ function tools แล้วจบ

มันมี toolset ที่ช่วยให้ agent รู้จัก skill, โหลด skill และโหลด resource ที่เกี่ยวข้อง

ADK docs ยังบอกว่า skill สามารถ define ใน code หรือโหลดจาก filesystem ได้

ฝั่ง Go ยังมีตัวอย่าง Source interface ที่สามารถ backed by data store ได้ด้วย

อันนี้น่าสนใจมาก เพราะมันเปิดประตูไปสู่ dynamic skills

เช่น skill ที่เก็บใน database, skill ที่ version ตามทีม, skill ที่เปิดใช้เฉพาะ role, หรือ skill ที่อัปเดตตาม policy ล่าสุด

ถ้าคิดให้ไกลขึ้น บริษัทอาจมี skill registry ภายในองค์กร

ไม่ใช่เพื่อโชว์เท่

แต่เพื่อทำให้ AI worker แต่ละตัวมีคู่มือทำงานที่ควบคุมได้

5) Business impact: ความรู้หน้างานเริ่มกลายเป็น software asset

สำหรับผม จุดที่น่าสนใจที่สุดไม่ใช่ syntax

แต่คือผลกระทบกับวิธีบริหารงาน

ทุกบริษัทมี tacit knowledge เยอะมาก

คนขายเก่งรู้ว่าลูกค้าประเภทไหนควร follow-up แบบไหน

ทีม support รู้ว่า complaint แบบไหนต้องรีบส่งต่อ

ทีม finance รู้ว่าเอกสารแบบไหนส่งไปแล้วจะโดนตีกลับ

ทีม content รู้ว่าโพสต์แบบไหนฟังเป็นแบรนด์เรา และแบบไหนฟังเหมือน AI แปะคำหรู

ความรู้นี้มักอยู่ในหัวคนเก่ง

พอเอา AI agent เข้ามา ถ้าเราไม่แพ็กความรู้เหล่านี้ให้ดี agent ก็จะทำงานแบบ generic

ตอบได้ แต่ไม่ใช่เรา

ทำได้ แต่ไม่เข้าระบบ

เร็วขึ้น แต่คุณภาพแกว่ง

Skill คือวิธีหนึ่งในการเปลี่ยนความรู้หน้างานให้กลายเป็น reusable asset

พูดอีกแบบคือ บริษัทไม่ได้แข่งกันแค่ใครใช้ model ใหม่กว่า

แต่แข่งกันว่าใครเปลี่ยน know-how ของตัวเองให้เป็น skill ที่ agent ใช้ซ้ำได้เร็วกว่า

นี่เข้ากับโลก agentic business มากครับ

เพราะถ้าทุกคนใช้ model ใกล้กัน ความต่างจะอยู่ที่ operating system ของงาน

6) ตัวอย่าง skill ที่ SME ไทยควรเริ่มทำก่อน

ถ้าเป็น SME หรือทีมเล็ก ผมไม่แนะนำให้เริ่มจาก skill ใหญ่ระดับ “บริหารทั้งบริษัท”

เริ่มจากงานที่มี pattern ชัดก่อน

ตัวอย่างที่คุ้ม:

Sales follow-up skill

ใช้เมื่อมี lead ใหม่หรือมี call note หลังคุยลูกค้า

ใน skill ควรมี:

• criteria การแยก hot, warm, cold lead
• tone of voice สำหรับ follow-up
• template ข้อความ LINE หรือ email
• ข้อห้าม เช่น ห้าม promise ราคา ห้ามลดราคาเอง
• checklist ว่าก่อนส่งต้องมีชื่อบริษัท pain point และ next step

Content voice skill

ใช้เวลาทำโพสต์หรือบทความในแบรนด์เดียวกัน

ใน skill ควรมี:

• voice guide
• คำที่ชอบใช้และคำที่ห้ามใช้
• ตัวอย่างโพสต์ที่ผ่าน approval
• hashtag rule
• anti-slop checklist
• ขั้นตอน source checking

Support triage skill

ใช้เมื่อมีข้อความลูกค้าหรือ ticket ใหม่

ใน skill ควรมี:

• ประเภทเคส
• severity level
• response template
• escalation rule
• ข้อมูลที่ต้องถามเพิ่ม
• เคสที่ agent ห้ามตอบเอง

Code review skill

ใช้ก่อน merge PR หรือก่อน deploy

ใน skill ควรมี:

• security checklist
• test commands
• style convention
• common failure modes
• definition of done
• rollback checklist

สิ่งสำคัญคือ skill ไม่ควรเป็นเอกสารสวย ๆ ที่ไม่มีใครใช้

มันควรเป็นคู่มือที่ agent ใช้แล้ว output ดีขึ้นจริง

ถ้า output ไม่ดี แปลว่า skill ยังเขียนไม่พอ ไม่ชัดพอ หรือไม่มีตัวอย่างที่ดีพอ

7) Context window ไม่ใช่ถังขยะ

ผมชอบประเด็นเรื่อง incremental loading มาก

เพราะช่วงที่ผ่านมา หลายคนแก้ปัญหา agent พลาดด้วยการใส่ context เพิ่ม

ตอบผิด ก็ใส่ rule เพิ่ม

ลืม format ก็ใส่ตัวอย่างเพิ่ม

ไม่เข้าใจ domain ก็ยัด docs เพิ่ม

ทำไปเรื่อย ๆ prompt กลายเป็นบ้านรก

ทุกอย่างสำคัญหมด แต่ agent แยกไม่ออกว่าอะไรสำคัญกับงานตอนนี้

Skill ทำให้เราคิดต่างออกไป

แทนที่จะถามว่า “ต้องใส่อะไรทั้งหมดใน prompt”

ให้ถามว่า “งานนี้ต้องโหลดคู่มือเล่มไหน”

นี่คือความต่างระหว่าง memory stuffing กับ context routing

และผมคิดว่านี่จะเป็นทักษะสำคัญของคนทำ agent ในปีนี้

ไม่ใช่เขียน prompt ยาวที่สุด

แต่คือจัดความรู้ให้ agent หยิบใช้ถูกเวลา

8) แต่ Skill ไม่ได้แก้ทุกอย่าง

ต้องพูดตรง ๆ ว่า ADK Skills ยังเป็น experimental

และต่อให้ spec ดี แต่ออกแบบ skill แย่ agent ก็ยังพังได้

Skill ที่แย่มักมีอาการแบบนี้:

• description กว้างเกินไป จน agent เรียกใช้ผิดงาน
• instructions ยาวมาก แต่ไม่มีขั้นตอนชัด
• ไม่มีตัวอย่าง output ที่ดี
• ไม่มี validation checklist
• ไม่มีข้อห้ามหรือ escalation rule
• update แล้วไม่มี version note
• resource เยอะ แต่ไม่บอกว่าอ่านไฟล์ไหนเมื่อไร

นี่เหมือนทำ SOP ให้มนุษย์ครับ

ถ้า SOP อ่านแล้วงง คนก็ทำผิด

AI ก็เหมือนกัน แถมผิดด้วยความมั่นใจกว่าอีกนิดหนึ่ง

ดังนั้น skill ที่ดีควรสั้น ชัด ใช้งานได้ และมี proof ว่า output ดีขึ้น

9) วิธีเริ่มทำ skill แบบไม่หลงทาง

ถ้าจะทดลองในทีม ผมแนะนำสูตรนี้:

1. เลือก workflow เดียวที่ทำซ้ำบ่อย
2. เก็บตัวอย่างงานดี 3 ถึง 5 ชิ้น
3. เขียน SKILL.md ให้มี trigger, steps, output format, validation
4. แยกเอกสารยาวไปไว้ references/
5. ใส่ template หรือ schema ไว้ใน assets/
6. ทดลองกับ case จริง 5 ถึง 10 เคส
7. จดว่า agent พลาดตรงไหน แล้วแก้ skill
8. อย่าให้ agent action งานเสี่ยงโดยไม่มี human approval

อย่าเริ่มด้วยการทำ skill library 50 อัน

เริ่มจาก skill เดียวที่ลดงานจริงได้ก่อน

ถ้า skill นั้นทำให้ทีมประหยัดเวลา 30 นาทีต่อวัน และ output นิ่งขึ้น นั่นคือของจริง

10) มุมมองของผม: Skills คือชั้นกลางระหว่าง prompt กับ organization memory

ถ้ามองภาพใหญ่ ผมว่า ADK Skills คือสัญญาณว่า agent platform กำลังโตขึ้น

ช่วงแรกเราคุยกับ AI ผ่าน prompt

ต่อมาเราให้ AI ใช้ tools

ตอนนี้เราเริ่มให้ AI มี skill package

ต่อไปสิ่งที่น่าจะเกิดขึ้นคือ agent จะไม่ได้ถูกวัดแค่ว่า model ฉลาดแค่ไหน

แต่จะถูกวัดว่าองค์กรมี skill library ดีแค่ไหน

เพราะ skill library คือการสะสม know-how ของบริษัทในรูปแบบที่ agent ใช้งานได้

นี่สำคัญมากสำหรับบริษัทไทย

เราไม่จำเป็นต้องมีทีม AI ใหญ่ที่สุด

แต่ถ้าเราเก็บ workflow หน้างานให้เป็น skill ได้เร็วกว่า เราจะได้เปรียบ

เพราะ AI ที่เข้าใจงานของเรา ย่อมมีค่ากว่า AI ที่เก่งกว้าง ๆ แต่ไม่รู้บริบทอะไรเลย

สรุป

Google ADK Skills ไม่ใช่แค่ฟีเจอร์อีกช่องใน framework

มันสะท้อนวิธีคิดสำคัญของยุค agentic work:

Agent ไม่ควรจำทุกอย่างไว้ใน prompt เดียว

มันควรรู้ว่าต้องโหลดคู่มือไหน ใช้ resource อะไร ทำตามขั้นตอนใด และส่ง proof อะไรกลับมาให้มนุษย์ตรวจ

สำหรับทีมที่อยากใช้ AI agent จริงจัง ให้เริ่มคิดเรื่อง skill library ได้แล้วครับ

ไม่ต้องใหญ่

ไม่ต้องหรู

เริ่มจาก workflow เดียวที่เจ็บจริง

เขียนคู่มือให้ชัด

ให้ agent ใช้

วัดผล

แก้ skill

ทำซ้ำ

สุดท้ายความได้เปรียบอาจไม่ได้อยู่ที่ใครมี agent เยอะกว่า

แต่อยู่ที่ใครมีคู่มือให้ agent ทำงานถูกทางมากกว่าครับ