กำไร:
- การกำหนดเอเจนต์เป็น 'โมเดล + เครื่องมือ + ลูป' และตัดสินใจว่าเมื่อใดที่จำเป็น
- การเขียนคำจำกัดความของเครื่องมือด้วยชื่อ คำอธิบาย และ input_schema
- การตรวจสอบโฟลว์และการจัดการข้อผิดพลาดของลูป tool_use และ tool_result
จนถึงขณะนี้ โมเดลมีงานเดียวมาโดยตลอด: รับการป้อนข้อความ สร้างการตอบกลับด้วยข้อความ แต่งานจริงมักต้องการมากกว่าข้อความ ทำการคำนวณ, ค้นหาฐานข้อมูล, เรียกใช้ API, ค้นหาอัตราแลกเปลี่ยนปัจจุบัน นางแบบไม่สามารถทำสิ่งเหล่านี้ได้ด้วยตัวเอง แต่เธอสามารถตัดสินใจได้เมื่อจำเป็นต้องทำและขอให้ใครสักคนทำ นี่คือสิ่งที่เครื่องมือมอบให้กับโมเดล และนี่คือพื้นฐานของตัวแทน AI ในหน่วยนี้ เราจะเรียนรู้ว่าเอเจนต์คืออะไร กำหนดเครื่องมืออย่างไร และลูป tool_use ทำงานอย่างไร
ตัวแทนคืออะไร? โมเดล + เครื่องมือ + ลูป
AI Agent ประกอบด้วยสามส่วน: โมเดล (สมองที่ทำการตัดสินใจ), เครื่องมือ (ฟังก์ชันที่โมเดลสามารถเรียกใช้ได้: สภาพอากาศ, การสืบค้นฐานข้อมูล, ส่งอีเมล) และลูป (ลูป โมเดลเรียกใช้เครื่องมือ รับผลลัพธ์ ตัดสินใจอีกครั้งว่าต้องทำอะไร และอื่นๆ)
ความแตกต่างที่สำคัญ: การเรียกรูปแบบเดียวไม่ใช่ตัวแทน เจ้าหน้าที่เป็นกระบวนการที่โมเดลดำเนินการทีละขั้นตอน โดยในแต่ละขั้นตอนจะเลือกการเคลื่อนไหวถัดไปตามผลลัพธ์ของเครื่องมือ “คิดอย่างมนุษย์ ใช้มือ มองผลลัพธ์ คิดใหม่”
ข้อเท็จจริงที่สำคัญ: ตัวโมเดลเองไม่ได้ใช้งานยานพาหนะ โมเดลเพียงพูดว่า "ฉันต้องการเรียกเครื่องมือนี้ด้วยอินพุตเหล่านี้" แอปพลิเคชันของคุณ (เรียกว่าสายรัด) เรียกใช้เครื่องมือและส่งคืนผลลัพธ์ให้กับโมเดล นี่เป็นสิ่งสำคัญสำหรับการรักษาความปลอดภัย: โมเดลไม่ได้สัมผัสระบบของคุณโดยตรง ทุกการกระทำอยู่ภายใต้การควบคุมของคุณ
เคล็ดลับ: อย่าพยายามแก้ไขปัญหาทุกอย่างกับตัวแทน ตัวแทน; เพิ่มความเสี่ยงของความล่าช้า ต้นทุน และข้อผิดพลาด ถามก่อน: “จะแก้ไขได้ด้วยการโทรเพียงครั้งเดียวหรือเวิร์กโฟลว์ที่ตายตัว?” ถ้าคำตอบคือใช่ก็ไม่จำเป็นต้องมีตัวแทน Agent มีไว้สำหรับงานปลายเปิดที่ไม่สามารถทราบขั้นตอนล่วงหน้าได้
คำจำกัดความของเครื่องมือ: ชื่อ คำอธิบาย input_schema
หากต้องการแนะนำเครื่องมือให้กับโมเดล คุณต้องให้สามสิ่งต่อไปนี้:
- ชื่อ: ตัวตนของยานพาหนะ เช่น get_weather
- คำอธิบาย: เครื่องมือนี้ทำหน้าที่อะไรและเมื่อใดที่ควรเรียกใช้ นี่เป็นส่วนที่สำคัญที่สุดที่ช่วยให้โมเดลสามารถเลือกเครื่องมือที่เหมาะสมในเวลาที่เหมาะสมได้ เขียนไม่ใช่แค่ "ทำอะไร" แต่ยังเขียนว่า "โทรเมื่อใด" ด้วย
- input_schema (สคีมาอินพุต): สคีมา JSON ที่กำหนดพารามิเตอร์ที่เครื่องมือคาดหวัง เป็นประเภทใด
# คำจำกัดความของยานพาหนะ (แนวความคิด — สคีมา JSON){ "name": "get_order_status", "description": "ดึงข้อมูลสถานะการจัดส่งปัจจุบันของคำสั่งซื้อ โทรเมื่อผู้ใช้ถามว่าหมายเลขคำสั่งซื้ออยู่ที่ไหนหรือจะมาถึงเมื่อใด", "input_schema": { "type": "object", "properties": { "order_no": {"type": "string", "description": "หมายเลขคำสั่งซื้อ เช่น SP-1024"} }, "จำเป็น": ["order_no"] }}
กฎสำหรับคำอธิบายเครื่องมือที่ดี: ชื่อที่ชัดเจนและกระชับ คำอธิบายว่า "ควรใช้เมื่อใด" คำอธิบายสำหรับแต่ละพารามิเตอร์ การใส่พารามิเตอร์ที่จำเป็นอย่างแท้จริงลงไป รักษาจำนวนยานพาหนะให้มุ่งเน้น รถยนต์หลายสิบรุ่นที่คล้ายกันนั้นน่าประหลาดใจ
พื้นที่
มันทำอะไร?
ตัวอย่างที่ดี
ตัวอย่างที่ไม่ดี
ชื่อ
รหัสยานพาหนะ
order_status_getir
นำ
คำอธิบาย
มันทำอะไร + เวลาที่จะโทร
“คืนสถานะสินค้า โทรเมื่อผู้ใช้ถามว่าออเดอร์อยู่ที่ไหน”
"ดึงข้อมูล"
input_schema
ประเภทพารามิเตอร์และข้อกำหนด
{order_no: สตริง มีคำอธิบายประกอบ}
ไม่มีแผนภาพ / ไม่มีคำอธิบาย
tool_use → tool_result วนซ้ำ
วงจรทำงานดังนี้:
- คุณส่งคำถามผู้ใช้ + คำอธิบายเครื่องมือไปยังโมเดล
- โมเดลตอบสนองโดยตรงหรือสร้างบล็อก tool_use: "call order_durumu_getir with order_no=SP-1024"
- แอปพลิเคชันของคุณรันเครื่องมือจริง (สอบถามฐานข้อมูล)
- คุณส่งผลกลับไปยังโมเดลเป็น tool_result
- ด้วยผลลัพธ์นี้ แบบจำลองจะสร้างคำตอบสุดท้ายหรือเรียกเครื่องมืออื่น วงจรจะดำเนินต่อไปจนกว่าโมเดลจะพูดว่า "เสร็จแล้ว"
# Agent loop (conceptual)messages = [user_question] While True: response = model.uret(messages, tools=tool_definitions) if response.tur == "tool_use": result = harness.run(response.tool_name, response.entries) # APPLICATION รันข้อความ += [response, tool_result(result)] # return result else: break # การตอบสนองขั้นสุดท้าย; วนซ้ำสิ้นสุด
SDK สมัยใหม่นำเสนอ tool runners ที่เรียกใช้ลูปนี้ให้กับคุณ คุณเพียงแค่เขียนฟังก์ชันเครื่องมือ แต่นั่นคือสิ่งที่เกิดขึ้นเบื้องหลัง
การจัดการข้อผิดพลาด
เครื่องมืออาจล้มเหลว: ไม่พบคำสั่งซื้อ, API หมดเวลา, อินพุตไม่ถูกต้อง หากคุณไม่สามารถเรียกใช้เครื่องมือได้ ให้ส่งคืนข้อผิดพลาดไปยังโมเดลเป็น tool_result ที่สื่อความหมาย ("ข้อผิดพลาด: ไม่พบหมายเลขคำสั่งซื้อ SP-9999") และแฟล็กข้อผิดพลาด โมเดลสามารถเห็นสิ่งนี้และค่อยๆ อธิบายให้ผู้ใช้ทราบ หรือลองใช้วิธีอื่น อย่ากลืนข้อผิดพลาดและส่งคืนผลลัพธ์ที่ว่างเปล่า โมเดลต้องรู้ว่ามีอะไรผิดพลาด
คำอธิบายยานพาหนะที่อ่อนแอ/แข็งแกร่ง
อ่อนแอ (นามไม่ชี้ชัด ไม่มี "เมื่อ"):
ชื่อ: "data" คำอธิบาย: "ดึงข้อมูล"# โมเดลไม่รู้ว่าจะโทรเมื่อใดและอย่างไร มันไม่โทรเลยหรือโทรผิด
Strong (ชื่อเน็ต + เมื่อ + คำอธิบายพารามิเตอร์):
name: "musteri_bakiyesi_getir"description: "ส่งคืนยอดคงเหลือในบัญชีปัจจุบันของลูกค้า โทรเมื่อผู้ใช้ขอเดบิต เครดิต หรือยอดคงเหลือ ไม่ชำระเงิน"input_schema: {custeri_id: string ("รหัสลูกค้า")}# โมเดลเรียกใช้ในเวลาที่เหมาะสม พร้อมพารามิเตอร์ที่ถูกต้อง โดยทราบขีดจำกัด
มินิเคสสามอัน
กรณีที่ 1 — ตัวแทนที่ไม่จำเป็น ทีมหนึ่งสร้างธุรกิจ "ข้อความสรุป" ด้วยตัวแทนเครื่องมือที่หลากหลาย การสรุปแต่ละครั้งใช้เวลาเรียกโมเดล 4 ครั้งและ 9 วินาที งานนี้เป็นงานสายเดียวจริงๆ เมื่อเราลบตัวแทนและลดเหลือการโทรครั้งเดียว เวลาลดลงเหลือ 1.5 วินาทีและค่าใช้จ่ายลดลงเหลือหนึ่งในสี่ บทเรียน: ใช้ตัวแทนเมื่อจำเป็นจริงๆ
กรณีที่ 2 — อธิบายไม่ดี โทรผิด ในตัวแทนฝ่ายสนับสนุน เครื่องมือที่ไม่ชัดเจนที่เรียกว่าการดึงข้อมูลจะถูกสุ่มเรียกโดยแบบจำลองทั้งในคำถามเกี่ยวกับยอดคงเหลือและคำถามในการจัดส่ง เมื่อยานพาหนะถูกแบ่งออกเป็น balance_getir และ cargo_durumu_getir และเพิ่มคำอธิบาย "โทรเมื่อ" การเลือกยานพาหนะที่ไม่ถูกต้องลดลงจาก 18 เป็น 1 ใน 50 ตัวอย่าง
กรณีที่ 3 — เกิดข้อผิดพลาดในการกลืน ตัวแทนส่งคืนผลลัพธ์ที่ว่างเปล่าเมื่อไม่พบคำสั่งซื้อ โมเดลตีความสิ่งนี้ว่า "จัดส่งคำสั่งซื้อแล้ว" และทำให้ลูกค้าเข้าใจผิด เมื่อมีการเขียนข้อความแสดงข้อผิดพลาดอย่างชัดเจนไปที่ tool_result ("ไม่พบคำสั่งซื้อ") โมเดลจะแจ้งอย่างถูกต้องว่า "ฉันไม่พบหมายเลขนี้ คุณตรวจสอบได้ไหม" เขาเริ่มพูด
ข้อผิดพลาดทั่วไป
- เปลี่ยนทุกอย่างให้เป็นตัวแทน: แม้ว่าการโทรเพียงครั้งเดียวจะเพียงพอ แต่ตัวแทนก็เพิ่มค่าใช้จ่ายและความล่าช้า
- คำอธิบายรถคลุมเครือ: รุ่นไม่ทราบว่าจะโทรติดต่อเมื่อใด เลือกผิด
- คิดว่าโมเดลขับเคลื่อนยานพาหนะ: สายรัดควบคุมยานพาหนะ นางแบบก็แค่ต้องการ
- การกลืนข้อผิดพลาด: แบบจำลองต้องรู้ว่ามีอะไรผิดพลาด ให้ข้อผิดพลาดเป็น open tool_result
- ยานพาหนะที่คล้ายกันมากเกินไป: โมเดลสับสน; รักษาชุดเครื่องมือให้เน้นและน้อยที่สุด
ข้อควรพิจารณา: เพียงเพราะโมเดลแจ้งว่า "เรียกรถคันนั้น" ไม่ได้หมายความว่าควรดำเนินการใดๆ สำหรับเครื่องมือทำลายล้าง (ลบ, ชำระเงิน, อีเมล) แอปพลิเคชันของคุณไม่ควรดำเนินการเรียกโดยสุ่มสี่สุ่มห้า — นี่คือแกนหลักของหัวข้อความปลอดภัยในหน่วยถัดไป
โดยสรุป
- Agent = โมเดล (การตัดสินใจ) + เครื่องมือ (ฟังก์ชัน) + ลูป (เครื่องมือเรียก รับผลลัพธ์ ตัดสินใจอีกครั้ง)
- การเรียกรูปแบบเดียวไม่ใช่ตัวแทน ตัวแทนเป็นกระบวนการทีละขั้นตอน
- โมเดลไม่ได้ขับเคลื่อนยานพาหนะ แอปพลิเคชันของคุณทำงาน (ควบคุม) และส่งคืนผลลัพธ์เป็น tool_result
- เครื่องมือจะถูกระบุด้วยชื่อ คำอธิบาย (โดยเฉพาะ "โทรเมื่อ") และ input_schema
- การวนซ้ำจะดำเนินต่อไปเมื่อ tool_use → harness run → tool_result → model ดำเนินต่อไปจนกระทั่งโมเดลแจ้งว่า "เสร็จสิ้น"; ข้อผิดพลาดจะถูกรายงานไปยังโมเดลอย่างชัดเจน
งานสมัคร
ออกแบบ 3 เครื่องมือจากธุรกิจของคุณเองที่สามารถมอบให้กับตัวแทนได้ (1) เขียนชื่อ คำอธิบายด้วย "call when" และ input_schema สำหรับแต่ละรายการ ให้อย่างน้อยหนึ่งอันเป็นเครื่องมืออ่านแบบไม่ทำลายและอีกหนึ่งอันสำหรับการคำนวณ (2) เลือกคำถามของผู้ใช้ที่สมจริงและเขียนทีละขั้นตอนด้วยตนเอง (แบบวนซ้ำ) ว่าเครื่องมือใดที่โมเดลจะเรียกใช้ด้วยอินพุตใด และจะทำอะไรหลังจาก tool_result มาถึง (3) ตั้งค่าสถานการณ์ที่เครื่องมือตัวใดตัวหนึ่งล้มเหลว และแสดงให้เห็นว่าข้อความแสดงข้อผิดพลาดจะกลับสู่แบบจำลองอย่างไร
รายการตรวจสอบ
- [ ] ฉันสามารถกำหนดเอเจนต์เป็น "model + tools + loop" และตัดสินใจว่าเมื่อใดที่จำเป็น
- [ ] ฉันรู้ว่าสายรัดควบคุมยานพาหนะ นางแบบแค่ต้องการมัน
- ฉันสามารถเขียนคำอธิบายยานพาหนะที่ชัดเจนด้วยชื่อ [ ] คำอธิบาย ("โทรเมื่อ") และ input_schema
- ฉันสามารถทำตามขั้นตอน [ ] tool_use → tool_result ทีละขั้นตอน
- [ ] ฉันรายงานข้อผิดพลาดของเครื่องมือไปยังโมเดลเป็น open tool_result