การเพิ่มเครื่องมือให้ AI Agent อาจทำให้ context ยาวขึ้น Jan Čurn ตั้งคำถามในคลิปว่า ปัญหาที่พบมาจากมาตรฐาน MCP หรือจากวิธีที่ระบบรอบ Agent โหลดเครื่องมือและจัดผลลัพธ์
Jan Čurn ผู้ก่อตั้งและซีอีโอของ Apify เสนอประเด็นนี้ในคลิปจากช่อง AI Engineer โดยแยกให้เห็นว่าอะไรเป็นหน้าที่ของ MCP และอะไรเป็นหน้าที่ของระบบควบคุม Agent พร้อมสาธิต mcpc เครื่องมือที่นำข้อดีของ MCP มารวมกับการสั่งงานผ่าน CLI
ข้อคิดประยุกต์ของ VibeSolo คือดูว่า workflow ให้ AI เห็นข้อมูลใด จัดการข้อมูลส่วนใดนอกบทสนทนา และจะวัดผลจากงานที่ตรวจคำตอบได้อย่างไร
แยกปัญหา MCP ออกจากปัญหา AI Agent
Jan อธิบาย MCP ว่าเป็นช่องทางให้แอปพลิเคชัน AI เข้าถึงเครื่องมือและทรัพยากรของ server
ข้อโต้แย้งของเขาคือ MCP กับ harness มีหน้าที่ต่างกัน ระบบรอบ Agent ยังต้องเลือกว่าจะโหลดเครื่องมือใด ส่งข้อมูลอะไรเข้า model และจัดการผลลัพธ์อย่างไร
ในมุมประยุกต์ของ VibeSolo harness เปรียบได้กับส่วนจัดงานให้ AI เห็นข้อมูลและเครื่องมือที่เกี่ยวข้อง การแยกหน้าที่เช่นนี้ช่วยตั้งโจทย์ตรวจระบบทีละส่วน
ตัวอย่างปัญหา: มีเครื่องมือมาก แต่โหลดทั้งหมดตั้งแต่แรก
Jan ยกตัวอย่างสมมติว่ามี MCP server 10 ตัว ตัวละประมาณ 10 เครื่องมือ หากใส่รายละเอียดทั้ง 100 เครื่องมือเข้า context ตั้งแต่ต้น ก็ใช้พื้นที่ไปก่อนเริ่มงาน
ในรูปแบบ harness ที่เขากำลังวิจารณ์ ผลจากเครื่องมือถูกนำกลับเข้า context และสะสมระหว่างทำงาน เขามองว่ารูปแบบนี้อาจเพิ่มต้นทุนและรบกวนการเลือกข้อมูล
หากนำแนวคิดนี้มาคิดกับธุรกิจไทย สมมติทีมใช้ AI ช่วยค้นเอกสาร การเปิดเครื่องมือด้านการเงิน การตลาด และระบบไฟล์ทั้งหมดให้พร้อมกันอาจไม่จำเป็น งานค้นเอกสารควรเริ่มจากเครื่องมือที่เกี่ยวข้อง ไม่ใช่จากรายการความสามารถทั้งองค์กร
ข้อคิดของ VibeSolo คือแยก server, client และ harness เมื่อตรวจสาเหตุของ context ที่ยาวขึ้น เพื่อถามได้ตรงส่วนที่ต้องปรับ ข้อเสนอของ Jan เป็นมุมมองของทีมพัฒนาเครื่องมือ ซึ่งยังต้องเทียบกับงานจริง
เลือกวิธีลด context ให้ตรงกับสาเหตุ
คลิปเสนอสามแนวทางหลัก ได้แก่ Agent ย่อย การค้นหาเครื่องมือเมื่อจำเป็น และการใช้เครื่องมือผ่านโค้ด ทั้งสามวิธีแก้คนละส่วน จึงไม่ควรใช้แทนกันโดยไม่ดูสาเหตุ
วิธีที่หนึ่ง: แบ่งงานให้ Agent ย่อย
Jan อธิบายว่า sub-agent มี context แยกจาก Agent หลัก จึงช่วยแยกงานและรายละเอียดระหว่างทำงานได้ในแนวทางที่เขายกตัวอย่าง
ข้อดีคือช่วยแยกงานและลดความรกของ Agent หลัก แต่ Jan ชี้ข้อจำกัดไว้ชัดเจนว่า token ที่ Agent ย่อยใช้ยังต้องจ่าย การย้ายข้อมูลไปอีกบทสนทนาจึงไม่เท่ากับการลดข้อมูลที่ระบบประมวลผลโดยรวม
เขายกกรณีสมมติว่าเครื่องมือคืนรหัสผ่านเข้ามาใน context ของ sub-agent ปัญหาการส่งข้อมูลลับเข้า model ก็ยังอยู่ การแยก Agent จึงต้องดูสิ่งที่เครื่องมือส่งกลับด้วย
วิธีที่สอง: ค้นหาเครื่องมือเมื่อจำเป็น
แนวทาง progressive tool discovery ไม่ใส่รายละเอียดเครื่องมือทั้งหมดตั้งแต่ต้น แต่ให้ Agent ค้นก่อนว่างานนี้ต้องใช้เครื่องมืออะไร แล้วจึงโหลดเฉพาะรายการที่เกี่ยวข้อง
Jan ยก Tool Search ของ Anthropic เป็นตัวอย่างของการค้นหาเครื่องมือก่อนโหลดรายละเอียด เขาเสนอให้เปิดเฉพาะความสามารถที่เกี่ยวกับงาน โดยต้องตรวจว่า client ที่ใช้รองรับวิธีนี้หรือไม่
คำถามประยุกต์ของ VibeSolo สำหรับทีมที่เชื่อมหลายระบบคือ “ระบบค้นหาเครื่องมือก่อนใช้ หรือส่งรายการทั้งหมดให้ model ตั้งแต่เริ่มงาน?” ต้องวัดกับ workflow ของทีมก่อนสรุปว่าการเปลี่ยนวิธีโหลดจะลดต้นทุนได้เท่าไร
วิธีที่สาม: ใช้เครื่องมือผ่านโค้ด
Jan อธิบาย Code Mode ว่าให้ Agent ใช้โค้ดค้นหาและเรียกเครื่องมือ แล้วประกอบขั้นตอนการทำงาน เขายกแนวทางของ Cloudflare เป็นตัวอย่างของการจัดงานและผลลัพธ์ผ่านโค้ด
ผู้พูดให้เหตุผลว่า model คุ้นเคยกับโค้ดและเสนอให้ลองแนวทางนี้กับการเรียกเครื่องมือ ผลว่าเหมาะกับงานใดยังต้องวัดแยกจากเหตุผลที่เขาเสนอ
ข้อคิดประยุกต์ของ VibeSolo คือพิจารณาว่าระบบจะกรองหรือจัดการข้อมูลส่วนใดก่อนส่งกลับให้ AI โดยต้องตรวจความสามารถของสภาพแวดล้อมที่ใช้งานจริง
ใช้ MCP และ CLI ตามหน้าที่ ไม่ต้องเลือกข้าง
Jan เสนอให้ใช้ CLI เป็นทางที่ Agent เรียกคำสั่งในเครื่องหรือสภาพแวดล้อมทำงาน เขามองว่า Agent ใช้คำสั่ง shell และเปิดคู่มือเฉพาะตอนจำเป็นได้
ในแนวทางที่เขานำเสนอ Agent สามารถอ่านรายละเอียดเฉพาะคำสั่งและต่อผลลัพธ์ด้วยเครื่องมือใน shell วิธีนี้เป็นอีกทางของการค้นหาความสามารถและจัดงานผ่านโค้ด
เขามองว่าคำสั่ง CLI แต่ละตัวอาจจัดการการเชื่อมต่อระยะไกลและการยืนยันตัวตนต่างกัน จึงเสนอให้ใช้ MCP จัดส่วนนี้
ข้อเสนอของ Jan จึงเป็นการแบ่งหน้าที่:
- MCP: ในข้อเสนอของผู้พูด ใช้เชื่อมกับบริการระยะไกลและจัดรายละเอียดการเชื่อมต่อ เช่น การยืนยันตัวตนและ session
- CLI: เป็นช่องทางที่ Agent ใช้สั่งงานจากเครื่องหรือสภาพแวดล้อมที่กำลังทำงานอยู่
- เครื่องมือตัวกลาง: รับคำสั่งผ่าน CLI แล้วจัดการรายละเอียดการเชื่อมต่อ MCP ให้
คำถามประยุกต์ของ VibeSolo คือระบบที่เลือกจัดการสิทธิ์และค้นหาเครื่องมือได้ตรงกับงานหรือไม่ รวมถึงข้อมูลใดถูกส่งเข้า model
ส่วนข้อจำกัดที่ไม่ควรมองข้ามคือ วิธีนี้ต้องมีสภาพแวดล้อมให้ Agent รันคำสั่งได้ หาก platform ที่ใช้อยู่ไม่รองรับ shell หรือการรันโค้ด การเพิ่ม CLI ก็อาจไม่ใช่ทางเลือกที่นำมาใช้ได้ทันที
ทดลอง mcpc ด้วย workflow เล็กๆ ก่อน
Jan แนะนำ mcpc เป็น CLI client สำหรับ MCP ที่ทีม Apify พัฒนา โดยระบุว่าตัวเครื่องมือไม่มี LLM แต่จัดรายละเอียดโปรโตคอลไว้หลังคำสั่ง
คำอธิบายวิดีโอแนบโครงการ mcpc บน GitHub สำหรับศึกษาต่อ ลำดับด้านล่างเป็นสิ่งที่ผู้พูดแสดงในเดโม
- เริ่มจาก server ภายในเครื่อง: ตัวอย่างใช้ MCP server สำหรับระบบไฟล์ผ่าน stdio เพื่อทดสอบการเชื่อมต่อและดูรายการเครื่องมือ
- ตรวจข้อมูลที่ server ส่งมา: ดูชื่อ server ความสามารถที่รองรับ คำแนะนำ และคำสั่งที่เรียกได้
- ทดลองบริการระยะไกล: ตัวอย่างเชื่อม Apify MCP server โดยเข้าสู่กระบวนการยืนยันตัวตนผ่านเบราว์เซอร์
- ตรวจการเก็บข้อมูลยืนยันตัวตน: Jan ระบุว่าข้อมูลของเดโมเก็บใน keychain ของระบบปฏิบัติการ ซึ่งเป็นคำอธิบายของผู้พัฒนา
- ค้นหาเครื่องมือเฉพาะงาน: ผู้พูดค้นจากชื่อและคำอธิบาย แทนเปิดรายละเอียดเครื่องมือทั้งหมด
Jan แสดงรายการ session ที่เก็บไว้และกล่าวว่า coding agent ต่างตัวสามารถใช้ session เดียวกันได้ในสภาพแวดล้อมนั้น ทีมที่จะนำไปใช้ต้องตรวจการเข้าถึงและการเชื่อมต่อของตน
ในตัวอย่าง Jan ค้นหาเครื่องมือที่มีคำว่า “find” แล้วได้ผลลัพธ์จากทั้ง server ระบบไฟล์และ Apify วิธีนี้ทำให้เห็นการค้นหาเครื่องมือเมื่อจำเป็นเป็นรูปธรรม ไม่ใช่เพียงแนวคิดบนสไลด์
ข้อเสนอประยุกต์ของ VibeSolo คือเริ่มจากงานอ่านข้อมูลที่มีขอบเขตและตรวจผลได้ แล้วดูว่า Agent เลือกเครื่องมือถูกหรือไม่ การเชื่อมต่อได้สำเร็จยังไม่พิสูจน์ว่างานปลายทางถูกต้อง
แยกข้อมูลจำนวนมากและงานรอนานออกจากบทสนทนา
Jan อธิบายว่า mcpc ส่งผลลัพธ์แบบ JSON เพื่อนำไปใช้กับเครื่องมืออย่าง jq และการต่อคำสั่งใน shell ได้
ข้อเสนอของเขาคือให้เครื่องมือกรองและจัดข้อมูลบางส่วนก่อนส่งกลับเข้า context ของ Agent จึงไม่ต้องนำผลดิบทุกชิ้นผ่าน model
หากประยุกต์กับงานค้นข้อมูลเว็บของธุรกิจ เราอาจให้ระบบรวบรวมและคัดข้อมูลก่อนส่งให้ AI สรุป แทนการส่งข้อมูลดิบทั้งหมดเข้าแชต ตัวอย่างนี้เป็นแนวทางประยุกต์ ไม่ใช่ผลทดสอบที่คลิปยืนยันไว้
งานรอนานควรตรวจสถานะและรับผลภายหลังได้
เดโมอีกส่วนเริ่ม asynchronous task ที่ server และแสดงสถานะว่ากำลังทำงาน ผู้พูดอธิบายว่าตรวจสถานะหรือรับผลภายหลังได้ แต่จบส่วนเดโมขณะงานยังรันอยู่ จึงไม่มีหลักฐานผลลัพธ์ที่เสร็จแล้วจากช่วงนี้
Jan ระบุว่าความสามารถงานเบื้องหลังต้องได้รับการรองรับจากการเชื่อมต่อที่ใช้ เป็นเรื่องแยกจากความเร็วของตัวงาน
ช่วงท้าย Jan ยังกล่าวถึง x402 และ proxy จาก sandbox แบบสั้นๆ โดยไม่ได้ลงรายละเอียดพอเป็นคู่มือติดตั้งหรือระบุเงื่อนไขการใช้งานในปัจจุบัน
ข้อคิดประยุกต์ของ VibeSolo จากตัวอย่างข้อมูลลับคือแยกการจัดเก็บข้อมูลยืนยันตัวตนออกจากสิ่งที่เครื่องมือคืนเข้า context แล้วตรวจสิ่งที่ Agent ได้รับด้วย
วัดผลจากงานเดียวกัน ก่อนเชื่อคำว่าเร็วหรือถูกกว่า
Jan แนะนำ Connector Evals ซึ่งทีม Apify ใช้เปรียบเทียบช่องทางเชื่อมต่อ MCP แบบเรียกตรง, CLI และ mcpc โดยพยายามคง Agent ที่ใช้ทดสอบไว้เหมือนกัน
กราฟตัวอย่างบนสไลด์ใช้เวลาในแนวนอนและต้นทุนสะสม (USD) ในแนวตั้ง Jan รายงานว่า mcpc กับ CLI ใกล้เคียงกันในงานตัวอย่าง ส่วน MCP แบบเรียกตรงบางกรณีเร็วกว่าแต่ใช้ token มากกว่า
Jan ระบุว่าการทดสอบยังอยู่ช่วงแรก ผลที่นำเสนอมาจากทีมพัฒนา mcpc และไม่ได้มีข้อมูลดิบให้บทความตรวจซ้ำ จึงยังสรุปไม่ได้ว่า mcpc ถูกที่สุด หรือ MCP แบบเรียกตรงแย่กว่าเสมอ
ข้อเสนอประยุกต์ของ VibeSolo คือใช้โจทย์ ข้อมูล และเกณฑ์ตรวจงานเดียวกันเมื่อเปรียบเทียบวิธีเชื่อมต่อ แล้วดูความถูกต้อง เวลา และต้นทุนร่วมกัน
ข้อเสนอของ Jan ชวนแยกมาตรฐานเชื่อมต่อออกจากวิธีจัดเครื่องมือและข้อมูลให้ Agent ส่วนที่นำมาทดลองได้คือการค้นหาความสามารถเมื่อจำเป็น การจัดข้อมูลผ่าน shell และการเปรียบเทียบ connector ด้วยงานเดียวกัน ผลจริงยังต้องวัดกับระบบของทีม
ที่มา: Jan Čurn จาก Apify ทางช่อง AI Engineer อัปโหลดวันที่ 2 ตุลาคม 2026 เวลา 21:00:05 น. ตามเวลาไทย (14:00:05 UTC) สรุปจากคำบรรยายภาษาอังกฤษที่บันทึกไว้ช่วง 00:12–18:22 ซึ่งขาดช่วงต้นและท้าย ไม่ได้ตรวจโค้ด เดโม หรือความพร้อมใช้ของบริการอย่างอิสระ วันอัปโหลดเป็นวันของแหล่งข้อมูล ไม่ใช่วันเผยแพร่บทความนี้
