แนวทางปฏิบัติแนะนำสำหรับ WebMCP

Alexandra Klepper

เผยแพร่: 18 พฤษภาคม 2026

การประกาศเครื่องมือ WebMCP ควรชัดเจนโดยไม่จำเป็นต้องให้ นักพัฒนาแอปหรือเอเจนต์ดูเอาต์พุตและลองอีกครั้ง ไม่ว่าคุณจะใช้ Imperative API หรือ Declarative API โปรดทำตามแนวทางปฏิบัติแนะนำต่อไปนี้

• สร้างกลยุทธ์เครื่องมือก่อนสร้าง
• ใช้ภาษาที่ชัดเจนและ HTML เชิงความหมาย
• ออกแบบสคีมาและจัดการอินพุต
• สร้างเครื่องมือที่เชื่อถือได้
• ทดสอบและแก้ไขข้อบกพร่อง

สร้างกลยุทธ์เครื่องมือ

เช่นเดียวกับที่คุณทำกับแอปพลิเคชันซอฟต์แวร์อื่นๆ ขั้นตอนแรกของคุณควรเป็นการวางแผน กลยุทธ์เครื่องมือ

• เครื่องมือแต่ละอย่างควรประกอบด้วยฟังก์ชันเดียว ตัวอย่างเช่น เครื่องมือหนึ่งอาจ นำผู้ใช้ไปยังแบบฟอร์มประเภทหนึ่งๆ ในขณะที่อีกเครื่องมือหนึ่งควรจับคู่ ช่องป้อนข้อมูลกับข้อมูลผู้ใช้ โปรดระมัดระวังไม่ให้สร้างเครื่องมือที่ซ้อนทับกัน เนื่องจาก Agent อาจสับสนว่าจะใช้เครื่องมือใด ลองถามตัวเองว่า ฉันใช้ฟังก์ชันเดียวกันเพื่อทำงานหลายอย่างได้ไหม
• จัดการการลงทะเบียนเครื่องมือ ลงทะเบียนเครื่องมือเมื่อมีประโยชน์ในสถานะหน้าเว็บหนึ่งๆ จากนั้นยกเลิกการลงทะเบียนเมื่อเครื่องมือใช้ไม่ได้อีกต่อไป
  • API ที่จำเป็น: คุณสามารถจัดการการจดทะเบียนแบบไดนามิกด้วย registerTool
  • Declarative API: คุณสามารถจัดการการลงทะเบียนแบบไดนามิกได้โดยการเพิ่มหรือนำแอตทริบิวต์เครื่องมือในแบบฟอร์มออก ด้วย toolname และ tooldescription
• ลดความซับซ้อน: สำหรับแอปพลิเคชันส่วนใหญ่ การลงทะเบียนแบบคงที่ควรเป็น แนวทางเริ่มต้น
• วางใจให้ตัวแทนทำงานให้เสร็จ แทนที่จะเขียนคำสั่งที่เข้มงวดหรือเป็นลบ ให้ถือว่าเอเจนต์เข้าใจสิ่งที่จำเป็นในการทำงานให้เสร็จสมบูรณ์ แทนที่จะคาดหวังให้เอเจนต์จัดการขั้นตอนที่แน่นอน

แม้ว่าจะไม่มีจำนวนเครื่องมือสูงสุดที่อนุญาต แต่เครื่องมือแต่ละอย่างจะใช้ส่วนหนึ่งของหน้าต่างบริบทและเพิ่มเวลาในการดำเนินการให้เสร็จสมบูรณ์ ยิ่งคุณให้เครื่องมือมากเท่าใดและเครื่องมือมีความทับซ้อนกันมากเท่าใด Agent ก็จะยิ่งเลือกได้อย่างถูกต้องยากขึ้นเท่านั้น ทดสอบเพื่อดูว่าอะไรเหมาะกับแอปพลิเคชันของคุณ

ซึ่งจะช่วยให้คุณสร้างเครื่องมือแต่ละรายการได้โดยไม่มีวัตถุประสงค์ที่ทับซ้อนกัน และจัดการได้ว่าเครื่องมือเหล่านี้พร้อมใช้งานเมื่อใด

