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

Alexandra Klepper

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

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

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

เราได้เขียนแยกต่างหากเกี่ยวกับ การสร้างเครื่องมือที่คำนึงถึงความปลอดภัย

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

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

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

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

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

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

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

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

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

ลดการประมวลผลเชิงความรู้ความเข้าใจ

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

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

จัดลำดับความสำคัญของความน่าเชื่อถือ

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

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

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

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

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

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

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

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

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