ควรมีเครื่องมือกี่รายการต่อเอเจนต์
4-5 รายการเหมาะสมที่สุด ส่วน 18 รายการขึ้นไปทำให้ความน่าเชื่อถือในการเลือกลดลง
ควรมีเครื่องมือกี่รายการต่อเอเจนต์ เป็นบทเรียน Claude Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Claude Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน
ปัญหาการเลือก
เมื่อคุณมอบชุด tools ให้เอเจนต์ โมเดลต้องทำสิ่งที่ละเอียดอ่อนในทุกครั้งที่โต้ตอบ นั่นคืออ่านคำอธิบายเครื่องมือทั้งหมด แล้วเลือกเครื่องมือที่เหมาะสมกับขั้นตอนปัจจุบัน
นี่คือภารกิจด้านการเลือก ยิ่งคุณเพิ่มตัวเลือกมากเท่าไร การตัดสินใจก็ยิ่งยากขึ้นเท่านั้น ชุดเครื่องมือที่เน้นเฉพาะด้านช่วยให้การเลือกแม่นยำ ส่วนชุดเครื่องมือที่มากเกินไปทำให้โมเดลลังเล เลือกเส้นทางผิด หรือหยิบเครื่องมือผิด
บทเรียนนี้จะตอบคำถามที่ฟังดูเรียบง่ายแต่ชวนให้เข้าใจผิดว่า เอเจนต์หนึ่งตัวควรมีเครื่องมือกี่รายการ
หลักการคร่าว ๆ
จำนวนที่เหมาะสมในทางปฏิบัติคือ เครื่องมือ 4–5 รายการต่อเอเจนต์หนึ่งตัว เมื่อมีจำนวนเท่านี้ โมเดลจะให้เหตุผลได้อย่างน่าเชื่อถือว่าเครื่องมือใดเหมาะกับแต่ละขั้นตอน
เมื่อจำนวนเพิ่มขึ้น ความน่าเชื่อถือในการเลือกจะลดลง เมื่อมีเครื่องมือประมาณ 18 รายการขึ้นไปในเอเจนต์เดียว โมเดลจะเริ่มสับสนระหว่างตัวเลือกที่คล้ายกันและเลือกได้ไม่ดี เครื่องมือที่มากขึ้นไม่ได้หมายถึงความสามารถที่มากขึ้นเสมอไป — เมื่อเกินจุดหนึ่ง ความสามารถจะน่าเชื่อถือน้อยลง
- เครื่องมือ 4–5 รายการ → การเลือกเหมาะสมที่สุด
- เครื่องมือ 18 รายการขึ้นไป → ความน่าเชื่อถือในการเลือกลดลง
เอเจนต์ที่มีขอบเขตชัดเจน
นี่คือตัวอย่างเอเจนต์ฝ่ายสนับสนุนที่มีชุดเครื่องมือขนาดพอดีและกำหนดขอบเขตตามบทบาท มีเครื่องมือสี่รายการ โดยแต่ละรายการมีหน้าที่ชัดเจน ได้แก่ ยืนยันตัวตนลูกค้า ตรวจสอบคำสั่งซื้อ ดำเนินการคืนเงิน และส่งต่อให้เจ้าหน้าที่มนุษย์
โมเดลไม่ต้องสงสัยว่าจะเรียกเครื่องมือเกือบเหมือนกันยี่สิบรายการใด แต่ละรายการสอดคล้องกับเจตนาที่แตกต่างกันอย่างชัดเจน
tools = [
{"name": "get_customer", "description": "...", "input_schema": {...}},
{"name": "lookup_order", "description": "...", "input_schema": {...}},
{"name": "process_refund", "description": "...", "input_schema": {...}},
{"name": "escalate_to_human", "description": "...", "input_schema": {...}},
]
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system="You are a support agent. Verify identity before any refund.",
tools=tools,
messages=messages,
)คำอธิบายเป็นตัวช่วยเลือก
มีประเด็นสำคัญประการหนึ่งคือ โมเดลเลือกเครื่องมือโดยอาศัยคำอธิบายเป็นหลัก ไม่ใช่ชื่อเครื่องมือ คำอธิบายที่ดีควรระบุวัตถุประสงค์ของเครื่องมือ ค่าที่ส่งกลับ รูปแบบข้อมูลนำเข้าพร้อมตัวอย่าง กรณีขอบ และขอบเขตการใช้งาน
นี่คือเหตุผลที่จำนวนและคุณภาพของเครื่องมือส่งผลต่อกัน แม้มีเครื่องมือเพียง 5 รายการ ก็อาจเลือกเส้นทางผิดได้หากคำอธิบายทับซ้อนกันหรือกำกวม ยิ่งคุณเพิ่มเครื่องมือมากขึ้น โอกาสที่คำอธิบายของสองเครื่องมือจะฟังดูคล้ายกันก็ยิ่งสูงขึ้น และข้อผิดพลาดในการเลือกก็จะยิ่งมากขึ้น
{
"name": "lookup_order",
"description": "Retrieve a single order by its order ID. "
"Input: order_id (string, e.g. 'ORD-10482'). "
"Returns: items, status, total, and ship date. "
"Use AFTER get_customer confirms identity. "
"Does NOT search by email — use lookup_order, not find_orders.",
"input_schema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
}เมื่อมีเครื่องมือมากเกินไปจะเป็นอย่างไร
ลองนึกภาพว่าคุณยัดทั้งแผนกไว้ในเอเจนต์เดียว ทั้งเครื่องมือด้านลูกค้า คำสั่งซื้อ การเรียกเก็บเงิน สินค้าคงคลัง การจัดส่ง การวิเคราะห์ และอื่น ๆ รวมรายการมากกว่ายี่สิบรายการไว้ในอาร์เรย์ tools เดียว
จากนั้นเครื่องมือหลายรายการก็ฟังดูคล้ายกัน เช่น lookup_order, find_orders, get_order_history, search_purchases โมเดลต้องแยกแยะความแตกต่างในทุกครั้งที่โต้ตอบ ทำให้ความแม่นยำลดลง การมีเครื่องมือมากเกินไปต่อเอเจนต์หนึ่งตัวเป็นรูปแบบการออกแบบที่ควรหลีกเลี่ยง เช่นเดียวกับคำอธิบายที่กำกวม
กำหนดขอบเขตเครื่องมือตามบทบาท
วิธีแก้ไม่ใช่การทำให้คำอธิบายยาวขึ้นเรื่อย ๆ แต่คือการกำหนดขอบเขตเครื่องมือตามบทบาท ให้ถามว่า เอเจนต์ THIS มีหน้าที่อะไร และต้องใช้เครื่องมือจำนวนน้อยที่สุดเท่าใดจึงจะทำหน้าที่นั้นได้
เอเจนต์คืนเงินต้องใช้เครื่องมือด้านการยืนยันตัวตน คำสั่งซื้อ การคืนเงิน และการส่งต่อ แต่ไม่จำเป็นต้องใช้การพยากรณ์สินค้าคงคลังหรือการวิเคราะห์การตลาด การตัดเครื่องมือที่ไม่เกี่ยวข้องออกจะลดสิ่งรบกวนและทำให้การเลือกเครื่องมือที่เหลือแม่นยำขึ้น
แยกงานด้วยสถาปัตยกรรมหลายเอเจนต์
เมื่อภารกิจจำเป็นต้องใช้ความสามารถหลายด้านจริง ๆ อย่านำทั้งหมดไปรวมไว้ในเอเจนต์เดียว ให้ใช้การออกแบบหลายเอเจนต์แบบศูนย์กลางและแขนง โดยผู้ประสานงานจะแยกย่อยงานและมอบหมายให้เอเจนต์ย่อยเฉพาะด้าน ซึ่งแต่ละตัวมีชุดเครื่องมือที่จำกัดเฉพาะงาน
การกระจายเครื่องมือยี่สิบรายการไปยังเอเจนต์ย่อยสี่ตัว ตัวละ 5 รายการ ทำให้เลือกได้อย่างน่าเชื่อถือกว่าการใส่เครื่องมือยี่สิบรายการไว้ในเอเจนต์เดียวมาก โปรดจำไว้ว่าเอเจนต์ย่อยจะไม่สืบทอดประวัติของผู้ประสานงาน ดังนั้นคำสั่งของเอเจนต์ย่อยแต่ละตัวต้องมีบริบทของตนเองอย่างชัดเจน
research_agent = AgentDefinition(
name="research_agent",
description="Searches sources and extracts findings.",
system_prompt="You gather and cite evidence for a sub-question.",
allowed_tools=["web_search", "fetch_page", "extract_quote"],
)
verify_agent = AgentDefinition(
name="verify_agent",
description="Cross-checks claims against sources.",
system_prompt="You validate claims and flag conflicts.",
allowed_tools=["fetch_page", "compare_sources", "flag_conflict"],
)สิทธิ์เท่าที่จำเป็นสำหรับเอเจนต์ย่อย
การแบ่งเครื่องมือให้เอเจนต์ย่อยมีข้อดีเพิ่มเติมคือการให้สิทธิ์เท่าที่จำเป็น แต่ละ AgentDefinition จะประกาศเฉพาะ allowed_tools ที่จำเป็นต้องใช้จริง
เอเจนต์ย่อยด้านการวิจัยที่อ่านข้อมูลได้อย่างเดียวจะไม่เคยได้รับเครื่องมือ process_refund หรือ delete จึงไม่สามารถเรียกใช้ผิดพลาดได้ ชุดเครื่องมือที่เล็กและกำหนดขอบเขตตามบทบาทมีทั้งความน่าเชื่อถือมากกว่า (เลือกได้ดีขึ้น) และความปลอดภัยมากกว่า (ขอบเขตความเสียหายแคบลง) กฎหนึ่งข้อที่ผู้ประสานงานต้องจำไว้คือ allowedTools ของผู้ประสานงานต้องมี "Task" เพื่อให้สามารถมอบหมายงานได้
เครื่องมือกับทรัพยากรใน MCP
ทุกสิ่งที่เอเจนต์ต้องการไม่จำเป็นต้องเป็นเครื่องมือ ใน MCP องค์ประกอบพื้นฐานของเซิร์ฟเวอร์แบ่งเป็นสามประเภท
- เครื่องมือ — การกระทำที่โมเดลเรียกใช้
- ทรัพยากร — ข้อมูลหรือบริบทแบบอ่านอย่างเดียว เช่น โครงร่างหรือแค็ตตาล็อก
- พรอมต์ — แม่แบบที่นำกลับมาใช้ซ้ำได้
หากโมเดลเพียงต้องการอ่านโครงร่างหรือแค็ตตาล็อกผลิตภัณฑ์ ให้เปิดเผยสิ่งนั้นเป็นทรัพยากร ไม่ใช่เครื่องมือ วิธีนี้จะทำให้อาร์เรย์ tools มีขนาดกะทัดรัดและสงวนไว้สำหรับการกระทำจริง ซึ่งเป็นอีกวิธีหนึ่งที่ช่วยให้มีเครื่องมือที่ใช้ดำเนินการอยู่ใกล้เคียง 4–5 รายการ
เครื่องมือในตัวมีขอบเขตอยู่แล้ว
ชุดเครื่องมือในตัวของ Claude Code เป็นตัวอย่างที่ดีของการกำหนดขอบเขตอย่างมีวินัย เครื่องมือแต่ละรายการมีหน้าที่ชัดเจนเพียงหนึ่งเดียว
Glob— ค้นหาไฟล์ตามรูปแบบ (เช่น**/*.test.tsx)Grep— ค้นหาเนื้อหาภายในไฟล์Read/Write/Edit— โหลด สร้าง และเปลี่ยนแปลงไฟล์อย่างแม่นยำBash— เรียกใช้คำสั่งเชลล์
ไม่มีเครื่องมือใดทับซ้อนกัน โมเดลนำเครื่องมือเหล่านี้มาประกอบกันเป็นลำดับการทำงานแบบค่อยเป็นค่อยไป ได้แก่ Grep จุดเริ่มต้น, Read ไฟล์, Grep ตำแหน่งที่ใช้งาน และ Read ส่วนที่เรียกใช้ แทนที่จะต้องเลือกจากตัวเลือกที่ทำงานซ้ำกัน
# Incremental investigation with non-overlapping tools
Grep "createOrder" # find entry points
Read src/orders/api.ts # load the file
Grep "api.createOrder" # find usages
Read src/checkout/page.ts # load consumersรายการตรวจสอบการจัดสรรที่ใช้ได้จริง
ก่อนนำเอเจนต์ไปใช้งานจริง ให้ตรวจสอบรายการนี้
- ชุดเครื่องมือมีจำนวนใกล้เคียง4–5 รายการ และน้อยกว่า 18 รายการมากพอหรือไม่
- เครื่องมือแต่ละรายการสอดคล้องกับเจตนาที่แตกต่างกัน และมีคำอธิบายที่ไม่ทับซ้อนกันหรือไม่
- ความต้องการแบบอ่านอย่างเดียวถูกกำหนดเป็นทรัพยากร ไม่ใช่เครื่องมือหรือไม่
- หากต้องการความสามารถเพิ่มขึ้น คุณสามารถแยกเป็นเอเจนต์ย่อยที่มีชุดเครื่องมือตามสิทธิ์เท่าที่จำเป็นได้หรือไม่
หากคุณกำลังเพิ่มเครื่องมือให้เอเจนต์เดียวจนเกินสิบสองรายการ นั่นคือสัญญาณให้แยกย่อยงาน ไม่ใช่เขียนคำอธิบายให้ยาวขึ้น
ตรวจสอบสั้น ๆ: การจัดสรรเครื่องมือ
นำหลักการนี้ไปใช้กับการตัดสินใจด้านการออกแบบจริง
สรุป: เอเจนต์หนึ่งตัวควรมีเครื่องมือกี่รายการ
ประเด็นสำคัญ
- เครื่องมือ 4–5 รายการต่อเอเจนต์หนึ่งตัวเหมาะสมที่สุด ความน่าเชื่อถือจะลดลงเมื่อจำนวนเพิ่มขึ้น และเครื่องมือ 18 รายการขึ้นไปส่งผลเสียต่อการเลือกอย่างเห็นได้ชัด
- โมเดลเลือกจากคำอธิบาย ดังนั้นเครื่องมือที่ทับซ้อนหรือกำกวมจะทำให้เลือกเส้นทางผิด แม้มีจำนวนไม่มาก
- กำหนดขอบเขตเครื่องมือตามบทบาท — ตัดสิ่งรบกวนออกแทนการเขียนคำอธิบายให้ยาวขึ้น
- ต้องการความสามารถเพิ่มหรือไม่ แยกเป็นเอเจนต์ย่อย (แบบศูนย์กลางและแขนง) พร้อมชุดเครื่องมือตามสิทธิ์เท่าที่จำเป็น และส่งบริบทอย่างชัดเจน เนื่องจากเอเจนต์ย่อยไม่สืบทอดประวัติ
- กำหนดความต้องการแบบอ่านอย่างเดียวเป็นทรัพยากรของ MCP ไม่ใช่เครื่องมือ เพื่อให้อาร์เรย์
toolsมีขนาดกะทัดรัด
เรียนรู้ Python ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 26
- บทเรียน
- 104
คำถามที่พบบ่อย
บทเรียน “ควรมีเครื่องมือกี่รายการต่อเอเจนต์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “ควรมีเครื่องมือกี่รายการต่อเอเจนต์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Claude Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “ควรมีเครื่องมือกี่รายการต่อเอเจนต์”
4-5 รายการเหมาะสมที่สุด ส่วน 18 รายการขึ้นไปทำให้ความน่าเชื่อถือในการเลือกลดลง คุณปฏิบัติ Claude Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Claude Architect หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Claude Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “ควรมีเครื่องมือกี่รายการต่อเอเจนต์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Claude Architect นี้ได้ไหม
ได้ บทเรียน Claude Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- ควรมีเครื่องมือกี่รายการต่อเอเจนต์
- tool_choice: อัตโนมัติ / ใดก็ได้ / บังคับ
- เครื่องมือในตัวของ Claude Code
- รูปแบบการสืบค้นแบบเพิ่มทีละขั้น