ใช้ภาษาที่ชัดเจนและโค้ดเชิงความหมาย

ใช้ภาษาที่ชัดเจนและตรงไปตรงมาในการตั้งชื่อเครื่องมือและอธิบายการใช้งาน ซึ่งจะช่วยให้ ตัวแทนค้นหาสิ่งที่ต้องการ เข้าใจสิ่งที่ค้นพบ และใช้ข้อมูลนั้น ตามที่นักพัฒนาซอฟต์แวร์คาดหวัง

เมื่อเขียนชื่อเครื่องมือ ให้แยกการดำเนินการจากการเริ่มต้น และใช้คำกริยา ที่อธิบายสิ่งที่เกิดขึ้นอย่างชัดเจน เช่น create-event เป็นเครื่องมือสำหรับ การสร้างกิจกรรมทันที แต่ start-event-creation-process เป็นเครื่องมือที่ เปลี่ยนเส้นทางผู้ใช้ไปยังแบบฟอร์มเพื่อสร้างกิจกรรม

คำอธิบายที่ชัดเจนควรระบุสิ่งที่เครื่องมือทำและเวลาที่ควรใช้ ใช้ภาษาและค่ากำหนดเชิงบวกแทนภาษาเชิงลบ เช่น ข้อจำกัด

ลดการประมวลผลทางปัญญา

เช่นเดียวกับที่คุณควรลดภาระทางปัญญาสำหรับมนุษย์ที่ทำงานที่ซับซ้อน คุณก็ควรลดการประมวลผลด้านการรู้คิดสำหรับโมเดลด้วย

• ยอมรับข้อมูลจากผู้ใช้แบบดิบ หลีกเลี่ยงการขอให้ตัวแทนทำการคำนวณทางคณิตศาสตร์หรือแปลงสตริงอินพุต เช่น หากผู้ใช้พูดว่า "11:00 น. ถึง 15:00 น." เครื่องมือควรยอมรับข้อความนี้เป็นสตริง หลีกเลี่ยงการขอให้โมเดลคำนวณนาทีระหว่างเวลาเหล่านี้
• ประกาศประเภทที่เฉพาะเจาะจงสำหรับพารามิเตอร์ เช่น สตริง ตัวเลข หรือ Enum
• อธิบายเหตุผลที่คุณเลือกตัวเลือกหนึ่งๆ ตัวเลือกที่คุณเลือกควรจะอธิบายตัวเองได้ ส่วนเหตุผลจะช่วยให้ตัวแทนเลือกตัวเลือกที่ดีขึ้น เช่น หากคุณมีร้านค้าอีคอมเมิร์ซ ให้ประกาศประเภทการจัดส่งด้วยภาษาธรรมชาติแทนการใช้รหัสที่คลุมเครือ: shipping="Express" แทน shipping_id=1

ให้ความสำคัญกับความน่าเชื่อถือ

เอเจนต์และมนุษย์จะได้รับประโยชน์จากเครื่องมือที่ทำงานตามที่คาดไว้ ดังนี้

• ตั้งค่าการทำงานล้มเหลวอย่างค่อยเป็นค่อยไปสำหรับขีดจำกัดอัตรา เครื่องมือควรอนุญาตให้มีการทำซ้ำอย่างสมเหตุสมผล เช่น การเปรียบเทียบราคา หากเครื่องมือถูกจำกัดอัตรา ให้แสดงข้อผิดพลาดที่มีความหมายหรือแนะนำให้ผู้ใช้ดำเนินการด้วยตนเอง
• อัปเดตสถานะอินเทอร์เฟซหลังจากฟังก์ชันเสร็จสมบูรณ์ ตัวแทนอาจต้องพึ่งพาอินเทอร์เฟซเพื่อวางแผนขั้นตอนถัดไป ในขณะที่ฟังก์ชันอาจใช้เวลานานกว่าการโหลดอินเทอร์เฟซ ตัวแทนควรยืนยันว่าฟังก์ชัน เสร็จสมบูรณ์แล้วเมื่ออินเทอร์เฟซได้รับการอัปเดต หรือขออัปเดตอีกครั้ง
• ตรวจสอบอย่างเคร่งครัดในโค้ด และตรวจสอบอย่างคร่าวๆ ในสคีมา ควรใช้ข้อจำกัดและการทดสอบ สำหรับฟังก์ชันและโค้ดที่มีตรรกะไบนารี แม้ว่าข้อจํากัดของสคีมา จะมีประโยชน์ แต่ก็ไม่ได้รับประกัน เพิ่มข้อผิดพลาดที่สื่อความหมาย ลงในโค้ดฟังก์ชันเพื่อให้โมเดลแก้ไขตัวเองและลองอีกครั้งด้วยพารามิเตอร์ใหม่ที่ถูกต้อง

