Tool คืออะไร AI Agent เรียกใช้อย่างไร

เผยแพร่ 12 สิงหาคม 2569

ภาพประกอบ: Tool คืออะไร AI Agent เรียกใช้อย่างไร

บทความชุดถัดจากนี้จะพาไปเจาะลึกทีละ tool ของแต่ละผลิตภัณฑ์ ก่อนเข้าเรื่องนั้น บทความนี้อธิบายพื้นฐานก่อนว่า “tool” ในบริบทของ AI agent คืออะไร และ agent ตัดสินใจเรียกใช้ tool อย่างไร — เข้าใจตรงนี้ก่อน จะอ่านบทความเจาะลึกแต่ละ tool ต่อไปได้ลื่นขึ้นมาก

LLM เดี่ยวๆ ทำอะไรได้แค่ “ทายคำถัดไป”

โมเดลภาษา (LLM) ไม่ว่าจะใหญ่แค่ไหน โดยพื้นฐานแล้วทำอย่างเดียวคือรับข้อความเข้า แล้วทายว่าคำ/token ถัดไปควรเป็นอะไร ทำซ้ำไปเรื่อยๆ จนได้คำตอบ — มันไม่มีทาง “ไปเปิดไฟล์ในเครื่องคุณดู” หรือ “ไปเช็คราคาหุ้นตอนนี้” ได้ด้วยตัวเอง เพราะมันไม่มีมือไม่มีตา มีแค่ข้อความเข้า-ข้อความออก

นี่คือข้อจำกัดที่แท้จริงของ LLM: ความรู้ของมันหยุดอยู่ที่วันที่เทรนโมเดลเสร็จ และไม่รู้อะไรเลยเกี่ยวกับเครื่องหรือข้อมูลของคุณ

Tool คือสะพานเชื่อมระหว่างโมเดลกับโลกจริง

“Tool” (บางที่เรียก “function calling”) คือกลไกที่ให้โค้ดรอบๆ โมเดลทำงานแทน แล้วส่งผลลัพธ์กลับเข้าไปในบทสนทนาให้โมเดลอ่านต่อ ตัวอย่างที่เข้าใจง่าย:

ผู้ใช้ถาม: "ไฟล์ contract.pdf อยู่ไหน"
1. โมเดลตัดสินใจ: "ต้องค้นไฟล์ ไม่ใช่ทายเอง" → เรียก tool rag_search(query="contract.pdf")
2. โค้ด (ไม่ใช่โมเดล) รันคำสั่งค้นหาจริงในเครื่อง
3. ผลลัพธ์ (path ของไฟล์ที่เจอ) ถูกส่งกลับเข้า context ให้โมเดลอ่าน
4. โมเดลตอบผู้ใช้โดยอ้างอิงผลลัพธ์จริงที่เพิ่งได้มา ไม่ใช่เดา

จุดสำคัญ: โมเดลไม่เคยรันคำสั่งเอง มันแค่ “ขอ” ให้โค้ดรันให้ ด้วยการส่งชื่อ tool + argument ที่ต้องการออกมาเป็นข้อความที่มีรูปแบบตายตัว (structured call) — โค้ดฝั่งแอปเป็นคนตรวจสอบ อนุญาต/บล็อก แล้วรันจริง

Tool แต่ละตัวมี “schema” ที่บอกโมเดลว่ามันคืออะไร

ทุก tool ต้องประกาศตัวเองด้วย schema (แบบ OpenAI function-calling format) ที่มีอย่างน้อย:

  • ชื่อ (เช่น rag_search, bash, web_search)
  • คำอธิบาย (description) — บอกโมเดลว่า tool นี้ใช้ทำอะไร และเมื่อไรควรเรียก (ส่วนนี้สำคัญมาก มักมีตัวอย่าง ✅/❌ กำกับไว้ให้โมเดลเทียบ)
  • พารามิเตอร์ที่ต้องส่งมา (เช่น rag_search ต้องการ query เป็น string)

โมเดลเห็น schema ของ tool ทั้งหมดที่ agent มีให้ใช้ พร้อมกับคำถามของผู้ใช้ในทุกรอบสนทนา แล้วตัดสินใจเองว่าจะเรียก tool ไหน (ถ้ามี) จากคำอธิบายที่อ่านได้ — นี่คือเหตุผลที่คำอธิบายใน schema ต้องเขียนอย่างระมัดระวังมาก โมเดลอ่านผิดหรือ description กำกวม จะเรียก tool ผิดตัวได้จริง

วงจร ReAct: คิด → เรียก tool → ดูผล → คิดต่อ

รูปแบบที่ agent ส่วนใหญ่ในเว็บนี้ใช้เรียกว่า ReAct (Reason + Act) วนเป็นลูป:

  1. โมเดลคิดว่าต้องทำอะไรต่อจากคำถามและบริบทที่มี
  2. ถ้าต้องการข้อมูล/การกระทำที่ตัวเองทำเองไม่ได้ → เรียก tool (ส่ง tool name + arguments)
  3. โค้ดรัน tool จริง แล้วส่งผลลัพธ์กลับเข้า context เป็นข้อความใหม่
  4. โมเดลอ่านผลลัพธ์ แล้วตัดสินใจต่อ — เรียก tool ตัวอื่นอีก หรือสรุปคำตอบสุดท้ายให้ผู้ใช้

วนซ้ำได้หลายรอบในคำถามเดียว จนกว่าจะได้คำตอบสุดท้าย หรือชนเพดานจำนวนรอบที่ตั้งไว้ (กันไม่ให้วนไม่รู้จบ)

ทำไมต้อง “โค้ดคุมเข้ม” ไม่ใช่ปล่อยให้โมเดลตัดสินใจเอง 100%

จุดที่น่าสนใจของ 4 ผลิตภัณฑ์ในเว็บนี้คือ ไม่มีตัวไหนปล่อยให้โมเดลเรียก tool ได้อย่างอิสระเต็มที่ — มีชั้นโค้ดคอยตรวจสอบก่อน-ระหว่าง-หลังการเรียกทุกครั้งเสมอ ด้วยเหตุผลจริง 2 ข้อ:

  1. ความปลอดภัย — tool อย่าง bash เข้าถึงไฟล์/คำสั่งจริงในเครื่องได้ ถ้าปล่อยให้โมเดล (ที่บางทีก็ทายผิดหรือถูกหลอกจากข้อความในผลค้นเว็บ) ตัดสินใจเองล้วนๆ ความเสี่ยงสูงเกินไป จึงต้องมี allow-list, deny-list, และ sandbox ระดับ OS คอยกำกับ
  2. ความแม่นยำ — โมเดลขนาดเล็กมีโอกาสเรียก tool ผิด, ใส่ argument ผิดรูปแบบ, เรียกซ้ำไม่จบ หรือลืมแนบแหล่งอ้างอิง — โค้ดจึงมีชั้นตรวจสอบ (guardrail) คอยจับพฤติกรรมพวกนี้และแก้ไขแบบตรวจสอบได้ ไม่ปล่อยให้เป็นดวง

อ่านต่อ: เจาะลึกแต่ละ tool จริง

บทความถัดไปในชุดนี้จะพาไปดู tool จริงทีละตัวของแต่ละผลิตภัณฑ์ในเว็บนี้ — schema จริง, เงื่อนไขที่ agent ใช้ตัดสินใจว่าจะเรียกเมื่อไร, และกลไกป้องกันภายในของแต่ละตัว เริ่มจาก ENDEAVOR AGENT LITE ซึ่งมี 6 tools

อ่านเพิ่มเติม

ความคิดเห็น

กำลังโหลดความคิดเห็น...