Tool Calling คืออะไร: ทำให้ AI สั่งงานระบบจริงได้

เจาะกลไก Tool Calling ทีละขั้น ความต่างของ client tools กับ server tools และหลักออกแบบเครื่องมือให้ AI Agent ใช้ได้ถูกต้องและปลอดภัย

ร้านออนไลน์แห่งหนึ่งให้ AI ตอบแชตลูกค้าใน LINE OA ลูกค้าถามว่า "ออเดอร์ #10482 ส่งถึงไหนแล้ว" ถ้า AI ไม่มีทางเข้าถึงระบบขนส่ง มันมีแค่สองทางเลือก: ตอบว่าไม่ทราบ หรือแย่กว่านั้นคือเดาสถานะขึ้นมาเอง สิ่งที่ทำให้ AI ตอบได้จริงคือความสามารถที่เรียกว่า Tool Calling หรือ Function Calling

Tool Calling คืออะไร

Tool Calling คือกลไกที่ให้โมเดลภาษาบอกว่า "อยากเรียกเครื่องมือตัวไหน ด้วยข้อมูลอะไร" ในรูปแบบที่โปรแกรมอ่านได้ แล้วระบบของคุณเป็นคนรันเครื่องมือนั้นจริง เอกสาร Tool use ของ Claude เขียนไว้ชัดว่า "โมเดลไม่ได้รันอะไรด้วยตัวเอง" มันแค่ส่งคำขอแบบมีโครงสร้าง แล้วโค้ดของคุณหรือเซิร์ฟเวอร์ของผู้ให้บริการเป็นผู้ทำงาน ผลลัพธ์จึงไหลกลับเข้าสู่บทสนทนา นี่คือส่วน "Act" ใน Agent Loop

กลไกทีละขั้น

คู่มือ Function calling ของ OpenAI สรุป flow ไว้ 5 ขั้น ซึ่งใช้ได้กับผู้ให้บริการแทบทุกเจ้า

1. ส่งคำขอไปยังโมเดล พร้อมรายการเครื่องมือที่เรียกได้
2. โมเดลตอบกลับเป็นการเรียกเครื่องมือ ประกอบด้วย ชื่อ และ arguments ในรูป JSON เช่น check_order_status กับ order_id เป็น "10482"
3. แอปของคุณรันฟังก์ชันนั้นจริง เช่น ยิง API ไปที่ระบบขนส่ง
4. ส่งผลลัพธ์กลับไปให้โมเดลในคำขอถัดไป
5. โมเดลตอบคำตอบสุดท้าย หรือขอเรียกเครื่องมือเพิ่ม

คู่มือเดียวกันแนะนำให้ถือว่าในหนึ่งคำตอบ โมเดลอาจเรียกเครื่องมือ "หลายตัว" พร้อมกัน โค้ดของคุณจึงควรรองรับกรณีนี้เสมอ

Client tools กับ Server tools

เอกสารของ Claude แบ่งเครื่องมือตามว่าใครเป็นคนรันโค้ด: เครื่องมือที่คุณนิยามเองและรันในแอปของคุณ กับเครื่องมือฝั่งเซิร์ฟเวอร์ที่ผู้ให้บริการรันให้ เช่น web search หรือ code execution ความต่างนี้สำคัญเรื่องความปลอดภัย เพราะเครื่องมือที่รันในระบบคุณย่อมเข้าถึงข้อมูลของคุณได้

ออกแบบเครื่องมือให้ Agent ใช้ถูก

คุณภาพของ Tool Calling ขึ้นกับการออกแบบเครื่องมือมากกว่าที่หลายคนคิด Anthropic เล่าใน Building effective agents ว่าตอนสร้าง Agent สำหรับ SWE-bench ทีมใช้เวลาปรับเครื่องมือมากกว่าปรับ prompt หลักเสียอีก บทความ Writing effective tools for AI agents (กันยายน 2025) ให้หลักไว้หลายข้อ

1. รวมขั้นตอนเป็นเครื่องมือเดียว

แทนที่จะมี list_users, list_events และ create_event แยกกัน ให้มี schedule_event ที่หาเวลาว่างและนัดในคราวเดียว เครื่องมือที่ซ้อนทับกันเยอะทำให้ Agent สับสน

2. ตั้งชื่อเป็นหมวดหมู่

ใช้ prefix บอกระบบและทรัพยากร เช่น crm_search_customer กับ erp_search_invoice เพื่อให้ Agent เลือกถูกตัว

3. คืนข้อมูลที่มีความหมาย

คืนชื่อลูกค้าแทนรหัส UUID ยาวๆ Anthropic พบว่าการแปลงรหัสเป็นภาษาที่อ่านเข้าใจช่วยลดการ hallucinate

4. คุมขนาดผลลัพธ์และเขียน error ให้ช่วยแก้ได้

ใส่ pagination หรือ filter และเขียน error ที่บอกวิธีแก้ เช่น "order_id ต้องเป็นตัวเลข 5 หลัก" แทน error code ที่อ่านไม่ออก

5. ทำให้ใช้ผิดได้ยาก

Anthropic เรียกหลักนี้ว่า poka-yoke เช่นบังคับใช้ path แบบเต็มเพื่อเลี่ยงความผิดพลาด ส่วน OpenAI แนะนำให้ใช้ enum และโครงสร้าง object ป้องกันค่าที่เป็นไปไม่ได้ และแนะนำแบบยืดหยุ่นว่าควรมีเครื่องมือน้อยกว่า 20 ตัวในแต่ละรอบ

ข้อควรระวัง

• Arguments อาจผิด: โมเดลอาจส่งค่าผิดรูปแบบหรือเลขผิด ต้อง validate ฝั่งเซิร์ฟเวอร์ทุกครั้ง ไม่เชื่อค่าจากโมเดลตรงๆ
• สิทธิ์เกินจำเป็น: OWASP จัด Excessive Agency ไว้ใน Top 10 ความเสี่ยงของแอป LLM ปี 2025 ให้เครื่องมือเข้าถึงเท่าที่งานต้องใช้เท่านั้น
• เครื่องมือที่เขียนข้อมูล: อย่างการโอนเงิน ลบข้อมูล หรือส่งอีเมลออกนอก ควรมีคนอนุมัติ อ่านต่อใน Guardrails และ Human-in-the-loop

Prompt บอก Agent ว่าควรทำอะไร แต่เครื่องมือเป็นตัวกำหนดว่ามันทำอะไรได้จริง

เริ่มต้นยังไง

1. ลิสต์คำถามที่ลูกค้าหรือทีมถามบ่อย แล้วดูว่าต้องดึงข้อมูลจากระบบไหน
2. เริ่มจากเครื่องมือแบบอ่านอย่างเดียว เช่น เช็กสถานะ ค้นข้อมูล
3. เขียนคำอธิบายเครื่องมือเหมือนอธิบายให้พนักงานใหม่ฟัง บอกรูปแบบของทุก parameter
4. ทดสอบด้วยคำถามจริง 20 ถึง 30 ข้อ แล้วดูว่าเรียกเครื่องมือถูกตัวไหม
5. ค่อยเพิ่มเครื่องมือที่เขียนข้อมูล พร้อมขั้นอนุมัติ

ทักษะออกแบบเครื่องมือให้ AI เป็นที่ต้องการทั้งในสายนักพัฒนาและสาย Automation ดูตำแหน่งงานที่เกี่ยวข้องได้ที่ Plants.work Jobs หรือเริ่มลงมือกับคอร์ส n8n Integrations