การทดสอบและการแก้ไขข้อบกพร่องของ Eval

สร้างการทดสอบการประเมินและทำให้เครื่องมือพร้อมใช้งานสำหรับการแก้ไขข้อบกพร่อง การประเมินจะเขียนโค้ดแบบฮาร์ดโค้ดไม่ได้เนื่องจากเอาต์พุตอาจอยู่ในรูปแบบที่ไม่คาดคิด ซึ่งแตกต่างจากการทดสอบหน่วยที่กำหนด

• ระบุปัญหา คุณสามารถกำหนดปัญหาในลักษณะของสัญญา API ซึ่งรวมถึงประเภทอินพุต รูปแบบเอาต์พุต และข้อจำกัดเพิ่มเติม
• กำหนดพื้นฐานและผลลัพธ์ในอุดมคติ โดยเฉพาะอย่างยิ่งเมื่อป้อนข้อความ คุณควรทำความเข้าใจประเภทผลลัพธ์ที่สามารถให้เอาต์พุตที่คุณคาดหวัง
• กำหนดวิธีประเมินผลลัพธ์ คุณน่าจะระบุและวัดผลลัพธ์เชิงคุณภาพที่เป็นอัตวิสัยโดยอิงตามคุณภาพของอินพุต ความมีประโยชน์ และความสามารถในการทำงานถัดไปให้สำเร็จ คุณใช้เทคนิคต่างๆ เพื่อประเมินเอาต์พุตได้ เช่น การตรวจสอบที่อิงตามโค้ดสำหรับเอาต์พุตที่อิงตามกฎ (ขีดจำกัดอักขระ) และ LLM-as-a-judge

หลีกเลี่ยงการเพิ่มกฎที่จำกัดเพื่อแก้ไขปัญหาเกี่ยวกับโมเดลใดโมเดลหนึ่ง เช่น หากคุณรวมช่องแบบเลือกสำหรับคำนำหน้าชื่อ โมเดลอาจเลือกผิด แทนที่จะเพิ่มกฎที่จำกัดเพื่อแก้ไขปัญหานี้ ให้สรุปและปรับเครื่องมือ คุณอาจทำได้ดีที่สุดโดยการตั้งค่าช่องนี้เป็นไม่บังคับ จากนั้นขอให้ตัวแทนถาม ผู้ใช้ว่าตัวเลือกใดสมเหตุสมผล เพื่อให้แน่ใจว่าผู้ใช้พึงพอใจกับผลลัพธ์

มีส่วนร่วมและแชร์ความคิดเห็น

WebMCP อยู่ระหว่างการหารืออย่างต่อเนื่องและอาจมีการเปลี่ยนแปลงในอนาคต หากคุณลองใช้ API เหล่านี้และมีความคิดเห็น โปรดส่งมาให้เรา

• อ่านคำอธิบายของ WebMCP ถามคำถามและเข้าร่วมการสนทนา
• ดูการติดตั้งใช้งานสำหรับ Chrome ได้ที่ Chrome Status
• เข้าร่วมโปรแกรมทดลองใช้ก่อนเปิดตัว เพื่อดู API ใหม่ๆ ก่อนใครและรับสิทธิ์เข้าถึงรายชื่ออีเมลของเรา
• หากมีความคิดเห็นเกี่ยวกับการติดตั้งใช้งานของ Chrome โปรดรายงานข้อบกพร่องของ Chromium