เดิมการเชื่อมเครื่องมือ N ตัวกับโมเดล M ตัวต้องสร้างชั้นปรับแต่ง N×M ชุด MCP แยกฝั่งเครื่องมือออกจากฝั่งโมเดล ทำให้แต่ละฝั่งต้องรองรับโปรโตคอลเพียงครั้งเดียว บทความนี้อธิบายแนวคิดดังกล่าว การนามธรรมของสภาพแวดล้อมและการกระทำในเบราว์เซอร์ รวมถึงสิ่งที่ยังแก้ไม่ได้ในปัจจุบัน
เมื่อ Agent ต้องลงมือทำงานจริง สุดท้ายมักต้องทำผ่านเบราว์เซอร์ ไม่ว่าจะเป็นการล็อกอิน โพสต์ข้อมูล เก็บข้อมูล หรือกรอกแบบฟอร์ม ความยากทางเทคนิคไม่ใช่ว่าคลิกได้หรือไม่ แต่คือค่าใช้จ่ายในการเชื่อมต่อเมื่อส่งมอบเบราว์เซอร์ให้ Agent ใช้งาน
หล่มของการปรับแต่ง N×M
สมมติว่ามีเครื่องมือ N ตัวและโมเดล M ตัวในตลาด ผู้ให้บริการเครื่องมือต้องเขียนโค้ดเชื่อมต่อสำหรับแต่ละโมเดล ขณะที่ฝั่งโมเดลก็ต้องมีชั้น adapter สำหรับแต่ละเครื่องมือ ทั้งสองฝั่งดูแลส่วนของตนเอง ทำให้มีการใช้งานรวม N×M ชุด
ปัญหาคือมันเป็นการคูณ การเพิ่มเครื่องมือหนึ่งตัวไม่ได้เพิ่มงานแค่ชิ้นเดียว แต่ต้องเชื่อมเครื่องมือนั้นกับทุกโมเดล ในทางกลับกัน เมื่อโมเดลเปลี่ยนเวอร์ชัน เครื่องมือที่เชื่อมแล้วก็อาจต้องตรวจสอบใหม่ ความสามารถหนึ่งอาจดีเพียงใด แต่ถ้าไม่มี adapter สำหรับโมเดลใดโมเดลหนึ่งก็ใช้งานไม่ได้ เครื่องมือจึงติดค้างอยู่ในขั้นตอนการกระจาย
ในช่วงแรกทุกฝ่ายต้องเขียนของตัวเอง งานเดียวกัน เช่น แสดงรายการสภาพแวดล้อม เริ่มเบราว์เซอร์ อ่านหน้าเว็บ ต้องเขียนใหม่เมื่อเปลี่ยนผู้เรียกใช้ และตรรกะก็มักไม่เหมือนกัน บางรายวางการรอไว้ที่ client บางรายวางไว้ที่ server
โปรโตคอลแยกสองฝั่งออกจากกัน
MCP (Model Context Protocol) เปิดเผยต่อสาธารณะในช่วงปลายปี 2024 แนวทางคือกำหนดการค้นหาและเรียกใช้เครื่องมือให้เป็นรูปแบบมาตรฐาน ตั้งแต่ว่าเปิดเผยอะไร อธิบายพารามิเตอร์อย่างไร ไปจนถึงส่งคืนโครงสร้างแบบใด ทั้งหมดถูกกำหนดไว้ในโปรโตคอล
โครงสร้างจึงกลายเป็น Agent เชื่อมกับ MCP Client จากนั้น Client เชื่อมกับ MCP Server หลายตัวตามโปรโตคอล ส่วนความสามารถจริงอยู่หลัง Server จำนวนการใช้งานลดจาก N×M เหลือ N+M ฝั่งโมเดลทำ client ครั้งเดียว และฝั่งเครื่องมือทำ server ครั้งเดียว
มีเพียงสามบทบาท Host คือแอปพลิเคชันที่รันโมเดลและมีหน้าที่เริ่ม client ส่วน Client คือการใช้งานไคลเอนต์ของโปรโตคอล โดยทั่วไปหนึ่ง Server ต่อหนึ่ง Client และ Server เขียนโดยผู้ให้บริการเครื่องมือเพื่อนำความสามารถออกมาเป็นเครื่องมือมาตรฐาน
ปัจจุบันมีการสื่อสารสองแบบ โหมด local ใช้ standard input/output โดย client และ server อยู่บนเครื่องเดียวกัน เส้นทางสั้นและตั้งค่าน้อย จึงใช้มากในงานอัตโนมัติ ส่วนโหมด remote ใช้ HTTP หรือ WebSocket เหมาะกับการติดตั้งแบบกระจาย แต่ต้องคิดเรื่องการยืนยันตัวตนและขอบเขตเครือข่ายให้ชัดเจนขึ้น
ในเบราว์เซอร์มีความสามารถสามชั้น
เมื่อนำสภาพแวดล้อมเบราว์เซอร์เข้าสู่โปรโตคอล ความสามารถที่เปิดเผยโดยทั่วไปแบ่งเป็นสามชั้น
ชั้นบนสุดคือสภาพแวดล้อม: แสดงรายการสภาพแวดล้อมในบัญชี สร้างใหม่ตามการตั้งค่า เริ่มสภาพแวดล้อมที่กำหนด ผูกทางออกเครือข่าย และปิดเมื่อใช้งานเสร็จ เดิมการทำงานเหล่านี้กระจายอยู่ใน API ของแต่ละผู้ให้บริการ แต่ตอนนี้กลายเป็นเครื่องมือที่โมเดลค้นหาและเรียกใช้ได้ หลังเริ่มทำงานมักส่งคืน debugging endpoint เช่น port หรือที่อยู่ WebSocket ซึ่งสามารถส่งต่อให้ driver อย่าง Selenium หรือ Puppeteer ได้
ชั้นกลางคือหน้าเว็บ: เปิดที่อยู่ อ่าน DOM หรือ accessibility tree สลับแท็บ และถ่ายภาพหน้าจอ
ชั้นล่างคือการกระทำ: คลิก พิมพ์ เลื่อน รอให้เงื่อนไขเป็นจริง และจัดการป๊อปอัป
การเปลี่ยนแปลงสำคัญไม่ได้อยู่ที่จำนวนการกระทำ แต่อยู่ที่สภาพแวดล้อมเปลี่ยนจากโค้ดที่ต้องเขียนเองเป็นทรัพยากรที่ Agent เลือกและใช้เองได้ คุณเพียงระบุเป้าหมายให้ชัด Agent สามารถตัดสินใจว่าจะสร้างสภาพแวดล้อมใหม่หรือใช้ของเดิม และจะเรียกเครื่องมือในลำดับใด เรื่องนี้เห็นชัดเมื่อใช้หลายสภาพแวดล้อมพร้อมกัน เพราะการจัดตารางอยู่ใน prompt แทนที่จะ hard-code ไว้ใน script
สิ่งที่ยังไม่ถูกแก้ในปัจจุบัน
โปรโตคอลแก้ปัญหาการเชื่อมต่อ ไม่ได้แก้ความถูกต้อง ยังมีหลายจุดที่มักถูกมองข้าม
คุณภาพของคำอธิบายเครื่องมือมีผลต่อผลลัพธ์การเรียกใช้ หากพารามิเตอร์ผิดหรือเลือกเครื่องมือผิด โปรโตคอลช่วยไม่ได้ เมื่อเครื่องมือเพิ่มขึ้น คำอธิบายเองก็กิน context จึงต้องหาสมดุลระหว่างจำนวนกับ granularity หากหยาบเกินไป โมเดลจะไม่รู้ว่าเครื่องมือหนึ่งทำได้กี่อย่าง หากละเอียดเกินไป context จะเต็มก่อน
สิทธิ์และการตรวจสอบยังอยู่ในระยะแรก Server จำนวนมากเป็นแบบ local บนเครื่องเดียว เมื่อเริ่มทำงานก็มีสิทธิ์ค่อนข้างสูง แต่ขาดการกำหนดสิทธิ์แบบละเอียดและบันทึกการเรียกใช้ ส่วนโหมด remote ต้องตอบก่อนว่าใครเชื่อมต่อได้และมองเห็นอะไรได้บ้าง
ความไม่เสถียรของหน้าเว็บก็ยังไม่หายไป การหา element ไม่เจอ ลำดับการโหลดไม่แน่นอน สถานะล็อกอินหมดอายุ และ CAPTCHA ยังต้องใช้การรอ การลองใหม่ และ fallback โปรโตคอลเพียงทำให้จุดเข้าใช้งานเป็นมาตรฐานเดียวกัน
ความพร้อมของระบบนิเวศก็ไม่เท่ากัน Server ต่างกันรองรับ resource types, return structures และ error codes ไม่เหมือนกันทั้งหมด เมื่อต้องรวม Server หลายตัวไว้ในงานเดียว มักยังต้องเขียน orchestration logic เอง และตัวโปรโตคอลยังพัฒนาต่อ จึงต้องระวังพฤติกรรมที่แตกต่างกันระหว่างเวอร์ชัน
ยังมีอีกขอบเขตที่ต้องแยกให้ชัด: โปรโตคอลดูแลว่าโมเดลเรียกเครื่องมืออย่างไร ไม่ได้ตัดสินว่างานนั้นเป็นไปตามกฎหรือไม่ การเก็บข้อมูลได้รับอนุญาตหรือไม่ วัตถุประสงค์การใช้บัญชีเหมาะสมหรือไม่ หรือมีการละเมิดกฎของแพลตฟอร์มหรือไม่ เป็นการพิจารณาแยกกัน และไม่เกี่ยวกับว่าการเชื่อมต่อราบรื่นเพียงใด
ในสถานการณ์หลายสภาพแวดล้อม การแยกจากกันระหว่างสภาพแวดล้อม และการตั้งค่า network egress, timezone และภาษาให้เป็นชุดเดียวกัน มักมีผลต่อผลลัพธ์มากกว่าวิธีเชื่อมต่อ ที่ชั้น environment isolation, PurpleMark มี interface สำหรับสร้าง เริ่ม และตั้งค่าเครือข่ายของสภาพแวดล้อมที่เครื่องมือ AI เรียกใช้ได้ และ client เดียวสามารถจัดตารางได้
เนื้อหานี้มีไว้เพื่ออธิบายหลักการทางเทคนิคเท่านั้น โปรดใช้โปรโตคอลและเครื่องมือที่เกี่ยวข้องภายใต้กฎหมายและข้อกำหนดที่ใช้บังคับ
