เมื่อให้ AI เรียกเครื่องมือได้ งานจะขยับจากการอธิบายข้อมูลไปสู่การค้นหรือสร้างผลในระบบอื่น โมเดลอาจหารายการ อ่านรายละเอียดแล้วส่งคำขอแก้สถานะต่อได้ แต่การที่มันเลือกชื่อเครื่องมือถูกยังไม่พอจะบอกว่าทำงานถูกขอบเขตแล้ว
ก่อนถึงผลปลายทางยังมีคำถามว่าเลือกข้อมูลถูกชิ้นไหม input หมายถึงอะไร ผู้เรียกมีสิทธิ์หรือเปล่า และคำตอบจากเครื่องมือยืนยันงานถึงขั้นใด หากส่วนเหล่านี้คลุมเครือ เราอาจเห็นข้อความว่างานเสร็จแล้วทั้งที่เพิ่งรับคำขอไว้หรือแก้คนละรายการ
การออกแบบ tool จึงควรเริ่มจากสัญญาที่ตรวจได้ทั้งสองฝั่งครับ ให้โมเดลเข้าใจว่าจะใช้เมื่อใด และให้บริการบังคับเงื่อนไขก่อนสร้างผลจริงด้วย
ถ้ามีเครื่องมือหลายตัวชื่อใกล้กันและคำอธิบายกว้างเหมือนกัน โมเดลต้องเลือกจากข้อมูลที่ไม่พอ การแยกหน้าที่ตามงาน เช่น ค้นรายการ อ่านฉบับปัจจุบัน หรือขอเปลี่ยนสถานะ ช่วยให้เห็นว่าแต่ละตัวรับผิดชอบผลแบบใด
เครื่องมือที่ทำหลายขั้นภายในก็มีได้ ถ้ามันมีขอบเขตที่อธิบายและตรวจได้ตามงาน แต่ไม่ควรใช้ชื่อเหมือนอ่านข้อมูลทั้งที่มีการเปลี่ยนผลตามมาด้วย เพราะผู้เรียกกับคนดูแลจะประเมินผลกระทบจากสัญญาผิดไปตั้งแต่ต้น
การเพิ่มทุก API endpoint ให้กลายเป็น tool ก็ไม่ได้ทำให้ทำงานง่ายขึ้นเสมอไป ควรเลือกสิ่งที่ตรงกับโจทย์ที่ต้องรองรับ และตรวจว่าหน้าที่ไม่ทับกันจนเลือกผิดบ่อย แนวทางของ Anthropic เน้นเครื่องมือที่มีจุดประสงค์ชัดและผลที่นำไปใช้ต่อได้ ซึ่งต้องประเมินกับชุดงานของเราเอง
ตัวอย่างสมมติอย่าง parameter ชื่อ project ยังไม่บอกว่ารับชื่อที่คนเห็น รหัสถาวร หรือข้อความไว้ค้น หากเครื่องมือรับ project_id ก็ควรระบุแหล่งที่ได้รหัสและตรวจว่ารหัสนั้นอยู่ในขอบเขตที่ผู้เรียกใช้ได้จริง
เมื่อชื่อค้นแล้วพบหลายรายการ ควรมีผลลัพธ์ที่ให้เลือกหรือตรวจต่อ ไม่หยิบรายการแรกไปแก้เพียงเพราะคะแนนค้นสูงกว่าเล็กน้อย ความกำกวมของตัวระบุควรถูกแก้ก่อนขั้นสร้างผล ไม่ฝากไว้ให้คำตอบสุดท้ายบอกว่าเดาผิดภายหลัง
Schema ช่วยตรวจชนิดและค่าที่รับได้ แต่ยังต้องตรวจความสัมพันธ์ เช่น รายการนี้เปลี่ยนจากสถานะปัจจุบันไปสถานะที่ขอได้หรือไม่ และรหัสโครงการกับรหัสรายการเป็นคู่เดียวกันหรือเปล่า การผ่านตัวตรวจ JSON จึงยังไม่แทนกติกางานทั้งหมด
การเขียนไว้ในคำอธิบายว่าใช้สำหรับผู้ดูแลช่วยให้โมเดลเข้าใจเจตนา แต่ไม่ใช่กลไกพิสูจน์ว่าคนเรียกเป็นผู้ดูแลจริง บริการต้องตรวจตัวตนและสิทธิ์ตามการกระทำกับรายการก่อนทำผลเหมือน API ปกติ
ไม่ควรเปิดให้โมเดลเลือกค่าบัญชีหรือระดับสิทธิ์แล้วเชื่อตาม input นั้นทันที บริบทที่ใช้อนุญาตควรมาจากการเชื่อมต่อที่ตรวจแล้ว และจำกัดสิ่งที่เครื่องมือทำได้ตามหน้าที่ ไม่ใช้สิทธิ์กว้างเพียงเพราะครอบคลุมงานได้สะดวกกว่า
หากงานมีขั้นยืนยันจากคนตามนโยบาย ควรส่งรายละเอียดผลที่กำลังจะเกิดให้ตรวจได้ เช่น รายการเป้าหมาย ฉบับข้อมูลและการเปลี่ยนที่ขอ ไม่ถือว่าประโยคในเอกสารที่โมเดลอ่านหรือข้อความจาก tool อื่นเป็นการยืนยันจากผู้มีอำนาจโดยตัวมันเอง
เครื่องมือค้นอาจจำกัดจำนวนผลหรือความยาวข้อความเพื่อรักษาบริบทให้พอดี แต่ต้องบอกเมื่อมีหน้าถัดไปหรือข้อมูลถูกตัด ไม่ให้โมเดลเห็นรายการบางส่วนแล้วเขียนว่าเป็นข้อมูลทั้งหมดที่มีอยู่
กรณีไม่พบผล ไม่มีสิทธิ์ค้น และบริการปลายทางไม่พร้อมก็มีวิธีทำต่อต่างกัน ควรออกแบบสถานะกับข้อความที่ช่วยให้ตัดสินขั้นถัดไปได้ ภายใต้ขอบเขตข้อมูลที่เปิดเผยได้ ไม่รวมทุกอย่างเป็นผลว่างจนผู้เรียกคิดว่าไม่มีรายการนั้นจริง
คำตอบควรให้ข้อมูลที่จำเป็นต่อการทำงานต่อ เช่น รหัสที่ใช้เรียกครั้งถัดไปพร้อมชื่อที่คนตรวจเข้าใจ และส่วนหลักฐานที่สัมพันธ์กับคำถาม แทนการคืนข้อมูลภายในทุกช่องหรือ stack trace ทั้งหมดที่ไม่ได้ช่วยตัดสินงานและอาจมีข้อมูลลับติดมา
ถ้า tool เริ่มงานเบื้องหลังแล้วคืนรหัสงาน โมเดลควรรู้ว่านั่นเป็นการตอบรับ ไม่ใช่ผลสำเร็จของงานทั้งหมด เครื่องมือจึงควรมีสถานะและทางตามที่ตรงกับขั้นที่ยืนยันได้ ไม่คืนข้อความกว้างๆ ว่าสำเร็จตั้งแต่แค่ส่งเข้าคิว
เมื่อคำตอบขาดหลังสั่งเปลี่ยนข้อมูล โมเดลก็ไม่ควรส่งใหม่แบบสร้างงานอีกชิ้นทันทีโดยไม่มีทางตรวจเดิม สัญญาเครื่องมือควรมีวิธีตามผลหรือใช้รหัสการดำเนินการที่คงเดิมตามกติกา เพื่อแยกคำขอเดิมออกจากความตั้งใจใหม่
ส่วนงานแก้ข้อมูลที่มีหลายคนใช้อยู่ควรพิจารณาเงื่อนไขรุ่นด้วย ไม่ให้เครื่องมืออ่านข้อมูลแล้วเขียนทับฉบับที่เปลี่ยนระหว่างทางโดยไม่ตรวจ การมีโมเดลคั่นอยู่ไม่ได้ลดความจำเป็นของกติกา concurrency และ idempotency ที่บริการต้องรักษา
ป้ายหรือ annotation ที่บอกว่าเครื่องมืออ่านอย่างเดียวควรถูกใช้เป็นข้อมูลอธิบายความสามารถตามที่ระบบรองรับ แต่ยังต้องตรวจว่าการทำงานภายในรักษาคำอธิบายนั้นจริง ไม่ใช้ metadata ในรายการเครื่องมือแทนการจำกัดสิทธิ์ของบริการที่ถูกเรียก
เมื่อเครื่องมือผิดพลาดซ้ำ ควรมีเกณฑ์ว่าจะลองใหม่ เปลี่ยนทาง หรือส่งสถานะให้คนรับช่วง ไม่เพิ่มการเรียกไปเรื่อยๆ โดยไม่มีข้อมูลใหม่ ขอบเขตจำนวนขั้น เวลาและทรัพยากรช่วยให้ระบบมีจุดหยุดที่ตามเหตุได้ โดยยังไม่รายงานว่าสำเร็จถ้าผลปลายทางยังไม่ยืนยัน
ชุดตรวจควรมีงานที่พบหลายรายการ input ไม่ครบ สิทธิ์ไม่พอ ผลค้นหลายหน้า และคำตอบขาดหลังสร้างผล พร้อมตรวจข้อมูลปลายทางจริงในสภาพทดลอง ไม่ให้คะแนนจากถ้อยคำรายงานอย่างเดียว ควรบันทึกด้วยว่ามีการเรียกซ้ำหรือเลือกเครื่องมือที่ไม่จำเป็นตรงไหน เพื่อปรับสัญญาตามปัญหาที่พบ
Tool ที่ใช้ร่วมกับ AI ได้ดีต้องมีหน้าที่ input สิทธิ์และผลลัพธ์ที่ตรงกัน เมื่อบริการบังคับขอบเขตจริง และผลตอบบอกได้ว่าข้อมูลครบหรือยัง งานไปถึงขั้นใดและตามต่ออย่างไร โมเดลก็มีหลักฐานพอสำหรับเลือกขั้นถัดไป ส่วนการประเมินควรตรวจทั้งทางเลือกของโมเดลกับผลที่เครื่องมือสร้าง เพื่อให้คำว่างานเสร็จมีสิ่งยืนยันอยู่ข้างหลัง