คำอธิบายเครื่องมือเป็นตัวขับเคลื่อนการเลือก
โมเดลเลือกเครื่องมือจากคำอธิบาย ไม่ใช่ชื่อ
คำอธิบายเครื่องมือเป็นตัวขับเคลื่อนการเลือก เป็นบทเรียน Claude Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Claude Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน
โมเดลอ่าน ไม่ได้เดา
เมื่อ Claude ตัดสินใจว่าจะเรียกใช้เครื่องมือใด มัน ไม่ได้เลือกจากชื่อของเครื่องมือ แต่มันอ่าน คำอธิบายของเครื่องมือแต่ละตัว แล้วใช้เหตุผลว่าเครื่องมือใดเหมาะกับงาน
นี่คือข้อเท็จจริงที่สำคัญที่สุดเพียงข้อเดียวในการออกแบบเครื่องมือ: คำอธิบายคือกลไกหลักในการเลือก เครื่องมือชื่อ process_refund ที่มีคำอธิบายคลุมเครือจะถูกเลือกได้ถูกต้องยากกว่าเครื่องมือที่มีคำอธิบายชัดเจนแต่ชื่อไม่สละสลวย
หากต้องการพฤติกรรมที่เชื่อถือได้ ให้ทุ่มความพยายามไปกับการเขียนคำอธิบาย ไม่ใช่การตั้งชื่ออย่างฉลาด
ชื่อไม่ใช่ข้อกำหนดจำเพาะ
ชื่อสั้นและกำกวม ลองพิจารณาเครื่องมือสองตัว: search_orders และ lookup_order จากชื่อเพียงอย่างเดียว ตัวใดใช้ค้นหารายการสั่งซื้อด้วย ID ตัวใดใช้กรองรายการตามวันที่ คุณบอกไม่ได้ และโมเดลก็บอกไม่ได้เช่นกัน
ความหมายที่แท้จริงอยู่ในคำอธิบาย:
- เครื่องมือนี้มีไว้ เพื่ออะไร (วัตถุประสงค์)
- เครื่องมือนี้ ส่งคืนอะไร
- ต้องการ ข้อมูลนำเข้าอะไร พร้อมตัวอย่าง
- กรณีขอบและขอบเขตการใช้งานของเครื่องมือ
ตั้งชื่อเครื่องมือให้เหมาะสม แต่อย่าพึ่งพาชื่อเพื่อแยกแยะพฤติกรรม
องค์ประกอบของคำอธิบายที่ดี
คำอธิบายเครื่องมือที่ดีต้องตอบทุกสิ่งที่โมเดลจำเป็นต้องรู้เพื่อเลือกและเรียกใช้เครื่องมือนั้นได้อย่างถูกต้อง ควรระบุ:
- วัตถุประสงค์ — งานเดียวที่เครื่องมือนี้ทำ
- ค่าที่ส่งคืน — ผลลัพธ์ที่ส่งกลับมาและอยู่ในรูปแบบใด
- รูปแบบอินพุตพร้อมตัวอย่าง — อาร์กิวเมนต์ตัวอย่างที่เป็นรูปธรรม
- กรณีขอบ — ผลลัพธ์ว่าง ไม่พบข้อมูล และความกำกวม
- ขอบเขตการใช้งาน — เมื่อใดที่ NOT ควรใช้เครื่องมือนี้
ข้อกำหนดเรื่องขอบเขตนี่เองที่ช่วยหยุดการส่งงานผิดระหว่างเครื่องมือที่คล้ายกัน
lookup_order = {
"name": "lookup_order",
"description": (
"Fetch a single order by its exact order_id. "
"Returns status, items, total, and ship date. "
"order_id format: 'ORD-' + 8 digits, e.g. 'ORD-10293847'. "
"Returns an empty result (not an error) if no order matches. "
"Use this ONLY when you already have a specific order_id; "
"to find orders by customer or date, use search_orders instead."
),
"input_schema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
}คำอธิบายคลุมเครือทำให้ส่งงานผิด
ความล้มเหลวที่พบบ่อยที่สุดคือ คำอธิบายที่สั้นเกินไปหรือกำกวม นี่เป็นรูปแบบคำตอบที่ผิดบ่อยในการสอบ และมักเป็นคำตอบที่ผิดเมื่อโจทย์ถามว่าเหตุใดจึงเลือกเครื่องมือผิด
ลองดูสิ่งที่เกิดขึ้นเมื่อคำอธิบายมีรายละเอียดน้อย:
get_data: "ดึงข้อมูล"fetch_info: "ดึงข้อมูลข่าวสาร"
เมื่อภารกิจคือ "ค้นหาคำสั่งซื้อล่าสุดของลูกค้า" โมเดลจะแยกเครื่องมือสองตัวนี้ไม่ออก อาจเรียกใช้ตัวที่ผิดหรือสลับไปมา คำอธิบายที่ทับซ้อนหรือกำกวมทำให้ส่งงานผิด — วิธีแก้คือใช้ถ้อยคำที่ชัดเจนและไม่ทับซ้อนกัน ไม่ใช่เปลี่ยนชื่อเครื่องมือ
กำหนดขอบเขตระหว่างเครื่องมือให้ชัดเจน
เมื่อมีเครื่องมือสองตัวที่อาจใช้ได้อย่างสมเหตุสมผล คำอธิบายของแต่ละตัวต้องชี้อย่างชัดเจนว่าไม่ใช่อีกตัวหนึ่ง วิธีนี้จะลบส่วนที่ทับซ้อนกันซึ่งทำให้การเลือกสับสน
สังเกตว่าคำอธิบายแต่ละรายการระบุเครื่องมือคู่กันและบอกว่าเมื่อใดควรส่งต่อให้อีกตัว ขอบเขตร่วมกันนี้ช่วยให้โมเดลเลือกใช้เครื่องมือที่ถูกต้อง
tools = [
{
"name": "search_orders",
"description": (
"List orders matching a customer_id and/or date range. "
"Returns an array of order summaries (id, status, total). "
"Use to DISCOVER orders when you do not know the order_id. "
"For full details of one known order, use lookup_order."
),
},
{
"name": "lookup_order",
"description": (
"Fetch full details of ONE order by exact order_id. "
"Use only when the order_id is already known. "
"To find orders, use search_orders first."
),
},
]บันทึกกรณีขอบไว้ในคำอธิบาย
ควรใส่กรณีขอบไว้ในคำอธิบาย เพราะกรณีเหล่านี้มีผลต่อการให้เหตุผลในขั้นตอนถัดไปของโมเดล ไม่ใช่แค่การเรียกใช้เท่านั้น
มีความแตกต่างที่สำคัญที่สุดสองประการ:
- การเข้าถึงล้มเหลว (ระบบไม่สามารถเข้าถึงได้ — อาจลองใหม่ได้) เทียบกับ ผลลัพธ์ว่างที่ถูกต้อง (ไม่พบรายการที่ตรงกัน — ห้ามลองใหม่ เพียงรายงานผล)
- สิ่งที่จะเกิดขึ้นเมื่อ อินพุตกำกวม — เช่น พบลูกค้าหลายรายที่ตรงกัน
หากคำอธิบายระบุว่า "ส่งคืนค่าว่างเมื่อไม่มีคำสั่งซื้อที่ตรงกัน" โมเดลจะไม่ถือว่า 'ไม่พบผลลัพธ์' เป็นข้อผิดพลาดที่ต้องลองใหม่ หากระบุว่า "ส่งคืนรายการที่ตรงกันหลายรายการเมื่อชื่อไม่ไม่ซ้ำกัน" โมเดลจะรู้ว่าต้องขอตัวระบุเพิ่มเติมแทนการเดา
ทำให้ชุดเครื่องมือมีขนาดเล็ก
แม้คำอธิบายจะสมบูรณ์แบบ แต่ประสิทธิภาพก็ลดลงได้เมื่อมีเครื่องมือมากเกินไป การเลือกเป็นงานใช้เหตุผล และตัวเลือกที่มากขึ้นจะทำให้การตัดสินใจเจือจางลง
- เครื่องมือ 4-5 รายการต่อตัวแทน เป็นช่วงที่เหมาะสมที่สุดสำหรับการเลือกที่เชื่อถือได้
- เมื่อมี เครื่องมือ 18 รายการขึ้นไป ความน่าเชื่อถือในการเลือกจะลดลงอย่างเห็นได้ชัด
ดังนั้นคำอธิบายที่ดีและชุดเครื่องมือขนาดเล็กจึงต้องทำงานร่วมกัน: กำหนดขอบเขตเครื่องมือของตัวแทนแต่ละตัวให้สอดคล้องกับบทบาท แล้วอธิบายเครื่องมือจำนวนน้อยเหล่านั้นอย่างแม่นยำ ชุดเครื่องมือที่ใหญ่เกินไปไม่อาจแก้ได้ด้วยถ้อยคำเพียงอย่างเดียว
กำหนดขอบเขตเครื่องมือให้เหมาะกับบทบาท
คุณภาพของคำอธิบายและหลักสิทธิ์เท่าที่จำเป็นต่างชี้ไปในทิศทางเดียวกัน ตัวแทนย่อยด้านการวิจัยไม่ควรมีเครื่องมือคืนเงิน และผู้ตรวจสอบแบบอ่านอย่างเดียวไม่ควรมี Write หรือ Bash
การกำหนดขอบเขตตามบทบาททำสองสิ่งได้พร้อมกัน:
- ลบตัวเลือกที่ทับซ้อนกัน ทำให้แยกแยะคำอธิบายที่เหลือได้ง่ายขึ้น
- รักษาจำนวนเครื่องมือของตัวแทนแต่ละตัวให้อยู่ใกล้ช่วงที่เหมาะสม 4-5 รายการ
เครื่องมือที่น้อยลงและเกี่ยวข้องกับบทบาทหมายถึงคำอธิบายที่กระชับและไม่ทับซ้อนกัน — และนั่นคือสิ่งที่ทำให้เลือกได้อย่างแม่นยำ
support_agent = AgentDefinition(
name="support",
description="Resolves customer order and refund requests.",
system_prompt="Verify identity, then resolve the request.",
allowed_tools=[
"get_customer",
"lookup_order",
"process_refund",
"escalate_to_human",
], # 4 role-scoped tools, each clearly described
)คำอธิบายใช้เลือก ส่วน tool_choice ใช้จำกัด
คำอธิบายเป็นตัวตัดสินว่าเครื่องมือ ใดเหมาะสม ส่วนพารามิเตอร์ tool_choice เป็นกลไกอีกอย่างที่ใช้จำกัดว่าเครื่องมือจะถูกเรียกใช้ หรือไม่และอย่างไร:
"auto"— โมเดลเลือกข้อความหรือเครื่องมือ (การเลือกยังคงขับเคลื่อนด้วยคำอธิบาย)"any"— โมเดลต้องเรียกใช้เครื่องมือ SOME ตัว เหมาะสำหรับรับประกันผลลัพธ์ที่มีโครงสร้าง{"type":"tool","name":"X"}— บังคับใช้เครื่องมือใดเครื่องมือหนึ่งโดยเฉพาะ
การบังคับใช้เครื่องมือไม่ได้แก้คำอธิบายที่ไม่ดี — เพียงลบตัวเลือกออกไป เมื่อใช้ "auto" หรือ "any" โมเดลยังคงอ่านคำอธิบายเพื่อเลือกจากตัวเลือกต่าง ๆ ดังนั้นถ้อยคำจึงยังต้องชัดเจน
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
tools=tools,
tool_choice={"type": "auto"}, # model selects by reading descriptions
messages=messages,
)จุดสิ้นสุดของเครื่องมือและจุดเริ่มต้นของทรัพยากร
ใน MCP ไม่ใช่ทุกอย่างควรเป็นเครื่องมือ เซิร์ฟเวอร์เปิดเผยองค์ประกอบพื้นฐานสามประเภท และการเลือกประเภทที่เหมาะสมจะช่วยให้คำอธิบายเครื่องมือมีจุดเน้น:
- เครื่องมือ — การกระทำที่ DO บางอย่าง (ดำเนินการคืนเงิน เรียกใช้คำค้น)
- ทรัพยากร — ข้อมูลและบริบทแบบอ่านอย่างเดียว เช่น สคีมาหรือแค็ตตาล็อก
- พรอมต์ — เทมเพลตที่นำกลับมาใช้ซ้ำได้
การจำลองสคีมาหรือแค็ตตาล็อกแบบอ่านอย่างเดียวเป็น ทรัพยากร แทนที่จะเป็นเครื่องมือ จะนำสิ่งนั้นออกจากกลุ่มตัวเลือกการกระทำโดยสิ้นเชิง เท่ากับลดตัวเลือกที่กำกวมซึ่งแข่งขันกันในคำอธิบายลงหนึ่งรายการ และช่วยให้เลือกเครื่องมือได้โดยตรง
ทำให้ข้อผิดพลาดเลือกเส้นทางได้ด้วย
การเลือกไม่ได้จบลงหลังการเรียกครั้งแรก — บ่อยครั้งโมเดลต้องเลือกเครื่องมือ กู้คืนในขั้นถัดไป การเลือกนั้นขึ้นอยู่กับข้อผิดพลาดที่ได้รับกลับมา
ข้อผิดพลาดทั่วไปอย่าง "การดำเนินการล้มเหลว" ไม่ให้ข้อมูลใดแก่โมเดลสำหรับเลือกเส้นทาง แต่ ข้อผิดพลาด MCP ที่มีโครงสร้างให้ข้อมูลดังกล่าว:
isError: trueและerrorCategory(ชั่วคราว / การตรวจสอบความถูกต้อง / ธุรกิจ / สิทธิ์)isRetryable,message,attempted_queryและpartial_resultsหากมี
ด้วยข้อมูลนี้ โมเดลจะตัดสินใจได้อย่างชาญฉลาดว่าจะลองใหม่เมื่อเกิดข้อขัดข้องชั่วคราว แก้ปัญหาการตรวจสอบความถูกต้อง หรือส่งต่อปัญหาด้านธุรกิจหรือสิทธิ์ แทนที่จะหยุดค้าง
{
"isError": true,
"errorCategory": "transient",
"isRetryable": true,
"message": "Order service timed out",
"attempted_query": "lookup_order(order_id='ORD-10293847')",
"partial_results": null
}ตรวจสอบอย่างรวดเร็ว
นำปัจจัยที่ขับเคลื่อนการเลือกเครื่องมือไปใช้กับข้อบกพร่องจากการส่งงานผิดที่เกิดขึ้นจริง
สรุป
ประเด็นสำคัญเกี่ยวกับการเลือกเครื่องมือ:
- Claude เลือกเครื่องมือโดยอ่าน คำอธิบาย ไม่ใช่ชื่อ
- คำอธิบายที่ดีต้องระบุ วัตถุประสงค์ ค่าที่ส่งคืน รูปแบบอินพุตพร้อมตัวอย่าง กรณีขอบ และขอบเขตการใช้งาน
- คำอธิบายที่ทับซ้อนหรือกำกวมทำให้ส่งงานผิด ควรกำหนดขอบเขตอย่างชัดเจนเพื่อชี้ให้แต่ละเครื่องมือต่างจากเครื่องมือคู่กัน
- บันทึกกรณีขอบไว้ในคำอธิบาย โดยเฉพาะ ผลลัพธ์ว่างเทียบกับการเข้าถึงล้มเหลว และกรณีที่ตรงกันหลายรายการอย่างกำกวม
- จำกัดไว้ที่ เครื่องมือ 4-5 รายการต่อตัวแทน ความสามารถในการเลือกจะลดลงเมื่อมี 18 รายการขึ้นไป กำหนดขอบเขตเครื่องมือให้เหมาะกับบทบาท
tool_choice(อัตโนมัติ / ใดก็ได้ / บังคับ) จำกัดการเรียกใช้ แต่ไม่สามารถแทนที่คำอธิบายที่ชัดเจน- จำลองข้อมูลแบบอ่านอย่างเดียวเป็น ทรัพยากร ของ MCP และส่งคืน ข้อผิดพลาดที่มีโครงสร้าง เพื่อให้โมเดลเลือกเส้นทางการกู้คืนได้
เรียนรู้ Python ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 26
- บทเรียน
- 104
คำถามที่พบบ่อย
บทเรียน “คำอธิบายเครื่องมือเป็นตัวขับเคลื่อนการเลือก” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “คำอธิบายเครื่องมือเป็นตัวขับเคลื่อนการเลือก” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Claude Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “คำอธิบายเครื่องมือเป็นตัวขับเคลื่อนการเลือก”
โมเดลเลือกเครื่องมือจากคำอธิบาย ไม่ใช่ชื่อ คุณปฏิบัติ Claude Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Claude Architect หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Claude Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “คำอธิบายเครื่องมือเป็นตัวขับเคลื่อนการเลือก” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Claude Architect นี้ได้ไหม
ได้ บทเรียน Claude Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- คำอธิบายเครื่องมือเป็นตัวขับเคลื่อนการเลือก
- โครงสร้างของคำอธิบายที่ดี
- หลีกเลี่ยงเครื่องมือที่ทับซ้อนกัน
- รูปแบบและตัวอย่าง input